UML for Realtime

(1)

UML for Realtime

Marie-Agnès Peraldi-Frati UNSA/I3S/INRIA

[email protected]

Charles André - University of Nice-Sophia Antipolis 2

Purpose

• Not a study of UML per se.

• UML for modeling real-time and embedded systems.

• Analyzing performance of such systems

• Implementing such systems

• Not restricted to software application

• Systems engineering

(2)

Part I: Introduction to UML

Excerpts from

Jean-Paul Rigault’s lecture.

(See the full course document //www-local.essi.fr/~jpr)

• Introduction: modeling and OO modeling

• Application modeling with Use Case

• Class and object modeling

• State modeling

Focus on modeling and

analysis

(3)

Modeling and OO modeling

• What is modeling?

• What is object-oriented modeling?

• What is UML?

• Technical activities in OO modeling

Overview of UML: A Brief History

Many OOAD methods (> 50)

Coad Coad Coad Coad----YourdonYourdonYourdonYourdon Shlaer Shlaer Shlaer Shlaer----MellorMellorMellorMellor Fusion Fusion Fusion Fusion etc.

etc.

199119911991

1991 1992199219921992 1993199319931993 1994199419941994 1995199519951995 1996199619961996 1997199719971997 1998199819981998 ………… 2004200420042004 Booch (Rose)

Booch (Rose) Booch (Rose) Booch (Rose) Good for design Good for designGood for design Good for design and construction and construction and construction and construction

Rumbaugh (OMT) Rumbaugh (OMT) Rumbaugh (OMT) Rumbaugh (OMT) Good for analysis and Good for analysis and Good for analysis and Good for analysis and data

data data

data----intensive systemsintensive systemsintensive systemsintensive systems

Jacobson (OOSE) Jacobson (OOSE)Jacobson (OOSE) Jacobson (OOSE) Good for the capture Good for the captureGood for the capture Good for the capture of requirements of requirements of requirements of requirements

U M L 0.8

U M L 0.9

Rational Rational Rational Rational

U M L 1.0

U M L 1.1 OMG request

UML UMLUML UML consortium consortium consortium consortium

U M L 1.2

U M L 1.3

U M L 2.0

OMG OMG OMG OMG OMG vote

(4)

What is UML and what is it for?

UML is a language for

– Visualizing – Specifying – Constructing – Documenting

Syntax, Semantics (verification)

Graphics

Architecture and behavior Allow code generation Textual and graphical

descriptions

the artifacts of a software-intensive system

Overview of UML: What is a UML Model?

• A Use Case view

– Functional requirements

• Several object views

– Different concerns (architecture, behaviour…) – Different levels of

description

(analysis, design, implementation…)

State StateState State Diagrams DiagramsDiagrams Diagrams Use Case

Use CaseUse Case Use Case Diagrams Diagrams Diagrams DiagramsUse CaseUse CaseUse CaseUse Case

Diagrams DiagramsDiagrams DiagramsUse CaseUse CaseUse CaseUse Case

Diagrams Diagrams Diagrams Diagrams

Scenario ScenarioScenario Scenario Diagrams Diagrams Diagrams DiagramsScenarioScenarioScenarioScenario

Diagrams Diagrams Diagrams Diagrams Collaboration CollaborationCollaboration Collaboration Diagrams DiagramsDiagrams Diagrams

State StateState State Diagrams DiagramsDiagrams DiagramsStateStateStateState Diagrams Diagrams Diagrams DiagramsComponentComponentComponentComponent

Component Component Component Component Diagrams Diagrams Diagrams DiagramsComponent ComponentComponent Component Diagrams Diagrams Diagrams DiagramsDeployment DeploymentDeployment Deployment Diagrams Diagrams Diagrams Diagrams

State StateState State Diagrams DiagramsDiagrams DiagramsStateStateStateState Diagrams Diagrams Diagrams DiagramsObjectObjectObjectObject Diagrams Diagrams Diagrams Diagrams

Scenario Scenario Scenario Scenario Diagrams DiagramsDiagrams DiagramsScenarioScenarioScenarioScenario

Diagrams Diagrams Diagrams DiagramsStatechartStatechartStatechartStatechart

Diagrams Diagrams Diagrams Diagrams Use Case Use Case Use Case Use Case Diagrams Diagrams Diagrams DiagramsUse CaseUse CaseUse CaseUse Case

Diagrams Diagrams Diagrams DiagramsSequenceSequenceSequenceSequence

State State State State Diagrams Diagrams Diagrams DiagramsClassClassClassClass Diagrams Diagrams Diagrams Diagrams

Activity Activity Activity Activity Diagrams Diagrams Diagrams Diagrams Model ModelModel Model Elements ElementsElements Elements

(5)

UML and Software Methodologies

• The UML is methodology independent

• However it is better suited to a development process that is

– Use case driven – Architecture centric – Iterative and incremental

Technical activities in OO

modeling

(6)

Application modeling

• Modeling requirements in UML – Functional requirements

• Modeled as Use Cases

– Non-functional requirements

• Some are specific to one use case

• Some relate to technical issues addressed by implementation diagrams and models

• Other in some supplementary documents, out of the UML scope

Timing constraints, Reliability,

…

System Requirements Capture

Identify capabilities as Use Cases

Use Case scenario analysis Use Case specification

Identify interactions of interest

Add QoS Constraints

Informal specification

Specify protocols of interaction with Statecharts or

activity diagrams

Derive scenarios from specifications

Add QoS Constraints

Requirements

“By example” Requirements

“By specification”

(7)

What is a Use Case?

• Set of sequences of actions that a system performs and that yields an observable result

• A set of related services provided by the system, together with scenarios of use.

• Actor

– Anything which interface with the system – Not part of the system

Sensors, actuators, …

Use Case: Difficulty and Drawbacks

• Use case modeling is difficult

– Homogeneity, completeness, consistency…

• UML “formalism” is simple, even simplistic

– No real semantics

– No formal description of textual senarios

– Need for predefined interpretations, corporate policies

• Textual scenarios awkwardly express complex control

– Loops, conditionals…

(8)

Use Case: Advantages

• Simple to elaborate, understand, and communicate

– Even for non-computer scientists

• Focus on user needs, not on solution or architecture

– Avoid architectural drift in object-orientation – Ease traceability from functional needs to

implementation

• Facilitate setting up integration tests – From use cases, one can derive test cases

Use Cases

• A use case usually provides a textual description outlining its intent and purpose.

• Use Case Description Format:

– Name – Purpose

• May be written informally (“The purpose of the capability is to…”) – Description

• May be written semi-formally (“The system shall…”)

• May be informal

• May be a hyperlink off to a separate document – Preconditions

• What is true prior to the execution of the capability?

– Postconditions

• What does the system guarantee to be true after the execution of the use case?

– Constraints

• Additional QoS requirements or other rules for the use case

(9)

Use Case Diagram

User

Priority User

Edit Phone List Data

Initialize phone

Display text

Connected services

Make call

Send text message

Receive call

Receive text message

Phone Company

Make priority call

<< predecessor >>

<< include >>

<< extends >>

{ worst case performance < 2s }

YakityYak Deluxe ™ Cell Phone use cases.

Identifies the primary capabilities of the system.

Dependency relation

Association relation

Generalization relation

Object-Orientation Overview

The (application) world is composed of objects These objects are linked together

Static relationships (links)

These objects react to stimuli (messages)

Either internal or external

Originating from other objects or from outside the system

These objects have an internal state

Internal data (attributes) and status of the links with other

The statemay change when the objects are stimulated

(10)

What is an object?

Object =Identity+State+Behavior

Objects should be distinguishable

The identity is independent of the state

Internal data values Status of links with other objects

Operations,

events, messages…

Public interface

Objects have “crisp” conceptual boundaries (Booch, 1994)

What is an object?

Static information: architectural aspects – List of operations (interface)

• The messages the object can accept and react to

– State values

• Possible values of internal data (attributes)

• Possible links with other objects, that are message transport media

Dynamic behavior: control aspect

– State evolution and messages sent to other objects

• Triggered by message flows

(11)

What is a Class?

A group of objects sharing common properties

– common structure:

• same attributes

• same possible relations with other objects

– common behavior: same operations An abstract data type

A model to instantiate objects

– A class defines the possible behaviors and the information structure of all its instances

Model Elements

ModelElement

Diagram

“Thing”

Relation

Abstractions, first-class citizen in the model

Tie "things" together

Group interesting collections of things and express (some of) their relationships

(12)

Model Elements: Summary

ModelElement

Diagram

“Thing”

Use Case Class Interface Collaboration

Active Class Component Node

Relation

Realization Dependency Association Generalization

Class Use Case Collaboration

Deployment

Object Sequence State-Transition Component Activity

Structural

Behavioral Organizational Annotational

Interaction

State Machine Package

Note

Dynamic diagrams

Model Elements: Diagrams

Class diagram Object diagram Use case diagram Sequence diagram Collaboration diagram Statechart diagram Activity diagram Component diagram Deployment diagram

Static diagrams

Static (implementation) diagrams Interaction diagrams

State-transition diagrams

(13)

UML Diagrams

Requirement modeling, Design…

Design, Test, Configuration Management

Requirement modeling, Design Design, Test, Simulation Requirement modeling, Design, Test

Requirement modeling, Design, Test

Requirement modeling Analysis, Design, Test…

Analysis and Design

Run-time organization, distribution…

Deployment

Software resource organization Component

Business procedures Activity

Dynamic behavior Statechart

Cooperation between objects, Design Patterns

Collaboration

Scenario of use, exchange of messages between objects Sequence

Application needs Use Case

Architecture of a particular instance of the model Object

Architecture, structure Class

Part II: UML 2.0

Model-Driven Development and MDA

Excerpts from “Bubbles of Steel:

A Preview of UML 2.0 and MDA”

Bran Selic

IBM Software Group – Rational Software

(14)

Model-Driven Style of Development

• An approach to software development in which the focus and primary artifacts of development are models (as opposed to programs)

– Implies automatic generation of programs from models

– Using modeling languagesdirectly as implementation tools

– “The model isthe implementation”

Modeling vs. Programming Languages

Level of Abstraction

high

low

Programming Languages

(C/C++, Java, …)

Modeling Languages

(UML,…)

∆

LO

::::

data layout, arithmetical and logical operators, etc.

∆

HI

::::

statecharts, interaction diagrams, architectural structure, etc.

Cover different ranges of abstraction

(15)

Covering the full range of detail

(Any) Action Language

“Action” languages(e.g., Java, C++) for fine-grain detail

Level of Abstraction

high

low

Programming Languages

(C/C++, Java, …)

Modeling Languages

(UML,…)

implementation level detail (application specific)

Fine-grain logic, arithmetic formulae, etc.

How We Learn From Models

Ξ = Ξ = Ξ =

Ξ = cos(η + π/2)(η + π/2)(η + π/2)(η + π/2) + ξ∗5 + ξ∗5 + ξ∗5 + ξ∗5 Ξ = Ξ =

Ξ = Ξ = cos(η + π/2)(η + π/2)(η + π/2)(η + π/2) + ξ∗5 + ξ∗5 + ξ∗5 + ξ∗5

?

• By inspection

?

– mental execution – unreliable

Ξ = Ξ = Ξ =

Ξ = cos(η + π/2)(η + π/2)(η + π/2)(η + π/2) + ξ∗5 + ξ∗5 + ξ∗5 + ξ∗5 Ξ = Ξ = Ξ =

Ξ = cos(η + π/2)(η + π/2)(η + π/2)(η + π/2) + ξ∗5 + ξ∗5+ ξ∗5 + ξ∗5

?

• By formal analysis

?

•Mathematical methods

•Reliable (theoretically)

•Software is very difficult to model

mathematically! ??

Ξ = Ξ = Ξ =

Ξ = cos(η + π/2)(η + π/2)(η + π/2)(η + π/2) + ξ∗5 + ξ∗5 + ξ∗5 + ξ∗5 Ξ = Ξ = Ξ =

Ξ = cos(η + π/2)(η + π/2)(η + π/2)(η + π/2) + ξ∗5 + ξ∗5+ ξ∗5 + ξ∗5

•By experimentation (execution)

•More reliable than inspection

•Direct experience/insight

(16)

MDD Implications

• Ultimately, it should be possible to:

– Execute models

– Translatethem automatically into implementations – …possibly for different implementation platforms Platform independent models(PIMs)

• Modeling language requirements

– The semanticunderpinnings of modeling languages must be precise and unambiguous

– It should be possible to easily specializea modeling language for a particular domain

– It should be possible to easily define new specialized languages

The OMG’s Model Driven Architecture

• The OMG has formulated an initiative called “Model-Driven Architecture” (MDA)

– A framework for a set of standards in support of MDD – Inspired by the widespread public acceptance of UML and

the availability of mature MDD technologies

• Rational is a pioneer of model-driven development and is one of the principal drivers of MDA

– Conceived and refined UML (Booch, Rumbaugh, Jacobson) – Model-driven development process (RUP)

– Tools for executable models and automatic code generation (XDE, Rose RealTime, Rose)

(17)

The Languages of MDA

• Set of modeling languagesfor specific purposes

General Standard UML

Common Warehouse Metamodel (CWM)

etc.

Real-Time profile

EAI profile

Software process profile

etc.

MetaObject Facility (MOF)

A modeling language for defining modeling languages

For exchanging information about business data

For general OO modeling UML

“bootstrap”

MOF MOF

“core”

1967 Jacobson

UML: The Foundation of MDA

Booch Rumbaugh

UML 1.1 (OMG Standard) UML 1.1 (OMG Standard)

UML 1.3 (extensibility) UML 1.3 (extensibility) UML 1.4 (action semantics) UML 1.4 (action semantics)

UML 1.4.1 UML 1.4.1

1996 1997 1998 2001 2002 2003

UML 2.0 (MDA) UML 2.0 (MDA)

Foundations of OO (Nygaard, Meyer, Stroustrup, Harel, Wirfs-Brock, Reenskaug,…)

(18)

Formal RFP Requirements

1) Infrastructure – UML internals

