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