Département de génie logiciel et des TI Systèmes dinformation dans les entreprises Chargé: JF...

Département de génie logiciel et des TI

Systèmes d’information dans les entreprises

Chargé: JF Couturier

Cours # 5

MTI515 Automne 2013 JF Couturier 1


Retour sur le dernier cours

Le diagramme des cas d’utilisation Les cas d’utilisation Le SRS Les cas de test Des questions?



Quelques points importants

Pourquoi faire le modèle du domaine avant les cas d’utilisation?

Plusieurs niveau de détails pour un cas d’utilisation…essentiel, concret, etcQu’est-ce qui est pratique pour un

développeur?

Nommer vos écrans



Bilan

Nous avons faitLe modèle des processus d’affaires

Le modèle du domaine et le glossaire

Le modèle des cas d’utilisation

Nous détaillons toujours les exigences de notre système

Abordons maintenant Le modèle d’analyse du système



Retour sur les CU

1 PMÉ = 1 CU Les CU et les acteurs

1 acteur principal

1 système

1 ou plusieurs acteurs secondaires

Lorsqu’il y a plusieurs acteursVisual Use Case?



Petit croche par la droite

Présentation du PDG du CRIM Sondages auprès des dirigeants de

DMR, Odésia, Ville de Mtl, Dir. Informatique, Audisoft, etc.

Tendances Mobilité, accessibilité, sécurité, web 2,3,4,

cloud computing, virtualisation, gaming, logiciels libres, méthodes et standards, intégration….


Yves Sanssouci, CRIM, 2009

http://www.crim.ca/fr/


Qualités requises

Savoir faire 1 langage de programmation

Comprendre les idées, les concepts

Moins besoin de programmeur, besoin d’intégrateurs

– Pourquoi selon vous?

Sécurité Gestion du risque, MEHARI, ISO17799, ISO27001

Intégration




Qualités requises

Savoir faire Méthodologies (CoBIT, ISO, CMMi, MEHARI)

Veille État de l’art, collecter et organiser l’information

pertinente, suivre l’évolution de son environnement, préparer l’innovation

Plateforme mobile Sondage PEW: en 2020, la plupart des gens vont

accéder au Web via des mobiles

Architectures distribuées




Qualités requises

Autres Gestion de projet

La notion de livrable

Rédaction de rapport Concis, clair, direct

Connaissance du marché …et de ses attentes

Les autres cultures Les différences dans les interactions, face à

l’autorité, en équipe




Qualités requises

Savoir être Attitude

Positive bien sûr! Disposée à bien faire son travail, qui a le sens des responsabilités, proactif!

Sens du client On travaille pour quelqu’un, adopter son point de

vue, qui a des exigences particulières qu’il faut comprendre

Le cœur à plus de mémoire que le portefeuille




Qualités requises

Savoir être Rigueur et discipline

Respect des échéances, des procédures, exactitude, ponctualité, adopter des méthodes de travail

Esprit d’équipe Complémentaires, capable de travailler ensemble



Autres considérations

Délocalisation / Offshoring Green IT Gouvernance

Gouvernance des TI




BABOK Business Analysis Body of Knowledge

Ensemble des bonnes pratiques en analyse d’affaires

Certified Business Analysis Professional (CBAP)

On y retrouve

Diagramme d’activité (p192)

Cas d’utilisation et scénario (p204)

DFD

Prototypage (p196), interview, questionnaires, brainstorming

Même le diagramme de séquence! (p208)

Chapitre 6 de BABOK Analyse des exigences



Exemple de stage à l’ACDI

Tâches :1. Travailler à un projet en tant que stagiaire sous la direction d'unanalyste principal d'affaires. L'étudiant jouera un rôle clé dans laréalisation du projet. Les tâches pourraient amener l'étudiant à : a. Collaborer à la documentation des processus; b. Collaborer à la formulation et à la documentation des besoins; c. Assumer d'autres fonctions administratives telles que lapréparation de présentations, de notes de service, de tables decalculs et de compte rendu de réunions.

Connaissances constituant un atout :1. Connaissance des techniques de modélisation de processus.2. Connaissance de la modélisation de données et des capacités enmatière d'UML (langage de modélisation unifié).3. Connaissance de BABOK (Business Analysis Body of Knowledge) del'IIBA (International Institute of Business Analysis).4. Connaissance de base de la méthodologie RUP (Rational UnifiedProcess) et des outils Rational.