– More precise conceptual base for better MDA support

2) Superstructure – User-level features

– New capabilities for large-scale software systems – Consolidation of existing features

3) OCL – Constraint language

– Full conceptual alignment with UML

4) Diagram interchange standard

– For exchanging graphic information (model diagrams)

Language Structure

• A core language + optional “sub-languages”

– Enables flexible subsetting for specific needs – Users can “grow into” more advanced capabilities

OCL

Basic UML

(Classes, Basic behavior, Internal structure, Use cases…) MOF Profiles

State Machines

Structured Classes and Components

Activities Interactions Detailed Actions

Flows

Basic Level Basic Level

Intermediate Level Intermediate Level

Complete Level Complete Level

UML Infrastructure

(19)

Infrastructure: Consolidation of Concepts

• Breakdown into fundamental conceptual primitives

Namespace PackagableElement RedefinableElement

Classifier Feature

• Eliminate semantic overlap

• Better foundation for precise definition of concepts and semantics

Infrastructure: Behavior Harmonization

• Common semantic base for all behaviors

– Choice of behavioral formalism driven by application needs

Classifier

. . .

Class UseCase Component Action Activity Interaction Statemachine Behavior

0..1 0..*

(20)

Package diagrams

Package

• Package = Organizationalmodel elements.

– Provides a way to group related UML elements – and scope their names (defines a namespace)

