urbanisation-si.com

Une exigence spécifie un besoin ou une règle qui doit être satisfaite.

Une exigence peut spécifier une fonction qu'un système doit exécuter ou des critères de performance à atteindre.

SysML fournit des éléments pour représenter des exigences textuelles et les relier à d'autres éléments de modélisation.

Le diagramme d'exigences décrit les exigences de manière graphique, tabulaire, ou arborescente.

Une exigence peut aussi figurer sur d'autres diagrammes pour montrer sa relation à d'autres éléments de modélisation.

La modélisation des exigences est destinée à fournir une passerelle entre des outils de gestion d'exigences traditionnels et les autres modèles SysML.

Une exigence est définie comme un stéréotype <<requirement>> de classe UML soumise à un ensemble de contraintes.

Une exigence standard inclut les propriétés pour spécifier son identifiant unique (id) et sa description textuelle (text).

Les propriétés supplémentaires comme le statut de vérification, peuvent être spécifiées par l'utilisateur.

 
Plusieurs relations d'exigences sont spécifiées qui permet au modélisateur de relier des exigences à d'autres exigences aussi bien qu'à d'autres éléments de modèles.

On trouve des relations pour définir une hiérarchie d'exigences, des exigences dérivées (<<deriveReqt>>), des exigences satisfaites par d'autres éléments du modèle (<<satisfy>>), des scénarios de tests vérifiant des exigences (<<verify>>) et des exigences affinées (<<refine>>).

Une exigence composite (relation de composition UML) peut contenir des sous-exigences dans une hiérarchie d'exigences, on utilise alors la syntaxe des "namespace" UML.

Cette relation permet à une exigence complexe d'être décomposée avec des exigences enfants.

Une spécification entière peut être décomposée en sous exigences, qui peuvent être elles mêmes décomposées et ainsi de suite pour définir la hiérarchie d'exigences.

On pourra ainsi réutiliser des exigence dans d'autres produits ou projets.

Les scénarios typiques sont des exigences réglementaires, statutaires, ou contractuelles applicables à des produits et à des projets.

On doit pouvoir faire référence à une exigence qui peut donc se trouver dans des contextes multiples ou bien mettre à jour l'exigence d'origine et propager  les modification aux exigence réutilisées.

Puisque le concept de réutilisation d'exigences est très important dans beaucoup d'applications, SysML présente le concept d'une exigence esclave. Une exigence esclave est une exigence dont la propriété de description textuelle est une copie (stéréotype <<copy>>) en lecture seule de la même propriété d'une exigence maître. La description textuelle de l'exigence esclave est contrainte pour être le même que la description textuelle de l'exigence maître liée. La relation maître/esclave est indiquée par l'utilisation de la relation de copie (stéréotype <<copy>>).

La relation <<deriveReqt>> exprime un relation logique entre une exigence de haut niveau et des sous exigences.

A partir d'une exigence source, l'analyse détermine des exigences dérivées.

Les exigences dérivées correspondent généralement aux exigences de niveau inférieur de la hiérarchie de système.

Par exemple, une exigence d'accélération de véhicule peut impliquer des exigences sur la puissance du moteur, le poids du véhicule et le coefficient de traînée.

 
La relation <<satisfy>> décrit comment une conception ou un modèle de mise en œuvre satisfait une ou plusieurs exigences.

Un modélisateur de système spécifie les éléments de conception du système qui sont destinés pour satisfaire l'exigence.

Dans l'exemple ci-dessus, la conception du moteur satisfait l'exigence de puissance du moteur.

La relation <<verify>> définit comment un scénario de test ou d'autres éléments de modèle vérifient une exigence.

Dans SysML, un scénario de test ou d'autres éléments de modélisation peuvent être utilisés comme un mécanisme général pour représenter n'importe laquelle des méthodes de vérification ou de simulation.

Des sous-classes supplémentaires peuvent être définies par l'utilisateur si nécessaire pour représenter des méthodes de vérification différentes.

Une propriété (verdict) peut être utilisée pour représenter le résultat de vérification d'un scénario de test.

