Jump to content

Universal Systems Language: Difference between revisions

Edit links
From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
DBTF
m Jjjjjjjjjj moved page Universal systems language to Universal Systems Language over redirect: Misspelled: It seems that in ordinary prose it is written as "Universal Systems Language", so just like for Corporation for Public Broadcasting or United Nations High Commissioner for Refugees can use title case. There's a section in the talk page for this change.
 
(46 intermediate revisions by 28 users not shown)
Line 1: Line 1:
⚫
'''Universal Systems Language''' ('''USL''') is a systems [[modeling language]] and [[formal method]] for the specification and design of software and other complex systems. It was designed by [[Margaret Hamilton (scientist)|Margaret Hamilton]] based on her experiences writing flight software for the [[Apollo program]].<ref name="USL">[[Margaret Hamilton (scientist)|M. Hamilton]] and W.&nbsp;R. Hackler, "[http://www.htius.com/Articles/r12ham.pdf Universal Systems Language: Lessons Learned from Apollo]", IEEE Computer, Dec. 2008.</ref> The language is implemented through the 001 Tool Suite software by Hamilton Technologies, Inc.<ref>[http://www.htius.com 001 Tool Suite (1986-2020)]</ref> USL evolved from 001AXES which in turn evolved from AXES all of which are based on Hamilton's axioms of control. The 001 Tool Suite uses the preventive concept of Development Before the Fact (DBTF) for its life-cycle development process. DBTF eliminates errors as early as possible during the development process removing the need to look for errors after-the-fact.
{{Multiple issues|
{{context|date=June 2009}}
{{confusing|date=June 2009}}
{{COI|date=July 2016}}
}}


==Philosophy==
⚫
Universal Systems Language is a [[modeling language]] and [[formal method]] for the specification and design of software and other complex systems. It was designed by [[Margaret Hamilton (scientist)|Margaret Hamilton]] based on her experiences writing flight software for the [[Apollo program]].<ref name="USL">[[Margaret Hamilton (scientist)|M. Hamilton]] and W.&nbsp;R. Hackler, "[http://www.htius.com/Articles/r12ham.pdf Universal Systems Language: Lessons Learned from Apollo]", IEEE Computer, Dec. 2008.</ref> The language is implemented through the 001 Tool Suite software by Hamilton Technologies, Inc.<ref>[http://www.htius.com 001 Tool Suite (1986-2015)]</ref> Previous iterations of the concept have been known as 001AXES, Development Before The Fact, or Higher Order Software.
USL was inspired by Hamilton's recognition of patterns or categories of errors occurring during Apollo software development.<ref>{{cite web|title="Universal Systems Language and its Automation, the 001 Tool Suite, for Designing and Building Systems and Software" Lockheed Martin/IEEE Computer Society Webinar Series|author= Margaret H. Hamilton, Hamilton Technologies|date=September 27, 2012|url=https://media.computer.org/sponsored/podcast/lmco/lmco-089-p.mp4?_kip_ipx=966916323-1480349712}}</ref><ref name="Hamilton2018">{{cite journal |last=Hamilton |first=Margaret H. |title=What the Errors Tell Us |journal=[[IEEE Software]] |volume=35 |issue=5 |year=2018 |pages=32–37 |issn=0740-7459 |doi=10.1109/MS.2018.290110447|s2cid=52896962 |doi-access=free }}</ref>


Certain correctness guarantees are embedded in the USL grammar.<ref>Dolha, Steve, Chiste, Dave, "A Remote Query System for the Web: Managing the Development of Distributed Systems.", Chapter 32, Internet Management, Editor Jessica Keyes, Auerbach, 2000.</ref>
==Apollo beginnings==
USL had as its origin its creators' study of the [[Apollo program]] flight software development.<ref name="USL"/> This study included the errors that took place during verification and validation of the Apollo software.


USL is regarded by some users as more [[usability|user-friendly]] than other formal systems.<ref>Krut, Jr., B., "[https://apps.dtic.mil/sti/pdfs/ADA293427.pdf Integrating 001 Tool Support in the Feature-Oriented Domain Analysis Methodology]" (CMU/SEI-93-TR-11, ESC-TR-93-188), Pittsburgh, SEI, Carnegie Mellon University, 1993.</ref> It is not only a formalism for software, but also defines [[ontology (information science)|ontologies]] for common elements of problem domains, such as physical space and event timing.
The interface errors were analyzed in greater detail first, because they not only accounted for the majority of errors, they also were often the most subtle and most difficult to find. Each interface error was placed into a category identifying the means to prevent it by way of system definition. This process led to a set of six axioms, forming the basis for a new mathematical theory for designing systems that would, among other things, eliminate the entire class of interface errors just by the way a system is defined.


⚫
==Formalism for a theory of control==
Given the ongoing evaluation of the Apollo effort, it became clear that a new kind of language was needed and that this mathematical theory could provide its core. Results of the analysis took on many dimensions, not just for space missions but for applications in general, and not just for software but systems in general – the results of which were not readily apparent for many years to come.
⚫
<ref>[[Margaret Hamilton (scientist)|Hamilton, M.]], "[http://www.htius.com/Articles/ELECTRONIC_DESIGN/INSIDE_DBTF.pdf Inside Development Before the Fact"], cover story, Special Editorial Supplement, 8ES-24ES. Electronic Design, Apr. 1994.</ref><ref>[[Margaret Hamilton (scientist)|Hamilton, M.]], "[http://www.htius.com/Articles/ELECTRONIC_DESIGN/001_A_FULL_LIFE_CYCLE.pdf 001: A FULL LIFE CYCLE SYSTEMS ENGINEERING AND SOFTWARE DEVELOPMENT ENVIRONMENT Development Before The Fact In Action"], cover story, Special Editorial Supplement, 8ES-24ES. Electronic Design, Apr. 1994.</ref>