– Contains PackageableElements(Class, Object, Event, Packages… are PackageableElements).

• Packages cannot be instantiated and can only be used to organize models

.

• Representation

– A package is denoted by a rectangle with a tab attached to the top left.

– Example: the Utilitiespackage below – Utilitiesis the name of the package

– Each element in the package has a fully qualified name (e.g., Utilities::Timer).

(21)

Representations

Charles André - UNSA 41

Visibility

• May specify visibility information for owned and imported elements (public or private)

(22)

Importing & Accessing Packages

• When accessingelements in one package from a different package, you must qualify the name of the element you are accessing.

• To simplifyaccessing elements in a different package, UML allows a package to importanother package. Imported elements are

available without qualification in the importing package.

• By default, imported elements are public, but they can be given private visibility.

• «import» vs. «access»

• «merge» mainly for metamodeling.

UML: Diagrammes de Classes

Transparents inspirés de [4]

(23)

Charles André - University of Nice-Sophia Antipolis

45 Charles André - UNSA

45

Diagrammes de classes

• Les diagrammes de classes représentent un ensemble de classes, d'interfaces et de collaborations, ainsi que leurs relations.

Ce sont les diagrammes les plus fréquents dans la modélisation des systèmes à

objets. Ils présentent la vue de conception statique d'un système. Les diagrammes de classes, (qui comprennent aussi les

