OMG Unified Modeling Language UML overview Copyright 2002

  • Slides: 55
Download presentation
OMG Unified Modeling Language UML overview Copyright @ 2002, Anders W. Tell, Financial Toolsmiths

OMG Unified Modeling Language UML overview Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Fundamental UML • OMG – Object Management Group • Metamodeling – Formalisms – Metamodel

Fundamental UML • OMG – Object Management Group • Metamodeling – Formalisms – Metamodel hierachy • 4+1 Views – High level views • Notation in general, Model. Management • Model. Elements – Building blocks in models – Description, Metamodel, Notation • Diagram – View of a part of a model – One or more views Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

OMG – Common Warehouse Model (CWM) Copyright @ 2002, Anders W. Tell, Financial Toolsmiths

OMG – Common Warehouse Model (CWM) Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

OMG Model. Driven Architecture (MDA) Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB

OMG Model. Driven Architecture (MDA) Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

UML Architecture principles From UML 2. 0 Infrastructure Vesion 2 beta R 2 ”The

UML Architecture principles From UML 2. 0 Infrastructure Vesion 2 beta R 2 ”The UML metamodel has been architected with the following design principles in mind: • Strong cohesion and loose coupling. This fundamental software engineering principle is applied to group constructs into packages and organize features into metaclasses. • Layering. Laying is applied in two ways to the UML metamodel. The package structure is layered to separate metalanguage kernel from structural and behavioral constructs that use them. In addition, a 4 -layer metamodel architectural pattern is consistently applied to the metmodel in order to separate concerns (especially regarding instantiation) across metalayers of abstraction. • Partitioning is used to organize conceptual areas within the same layer. In the case of the Infrastructure. Library, fine-grained partitioning is used to provide the flexibility required by current and future metamodeling standards. In the case of the UML metamodel, the partitioning is coarser-grained in order to increase the cohesion within packages and loosing the coupling across packages. • Extensibility. The UML can be extended in two ways: 1. 2. • a new dialect of UML can be defined by using Profiles to customize the language for particular platforms (e. g. , J 2 EE/EJB, . NET/COM+) and domains (e. g. , finance, telecommunications, aerospace); a new language related to UML can be specified by reusing part of the Infrastructure. Library package and augmenting with appropriate metaclasses and metarelationships. The former case defines a new dialect of UML, while the latter case defines a new member of the UML family of languages. Reuse. A fine-grained, flexible metamodel library is provided that is reused to define the UML metamodel, as well as other architecturally related metamodels, such as the Meta Object Facility (MOF) and the Common Warehouse Model (CWM). ” Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

UML Formalisms From UML 2. 0 Infrastructure Vesion 2 beta R 2 • ”The

UML Formalisms From UML 2. 0 Infrastructure Vesion 2 beta R 2 • ”The following are the goals of the specifications techniques used to define UML: – Correctness. The specification techniques should improve the correctness of the metamodel by helping to validate it. For example, the well-formedness rules should help validate the abstract syntax and help identify errors. – Precision. The specification techniques should increase the precision of both the syntax and semantics. The precision should be sufficient so that there is no syntactic nor semantic ambiguity for either implementors or users. – Conciseness. The specification techniques should be parsimonious, so that the precise syntax and semantics are defined without superfluous detail. – Consistency. The specification techniques should complement the metamodeling approach by adding essential detail in a consistent manner. – Understandability. While increasing the precision and conciseness, the specification techniques should also improve the readability of the specification. For this reason a less than strict formalism is applied, since a strict formalism formal techniques” Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

OMG Metamodeling Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb.

OMG Metamodeling Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

OMG Metamodel hierachy In the Real world Descriptio ns From UML 2. 0 Infrastructure

OMG Metamodel hierachy In the Real world Descriptio ns From UML 2. 0 Infrastructure Vesion 2 beta R 2 Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

4+1 Views Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb.

4+1 Views Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Use case view • • • Extracted from usage perspective Scenarios Stakeholder requirements All

Use case view • • • Extracted from usage perspective Scenarios Stakeholder requirements All other views are derived from use cases Diagrams: – Use case Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Logical View • Vocabulary of problem domain • Model of behavior and information •

Logical View • Vocabulary of problem domain • Model of behavior and information • Model. Elements – – Models and packages Classes and Objects, Stereotypes Associations Use case and Actors • Diagrams – – – Class, Object State Activity Collaboration Sequence. Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Implementation View • • • Components and files of a system Composition Dependencies Configuration

Implementation View • • • Components and files of a system Composition Dependencies Configuration Diagrams – Component Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Deployment View • Placement of components on network nodes – Computers, peripherals – Topology,

Deployment View • Placement of components on network nodes – Computers, peripherals – Topology, Distribution, Delivery, Installation • Diagrams – Deployment Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

T- Architecture and deployment Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB ,

