Madalina Croitoru IUT Montpellier, UM AS

Transcription

1 Genie Logiciel Madalina Croitoru IUT Montpellier, UM AS

2 Madalina Croitoru PhD Univ. of Aberdeen, UK Research Fellow Univ. Southampton, UK MCF 2008-today Univ. of Montpellier 2 Research : LIRMM Knowledge Representation Teaching : IUT, UM2 Web GL Google: Madalina Croitoru

3 Genie Logicel Cours + TP = 4h Flexible : ~1h Cours + ~3h TP Obligatory presence: all TPs will be counted in the final mark as follows: Final mark computed as: 70%: 20% Exercise on Information Systems: week 4 30% Project Analysis Report: week 8 30% Project Implementation Report: week 11 20% Project Test Report and Presentation: week 13 30%: Note on presence, work, implication (cf. each week s activity) NO EXAM

4 Course Structure Week 1: Use of GL and introduction Week 2: Planning in GL Week 3: Information Systems Week 4 Week 5: Information Process Week 6: Analysis Phase Week 7 Week 10: Conception Phase Week 11: Test Phase

5 Typical Document to Produce Software Requirements Specifications Document (SRSD) (You will have to produce such document at the end of the term too!) In this course: an intuitive view of what this document is on a simple example (origami!)

6 The TP: in groups, you produce a SRSD for a origami of your choice

7 How can you describe your work to the other group? Using an SRSD Using diagrams instead of French (or English)

8 What you would normally produce

9 What you need to produce Structured document: Introduction Overall Description External Interface Requirements System Features Non functional requirements Other requirements WHEN APPLICABLE

10 Software Requirements Specifications structure 1. Introduction 2. Overall Description 3. External Interface Requirements 4. System Features 5. Nonfunctional Requirements 6. Other Requirements

11 1. Introduction 1. Purpose 2. Document conventions 3. Intended audience 4. Additional information 5. Contact information / team members 6. References

12 2. Overall Description 1. Product perspective 2. Product functions 3. User classes and characteristics 4. Operating environment 5. User environment 6. Design / implementation constraints 7. Assumptions and dependencies

13 3. External Interface Requirements 1. User interfaces 2. Hardware interfaces 3. Software interfaces 4. Communications protocols and interfaces

14 4. System Features 1. System feature 1 2. Description and priority 3. Action / results 4. Functional requirements 1. System feature 2 2.

15 5. Nonfunctional requirements 1. Performance requirements 2. Safety requirements 3. Security requirements 4. Software quality attributes 5. Project documentation 6. User documentation

16 6. Other Requirements Appendix 1: Terminology, Glossary, Definitions

17 Use of UML diagram conventions in order to illustrate the software requirements specifications document (analysis). These diagrams will be reconsidered at the conception step and included in the final document used for coding.

18 In this example: Use of the diagrams to explain HOW TO BUILD the origami to the colleagues The aim: To familiarise yourself with UML notation To make a first diagram

19 Diagramme cas d'utilisation Vision globale du comportement fonctionnelle du logiciel. Représente également les interactions des Représente également les interactions des utilisateurs (appelés acteurs) avec les cas d'utilisations (use cases). Un acteur est l idéalisation d un rôle joué par une personne externe, un processus ou une chose qui interagit avec un système. Un cas d utilisation est un élément représentant une fonctionnalité visible de l extérieur. Il réalise un service avec un déclenchement, un déroulement et une fin, pour l acteur qui l initie.

20 Conventions graphiques Les acteurs peuvent être représentés sous deux formes différentes. La première est une représentation sous la forme d'un petit bonhomme avec le nom écrit dessous. La deuxième est un «classeur» précisant le type contenu dedans ainsi que le nom. Un cas d utilisation se représente par une ellipse contenant le nom du cas (un verbe à l infinitif), et optionnellement, au-dessus du nom, un stéréotype. Dans le cas où l on désire présenter les attributs ou les opérations du cas d utilisation, il est préférable de le représenter sous la forme d un classeur stéréotypé << use case >>.

21 Conventions graphiques Une relation d association est chemin de communication entre un acteur et un cas d utilisation et est représenté un trait continu. Les inclusions sont une étape obligatoire dans plusieurs cas d'utilisations, les inclusions permettent essentiellement de factoriser une partie de la description d un cas d utilisation qui serait commune à d autres cas d utilisation On dit qu un cas d utilisation A étend un cas d utilisation B lorsque le cas d utilisation A peut être appelé au cours de l exécution du cas d utilisation B. Cette dépendance est symbolisée par le stéréotype << extend >>.

22

23 What does this become when describing how to build an origami? Can one describe completely an origami with use cases? Why?

24 Diagramme d'activité Permet de modéliser un processus interactif, global ou partiel pour un système donné (logiciel, système d'information). Il est recommandable pour exprimer une dimension temporelle sur une partie du modèle, à partir de diagrammes de classes ou de cas d'utilisation, par exemple.

25 Diagramme d'activité des nœuds actions des nœuds de contrôle permettant de spécifier l enchaînement des actions (synchronisation, branchement) des nœuds d objet permettant de représenter les objets créées ou utilisés au cours d une activité. des arcs de transition permettant de relier les nœuds.

26 Diagrammes d'état/transition Les diagrammes d'état/transition sont des automates à états Ils présentent la vue dynamique d un système Ils sont particulièrement importants dans la modélisation du comportement d'une interface d'une classe d'une collaboration Ils mettent l'accent sur le comportement d'un objet ordonnancé par les événements.

27 Diagrammes d'état/transition Les éléments

28

29 Diagramme de séquence Principales informations contenues dans un diagramme de séquence sont les messages échangés entre les lignes de vie, présentés dans un ordre chronologique. Peut servir à illustrer un cas d'utilisation (use case).

30 Diagramme de séquence Les acteurs/objets sont représentés par de gros rectangles tout en haut du diagramme. La ligne de vie d'un objet est représentée par des pointillés sur l'axe vertical descendant de celui-ci. Les périodes d'activité de ces différents objets sont symbolisées par des rectangles positionnés sur sa ligne de vie. Les objets intéragissent entre eux via des messages (flèches). Ces derniers se diversifient en fonction des besoins.

31 TP SRSD document All the 4 types of diagrams for your origami Work in groups of max 4 At the end of the TP: the report on the TP progress (to be continued next week for the final version)