Hubbry Logo
Unified Modeling LanguageUnified Modeling LanguageMain
Open search
Unified Modeling Language
Community hub
Unified Modeling Language
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Unified Modeling Language
Unified Modeling Language
Unified Modeling Language
View on Wikipedia
from Wikipedia

UML
FamilyModeling language
Websitewww.uml.org

The Unified Modeling Language (UML) is a general-purpose, object-oriented, visual modeling language that provides a way to visualize the architecture and design of a system, like a blueprint.[1][2] UML defines notation for many types of diagrams which focus on aspects such as behavior, interaction, and structure.

UML is both a formal metamodel and a collection of graphical templates. The metamodel defines the elements in an object-oriented model such as classes and properties. It is essentially the same thing as the metamodel in object-oriented programming (OOP), however for OOP, the metamodel is primarily used at run time to dynamically inspect and modify an application object model. The UML metamodel provides a mathematical, formal foundation for the graphic views used in the modeling language to describe an emerging system.

UML was created in an attempt by some of the major thought leaders in the object-oriented community to define a standard language at the OOPSLA '95 Conference. Originally, Grady Booch and James Rumbaugh merged their models into a unified model. This was followed by Booch's company Rational Software purchasing Ivar Jacobson's Objectory company and merging their model into the UML. At the time Rational and Objectory were two of the dominant players in the small world of independent vendors of object-oriented tools and methods.[3] The Object Management Group (OMG) then took ownership of UML.

The creation of UML was motivated by the desire to standardize the disparate nature of notational systems and approaches to software design at the time.[4] In 1997, UML was adopted as a standard by the Object Management Group (OMG) and has been managed by this organization ever since. In 2005, UML was also published by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) as the ISO/IEC 19501 standard.[5] Since then the standard has been periodically revised to cover the latest revision of UML.[6]

Most developers do not use UML per se, but instead produce more informal diagrams, often hand-drawn. These diagrams, however, often include elements from UML.[7]: 536 

Use

[edit]

UML is primarily used for software development (in any industry or domain)[8] but also used outside elsewhere including business processes, system functions, database schemas, workflow in the legal systems, medical electronics, Health care systems, and hardware design.[9]

UML is designed for use with many object-oriented software development methods; both today and for the methods when it was first developed including OMT, Booch method, Objectory, and especially for RUP which it was originally intended to be used with when work began at Rational Software.[10] Although originally intended for object-oriented design documentation, UML has been used effectively in other contexts such as modeling business process.[11][12]

As UML is not inherently linked to a particular programming language, it can be used for modeling a system independent of language. Some UML tools generate source code from a UML model.[13]

Elements

[edit]
Components in a travel reservation system

UML diagrams support visualizing system aspects like:[14]

In addition to syntactical (notational) elements with well-defined semantics, UML diagrams also allow for free-form comments (notes) that explain aspects such as usage, constraints, and intents.

Sharing

[edit]

UML models can be exchanged among UML tools via the XML Metadata Interchange (XMI) format.

Cardinality notation

[edit]

As with database Chen, Bachman, and ISO ER diagrams, class models are specified to use "look-across" cardinalities, even though several authors (Merise,[15] Elmasri & Navathe,[16] amongst others[17]) prefer same-side or "look-here" for roles and both minimum and maximum cardinalities. Recent researchers (Feinerer[18] and Dullea et al.[19]) have shown that the "look-across" technique used by UML and ER diagrams is less effective and less coherent when applied to n-ary relationships of order strictly greater than 2.

Feinerer says: "Problems arise if we operate under the look-across semantics as used for UML associations. Hartmann[20] investigates this situation and shows how and why different transformations fail.", and: "As we will see on the next few pages, the look-across interpretation introduces several difficulties which prevent the extension of simple mechanisms from binary to n-ary associations."

Artifacts

[edit]
Artifact manifesting components

An artifact is the "specification of a physical piece of information that is used or produced by a software development process, or by deployment and operation of a system"[21] including models, source code, scripts, executables, tables in database systems, development deliverables, a design documents, and email messages.[21]

An artifact is the physical entity that is deployed to a node[21]. Other UML elements such as classes and components are first manifest into artifacts and instances of these artifacts are then deployed. Artifacts can be composed of other artifacts.

Metamodeling

[edit]
Illustration of the Meta-Object Facility

The OMG developed a metamodeling architecture to define UML, called the Meta-Object Facility (MOF).[22] MOF is designed as a four-layered architecture, as shown in the image at right. It provides a meta-meta model at the top, called the M3 layer. This M3-model is the language used by Meta-Object Facility to build metamodels, called M2-models.

The most prominent example of a Layer 2 Meta-Object Facility model is the UML metamodel, which describes UML itself. These M2-models describe elements of the M1-layer, and thus M1-models. These would be, for example, models written in UML. The last layer is the M0-layer or data layer. It is used to describe runtime instances of the system.[23]

The metamodel can be extended using a mechanism called stereotyping. This has been criticized as being insufficient/untenable by Brian Henderson-Sellers and Cesar Gonzalez-Perez in "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0".[24]

Diagrams

[edit]
UML diagram types
Structural UML diagrams
Behavioral UML diagrams

UML 2 defines many types of diagrams – shown as a taxonomy in the image.[14][25]

Hierarchy of UML 2.2 Diagrams, shown as a class diagram
Hierarchy of UML 2.2 Diagrams, shown as a class diagram

Structure diagrams

[edit]

Structure diagrams emphasize the structure of the system – using objects, classifiers, relationships, attributes and operations. They are used to document software architecture.

Behavior diagrams

[edit]

Behavior diagrams emphasize the behavior of a system by showing collaborations among objects and changes to the internal states of objects. They are used to describe the functionality of a system.

Interaction diagrams

[edit]

Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data between components of a system.

Examples

[edit]
  • Component diagram
    Component diagram
  • Class diagram
    Class diagram
  • Activity diagram
    Activity diagram
  • Use case diagram
    Use case diagram
  • Use case diagram
    Use case diagram
  • Deployment diagram
    Deployment diagram

Adoption

[edit]

In 2013, UML had been marketed by OMG for many contexts, but aimed primarily at software development with limited success.[12][27]

It has been treated, at times, as a design silver bullet, which leads to problems. UML misuse includes overuse (designing every part of the system with it, which is unnecessary) and assuming that novices can design with it.[28]

It is considered a large language, with many constructs. Some people (including Jacobson) feel that UML's size hinders learning and therefore uptake.[29]