T- Architecture and deployment Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Process View • Runtime behavior of system – System Processes – Thread – Servants

Process View • Runtime behavior of system – System Processes – Thread – Servants – Java Virtual Machine • Diagrams – Class – Object Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Notation • • ”Notational representation of semantical concepts” For communication purposes One or more

Notation • • ”Notational representation of semantical concepts” For communication purposes One or more Diagram. Elements per UML Model. Element Chapter 3 in UML specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Notation: Rational Rose Diagram Filtered Diagram Model Elements Model Notation for Model. Element: Class

Notation: Rational Rose Diagram Filtered Diagram Model Elements Model Notation for Model. Element: Class Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Notation: Argo. UML (open source) Model perspectives Association information Model. Element information Critique Copyright

Notation: Argo. UML (open source) Model perspectives Association information Model. Element information Critique Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Model. Management • Top level management of modeling artefacts • Organisation of modelelements using.

Model. Management • Top level management of modeling artefacts • Organisation of modelelements using. . . – – Models Packages Subsystems Profiles • Important because it is. . . – – easier to navigate, better overview separate core elements from extensions easier to versionhandle easier to work in groups on separate parts of models Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Meta. Model : Model. Management From UML 1. 4 specification Copyright @ 2002, Anders

Meta. Model : Model. Management From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Model. Element: Package • Grouping of Model. Elements to capture – Dependencies – Categories

Model. Element: Package • Grouping of Model. Elements to capture – Dependencies – Categories – Architectural aspects – etc. • Are hierarchical by nature Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Notation: Package Model. Element: package From UML 1. 4 specification Copyright @ 2002, Anders

Notation: Package Model. Element: package From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Model. Element: Class • ”A class is the description for a set of objects

Model. Element: Class • ”A class is the description for a set of objects with similar structure behavior and relationships” • Also called entity, type, classifier, template, table • Sometimes even called Object – confusing! • Has structural features – Attributes • Has behavioral features – Operations • Stereotype – Branding of modelelements so that they behave simillary in some repects. Shared strutural and behaviour features. Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Model. Element: Object • • Defined by Class Also called instance, example, row Are

Model. Element: Object • • Defined by Class Also called instance, example, row Are instances with unique identity Data. Values are instances without identity – Text, Double, String, Date, . . . Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Notation: Class and Object Model. Element: Class Model. Element : Attribute Model. Element: Operation

Notation: Class and Object Model. Element: Class Model. Element : Attribute Model. Element: Operation From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Meta. Model: Class From UML 1. 4 specification Copyright @ 2002, Anders W. Tell,

Meta. Model: Class From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Meta. Model: Object From UML 1. 4 specification Copyright @ 2002, Anders W. Tell,

Meta. Model: Object From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Model. Element: Class, Object - Patterns • A pattern catalog contains pattern languages describes

Model. Element: Class, Object - Patterns • A pattern catalog contains pattern languages describes interrelated patterns that describe how classes and objects are related under specific circumstances • Information and Data classes/objects – Only information and no behavior – Storable – Stateful • Behavior and Function classes / objects – – – Only behavior and no information May be used to model processes, activities, tasks, . . . Strategy pattern – delegate responsibility to expert object Stateless May be configured at creation time Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Model. Element: Association • ”An association defines a semantic relationship between classifiers” • Consist

Model. Element: Association • ”An association defines a semantic relationship between classifiers” • Consist of three (3) parts – Association. End • Alos called relationship, binding Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Notation: Association Model. Element: Association. End Model. Element: Association Model. Element: Multiplicity Model. Element:

Notation: Association Model. Element: Association. End Model. Element: Association Model. Element: Multiplicity Model. Element: Aggregation. Kind Aggregate Model. Element: Association. End Role Name Model. Element: Visibility From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Meta. Model: Association Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open

Meta. Model: Association Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XMLFrom Laboratory UML 1. 4 specification

Notation: Association 2 Model. Element: Association. En d Model. Element: Association: : Association. Class

Notation: Association 2 Model. Element: Association. En d Model. Element: Association: : Association. Class From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Notation: Association 3 Model. Element: Association. En d Model. Element: Association. Class From UML

Notation: Association 3 Model. Element: Association. En d Model. Element: Association. Class From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Notation: Association: Composition Model. Element: Aggregation. Kind: Composite • Aggregation. Kind: – None •

Notation: Association: Composition Model. Element: Aggregation. Kind: Composite • Aggregation. Kind: – None • Related to / reference / dependency – Aggregate • Shared with other objects – Composition • Ownership • Same lifecycle • Often container for parts • Is often an address-space for parts • Often determines uniqueness of parts From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Model. Element: Association - Roots: • Are those element s that are not part

Model. Element: Association - Roots: • Are those element s that are not part of any composite relationship. • Can always find roots. Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Model. Element: Generalization • Possible to model generalizations and specializations • Also named inheritance,

