La modélisation des SI

Hela Masri

La modélisation

Objectifs

Importance

2. Les 4+1 vues

3. Les niveaux d’abstraction

4. Mécanismes généraux UML

Vues multiples (aspects d'un système logiciel)

Vue du plombier

Vue de l'électricien

Vue du locataire

Vue du maçon

Vue du notaire

Vue du propriétaire

Vue de l'architecte

Vue du cadastre

Vue du service des impots locaux

L’importance de la modélisation

Qu’est ce qu’un modèle?

Un modèle est une simplification de la réalité

Pourquoi modéliser?

Les modèles permettent de mieux comprendre le système que l’on développe

Nous construisons des modèles pour les systèmes complexes parce que nous ne sommes pas en mesure d’appréhender de tels systèmes dans leur intégralité.

Les quatres principes de modélisation

2. 3. 4.

Le choix des modèles à créer a une forte influence sur la manière d’aborder un problème et sur la nature de sa solution. Tous les modèles peuvent avoir différents niveaux de précision. Les meilleurs modèles ne perdent pas le sens de la réalité. Parce qu’aucun modèle n’est suffisant à lui seul, il est préférable de décomposer un système important en un ensemble de petits modèles presque indépendants.

Albert Einstein :

« Everything should be made as simple as possible, but no simpler »

Intérêt du modèle

 Le modèle est important pour : ° Comprendre un problème ° Supporter un travail coopératif d'ingénierie ° Prévoir et simuler la réalisation d'un développement ° Identifier et suivre les lots de travaux ° Guider, contrôler, automatiser la production

 Construire un bâtiment sans plan : Est ce possible?

 Evolution de la CAO

° Représentation des pièces mécaniques ° Vérification de la compatibilité de pièces ° Emission de plans de fabrication ° Pilotage des chaînes de production

 Et le logiciel?

Limites et dangers des modèles

Tout modèle est faux, toute abstraction est fausse!--- Ne pas confondre le modèle et le système

Note : un langage de programmation est une forme de modèle

 La pipe de Magritte  L'image de la pipe ne permet pas de fumer

 L'image de la pipe

permet de raisonner sur la pipe (design, constitution, etc.) au niveau de l'instance ou du concept.

modelOf

La mappemonde est un modèle de la terre

modelOf

La mappemonde est un modèle de la terre

Permettant de poser certaines questions …

mais pas d'autres.

Différentes sortes de modèles

La carte est un modèle statique d'un système statique.

Autre exemple, un recensement.

modèle S D

UML - Langage

UML est un langage conçu pour:

◦ ◦ ◦ ◦

visualiser spécifier construire documenter

les artefacts d’un système à forte composante logicielle

Caractéristiques UML

Les Représentations possibles

Les représentations possibles

ACOO - UML

Les représentations possibles

Les niveaux d’abstractions

Un formalisme & plusieurs vues

Algorithme du monde réel (scénario)

Algorithme du logiciel

(scénario)

Objets du monde réel

Objets du logiciel

Objets du langage

De quoi parle-t-on ?

Comment ‘logique’ ?

Comment ‘physique’ ?

Analyse

Conception

Code

Modèle conceptuel

Modèle logique

Modèle physique

Les représentations possibles

Le langage UML



Les mécanismes généraux ◦ ◦ ◦ ◦ ◦

Les paquetages Les stéréotypes Les étiquettes Les notes Les contraintes

Les diagrammes de base ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦

Les diagrammes de classes Les diagrammes d’objets Les diagrammes de cas d'utilisation Les diagrammes de séquence Les diagrammes de communication Les diagrammes d'états/transitions Les diagrammes d'activités Les diagrammes de composants Les diagrammes de déploiement

avec la contribution de Pierre-Alain Muller

Les modèles UML / par vue

Le développement d’un système

cycle de vie

Phases du cycle de vie

 Analyse des spécifications du système

Cette phase porte uniquement sur les aspects externes du système. On s’attachera donc uniquement à décrire les frontières du système et les acteurs externes.

 Analyse du domaine

Cette phase a pour but d’exprimer un modèle objet dépendant uniquement du point de vue des utilisateurs. Il ne faut donc pas fournir de solution informatique, mais uniquement préciser le problème en termes dépendant du domaine d’application.

 Conception

Lors de cette phase, les concepteurs compléteront le modèle d’analyse afin de réaliser la spécification de la solution informatique. L’objectif principal est donc de fournir suffisamment de détails pour que la réalisation s’effectue au mieux. La dossier de conception se différencie assez peu du dossier d’analyse car la notation est strictement identique. C’est l’adjonction des objets d’applications et la précision des spécifications d’analyse qui marquent la frontière entre analyse et conception.

Phases du cycle de vie

 Conception détaillée

La conception détaillée est la continuation de la conception, à laquelle le concepteur va fournir des détails dépendant généralement du langage et des systèmes cibles.

 Architecture logique

A partir du découpage en paquetages réalisé pendant l’analyse, le concepteur effectue un découpage des applications en adéquation avec le modèle physique qui sera réalisé.

 Architecture physique

Le concepteur réalise la modélisation physique de l’architecture du logiciel grâce à la modélisation des processeurs et des périphériques, représentés à l’aide d’objets noeuds.

Analyse des spécifications du système

Objectifs

 Prendre connaissance du cahier des charges  Prendre en compte les aspects externes du système  Réaliser une description fonctionnelle de haut niveau  Définir l’architecture du système et un découpage en sous-

systèmes Comprendre les besoins du client  Préciser et reformuler les besoins  Déterminer les frontières du système  Etablir un contrat de développement

entre le client et le réalisateur

Analyse du domaine

Objectifs

 Raffiner les cas d’utilisation du système en scénarios  Découper en sous-systèmes fonctionnels  Etablir le modèle des objets métiers avec les experts  Décrire le comportement des objets les plus significatifs  Valider l’usage correct de la notation et des concepts  Réaliser les spécifications des interfaces homme -machine

Outils UML

Diagrammes de séquences Diagrammes de paquetages  Diagrammes de classes Diagrammes d’états  Relectures et revues du dossier d’analyse

Conception

Objectifs

 Compléter le modèle issu de l’analyse  Définir les objets d’application et ajouter les objets

techniques ou informatiques

 Rester indépendant du langage de programmation

Outils UML

 Diagrammes de classes complet, avec toutes les relations inter-classes possibles  Diagrammes d’états  Diagrammes de séquences (scénarios) détaillés  Relectures et revues du dossier de conception

Conception détaillée

Objectifs  Apporter des détails aux différents diagrammes  compositions par valeur ou par référence  signature des méthodes  visibilité des objets dans les scénarios  spécification de pré-conditions et post-conditions  ...

Outils UML Diagrammes d’activités

Architecture logique

Objectifs Déterminer l’architecture logicielle du système en minimisant la

complexité des relations de dépendances entre entités

Tenir compte des considérations liées à l’optimisation du nombre de classes en mémoire ou à l’ordre d’introduction des classes Répartition des ressources sur une architecture distribuée ou client-serveur

Outils UML

Modèle de composants

Architecture physique

Objectifs Concevoir l’architecture matérielle physique du système en termes de processus, processeurs, périphériques, ...  Etablir une correspondance entre les objets logiques et les supports physiques  Spécifier les protocoles mis en œuvre

Diagrammes de déploiement

Outils UML

Processus de développement (de) logiciel

Un processus correctement défini aide à choisir:

◦ ◦ ◦

◦

les artefacts à produire les procédures à développer les intervenants chargés de leur création et de leur gestion la manière d’employer ces artefacts pour évaluer et diriger le projet dans son ensemble

UML vs démarche standard

UML + Méthode Unifiée ?

Un langage formel

 Générique, Expressif, Evolutif, Syntaxe et sémantique parfaitement définies, Concepts universels :classe ,cas d’utilisation

,événement ,état, association , système, ...

Un processus de Génie Logiciel

 Très difficile à standardiser

 Nombreux types de cycles de vie

 Contraintes organisationnelles très diverses

 Diversité des métiers

Pas de démarche standard UML

Les créateurs d’UML insistent tout particulièrement sur le fait que la notation UML est un langage de modélisation objet et non pas une méthode objet.

UML n’est pas une notation propriétaire; elle est accessible à tous et les fabricants d’outils ainsi que les entreprises de formation peuvent librement en faire usage.

En français, UML pourrait se traduire par langage unifié pour la modélisation objet, mais il est plus probable qu’UML se traduise plutôt par notation unifiée, voire notation UML…

 Le processus à adopter est totalement libre  Il n’ya pas de normalisation de cette démarche prévue dans un futur proche  Des travaux de formalisation d’un processus générique de développement objet sont en cours :Méthode

Unifiée

 Quelques recommandations générales  Développement incrémental et itératif  Basé sur une architecture en couches