Visual Studio dropped support for UML in 2016 due to lack of use.[30]

According to Google Trends, use of the term UML has declined since 2004 although leveled off in the last 5 years.[31]

History

[edit]
Timeline and relationships of object-oriented methods and notation

UML has evolved since the second half of the 1990s and has its roots in the object-oriented programming methods developed in the late 1980s and early 1990s. The image shows a timeline of the history of UML and other object-oriented modeling methods and notation.

Origin

[edit]

Rational Software hired James Rumbaugh from General Electric in 1994 and after that, the company became the source for two of the most popular object-oriented modeling approaches of the day:[32] Rumbaugh's object-modeling technique (OMT) and Grady Booch's method. They were soon assisted in their efforts by Ivar Jacobson, the creator of the object-oriented software engineering (OOSE) method, who joined them at Rational in 1995.[4]

UML 1.x

[edit]

UML is originally based on the notations of the Booch method, the object-modeling technique (OMT), and object-oriented software engineering (OOSE), which were integrated into a single language.[14] UML was developed at Rational Software in 1994–1995, with further development led by them through 1996.[4]

Under the technical leadership of Rumbaugh, Jacobson, and Booch, a consortium called the UML Partners was organized in 1996 to complete the Unified Modeling Language (UML) specification and propose it to the Object Management Group (OMG) for standardization. The partnership also contained additional interested parties (for example HP, DEC, IBM, and Microsoft). The UML Partners' UML 1.0 draft was proposed to the OMG in January 1997 by the consortium. During the same month, the UML Partners formed a group, designed to define the exact meaning of language constructs, chaired by Cris Kobryn and administered by Ed Eykholt, to finalize the specification and integrate it with other standardization efforts. The result of this work, UML 1.1, was submitted to the OMG in August 1997 and adopted by the OMG in November 1997.[4][33]

After the first release, a task force was formed[4] to improve the language, which released several minor revisions, 1.3, 1.4, and 1.5.[34]

The standards it produced (as well as the original standard) have been noted as being ambiguous and inconsistent.[35]

UML 2

[edit]

UML 2.0 major revision replaced version 1.5 in 2005, which was developed with an enlarged consortium to improve the language further to reflect new experiences on the usage of its features.[36]

Although UML 2.1 was never released as a formal specification, versions 2.1.1 and 2.1.2 appeared in 2007, followed by UML 2.2 in February 2009. UML 2.3 was formally released in May 2010.[37] UML 2.4.1 was formally released in August 2011.[37] UML 2.5 was released in October 2012 as an "In progress" version and was officially released in June 2015.[37] The formal version 2.5.1 was adopted in December 2017.[1]

There are four parts to the UML 2.x specification:

  • The Superstructure that defines the notation and semantics for diagrams and their model elements
  • The Infrastructure that defines the core metamodel on which the Superstructure is based
  • The Object Constraint Language (OCL) for defining rules for model elements
  • The UML Diagram Interchange that defines how UML 2 diagram layouts are exchanged

Until UML 2.4.1, the latest versions of these standards were:[38]

  • UML Superstructure version 2.4.1
  • UML Infrastructure version 2.4.1
  • OCL version 2.3.1
  • UML Diagram Interchange version 1.0.

Since version 2.5, the UML Specification has been simplified (without Superstructure and Infrastructure), and the latest versions of these standards are now:[39]

  • UML Specification 2.5.1
  • OCL version 2.4

It continues to be updated and improved by the revision task force, who resolve any issues with the language.[40]

See also

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Unified Modeling Language

View on Grokipedia
from Grokipedia
The Unified Modeling Language (UML) is a standardized, graphical for specifying, visualizing, constructing, and documenting the artifacts of software-intensive systems. Maintained by the (OMG), UML provides a common visual notation that supports , enabling developers to model system structure, behavior, and interactions before implementation. This standardization promotes communication among stakeholders, facilitates code reuse through modular designs, and integrates with methodologies like (MDA) to generate platform-specific models from platform-independent ones. UML originated in the mid-1990s amid the proliferation of diverse object-oriented modeling techniques, aiming to unify best practices into a single standard. It was primarily developed by and submitted to the OMG in response to a request for proposals, with support from 18 companies including , , , and . The OMG adopted the initial UML 1.1 specification in December 1997 following a consensus-based process, marking it as the first major for object-oriented modeling. Since then, UML has evolved through revisions managed by OMG's Revision Task Force, with major updates addressing enhancements in , , and diagram expressiveness. The current version, UML 2.5.1, released in December 2017, includes an abstract syntax metamodel, primitive types, and a standard profile for extensible modeling. It features 14 types of diagrams categorized into structure diagrams (e.g., class, component, deployment), behavior diagrams (e.g., activity, , state machine), and interaction diagrams (e.g., , communication, timing), allowing comprehensive representation of and static elements. UML's methodology-independent nature, supported by the (XMI) standard, ensures across tools and platforms, making it essential for large-scale software projects to mitigate risks of failure due to poor design.

Overview

Definition

The Unified Modeling Language (UML) is a general-purpose, developmental, for specifying, visualizing, constructing, and documenting the artifacts of software systems. It provides a standardized graphical notation that enables developers and architects to represent system structures, behaviors, and interactions in a consistent manner, facilitating communication among stakeholders throughout the lifecycle. UML has been standardized by the Object Management Group (OMG), an international, non-profit consortium, since its initial adoption as version 1.1 in November 1997. As a non-proprietary specification, UML is openly available for use and extension by the software industry, ensuring broad accessibility without licensing restrictions tied to specific vendors. This standardization promotes interoperability among modeling tools and methodologies, allowing organizations to adopt UML without proprietary lock-in. At its core, UML functions as a visual that integrates multiple complementary views of a system, such as structural, behavioral, and functional perspectives, to support processes. These views are expressed through diagrams that abstract complex software architectures into comprehensible representations, aiding in the identification of requirements, design flaws, and implementation strategies. Unlike programming languages, which are imperative and produce executable code, UML is declarative and diagrammatic, focusing on high-level modeling rather than low-level implementation details.

Purpose and Benefits

