Comprendre les exigences

Le première activité pendant le processus de développement de logiciel est l'établissement des exigences pour le nouveau système. Voici une blague. On peut distinguer les phases suivantes:

• Analyse du domaine
  • Le but de l’analyse du domaine est de comprendre le domaine du problème indépendamment d’un système particulier à développer. Ici, on n’essaie pas de tracer la limite entre le système et son environnement.
  • On se concentre sur les concepts et la terminologie du domaine d’application avec une vue plus large que le système futur à développer
• Conception externe: Établir la frontière entre le système à construire et son environnement.
• Analyser, modéliser et spécifier les exigences. Le livrable est la spécification des exigences du système à construire.

Les activités et les résultats de l'analyse du domaine

Première activité: Analyse du domaine tel qu'il est:

• Établir un dictionnaire qui définit une terminologie commune et les concepts du domaine
• Description du domaine d’un point de vue d’un modèle conceptuel, incluant des hiérarchies d'héritage. Les concepts utilisés pour cela sont normalement la modélisation par entités et relations (à l'origine proposée par Peter Chen en 1976). Maintenant, on adopte normalement la notation des diagrammes UML de classes.
  • Entité: représente un type d’objets, définit les propriétés que toutes les instances de ce type auront  
  • Relation: :représente des liens entre instances de certains types d'objets+.
    • Les types d’entités reliés s’appellent aussi rôles.
    • L’ information sur la multiplicité indique combien d’instances “sur l’autre côté” peuvent être liées avec une instance “de ce côté”.
  • Attribut:Une entité ou une relation peut avoir plusieurs attributs. Chaque attribut est identifié par un nom et son type (qui est normalement un type de donnée simple, comme entier ou chaîne de caractères). Remarque: Un type d’entité n’est normalement pas utilisé comme type d’attribut, parce que dans une telle situation on utilise plutôt une relation entre l’entité donné et le type d’attribut.
• Méthodologie: La méthodologie suivante est proposée. Elle devrait être utilisée avec beaucoup de retours en arrière - essais, corrections, et améliorations du modèle établi.
  • Normalement, une description textuelle du domaine et des exigences est donnée dans une forme ou une autre.
  • Etablissez un dictionnaire des termes qui inclut les mots les plus importants de la description textuelle. Chaque nom indique un objet ou une classe d'objets qui pourrait être représenté dans le modèle. Ce sont les "entités" de l'approche de modélisation par entités et relations. Chaque verbe indique une relation entre objets qui pourrait être représentée dans le modèle. On distingue entre objets actifs (aussi appellés acteurs) et objets passifs qui n'ont pas d'initiative propre (ils sont normalement "appellés").
• Note: Plus tard on veut aussi un énoncé clair du but, des objectifs du nouveau système à construire et sa frontière par rapport aux autre entités dans le domaine. (Ce système à construire fait parti du domaine dans sa version future)

Deuxième activité: Conception externe - la conception du domaine comme il devrait être, incluant le système à construire

• Pendant l’analyse des exigences, on trouve les propriétés du domaine actuel, et aussi les exigences qui devraient être réalisées dans la version future du domaine. Nous faisons l’hypothèse que la version future du domaine inclut un nouveau système à construire, tandis que d’autres aspects du domaine pourraient aussi changer dans la version future.
• La détermination de cette version future du domaine, incluant le nouveau système à construire, est un cas typique d’un processus de conception. On l’appelle Conception externe, parce que le nouveau système est considéré en “black-box” à l’intérieur de la version future du domaine – qui est considérée en “white-box”; et il s’agit de concevoir cette version future du domaine.
  • Quelqu'un disait: La spécification des exigences est “l’invention et la définition du comportement du nouveau système (dans la nouvelle version future du domaine) tel qu’il produira les effets souhaités dans le domaine”
• Note: Pendant ce processus, la limite entre le système à construire et les autres entités dans le domaine est établie. 

Voici un exemple d'analyse de domaine (d'un système de contrôle d'access) qui inclut aussi le première phase de l'analyse des exigences.

Analyse, modélisation et spécification des exigences: Considérations générales

C'est quoi, un système?

