Conception de Systèmes d’Information – S1 JPmP 1.1 ã Etude de Cas SI d ’un bureau d ’étude Hydraulique Michel TOLLENAERE professeur laboratoire GILCO Dominique

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



1.18

Con

cept

ion

de

Sys

tèm

es d

’In

form

atio

n –

S1

JP mP

Diagrammes



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



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



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.


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


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




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




enregistrer fret

enregistrer passagers



Client

(Système) RESERVER


Spécialisation parl’objet du transport

1.31

Con

cept

ion

de

Sys

tèm

es d

’In

form

atio

n –

S1

JP mP




enregistrer fret




payer

Client

(Système) RESERVER


1.32

Con

cept

ion

de

Sys

tèm

es d

’In

form

atio

n –

S1

JP mP



enregistrer fret




payer

Client

obtenir billets


les liens d’activation du système

(Système) RESERVER


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



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




Client



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




Client



Gestion interface

(Système) RESERVER

Vue AnalyseGestionnaire financier

payer


1.36

Con

cept

ion

de

Sys

tèm

es d

’In

form

atio

n –

S1

JP mP


enregistrer fret




Client



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


Consulter les promotions


<<extend>>

Extension : Systèmes Évolutifs


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


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 »...


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


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


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


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


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),


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


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 ».


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>>


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


1.57

Con

cept

ion

de

Sys

tèm

es d

’In

form

atio

n –

S1

JP mP

Étudiant



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



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


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 »


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


1.63

Con

cept

ion

de

Sys

tèm

es d

’In

form

atio

n –

S1

JP mP


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)


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 )


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


Attente<<idle>>

Actif

Lavage Rinçage SéchageLavage Rinçage Séchage


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


Rinçage Séchage

Fin( programme )

Fin( programme )

Suite( programme )

Fin( programme )

Suite( programme )

Diagramme « hiérarchisé »

Diagramme « plat »

Attente<<idle>>

Actif

...


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


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


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 ;


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


É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


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.


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


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


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.


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.


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 Composants

Structure du Logiciel Diagrammes de Séquences


Diagrammes de États-Transition


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

Documents

Conception de Systèmes d’Information – S1 JPmP 1.1 ã Etude de Cas SI d ’un bureau d ’étude Hydraulique Michel TOLLENAERE professeur laboratoire GILCO Dominique