La relation d'exigence <<refine>> peut être utilisée pour décrire comment un élément de modèle peut être utilisé pour affiner une exigence.

Par exemple, un cas d'utilisation ou un diagramme d'activité peuvent être utilisés pour affiner une exigence fonctionnelle textuelle.

Cette relation <<refine>> peut aussi être utilisé pour montrer comment une exigence textuelle détaille un élément de modèle.

Dans ce cas, une description textuelle détaillée pourrait être utilisé pour expliquer un élément modèle possédant une granularité moins fine.

Une relation d'exigence de trace générique (<<trace>>) fournit une relation universelle entre une exigence et un autre élément de modèle.

La sémantique de trace laisse de la souplesse au modélisateur car elle n'inclut aucune contrainte réelle.

En conséquence, il est recommandé que la relation de trace ne soit pas utilisée en même temps que les autres relations d'exigences décrites ci-dessus.

Un commentaire stéréotypé <<rationale>> peut représenter un algorithme, une expression de besoin, un processus ou un ensemble de règles rattachées à une relation <<satisfy>> pour justifier les exigences et servir de référence à la conception.

De la même manière on pourrait relier le commentaire stéréotypé <<rationale>> à d'autres relations comme la relation <<deriveReqt>>.

Il fournit aussi un mécanisme alternatif pour capturer la relation <<verify>> en attachant un besoin ou une règle à une relation <<satisfy>> qui fait référence à un scénario de test.

 
Les modélisateurs peuvent personnaliser des taxonomies d'exigences en définissant des sous-classes supplémentaires du stéréotype d'exigence.

Par exemple, un modélisateur peut vouloir définir des catégories d'exigences comme des exigences opérationnelles, fonctionnelles, non fonctionnelles, d'interface, de performance, physique, de stockage, d'activation/désactivation, de contraintes de conception et d'autres exigences spécialisées comme la fiabilité et la maintenabilité, ou encore représenter un besoin de partie prenante (sponsor) de haut niveau.

Le stéréotype permet au modélisateur d'ajouter des contraintes qui limitent les types des éléments de modèles qui peuvent être liés à la relation d'exigence <<satisfy>>.

Par exemple, une exigence fonctionnelle peut être contrainte pour qu'elle puisse seulement être satisfaite par un comportement SysML comme une activité, une machine d'état, ou une interaction.

Rhona Maxwel

@rhona_helena

"Le bonheur : petits plaisirs, équilibre, goût de la vie, optimisme, fantaisie, énergie, poésie."
Emmanuelle de Boysson

Voir aussi :  

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/

Comme le mécanisme d’allocation est très général, SysML n’a pas ajouté un diagramme spécifique, mais plutôt un mécanisme avec plusieurs représentations graphiques disponible dans de nombreux diagrammes.

C'est le terme utilisé par les ingénieurs système pour représenter une cartographie d'un système, la "trans-association" d'éléments appartenant à des structures diverses ou à des hiérarchies d'un modèle utilisateur.

Le concept d'allocation offre la flexibilité appropriée pour la spécification de systèmes abstraits, plutôt qu'une méthode détaillant les contraintes d'un système ou la conception logiciel.

Les modélisateurs de système associent souvent des éléments différents dans un modèle utilisateur en affinant au cours des itérations la manière de réaliser ces liens.

Les allocations peuvent être utilisées tôt dans la conception,  comme par exemple dans un cahier des charges aux spécifications rigoureuses et détaillées concernant les mises en œuvre.

La relation d'allocation peut fournir un  moyens efficace pour naviguer dans le modèle en établissant des relations mutuelles et en assurant que les différentes parties du modèle sont correctement intégrées.
Un exemple typique est l'allocation d'activités de blocs (par exemple, des fonctions aux composants).

La relation d'allocation se traduit graphiquement par une flèche pointillée avec le mot-clé « allocate », un compartiment spécifique avec les mots-clés allocatedFrom, allocatedTo, une note, etc