Plan du cours 5

Quiz 2

Les Patrons(Patterns)

Architecture d’application

Stéréotype

Modèle d’analyse



Plan du cours 5

Quiz 2

Les Patrons (Patterns)


Modèle d’analyse

Stéréotype



Les patrons

Qu’est-ce qu’un patron?

C’est la description d’un problème, sa solution et les conséquences attendues.

On retrouve 4 éléments: Le nom du patron

Le problème à résoudre

La solution

La conséquence d’appliquer le patron



Les patrons

Le nom du patronC’est une description sur sa conception,

sa solution, mais de façon succincte (2-3 mots)

Un nom significatif aide à cataloguer et retrouve le motif



Les patrons

Le problème à résoudreDécrit le problème dans son contexte

Peut décrire des classes ou des structures d’objets qui sont symptomatiques du design

Parfois une liste de conditions qui doivent être remplies avant d’être appliqué est incluse



Les patrons

La conséquence d’appliquer le patronLa résultante et les compromis

d’appliquer la solution

Parfois absent, mais important pour comprendre les bénéfices de son utilisation



Exemples de patrons

Architecturaux MVC, 3-Tiers

ConceptionAdapter, Composite, Façade

Application d’entreprise (Fowler)Service Layer, Lazy load

Les patrons GRASP (Larman)



Ressources

Les patrons de la gang des 4 (GoF) Les patrons d’entreprise de Fowler Il y en a beaucoup d’autres

Il faut les connaître pour pouvoir les appliquer

Il ne faut pas chercher à mettre des patrons partout, au risque de complexifier votre environnement



Plan du cours 5

Quiz 2

Les motifs (Patterns)


Modèle d’analyse

Stéréotype




Le patron MVCModèle

Vue

Contrôleur

La patron 3 tiersPrésentation

Métier

Base de donnéesMTI515 Automne 2013 JF Couturier 25


D’autres niveaux…


Dennis, Alan R., Barbara Haley Wixom, and David Tegarden. "Chapter 8 - Moving on to Design". Systems Analysis and Design with UML Version 2.0: An Object-Oriented Approach, Third Edition. John Wiley & Sons. © 2009. Books24x7. <http://common.books24x7.com/book/id_29675/book.asp> (accessed May 29, 2009)


Architecture

Pouvons-nous utiliser notre analyse et nos artéfacts et réduire l’écart avec la conception?

Pouvons-nous aider visuellement l’équipe de développement logiciel à comprendre nos artéfacts?

Pouvons-nous déjà séparer la présentation, la logique et le domaine?



Plan du cours 5

Quiz 2



Stéréotype

Modèle d’analyse



Les stéréotypes

Dans UML, les stéréotypes permettent d’étendre les éléments du modèle en y apportant une annotation particulière.

On utilise généralement les « » pour encadrer les stéréotypes.

Un stéréotype peut aussi être représenté sous la forme d’une icône



Exemples de stéréotypes



Exemple avec la formation





UML2 par la pratique, Pascal Roques


Plan du cours 5

Quiz 2

Architecture d’application Couches de base


Stéréotype

Modèle d’analyse



Question

Vous êtes développeur Je vous donne les artéfacts que nous

avons actuellement Comment débutez-vous votre travail de

conception? Voyez-vous un écart entre l’analyse et

la conception? Expliquez?



Les classes d’analyses

Une des difficultés en conception est de passer des cas d'utilisation à la conception, ces deux représentations n'ayant que peu de choses en commun.

Les classes d'analyse sont des objets fictifs capables de produire le comportement décrit dans les cas d'utilisation et qui sont « faciles » à transformer en classes de conception.

Il s'agit de la première étape dans la transformation du système de la description des comportements vers la façon dont il doit fonctionner


Normand Rivard, GTI710, cours 3


La transition


http://iconixprocess.com/iconix-process/analysis-and-preliminary-design/robustness-analysis/

http://iconixprocess.files.wordpress.com/2007/01/bridgingthechasm.png


Modèle d'analyse RUP

