1. UML
1.1. Définition
1.1.1. Langage de modélisation
1.1.2. graphique et textuel
1.1.3. orienté objet
1.1.4. support de communication
1.1.5. modulaire
1.1.6. n'est pas une méthode
1.2. Diagramme
1.2.1. modèle
1.2.2. point de vue
1.2.2.1. 1 seul par diagramme
1.2.2.2. mot clé : objectif de la description du SI
1.2.3. niveau d'abstraction
1.2.3.1. plusieurs par diagramme
1.2.3.2. mot clé : profondeur de la description du SI
1.2.4. caractéristiques
1.2.4.1. concepts orientés objet
1.2.4.2. formalisé
1.2.4.2.1. symboles : syntaxe
1.2.4.2.2. règles de construction : grammaire
1.2.4.3. graphique et textuel
1.2.5. classification
1.2.5.1. 14 diagrammes
1.2.5.2. 2 visions
1.2.5.2.1. vision statique
1.2.5.2.2. vision dynamique
2. CAPTURE INITIALE DES BESOINS
2.1. démarche
2.1.1. lien entre ...
2.1.1.1. le processus de développement logiciel
2.1.1.1.1. 4 étapes
2.1.1.1.2. la modélisation métier
2.1.1.1.3. la capture du besoin
2.1.1.1.4. l'analyse
2.1.1.1.5. la conception
2.1.1.2. le langage de modélisation
2.2. définition
2.2.1. comprendre le besoin du client (et de l'utilisateur du SI)
2.2.2. la démarche
2.2.2.1. 1 - Réaliser un diagramme de cas d'utilisation
2.2.2.2. 2 - Décrire chacun des cas d'utilisation pour préciser le service attendu soit avec un fiche descriptive soit avec un DSEQ Système
2.2.2.3. 3 - D'en déduire, par cas d'utilisation, une maquette IHM pour chacun des écrans
2.2.2.4. 4 - Réaliser un diagramme de classes métier regroupant les concepts métier nécessaires au SI étudié
2.2.3. analyste
3. DIAGRAMME DE CAS D'UTILISATION (DCU)
3.1. Définition
3.1.1. Point de vue : périmètre du système à travers les services rendus aux utilisateurs du SI.
3.1.2. Niveau d'abstraction : niveau d'objectif des services rendus par le SI
3.1.2.1. niveau stratégique : modélisation métier
3.1.2.2. niveau utilisateur : capture du besoin
3.1.2.3. niveau sous-fonction : analyse
3.2. Concepts
3.2.1. DCU général ou global
3.2.1.1. concepts de base
3.2.1.1.1. Le système : périmètre du SI
3.2.1.1.2. L'acteur : couple (utilisateur/rôle) qui interagit avec le SI
3.2.1.1.3. Le cas d'utilisation (UC) : service
3.2.1.1.4. L'association : canal de communication (tuyau)
3.2.2. DCU élaboré
3.2.2.1. concepts avancés
3.2.2.1.1. L'héritage : généricité
3.2.2.1.2. Les relations de dépendances
3.3. Elaboration
3.3.1. 1 - préciser le domaine et le champ d’étude
3.3.2. 2 - identifier et recenser les acteurs (rôles, fonctions ou autres systèmes)
3.3.3. 3 - identifier et recenser les UC
3.3.3.1. 3.1 - DCU général uniquement les concepts de base
3.3.3.2. 3.2 - DCU élaboré ajout des concepts avancés
4. DESCRIPTION DU CAS D'UTILISATION
4.1. Les objectifs de la description d'un UC ?
4.1.1. Raconter son histoire et lister ses scénarios : algoritmes
4.1.2. Recenser les exigences en IHM : maquettes
4.1.3. Recueillir les exigences non-fonctionnelles : architecture technique et matérielle + recette
4.2. fiche descriptive
4.2.1. Cartouche présentation
4.2.1.1. sous partie entête : état civil de l'UC
4.2.1.2. sous partie situation spatiale : acteur et niveaux d'objectif
4.2.1.3. sous partie situation personnelle : déclenchement et état du SI
4.2.2. Cartouche des scénarios
4.2.2.1. Définiton
4.2.2.1.1. histoires du cas d'utilisation
4.2.2.1.2. liste des interactions numérotées entre le ou les acteurs et le système
4.2.2.2. un scénario nominal
4.2.2.2.1. scénario sans erreur
4.2.2.2.2. s'achève par la délivrance du service
4.2.2.3. scénario(s) alternatif(s)
4.2.2.3.1. cas particulier
4.2.2.3.2. dérivation au scénario nominal
4.2.2.3.3. s'achève par un retour au scénario nominal
4.2.2.4. scénario(s) d'exception
4.2.2.4.1. anomalie
4.2.2.4.2. fin impromptue du scénario nominal
4.2.2.4.3. s'achève par un message d'erreur et la non délivrance du service
4.2.3. Cartouche des exigences fonctionnelles
4.2.3.1. Tout ce qui n'est pas fonctionnel
4.2.3.2. conception, architecture, matériel ...
4.2.3.3. Ne peut pas être modélisé dans le DSEQ Système
4.2.4. Cartouches des exigences IHM
4.2.4.1. Contraintes liées à la présentation des informations dans l'IHM
4.2.4.2. Ne peut pas être modélisé dans le DSEQ Système
5. DIAGRAMME DE CLASSES METIER
5.1. Définition
5.1.1. recenser les classes et leurs responsabilités (associations, caractéristiques et comportements)
5.1.2. point de vue : mécanique du SI
5.1.3. niveaux d'abstraction
5.1.3.1. métier : DCLAM
5.1.3.1.1. classes métier
5.1.3.1.2. associations
5.1.3.1.3. héritage
5.1.3.2. analyse : DCLAA
5.1.3.3. conception : DCLAC
5.2. Concepts
5.2.1. classe métier
5.2.1.1. chose/concept focntionnel
5.2.1.2. information à gérer par le SI
5.2.2. association
5.2.2.1. connexion sémantique (lien fonctionnel) entre deux classes
5.2.2.2. traduit une règle de gestion
5.2.3. multiplicité
5.2.3.1. nombre d'instances minimales et maximales qui participe à la relation
5.2.3.1.1. 0 .. 1
5.2.3.1.2. 0 .. *
5.2.3.1.3. 1 .. *
5.2.3.1.4. N .. *
5.2.3.1.5. 0 .. M
5.2.3.1.6. 1 .. M
5.2.3.1.7. N .. M
5.2.3.2. portée par l'association
5.2.4. rôle
5.2.4.1. nomme les instances d'une classe vues par celles d'une autre classe
5.2.4.2. précision fonctionnelle du diagramme
5.2.4.3. s'accorde en nombre
5.2.4.3.1. une instance : nom du rôle au singulier
5.2.4.3.2. plusieurs instances : nom du rôle au pluriel
5.2.5. héritage
5.2.5.1. classe générique
5.2.5.1.1. caractéristiques et comportements communs
5.2.5.1.2. abstraite
5.2.5.2. classe spécifique
5.2.5.2.1. hérite des responsabilités de la classe mère
5.2.5.2.2. spécialise la classe mère
5.3. Elaboration du diagramme
5.3.1. étape 1
5.3.1.1. identifier les concepts métier
5.3.1.2. à partir de la fiche descriptive de chacun des cas d'utilisation, relèver les noms communs importants
5.3.1.3. classes métier dites candidates
5.3.1.4. héritage
5.3.2. étape 2
5.3.2.1. déterminer les liens structurels entre les concepts métier
5.3.2.2. à partir de la fiche descriptive, chercher les verbes associant les noms communs
5.3.2.3. associations et autres concepts associés (multiplicité et rôle)
5.3.3. étape 3
5.3.3.1. décomposer en packages le diagramme
5.3.3.2. à partir des grands domaines de gestion de l'entreprise par exemple