# 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**