Le modèle d'analyse dans RUP suit les étapes suivantes:Créer et décrire la réalisation du CU

Trouver les classes d'analyse (Stéréotypes de Jacobson..on y arrive)

Distribuer les comportements aux classes d'analyse

Diagramme de robustesse pour certains



Stéréotypes d'analyse en UML



Les classes d’analyses (1) Frontières - Boundary

Représentent les points d'arrimage avec les acteurs. Dès qu'un acteur intervient dans le texte d'un cas d'utilisation (qu'il agisse ou qu'il subisse), un objet frontière est nécessaire. Objet à la frontière entre le système et un acteur. Écran.

Contrôles - Control

Représentent les traitements à faire avec les entités. Corresponds souvent aux verbes d'action dans le texte des cas d'utilisation. Objet assurant une coordination avec les autres objets.

Entités - Entity

Représentent des choses inertes. Corresponds souvent aux noms communs dans le texte des cas d'utilisation. Font référence à une donnée persistante. Correspond à vos entités dans votre modèle conceptuel/du domaine.




Stéréotypes d'analyse (2)

Frontière - Boundary

une classe qui interagit en périphérie du système directement avec un acteur, mais aussi avec les classes 'control' et autres 'boundaries' (selon les auteurs).

Contrôle - Control

une classe qui gère dans le temps l'interaction entre une collection d'objets. Elle est généralement dédiée à un seul PMÉ. Et puisque généralement nous avons 1 PMÉ = 1 CU...il y a aura toujours minimalement 1 contrôle par CU. Espérons en avoir plus.

Entité - Entity

Une classe qui a une existence propre dans le domaine, mais qui est passive donc n'initie pas d'interaction avec le reste du système. Elle peut participer dans plusieurs PMÉ.



Les classes d’analyses Règles à respecter

Les acteurs ne parlent qu’aux frontières.

Les frontières parlent aux contrôles ou aux frontières (selon votre source…).

Aux contrôles uniquement selon-moi...

Les entités ne parlent à personne, mais répondent aux contrôles (selon vos sources).

Les contrôles peuvent parler aux frontières, aux entités et à d’autres contrôles, mais pas aux acteurs.


Inspiré de Normand Rivard, GTI710, cours 3http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern_C4047897.htmlhttp://www.upedu.org/upedu/process/gdlines/md_acls2.htm

http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/guidelines/entity_control_boundary_pattern_C4047897.html

http://www.upedu.org/upedu/process/gdlines/md_acls2.htm


Exemple




Exemple selon RUP



Trouver les objets entités

Dans la description détaillée d’un UC : lister les noms candidats :

client, acheteur, employé, utilisateur, internaute

catalogue, prospectus, article, item, …

Éliminer les synonymes et les noms ambigus

Choisir des noms clairs et consistants

Conserver la terminologie du métier



Trouver les objets frontière

Le plus souvent objet d’interface utilisateur (UI)

Interagit avec un acteur externe pour : recueillir des données

présenter de l’information

D’où l’intérêt de nommer ses écrans dans le CU



Trouver les objets contrôle

Fournit un service spécifique à un objet frontière. Opération réalisé par le système.

Implémente ce service en collaborant avec plusieurs objets entité

Masque la complexité

Minimalement 1 objet contrôle pour un cas d’utilisation Mais généralement beaucoup plus si le

traitement est décomposé



Guide

Ayez votre CU et votre modèle du domaine en main.

Créer une frontière pour chaque écran utilisateur.

Créer un contrôle pour chaque CU, puis pour chaque fonction logique logicielle (verbe, validation, règles d’affaires)

Ce diagramme représente une conception préliminaire, pas une conception détaillée.

Les frontières et les entités vont devenir des objets alors que les contrôleurs vont généralement devenir les messages dans le diagramme de séquence…vous voyez où je veux en venir?

L’objectif ici est de raffiner ET vos cas d’utilisation ET votre modèle d’objet


Use Case Driven Object Modeling with UML, Rosenberg D. Stephens M.


Rappelez-vous que…

C’est une bonne idée de comprendre les exigences avant de faire la conception…

Mais qu’il est parfois impossible d’appréhender toutes les exigences sans faire un peu de conception exploratoire…


Use Case Driven Object Modeling with UML, Rosenberg D. Stephens M.


