Lifecycle Modeling Language

Last updated

The Lifecycle Modeling Language (LML) is an open-standard modeling language designed for systems engineering. It supports the full lifecycle: conceptual, utilization, support and retirement stages. Along with the integration of all lifecycle disciplines including, program management, systems and design engineering, verification and validation, deployment and maintenance into one framework. [1] LML was originally designed by the LML steering committee. The specification was published October 17, 2013.

Contents

This is a modeling language like UML and SysML that supports additional project management uses such as risk analysis and scheduling. LML uses common language to define its modeling elements such as entity, attribute, schedule, cost, and relationship. [2]

Overview

LML communicates cost, schedule and performance to all stakeholders in the system lifecycle. LML combines the logical constructs with an ontology to capture information. SysML is mainly constructs and has a limited ontology, while DoDAF MetaModel 2.0 (DM2) only has an ontology. Instead LML simplifies both the constructs and ontology to make them more complete, but still easier to use. There are only 12 primary entity classes. Almost all of the classes relate to each other and themselves with consistent words, i.e., Asset performs Action. Action performed by Asset. [3] SysML uses object oriented design, because it was designed to relate systems thinking to software development. No other discipline in the lifecycle uses object oriented design and analysis extensively. LML captures the entire lifecycle from cradle to grave. [1]

Systems Engineers have identified complexity as a major issue. [3] LML is a new approach to analyzing, planning, specifying, designing, building and maintaining modern systems. LML focuses on these 6 goals: 1. To be easy to understand 2. To be easy to extend 3. To support both functional and object oriented approaches within the same design 4. To be a language that can be understood by most system stakeholders, not just Systems Engineers 5. To support systems from cradle to grave 6. To support both evolutionary and revolutionary changes to system plans and designs over the lifetime of a system [1]

History

The LML Steering Committee was formed in February 2013 to review a proposed draft ontology and set of diagrams that forms the LML specification. Contributors from many academic and commercial organizations provided direct input into the specification, resulting in its publication in October 2013. Presentations and tutorials were given at the National Defense Industrial Association (NDIA) Systems Engineering Conference (October 2013) and the Systems Engineering in DC (SEDC) in April 2014. A predecessor to LML was developed by Dr. Steven H. Dam, SPEC Innovations, as part of a methodology called Knowledge-Based Analysis and Design (KBAD). The ontology portion was prototyping in a systems engineering database tool. Ideas on how to better implement it and the development of key LML diagrams (Action and Asset) were part of their Innoslate product development from 2009 to present. [4]

Ontology

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. Common ways for describing such ontologies are "Entity", "Relationship", and "Attribute" (ERA). ERA is often used to define database schemas. LML extends the ERA schema with "Attributes on Relationship", a feature that can reduce the number of required "Relationships", in the same way that "Attribute" reduce the number of required "Entities" in ERA. In alignment with the first goal of LML, "Entity", "Relationship", "Attribute", and "Attribute on Relationship" have equivalent English language elements: noun, verb, adjective and adverb. [1]

Entity (noun) An entity is defined as something that is uniquely identifiable and can exist by itself. There are only 12 parent entities in LML: Action, Artifact, Asset, Characteristic, Connection, Cost, Decision, Input/Output, Location, Risk, Statement and Time. Several child entities have been defined to capture information that stakeholders need. The child entities have the attributes and relationships of the parents plus additional attributes and relationships that make them unique. Child entities include: Conduit (child of Connection), Logical (child of Connection), Measure (child of Characteristic), Orbital (child of Location), Physical (child of Location), Requirement (child of Statement), Resource (child of Asset), and Virtual (child of Location). Every entity has a name or number or description attribute or combination of the three to identify it uniquely. The name is a word or small collection of words providing an overview of information about the entity. The number provides a numerical way to identify the entity. The description provides more detail about that entity. [1]

Attribute (adjective) The attributes work in the same way an adjective. Entities (the nouns) can have names, numbers, and description attributes. The inherent characteristic or quality of an entity is an attribute. Every attribute has a name that identifies it uniquely within an entity. Attributes names are unique within an entity, but may be used in other entities. The name provides an overview of information about the attribute. The attribute data type specifies the data associated with the attribute. [1]

Relationship (verb) The relationship works the same way a verb connects nouns or in this case the entities. The relationships enable a simple method to see how [entities] connect. For example, when connecting an action to a statement, LML uses “traced from” as the relationship: an Action is traced from a Statement. The inverse relation of traced from is “traced to.” Relationships are defined in both directions and have unique names with the same verb. The standard parent child relationship is decomposed by and its inverse is decomposes. Relationship names are unique across the whole schema. [1]

Attributes on Relationships (adverb) Classic ERA modeling does not include "attributes on relationships", but is included in LML. In terms of the English language, an "attribute on a relationship" is like an adverb, helping to describe the relationship. Analogous to the way in which attributes relate to entities the "attribute on a relationship" has a name that is unique to its relationship, but need not be unique across other relationships. [1]

List of LML Tools

See also

Related Research Articles

<span class="mw-page-title-main">Systems engineering</span> Interdisciplinary field of engineering

Systems engineering is an interdisciplinary field of engineering and engineering management that focuses on how to design, integrate, and manage complex systems over their life cycles. At its core, systems engineering utilizes systems thinking principles to organize this body of knowledge. The individual outcome of such efforts, an engineered system, can be defined as a combination of components that work in synergy to collectively perform a useful function.

<span class="mw-page-title-main">Data model</span> Abstract model