Model. Element: Generalization • Possible to model generalizations and specializations • Also named inheritance, Is. A, . . . – Java: extends, implements Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Notation: Generalization Model. Element: Generalization From UML 1. 4 specification Copyright @ 2002, Anders

Notation: Generalization Model. Element: Generalization From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Model. Element: Use Case • Use Case – ”A use case is a kind

Model. Element: Use Case • Use Case – ”A use case is a kind of classifier representing a coherent unit of functionality provided by a system, or a class as manifested by a sequence of message exchanged among the system (subsystem, class) and one or more outside interactors (called actors) together with actions performed by the systems(subsystem, class). ” • Actor – ”An actor defines a coherent set of roles that users of an entity can play when interacting with an entity, An actor may be considered to play a separate role with regard to each use case with wich it communicates” Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Model. Element: Use Case • Describes usage scenarions from the perspective of users. •

Model. Element: Use Case • Describes usage scenarions from the perspective of users. • Often developed early in projects. • Good for communication purposes Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Notation: Use Case and Actor Model. Element: Use Case Model. Element: Actor From UML

Notation: Use Case and Actor Model. Element: Use Case Model. Element: Actor From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Notation: Use Case and Actor (extended) From UML 1. 4 specification Copyright @ 2002,

Notation: Use Case and Actor (extended) From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Diagram: Class (static structure) • ”A class diagram is a graph of Classifier elements

Diagram: Class (static structure) • ”A class diagram is a graph of Classifier elements connected by their various static relationships. ” • ”. . . A class diagram may also contain interfaces, packages, relationships end even instances, such as objects and links. ” • Does not show temporal or dynamic information. From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Diagram: Object (static structure) • ”An object diagram is a graph of instances including

Diagram: Object (static structure) • ”An object diagram is a graph of instances including objects and datavalues” • ”. . . it shows a snaphot of detailed state of a system at a point in time. ” • ”An object diagram shows instances compatible with a particulae class diagram” From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Diagram: Class and Object Model. Element: Class Model. Element : Object Name of Class

Diagram: Class and Object Model. Element: Class Model. Element : Object Name of Class / Classifier Name of Object Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Diagram: Class – Abstract syntax • Only generalization- specialization and composite relationship are displayed

Diagram: Class – Abstract syntax • Only generalization- specialization and composite relationship are displayed Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Diagram: Use case (static structure) From UML 1. 4 specification Copyright @ 2002, Anders

Diagram: Use case (static structure) From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Diagram: Collaboration (interaction) Rolename, object id, class Sequence number and name of operation From

Diagram: Collaboration (interaction) Rolename, object id, class Sequence number and name of operation From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Diagram: Sequence (interaction) object id timeline From UML 1. 4 specification Copyright @ 2002,

Diagram: Sequence (interaction) object id timeline From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Diagram: Statechart Model. Element: State. Machine ME: State ME: Event ME: End ME: Start

Diagram: Statechart Model. Element: State. Machine ME: State ME: Event ME: End ME: Start ME: Guard ME: Transition From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Diagram: Activity ME: Choice ME: Guard • Extends State. Machine • ”. . .

Diagram: Activity ME: Choice ME: Guard • Extends State. Machine • ”. . . convenient for modeling control-flows and object-flows in organizational processes. ” From UML 1. 4 specification, section 2. 13 Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Diagram: Activity: Swimlanes Swimlane • Organization activities according to responsibilities • Often related to

Diagram: Activity: Swimlanes Swimlane • Organization activities according to responsibilities • Often related to organizational units • Popular in business modeling From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Diagram: Activity: Object Flow Object Order in state: entered • • • ME: Object.

Diagram: Activity: Object Flow Object Order in state: entered • • • ME: Object. Flow. State Used often in collaboration with eb. XML Popular in business modeling ”Actions operate by and in objects. These objects either have primary responsibility for initiating an action, or are used or determined by the action, Actions usually specify calls sent between the object owning the activity graph, which initiates actions, and the objects that are the targets of the actions. ” From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Diagram: Activity: Send, Receive signals Send Receive From UML 1. 4 specification Copyright @

Diagram: Activity: Send, Receive signals Send Receive From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Diagram: Component (implementation) Classifier (Class) Component • Shows dependencies among components and the artifacts

Diagram: Component (implementation) Classifier (Class) Component • Shows dependencies among components and the artifacts that implements them (source code, scripts, etc. ) From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory

Diagram: Deployment (implementation) Process Node • Shows composition of runtime artifacts such as processors

Diagram: Deployment (implementation) Process Node • Shows composition of runtime artifacts such as processors and threads and their relationship to components From UML 1. 4 specification Copyright @ 2002, Anders W. Tell, Financial Toolsmiths AB , Open eb. XML Laboratory