Lifecycle Modeling Language

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.

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

• Innoslate is the model-based systems engineering tool with LML available on the market. Innoslate implements LML and enables translation to UML, SysML, DoDAF 2.0, and other languages.^[5]
• 3DExperience platform is the enterprise software platform that fully supports LML modeling concepts. Particular tool for schema modeling is "Business Modeler" and basic tool for instance modelling based on that schema is "Matrix Navigator". Software is evolution of MatrixOne and Dassault Systemes V6 platform. CAD, CAM, CAE, PDM and other PLM technologies tools are provided based on that platform.

See also

• Formal specification
• Functional specification
• Process specification
• Product design specification
• Requirements analysis
• Specification (technical standard)
• Specification tree

References

0.00 (0 votes) Original source: https://en.wikipedia.org/wiki/Lifecycle Modeling Language. Read more