1.1
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Etude de CasSI d ’un bureau d ’étude
Hydraulique
Michel TOLLENAERE professeur laboratoire GILCODominique RIEU Professeur laboratoire LSR/équipe SIGMAEric BLANCO Maître de Conférence laboratoire GILCOKhadidja GREBICI doctorante laboratoires GILCO / LSR.
1.2
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Conception de Systèmes d ’Information
Cours : Systèmes d ’InformationMichel TOLLENEAR
Dominique RIEU.
1.3
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Notion de modèle
Qu’est ce qu’un modèle ? (Minsky 1968)A* est un modèle de A pour un observateur O
ssi A* aide O à répondre aux questions qu’il se pose sur A.
Système observé
ModèleObservateur
Où sont construites les ailes ?
1.4
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Objet: entité d ’un monde réel ou virtuel, capable de sauvegarder un état (une information) et qui offre des opérations (un comportement) pour observer ou modifier cet état.
Acteur: classe d ’utilisateur du système, personne physique ou morale, entité fonctionnelle ou organisationnelle.
Activité: opération interruptible exécutée durant un état zone d ’activités
Collaboration: interaction entre objets collaborants. Relation: dépendance entre entités. Paquetage: partition du modèle. Cas d ’utilisation: manière dont les acteurs utilisent le système.
notions de base: objet, acteur, collaboration, activité, Evénements, scénarios, états…
1.5
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Un événement est un stimuli externe visible, avec ses réponses. On commence la modélisation dynamique par l'extraction d'un résumé des séquences d'événements ; pour chaque objet il faut établir un diagramme d'états avec les événements entrants et sortants et qui montre les interactions entre objets. On n'établit pas d'algorithme, ce qui relève de l'implantation, si l'événement n'est pas externe. Ces diagrammes sont essentiels pour les systèmes interactifs, contrairement aux systèmes statiques comme les Bases de Données. Il faut aussi noter qu'ils ne sont pas suffisants pour les systèmes temps réel.
Un scénario est une séquence type d'événements, il permet de décrire les interactions courantes pour l'extraction des événements et l'identification des objets cibles. Le suivi des séquences et des états permet d'établir les diagrammes d'états et de les comparer afin d'obtenir la correspondance événement-objet. L'ensemble des diagrammes d'état définit le modèle dynamique.
Un état est une abstraction des valeurs des attributs et des liens d'un objet. Ces valeurs sont groupées selon les propriétés qui affectent le comportement de l'objet. Il faut établir, pour chaque objet non trivial un diagramme d'états qui décrit ses événements d'entrées et de sortie. Un scénario correspond à un chemin dans un tel diagramme. Pour ce faire il faut considérer un objet unique et ses interactions type, ce qui définit un chemin constitué d'un ensemble d'arcs étiquetés par les événements d'une colonne du suivi. L'intervalle entre deux événements correspond à une activité continue ou qui prend du temps ; c'est un état, représenté par un noeud et auquel on peut donner un nom si nécessaire. La modification d'un état par un événement donne lieu à une transition.
ACTIVITE
CHOMAGE
Plus de 60 ans
Plus de 60 ans
Perte d ’emploi recrutement RETRAITE
EXEMPLE
notions de base: objet, acteur, collaboration, activité, Evénements, scénarios, états…
1.6
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
• diagramme de classes
• diagramme d’objets
• diagramme de composants
• diagramme de déploiement
Statique (ce que le système EST)
• diagramme de séquence
• diagramme de collaboration
• diagramme d’états-transitions
• diagramme d’activités
Fonctionnel (ce que le système FAIT)
Dynamique(comment le système EVOLUE)
• diagramme de cas d’utilisation
• diagramme de collaboration
• diagramme FAST
Axes de modélisation d ’un système
1.7
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Révision UML UML: Définition
UML: Bibliographie et sites.
UML: Genèse
pourquoi UML?
UML, modèles et diagrammes, parcours général
Les Données : diagramme de classes - structure statique
Organiser les documents : les packages
Analyser par les Cas d’Utilisation
Compléments sur les langages et concepts
1.8
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
•langage semi formel•analyse et conception orientée objet•une notation• une méthode: « the Unified Software Development Process•outils : rational Rose, objecteering...
1.9
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Bibliographie « MODELISATION OBJET AVEC UML » P.Muller N.Gaertner, Editions Eyrolles
- mars 2000 « UML EN Action : de l’analyse des besoins à la conception en Java »
P.Roques F.Vallée, Editions Eyrolles - février 2000 «Advanced Object-Oriented Analysis & Design Using UML», Odell J., SIGS
Publications, 1997. « UML DISTILLED : A Brief Guide to the Standard Object Modeling Language »
M.Fowler K.Scott, Addison & Wesley - août 1999 « LE GUIDE DE L’UTILISATEUR UML » G.Booch I.Jacobson J.Rumbaugh,
Editions Eyrolles - février 2000 « LE PROCESSUS UNIFIE DE DEVELOPPEMENT LOGICIEL » I.Jacobson
G.Booch J.Rumbaugh, Editions Eyrolles - juin 2000. « UML POUR L’ANALYSE D’UN S.I. : Le cahier des charges du maître
d'ouvrage » C.Morley J.Hugues B.Leblanc, Dunod - février 2000 « Business Modeling with UML : Business Patterns at work »
H.Eriksson M.Penker Wiley & Sons - janvier 2000 « Concevoir des application Web avec UML » , J.Conallen, Eyrolles, sept 2000
1.10
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Bibliographie « Unified Modeling Langage Reference Manual », J.Rumbaugh I.Jacobson
G.Booch, Addison-Wesley, 1998. « UML en Action », Pascal Rocques, Vallée F , Eyrolles, 2000.
1.11
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Des sites...
Des sites en français– //www.uml.crespim.uha.fr/ (site de mulhouse)
– //free.uml.fr/
Des sites industriels– //www.rational.com/uml
– //www.objexion.com/
– //www.softeam.fr/
Des livres sur UML répertoriés par– //www.eyrolles.fr/php.informatique/Ouvrages/liste_ouvrages
1.12
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Genèse d’UML
1995
2002
2000
19991998
1996
1997
OOADBooch
Méthode unifiée 0.8
UML 0.9
OMTRumbaugh...
OOSEJacobson...
AutresMéthodes
UML 1.1UML 1.0
UML 1.3UML 1.2
UML 1.4
UML 2.0
Spécification sur internet
Partenaires
Novembre : AcceptationSeptembre : soumission finalJanvier : soumission OMG
RévisionMineur
Révision
1997
1.13
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Pourquoi UML ? Besoin d’un Langage de Modélisation
– notation claire des diagrammes
– de modèles variés/points de vue
– flexibilité
– unificateur
Besoin d’un Processus de Modélisation (dirigé par les cas d’utilisation)– modèles et vues intégrant
l’architecture
– itératif et incrémental
– non standard mais à ADAPTER...
Pour Documenter– les besoins
– l’architecture
– la conception
– le codage, les tests....
Dans X Environnements de systèmes à support logiciels :– SI de l’entreprise
– Systèmes bancaires, financiers
– Télécoms, transports
– Aérospatiale, scientifique
– Électronique, médical
– Services Web
1.14
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
UML, Modèles et Diagrammes Parcours Général
1.15
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Modèle de Classes qui capture la structure statique
Modèle des Cas d’Utilisation – Use Case, UC – qui décrit les
besoins, les fonctions
Modèle d’Interaction qui représente les scénarios et les flots de
messages
Modèle des États qui exprime le comportement dynamique des
objets, classes...
Modèle de Réalisation qui montre des unités de travail
Modèle de Déploiement qui précise la répartition des processus
Descriptions abstraites pour capturer la sémantique d’un système
Un Modèle = Un point de vue sur le système
1.16
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Diagrammes
Diagrammes
Classes Objets Séquence Collaboration Activités
Cas d'Utilisation États-Transitions Composants Déploiement
1.17
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
lien d’héritage : «est un diagramme»,chacun est une spécialisation de la classe diagramme
Un diagramme est un « langage graphique » de phrases traduisant entre les concepts « éléments du vocabulaire du diagramme », icônifiés aux
nœudsdes relations matérialisées par des arcs du graphe, écrits avec un forme
particulière.L’ensemble donne la syntaxe, graphique du langage associé
Diagrammes
Diagrammes
Classes Objets Séquence Collaboration Activités
Cas d'Utilisation États-Transitions Composants Déploiement
1.18
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Diagrammes
Classes Objets Séquence Collaboration Activités
Cas d'Utilisation États-Transitions Composants Déploiement
Aspects structurels statiques diagramme de classes : classes et relations statiques
diagramme des objets : objets et liens
Aspects fonctionnels et dynamiques
diagramme de cas d’utilisation : acteurs et utilisation du
système
Diagrammes
Ce que le système EST
Ce que le système FAIT
1.19
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Diagrammes
Classes Objets Séquence Collaboration Activités
Cas d'Utilisation États-Transitions Composants Déploiement
Diagrammes
Aspects dynamiques diagramme de séquence : vision temporelle des interactions
diagramme de collaboration : vision spatiale des interactions
diagramme d’états-transitions : comportement des objets
diagramme d’activités : flot de contrôle interne aux opérations
comment le système EVOLUE
1.20
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Diagrammes
Classes Objets Séquence Collaboration Activités
Cas d'Utilisation États-Transitions Composants Déploiement
Diagrammes
Aspects implantation diagramme de composants : codage
diagramme de déploiement : implantation, distribution
Les diagrammes des classes physiques participant aussi à cette description
1.21
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Organiser les documents, Les Packages
1.22
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Structurer : Package Unité de stockage d’un ensemble d’informations variées ayant trait à
une même unité d’information pour l’application modélisée. Appliqué selon
plusieurs points de vue :
package exigencespackage analysepackage conceptionpackage réalisationpackage maintenance
Vue cycle de développement
Pkg-projet
Pkg-exigences
Pkg-analyse
Pkg-maintenancePkg-maintenance
Pkg-maintenance
Pkg-conceptionPkg-conception
«trace»
Pkg-réalisationPkg-réalisation
Pkg-réalisation«realise»
1.23
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Graphisme Chaque package peut avoir divers modèles (UC, Classes, textes, ….)
lesquels constituent une unité de documentation pour le niveau auquel on se trouve….– Analyse
– Conception
– Réalisation
Structurer : Package
Gérer une compagnie d'aviation
Gérer les réservations
Gérer la politique commerciale
Gérer le réseaux
Gérer le parc
1.24
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Analyser par les Cas d’Utilisation,
Cas d’Utilisation,Scénarios : Collaborations et Séquences
1.25
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Diagrammes de Cas d’Utilisation Un CU est : une réponse à la question « dans quel cas tel acteur utilise-t-il le système?. C ’est un ensemble d ’interactions entre acteur et système. une technique d ’expression des besoins mise en œuvre par Ivar Jacobson (objectory). une manière spécifique d’utiliser un système représenté dans un diagramme de CU faisant référence aux acteurs, i.e: « choses » externes au système qui communiquent avec ce dernier (principaux, secondaires, matériels ou non) et aux relations (communication, utilisation, extension) de propriétés : - exclusivité les uns des autres, le système est dans une situation donnée pour un acteur donné et à un instant donné. - couverture d ’une utilisation complète depuis la connexion jusqu ’à la déconnexion.
L’analyse d’un cas d’utilisation par des scénarios : Diagrammes de Collaboration (modèles organisationnels) Diagrammes de Séquence (modèles chronologiques) pour des regroupements et la mise en évidence des objets et des cas d’utilisation
1.26
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Modéliser le comportement d’un : – élément,– système,– sous-système,– classe.
Un acteur fait avec le système qui lui offre ce service :– « un client fait un virement »
Ce que fait l’élément et NON Comment il le fait
Diagrammes de Cas d’Utilisation
« généralise »
Identification
ClientVirement
<<include>>
Client distantVirement minitel
1.27
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Exemple1 : Réserver sur un vol à une date donnée
Le client interroge le système, soit en passant dans une agence, soit par un système télé-informatique (minitel ou internet) pour s’assurer de pouvoir faire la réservation souhaitée.
La réservation peut concerner un déplacement de passagers (un ou plusieurs) ou une demande de transport de fret.
Une solution réalisable étant trouvée, il enregistre la réservation (nom des passagers ou volumes et caractéristiques du fret) et paye par le moyen adapté à l’environnement (liquide, chèque, carte de crédit).
Le ou les billets correspondants lui sont délivrés (directement, à l’agence, par la poste, par mise à disposition à l’aéroport pour télépayement ou aussi par impression de bons de transports sur connexion internet.
Diagrammes de Cas d’Utilisation
ClientRéserver
une note est attachéeà tout UC, pour définirson rôle et son contenu
1.28
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Exemple 1 – Requirements
Diagrammes de Cas d’Utilisation
Interroger au guichet
Interroger par le net
Interroger possibilité-vol
Client
(Système) RESERVER
Vue analyse des besoins :un acteur, le client
Le diagramme d’UC du package RESERVER, décompose l ’UC RESERVER
Généralisation/spécialisation selon les « modes d ’accès »
1.29
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Diagrammes de Cas d’Utilisation – Exemple 1 : Requirements
Interroger au guichet
Interroger par le net
Interroger possibilité-vol
enregistrer réservation
Client
(Système) RESERVER
Vue analyse des besoins
1.30
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Diagrammes de Cas d’Utilisation – Exemple 1 : Requirements
Interroger au guichet
Interroger par le net
enregistrer fret
enregistrer passagers
Interroger possibilité-vol
enregistrer réservation
Client
(Système) RESERVER
Vue analyse des besoins
Spécialisation parl’objet du transport
1.31
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Diagrammes de Cas d’Utilisation – Exemple 1 : Requirements
Interroger au guichet
Interroger par le net
enregistrer fret
enregistrer passagers
Interroger possibilité-vol
enregistrer réservation
payer
Client
(Système) RESERVER
Vue analyse des besoins
1.32
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Interroger au guichet
Interroger par le net
enregistrer fret
enregistrer passagers
Interroger possibilité-vol
enregistrer réservation
payer
Client
obtenir billets
Diagrammes de Cas d’Utilisation – Exemple 1 : Requirements
les liens d’activation du système
(Système) RESERVER
Vue analyse des besoins
1.33
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Exemple 1 – AnalyseDiagrammes de Cas d’Utilisation
Vue Analyse (raffinement)spécification
Interroger au guichet
Interroger par le net
Client
Gestionnaire des volsInterroger possibilité-vol
Gestion interface
(Système) RESERVER
Sous-systèmes externes
Généralisation/spécialisation selon les « modes d ’accès »
1.34
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
enregistrer fret
enregistrer passagers
Interroger au guichet
Interroger par le net
Client
Gestionnaire des volsInterroger possibilité-vol
enregistrer réservation
Gestion interface
(Système) RESERVER
Vue Analyse
Spécialisation parl’objet du transport
Diagrammes de Cas d’Utilisation – Exemple 1 : Analyse
1.35
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
enregistrer fret
enregistrer passagers
Interroger au guichet
Interroger par le net
Client
Gestionnaire des volsInterroger possibilité-vol
enregistrer réservation
Gestion interface
(Système) RESERVER
Vue AnalyseGestionnaire financier
payer
Diagrammes de Cas d’Utilisation – Exemple 1 : Analyse
1.36
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Diagrammes de Cas d’Utilisation – Exemple 1 : Analyse
enregistrer fret
enregistrer passagers
Interroger au guichet
Interroger par le net
Client
Gestionnaire des volsInterroger possibilité-vol
enregistrer réservation
Gestion interface
(Système) RESERVER
Vue AnalyseGestionnaire financier
payer
obtenir billets
des acteurs secondaires
des acteurs
secondaire
principal
1.37
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
relation d’extension : une évolution demandée avec indication de l’endroit
où elle vient s’insérer
Interroger possibilité-vol
Consulter les promotions
Interroger par le net
<<extend>>
Extension : Systèmes Évolutifs
Diagrammes de Cas d’Utilisation
extension points : commande complémentaire - les bonnes occases- après rechercher un vol.
1.38
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Exemple 1 – Conception
Diagrammes de Cas d’Utilisation
Télé-système Agence
Gérer paiements
ss-système Gérer-réservation
Validerla commande
Enregistrerdemande
Enregistrerpassager
Enregistrerfret
Agent-réservation
Éditer billet
Client
Réserver
<<include>><<include>>
<<include>>
<<include>>
<<realize>>
Système de Réservation
1.39
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Relations dans les Diagrammes d’UC Pas de Composition-Décomposition: (pour le raffinement) mais un UC se décrit en détail à travers un
package associé à l ’UC à détailler et décrit par des diagrammes d’UC définissant le contenu du package.
Inclusion « include »: (pour la réutilisation) A inclut B
& l’utilise relation de dépendance entre UC d’un même
diagramme; l’UC, inclus, peut être réutilisé dans d’autres
diagrammes ; (exemple type : Réserver, Éditer billet)
Extension « extend »: (pour l’extensibilité) B étend A,
en ... relation de dépendance entre UC d’un même
diagramme; l’UC, qui « étend », doit avoir un point
d’insertion dans l’UC « étendu » ; (exemple :
« Consulter les promotions »)
Généralisation : (pour les mécanismes d’héritages et de versions) relation hiérarchique (une spécialisation
assure la fonction de l’UC parent) qui permet d’avoir plusieurs environnements pour le même objectif.
(exemple : Interroger possibilité-vol et Interroger par le net…)
Sans oublier entre les niveaux les dépendances de « trace » ou « réalisation »...
Diagrammes de Cas d’Utilisation
Cas d'utilisation A Cas d'utilisation B
<<include>>
Cas d'utilisation BCas d'utilisation A
<<extend>>
Lorsque la description textuelle fait apparaître des interactions
communes à plusieurs cas.Pour éviter la ré-écriture.
Permettre d ’étendre les interactions et donc les
fonctionnalités décrites par les interactions
typique d ’une situation optionnelle.
1.40
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Diagrammes d’Interaction
Ensemble des objets, acteurs, systèmes qui collaborent pour contribuer
à la réalisation d’un U.C.
A l’expression d’une collaboration est associé un diagramme de
collaboration qui met en évidence les parties de système, acteurs et
objets collaborants
Deux Types : Collaboration ou Séquences
1.41
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Diagrammes de Collaboration
Utilisé pour décrire des scénarios du modèle : formes de séquences des vies relationnelles des objets
Utilisé pour décrire les interactions entre objets– ensembles de messages échangés entre les objets,
– liens créés par ces échanges et leurs successions et/ou alternatives
– messages (orientés), flux de données
Syntaxe d’un OBJET
1-objet:
joël:ETUDIANT
:ETUDIANT
un objet anonyme de la classe étudiant
l ’objet, nommé Joël de la classe ETUDIANT
objet, nommé 1-objet pas de classe associée
Modéliser les Flux de Contrôle
1.42
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Ce scénario traduit ce qui se passe quand tout est OK à étudier, les autres cas : pas de “vol” et pas de “place”
Dans ce modèle, on ne se préoccupe pas de l’aspect “gestion d’interface-client”, serveur d’agence ou de télécommunication, gestionnaire du dialogue, qui serait seul à communiquer avec les sous-systèmes du système de réservation. C’est ici une vue purement “fonctionnelle”
Séquencement chronologique sans notion d’écoulement de temps
Message action : VerbeChaque message crée un lien entre les objets, une relation entre leurs classes
Un Use Case est un « classifier », unité de regroupement, de Scénarios
Diagrammes de Collaboration
Exemple :
f : Gestionnaire financier
b : Billets
7: éditer réservation
c : Client
r : Réserve
8: demander billet
: Gestion interface1: demander réservation
2: réserve
3: réservation possible
4: évaluer réservation
5: afficher prix à payer
6: payer
9: m à dispo-billet
1.43
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
1 : demander réservation
2.0 [choix = OK]: confirme-réservation
Exprimer une alternative :
2.0 [non(choix = OK)]: propose-alternatives
2.1 [non(choix = OK)]: choisir-alternative
2.2 [non(choix= OK)] : confirme-alternative
Même numéro de séquence de l’action suivie d’une condition.Pour la cohérence du modèle, il faut que les conditions soient exclusives et totalement définies, mais rien dans les outils ne valide cela, pour l’instant
Pour la lisibilité, il est souvent opportun de multiplier les modèles descriptifs chacun d’une situation, càd d’un scénario pour le cas « normal » et les exceptions
Diagrammes de Collaboration
c : Client
r : Réserve
1.44
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Diagramme de Séquence
Utilisé pour modéliser des scénarios du modèle entre des objets Utilisé pour décrire les interaction entre objets selon un point de vue temporel :
– ensembles d’opérations échangées entre les objets, liens, messages (orientés)– séquencement chronologique avec la notion de “vie de l’objet”– écoulement du temps vertical/échange de message horizontal avec du parallélisme
d’existence, des alternatives ...
Deux utilisations :– documentation des cas d’utilisation (événements, ...)
– représentation précise des interactions entre objets (messages, ...)
Messages synchrones, asynchrones, délai de transmission, contraintes temporelles...
Création, destruction d’objets / durée d’activation d’un objet / boucles, conditionnelles
Utilisé aussi pour documenter la dynamique des processus au niveau de la conception
physique du système
Modéliser les Flux de Contrôle selon le Temps
1.45
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
:Unobjet :autreobjet
Message asynchrone
Retour explicite
:Unobjet :autreobjet
Message synchrone
Retour implicite
:Unobjet
:autreobjet
X
création
destruction
Diagrammes de Séquence
1.46
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
c : Client r : Réserve f : Gestionnaire financier
b : Billets : Gestion interface
demander billet
éditer réservation
demander réservationréserve
réservation possible
évaluer réservation
afficher prix à payer
payer
m à dispo-billet
Exemple :
Un dual du diagramme de collaboration avec insistance sur le temps
Diagrammes de Séquence
1.47
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Syntaxe Entête des colonnes :
– Objets
– Acteur, si il est acteur de l’UC dont le DS est un scénario (rattachement)
Message : deux types– message synchrone : A attend la réponse de B
– message asynchrone : A envoie un signal et ne s’en occupe plus
Alternatives entre les mêmes objets
A B
Diagrammes de Séquence
1.48
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Diagrammes de Classes – DonnéesClasses, Attributs, Opérations, Associations,
Agrégation, Composition, Héritage
1.49
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Classes - Propriétés Les classes : ensemble d’objets ayant les mêmes attributs, les mêmes opérations,
les mêmes relations et la même sémantique
Responsabilités : représentées comme une note ou dans la doc de la classe
Vol
numVolhdephar
définir-périodes()définit la desserted’une ligne (ville de départ, ville d’arrivée) selon un horaire donné
Représentation graphiques
nom de classe (unique)
attributs, typés ou non, simples ou multiples, avec valeur initiale éventuelle
opérations() avec ou sans leurs paramètres
Avion
Une classe peut être présentée sans ses attributs e/ou sans ses opérations.
1.50
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Classes - Instances
Une classe = un type + un conteneur d’objets de ce type
« instancie »
« instancie »
Grenoble-Paris1 :VOL
GREPA015h376h41
Paris-Grenoble1 :VOL
PAGRE017H158H20
Vol
numVolhdephar
définir-périodes()
Donc, il faut « classer », càd, reconnaître les familles d’éléments, « ensembles » cohérents leur rôle, « responsabilité » les données associées « attributs » les actions que font les éléments « actifs » les actions que l’on fait sur les éléments « passifs » les « signaux » qu’ils envoient
les « opérations »
1.51
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Responsabilités Utiliser en phase d’analyse de besoins
– pour décrire le rôle des objets de la classe par rapport à l’environnement
– pour se concentrer sur le « pourquoi » avant d’aborder les structures : attributs
– mettre en évidence les relations fonctionnelles pour l’utilisateur
Concerne particulièrement les «objets clients»– un badge, identifie une des personnes autorisées
– un lecteur, veille & détecte la présentation d’un badge et en lit le code informe le système de contrôle et affiche le résultat du contrôle …
Diagrammes de Classes
Exemple Contrôled’Access
1.52
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Propriétés Statiques - Attributs
Concernent la structure des données Une syntaxe
– [visibilité] nom [multiplicité] [ : type ][= valeur-initiale] – [ {chaîne-propriété} ]
Trois valeurs de visibilité :– +, public (visible de toute classe),
– #, protégé (visible dans la classe et ses sous-classes),
– -, privé (visible dans la classe uniquement),
Diagrammes de Classes
1.53
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Propriétés Dynamiques - Opérations Une syntaxe et quelques propriétés
– [visibilité] nom [ (liste-paramètre) ] [ : type-retour ]
– [ {chaîne-propriété} ]
Des propriétés de contrôle de flots dynamiques :– sequential : coordination extérieure pour que les appels soient séquentiels (1à1)
– guarded : contrôle d’intégrité sémantique, pas d’appels concurrents sur les gardes
– concurrent
Diagrammes de Classes
1.54
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Exemples
Les opérations de création d’un objet sont implicites car « standard ».
Diagrammes de Classes
Formation
nom : String
ajouter(nom : String) : voidvalider(nom : String) : void
Inscription
date : Date
Sport
nom
ajouter()invalider()
Étudiant
nom : Stringnuméro : Integer = 0age : Integergrade
ajouter(Nom : String) : voids-inscrire() : Boolean
Formation : cycle d’étude auquel les étudiants peuvent s’inscrire dans le cadre de l’institution que l’on gère.Créée ou invalidée par l’administration après habilitationArchivée pour l’historique de la vie de l’établissement
Note
Lors de la création d’une classe, donner sa definition comme une Note ou avec la Documentation de la Classe
1.55
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Variétés Spécifiques «stéréotype» : type de méta-classe qui sert de «définition de type» pour une famille
de classe– <<boundary>>, <<control>>, <<entity>>...
– «interface» : associée à une classe, elle décrit un comportement visible Ne contient que des opérations (un type de stéréotype)
POSterminal
I-Store
Store
storeId : IntegerPOSlist : list
create()login()find()getPOStotals()updateStoreTotals()get()
<<uses>>
POSterminal
I-Store
getPOStotals()updateStoreTotals()
get()
StorestoreId : IntegerPOSlist : list
create()login()find()getPOStotals()updateStoreTotals()get()
<<uses>>
Diagrammes de Classes
Une classe « interface » est une
Classe abstraire.
Autre représentation
1.56
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Les Relations Lien entre les objets ou les classes qui crée des dépendances fortes entre les classes
du diagramme Trois types de liens de base, statiques, structurants :
– association
– agrégation, composition
– héritage
Aussi, des liens de dépendance, plus faibles concernant la conception/réalisation du modèle de base ce sont les dépendances :– « réalise » entre classe et une interface
– « réalise » entre des composants logiciels et une classe
– « trace » entre classe « utilisateur » issue de l’analyse et
– classe « composant » qui est le résultat de la conception du logiciel
Diagrammes de Classes
1.57
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Étudiant
nom : Stringnuméro : Integer = 0age : Integergrade
ajouter(Nom : String) : voids-inscrire() : Boolean
Formation
nom : String
ajouter()valider()
1..41..n 1..41..n
Inscription >+inscrits
Diagrammes de Classes – Les Relations
Associations
!La formation à laquelle l’étudiant est inscrit ne figure pas en « doublon » dans les attributs de Étudiant C’est la relation qui traduit la propriété.
Rôle (pas nécessairement des deux côtes)
Nom de la association (en italique)> Comment lire l’association
Cardinalités (inversées)
1.58
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Classe Associative
Inscriptiondate : Date Action pour un étudiant de
s’inscrire à une formation de l’établissement, créé et daté par la scolarité lors de cette inscription.Archivé pour l’historique de la vie de l’étudiant
Étudiant
nom : Stringnuméro : Integer = 0age : Integergrade
ajouter(Nom : String) : voids-inscrire() : Boolean
Formation
nom : String
ajouter()valider()
1..41..n 1..41..n
Inscription >+inscrits
Classe associative : un objet de la classe est identifié par le « couple » d’objets liés par l’association
Diagrammes de Classes – Les Relations – Association
1.59
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Généralisation-Spécialisation
Diagrammes de Classes – Les Relations
Instance-Vol
associerAvion()
Instance-Passres1res2
réserver1()réserver2()associerAvion()
Instance-Fretfret
reserver-fret()associerAvion()
Héritage
Polymorphisme
Généralisation : plus général…
– super-classe
– sous-classe (hérite de)
Spécialisation : plus spécial
Généraliser :– factoriser attributs, opérations,
contraintes
Spécialiser :– extension COHERENTE…au
sens ensembliste...
1.60
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Héritage Multiple
Animal
Mammifere Poisson Carnivore Herbivore
Felin
Diagrammes de Classes – Les Relations – Généralisation-Spécialisation
1.61
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
« Classe Abstraite » Classe, regroupant des propriétés communes à ses sous-classes
Pas d’instances propres, sert juste à la « factorisation », « abstraction »
Diagrammes de Classes – Les Relations – Généralisation-Spécialisation
Personnenom : Stringprénom : Stringn-insee : Integeradresse : String
identifier()
Employesalaire : Doubleindice : Double
identifier()
Etudiant
n-inscription : Integer
identifier()
Nom en italique
1.62
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Quelques Considérations Sens : « est un » , « est une sorte de » , « est de la famille des »
Propriétés : – non réflexive : A n’hérite pas de lui-même ; il EST lui-même
– non-symétrique : B sous-classe de A, interdit A sous-classe de B (pas de cycle)
– transitive : C sous classe de B, B sous-classe de A => C sous-classe de A
A
A
B
A
B
C
Diagrammes de Classes – Les Relations – Généralisation-Spécialisation
1.63
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Diagrammes de Classes – Les Relations
Filière Module1..n1 1..n1
Filière Module1..n1..n 1..n1..n
Type de relation orientée, du tout vers les parties
Forte : Composition
Faible : Agrégation
Agrégation
Un module appartient à une seule filière (et disparaît avec elle)
Les modules sont partagés par plusieurs filières
composition = agrégation forte
pas de partage
mort simultanée
Tout Partie
1.64
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Dépendances Réalisation
La dépendance « type de dépendance »
– bind , entre des classes paramétrées et les paramètres effectifs
– derive, attribut dérivé : âge dérivé de date-de naissance
– friend, visibilité du but par la source
– instanceOf, instantiate pour des relations classe/objet
– powertype dans une relation enfants d’un même parent
– refine par raffinement d’abstraction de classe (analyse...implémente)
Diagrammes de Classes
RéservationJava-Réserve
1.65
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Dynamique des Classes Diagramme d’ État-Transition, Diagramme
d’Activités.
1.66
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Diagrammes d’États-Transitions Automates d’états finis de type State Charts de Harel (visual Formalism
for complexe systems, Sciences of Computer Programming vol 8). Exprime contraintes dynamiques Abstraction des comportements possibles
– des objets d’une classe (le plus souvent...)– d’un U.C.– d’un système
Un état est caractérisé par une notion de durée et de stabilité Automates déterministes avec un état initial et des états finaux Transitions déclenchées par des événements
– avec conditions, actions et activités
Décomposition disjonctive et composition conjonctive d’états Historique
Etat initial
Etat intermédiaire
Etat final
ACTIVITE
CHOMAGE
Plus de 60 ans
Plus de 60 ans
Perte d ’emploi recrutement RETRAITE
1.67
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Exemple 1
Classe
Diagrammes d’États-Transition
Diagramme d’États-Transition pour la Classe Station-Lavage
Attente<<idle>>
Lavage Rinçage Séchage
Fin( programme )
Suite( Programme ) Suite( programme )
Fin( programme )
Fin( programme )
Démarrer( programme )[ présence(véhicule) ]
Station-Lavage
1.68
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
événement
transitions
états
Attente<<idle>>
Lavage Rinçage Séchage
Fin( programme )
Suite( programme ) Suite( programme )
Fin( programme )
Fin( programme )
Démarrer( programme )[ présence(véhicule) ]
garde
démarrer(programme) est un « signal » du Système de commande
[présence(véhicule)] est une « garde », condition qui est évaluée pour
accepter ou refuser la transition.
Le développement des diagrammes d’états entraîne la mise à jour en
cohérence des diagrammes de classes (statique)
Syst-Commande « signal »démarrer(programme)fin(programme)
Classes
Station-Lavage
Diagrammes d’États-Transition – Exemple 1
1.69
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
En regroupant toutes les transitions « fin programme »
on met en évidence un sur-état Actif
événement
Diagrammes d’États-Transition – Exemple 1
Attente<<idle>>
Actif
Lavage Rinçage SéchageLavage Rinçage Séchage
Démarrer( programme )[ présence(véhicule) ]
Fin( programme )
Syst-Commande « signal »démarrer(programme)fin(programme)
Classes
Station-Lavage
1.70
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Attente<<idle>>
Lavage
Démarrer( programme )[ présence(véhicule) ]
Rinçage Séchage
Fin( programme )
Fin( programme )
Suite( programme )
Fin( programme )
Suite( programme )
Diagramme « hiérarchisé »
Diagramme « plat »
Attente<<idle>>
Actif
...
Démarrer( programme )[ présence(véhicule) ]
Fin( programme )
Actif
Lavage Rinçage SéchageLavage Rinçage Séchageles sous-états héritent des transitions de sortie
1.71
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
État “historique” – indique un retouravec mémorisation
Diagrammes d’États-Transition – Exemple 1
Actif
Lavage Rinçage SéchageH
Lavage Rinçage SéchageH
Attente<<idle>>
Fin( programme )
ProblèmeDémarrage( programme )[ présence(véhicule) ]
Histoire des sous-états dans un état
1.72
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Concepts 1 État : (d’un objet ou d’une classe) : ensemble des valeurs, des attributs,
des relations et des opérations exécutables (pour l’objet et ceux qui sont visibles par lui)– nom: nomme l’état, mais il peut être anonyme ; pas obligatoire– actions : d’entrée/sortie, opérations instantanées, non interruptive
exécutées à l’entrée ou la sortie de l’état, (au passage de la transition)– transitions internes : transitions qui ne changent pas l’état, et s’exécutent
sous le contrôle des sous états– sous états : états contenus dans l’état impliquant des sous-états, disjoints
(séquentiels) ou concurrents– pseudo états : il existent trois :
état initial : correspond à l’état implicite “le diagramme d’états est crée” état final : correspond à l’état implicite “le diagramme d’états est détruit” état “indicateur d’historique” : une transition vers cet état déclenche une transition au
dernier sous-état atteint lors du dernier passage à cet état
Diagrammes d’États-Transition
1.73
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Concepts 2 État “idle”, inactif, attente : état neutre de l’objet après une transition, il attend
d’autres événements pour effectuer une transition. État actif : état actif càd une activité se déroule pendant que l’objet est dans cet état,
en attendant un événement déclencheur d’une transition (avec durée) Activité - do/activity (faire/activité)
– Ensemble d’opérations qui peuvent se produire pendant que l’objet est dans un état. Ex.: do/op1(a); op2(b); op3(c)
– Séquence d’actions (chaque action est non interruptive)
– Une activité met un certain temps à s’exécuter.
– Elle est interruptive (entre deux actions) par un événement déclencheur.
– Elle peut faire référence à un autre diagramme d’état qui la décrit ;
Diagrammes d’États-Transition
Transition d’État
Événement[Garde]/Action
États
Initial Final
Nom
Nom de l’Étatentry: action d’entréeentry: ^class.événementexit: action de sortirexit: ^ class.événementdo: activitédo: ^class.événement
1.74
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Concepts 3 Les événements provoquant les transitions sont classables suivant 4 natures :
– change event :changements de valeur, atteintes de limites
– time event : date, jour-heure, fin ou début de période
– signal : signaux venant d ’une autre classe (classe-active) avec ou sans paramètre
– call event : appel de procédure qui déclenche une action qui fait transiter…
Comment les reconnaître ? Et trouver les états : – en examinant dans les scénarios, les appels de procédure inter-objets ou les signaux
envoyés
– en regardant les qualificatifs associés aux objets dans ces mêmes scénarios
– en examinant les attributs des objets et leurs valeurs critiques
– en établissant une trace des divers points importants du «calendrier » qui rythme la vie du système et des objets
Diagrammes d’États-Transition
État : une situation assez stable pour « durer » !
1.75
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Exemple 2Diagramme d’États-Transition pour une Classe Fax
Diagrammes d’États-Transition
super-état
actions
transitions sans déclencheur
sous-état
état final (fin du scénario)état initial (début du scénario)
Attendre<<idle>>
Transmission
Réception
Connecté
En-traitement
do/ recevoir
Effacer
entry/ décrocherexit/ déconnecter
Connecté
En-traitement
do/ recevoir
Effacer
Entête-Ok
[ parité-Faux ]
raccrocher
Erreur / imprimer-rapport
sonnerie
Envoie-fax
1.76
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Diagrammes d’Activités
Autre diagramme pour exprimer de la dynamique un organigramme qui présente le flux de contrôle entre des activités
Utilisé principalement pour la modélisation d’étapes séquentiels (ou concurrents...) d’un processus de calcul
Modélise le comportement interne d’une méthode (d’un seul objet) ou d’un cas d’utilisation (d’une société d’objets)
Une variante du diagramme d’états transition
– Diagramme d’États Transition : mis en valeur des états et des transitions
– Diagramme d’Activités : mis en valeur des activités et des transitions
Zones d’activités
– pour exprimer en analyse de besoin, les grandes étapes du système
– pour montrer globalement des interactions avec le temps et les contraintes logiques
1.77
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
A cause de la nature procédurale des opérations (la plupart des événements
correspondent simplement à la fin de l’activité précédente) la distinction
systématique entre état, activité et événement est parfois inutile Les
diagrammes d’activités offrent une manière simplifiée pour la visualisation
des activités.
Par rapport aux Diagrammes d’Interaction, que mettent en valeur le flux de
contrôle entre les objets, les Diagrammes d’Activités mettent en valeur le
contrôle d’une activité vers une autre.
Les Diagrammes d’Activités peuvent exister pour qu’on puisse d’une manière
indépendante , visualiser, spécifier, construire et documenter la dynamique
d’un ensemble d’objets peuvent aussi servir à modéliser le flux de contrôle
d’une opération.
Diagrammes d’Activités
1.78
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Concepts 1 État d’Action et État d’Activité :
– États d’Action : représentent un calcul exécutable atomique (ne peut pas être divisé) des états du système que représentent chacun l’exécution d’une action.
Un État d’Action ne peut pas être décomposé Un État d’Action est atomique : des événements peuvent se
produire sans que l’action réalisée par l’état soit interrompue.
La durée d’exécution de l’action dans un état d’action est considéré non significative.
– États d’Activités : sont des états dont l’activité peut éventuellement être représentée par d’autres diagrammes d’activités un État d’Action peut être considéré comme un cas spécial d’État d’Activité qui ne peut plus être divisé.
Un État d’Activité peut être décomposé Les États d’Activités ne sont pas atomiques : ils peuvent être
interrompus par des événements La durée d’exécution de l’activité dans un État d’Activité
peut être mesuré, elle est significative
Étudier devis
index:= index + 1
Action simple
Expression
Début Construction()entry / bloquer()
Action d’entre
Contrôle Finance(f)
Sous-diagramme
Diagrammes d’Activités
1.79
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Concepts 2 États Initial et Final : utilisés au même sens que dans les
Diagrammes d’États Transition. Transition : quand l’action ou activité d’un état se termine, le
flux de contrôle passe immédiatement à l’activité suivante ce flux est indiqué avec les Transitions que permettent de montrer le chemin entre les états d’action ou d’activité.
Division Conditionnelle du Flux : est utilisée pour spécifier les différents chemins qui peut prendre le flux à partir de l’évaluation d’une expression booléenne.
– Un division doit avoir une transition entrante et une ou plusieurs transitions sortantes
– Chaque transition sortante doit avoir une expression booléenne qui est évalue lorsque la division est atteinte les conditions de garde de chacune de ces transitions doivent être mutuellement exclusives et doivent couvrir toutes les possibilités pour maintenir le déterminisme
– On peut utiliser le mot clef else pour indiquer la transition que doit être suivie dans le cas où aucune autre n’est vrai
État d’ActionÉtat 1
État 2
État initial
État final
Transition
Ordre débutdes travails
Attribuer taches
Replanifier
[matériel prêt]
[matériel pas prêt]
Condition de garde
division
Diagrammes d’Activités
1.80
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Concepts 3 Synchronisation de Flux
Concurrents: – Utilisées pour représenter la division et
le regroupement de flux de contrôle parallèles.
– Une fourche concurrente représente la division du flux de contrôle au dessous de la division, les activités associées aux flux se développent en parallèle.
– Une jonction concurrente peut avoir deux ou plus transitions entrantes et généralement une unique sortante après que toutes les transitions aient atteint la jonction, la transition de sortie est réalisée.
Diagrammes d’Activités
JonctionConcurrente
FourcheConcurrente
Action deResfrier
ArreterChaufage Aerer
MesurerTemperature
1.81
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Concepts 4 Travées :
– Est une division que peut être appliquée à un Diagramme d’Activités pour représenter les différents responsabilités d’un mécanisme ou d’une organisation.
– Chaque responsabilité est assuré par un ou plusieurs objets et chaque action d’état ou activité est attachée à un une travée en particulier.
– Chaque travée est divisée avec des lignes verticales.
– Les transitions peuvent traverser les travées.
Flot d’Objet : – Est un ensemble composé d’une relation de dépendance entre un objet et l’action ou
l’activité à l’origine de sa création, destruction ou modification.
– Présente les objets qui participent au flux de contrôle d’un Diagramme d’Activités.
– Peut présenter pour les objets qui participent du diagramme ses états et les valeurs de ses attributs.
– Des objets peuvent être connectés à différentes actions d’états ou d’activités son état est représenté pour faire la différence
– Des flots d’objets peuvent être utilisés avec de diagrammes d’activités simples ou en travée.
Diagrammes d’Activités
1.82
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Diagrammes d’Activités – Concepts 4 : Travées et Flot d’Objets
Commanderproduit
Traitercommande
Sortirarticles
c : Commande
Expediercommande
Recevoircommande
Facturerclient
c : Commande
f : FacturePayerfacture
Cloturercommandef : Facture
Client Ventes Entrepot
[en cours]
[traitée]
[due]
[payée]
flot d’objet
travées
objet
état
flot d’objet
1.83
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
DEMARCHE ORIENTEE OBJET Le domaine d ’étude n ’est pas le système d ’information dans sa globalité
(l ’organisation n ’est pas prise en compte). Il est réduit au système informatique. La démarche proposée (à travers UML) vise donc à spécifier et à implanter les fonctions informatisées du système d ’information.
A.Expression des besoins
A.1 Cas d ’utilisation (Use Case) à partir des fonctions attenduesdu système informatique, établir un diagramme de cas d ’utilisation.A.2 Diagramme de séquence de haut niveaupour chaque cas d ’utilisation, décrire le scénario principal et éventuellement les scénarios secondaires en langue naturelle
B.Analyse
B.1 diagramme de séquence intermédiaire«pour chaque diagramme de séquencesde haut niveau construire le diagrammede séquences intermédiaire qui exprimeles demandes de services fondamentales entre objets.B.2 diagramme de classe intermédiaireconstruire progressivement le diagramme de classes: classes, attributs et associations.Ajouter les classes application et sesopérations (cas d ’utilisation définis du système.
C.conception
C.1diagramme de Séquences Détaillé à chaque diagramme se séquences interm.Construire le D S D: exprimer les demandesde services détaillées entre objets et spécifierleurs paramètres.C.2 Diagramme de Classe Détaillé compléter le diagramme de classe conformément aux Diagrammes de SéquencesDétaillés.C.3 Diagramme de Classes Généraliséprincipes d ’abstraction et de polymorphisme.C.4 Langage de conception
D.Implantation
1.84
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Démarche Orienté Objet
Les étapes expression des besoins, analyse et conception sont menées de manière cyclique
où les diagrammes d ’état-transition, d ’activité, de séquences… permettent d ’affiner le système informatique(selon des points de vue différents)
en introduisant plus de détailles concernant les rôles, les objets, les liens… et par conséquent élargir le périmètre du SI.
Conclusion
1.85
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Etude de Cas
1.86
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Décrire la Réalisation et son Implantation
Diagrammes de Composant, Diagrammes de Déploiement
1.87
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Diagrammes de Composants Fournit une vue statique (l’architecture logicielle) représentant la mise en oeuvre d'un
système, dessiné sous la forme d'un graphique de composants logiciels connectés par des relations : dépendance, généralisation, association et réalisation.
Éléments : composants (avec plusieurs stéréotypes) et interfaces.
Utilisés pour définir les dépendances et relations entre objets à un niveau “supérieure” à celui du diagramme de classes les AGLs permettent de créer un lien entre les classes du modèle logique et les composants.
Modélisent la structure du logiciel et montrent les dépendances entre le code source, le code binaire et les composants exécutables, de sorte que l'impact d'une modification puisse être évalué Les dépendances entre composants permettent notamment d'identifier les contraintes de compilation et de mettre en évidence la réutilisation de composants.
Le composants peuvent être organisés en packages, qui définissent des sous-systèmes.
Sybase® - PowerAMC™ - Modèle Orienté ObjetGuide de l'utilisateur Version 9.0 - Janvier 2002
1.88
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
ExempleDiagrammes de Composants
Cours UML : UML, le langage de modélisation objet unifié http://uml.free.fr/index.html
1.89
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
Diagrammes de Déploiement Architecture matérielle et répartition logicielle
Éléments : des nœuds (ressources matérielles) et des relations de dépendance et d’association aussi des composants qui doivent résider sur un nœud et de packages.
Des Diagrammes de Classes centrées sur les nœuds d’un système
Stéréotypes utilisés pour les nœuds : <<processeur>>, <<mémoire>>, <<dispositif>>
Connections bi-directionnelles avec cardinalités des nœuds et des connections
Diagrammes de Classes
Diagrammes de Composants
Structure du Logiciel Diagrammes de Séquences
Diagrammes de Collaboration
Diagrammes de États-Transition
Diagrammes d’Activités
Comportement du Logiciel
Diagrammes de DéploiementA la frontière matériel/logiciel du système pour planifier la topologie des
processeurs et des périphériques sur lesquels le système tourne
1.90
Con
cept
ion
de
Sys
tèm
es d
’In
form
atio
n –
S1
JP mP
ExempleDiagrammes de Déploiement
Cours UML : UML, le langage de modélisation objet unifié http://uml.free.fr/index.html