On peut montrer les éléments de diagramme définis par la relation d'allocation sur certains ou tous les types de diagramme SysML, en plus des éléments de diagramme spécifiques pour chaque type de diagramme.
Dans la liste ci-dessous, "elementType" lié aux mots clés "allocated-to" ou "allocated-from" est applicable à un des artefacts de modélisation suivant : "activity", "action", "objectFlow", "controlFlow", "objectNode", "operation", "block", "property", "itemFlow", "connector", "port", "value".
Il est important d'utiliser des noms entièrement qualifiés pour éviter toute ambiguïté  : PackageName :: ElementName. PropertyName

Le diagramme de cas d'utilisation (use case) décrit l'utilisation d'un système (subject) par ses acteurs pour atteindre un but.

Le diagramme de use case SysML est identique à celui d'UML, voir l'article que j'y avais consacré :

"Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 14ème partie - Cas d’Utilisation – UML – Diag. Use Case"

https://www.urbanisation-si.com/urbanisation-si-la-methode-ultime-pour-modeliser-les-besoins-d-un-projet-14eme-partie-cas-dutilisation-uml-diag-use-case

Le système réalise les objectifs et fourni un ensemble de services aux acteurs.

Le cas d'utilisation peut aussi être vu comme la fonctionnalité qui est accomplie par l'interaction entre le système et ses acteurs.

Les diagrammes de cas d'utilisation incluent les cas d'utilisation, les acteurs et les communications associées entre eux.

Les acteurs représentent les rôles joués par les acteurs lorsqu'ils interagissent avec le use case.

Les rôles sont externes au système peuvent correspondre aux utilisateurs, à des systèmes et ou d'autres entités environnementales.

Ils peuvent interagir directement ou indirectement avec le système.

Les acteurs sont souvent spécialisés par des relations d'héritage pour représenter une taxonomie de types d'utilisateur ou des systèmes externes.

Le diagramme de cas d'utilisation est une méthode pour décrire les utilisations du système.

L'association entre les acteurs et le cas d'utilisation représente les interactions entre les acteurs et le système qui va réaliser la fonctionnalité correspondant au cas d'utilisation.

La frontière du système peut être représenté via un rectangle entourant les use case représentés par des ovales.

Les cas d'utilisation qui sont inclus dans la frontière du système représentent la fonctionnalité qui est réalisée par des comportements comme des diagrammes d'activité, des diagrammes de séquence et des diagrammes de machine d'état.

Les relations de cas d'utilisation sont "la communication", "include", "extend" et "generalization".

Les acteurs sont connectés pour utiliser des cas d'utilisation via des chemins de communication, qui sont représentés par une relation d'association.

La relation "include" permet de factoriser une fonctionnalité commune qui est partagée entre plusieurs cas d'utilisation et est obligatoire pour atteindre le but de l'acteur du cas d'utilisation de base.