Primitive structures are universal in that they are able to be used to derive new abstract universal structures, functions or types. The process of deriving new objects (i.e., structures, types and functions) is equivalent to the process of deriving new types in a constructive type theory.
Lessons learned from this effort continue today: Systems are asynchronous, distributed, and event-driven in nature, and this should be reflected inherently in the language used to define them and the tools used to build them. This implies that a system's definition should characterize natural behavior in terms of real-time execution semantics, and designers should no longer need to explicitly define schedules of when events are to occur. Instead, events should occur when objects interact with other objects so that by defining such interactions the schedule of events is inherently defined. Most importantly, it became clear that the root problem with traditional approaches is that they support users in "fixing wrong things up" rather than in "doing things in the right way in the first place". Combined with further research, as this became more widely understood, it became clear that the characteristics of good design could be reused by incorporating them into a language for defining systems.


⚫
[[Image:ucs rules.png|center|frame|Figure. 1 The three primitive control structures and their rules form a universal foundation for constructing maps in the domains of time and space as FMaps and TMaps]]
USL captures the lessons learned from Apollo. When a model is defined with USL, correctness is accomplished by the very way a system is defined, by built-in language properties inherent in the grammar. Whereas the traditional software development approach is curative, testing for errors late into the life cycle, USL's development-before-the-fact philosophy is preventive, not allowing errors in the first place. A USL definition models both its application (for example, an avionics or banking system) and properties of control into its own life cycle.<ref>Dolha, Steve, Chiste, Dave, "A Remote Query System for the Web: Managing the Development of Distributed Systems.", Chapter 32, Internet Management, Editor Jessica Keyes, Auerbach, 2000.</ref> Each SOO definition has built-in constraints that support the designer and developer, yet they do not take away flexibility in fulfilling requirements. A SOO inherently integrates all aspects of a system (for example, function-, object-, and timing-oriented). Every system is an object, every object a system.