The Unified Modeling Language (UML) primarily aims to specify, visualize, construct, and document the artifacts of software systems, enabling software engineers to model system structure and behavior in a standardized manner. This facilitates effective communication among stakeholders, including developers, analysts, and non-technical users, by providing a common visual language that bridges gaps in technical understanding and requirements articulation. By abstracting complex designs into diagrams, UML reduces the inherent complexity of large-scale systems, allowing teams to focus on high-level architecture rather than implementation details from the outset. Key benefits of UML include enhanced system understanding through its graphical notations, which clarify relationships and components, and early error detection during design validation against requirements, thereby lowering the risk of failures in production. Its methodology-independent nature aligns well with both iterative approaches, such as agile development, where models evolve incrementally, and traditional processes that emphasize upfront planning. Unlike informal sketches, which often lead to ambiguity and misinterpretation, UML's standardized, precise notation minimizes such issues, promoting unambiguous designs that support code generation and maintenance. UML's extensibility further amplifies its benefits, as users can adapt the language through profiles to suit domain-specific needs, such as real-time embedded systems via the MARTE profile or extensions. This customization enables precise modeling for specialized applications without altering the core language, fostering reusability and interoperability across tools and platforms. Overall, these features contribute to scalable, robust by encapsulating in a technology-neutral form.

History

Origins

In the early 1990s, the object-oriented field experienced significant fragmentation, with numerous competing modeling methods emerging to support the growing adoption of object-oriented paradigms. Key among these were Grady Booch's for object-oriented design, introduced in the late 1980s and focused on implementation-level modeling; James Rumbaugh's (OMT), developed in 1991 at and emphasizing analysis for data-intensive systems through object, dynamic, and functional models; and Ivar Jacobson's Object-Oriented (OOSE), published in 1992, which introduced use cases to capture system behavior and requirements. This proliferation of notations created challenges for practitioners, as no single approach dominated, leading to inconsistencies in communication and tool support across projects. To consolidate these best practices, —where Booch was already employed—began unification efforts in 1994 when Rumbaugh joined the company from , merging OMT and the Booch method into an initial "Unified Method." In 1995, Jacobson also joined Rational, integrating OOSE's concepts, and the trio—Booch, Rumbaugh, and Jacobson—became known as the "" for their collaborative leadership in standardizing object-oriented modeling. The drive for unification stemmed from industry demands for a common to reduce confusion and enhance in , particularly as object-oriented methods gained traction for complex systems development. These efforts were influenced by prior (OMG) standards, such as the (CORBA), which had established a framework for distributed object computing since 1991 and underscored the need for standardized modeling to support platform-independent architectures.

Development of UML 1.x

The development of UML 1.x marked the formal standardization of a unified notation for object-oriented modeling, building briefly on the integration of methods from , James Rumbaugh, and at . In January 1997, and its partners submitted UML version 1.0 to the (OMG) in response to a request for proposals aimed at standardizing practices. This initial submission was refined through collaborative review, leading to version 1.1, which was submitted in September 1997 and adopted by the OMG in late 1997 as UML 1.1. UML 1.1 established the core structure of the language, introducing nine diagram types to support both static and dynamic modeling aspects, including diagrams for capturing , class diagrams for defining structural relationships, and sequence diagrams for illustrating object interactions over time. Led by , the development involved contributions from a of about 20 companies, such as , , , , and , which helped harmonize diverse modeling semantics from earlier fragmented approaches. Subsequent minor revisions refined UML 1.x without major overhauls. UML 1.3, adopted in February 2000, enhanced modeling with relationships like «include» and «extend», tightened semantics to better support concurrency via constructs, and improved overall precision in the metamodel. UML 1.5, adopted in March 2003, introduced formal action semantics to provide executable foundations for behavioral models, enabling better integration with implementation tools while maintaining with prior 1.x versions. These updates were managed through OMG's Revision , ensuring iterative improvements based on industry feedback.

Evolution to UML 2.x

The Unified Modeling Language (UML) 2.0 was formally adopted by the (OMG) in July 2005 as a major revision to address key limitations in the UML 1.x series. These shortcomings included imprecise semantics, particularly for actions, which hindered executable models; excessive complexity that overwhelmed users; inadequate support for component-based development; and challenges in diagram scalability and interchangeability across tools. The revision aimed to enhance usability while expanding applicability to modern software paradigms like concurrent and distributed systems. Key enhancements in UML 2.0 included an expansion from nine diagram types in UML 1.x to thirteen, incorporating new ones such as communication, composite structure, interaction overview, and timing diagrams to better represent interactions and structures. It provided stronger support for component-based architectures by elevating components to a first-class modeling element throughout the lifecycle and improved concurrency modeling through refined behavioral semantics for threads and processes. Additionally, formal metamodel refinements separated the language into (core abstractions) and (user-facing elements), enabling more precise definitions and easier customization via profiles. Subsequent iterative releases refined these foundations. UML 2.1, released in 2007, focused on diagram improvements, such as enhanced notations for and activity diagrams to clarify interactions and flows. UML 2.4, adopted in 2011 following interim updates, introduced better partitioning mechanisms in activity diagrams for organizing complex behaviors into swimlanes and regions, aiding scalability in large models. UML 2.5, finalized in June 2015, emphasized simplification by rewriting the specification to reduce redundancy and flatten hierarchies while preserving semantics, responding to an OMG request for consolidation. UML 2.x also introduced lightweight diagram extensions, such as optional and fragments, to allow concise notations without full formality, alongside more precise execution semantics based on token-flow models for activities, bridging the gap between modeling and code generation.

Recent Developments

The UML 2.5.1 specification, released by the (OMG) in December 2017, served as a maintenance update to UML 2.5, incorporating minor clarifications and bug fixes without introducing substantive changes to the language's structure or semantics. This revision addressed issues identified in prior versions, such as inconsistencies in metamodel definitions, to enhance clarity for tool implementers and users. As of 2025, no major new version of UML beyond 2.5.1 has been adopted, reflecting a period of stability focused on refinement rather than overhaul. Ongoing OMG efforts have emphasized profiles and subsets to extend UML's applicability in specialized domains. The Foundational UML Subset (fUML), an subset of UML, continues to evolve, with version 1.5 providing precise for structural and behavioral models, enabling direct execution of UML activities without additional code generation. Recent advancements include compiler-like optimizations for fUML to reduce execution overhead in , as demonstrated in implementations supporting precise behavioral specifications. Similarly, the (SysML), a UML profile for , saw significant updates with SysML v1.7 adopted in June 2024 for minor enhancements and SysML v2.0 finalized in July 2025, introducing improved textual notation, support, and for complex system architectures. These developments build on UML's foundational elements to address modern engineering challenges like model execution and systems integration. UML has seen increased alignment with complementary standards for business and . Integration with (BPMN) facilitates hybrid approaches, where UML structural diagrams complement BPMN's process flows, as outlined in frameworks mapping BPMN elements to UML for end-to-end modeling. Emerging AI-driven tools further support UML adoption by automating generation from or code, with platforms like Visual Paradigm AI producing editable class and diagrams from descriptions to streamline design workflows. Community-driven initiatives underscore UML's adaptability in contemporary software practices. Open-source contributions, such as the fUML Reference Implementation on , provide accessible virtual machines for executing UML models, fostering experimentation and tool development. Discussions within the modeling community highlight UML's relevance in and microservices architectures, where component and deployment diagrams visualize service dependencies and orchestration, aiding agile teams in managing distributed systems.

