Genie LogicielGenie LogicielMadalina Croitoru

IUT Montpellier, UM2

2012-2013

AS

Madalina Croitoru

• PhD 2002-2006 Univ. of Aberdeen, UK• Research Fellow 2006-2008 Univ. Southampton, UK• MCF 2008-today Univ. of Montpellier 2 • MCF 2008-today Univ. of Montpellier 2

▫ Research : LIRMM� Knowledge Representation

▫ Teaching : IUT, UM2� Web� GL

www.lirmm.fr/~croitoruGoogle: “Madalina Croitoru”

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:• 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 ☺

Course Structure

• Week 1: Use of GL and introduction

• Week 2: Planning in GL

• Week 3: Information Systems• Week 3: Information Systems

• Week 4 – Week 5: Information Process

• Week 6: Analysis Phase

• Week 7 – Week 10: Conception Phase

• Week 11: Test Phase

Typical Document to Produce

• Software Requirements Specifications Document (SRSD)

• (You will have to produce such document at the • (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!)

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

How can you describe your work to the other group?

• Using an SRSD• Using an SRSD

• Using diagrams instead of French (or English)

What you would normally produce

What you need to produce

• Structured document:

▫ Introduction

▫ Overall Description▫ Overall Description

▫ External Interface Requirements

▫ System Features

▫ Non functional requirements

▫ Other requirements

WHEN APPLICABLE

☺

Software Requirements Specifications structure1. Introduction

2. Overall Description

3. External Interface Requirements3. External Interface Requirements

4. System Features

5. Nonfunctional Requirements

6. Other Requirements

1. Introduction

1. Purpose

2. Document conventions

3. Intended audience3. Intended audience

4. Additional information

5. Contact information / team members

6. References

2. Overall Description

1. Product perspective

2. Product functions

3. User classes and characteristics3. User classes and characteristics

4. Operating environment

5. User environment

6. Design / implementation constraints

7. Assumptions and dependencies

3. External Interface Requirements

1. User interfaces

2. Hardware interfaces

3. Software interfaces3. Software interfaces

4. Communications protocols and interfaces

4. System Features

1. System feature 1

2. Description and priority

3. Action / results3. Action / results

4. Functional requirements

1. System feature 2

2. …

5. Nonfunctional requirements

1. Performance requirements

2. Safety requirements

3. Security requirements3. Security requirements

4. Software quality attributes

5. Project documentation

6. User documentation

6. Other Requirements

• Appendix 1: Terminology, Glossary, Definitions

• …

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.

• Use of the diagrams to explain HOW TO

BUILD the origami to the colleagues

In this example:

• The aim:

▫ To familiarise yourself with UML notation

▫ To make a first diagram

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.

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

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

What does this become when describing how to build an origami?describing how to build an origami?

Can one describe completely an origami with use cases? Why?

Diagramme d'activité

• Permet de modéliser un processus interactif, global ou partiel pour un système donné (logiciel, système d'information). (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.

Diagramme d'activité

• des nœuds actions• des nœuds de contrôle

permettant de spécifier l’enchaînement des actions 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.

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.

Diagrammes d'état/transitionLes éléments

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 échangés entre les lignes de vie, présentés dans un ordre chronologique.

• Peut servir à illustrer un cas d'utilisation (use case).

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

TP

• SRSD document

• All the 4 types of diagrams for your origami

• Work in groups of max 4• 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)