classes actives), présentent la vue de processus statique d'un système.

Les classes

• La classe est une description abstraited’un ensemble d’objets

• La classe peut être vue comme la factorisationdes éléments communs à un ensemble d’objets

• La classe décrit le domaine de définitiond’un ensemble d’objets

• Description conceptuellement sépa- rée en deux parties

– La spécificationd’une classe qui décrit le domaine de définition et les

propriétés des instances de cette classe (type de donnée)

– La réalisationqui décrit comment la spécification est réalisée

• Caractéristiques des classes

– Attributs – Opérations – Réceptions – Relations – Multiplicité – Persistance – Composant

(24)

Eléments graphiques

parametre

classe parametrable

une classe une autre classe

nom de l’association

nom de la classe association

attributs operations

une classe une autre classe

nom de l’association / association dérivée

rôle 1 rôle 2

nom de la classe attributs

nom_attr : type = valeur initiale opérations

nom_op (arg_list):type nom de la classe

- variable privée + variable publique

# variable protégée - opération privée + opération publique

# opération protégée

Remarque: Commencer le nom d’une classe par une majuscule

Visibilité des attributs et opérations

• Public+

Visible à l’extérieur de la classe

• Protected#

Visible seulement par les descendants (classes dérivées)

• Private-

Visible à l’intérieur des méthodes