==Implementation==
Mathematical approaches are known to be difficult to understand and are limited in their use for nontrivial systems as well as for much of the system's life cycle. Unlike formal languages that are not friendly or practical, and friendly or practical languages that are not formal, its users consider USL to be not only formal but also practical and friendly.<ref>Middleton, Frank, "USL For Fun and Profit", The IEEE Newsletter May 2009, IEEE North Jersey Section Computer Society Chapter, May 19, 2009.</ref><ref>Krut, Jr., B., "[http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA293427 Integrating 001 Tool Support in the Feature-Oriented Domain Analysis Methodology]" (CMU/SEI-93-TR-11, ESC-TR-93-188), Pittsburgh, SEI, Carnegie Mellon University, 1993.</ref> Unlike other mathematically based [[formal methods]], USL extends traditional mathematics with a unique concept of control: universal real-world properties internal to its grammar – such as those related to time and space – are inherent, enabling USL to support the definition and realization of any kind or size of system. The formalism along with its unfriendliness is "hidden" by language mechanisms derived in terms of that formalism.
⚫
The process of developing a software system with USL together with its automation, the 001 Tool Suite (001), is as follows: define the system with USL, automatically analyze the definition with 001's analyzer to ensure that USL was used correctly, automatically generate much of the design and all of the implementation code with 001's generator.<ref>Ouyang, M., Golay, M.W. 1995, ''[http://dspace.mit.edu/handle/1721.1/67642 An Integrated Formal Approach for Developing High Quality Software of Safety-Critical Systems]'', Massachusetts Institute of Technology, Cambridge, Massachusetts, Report No. MIT-ANP-TR-035.
⚫
</ref><ref>Software Productivity Consortium, (SPC) (1998), ''Object-Oriented Methods and Tools Survey'', Herndon, VA.SPC-98022-MC, Version 02.00.02, December 1998.</ref><ref>Max Schindler (1990) ''Computer Aided Software Design'', John Wiley & Sons, 1990.</ref><ref>* Department of Defense (1992). ''Software engineering tools experiment-Final report'', Vol. 1, Experiment Summary, Table 1, p.&nbsp;9. Strategic Defense Initiative, Washington, D.C.</ref> USL can be used to lend its formal support to other languages.<ref>[[Margaret Hamilton (scientist)|Hamilton, M.]] Hackler, W.R., "[http://www.htius.com/Articles/INCOSE.pdf A Formal Universal Systems Semantics for SysML], 17th Annual International Symposium, INCOSE 2007, San Diego, CA, June 2007.</ref>


==See also==
==General systems theory==
* [[Systems philosophy]]
A formalism for representing the mathematics of systems, USL is based on a set of axioms of the general systems theory and formal rules for their application. All representations of a system are defined in terms of a function map (FMap) and a type map (TMap). Every SOO is defined in terms of a set of FMaps and TMaps. Three primitive structures derived from the set of axioms and non-primitive structures derived ultimately in terms of the primitive structures specify each map. Primitive functions, corresponding to primitive operations on types defined in a TMap, reside at the bottom nodes of an FMap. Primitive types, each defined by its own set of axioms, reside at the bottom nodes of a TMap. Each primitive function (or type) can be realized as a top node of a map on a lower (more concrete) layer of the system.
* [[IDEF]]

* [[Model-driven architecture]]
Providing a mathematical framework within which objects, their interactions, and their relationships can be captured, USL – a metalanguage – has "metamechanisms" for defining systems. USL's philosophy is that all objects are recursively reusable and reliable; reliable systems are defined in terms of reliable systems; only reliable systems are used as building blocks; and only reliable systems are used as mechanisms to integrate these building blocks to form a new system. Designers can then use the new system, along with more primitive ones, to define (and build) more comprehensive reliable systems. If a system is reliable, all the objects in all its levels and layers are reliable.
* [[Systems modeling language]]

* [[Object process methodology]]
⚫
==Six axioms of control==
We must visualize a system definition both by what it does (level by level, ''e.g.'', a parent node in a hierarchy is on a higher level than its children nodes) and how it does it layer by layer, e.g., a specification is on a higher layer than its implementation). However, a hierarchical definition runs the risk of not being reliable unless there are explicit rules that ensure each decomposition is valid; for example, the behavior of a successive lower level (or layer) completely replaces the behavior of that which it replaces. A SOO can be defined from its most general state to its most detailed states. Objects, related properly, can replace other objects. An object is decomposed until the primitive objects by which it has been defined have been reached.

⚫
At the base of every USL system is a set of six axioms – universally recognized truths – and the assumption of a universal set of objects.<ref>[[Margaret Hamilton (scientist)|Hamilton, M.]], "[http://www.htius.com/Articles/ELECTRONIC_DESIGN/INSIDE_DBTF.pdf Inside Development Before the Fact"], cover story, Special Editorial Supplement, 8ES-24ES. Electronic Design, Apr. 1994.</ref><ref>[[Margaret Hamilton (scientist)|Hamilton, M.]], "[http://www.htius.com/Articles/ELECTRONIC_DESIGN/001_A_FULL_LIFE_CYCLE.pdf 001: A FULL LIFE CYCLE SYSTEMS ENGINEERING AND SOFTWARE DEVELOPMENT ENVIRONMENT Development Before The Fact In Action"], cover story, Special Editorial Supplement, 8ES-24ES. Electronic Design, Apr. 1994.</ref> The axioms provide the formal foundation for a USL "hierarchy" – referred to as a map, which is a tree of control that spans networks of relations between objects. Explicit rules for defining a map have been derived from the axioms, where – among other things – structure, behavior, and their integration are captured.

