Upload
duongkhuong
View
254
Download
0
Embed Size (px)
Citation preview
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 1
UML for Realtime
Marie-Agnès Peraldi-Frati
UNSA/I3S/INRIA
Charles André - University of Nice-Sophia Antipolis2
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
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 2
Part I: Introduction to UML
Excerpts from Jean-Paul Rigault’s lecture.
(See the full course document//www-local.essi.fr/~jpr)
Charles André - University of Nice-Sophia Antipolis4
Contents
• Introduction: modeling and OO modeling
• Application modeling with Use Case
• Class and object modeling
• State modeling
Focus on
modeling and
analysis
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 3
Charles André - University of Nice-Sophia Antipolis5
Modeling and OO modeling
• What is modeling?
• What is object-oriented modeling?
• What is UML?
• Technical activities in OO modeling
Charles André - University of Nice-Sophia Antipolis6
Overview of UML: A Brief History
Many
OOAD
methods
(> 50)
CoadCoadCoadCoad----YourdonYourdonYourdonYourdon
ShlaerShlaerShlaerShlaer----MellorMellorMellorMellor
FusionFusionFusionFusion
etc.etc.etc.etc.
1991199119911991 1992199219921992 1993199319931993 1994199419941994 1995199519951995 1996199619961996 1997199719971997 1998199819981998 ………… 2004200420042004
Booch (Rose)Booch (Rose)Booch (Rose)Booch (Rose)
Good for designGood for designGood for designGood for design
and constructionand constructionand constructionand construction
Rumbaugh (OMT)Rumbaugh (OMT)Rumbaugh (OMT)Rumbaugh (OMT)
Good for analysis andGood for analysis andGood for analysis andGood for analysis and
datadatadatadata----intensive systemsintensive systemsintensive systemsintensive systems
Jacobson (OOSE)Jacobson (OOSE)Jacobson (OOSE)Jacobson (OOSE)
Good for the captureGood for the captureGood for the captureGood for the capture
of requirementsof requirementsof requirementsof requirements
U
M
L
0.8
U
M
L
0.9
RationalRationalRationalRational
U
M
L
1.0
U
M
L
1.1
OMG request
UMLUMLUMLUMLconsortiumconsortiumconsortiumconsortium
U
M
L
1.2
U
M
L
1.3
U
M
L
2.0
OMGOMGOMGOMG
OMG vote
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 4
Charles André - University of Nice-Sophia Antipolis7
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
Charles André - University of Nice-Sophia Antipolis8
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…)
StateStateStateState
DiagramsDiagramsDiagramsDiagramsUse CaseUse CaseUse CaseUse Case
DiagramsDiagramsDiagramsDiagramsUse CaseUse CaseUse CaseUse Case
DiagramsDiagramsDiagramsDiagramsUse CaseUse CaseUse CaseUse Case
DiagramsDiagramsDiagramsDiagrams
ScenarioScenarioScenarioScenario
DiagramsDiagramsDiagramsDiagramsScenarioScenarioScenarioScenario
DiagramsDiagramsDiagramsDiagramsCollaborationCollaborationCollaborationCollaboration
DiagramsDiagramsDiagramsDiagrams
StateStateStateState
DiagramsDiagramsDiagramsDiagramsStateStateStateState
DiagramsDiagramsDiagramsDiagramsComponentComponentComponentComponent
DiagramsDiagramsDiagramsDiagrams
ComponentComponentComponentComponent
DiagramsDiagramsDiagramsDiagramsComponentComponentComponentComponent
DiagramsDiagramsDiagramsDiagramsDeploymentDeploymentDeploymentDeployment
DiagramsDiagramsDiagramsDiagrams
StateStateStateState
DiagramsDiagramsDiagramsDiagramsStateStateStateState
DiagramsDiagramsDiagramsDiagramsObjectObjectObjectObject
DiagramsDiagramsDiagramsDiagrams
ScenarioScenarioScenarioScenario
DiagramsDiagramsDiagramsDiagramsScenarioScenarioScenarioScenario
DiagramsDiagramsDiagramsDiagramsStatechartStatechartStatechartStatechart
DiagramsDiagramsDiagramsDiagrams
Use CaseUse CaseUse CaseUse Case
DiagramsDiagramsDiagramsDiagramsUse CaseUse CaseUse CaseUse Case
DiagramsDiagramsDiagramsDiagramsSequenceSequenceSequenceSequence
DiagramsDiagramsDiagramsDiagrams
StateStateStateState
DiagramsDiagramsDiagramsDiagramsClassClassClassClass
DiagramsDiagramsDiagramsDiagrams
ActivityActivityActivityActivity
DiagramsDiagramsDiagramsDiagrams
ModelModelModelModel
ElementsElementsElementsElements
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 5
Charles André - University of Nice-Sophia Antipolis9
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
Charles André - University of Nice-Sophia Antipolis10
Technical activities in OO modeling
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 6
Charles André - University of Nice-Sophia Antipolis11
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,
…
Charles André - University of Nice-Sophia Antipolis12
System Requirements CaptureIdentify 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”
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 7
Charles André - University of Nice-Sophia Antipolis13
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, …
Charles André - University of Nice-Sophia Antipolis14
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…
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 8
Charles André - University of Nice-Sophia Antipolis15
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
Charles André - University of Nice-Sophia Antipolis16
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
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 9
Charles André - University of Nice-Sophia Antipolis17
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
Charles André - University of Nice-Sophia Antipolis18
Object-Orientation OverviewThe (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 state may change when the objects are stimulated
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 10
Charles André - University of Nice-Sophia Antipolis19
What is an object?
Object = Identity + State + Behavior
Objects should bedistinguishable
The identity is independent
of the state
Internal data valuesStatus of links with otherobjects
Operations,events, messages…
Public interface
Objects have “crisp” conceptual boundaries (Booch, 1994)
Charles André - University of Nice-Sophia Antipolis20
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
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 11
Charles André - University of Nice-Sophia Antipolis21
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
Charles André - University of Nice-Sophia Antipolis22
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
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 12
Charles André - University of Nice-Sophia Antipolis23
Model Elements: Summary
ModelElement
Diagram
“Thing”
Use Case
Class
Interface
Collaboration
Active Class
Component
Node
Relation
Realization
DependencyAssociationGeneralization
Class
Use Case
Collaboration
Deployment
Object
Sequence
State-Transition
ComponentActivity
Structural
Behavioral
OrganizationalAnnotational
InteractionState Machine
PackageNote
Charles André - University of Nice-Sophia Antipolis24
Dynamic
diagrams
Model Elements: DiagramsClass 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
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 13
Charles André - University of Nice-Sophia Antipolis25
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 organizationComponent
Business proceduresActivity
Dynamic behaviorStatechart
Cooperation between objects, Design Patterns
Collaboration
Scenario of use, exchange of messages between objects
Sequence
Application needsUse Case
Architecture of a particular instance of the model
Object
Architecture, structureClass
Part II: UML 2.0
Model-Driven Development and MDA
Excerpts from “Bubbles of Steel: A Preview of UML 2.0 and MDA”
Bran SelicIBM Software Group – Rational Software
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 14
Charles André - University of Nice-Sophia Antipolis27
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 languages directly as implementation
tools
– “The model is the implementation”
Charles André - University of Nice-Sophia Antipolis28
Modeling vs. Programming Languages
Level of
Abstraction
high
low
Programming
Languages(C/C++, Java, …)
Modeling
Languages
(UML,…)
∆∆∆∆LO::::data layout, arithmeticaland logicaloperators,etc.
∆∆∆∆HI::::statecharts,interactiondiagrams,architecturalstructure, etc.
Cover different ranges of abstraction
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 15
Charles André - University of Nice-Sophia Antipolis29
Covering the full range of detail
(Any) Action
Language
“Action” languages (e.g., Java, C++) for fine-grain detail“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.
Fine-grain
logic,
arithmetic
formulae,
etc.
Charles André - University of Nice-Sophia Antipolis30
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
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 16
Charles André - University of Nice-Sophia Antipolis31
MDD Implications• Ultimately, it should be possible to:
– Execute models
– Translate them automatically into implementations
– …possibly for different implementation platforms
� Platform independent models (PIMs)
• Modeling language requirements
– The semantic underpinnings of modeling languages must be
precise and unambiguous
– It should be possible to easily specialize a modeling
language for a particular domain
– It should be possible to easily define new specialized
languages
Charles André - University of Nice-Sophia Antipolis32
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)
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 17
Charles André - University of Nice-Sophia Antipolis33
The Languages of MDA• Set of modeling languages for specific purposes
GeneralStandard UML
Common Warehouse
Metamodel (CWM)
etc.
Real-Timeprofile
EAI profile
Softwareprocess profile
etc.
MetaObjectFacility (MOF)
A modeling language
for defining modeling
languages
For exchanging
information about
business data
For general OO
modeling
UML
“bootstrap”
MOFMOF“core”
Charles André - University of Nice-Sophia Antipolis34
1967
Jacobson
UML: The Foundation of MDA
BoochRumbaugh
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.1UML 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,…)
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 18
Charles André - University of Nice-Sophia Antipolis35
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)
Charles André - University of Nice-Sophia Antipolis36
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
StateMachines
StructuredClasses andComponents
Activities Interactions DetailedActions
Flows
Basic LevelBasic Level
Intermediate LevelIntermediate Level
Complete LevelComplete Level
UML Infrastructure
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 19
Charles André - University of Nice-Sophia Antipolis37
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
Charles André - University of Nice-Sophia Antipolis38
Infrastructure: Behavior Harmonization
• Common semantic base for all behaviors
– Choice of behavioral formalism driven by application
needs
Classifier
. . .Class UseCase Component Action Activity StatemachineInteraction
Behavior0..1 0..*
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 20
Charles André - University of Nice-Sophia Antipolis39
Package diagrams
Charles André - University of Nice-Sophia Antipolis40Charles André - UNSA40
Package
• Package = Organizational model 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 Utilities package below
– Utilities is the name of the package
– Each element in the package has a fully qualified name (e.g., Utilities::Timer).
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 21
Charles André - University of Nice-Sophia Antipolis41
Representations
Charles André - UNSA41
Charles André - University of Nice-Sophia Antipolis42
Visibility
• May specify visibility information for owned and imported elements (public or private)
Charles André - UNSA42
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 22
Charles André - University of Nice-Sophia Antipolis43
Importing & Accessing Packages• When accessing elements in one package from a different package,
you must qualify the name of the element you are accessing.
• To simplify accessing elements in a different package, UML allows a
package to import another 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.Charles André - UNSA43
Charles André - University of Nice-Sophia Antipolis44
UML: Diagrammes de Classes
Transparents inspirés de [4]
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 23
Charles André - University of Nice-Sophia Antipolis45Charles André - UNSA45
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.
Charles André - University of Nice-Sophia Antipolis4646
Les classes
• La classe est une description abstraite d’un ensemble d’objets
• La classe peut être vue comme la factorisation des éléments communs à un ensemble d’objets
• La classe décrit le domaine de définition d’un ensemble d’objets
• Description conceptuellement sépa-rée en deux parties
– La spécification d’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éalisation qui décrit comment la spécification est réalisée
• Caractéristiques des
classes
– Attributs
– Opérations
– Réceptions
– Relations
– Multiplicité
– Persistance
– Composant
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 24
Charles André - University of Nice-Sophia Antipolis4747
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
attributsnom_attr : type = valeur initiale
opérationsnom_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
Charles André - University of Nice-Sophia Antipolis4848
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)
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 25
Charles André - University of Nice-Sophia Antipolis4949
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éesRelation
Realization
DependencyAssociationGeneralization
Charles André - University of Nice-Sophia Antipolis5050
Exemple d’association
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 26
Charles André - University of Nice-Sophia Antipolis5151
Nommage des associations
• Indication du sens de lecture
Charles André - University of Nice-Sophia Antipolis5252
Nommage des rôles
•Le rôle décrit une extrémité d’une association
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 27
Charles André - University of Nice-Sophia Antipolis5353
Multiplicité des rôles
1 Un et un seul0..1 Zéro ou unM .. N De M à N (entiers naturels)* Plusieurs0 .. * De zéro à plusieurs1 .. * D'un à plusieurs
class Personne {
Compagnie employeur; ... }
Charles André - University of Nice-Sophia Antipolis5454
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
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 28
Charles André - University of Nice-Sophia Antipolis5555
Exemple
Charles André - University of Nice-Sophia Antipolis5656
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.
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 29
Charles André - University of Nice-Sophia Antipolis57
L’agrégation• Forte = Composition
Modélisation de la composition physique
– Multiplicité au max de 1 du coté de l’agrégat
– Propagation automatique
de la destruction
– Agrégation simple
Compagnie
Département
*
1
Le tout
La partie
Charles André - University of Nice-Sophia Antipolis58
Relation : spécialisation/généralisation
• Gérer la complexité
• Héritage
• Arborescences de classes d’abstraction croissante
class Sous-Classe extends Super-classe { ... }
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 30
Charles André - University of Nice-Sophia Antipolis59
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 discontinu partant 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.
Charles André - University of Nice-Sophia Antipolis60
Relation de réalisation• Notation UML : Un trait discontinu partant 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éalise le contrat définit par
l'interface ActionListener.
class SaisirClient
extends JFrame
implements ActionListener
{ ...
public void actionPerformed (ActionEvent e) {
// faire quelque chose }
}
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 31
Charles André - University of Nice-Sophia Antipolis61
Exercice faire le diag de classes public interface Observer {
public void update(Observable o);} public class Observable {
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 class Bilan extends Observable { void setChange() { notify(); } ...
}public class UIGraphe implements Observer {
public void update(Observable o) { Bilan unbilan = (Bilan) o; double compteResultat = unbilan.getCompteResultat();
... } ...}
Charles André - University of Nice-Sophia Antipolis62
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
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 32
Charles André - University of Nice-Sophia Antipolis63
Retour sur les attributs (2)• Notation générale des inlined attributesvisibility / 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.
Charles André - UNSA63
Charles André - University of Nice-Sophia Antipolis64
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
Charles André - UNSA64
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 33
Charles André - University of Nice-Sophia Antipolis65
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.
Charles André - UNSA65
Charles André - University of Nice-Sophia Antipolis66
Retour sur les opérations
66
• Notationvisibility 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
– preconditions state before invocation
– postconditions state after execution
– body conditions constraints on the returned value
– query does not modify the state of the class
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 34
Charles André - University of Nice-Sophia Antipolis67Charles André - UNSA67
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
Charles André - University of Nice-Sophia Antipolis6868
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.
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 35
Charles André - University of Nice-Sophia Antipolis6969
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’associationAttention: 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)
Charles André - University of Nice-Sophia Antipolis70
Classes-associations (2)
Emploi
salairePersonne 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 s1e1
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érentesp1 s1
e1
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 36
Charles André - University of Nice-Sophia Antipolis7171
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.
Charles André - University of Nice-Sophia Antipolis72Charles André - UNSA72
Interfaces (2)
Class that implements
the interface
Class that uses the interface Other notation: ball
(provided interface)
And socket (required
interface)
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 37
Charles André - University of Nice-Sophia Antipolis73Charles André - UNSA73
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
Charles André - University of Nice-Sophia Antipolis74
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
Charles André - UNSA74
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 38
Charles André - University of Nice-Sophia Antipolis75
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.
Charles André - UNSA75
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
Charles André - University of Nice-Sophia Antipolis76
Enumeration
• A data type whose instances form a list of named literal values.
• An enumeration is a user-definable data type.
Charles André - UNSA76
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 39
References
Charles André - University of Nice-Sophia Antipolis78
Official references
• [UML-Infra] OMG “UML 2.0 Infrastructure Specification”, September 2003, OMG Adopted Specification, ptc/03-09-15.
• [UML-Super] OMG “UML 2.0 SuperstructureSpecification”, 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.
Master 2 TSM Janvier 2009
Marie-agnes Peraldi-Frati 40
Charles André - University of Nice-Sophia Antipolis79
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.
Charles André - University of Nice-Sophia Antipolis80
Books (continued)