Exemple



Étude de cas du garage

Avez-vous la séquence des évènements? Oui, avec le diagramme d’activité et les cas d’utilisation

Avez-vous les entités Oui, avec le modèle du domaine et le diagramme

d’activité si vous avez identifié les objets. Le glossaire.

Avez-vous les interactions entre les utilisateurs et le système?

Oui, avec les cas d’utilisation

Nous pouvons donc proposer une analyse avec les classes d’analyse





Diagramme d’activité




Modèle du domaine




Diagramme des CU


Étude de cas du garage Cas d’utilisation Prendre un rendez-vous

1. Le chef de service cherche une disponibilité de rendez-vous

2. Le système affiche le calendrier

3. Le chef de service sélectionne une date de rendez-vous.

4. Le système affiche une fiche de client.

5. Le chef de service complète le dossier client et confirme son choix.

6. Le système confirme le rendez-vous. La date et l’heure sont maintenant indisponibles.

5.a Le client existe déjà

5.a.1 Le système avertit le chef de service

5.a.2 Le chef de service complète le dossier client

Le scénario reprend à l’étape 6





Diagramme d’analyse (Itération 1)


Étude de cas du garage Cas d’utilisation Prendre un rendez-vous

1. Le chef de service cherche une disponibilité de rendez-vous

2. Le système affiche le calendrier

3. Le chef de service sélectionne une date de rendez-vous.

4. Le système affiche une fiche de client.

5. Le chef de service complète le dossier client et confirme son choix.

6. Le système confirme le rendez-vous.

7. Le système met à jour le calendrier

5.a Le client existe déjà

5.a.1 Le système affiche le dossier client

5.a.2 Le chef de service complète le dossier client

Le scénario reprend à l’étape 6



Étude de cas du login

Tenter de faire le diagramme d’analyse de ce cas.Un utilisateur entre son code et son mot

de passe

Le système authentifie l’utilisateur dans l’annuaire. L’annuaire récupère l’information du compte.

Le système affiche la page de bienvenue



Première itération



Seconde itération


Attention - erreur


Et après

Le diagramme de séquence Transformer les frontières et les entités

en instance d’objet Transformer les contrôleurs en

messages Et nous nous retrouvons avec les

premières briques de conceptions



Diagramme de séquence



Le diagramme de classe

Les contrôleurs sont des opérations pour les classes identifiés dans le modèle du domaine

On quitte le modèle du domaine et on construit maintenant un modèle de classe de conception..



Diagramme de classe



Ensuite

Selon leur expérience et leur habileté, le diagramme de robustesse est généralement le dernier moment où vos clients peuvent participer activement à l’explicitation des exigences Au-delà, c’est la conception du code, par les

développeurs.

Vos clients continueront à donner du feedback sur les livrables (prototypes, interfaces)



Lien avec Larman

Larman propose de passer directement au diagramme de séquence système (SSD) cf chapitre 10 du livre de Larman

Intéressant, sauf qu’à cette étape, nous voyons toujours le système comme une boîte noire… Nous sommes toujours dans les exigences

Larman propose également les contrats



Lien avec Roques

Roques, dans le chapitre 7, utilise les stéréotypes de Jacobson à l’intérieur d’un diagramme de communication.



Lien avec Rosenberg

Tout le chapitre 5 du livre de Rosenberg et Stephens(Use case driven object modeling with UML) est basé sur la transition entre l’analyse et la conception.

Très intéressant



Ressources

Chapitre 7 du livre

UML2 par la pratique de Pascal Roques

Chapitre 5 du livre

Use case driven object modeling with UML de Doug Rosenberg et Matt Stephens

Un lien sur le site du livre

Article de Scott Ambler sur le diagramme de robustesse À lire!

Le chapitre 11 de Larman sur les contrats d’opération






http://www.agilemodeling.com/artifacts/robustnessDiagram.htm


Prochain cours

Archétypes Modélisation en couleur Lecture

chapitres 3 et 4 d’UML2 par la pratique.


Département de génie logiciel et des TI Systèmes dinformation dans les entreprises Chargé: JF...

Documents

Transcript of Département de génie logiciel et des TI Systèmes dinformation dans les entreprises Chargé: JF...