LG

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
SysML est à UML ce que NoSQL est à SQL. On passe d'une approche document à une approche modèle.

Modélisation intégrée : il faut adresser tous les aspects du Système. Base commune pour la conception, la compréhension et la validation. Gérer le développement, documentation, représentation plus complète.

On commence par modéliser la couche la plus haute (le niveau opérationnel) et on descend jusqu'à (la couche composants).
   * Opérationnel : boite noire qui rend des services, des cas d'utilisation, des interfaces, IHM.
   * Système : architecture : assemblages des composants liés par des connecteurs.
   * Connecteur : respect des spécifications.

Langage graphique.

Supporte la spécification, l'analyse, la conception, la vérification (conforme aux process) et la validation (le résultat).

SysML contient une bonne partie de UML2 plus des extensions : blocs, item flow, value properties, allocations, exigences, paramétriques, flots continus.

Un bloc peut contenir des (une rubrique dans chaque case de l'UML) :
   * propriétés : valeurs (avec type, unité, dimension, probabilité/précision), références (aggrégation, partage entre plusieurs éléments), parties (composition),
   * opérations : méthodes,
   * contraintes,
   * allocations : lien (mapping) de/vers d'autres éléments d'autres diagrammes, d'activités souvent,
     * comportementale : fonction vers un constituant/composant,
     * structurelle : élément logique vers élément physique. logiciel -> oracle,
     * logiciel vers matériel.
     * allocation explicite avec des couloirs d'activités.
   * exigences,
   * comportements : définis par l'utilisateur.

Les ports :
   * Ils sont points d'interaction sur les blocs et les parties.
   * Ils ont un nom et un type.
   * Deux catégories :
     * port standard (UML, définit des services/API/etc requis ou fourni),
     * Flow port, flux continu (définit ce qui transite par le port).
   * Délégation de ports : proposer une interface/boite noire.

Type de diagrammes :
   * Diagrammes de structure (structure diagrams) (UML 2) : 
     * Diagramme de structure composite (block definition diagram BDD) (UML 2 modifié) : peut se définir comme une classe avec un stéréotype bloc. Renseigne de quoi est fait le système physique (les composants, les logiciels, l'humain, …). Possibilité d'héritage. Définition des relations entre blocs (composants) avec des connecteurs pour représenter des architectures/hiérarchies. L'usage des blocs est dans les diagrammes d'activités.
     * Diagramme de structure composite (internal block diagram IBD) (UML 2 modifié) : définit les propriétés d'un bloc et indique les interactions via des connecteurs entre les composants (diagramme interne). Les flèches indiquent l'interaction. Les blocks en composition sont en trait plein et les blocks en agrégation sont en trait pointillé.
     * Diagramme des paquets (package diagram) (UML 2) : c'est une sorte de répertoire. Classement au choix : par phase de projet, par sous-système. Possibilité de regrouper les paquets dans des vues.
   * Diagramme de comportement (behavior diagram) (UML 2) : description des activités.
     * Diagramme d'activité (activity diagram ACT) (UML 2 modifié) :
       * verbaliser les actions, analyse fonctionnelle.
       * Effectue une liste contrôlée d'action en fonction des paramètres d'entrée.
       * Responsabilité va des séparations en "couloir d'activités".
       * Extension : Flux continus (courant électrique, …) et diagramme fonctionnel de flux amélioré (noter les échanges d'information entre les actions et quand un bloc/flux se déclenche/s'arrête).
       * Une action peut être décrite comme une activité.
       * Une action prend une entrée fixe qui ne peut pas être modifiée durant l'action, elle est de type non Stream. Si l'entrée peut être modifiée (continue, échantionnée), elle s'appelle un stream.
       * Type d'action :
         * atomique (call operation action),
         * complexe (call behavior action), détaillé dans un diagramme d'activité.
         * réception d'un événement (accept event action),
         * émission d'un signal (send signal action).
       * Dessin :
         * Activité : rectangle à bords arrondis.
         * Pin In/Out : rectangle.
           * Sur le bord contour du diagramme s'ils sont des paramètres d'entrée ou des flux de sortie de l'activité.
           * Contre le bloc si la pin reste interne au diagramme. Possibilité de remplacer les 2 pin par un bloc.
         * Trait continu : transfert d'information/signal/…, trait pointillé : flot de contrôle, événement déclenchant une activité.
         * Rond plein : début de l'activité.
         * Rond plein avec auréole blanche : fin de l'activité.
         * Rond blanche avec croix interne : fin de l'activité d'un jeton.
         * Barre gras : dédoublement d'un jeton (fork) ou attente synchro jeton (seul le premier arrivé passe).
         * symbole de terre en électronique en haut à droite du rectangle action : activité décomposable.
         * cadre en pointillé à l'intérieur du diagramme : zone interruptible.
         * Trait séparant tout le diagramme : couloir d'activité et mettre pour chaque couloir le stéréotype ''allocate''.
     * Diagramme d'interaction/de séquence (sequence diagram) (UML 2),
       * Comportement d'un système et non d'un logiciel.
       * Opérateurs : ref (à un diagramme de séquence), opt + condition (optionnel), alt (alternative), par (parallèle), loop, break, critical, neg, assert, seq(weak)/strict, consider, ignore.
     * Diagramme états-transitions (state machine diagram) (UML 2) :
       * représente le cycle de vie d'un bloc.
       * Les événements déclenchent la transition entre les blocs. Événement Change, time et signal.
     * Diagramme des cas d'utilisation (use-case diagram) (UML 2) : décrire les fonctionnalités (buts et usages) d'un système.
       * 
   * Diagramme d'exigence (requirement diagram) (SysML) :
     * Stéréotype « Requirement »
     * À quoi répondre comme besoin : l'ensemble des exigences font les spécifications.
     * Deux attributs : id + text (description). Les exigences systèmes se transforment en exigence sur les constituants.
     * Chaque exigence peut être composé d'autres exigences. Représentation ⊕ : rond avec un + à l'intérieur.
     * Relation de type :
       * DeriveReqt : relation de dépendance (puissance d'un moteur avec l'accélération d'une voiture),
       * Satisfy : un bloc doit satisfaire une exigence,
       * Verify,
       * Refine,
       * Trace,
       * Copy.
   * Diagramme paramétrique (parametric diagram PAR) (SysML) : indique quelles sont les paramètres nécessaires pour chaque équation. Simulink : permet de vérifier que les assert sont correct en fonction des paramètres d'entrée.