notes-ing2/concept/01_init.md

Conception et architecture

Introduction

Phase de conception : processus créatif de décision des roles, relation et interfaçage entre les composants d'un système.

Modélisation

• Support de conception.
• Formalisation de la solution.

Réduit la complexité du système :

• met en évidence les détails superflu, pour les éliminer.
• met en évidence les caractéristiques importantes à prioriser.

Création d'un modèle :

• abstrait, non implémenté et dense en concepts
• concu en vue de décrire le système pour son implémentation et ses possible évolutions

Le modèle sert :

• de document d'échange entre clients et développeurs
• d'outil de conception
• de référence, pour le développement, l'extension et la maintenance

Documentation

Une possibilité : des textes de spécification :

• en langage naturel
• ambigu

Document de spécification :

• en langage spécifique au domaine
• supposé exaustif

Langages à différents niveaux de formalisastions.

• langages formels : s'appuient sur les mathématiques, permet des prouver des propriétés des spécifications.
• langages semi-formels : s'appuient sur les caractéristiques techniques de l'implémentation, suppose une expertise chez le lecteur car il en est le vérificateur.

Langages formels :

• précis, analysable.
• maitrise difficile et usage laborieux.
• principalement restreint aux logiciels critiques.

Langages semi-formels :

• suffisant.
• simple à lire et rédiger, peut être graphique.
• décrit le système à plusieurs niveau d'abstractions.

UML, Introduction générale

Langage

• Syntaxe et règles d'écriture
• Représentations graphiques normalisées

Modélisation

• abstraction du fonctionnement de la structure d'un système
• spécification et description

Unifié

• fusion de plusieurs notations antérieures
• standard défini par l'OMG (Object Management Group)

Historique

• 1.0.0 en 1997
• 2.5.1 en 2017

en 1990

• apparition de la programmation structurée objet, nécessité d'une méthodologie de conception adaptée.
• apparition de nombreuses méthodes

en 1994

• consensus sur trois méthodes
  • OMT Object Modeling Technique : représentation graphique
  • BOOSH
  • OSEE

Usage

UML est très large en cas d'usage, et d'autres professions s'en servent également.

En programmation, plusieurs modes :

• Mode esquisse

  • Diagrammes tracés à la main, de manière incomplète.
  • Support de communications abstraites pour concevoir des parties technniques et critiques.

• Mode plan

  • diagrammes formels détaillés.
  • annotations en langue naturelle.
  • Peut être utilisé pour générer des squelettes de codes.

• Mode programmation

  • spécification complète et formelle du système.
  • Est utilisé pour générer un code fini et directement utilisable.

Vue fonctionnelle du système

Vues :

• Cas d'utilisation

  • Description du modèle vu par les utilisateurs du système.
  • Besoins attendus par chaque acteur.

• Logique

  • Définition du système vu de l'intérieur
  • décrit à haut niveau comment satisfaire les besoins des acteurs

• Implantation

  • Dépendance entre les modules

• Processus

  • Vue temporelle
  • illustre le comportement dynamique du système

• Déploiement

  • Distribution des instances du système

14 types de diagrammes, organisés en hiérarchie

• Diagrammes structurels : Classes, Objets ...
• Diagrammes comportementaux : Cas d'usage, états ...
• Diagrammes d'interactions : Séquence, communications ...

Spécification :

• Diagrammes de cas d'utilisation
  • Illustre les besoins des utilisateurs.
• Diagrammes de séquence
  • Scénarios d'intéractions entre le logiciel et l'extérieur.
  • Pas de détails sur les différents composants du systèmes.
• Diagrammes d'activité
  • Enchainement d'actions représentatn un comportement du logiciel.

Conceptions :

• Diagrammes de classes : structure interne du logiciel
• Diagrammes d'objet : état interne du logiciel à un instant de l'execution
• Diagrammes de séquences : intéractions entre les objets lors d'une procédure

Briques de bases

• Les éléments :
  • Les abstractions essentielles au modèle.
• Les relations :
  • Les relations expriment les liens existatnts entre les différents éléments.
• Les diagrammes :
  • Représentations visuelles des éléments du systèmes.
  • Donnent une vue partielle du système, l'ensemble de ses diagrammes doit donner une vue globale.

Diagramme de cas d'usage

Pourquoi ?

• permet au client de spécifer ses besoins :
  • Parvenir un accord / contrat entre clients et développeurs.
  • Point d''entrée pour les étapes suivantes de conception et développement.

Décrit un usage

• USage que les acteurs font du système
  • Acteur : Entité extérieure qui interagit avec le système
    • Une même personne peut jouer le roles de différents acteurs.
    • un acteur peut être une personne ou bien un autre système.
  • Généralement composés de plusieurs scénarios
    • Scénario de base (cas nominal).
    • Et ses variantes (cas particuliers).

Comment découvrir les cas d'usages ?

• délimiter le périmètre du système
• identifier les acteurs interagissant avec le système
  • ceux qui utilisent le système
  • ceux qui fournissent un service au fonctionnement du système
• identifier les acteurs principaux
  • qui utilisera ce système, et pourquoi ?
• définir les cas d'utilisation correpsondant à ces buts

Éléments

• Des acteurs :

  • un rôle dans le système
    • pas forcément une personne physique
    • potentiellement un autre logiciel
  • une même personne ou système peut représenter plusieurs acteurs
  • principal ou secondaire
    • principal : provoque spontanément des échanges
    • secondaire : solicité par le système pour remplir son rôle

• Des cas d'utilisations :

  • Une procédure qu'un acteur peut déclancher avec le système pour répondre à un besoin.
  • Les acteurs impliqués das un cas d'utilisation lui sont liés par une association.
  • Unacteur peut utiliser plusieurs fois le même cas d'utilisation.
  • Peut être en relation avec d'autres cas d'utilisation :
    • Inclusion : A --- includes -> B, 'le cas A inclut le cas B', faire B est une partie de faire A
    • Extension : A <-- extends --- B, 'le cas A étends du cas B', faire A peut impliquer de faire B
    • Généralisation : A <|------------- B, 'le cas A est une généralisation du cas B', faire B est une manière de faire A
  • Les relations indiquent que l'évolution de certains cas d'usages sont susceptible d'avoir un impact sur d'autres.
  • Une relation entre deux acteur ne peut être qu'une généralisation.

Description textuelle

• formalisation contractuelle
• composée de
  • le nom du cas
  • acteurs concernés
  • séquence d'actions
    • pré conditions
    • actions
    • post-conditions
  • contraintes liées à l'interface homme-machine
  • assignation du document (version + date + responsable)

note : En UML, le sens des flèches indique la dépendance d'interface, et non la relation d'inclusion.

c'est à dire : si une flèche va de A vers B

• A dépends de B
• une évolution de l'interface de B peut nécessiter une évolution de A.

exemple : extraction d'un cas d'usage depuis une documentation technique.

The 12 bit [Analog to digital converter (ADC)] is a successive approximation analog-to-digital converter.
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\_ système étudié

It has up to 18 multiplexed channels allowing it measure signals from [16 external] and [two internal] sources.
                              acteurs externes concerné par l'usage _/^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[A/D conversion of the various channels] can be performed in single, continuous, scan or discontinuous mode.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\_ description d'un usage/service

The result of the ADC is stored in a left-aligned or right-aligned 16 bit data register.

The analog watchdog feature allows the application to detect if the input voltage goes outside the use-defined high or low thresholds.

le système : Analog to digital converter (ADC) acteurs : user/application, sources acteurs (alt) : user/application, sources (genéral), 16 external sources, two internal sources cas d'usages : A/D conversion of the various channels