Resident at every node on a map is the same kind of object (for example, a function on every node of an FMap and a type on a TMap). The object at each node plays multiple roles; for example, the object can serve as a parent (in control of its children) or a child (being controlled by its parent). Whereas each function on an FMap has a ''mapping'' from its input to output (domain to codomain), each type on a TMap has a ''relation'' between its domain and codomain.

Each axiom defines a relation of immediate domination of a parent over its children. The union of these relations is control. Among other things, the axioms establish the relationships of an object for invocation in time and space, input and output (domain and codomain), input access rights and output access rights (domain access rights and codomain access rights), error detection and recovery, and ordering during its developmental and operational states. Every system can ultimately be defined in terms of three primitive control structures, each of which is derived from the six axioms – resulting in a universal semantics for defining systems.

==Universal primitive control structures==
A structure relates each parent and its children according to the set of rules derived from the axioms of control. A primitive structure provides a relationship of the most primitive form (finest grain) of control. All maps are defined ultimately in terms of the primitive structures and therefore abide by the rules associated with each structure: A parent controls its children to have a dependent (Join), independent (Include), or decision-making relationship (Or).

Figure 1 shows the rules used in defining each of the three primitive structures, using a syntax that can be shared by FMaps and TMaps. Because it is defined in terms of these structures, every SOO has control properties, inherently providing seamless integration, maximizing its own reliability and flexibility to change, capitalizing on its own parallelism, and maximizing the potential for its own reuse and automation. The structures ensure that all interface errors – approximately 75 to 90 percent of all errors normally found during testing in a traditional development – are eliminated at the definition phase.{{Citation needed|date=November 2011}}

⚫
[[Image:ucs rules.png|center|frame|Caption|Figure. 1 The three primitive control structure and their rules form a universal foundation for constructing maps in the domains of time and space as FMaps and TMaps]]