Core Concepts

Basic Elements

The Unified Modeling Language (UML) employs a set of fundamental graphical symbols and notations to represent key modeling concepts, forming the building blocks for all UML diagrams. These elements include classifiers such as classes and , instances like objects, and connectors like associations, which together enable the visualization of system structures and behaviors. Core symbols in UML include classes, depicted as rectangles divided into compartments for the class name (in bold), attributes, and operations; objects, shown as rectangles with underlined names specifying the object instance and its class (e.g., myObject: ClassName); , represented as stick figures or rectangles stereotyped as «actor» to denote external entities interacting with the system; and , illustrated as ovals containing the use case name. Attributes are listed in the second compartment of a class with syntax like name: Type [multiplicity], while operations appear in the third compartment as visibility operationName(parameter: Type): ReturnType. Associations are solid lines connecting elements, often annotated with role names, multiplicities (e.g., 0..* for zero or more), and direction arrows to indicate . UML defines several relationship types to express connections between elements. Generalization, representing inheritance, is a solid line ending in a hollow triangle pointing to the superclass. Realization indicates implementation, using a dashed line with a hollow triangle from the realizing element to the interface or specification. Dependency shows reliance, notated as a dashed line with an open arrow from the dependent (client) to the depended-upon (supplier) element. Aggregation and composition, both forms of whole-part relationships, use solid lines with a hollow diamond (aggregation, shared ownership) or filled diamond (composition, exclusive ownership) at the whole end. Visibility levels control access to attributes and operations, prefixed by standard symbols: + for (accessible to all), - for private (accessible only within the class), # for protected (accessible within the class and subclasses), and ~ for package (accessible within the same package). These notations ensure precise modeling of encapsulation in object-oriented designs. Stereotypes and constraints provide mechanisms for extending and customizing UML elements without altering the core language. are denoted by guillemets enclosing a name (e.g., <<interface>> applied to a class to specify it defines a of operations without ), allowing domain-specific interpretations. Constraints, expressed in braces as {booleanExpression} or , restrict element properties (e.g., {self.size > 0} on an attribute to enforce non-emptiness). These features enhance UML's expressiveness for specialized modeling needs.

Notation and Semantics

The Unified Modeling Language (UML) employs a dual notation system comprising graphical and textual representations to specify models precisely and unambiguously. Graphical notation utilizes diagrams with standardized visual elements, such as rectangles for classes and solid lines for associations, to depict structural and behavioral aspects of systems. This visual syntax facilitates intuitive communication among stakeholders while adhering to formal rules for rendering, including adornments like multiplicity indicators and enclosed in guillemets (e.g., «abstract»). Textual notation, primarily through the (OCL), complements graphics by expressing precise constraints, preconditions, and postconditions that cannot be fully captured visually, such as invariants on model elements. OCL is integrated into UML as a side-effect-free, declarative for formal specifications, allowing constraints to be attached to diagram elements or defined separately. UML semantics are stratified into three interconnected layers to ensure consistent interpretation and execution of models. The abstract syntax layer, defined by the UML metamodel, establishes the foundational vocabulary and structure of model elements, such as classifiers, properties, and relationships, using a Meta-Object Facility (MOF)-based framework to represent the language's core concepts without regard to visualization. The concrete syntax layer specifies the visual rules for rendering these abstract elements, including layout conventions, line styles, and compartment structures in diagrams, enabling human-readable notations while maintaining fidelity to the abstract model. The behavioral semantics layer addresses dynamic aspects, defining how model elements evolve over time, such as token flows in activities, state transitions, and sequences in interactions, with operational rules for execution and validation. These layers collectively support by bridging informal diagrams to formal, specifications. Cardinality notation in UML specifies the allowable number of instances participating in associations, generalizations, and other relationships, using a multiplicity range expressed as [lower..upper] at association ends or connector roles. Common notations include 0..1 for optional participation (zero or one instance), 1..* for mandatory one-or-more instances, and * (equivalent to 0..) for unbounded multiplicity. For instance, an association between classes might denote one end as 1 (exactly one) and the other as 0.., indicating a one-to-many relationship. These multiplicities enforce constraints during model validation and code generation, ensuring structural integrity. OCL provides a formal mechanism to articulate constraints beyond graphical notation, using a context declaration followed by invariant, pre-, or postconditions. A basic example is context Class inv: self.attribute > 0, which specifies that an attribute's value must always be positive for instances of the Class. More complex constraints might include context Reception inv: name = signal.name, ensuring a reception's name matches its associated signal, or context Signal inv: ownedAttribute->size() = ownedParameter->size(), verifying that a signal's attributes align in count with its parameters. These expressions leverage OCL's type-safe navigation and collection operations to define precise, machine-checkable rules integrated with UML diagrams.

Metamodel and Profiles

The Unified Modeling Language (UML) employs a four-layer metamodel to provide a rigorous foundation for modeling, ensuring that models are instances of well-defined metamodels. This , standardized by the (OMG), consists of the M0 layer representing concrete data or runtime instances, such as actual software objects; the M1 layer for models that describe those instances, like UML diagrams of a ; the M2 layer for metamodels that define the and semantics of M1 models, including the UML metamodel itself; and the M3 layer for the meta-metamodel, which specifies the language for defining M2 metamodels. At the core of this architecture is the Meta-Object Facility (MOF), an OMG standard that serves as the M3 meta-metamodel and defines UML's abstract syntax. MOF enables the precise specification of modeling languages by providing a platform-independent framework where UML's metamodel at M2 reuses MOF's structural elements, such as classes and associations, while incorporating UML-specific extensions for . This self-describing structure allows UML to be both a and a metamodeling tool, supporting interoperability in . To extend UML for specific domains without modifying its core metamodel, UML incorporates profiles as lightweight customization mechanisms. Profiles define extensions through , which tag existing UML elements with domain-specific semantics (e.g., applying a stereotype to a class to denote a "real-time thread"); tagged values, which attach arbitrary name-value pairs to elements for additional properties; and constraints, often expressed in (OCL), to enforce rules on model validity. Examples of standardized profiles illustrate their practical application. The UML Profile for and Enterprise JavaBeans (EJB) tailors UML for Java-based development by introducing like <> and tagged values for Java-specific attributes, enabling precise mapping between UML models and Java code. Similarly, the UML Profile for Schedulability, Performance, and Time (SPTP), also known as the real-time profile, extends UML with such as <RT::ActiveObject> and constraints for timing analysis, supporting the modeling of embedded and real-time systems. The primary benefit of profiles lies in their ability to create domain-specific languages (DSLs) atop UML's stable core, promoting reusability and specialization while maintaining compatibility with standard UML tools and interchange formats like XMI. This approach avoids the need for proprietary extensions, fostering broader adoption in diverse fields such as software engineering and systems design.