• Package~

• Souligné

attribut/opération de classe (statique)

(25)

Relations : association

• L’association

• L’agrégation

• La composition

• La généralisation

• La dépendance

• L’association exprime une connexion

sémantique

bidirectionnelle entre classes

• Une association est une abstraction des liens qui existent entre les objets instances des classes associées

Relation

Realization Dependency Association Generalization

Exemple d’association

(26)

Nommage des associations

• Indication du sens de lecture

Nommage des rôles

• Le rôle décrit une extrémité d’une association

(27)

Multiplicité des rôles

1 Un et un seul

0..1 Zéro ou un

M .. N De M à N (entiers naturels)

* Plusieurs

0 .. * De zéro à plusieurs 1 .. * D'un à plusieurs

class Personne {

Compagnie employeur; ... }

Navigabilité

• étant donnée une association non décorée entre deux classes, on peut naviguer d'un type d'objet vers un autre type d'objet.

• par défaut une association est navigable dans les deux sens.

• une indication de navigabilité suggère en général qu'à partir d'un objet à une extrémité on peut directement et facilement

atteindre l'un des objets à l'autre extrémité.

• lors d'une mise en œuvre programmée, ceci peut suggérer par exemple qu'un objet source mémorise une référence directe aux objets cible.

• étant donné un utilisateur, on désire pouvoir accéder à ses mots de passe

• étant donné un mot de passe, on ne souhaite pas pouvoir accéder à l'utilisateur correspondant

(28)

Exemple

L’agrégation

• Forme d’association qui exprime un couplage plus fort entre classes

• Connexions sémantiques

bidirectionnelles non-symétriques

• Représentation des relations – maître et esclaves

– tout et parties

– composé et composant.

(29)

L’agrégation

• Forte = Composition Modélisation de la composition physique

– Multiplicitéau max de1 du coté de l’agrégat – Propagation automatique

de la destruction

– Agrégation simple

Compagnie

Département

* 1

Le tout

La partie

Relation : spécialisation/généralisation

• Gérer la complexité

• Héritage

• Arborescences de classes d’abstraction croissante

class Sous-Classe extends Super-classe { ... }

(30)

Relation de Dépendance

• Relation très générale (peut être utilisée entre n’importe quel NamedElement).

• Entre classes: la classe B dépend de la classe A. Si A change, B peut changer; mais pas l’inverse.

• Notation UML: Un trait discontinupartant de la classe dépendante et pointant vers la classe

proposant les services sollicités, se terminant par une pointe de flèche ouverte

Exemple : Un contrat dispose d'un service d'impression (méthode impression), qui utilise une méthode (print), dont la spécification est déclarée par l'interface Printer.

Relation de réalisation

• Notation UML: Un trait discontinupartant de la classe d'implémentation et allant vers l'interface, se terminant par une pointe de flèche fermée, la même utilisée par la spécialisation/généralisation

• La fenêtre SaisirClient réalisele contrat définit par l'interface ActionListener.

class SaisirClient extends JFrame