• Un système est une partie du monde réel qu’une personne ou un groupe de personnes considèrent, pendant un certain temps et pour un but particulier, comme un tout; il consiste de composantes interreliées, chaque composante étant caractérisée par des propriétés qui ont été sélectionnées parce qu’elles sont pertinentes pour le but considéré.
• Un système fait parti du monde réel.
• Ce qui constitue un système est sujet à définition.
• Chaque composante d’un système peut aussi être considérée comme un système.
• Un système n’est pas juste une collection non ordonnée de composantes.
• Un système a un but.

La description d'un système a deux buts:

• Décrire le comportement fonctionnel pour qu’il soit complètement compris
• Décrire la réalisation pour que le système puisse être produit

. . . et il y a deux aspects:

1. La structure (statique)
   • l’aspect du système qui reste invariant (fixe) pendant l’intervalle de temps sur laquelle le système  est étudié
   • la disposition, l’arrangement des parties du système
2. Le comportement (dynamique)
   • Le comportement d’un système est le développement des états et des transitions entre états générés par les actions du système pendant le laps de temps pour lequel il est étudié
   • Le comportement est un développement dynamique à travers le temps
   • Approximation: le comportement consiste d'actions qui changent l'état (les valeurs) de variables
   • Le comportement est l'aspect le plus difficile à décrire à cause de sa nature dynamique et transitoire. Dans le plupart des cas, les séquences d'interactions possibles incluent des comportements de boucles; donc ces séquences ont des longueurs sans bornes - il y a donc une infinité de comportements possibles. Comment peut-on décrire de tels comportement infinis avec une description finie ?

Techniquers pour gérer la complexité

• Abstraction:
  • Ignorer certains aspects d’un phénomène pour décrire (et comprendre) plus clairement d’autres aspects.
  • Le contraire de concret ou physique
  • L’abstraction devrait être claire et précise, offrir une implantation efficace et supporter l’évolution et la réutilisation
• Agrégation and décomposition:
  • Tous les systèmes non triviaux sont composés de composants
  • Le processus de combiner des composants pour en faire un tout est appelé agrégation
  • Le processus opposé est appelé décomposition
• Projection:
  • Lors d’une projection, nous regardons le système d’un certain angle
  • Une projection est une description d’un système comme il est aperçu par un sous-ensemble de ses interfaces
  • Seulement les interfaces visibles sont observables, les autres sont cachés
• Généralisation - Spécialisation:
  • Dans le monde réel, il y a un grand nombre d’objets similaires
  • Au lieu de décrire et comprendre tous les objets individuels en détails, nous pourrions les décrire et les comprendre par leurs traits similaires
  • Un type est une entité conceptuelle qui nous sert à structurer nos descriptions et pensées. En UML et Java, un type est appellé “Class”
  • Un objet individuel est une instance d’un type - son type décrit ses propriétés
  • Un sous-type d’un type définit des traits supplémentaires qui seront satisfaits par toutes ses instances
  • Un exemple

La spécification d'un système contient des hypothèses et des garanties

En général, une spécification d’un système a la forme suivante:

• Si certaines hypothèses sur l’environnement sont satisfaites, alors le système fournit certaines garanties à l’environnement.
  • Exemple – la spécification d’un programme de tri - Spécification (A): Si la liste de nombres entiers fournie comme entrée a moins que 1000 éléments, alors la liste de sortie contiendra les mêmes nombres entiers en ordre ascendant, mais la liste pourrait être plus courte si quelques nombres apparaissent plusieurs fois dans la liste d’entrée. – Note: Aucune garantie n’est donnée pour le cas que la liste d’entrée contient 1000 éléments ou plus.

Théorême pour le développement avec composantes: Etant donnée une spécification S = AS implique GS (hypothèse implique garantie) pour une composante dans un système donné, et une implantation qui satisfait la spécification I = AI implique GI . L’implantation peut être utilisée pour réaliser cette composante si et seulement si AI est moins forte que AS et GI est plus forte que GS . - - On dit des fois que I “est conforme à“ S.

Exemple: Etant donnée une implantation d’une programme de tri qui satisfait la Spécification (B): Si la liste des nombres entiers fournie comme entrée contient moins que 2000 éléments, alors la liste de sortie contiendra les même nombres entiers en ordre ascendant, chaque nombre seulement une fois, même si il apparaissait plusieurs fois dans la liste d’entrée. Cela veut dire:

• Hypothèse (B): Il y a moins que 2000 entiers dans la liste d’entrée
  • L’hypothèse de moins que 2000 éléments est moins forte que “moins que 1000”.
• Garantie (B): La liste de sortie contient les mêmes nombres en ordre ascendant, chaque nombre une fois.
  
  • La garantie d’avoir chaque nombre seulement une fois, est plus forte.
• Note: La garantie de la spécification (A) est non déterministe: elle permet différentes multiplicités de nombres dans la liste de sortie (si un nombre apparaît dans la liste d’entrée plusieurs fois).

Question: Est-ce que cette implantation peut être utilisée pour réaliser la composante qui doit satisfaire la Spécification (A) ?

Exemples de spécialisations:

• Si dans l’approche OO une classe I hérite d’une classe S, cela veut dire que toutes les méthodes fournies par S (des garanties) sont aussi fournies par I (les garanties de I sont égales ou plus fortes que les garanties de S). Ceci est une sorte particulière de spécialisation conforme.
• Une implantation de la fonction de tri qui est spécialisée (et optimisée) pour des nombres entre 0 et 255 peut être appellée une “spécialisation” de l’implantation considérée plus haut. Mais elle n’est pas conforme, puisqu'elle fait une hypothèse plus forte (en supposant que les valeurs à trier sont plus petites que 255).

Analyse, modélisation et spécification des exigences: Méthodologie

• Identifier les interfaces du système et les acteurs externes: Basé sur les relations entre les classes d'objets dans le modèle conceptuel de l'environnement, identifier les interfaces entre le système et les autres entités dans l'environnement. Identifier les différentes interactions qui pourraient y arriver. On pourrait distinguer différents types d'interactions sur un niveau abstrait, tel que appel d'opération (méthode), interaction rendez-vous, ou échange de messages (voir aussi chapitres suivantes).
• Définir des cas d'utilisation: Chaque cas d'utilisation définit une certaine séquence d'interactions. Ces séquences d'interaction peuvent être représentées par des diagrammes d'interactions UML.
  • Ils décrivent le comportement prévu du système. Ils peuvent représenter des services, tâches ou fonctions que le système doit réaliser.
  • Les cas d’utilisation sont rapidement devenus une pratique répandue pour capturer les exigences.
    • Ceci est surtout vrai dans la communauté objet-orientée d’où ces notions originent
    • Leur application n’est pas limitée aux systèmes objet-orientés
  • Un cas d’utilisation définit un ensemble d’interactions but-orienté entre les acteurs externes et le système en considération. (Les acteurs sont des composantes à l’extérieur du système qui interagissent avec le système).
    • Un cas d’utilisation est initié par un utilisateur qui possède un but particulier en tête, et est complété lorsque le but est atteint
    • Il décrit la séquence d’interactions entre les acteurs et le système qui sont nécessaires pour livrer le service qui satisfait au but
• Lors de l'établissement des exigences d'un système, il arrive que la structure du système est modélisée par plusieurs composantes. Voir exemple d'un système d'alarme.
• Le système, ou les composantes, pourraient exister dans différents états, et leur comportement dynamique pourrait dépendre de ces états. Identifier ces états par la construction d'un diagramme d'états (avec transitions entre les états) pour chaque composante (ou le système - comme boite noire).

Voici l'exemple du système de contrôle d'accès.

Exemple d'analyse des exigences: une machine ATM

Distinction entre exigences fonctionelles et non fonctionelles

• Les exigences fonctionnelles définissent ce que le système doit faire
• Les exigences non fonctionnelles définissent comment le système est supposé être: Normalement, ce sont des attributs du système tels que le temps de réponse, le débit, la sécurité, la fiabilité, les propriétés de maintenance, la scalabilité, l'utilisabilité…

Notes de cours - Gregor v. Bochmann - University of Ottawa. Créées: January 9, 2015 - Note: cette page contient du matériel copié des diagrammes Powerpoiont utilisés par Hussein Al Osman pour ce cours en 2014