The F-22 predates MoD approaches, or let us say that it uses "incipient" MoD approaches - it obviously predates the UML or the MOD approach as it is a 20+ year old project. And of course as you say they are a leader and this gets transitioned in one way or another back to this effort though it is not its major thrust. Designs were to be "backed modeled" to the UML, and new design models in the UML but these tend to be higher level usages of the UML and aimed at "RUP like" requirements engineering. Another area that the UML comes in is obviously describing state machines. The problem with these approaches is that it is deeply hard to capture in a reasonable way all of the millions of interaction between the various objects solely in the UML. This is particularly true in descibing very complex real time state machines that are not really of the linear "nested" sort that the UML is so good at describing (I know that you can describe other systems with the UML, but just reflect on it for a second and you can imagine how unwieldy it might get.) Whatever the Air Force might say, the UML approach has in fact been used as a design aid rather that the sort of "compilable design" that you are pointing to, at least in embedded real time systems. They tend to use it more in "traditional" information systems (eg. non embedded systems.) They are less than honest about this and, of course, there are competing camps and differnet schools of thought and practice in that community.
But in a way you are quite right about the source code issue but for an entirely different reason. Typically in avionics enviroments there are at least three development environments: 1) a developer's simulated "sandbox" which is ussauly just software and has nothing to do with the target environment (it could just be a standard UNIX environment but could be a real time UNIX - or other - environment,) 2) An "intermediate testbed" that could just be a software environment or could have some real target hardware (or combinations there of,) and 3) the actual target hardware ans software test bed. Each one othese envionments could have entirely different Hardware, machine laguages and operating systems.
The point is that in an ADA shop you would work in ADA and cross compile to whatever machine language the testbed ran in. So architects and programmers really are just thinking in ADA, not machine code or in many cases not even middle level constructions like "setjumps" that you might see in "C" or "C++." <
As an aside, while I am a big believer in the UML, there have been quite a bit of problems using it to capture every aspect about a problem domain and practically work out the sort of "compilable design" you favor, and this is particularly true on large projects and most particularly true in embedded real time. Three seems to be some middle ground that encompasses round trip engineering approaches and other "unwisely" engineering approaches. It is a laudable goal but so far more honored in its breach than in its realization, no matter what the MoD geeks at the OMG say about it.