Diagrams

Structural Diagrams

Structural diagrams in the Unified Modeling Language (UML) provide a means to visualize the static architecture of a system, emphasizing its organization, components, and relationships without addressing dynamic behaviors. These diagrams capture the foundational elements such as classes, objects, and their interconnections, enabling modelers to represent the system's structure at various levels of abstraction, from high-level packages to detailed deployments. As defined in the UML 2.5.1 specification, structural diagrams are essential for specifying, constructing, and documenting software systems, particularly in object-oriented and component-based development. Class diagrams form the of structural modeling by depicting the static structure of classes, interfaces, and their relationships within a or subsystem. They illustrate key elements such as attributes, operations, and constraints, along with connections like associations (which represent links between classes with specified multiplicity), (indicating or "is-a" relationships), and dependencies (showing reliance between elements). For instance, a points from a subclass to a superclass, promoting and in the model. These diagrams support at different levels, focusing on meaningful concepts rather than runtime instances, and are widely used to define the blueprint for object-oriented designs. Object diagrams complement class diagrams by providing instance-level snapshots of the system's state at a specific moment, showing concrete objects, their attribute values (via slots), and as instances of associations. Unlike class diagrams, which describe types, object diagrams instantiate these types to illustrate runtime configurations, such as how specific objects interact through . Although not formally redefined in UML 2.5, they retain their role from earlier versions as a diagnostic tool for validating class models against real-world scenarios. Component diagrams focus on the modular organization of software systems, portraying components as reusable units along with their provided and required interfaces, ports, and dependencies. Components can be logical (e.g., business logic modules) or physical (e.g., deployable binaries like JAR files), connected via connectors to indicate interactions in component-based or service-oriented architectures. Dependencies highlight how one component relies on another, often through required interfaces, while ports serve as gateways for external communication. This diagram type supports system decomposition and integration, emphasizing black-box views where internal details are hidden. Composite structure diagrams reveal the internal composition of a class or component, detailing its parts, ports, and connectors to show how interconnected elements to realize . They include internal structure views, which decompose a structured classifier into properties and relationships, and collaboration use views, which bind roles from a to specific parts. Parts represent sub-elements (e.g., instances of other classes), while connectors define wiring between them, enabling the modeling of complex assemblies like those in embedded systems. This approach allows for white-box analysis, contrasting with the black-box perspective of component diagrams. Deployment diagrams address the physical deployment of software artifacts onto hardware or execution environments, illustrating nodes (e.g., devices or virtual machines), artifacts (e.g., executables or scripts), and communication paths between them. Artifacts manifest components indirectly, deployed to nodes via deployment specifications, which can be at specification level (generic types) or instance level (specific instances like a server named "wsrv-01"). These diagrams are crucial for mapping logical designs to runtime topologies, including network architectures, and support scalability assessments in distributed systems. Package diagrams organize the model's elements into namespaces, showing packages as containers for related artifacts and their inter-package relationships such as imports, merges, and dependencies. A package import grants to elements from another package without merging contents, while a package merge incorporates one package's definitions into another, potentially redefining elements for extension. This diagram type facilitates modularization and large-scale model management, akin to directory structures in file systems, and is often used to delineate architectural layers or subsystems. Profile diagrams extend UML by defining custom stereotypes, tagged values, constraints, and other extensions to adapt the language for specific domains, platforms, or methodologies. They depict profiles as packages that apply to metaclasses (e.g., <> on Class), along with associations showing extensions (e.g., a stereotype extending a with an arrow). Metamodel references link the profile to the base UML metamodel, enabling lightweight customizations without altering the core language. This diagram type is vital for creating domain-specific languages (DSLs) or standardizing notations, such as in real-time systems or enterprise modeling.

Behavioral Diagrams

Behavioral diagrams in the Unified Modeling Language (UML) capture the dynamic behavior of a , illustrating how it responds to stimuli, processes , and evolves over time. These diagrams emphasize processes, interactions, and state changes rather than static , providing a foundation for understanding functionality from both high-level and detailed perspectives. In UML 2.5, behavioral diagrams consist of three primary types: diagrams, activity diagrams, and state machine diagrams, each serving distinct purposes in modeling . Use case diagrams model the functional requirements of a system by representing interactions between external entities, known as , and the system's s. Actors, depicted as stick figures, symbolize users or other s that initiate or participate in system operations, while use cases are shown as ovals encapsulating specific functionalities that deliver observable value. Relationships such as include, which indicates that one use case mandatorily incorporates the behavior of another to reuse common functionality, and extend, which allows optional behavior to be added under certain conditions, help refine and organize these interactions. Associations connect to use cases, often generalized or specialized to show inheritance among actors or use cases. This diagram type is particularly useful in the early stages of to outline what the system should do without detailing how it does it. Activity diagrams provide a detailed view of the and processes within a , modeling the flow of control and through sequences of actions. They are akin to flowcharts but support complex structures, including actions (rounded rectangles representing executable computations), decisions ( nodes for conditional branching based on guards), forks and joins (horizontal bars to denote concurrent flows and their ), and swimlanes (partitions dividing the to assign responsibilities across multiple entities or roles). Activity edges, shown as arrows, direct the flow, which can include object flows for movement. These diagrams are versatile for depicting both sequential and parallel behaviors in business processes, algorithms, or operations, enabling analysts to identify bottlenecks or parallelization opportunities. State machine diagrams describe the lifecycle of an object or system through a series of states, transitions, and events, focusing on how it behaves in response to stimuli. States, represented as rounded rectangles, indicate periods of stability where the entity performs internal activities or waits for events; pseudostates like initial (a filled circle) or final (a circled X) mark entry and exit points. Transitions, depicted as arrows, are triggered by events and may include guards (conditions in square brackets) or effects (actions executed upon firing). UML distinguishes between behavioral state machines, which model reactive object behavior, and protocol state machines, which specify valid usage sequences without internal details. This diagram type is essential for embedded systems, user interfaces, or any domain where state-dependent behavior is critical.