A data model is an abstract model that organizes elements of data and standardizes how they relate to one another and to the properties of real-world entities. For instance, a data model may specify that the data element representing a car be composed of a number of other elements which, in turn, represent the color and size of the car and define its owner.

A modeling language is any artificial language that can be used to express data, information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure of a programming language.

<span class="mw-page-title-main">Entity–relationship model</span> Model or diagram describing interrelated things

An entity–relationship model describes interrelated things of interest in a specific domain of knowledge. A basic ER model is composed of entity types and specifies relationships that can exist between entities.

Database design is the organization of data according to a database model. The designer determines what data must be stored and how the data elements interrelate. With this information, they can begin to fit the data to the database model. A database management system manages the data accordingly.

<span class="mw-page-title-main">Object Process Methodology</span> Modelling language and methodology for capturing knowledge and designing systems

Object process methodology (OPM) is a conceptual modeling language and methodology for capturing knowledge and designing systems, specified as ISO/PAS 19450. Based on a minimal universal ontology of stateful objects and processes that transform them, OPM can be used to formally specify the function, structure, and behavior of artificial and natural systems in a large variety of domains.

<span class="mw-page-title-main">Metamodeling</span> Concept of software engineering

A metamodel is a model of a model, and metamodeling is the process of generating such metamodels. Thus metamodeling or meta-modeling is the analysis, construction, and development of the frames, rules, constraints, models, and theories applicable and useful for modeling a predefined class of problems. As its name implies, this concept applies the notions of meta- and modeling in software engineering and systems engineering. Metamodels are of many types and have diverse applications.

<span class="mw-page-title-main">Information model</span>

An information model in software engineering is a representation of concepts and the relationships, constraints, rules, and operations to specify data semantics for a chosen domain of discourse. Typically it specifies relations between kinds of things, but may also include relations with individual things. It can provide sharable, stable, and organized structure of information requirements or knowledge for the domain context.

Domain-specific modeling (DSM) is a software engineering methodology for designing and developing systems, such as computer software. It involves systematic use of a domain-specific language to represent the various facets of a system.

<span class="mw-page-title-main">IDEF1X</span>

Integration DEFinition for information modeling (IDEF1X) is a data modeling language for the development of semantic data models. IDEF1X is used to produce a graphical information model which represents the structure and semantics of information within an environment or system.

The ISO 15926 is a standard for data integration, sharing, exchange, and hand-over between computer systems.

Web Modeling Language, (WebML) is a visual notation and methodology for the design of a data-intensive web applications. It provides a graphical means to define the specifics of web application design within a structured design process. This process can be enhanced with the assistance of visual design tools.

<span class="mw-page-title-main">Systems modeling language</span> General-purpose modeling language

The systems modeling language (SysML) is a general-purpose modeling language for systems engineering applications. It supports the specification, analysis, design, verification and validation of a broad range of systems and systems-of-systems.

A profile in the Unified Modeling Language (UML) provides a generic extension mechanism for customizing UML models for particular domains and platforms. Extension mechanisms allow refining standard semantics in strictly additive manner, preventing them from contradicting standard semantics.

Software mining is an application of knowledge discovery in the area of software modernization which involves understanding existing software artifacts. This process is related to a concept of reverse engineering. Usually the knowledge obtained from existing software is presented in the form of models to which specific queries can be made when necessary. An entity relationship is a frequent format of representing knowledge obtained from existing software. Object Management Group (OMG) developed specification Knowledge Discovery Metamodel (KDM) which defines an ontology for software assets and their relationships for the purpose of performing knowledge discovery of existing code.

The Semantics of Business Vocabulary and Business Rules (SBVR) is an adopted standard of the Object Management Group (OMG) intended to be the basis for formal and detailed natural language declarative description of a complex entity, such as a business. SBVR is intended to formalize complex compliance rules, such as operational rules for an enterprise, security policy, standard compliance, or regulatory compliance rules. Such formal vocabularies and rules can be interpreted and used by computer systems. SBVR is an integral part of the OMG's model-driven architecture (MDA).

<span class="mw-page-title-main">Core architecture data model</span>

Core architecture data model (CADM) in enterprise architecture is a logical data model of information used to describe and build architectures.

<span class="mw-page-title-main">Akoma Ntoso</span>

Akoma Ntoso (Architecture for Knowledge-Oriented Management of African Normative Texts using Open Standards and Ontologies) is an international technical standard for representing executive, legislative and judiciary documents in a structured manner using a domain specific, legal XML vocabulary.

<span class="mw-page-title-main">Enterprise Architect (software)</span> Visual modeling and design tool

Sparx Systems Enterprise Architect is a visual modeling and design tool based on the OMG UML. The platform supports: the design and construction of software systems; modeling business processes; and modeling industry based domains. It is used by businesses and organizations to not only model the architecture of their systems, but to process the implementation of these models across the full application development life-cycle.

References

  1. 1 2 3 4 5 6 7 8 LML Steering Committee. "LML Specification" . Retrieved 2023-03-01.
  2. ↑ "About Lifecycle Modeling Language". LML Steering Committee. Retrieved 2014-06-05.
  3. 1 2 Steven Dam; Warren Vaneman (2014-04-06). "Lifecycle Modeling Language Tutorial". SEDC 2014.
  4. ↑ "Knowledge-Based Analysis and Design (KBAD): An Approach to Rapid Systems Engineering for the Lifecycle" . Retrieved 2010-10-17.
  5. ↑ "Innoslate Integrated Solutions" . Retrieved 2014-12-09.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.