concept
This commit is contained in:
parent
a9e60a9ba0
commit
4f2f24fe7e
1 changed files with 239 additions and 0 deletions
239
concept/01_init.md
Normal file
239
concept/01_init.md
Normal file
|
|
@ -0,0 +1,239 @@
|
||||||
|
# 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**
|
||||||
Loading…
Add table
Add a link
Reference in a new issue