La relation "extend" fournit une fonctionnalité facultative (dans le sens ou elle n'est pas nécessaire pour atteindre le but du use case), qui prolonge le cas d'utilisation de base aux points d'extension définis dans des conditions indiquées.

La relation "generalization" fournit un mécanisme d'héritage pour spécifier les variantes du cas d'utilisation de base.
Les cas d'utilisation sont souvent organisés dans des packages avec les dépendances correspondantes entre les cas d'utilisation.

Rhona Maxwel

@rhona_helena

"La haine, c'est la colère des faibles."
Alphonse Daudet

Voir aussi :  

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/

 

Le diagramme d'état permet de modéliser de manière exhaustive l'ensemble des transitions d'état d'un système (automate à états finis ).

L’événement à l'origine de la transition, les activités invoquées pendant la transition, l'entrée et la sortie des états ainsi que les conditions, sont spécifiées sur la flèche représentant la transition.

Les activités invoquées dans l'état sont spécifiées avec le mot clé"do <le nom de l'activité>" et peuvent être continues ou discrètes.

Un état (composite) peut être composé d'états imbriqués qui peuvent être séquentiels ou parallèles.
Le concept UML de "machines d'état de protocole" est exclu de SysML pour réduire la complexité du langage.

La norme UML de concept de machine d'état est suffisante pour exprimer des protocoles.

Dans UML, tous les comportements sont des classes, y compris des machines d'état et leurs instances sont les exécutions de la machine d'état. Les états sont comme des blocs et les associations entre les états correspondent à des sous états, ils ont une sémantique analogue aux activités représentées par des blocs et les associations entre les activités permettent d'appeler les actions.

De même les associations entre des machines d'état et des classificateurs (comme des blocs ou des types de valeur) ont une sémantique analogue aux associations entre des activités et des blocs, mais avec le mot clé "stateMachine" et peuvent être utilisés pour indiquer que le stéréotype de Bloc est appliqué à une machine d'état.

Les propriétés "AdjunctProperty" (stéréotype "adjunct" sur la composition) correspondent à des états de sous-machine et peuvent être utilisées comme l'extrémité des associations vers la machine de sous état.

Les propriétés "AdjunctProperty" (stéréotype "adjunct" sur la composition)  peuvent aussi être des paramètres de la machine d'état et peuvent être utilisées comme l'extrémité des associations vers le type de paramètre.
"AdjunctProperty" peut apparaître dans des contraintes quand il est utilisé avec des états de sous-machine et des paramètres.

Des machines d'état dans des diagrammes de définition de bloc peuvent aussi apparaître avec la même notation que des états de sous-machine.

Rhona Maxwel

@rhona_helena

"Face à l'obstacle, l'homme moyen abandonne ce qu'il a entrepris. Un grand esprit ne se lasse pas et termine ce qu'il a commencé, même si mille fois des obstacles se dressent devant lui, jusqu'à ce qu'il ait remporté le succès."
Sagesse hindoue

Voir aussi :  

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/

Rhona Maxwel

@rhona_helena

"L'esprit est le contraire de l'argent, moins on en a, plus on est satisfait."
Voltaire

Voir aussi :  

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/

Le diagramme de séquence est utilisé pour décrire les interactions entre des entités.

Dans le langage de modélisation générique UML, les Interactions sont représentées selon quatre diagramme :

• le diagramme de séquence,
• le diagramme de communications,
• le diagramme de vue  d'ensemble d'interaction
• le diagramme de temps. 

Le diagramme de séquence est le plus utilisé des diagrammes d'interaction.

SysML inclut le diagramme de séquence seulement et exclut le diagramme de vue d'ensemble d'interaction et le diagramme de communication qui ressemble trop au diagramme de séquence en présentant que peu de fonctionnalités supplémentaires. Le diagramme de temps est aussi exclu en raison des préoccupations des entreprises qui ont peu de retours d'expérience à son sujet et de la pertinence pour les besoins en ingénierie des systèmes.
Le diagramme de séquence décrit le flux de contrôle entre des acteurs et des systèmes (blocs) ou entre les parties d'un système.
Ce diagramme représente l'envoi et la réception de messages entre les entités interagissantes appelées des lignes de vie, où le temps est représenté le long de l'axe vertical.

Les diagrammes de séquence peuvent représenter des interactions fortement complexes avec des constructions spéciales pour représenter tous les types de logique de contrôle des langages de programmation (test "alt", boucle "loop", goto "ref"...), des interactions de référence sur d'autres diagrammes de séquence et la décomposition de lignes de vie dans leurs parties constitutives.

Rhona Maxwel

@rhona_helena

"Il n'est rien de si absent que la présence d'esprit."
Rivarol

Voir aussi :  

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/

Rhona Maxwel

@rhona_helena

"La plus grande gloire n'est pas de ne jamais tomber, mais de se relever à chaque chute."
Confucius, philosophe

Voir aussi :  

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/

 

SysML étend le contrôle dans des diagrammes d'activité :

• Dans des Activités UML, le contrôle peut seulement permettre aux actions de commencer. SysML étend le contrôle pour supporter la mise hors de service des actions qui s'exécutent déjà . Ceci est accompli en fournissant une bibliothèque modèle avec un type pour les valeurs de contrôle qui sont traitées comme des données (ControlValue).
• Une valeur de contrôle est une entrée/sortie d'un opérateur de contrôle, qui agit comme des données. Un opérateur de contrôle peut représenter une opération logique complexe qui transforme ses données en entrées pour produire des données en sortie qui contrôle d'autres actions.

SysML fournit les extensions regroupées sous le terme "continuité", mais sont généralement applicables à n'importe quel sorte de flux distribué d'entités de type information et/ou physiques pour un système. Ceux-ci sont :

• Des Restrictions sur le débit du flux d'entités dans une activité, ou dans des paramètres d'un comportement. Ceci inclut aussi bien les flux discrets que continus, de matière, d'énergie, ou d'informations. Des flux discrets et continus sont unifiés sur le débit, comme s'est fait traditionnellement dans les modèles mathématiques de changement continu, où l'incrément discret de temps tend vers zéro.
• L'extension de nœuds d'objet, y compris les "pins" (connecteur de nœuds d'objet en UML), avec l'option pour la nouvelle valeur arrivée, de remplacer les valeurs qui sont déjà dans les nœuds d'objet (Overwrite). SysML étend aussi les nœuds d'objet avec l'option de rejeter les valeurs qui ne se seraient pas écoulées immédiatement en aval (NoBuffer). Ces deux extensions sont utiles pour assurer que les informations les plus récentes soient disponibles pour des actions en indiquant quand des anciennes valeurs ne devraient pas être gardées dans des nœuds d'objet et pour empêcher que des valeurs s'écoulent continuellement et se rassemblent dans un nœud d'objet, aussi bien que de modéliser des valeurs passagères, comme des signaux électriques.

SysML présente les probabilité dans des activités :

• L'extension sur les bords des activités avec les probabilités pour que vraisemblablement une valeur quitte le nœud de décision ou le nœud d'objet et traverse le bord.
• L'extension pour que des paramètres de sortie soient valorisés selon des probabilités.

Dans UML, tous les comportements incluant des activités sont des classes et leurs instances sont des exécutions.

Les comportements peuvent apparaître sur des diagrammes de définition de bloc et participer des généralisations et des associations.

SysML clarifie la sémantique :

• d'association et de composition entre des activités
• entre des activités et le type de nœuds d'objet dans les activités
• des règles de cohérence entre ces diagrammes et des diagrammes d'activité.

Le modèle de temps dans UML peut être utilisé pour représenter le temps et des contraintes de durée d'actions dans un modèle d'activité.
Ces contraintes peuvent être notées comme des notes de contrainte dans un diagramme d'activité.

Bien que le diagramme UML 2 de "timing" n'a pas été inclus dans cette version de SysML, on pourra l'utiliser pour compléter les diagrammes de comportement SysML.

Si besoin, on peut intégrer contrainte plus complexes avec les "blocs de contraintes".

Rhona Maxwel

@rhona_helena

"L'argent, jusqu'à ce jour, était le fumier dans lequel poussait l'humanité de demain; l'argent, empoisonneur et destructeur, devenait le ferment de toute végétation sociale, le terreau nécessaire aux grands travaux qui facilitent l'existence."
Émile Zola

Voir aussi :  

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/

 

Les blocs de contrainte fournissent un mécanisme pour intégrer les fonctions d'ingénierie comme la performance et la fiabilité.

Les blocs de contrainte peuvent être utilisés pour spécifier un système de contraintes qui représentent des expressions mathématiques comme {F=m*a} et {a=dv/dt}, qui contraint les propriétés physiques d'un système.

De telles contraintes peuvent aussi être utilisées pour identifier des paramètres de performance critiques et leurs relations à d'autres paramètres, qui peuvent être suivis à la trace partout dans le cycle de vie de système.
Un bloc de contrainte inclut la contrainte, comme {F=m*a} et les paramètres de la contrainte comme F, m et a.
 
Des définitions de contrainte réutilisables peuvent être spécifiées sur des diagrammes de définition de bloc et mis dans des bibliothèques de modèles universelles ou spécifiques à un domaine.

De telles contraintes peuvent être des expressions mathématiques ou logiques arbitrairement complexes.

Les contraintes peuvent être imbriquées pour permettre à une contrainte d'être définies en termes de contraintes de base comme des opérateurs mathématiques primitifs.
Les diagrammes paramétriques incluent les utilisations de blocs de contrainte pour contraindre les propriétés d'un autre bloc.

L'utilisation d'une contrainte lie les paramètres de la contrainte, comme F, m et a, aux propriétés spécifiques d'un bloc, comme une masse, qui fournit des valeurs pour les paramètres.

Les propriétés contraintes, comme la masse ou le temps de réponse, ont typiquement les types de valeur simples qui peuvent aussi porter des unités, des types de quantité, ou des distributions de probabilité.

Un nom de chemin avec une notation intégrant le point comme séparateur, peut être utilisée pour se référer aux propriétés imbriquées dans une hiérarchie de bloc.

Ceci permet à une propriété de valeur (comme un déplacement de moteur) qui peut être profondément imbriquée dans une hiérarchie de conteneur (comme le véhicule, l'installation électrique, le moteur), d'être référencée au niveau conteneur extérieur (comme des équations de niveau de véhicule).

Le contexte, pour les utilisations de blocs de contrainte doit aussi être spécifié dans un diagramme paramétrique pour maintenir l'espace de nom approprié pour les propriétés imbriquées.

 
Le temps peut être modélisé comme une propriété dont d'autres propriétés peuvent dépendre.

Une référence de temps peut être établie par une horloge locale ou globale qui produit une propriété de valeur de temps continue ou discrète.

D'autres valeurs de temps peuvent être tirées de cette horloge, en présentant des retards et ou biaiser dans la valeur de temps.

Les valeurs discrètes de temps aussi bien que le temps de calendrier peuvent être tirées de cette propriété de temps globale(mondiale).

SysML inclut le modèle de temps d'UML.

Un état du système peut être spécifié en termes des valeurs de certaines de ses propriétés.

Par exemple, quand la température d'eau est au-dessous de 0 degrés Celsius, il peut passer du liquide au solide.

Dans cet exemple, le changement de l'état aboutit à un ensemble différent d'équations de contrainte. 

Ceci peut être satisfait en spécifiant les contraintes qui sont conditionnées sur la valeur de la propriété d'état.

 
Des diagrammes paramétriques peuvent être utilisés pour modéliser les inter dépendances entre les paramètres.

Un bloc de contrainte peut définir une fonction objective pour comparer des solutions alternatives.

SysML identifie et nomme des blocs de contrainte, mais ne spécifie pas de langage informatique exécutable pour eux.

On doit fournir l'interprétation d'un bloc de contrainte donné (par exemple, une relation mathématique entre ses valeurs de paramètre).

Un bloc de contrainte est défini par un mot-clé "constraint" appliquée à une définition de bloc.

Les propriétés de ce bloc définissent les paramètres de la contrainte.

Un diagramme paramétrique est une forme limitée de diagramme de bloc interne qui montre seulement l'utilisation de blocs de contrainte avec les propriétés qu'ils contraignent dans un contexte.

Rhona Maxwel

@rhona_helena

"L'homme naît sans dents, sans cheveux et sans illusions, et il meurt de même, sans cheveux, sans dents et sans illusions."
Alexandre Dumas

Voir aussi :  

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/

Le but principal à la spécification des ports et des flux est d'obtenir une modélisation modulaire basée sur des blocs réutilisables définissant les manières de connecter et d'interagir avec leur contexte.

SysML étend la norme UML avec les ports imbiqués, les ports étendus pour supporter les propriétés de flux et les fonctionnalités requises et fournies, incluant les blocs et les types de ports.

Les ports peuvent être typés avec des blocs supportant des opérations, des réceptions et des propriétés comme dans UML.

SysML défini des blocs spécifiques (InterfaceBlock) qui peuvent être utilisés pour supporter les ports imbriqués.

SysML identifie 2 types de ports, un qui expose des fonctionnalités des blocs qu'il possède ou ses ports internes (proxy ports), et un autre supportant ses propres fonctionnalités (full ports).

Des règles de compatibilité sont définies pour l'usage des connexions des blocs comme les parties et les ports. Elles peuvent  redéfinies avec les associations entre blocs.

Ces fonctionnalités supplémentaires offrent au modeleur un large éventail pour interconnecter des composants qui peuvent être implémentés au travers de nombreuses techniques logiciels, électrique ou mécaniques ainsi que par des organisations humaines.

Ces extensions permettent aussi de spécifier les flux au travers des connecteurs et des associations.

Un port est donc un point de connexion auquel des entités externes peuvent se connecter et interagir avec le bloc de manières différentes ou limitées  qu'une simple connexion directe avec le bloc lui-même.

Un port est une propriété typée spécifiant les fonctionnalités disponibles d'une entité externe via un connecteur sur le port.

Les fonctionnalités sont des propriétés, des extrémités d'association, des opérations et réceptions.

 Les blocs avec des ports peuvent typer d'autres ports. Les propriétés "flux" spécifient les types d'éléments transitant entre un bloc et son environnement, que ce soit de la donnée, matériel ou énergétique.

Les catégories de flux sont spécifiées en typant les propriétés "flux".

Par exemple un bloc spécifiant une transmission automatique de voiture peut avoir une propriété "flux" en entrée et une autre en sortie.

Les fonctions requises et fournies sont des opérations/réceptions pour que blocs puissent utiliser d'autres blocs.

Par exemple un bloc peut fournir un service particulier à un autre bloc ou il peut nécessité l'utilisation de services d'un autre blocs.

Un port peut avoir des ports imbriqués.

Par exemple le port supportant le couple de torsion dans la transmission peut avoir des ports imbriqués pour le lien physique avec le moteur

SysML identie 2 usages pour les ports, un où le port joue le rôle de proxy pour son bloc ou les parties internes et un autre ou le port spécifie des éléments séparés dans le systéme (full).

Les 2 représente des façons de définir la frontière du bloc proposant des fonctionnalités au travers de ports permettant des connexions vers l'extérieur.

Les ports "proxy" définissent la frontière en spécifiant quelles fonctions du bloc  ou des parties internes sont visibles des connecteurs externes tandis que les ports "full" définissent la frontière avec leurs propres fonctions.

Les ports "proxy"sont toujours typés avec des blocs interfaces qui sont des blocs spécialisés sans comportements et sans parties.

Les ports "full" gèrent directement des fonctionnalités plutôt que d'exposer  les fonctionnalités du bloc propriétaire ou parties internes du bloc propriétaire.

Les ports qui ne sont ni "proxy", ni "full" sont de simples ports appelés "ports".

Autrement dit, les utilisateurs d'un bloc sont seulement concernés par les fonctionnalités de ses ports ou bien par les fonctionnalités filtrées et adaptées proposées par les "proxy" ports ou gérées directement par les "full" ports.

Les ports "proxy" ou "full" supportent les spécifications des ports classiques ou simples.

Le modélisateur peut choisir entre "proxy" et "full" à n'importe quel moment du cycle de vie du développement et n'est pas dépendant de la méthode.

Les fux d'éléments spécifient les entités circulant entre les blocs et/ou les ports au travers des associations ou des connecteurs.

Tandis que que les propriétés de type flux spécifie ce qui peut transiter en entrée ou en sortie d'un bloc,  les flux d'éléments spécifient quel est le flux entre les bloc et/ou les composants dans un contexte et pour un usage particulier.

Cette distinction permet au blocs d'être interconnectés de différentes manières selon les contextes.

Par exemple un réservoir peut avoir une propriété flux pouvant accepter un fluide en entrée. Pouu usage particulier, de l'essence peut circuler à travers un connecteur à l'intérieur du réservoir et pour un autre usage c'est de l'eau qui peut transiter.

Les flux d'éléments peuvent être allouer à partir des objets d'un diagramme d'activité ou des signaux envoyés d'une machine à états (automate à états finis).

Rhona Maxwel

@rhona_helena

"Le bonheur humain est composé de tant de pièces qu'il en manque toujours."
Bossuet

Voir aussi :  

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/