Any system can be defined completely using only primitive structures, but less primitive structures defined by and derived from the primitive structures – and therefore governed by the control axioms – accelerate the definition and understanding of a system. The defined structure, a powerful form of template-like reuse, provides a mechanism to define a map without explicitly defining some of its elements. An FMap structure has placeholders for variable functions; a TMap structure has placeholders for variable types; a universal structure has placeholders for functions or types. Async is an example of a real-time, distributed, communicating FMap structure with both asynchronous and synchronous behavior. An example of a TMap structure is TreeOf, a collection of the same type of objects ordered using a tree indexing system. Each TMap structure assumes its own set of possible relations for its parent and children types. Abstract types decomposed with the same TMap structure inherit the same primitive operations and therefore the same behavior (each of which is available to FMaps that have access to members of each of its TMap's types). As researchers gain experience with new and different types of applications, new reusable structures emerge.

With USL, all functions in a system and their relationships are defined with a set of FMaps. Similarly, all types in a system and their relationships are defined with a set of TMaps. FMaps represent the dynamic (doing) world of action by capturing functional and temporal (including priority) characteristics. TMaps represent the static (being) world of objects by capturing spatial characteristics – for example, containment of one object by another or relationships between locations of objects in space. FMaps are inherently integrated with TMaps.

⚫
The process of developing a software system with USL together with its automation, the 001 Tool Suite (001), is as follows; define the system with USL, automatically analyze the definition with 001's analyzer to ensure that USL was used correctly, automatically generate much of the design and all of the implementation code, production-ready, with 001's generator.<ref>Ouyang, M., Golay, M.W. 1995, ''[http://dspace.mit.edu/handle/1721.1/67642 An Integrated Formal Approach for Developing High Quality Software of Safety-Critical Systems]'', Massachusetts Institute of Technology, Cambridge, MA, Report No. MIT-ANP-TR-035.
⚫
</ref><ref>Software Productivity Consortium, (SPC) (1998), ''Object-Oriented Methods and Tools Survey'', Herndon, VA.SPC-98022-MC, Version 02.00.02, December 1998.</ref><ref>Max Schindler (1990) ''Computer Aided Software Design'', John Wiley & Sons, 1990.</ref><ref>* Department of Defense (1992). ''Software engineering tools experiment-Final report'', Vol. 1, Experiment Summary, Table 1, p.&nbsp;9. Strategic Defense Initiative, Washington, D.C.
</ref>

Most of today's systems are defined with a language(s) originally intended for software. These systems are built using a programming or specification language created specifically for a computer, a syntax-first, syntax-dependent approach. USL, based on a formal systems theory derived from real-world system, a semantics-first, syntax-independent approach, was originally created for defining systems in general, where the goal was to combine mathematical perfection with engineering precision.

Unlike languages where language mechanisms, rules, and tools are added after the fact as more is learned about a class of systems, USL derives its language mechanisms and tools from its core set of primitive mechanisms. Because of this flexibility, USL can be used as it gracefully evolves as well as have the ability to lend its formal support to other languages.<ref>[[Margaret Hamilton (scientist)|Hamilton, M.]] Hackler, W.R., "[http://www.htius.com/Articles/INCOSE.pdf A Formal Universal Systems Semantics for SysML], 17th Annual International Symposium, INCOSE 2007, San Diego, CA, June 2007.</ref> By inheriting its preventive philosophy, the potential exists to "solve" (prevent) a given problem as early in the life cycle as possible.


==References==
==References==
Line 57: Line 30:


== Further reading ==
== Further reading ==
* [[Margaret Hamilton (scientist)|Hamilton, M.]], Zeldin, S. (1976), "Higher Order Software&nbsp;— A Methodology for Defining Software," IEEE Transactions on Software Engineering, vol. SE-2, no. 1, Mar. 1976.
* Hamilton, M., Zeldin, S. (1976), "Higher Order Software&nbsp;— A Methodology for Defining Software," IEEE Transactions on Software Engineering, vol. SE-2, no. 1, Mar. 1976.
*Hamilton, M. (April 1994). [http://www.htius.com/Articles/Inside_DBTF.pdf "Inside Development Before the Fact"]. (Cover story). Special Editorial Supplement. 8ES-24ES. ''Electronic Design''.
⚫
* [[Margaret Hamilton (scientist)|Hamilton, M.]], Hackler, W.R.. (2004), Deeply Integrated Guidance Navigation Unit (DI-GNU) Common Software Architecture Principles (revised dec-29-04), DAAAE30-02-D-1020 and DAAB07-98-D-H502/0180, Picatinny Arsenal, NJ, 2003-2004.
* [[Margaret Hamilton (scientist)|Hamilton, M.]] and Hackler, W.R. (2007), "[http://www.htius.com/Articles/36.pdf Universal Systems Language for Preventative Systems Engineering]," ''Proc. 5th Ann. Conf. Systems Eng. Res.'' (CSER), Stevens Institute of Technology, Mar. 2007, paper #36.
* Hamilton, M. (June 1994). [http://www.htius.com/Articles/001_A_Full_Life_Cycle.pdf "001: A Full Life Cycle Systems Engineering and Software Development Environment"]. (Cover story). Special Editorial Supplement. 22ES-30ES. ''Electronic Design''.
⚫
* Hamilton, M., Hackler, W.R.. (2004), Deeply Integrated Guidance Navigation Unit (DI-GNU) Common Software Architecture Principles (revised dec-29-04), DAAAE30-02-D-1020 and DAAB07-98-D-H502/0180, Picatinny Arsenal, NJ, 2003–2004.
* Hamilton, M. and Hackler, W.R. (2007), "[http://www.htius.com/Articles/36.pdf Universal Systems Language for Preventative Systems Engineering]," ''Proc. 5th Ann. Conf. Systems Eng. Res.'' (CSER), Stevens Institute of Technology, Mar. 2007, paper #36.
* Hamilton, M.; Hackler, W. R. (2007). "[http://www.htius.com/Articles/INCOSE.pdf A Formal Universal Systems Semantics for SysML]". 17th Annual International Symposium, INCOSE 2007, San Diego, CA, Jun. 2007.


==External links==
==External links==
Line 67: Line 43:
[[Category:Formal specification languages]]
[[Category:Formal specification languages]]
[[Category:Systems engineering]]
[[Category:Systems engineering]]
[[Category:Modeling languages]]

Latest revision as of 06:30, 23 February 2024

Universal Systems Language (USL) is a systems modeling language and formal method for the specification and design of software and other complex systems. It was designed by Margaret Hamilton based on her experiences writing flight software for the Apollo program.[1] The language is implemented through the 001 Tool Suite software by Hamilton Technologies, Inc.[2] USL evolved from 001AXES which in turn evolved from AXES all of which are based on Hamilton's axioms of control. The 001 Tool Suite uses the preventive concept of Development Before the Fact (DBTF) for its life-cycle development process. DBTF eliminates errors as early as possible during the development process removing the need to look for errors after-the-fact.

Philosophy

[edit]

USL was inspired by Hamilton's recognition of patterns or categories of errors occurring during Apollo software development.[3][4]

Certain correctness guarantees are embedded in the USL grammar.[5]

USL is regarded by some users as more user-friendly than other formal systems.[6] It is not only a formalism for software, but also defines ontologies for common elements of problem domains, such as physical space and event timing.

Formalism for a theory of control

[edit]

[7][8]

Primitive structures are universal in that they are able to be used to derive new abstract universal structures, functions or types. The process of deriving new objects (i.e., structures, types and functions) is equivalent to the process of deriving new types in a constructive type theory.

Figure. 1 The three primitive control structures and their rules form a universal foundation for constructing maps in the domains of time and space as FMaps and TMaps

Implementation

[edit]

The process of developing a software system with USL together with its automation, the 001 Tool Suite (001), is as follows: define the system with USL, automatically analyze the definition with 001's analyzer to ensure that USL was used correctly, automatically generate much of the design and all of the implementation code with 001's generator.[9][10][11][12] USL can be used to lend its formal support to other languages.[13]

See also

[edit]

References

[edit]
  1. ^ M. Hamilton and W. R. Hackler, "Universal Systems Language: Lessons Learned from Apollo", IEEE Computer, Dec. 2008.
  2. ^ 001 Tool Suite (1986-2020)
  3. ^ Margaret H. Hamilton, Hamilton Technologies (September 27, 2012). ""Universal Systems Language and its Automation, the 001 Tool Suite, for Designing and Building Systems and Software" Lockheed Martin/IEEE Computer Society Webinar Series".
  4. ^ Hamilton, Margaret H. (2018). "What the Errors Tell Us". IEEE Software. 35 (5): 32–37. doi:10.1109/MS.2018.290110447. ISSN 0740-7459. S2CID 52896962.
  5. ^ Dolha, Steve, Chiste, Dave, "A Remote Query System for the Web: Managing the Development of Distributed Systems.", Chapter 32, Internet Management, Editor Jessica Keyes, Auerbach, 2000.
  6. ^ Krut, Jr., B., "Integrating 001 Tool Support in the Feature-Oriented Domain Analysis Methodology" (CMU/SEI-93-TR-11, ESC-TR-93-188), Pittsburgh, SEI, Carnegie Mellon University, 1993.
  7. ^ Hamilton, M., "Inside Development Before the Fact", cover story, Special Editorial Supplement, 8ES-24ES. Electronic Design, Apr. 1994.
  8. ^ Hamilton, M., "001: A FULL LIFE CYCLE SYSTEMS ENGINEERING AND SOFTWARE DEVELOPMENT ENVIRONMENT Development Before The Fact In Action", cover story, Special Editorial Supplement, 8ES-24ES. Electronic Design, Apr. 1994.
  9. ^ Ouyang, M., Golay, M.W. 1995, An Integrated Formal Approach for Developing High Quality Software of Safety-Critical Systems, Massachusetts Institute of Technology, Cambridge, Massachusetts, Report No. MIT-ANP-TR-035.
  10. ^ Software Productivity Consortium, (SPC) (1998), Object-Oriented Methods and Tools Survey, Herndon, VA.SPC-98022-MC, Version 02.00.02, December 1998.
  11. ^ Max Schindler (1990) Computer Aided Software Design, John Wiley & Sons, 1990.
  12. ^ * Department of Defense (1992). Software engineering tools experiment-Final report, Vol. 1, Experiment Summary, Table 1, p. 9. Strategic Defense Initiative, Washington, D.C.
  13. ^ Hamilton, M. Hackler, W.R., "A Formal Universal Systems Semantics for SysML, 17th Annual International Symposium, INCOSE 2007, San Diego, CA, June 2007.

Further reading

[edit]
[edit]
Wikimedia Commons has media related to Universal Systems Language.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Universal_Systems_Language&oldid=1209713035"