Interaction Diagrams

Interaction diagrams in UML model the dynamic aspects of a system by illustrating how entities collaborate through the exchange of messages over time. These diagrams emphasize the flow of control and data among lifelines or objects, capturing sequences of interactions that realize behaviors specified elsewhere in the model. According to the OMG UML 2.5.1 specification, interaction diagrams are a subset of behavioral diagrams that focus on observable message passing between connectable elements, such as objects, actors, or parts of a system. The sequence diagram is a primary interaction diagram that depicts the temporal ordering of messages exchanged between lifelines, which represent the participants in the interaction. Lifelines are shown as vertical dashed lines extending downward, symbolizing the existence and duration of the entity over time. Messages are arrows connecting lifelines, distinguished as synchronous (solid arrows with filled heads, implying a blocking call-response) or asynchronous (open arrows, for non-blocking signals). Activation boxes, depicted as thin rectangles on lifelines, indicate periods of execution or focus of control triggered by incoming messages. Interaction fragments, such as alt (for alternatives based on conditions) and opt (for optional sequences), are enclosed in rectangular frames with compartments to model conditional or iterative behaviors within the overall flow. The semantics ensure that the diagram defines valid traces of event occurrences, with time progressing implicitly from top to bottom. Communication diagrams, formerly known as diagrams, highlight the structural organization of objects and the routing of messages along numbered links, providing a compact view of interactions with emphasis on relationships rather than strict timing. Objects are represented as rectangles containing their names, connected by solid lines denoting associations or links along which messages flow. Messages are labeled with sequence numbers (e.g., 1, 1.1, 2) to indicate the order of exchange, allowing nested numbering for recursive or iterative calls. Unlike sequence diagrams, the layout focuses on spatial arrangement to reveal architectural dependencies, while the semantics trace message sequences through the links, supporting both synchronous and asynchronous types. This notation aids in understanding how objects collaborate within a system's structure to fulfill responsibilities. Interaction overview diagrams offer a high-level by integrating elements from and sequence diagrams, portraying the of complex interactions as a sequence of referenced sub-interactions. Nodes resemble activity diagram elements, such as initial and final nodes, decision and merge nodes, and action nodes, but the actions reference other interaction diagrams (e.g., via interaction uses) rather than simple operations. A lifeline clause may optionally list participants, and edges show with guards for conditions. The semantics combine the sequencing of activities with the behavioral details of embedded interactions, enabling a modular overview of large-scale flows without delving into low-level details. This hybrid approach facilitates the of overall system interactions into manageable parts. Timing diagrams address the temporal constraints in interactions, particularly the collaborative timing among multiple lifelines, by visualizing how states or conditions evolve over explicit time axes. Lifelines are placed horizontally or vertically with a time progression axis, where state changes, durations, or timing marks (e.g., {time} constraints) are annotated to show points. Messages appear as lines crossing lifelines, with duration observations indicating intervals of interest. The focus on collaborative timing semantics allows modeling of real-time constraints, such as deadlines or in message exchanges, ensuring that interactions meet temporal requirements across participants. This is especially useful for systems where timing is critical to the correctness of collaborations.

Examples of Diagrams

To illustrate the application of UML diagrams, consider examples drawn from common software systems. These diagrams demonstrate how UML notation captures key aspects of structure and behavior in a concise, visual manner. A sample for a banking system depicts the static relationships among core entities. It includes the class with attributes such as name, , and ID, and the Account class with attributes like account number, balance, and type (e.g., checking or savings). An association connects Customer to Account with a multiplicity of 1 to * (one customer to many accounts), representing , while operations like deposit() and withdraw() are shown in the Account class compartment. This diagram highlights if subclasses like SavingsAccount extend Account. In a sequence diagram example for a user login process, the User interacts with system objects such as Authentication Service and User Database. The flow begins with the User sending a synchronous "enter credentials" to the Authentication Service, which queries the User Database with "validate user." If successful, the Authentication Service returns "login approved" to the User, establishing a session; otherwise, an alt fragment shows an "invalid credentials." Lifelines represent object lifetimes, with activation bars indicating processing duration. A use case diagram for an e-commerce system identifies primary actors and functionalities. Actors include Buyer (representing customers) and Admin (for system management). Use cases such as Purchase Item (encompassing browsing, adding to cart, and checkout) and Manage Inventory (updating stock levels and supplier orders) are depicted as ovals, connected to actors via associations. The Buyer links to Purchase Item, while Admin connects to Manage Inventory; an include relationship may link Purchase Item to a secondary use case like Process Payment. This diagram outlines system boundaries and user goals. An activity diagram for order processing models the workflow as a series of coordinated actions. It starts with an initial node leading to "Receive Order," followed by a fork into parallel flows: one for "Validate Payment" and another for "Check Inventory." These join at a synchronization bar, then proceed to a decision node querying "All Valid?"—if yes, actions include "Process Shipment" and "Update Status"; if no, it branches to "Notify Customer" and ends. Final nodes mark completion, with swimlanes optionally partitioning actions by roles like Warehouse or Finance. These diagrams complement each other in a full UML model by providing complementary views: the establishes the structural foundation (e.g., entities like and Account), while behavioral diagrams like , , and activity elaborate dynamics, such as login flows, user interactions, and processes, ensuring a cohesive representation of the system from requirements to implementation.

Applications and Adoption

Use in Software Development