implements ActionListener { ...

public void actionPerformed (ActionEvent e) { // faire quelque chose }

(31)

Exercice faire le diag de classes

public interfaceObserver {

public void update(Observable o);

}

public classObservable { Collection observateurs;

public void notify() {

Iterator it = this.iterator();

while (it.hasNext())

{ ((Observer) it.next()).update(this);

} }

public void addObserver(Observer o) { observateurs.add(o); } ... } public classBilan extendsObservable {

void setChange() { notify(); } ...

}

public classUIGraphe implementsObserver { public void update(Observable o) {

Bilan unbilan = (Bilan) o;

double compteResultat = unbilan.getCompteResultat();

... } ...}

Retour sur les attributs (1)

• Les attributs peuvent

– Inlined attributes

– Attributes by relationship

• Il n’y a pas de

différence sémantique entre les deux

• Remarque: Avec les relations on peut introduire plus d’information (e.g., composition)

62

(32)

Retour sur les attributs (2)

• Notation générale des inlined attributes

visibility / name : type multiplicity = default { property strings and constraints }

visibility ::= + | - | # | ~

multiplicity ::= [ lower .. upper ]

/ indique que l’attribut est dérivé. Sa valeur peut être calculée à partir des autres attributs de la classe.

Retour sur les attributs (3)

• Attribute multiplicity:

quand plus qu’un, on peut préciser en plus

{ ordered, unique }

Défaut: unique, non ordonné

• Attribute properties:

– readOnly – union

– subsets attribute-name

– redefines attribute-name

(33)

Contraintes

• Les contraintes représentent des restrictions imposées sur un élément.

• Exprimées en langage naturel ou en langage formel (e.g., OCL)

• Notation: la contrainte est placée entre { }après

l’éléments contraint ou dans une note.

Retour sur les opérations

66

• Notation

visibility name ( parameters ) : return-type { properties and constraints }

visibility ::= + | - | # | ~

parameter ::= direction param-name type multiplicity = default-value { properties } direction ::= in | out | inout | return

multiplicity ::= [ lower .. upper ]

• Operation constraints

– preconditionsstate before invocation – postconditionsstate after execution

– body conditions constraints on the returned value – querydoes not modify the state of the class

(34)

67

Objet

• Un objet est une instance de classe.

• Chaque instance peut avoir un nom ou bien être anonyme. Le nom (s’il est donné) est suivi de : et son type (souvent une classe).

Une classe

Une instance de la classe Car

Remarque: commencer le nom d’une instance par une minuscule

Classe abstraite

• Une classe abstrait est utile pour identifier des fonctionnalités communes à plusieurs types d’objets.

• Notation: Le nom d’une classes abstraite est écrit en italique.

• Une classe abstraite ne peut pas être

instanciée. Elle doit être sous-classée

(spécialisée). Les sous-classes concrètes

peuvent être instanciées.

(35)

Les classes-associations (1)

•Ajout d’attributs ou d’opérations dans la relation

Personne Société

employé

* 0..2

Emploi salaire augmenter()

société

Le nom de la classe correspond au nom de l’association

Attention: Pour une association donnée, un couple d'objets ne peut être connectés que par un seul lien correspondant à cette association.

(sauf si l'association est décorée par {nonunique} en UML2.0)

Classes-associations (2)

Emploi salaire

Personne Société

employé

1 1

0..2 * société

Ci-dessus, une personne peut avoir deux emplois dans la même société

e2

p1 s1

e1

Personne Société

employé

* 0..2

Emploi salaire

sociétés

Ci-dessus, une personne peut avoir un emploi, dans deux sociétés différentes

p1 s1

e1

(36)

Interfaces (1)

• Une interface est un classeur (classifier) qui à des déclarations de propriétés et d’opérations mais pas d’implémentations.

• On peut utiliser des interfaces pour grouper des éléments communs à plusieurs classeurs et fournir un contrat qu’un classeur qui implémente l’interface doit respecter.

• Assez proche du concept d’interface en Java.

Interfaces (2)

Class that implements the interface

Class that uses the interface Other notation: ball (provided interface)

And socket (required interface)

(37)

73

Templates

• UML permet d’utiliser des abstractions pour les types de classes avec lesquels une classes peut interagir.

Templated class

Explicit template binding Implicit template binding

Classifier

• A classifier is a classification of instances, it describes a set of instances that have features

(structural and/or behavioral)

in common.

• Kinds of Classifiers: Class, Actor, Component, DataType, Interface, Node, Signal, Subsystem, UseCase,…

• Classes are the most general kind of classifiers.

Other can be intuitively understood as similar to classes, with certain restrictions on content or

usage. (

Excerpts from [B2])

• Note that Classifier is an abstract metaclass

(38)

Data types

• A data type is a type whose instances are identified only by their value. A DataType may contain attributes to support the modeling of structured data types.

Danger:

A metamodel, not a user’s

model

• All copies of an instance of a data type and any instances of that data type with the same value are considered to be the same instance. Value ≠ Object

Enumeration

• A data type whose instances form a list of named literal values.

• An enumeration is a user-definable data type.

(39)

References

Official references

• [UML-Infra] OMG“UML 2.0 InfrastructureSpecification”, September 2003, OMG Adopted Specification, ptc/03- 09-15.

• [UML-Super] OMG “UML 2.0 Superstructure Specification”, August 2003, OMG Adopted Specification, ptc/03-08-02.

• [MOF] OMG “Meta Object Facility (MOF) 2.0 Core Specification”, October 2003, OMG Adopted Specification ptc/03-010-04.

• [OCL] OMG “Unified Modeling Language: OCL”, August 2003, OMG 2.0 Draft Adopted Specification ptc/03-08- 08.

(40)

Books

• The Unified Modeling Language User Guide Grady Booch, James Rumbaugh, Ivar Jacobson Addison Wesley, 1999.

• The Unified Modeling Language Reference Guide James Rumbaugh, Grady Booch, Ivar Jacobson

Addison Wesley, 1999

• Real-Time UML

Douglass B.P., Addison-Wesley, 1998.

• Doing Hard Time

Douglass B.P., Addison-Wesley, 1999.

• Real-Time Design Patterns

Douglass B.P., “Addison-Wesley, 2003.

UML for Realtime

UML for Realtime

Marie-Agnès Peraldi-Frati UNSA/I3S/INRIA

[email protected]

Purpose

• Not a study of UML per se.

• UML for modeling real-time and embedded systems.

• Analyzing performance of such systems

• Implementing such systems

• Not restricted to software application

• Systems engineering

Part I: Introduction to UML

Excerpts from

Jean-Paul Rigault’s lecture.

(See the full course document //www-local.essi.fr/~jpr)

Contents

• Introduction: modeling and OO modeling

• Application modeling with Use Case

• Class and object modeling

• State modeling

Focus on modeling and

analysis

Modeling and OO modeling

• What is modeling?

• What is object-oriented modeling?

• What is UML?

• Technical activities in OO modeling

Overview of UML: A Brief History

What is UML and what is it for?

UML is a language for

the artifacts of a software-intensive system

Overview of UML: What is a UML Model?

UML and Software Methodologies

• The UML is methodology independent

• However it is better suited to a development process that is

– Use case driven – Architecture centric – Iterative and incremental

Technical activities in OO

modeling

Application modeling

• Modeling requirements in UML – Functional requirements

– Non-functional requirements

System Requirements Capture

What is a Use Case?

• Set of sequences of actions that a system performs and that yields an observable result

• A set of related services provided by the system, together with scenarios of use.

• Actor

– Anything which interface with the system – Not part of the system

Use Case: Difficulty and Drawbacks

• Use case modeling is difficult

• UML “formalism” is simple, even simplistic

• Textual scenarios awkwardly express complex control

Use Case: Advantages

• Simple to elaborate, understand, and communicate

– Even for non-computer scientists

• Focus on user needs, not on solution or architecture

– Avoid architectural drift in object-orientation – Ease traceability from functional needs to

implementation

• Facilitate setting up integration tests – From use cases, one can derive test cases

Use Cases

Use Case Diagram

Object-Orientation Overview

The (application) world is composed of objects These objects are linked together

These objects react to stimuli (messages)

These objects have an internal state

What is an object?

What is an object?

Static information: architectural aspects – List of operations (interface)

– State values

Dynamic behavior: control aspect

– State evolution and messages sent to other objects

What is a Class?

A group of objects sharing common properties

– common structure:

– common behavior: same operations An abstract data type

A model to instantiate objects

– A class defines the possible behaviors and the information structure of all its instances

Model Elements

Model Elements: Summary

Model Elements: Diagrams

Class diagram Object diagram Use case diagram Sequence diagram Collaboration diagram Statechart diagram Activity diagram Component diagram Deployment diagram