Unified Modeling Language® (OMG UML®) V2.51.pdf
This specification defines the Unified Modeling Language (UML), revision 2. The objective of UML is to provide
system architects, software engineers, and software developers with tools for analysis, design, and implementation of
software-based systems as well as for modeling business and similar processes.
The initial versions of UML (UML 1) originated with three leading object-oriented methods (Booch, OMT, and OOSE),
and incorporated a number of best practices from modeling language design, object-oriented programming, and
architectural description languages. Relative to UML 1, this revision of UML has been enhanced with significantly
more precise definitions of its abstract syntax rules and semantics, a more modular language structure, and a greatly
improved capability for modeling large-scale systems.
The LML specification’s purpose is to provide a reference for users of the language to understand its goals, concepts and structure and to provide vendors a reference for implementation of the language.
The basis for the LML formulation is the classic entity, relationship, and attribute (ERA) meta - meta model.
This formulation modifies the classical approach slightly by includ ing attributes on relationships, to provide the
adverb, as well as the noun (entity), relationship (verb), and attribute (ad jective ) language elements. Since LML
was designed to translate to object languages, such as UML/SysML, these language elements correspond to
classes (entity), relations (relationship), and properti es (attribute).
Current Systems Engineering languages tend to add complexity to already complex problems, thus making
it more difficult to communicate the unde rlying issues and develop effective solutions. LML is designed to be a
simpler language, both in terms of its ontology and visual expressions. This feature makes it easy to
understand by the entire set of lifecycle stakeholders. Such a simplified language many not include all the
“bins” for information a particular domain wants, hence, LML is extensible allowing for discipline and domain
specific extensions to support the needs of a specific pro ject, organization or customer. The process for
extension submission will be detailed on the lifecyclemodeling.org website.
For example, UML and SysML use the term Actor to define a part of the system that performs actions . The
DoDAF Metamodel 2 uses the word Performer for the same purpose. LML uses the term, Asset, but also
allows the user to extend the language by defining Actors or Performers. However, we recommend modelers
use the type attribute for Assets instead, as a means to differentiate between these different names. New
entities or child entities are recommended only when new attributes and/or relationships are needed. Thus
modelers using LML will know what entity to put something in immediately and can adjust the type as needed.
We saw this problem in the DoDAF where modelers were often confused by the difference between an
operational node and a systems node. When you have two “bins” to put the same kind of information into
confusion often results. Further examples of this comparison appear in Appendix A and B.
This specification of LML also defines common visualizations for information. For example, the Risk entity
has a standard Risk Matrix as its basic diagram. Each entity has these kinds of common visualizations and
they need to be as simple as possible to reduce the complexity of the language and make it more
understandable by a broader set of stakeh olders. Other visualizations are allowed and encouraged as they aid
in expressing the information, which is the real goal of any language visualizations. These can and should be
proposed as extensions to the language as well so that others practitioners can benefit from these
visualizations.
Ontologies provide a set of defined terms and relationships between the terms to capture the information
that describes the physical, functional, performance, and programmatic aspects of the system. By system,
1
we mean the entire set of processes, people and things which operate for the benefit of people. Common ways for
describing such ontologies is entity, relationship, and attribute (ERA). ERA is often used to define database
schemas. LML use s the ERA approach, but extends it by adding attribute s to relationships. The extension
reduces the number of relationships needed, just as attributes reduce the number of entities needed.
This section defines the ERAs for LML, thus providing the basic definitions of the data type s used to collect
information about the system . In addition, we describe how inheritance, extensions, limitations and instantiation
can be used by tool developers to remain within the guidelines of this standard.
Entity, relationship and attribute have equivalent English language elements: noun, verb, and adjective.
With the addition of attributes on the relationship, we also have the equivalent of the adverb. These
equivalencies have been provided to aid in understanding the semantics of the language.
Architecture-Driven Modernization Knowledge Discovery Meta-Model (KDM) V1.3.pdf
KDM is defined via Meta-Object Facility (MOF). KDM determines the interchange format via the XML Metadata
Interchange (XMI) by applying the standard MOF to XMI mapping to the KDM MOF model. The interchange format
defined by KDM is called the KDM XMI schema. The KDM XMI schema is provided as the normative part of this
specification.
KDM is a meta-model with a very broad scope that covers a large and diverse set of applications, platforms, and
programming languages. Not all of its capabilities are equally applicable to all platforms, applications, or programming
languages. The primary goal of KDM is to provide the capability to exchange models between tools and thus facilitate
cooperation between tool suppliers to integrate multiple facts about a complex enterprise application, as the complexity
of modern enterprise applications involves multiple platform technologies and programming languages. In order to
achieve interoperability and especially the integration of information about different facets of an enterprise application
from multiple analysis tools, this specification defines several compliance levels thereby increasing the likelihood that
two or more compliant tools will support the same or compatible meta-model subsets. This suggests that the meta-model
should be structured modularly, following the principle of separation of concerns, with the ability to select only those
parts of the meta-model that are of direct interest to a particular tool vendor. Separation of concerns in the design of KDM
is embodied in the concept of KDM domains.
Architecture-driven Modernization Abstract Syntax Tree Metamodel (ASTM) V1.pdf
The purpose of the ASTM is to provide a framework that allows tool vendors and tool clients to build and use tools that
conform to commonly agreed upon modeling specifications for the interchange of abstract syntax models of software.
Interoperability is achieved when models can be interchanged using modeling elements that conform to those specified in the
ASTM specification. The internal proprietary models of tools need not conform the ASTM for a tool to be considered
compliant with the ASTM. To be considered compliant a tool need only adhere to the ASTM as a model interchange
specification. Tool conformance is concerned solely with the ability of tools to interchange models that conform to the ASTM.
• For a GAST model to conform with the ASTM it must conform to the GAST Metamodel provided by this
specification.
• For a SAST model to conform to the ASTM it must conform to both the GASTM model provided with this
specification as well as the SASTM model provided by some future SASTM specification.
The ASTM is a bi-dimension multi-layered modeling specification. The two dimensions of the ASTM define both
syntactic as well as the semantic properties of software. The layers of the ASTM define a core set of modeling elements,
the GASTM, that are common to many programming languages as well as a set of extensions, the SASTMs, that extend
from the core for and are used in concert with the GASTM for defining models specialized to particular programming
languages. Table 2.1 illustrates the Compliance Points of the ASTM.
Ontology Definition Metamodel V1.1.pdf
There are several compliance points distinguished for the Ontology Definition Metamodel. These include:
1. None or Not Compliant, meaning that the application in question is not compliant with a particular metamodel, as
defined by the metamodel itself, the abstract syntax, well-formedness rules, semantics, and notation specified for a
particular package or set of packages.
2. Compliant, meaning that the implementation fully complies with the abstract syntax, well-formedness rules,
semantics and notation of a particular package or set of packages.
3. Interchange, indicating that the implementation provides compliance as specified in [2], and can exchange
metamodel instances using ODM package conformant XMI.
There are several possible entry points for implementations that want to provide/claim minimal compliance with the
ODM. These require compliance with one of the following base metamodel packages:
• RDFBase Metamodel Package (RDFBase is a sub package of the Resource Description Framework (RDF) Metamodel
Package).
• Topic Maps (TM) Metamodel Package.
• Common Logic (CL) Metamodel Package.
For a given implementation to claim ODM compliance, it must be Compliant, as defined in 2, above, with one of these
three packages.
There are several compliance options available to vendors for the RDF Metamodel Package. These include:
• RDFBase Only - as implied above, this package contains the set of elements requ ired for core RDF support, such as is
necessary to support a triple store implementation; the focu s here is on the set of constructs defined in the RDF
Concepts and Abstract Syntax [RDF Concepts] document.
• RDFBase + RDFWeb - provides core RDF support and fits these concepts to the World Wide Web.
• RDFBase + RDFS - moves the implementation focus from core RDF to RDF Schema, as specified in [RDF Schema].
• RDF - meaning, the implementation supports all of the concepts defined in the three sub packages, which represents
RDF Schema fitted to the Web.
There are two possible compliance points for the OWL Metamodel Package. Each of these requires support for the entire
RDF package, including the RDFWeb component. They include:
• OWLBase + OWLDL - focus is on a description logics application that constrains an ontology in turn for DL
decidability.
• OWLBase + OWLFull - focus is on more expressive applications rather than on decidability of entailment.
The complete set of ODM compliance options is summarized in Table 2.1.
Business Motivation Model V1.3.pdf
Fundamental to the Business Motivation Model is the notion of ‘motivation.’ If an enterprise prescribes a certain
approach for its business activity, it ought to be able to say ‘why ;’ that is, what result(s) the approach is meant to achieve.
Sometimes it is difficult to uncover such motivation, especially in operations that have been going on for some time. All
too often it turns out to be “...because we had to find a workaround for a system that didn’t do quite what was needed.”
This may describe business work prac tice, information systems, or both.
A cornerstone of any work addressing motivation has to be the enterprise’s aspirations (its Vision) and its action plans for
how to realize them (its Mission). Refinements were intr oduced; Vision into Goals and Objectives, and Mission into
Strategies for approaching Goals, and Tactics for achieving Objectives. The general term End was adopted to refer
broadly to any of the ‘aspiration’ concepts (Vision, Goal, Objective) and the term Means to refer generally to any of the
‘action plan’ concepts (Mission, Strategy, Tactic). This conjunction of Ends and Means ‘being’ and ‘doing’ provides the
core concepts of the Model
1
.
An enterprise, however, cannot operate on this Model alone — the business needs to take into account the numerous
Influencers that can hinder or assist its operation. These Influencers provide Oppor tunities that would help the enterprise
operate, as well as Threats that would thwart it. Influencers also represent Strengths from within that the enterprise could
exploit, or Weaknesses that it should compensate for.
But is an Influencer inherently a Strength or Weakness — is it always a Threat or Opportunity? That determination comes
from an Assessment of the impact of an Influencer on the st ated Ends and Means — an Assessment such as is developed
in SWOT
2
analysis. In this commonly-used technique, Internal In fluencers (assessed to be Strengths and Weaknesses) and
External Influencers (assessed to be O pportunities and Threats) are analyzed as a part of business plan development.
Once an Assessment has identified relevant Influencers in terms of their impact on Ends and Means, Directives (Business
Policies and Business Rules) can be put in place to govern and guide the enterprise Courses of Action. Directives keep the
enterprise on course and moving toward its Desired Results. Because of their integr al role in guiding Courses of Action,
Directives are included in the set of Means concepts.
Business Rules are noteworthy in that regard. Business Rule s sharpen the Business Tactics be cause they make Courses of
Action concrete at the operational level. Bu siness Rules can also provide specific remedies when a Course of Action fails,
and specific resolutions to conflicts that inevitably arise amon g the Ends. In short, Business Rules provide the leverage
needed for building effective, adaptable business solutions and systems.
Production Rule Representation (PRR) V1.pdf
The Production Rule Representation (PRR) fulfills a number of requirements related to business rules, software systems,
OMG standards, and other rule standards.
• It provides a standard production rule representation that is compatible with rule engine vendors’ definitions of
production rules. It can therefore be used for interchange of business rules amongst rule modeling tools (and other
tools that support rule modeling as a function of some other task).
• It provides a standard production rule representation that is readily mappable to business rules, as defined by business
rule management tool vendors.
• It provides a standard production rule definition that supports and encourages system vendors to support production
rule execution.
• It provides an OMG MDA PIM model with a high probability of support at the PSM level from the contributing rule
engine vendors and others, and can be included to add production rule capabilities to other OMG metamodels.
• It provides examples of how the OMG UML can be used to support production rules in a standardized and useful way.
• It provides a standard production rule representation that can be used as the basis for other efforts such as the W3C
Rule Interchange Format and a production rule version of RuleML.
Systems Modeling Language (OMG SysML™) 1.6.pdf
The purpose of this International Standard is to specify the Systems Modeling Language (SysML), a general-purpose
modeling language for systems engineering. Its intent is to specify the language so that systems engineering modelers
may learn to apply and use SysML; modeling tool vendors may implement and support SysML; and both can provide
feedback to improve future versions. Note that a definition of “system” and “systems engineering” can be found inISO/
IEC 15288.
SysML reuses a subset of UML 2.5 and provides additional extensions to address the requirements in UML for SE.
SysML uses the UML 2.5 extension mechanisms as further elaborated in Clause 17 as the primary mechanism to
specify the extensions to UML 2.5. This revision of SysML relies on several new features incorporated into UML 2.5.
Any use of the term “UML 2” or “UML” in this specification, unless otherwise noted, will refer to UML 2.5 in general
and the UML 2.5 specification in particular.
Since SysML uses UML 2.5 as its foundation, systems engineers modeling with SysML and software engineers
modeling with UML 2.5 will be able to collaborate on models of software-intensive systems. This will improve
communication among the various stakeholders who participate in the systems development process and promote
interoperability among modeling tools. It is anticipated that SysML will be customized to model domain-specific
applications, such as automotive, aerospace, communication, and information systems.
SysML is designed to provide simple but powerful constructs for modeling a wide range of systems engineering
problems. It is particularly effective in specifying requirements, structure, behavior, allocations, and constraints on
system properties to support engineering analysis. The language is intended to support multiple processes and methods
such as structured, object-oriented, and others, but each methodology may impose additional constraints on how a
construct or diagram kind may be used. This version of the language supports most, but not all, of the requirements of
the UML for Systems Engineering RFP, as shown in the Requirements Traceability referenced by Annex F. These gaps
are intended to be addressed in future versions of SysML as indicated in the matrix.
The following sub clauses provide background information about this International Standard. Instructions for both
systems engineers and tool vendors who read this International Standard are provided in “How to Read this
International Standard.” The main body of this International Standard describes the normative technical content. The
annexes include additional information to aid in understanding and implementation of this International Standard.
Unified Architecture Framework (UAF) V1
This Appendix describes the Unified Architecture Framework, the Domain Meta-Model (DMM) that captures the concepts,
relationships, and viewpoints that specify the Unified Architecture Framework Profile (UAFP). As well as providing the
DMM for the UAFP, it is intended to provided a non-implementation specific metamodel for those non-UML or SysML tool
vendors who may wish to implement the UAF, consequently it is not neccessary to generate XMI for the UAF.
Value Delivery Modeling Language (VDML) V1.1
The purpose of VDML is to provide a standard modeling language for analysis and design of the operation of an
enterprise with particular focus on th e creation and exchange of value. It provides an abstraction of the operation
of an enterprise that is appropriate for business executives, along with representation of supporting detail for
business analysts to link strategy and business models to the activities, roles, and capabilities that run the
enterprise. The target users are business people—executives, business architects, analysts and managers.
Information systems analysts and designers may use VDML models as specifications for the design of
supporting information systems.