Unified Modeling Language (UML) plays a central role in the software development lifecycle (SDLC) by providing standardized notations for capturing, analyzing, and communicating system requirements, designs, and documentation. In the requirements gathering phase, UML use case diagrams model interactions between users (actors) and the system, helping stakeholders articulate functional needs and scope without delving into implementation details. During the design phase, structural diagrams like class diagrams define the static architecture, while behavioral diagrams such as sequence and state machine diagrams outline dynamic interactions and state transitions, enabling architects to refine system blueprints iteratively. In documentation, UML artifacts serve as living references throughout maintenance, ensuring traceability from requirements to code and facilitating onboarding for new team members. UML integrates effectively with agile methodologies by adapting its notations to lightweight, iterative practices that emphasize and user-centric development. In agile environments, subsets of UML—such as simplified sketches or activity diagrams—are used to visualize user stories and criteria, supporting sprint planning without the overhead of comprehensive models. Tools and techniques like incremental UML embedding in allow diagrams to evolve alongside code changes, aligning with agile's preference for "working software over comprehensive " while maintaining visual clarity for cross-functional teams. This approach, often termed "," promotes just-in-time diagramming for prototypes and refactoring, reducing maintenance costs in fast-paced cycles. Across industries, UML supports diverse applications, from to embedded systems and business modeling. In enterprise applications, UML class and component diagrams model scalable architectures for distributed systems, aiding integration of legacy and new components in large-scale environments. For embedded systems, deployment and state machine diagrams capture hardware-software interactions and real-time constraints, as demonstrated in industrial case studies where UML facilitated modeling of control logic in resource-limited devices. In business modeling, UML profiles extend core notations to represent workflows and organizational structures, using activity diagrams to simulate processes and ensure alignment between business goals and technical implementations. To enable collaboration in distributed teams, UML models are shared via standardized export formats like XML Metadata Interchange (XMI), an OMG specification that serializes diagrams and metadata into XML for tool-agnostic interchange. XMI ensures fidelity in transferring elements such as classes, relationships, and constraints between modeling tools, supporting version control and integration in multi-vendor environments without proprietary lock-in. This facilitates seamless handoffs during SDLC phases, particularly in agile settings where models must propagate across sprints and stakeholders.

Tools and Implementation

Several commercial and open-source tools facilitate UML modeling, supporting diagram creation, validation, and integration with development environments. Sparx Systems' Enterprise Architect is a prominent commercial tool that provides extensive UML 2.5 support, including , , and features for large-scale projects. Visual Paradigm offers versatile UML diagramming with strong emphasis on code engineering, , and agile integration, making it suitable for both individual and team use. As an open-source alternative, delivers customizable UML modeling capabilities within the Eclipse ecosystem, particularly valued for its extensibility in embedded systems and applications. IBM's Rational , a legacy tool from the late , played a pivotal role in early UML adoption by enabling graphical modeling and code generation, though it has been succeeded by modern IBM Rational tools. The Object Management Group (OMG) establishes standards for UML tool conformance to ensure consistency across implementations. Historically, UML specifications defined compliance levels—L1 for basic metamodel support, L2 for full abstract syntax, and L3 for complete superstructure including profiles—allowing tools to declare partial adherence. Although later versions like UML 2.5 eliminated these levels in favor of holistic conformance, tools undergo validation through the OMG's Model Interchange Working Group (MIWG), which tests interoperability via standardized suites of UML, SysML, and related models. A key enabler of this conformance is the XML Metadata Interchange (XMI) standard, an OMG specification that serializes UML models in XML format for seamless exchange between disparate tools, supporting versions up to XMI 2.5.1 for UML 2.x. Implementation of UML often involves advanced features like code generation, reverse engineering, and alignment with Model-Driven Architecture (MDA). Many tools, such as Enterprise Architect and Visual Paradigm, automate forward engineering by transforming UML class diagrams into executable code in languages like Java, including attributes, methods, and associations while preserving model semantics. Reverse engineering complements this by parsing existing source code—e.g., Java files—to automatically generate UML diagrams, aiding legacy system documentation and refactoring efforts. Within the MDA framework, UML serves as the foundation for platform-independent models (PIMs) that are transformed into platform-specific models (PSMs) and ultimately code, promoting automation in software development lifecycles. Despite these capabilities, UML tool implementation faces notable challenges, particularly in and . Variations in tool support for UML subsets, extensions, and XMI dialects can lead to loss of model fidelity during interchange, as evidenced by MIWG test cases where only partial conformance is achieved across vendors. Additionally, the for mastering complex UML models is steep, requiring users to navigate intricate notations and tool-specific interfaces, which can hinder adoption in fast-paced development environments.

Criticisms and Limitations

One major criticism of UML is its inherent , stemming from over 100 notational elements across its diagrams, which contributes to a steep and challenges in . Studies applying structural complexity metrics, such as those by Rossi and Brinkkemper, have shown UML to be 2 to 11 times more complex than other object-oriented modeling techniques, leading to cognitive overload for users, particularly novices. This complexity arises from the language's extensibility features, including and profiles, which, while flexible, often result in ambiguous or overly detailed models that hinder comprehension and increase the effort required for diagram updates. UML also faces limitations in modeling non-object-oriented domains, such as or data-flow systems, where its primary focus on classes, objects, and does not naturally align with paradigms emphasizing immutability, pure functions, or process-oriented flows. For instance, UML lacks built-in notations for representing functional models or algorithmic analysis, requiring significant adaptations like custom profiles, which can lead to overly complex diagrams that deviate from standard semantics. In data-flow modeling, UML's activity diagrams can approximate processes but struggle with concurrent or stream-based computations without extensions, making it less effective for domains like reactive systems or where and data transformations dominate. As software architectures evolve toward distributed, scalable paradigms, UML's original design for large-scale object-oriented systems reveals outdated aspects, particularly in handling , cloud-native environments, and AI-driven systems. Its emphasis on monolithic structures and static relationships inadequately captures dynamic service , , or event-driven interactions in microservices without heavy customization, leading to incomplete representations of deployment and concerns. Similarly, for AI systems involving pipelines or integrations, UML's behavioral diagrams fall short in expressing probabilistic models or , prompting debates on its relevance in modern, non-traditional development contexts. In response to these shortcomings, alternatives such as domain-specific languages (DSLs) have gained prominence, offering tailored notations that address UML's generality and overhead. DSLs enable more precise modeling for specific domains, reducing and improving compared to UML's broad constructs, which often result in ill-balanced or misused elements. Efforts within UML, such as those in version 2.5, propose simplifications like streamlined profiles, but practitioners increasingly favor lightweight textual tools like for rapid, code-integrated diagramming over full UML adoption. Empirical studies highlight inconsistent UML usage in practice, with teams often employing only subsets of diagrams—typically class, use case, and sequence—due to time constraints and perceived irrelevance of others. A systematic mapping of 63 experiments and 3 case studies found that while these subsets aid by improving comprehensibility (e.g., 54% better functional correctness), full UML application leads to inconsistencies between models and code, exacerbated by uneven adoption across projects. Surveys of practitioners confirm this variability, noting that only experienced users leverage broader diagram types, resulting in documentation that is frequently outdated or incomplete during phases.

References

  1. https://www.omg.org/spec/UML/2.5.1/About-UML
  2. https://www.omg.org/uml/what-is-uml.htm
  3. https://www.omg.org/uml/uml-history-faq.htm
  4. https://www.omg.org/uml/why-uml-is-important.htm
  5. https://www.omg.org/spec/UML/2.5.1/PDF
  6. https://www.omg.org/spec/UML/About-UML/
  7. https://developer.ibm.com/articles/an-introduction-to-uml/
  8. https://www.omg.org/spec/UML/2.5.1/About-UML/
  9. https://www.omg.org/spec/UML/2.5.1/PDF/
  10. https://www.omg.org/spec/UML/2.1.2/Infrastructure/PDF/
  11. https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-uml/
  12. https://www.sciencedirect.com/topics/computer-science/unified-method
  13. http://www.uml.org/uml-history-faq.htm
  14. https://martinfowler.com/umlsupp/changes.pdf
  15. https://www.omg.org/spec/UML/1.1/About-UML
  16. http://www.omg.org/uml/uml-history-faq.htm
  17. https://www.omg.org/spec/UML/1.5/About-UML
  18. https://link.springer.com/article/10.1007/s10270-018-0675-4
  19. https://www.omg.org/spec/UML/2.0/
  20. https://kobryn.com/.res/docs/Kobryn-CACM-Jan02-UML2.pdf
  21. https://www.omg.org/cgi-bin/doc?ad/01-02-39.pdf
  22. https://www.omg.org/spec/UML/2.0/Superstructure/PDF
  23. https://www.omg.org/spec/UML/2.0/Infrastructure/PDF
  24. https://www.omg.org/spec/UML/2.1.2/
  25. https://www.omg.org/spec/UML/2.5/
  26. https://www.omg.org/spec/UML/2.5.1/
  27. https://stackoverflow.com/questions/52099585/differences-between-uml-2-5-1-and-uml-2-5
  28. https://www.researchgate.net/publication/281633784_OMG_Unified_Modeling_Language_Version_25
  29. https://www.omg.org/spec/UML
  30. https://ieeexplore.ieee.org/document/11184111/
  31. https://www.omg.org/sysml/
  32. https://www.omg.org/news/releases/pr2025/07-21-25.htm
  33. https://www.omg.org/spec/FUML/1.5/About-FUML
  34. https://www.conradbock.org/BPMNProfile-MITRE-2011-slides.pdf
  35. https://ai.visual-paradigm.com/
  36. https://github.com/ModelDriven/fUML-Reference-Implementation
  37. https://stackoverflow.com/questions/60071074/microservices-dependencies-in-uml-diagrams
  38. https://www.researchgate.net/publication/343712437_A_Systematic_Mapping_Study_on_Microservices_Architecture_in_DevOps
  39. https://www.omg.org/spec/OCL/2.4/PDF
  40. https://www.omg.org/spec/MOF/2.5.1/PDF
  41. https://www.uml-diagrams.org/profile-diagrams.html
  42. http://www.omg.org/cgi-bin/doc?formal/04-02-02.pdf
  43. https://www.omg.org/spec/SPTP
  44. https://www.uml-diagrams.org/class-diagrams-overview.html
  45. https://www.uml-diagrams.org/class-diagrams-overview.html#object-diagram
  46. https://www.uml-diagrams.org/component-diagrams.html
  47. https://www.uml-diagrams.org/composite-structure-diagrams.html
  48. https://www.uml-diagrams.org/deployment-diagrams-overview.html
  49. https://www.uml-diagrams.org/package-diagrams-overview.html
  50. https://www.uml-diagrams.org/use-case-diagrams.html
  51. https://www.uml-diagrams.org/activity-diagrams.html
  52. https://www.uml-diagrams.org/state-machine-diagrams.html
  53. https://www.uml-diagrams.org/timing-diagrams.html
  54. https://course-resources-uae.minervaproject.com/uploaded_files/production/00282894-6867/uml-class-diagrams-class-implementatin.pdf
  55. https://www3.cs.stonybrook.edu/~alee/cse416/lectures/lec7/Lec7_UML_Sequence_Diagrams_x4.pdf
  56. https://www.cs.toronto.edu/~matz/instruct/csc407/lectures/uml_for_e-commerce.pdf
  57. https://tildesites.bowdoin.edu/~allen/courses/cs260/readings/UMLactivitydiagrams.pdf
  58. https://www.omg.org/cgi-bin/doc?formal/03-03-10.pdf
  59. https://ink.library.smu.edu.sg/context/sis_research/article/10657/viewcontent/Unbekannt.pdf
  60. https://dl.acm.org/doi/10.1145/3183440.3194985
  61. https://ieeexplore.ieee.org/document/8449554
  62. https://ieeexplore.ieee.org/document/843700/
  63. https://www.omg.org/cgi-bin/doc?formal/01-09-75.pdf
  64. https://www.omg.org/spec/XMI
  65. https://www.omgwiki.org/model-interchange/
  66. https://www.omg.org/spec/XMI/2.5.1/PDF
  67. https://www.visual-paradigm.com/features/code-engineering-tools/
  68. https://www.uml-lab.com/tutorials/reverse-engineering
  69. https://www.omg.org/mda/mda_files/developing_in_omg.htm
  70. https://ink.library.smu.edu.sg/context/sis_research/article/10647/viewcontent/The_complexity_of_UML.pdf
  71. https://ceur-ws.org/Vol-365/paper9.pdf
  72. https://doi.org/10.1016/j.ins.2010.01.026
  73. https://link.springer.com/chapter/10.1007/978-1-4471-0843-6_49
  74. https://link.springer.com/content/pdf/10.1007/0-387-25745-4_3
  75. https://www.researchgate.net/publication/354572488_Addressing_Expressiveness_for_a_UML_Microservices-Based_Modeling_within_the_Life_Cycle_of_the_Ubiquitous_System_Development
  76. https://kobra.uni-kassel.de/bitstreams/bca14df7-e9a8-459f-8a7e-69cb011984b3/download
  77. https://doi.org/10.1016/j.infsof.2012.12.006
  78. https://www.se-rwth.de/sosym/UML-customization-versus-domain-specific-languages/
  79. https://link.springer.com/journal/10270
  80. https://web-backend.simula.no/sites/default/files/publications/Simula.SE.581.pdf
Add your contribution
Related Hubs
User Avatar
No comments yet.