Objectifs: Introduction à la notation Use Case Maps (UCM)

SEG 3601- Module 3 Introduction à la notation d’exigences utilisateur (URN) – Partie II: UCM
Objectifs: Introduction à la notation Use Case Maps (UCM) Liens avec GRL dans URN Exemples d’utilisation © Daniel Amyot, Gunter Mussbacher Introduction à la notation UCM/URN

User Requirements Notation - URN
URN est un langage graphique pour la modélisation et l’analyse d’exigences sous forme de buts et de scénarios. Combine deux sous-notations complémentaires: Goal-oriented Requirements Language (GRL) Use Case Map (UCM) Les modèles URN peuvent être utilisés pour divers types de systèmes réactifs, de normes en télécommunications et de processus d’affaires. Site Web: Introduction à la notation UCM/URN

Aperçu de la notation UCM
Use Case Map “Carte de cas d’usage” Une notation graphique pour scénarios Décrit des relations causales entre responsabilités Les éléments d’un scénario peuvent être alloués (optionnellement) à des composantes Les UCM modélisent le « quoi » Scénarios pour exigences fonctionnelles Intégration et réutilisation de scénarios Guide l’architecture et la conception détaillée du comportement Analyse de performance, détection de conflits, transformations Use Case Maps (UCMs) are a scenario-based software engineering technique that have a history of application to the description of object-oriented systems and reactive systems in various areas, including wireless, mobile, and agent domains. UCMs are used as a visual notation for describing causal relationships between responsibilities of one or more use cases, optionally allocated to a structure of abstract components. UCMs are most useful at the early stages of software development and are applicable to use case capturing and elicitation, use case validation, as well as high-level architectural design and test case generation. The combined, gray-box, view of behavior and structure and the flexible allocation of responsibilities to architectural structures bridge the gap between requirements and design. UCMs provide a behavioral framework for evaluating and making architectural decisions at a high level of design, optionally based on performance analysis of UCMs. Moreover, UCMs provide its users with dynamic (run-time) refinement capabilities for variations of scenarios and structure and allow incremental development and integration of complex scenarios. Introduction à la notation UCM/URN

Exemple: Se rendre au travail (du cercle au rectangle)
Notation UCM de base Exemple: Se rendre au travail maison transport ascenseur sécuriser maison X X prendre ascenseur X navette prêt à quitter au bureau [Am99] The UCM notation is composed of path elements and components. Imagine tracing a path through a system of objects to explain a causal sequence, leaving behind a visual signature. Use Case Maps capture such sequences. The basic path notation addresses simple operators for causally linking responsibilities in sequences, as alternatives, and in parallel. Responsibilities represent generic processing. Paths connect start points, responsibilities, and end points. Start points may have preconditions attached, while responsibilities and end points can have post-conditions. Components can be of different natures, allowing for a better and more appropriate description of some entities in a system. A responsibility is said to be bound to a component when the cross is inside the component. In this case, the component is responsible to perform the action, task, or function represented by the responsibility. Chemin (du cercle au rectangle) Responsabilité Composante (générique) Introduction à la notation UCM/URN

Notation UCM – Hiérarchies (avec stubs)
Exemple: Se rendre au travail maison transport ascenseur sécuriser maison prendre ascenseur sécuriser maison X navette X prendre ascenseur prêt à quitter X navette au bureau reste à la maison [Am99] When maps become too complex to be represented as one single UCM, containers called stubs may be used. Stubs link to sub-maps called plug-ins. Static stubs contain only one plug-in and enable hierarchical decomposition of complex maps. Dynamic stubs may contain several plug-ins, whose selection can be determined at run-time according to a selection policy (often described with pre-conditions). It is also possible to select multiple plug-ins at once (sequentially or in parallel). At the moment, the composition requires to be detailed outside the UCM diagram although some formalism in the form of global Boolean variables is provided. Stubs are similar in concept to commonality/variability. Stubs are similar in concept to polymorphism although more broadly applicable (e.g. selection policy may select more than one plug-in). Stub dynamique (avec politique de sélection) Stub statique Introduction à la notation UCM/URN

Notation UCM – Enfichable (plug-in) simple
Exemple: Navette - Auto (enfichable) transport aller en auto allé en auto X conduire auto Depending on the preconditions (i.e. preferences of the commuter), either the car plug-in or the bus plug-in will be selected (i.e. selection depends on the installed features). The postconditions and results of responsibilities and plug-ins become preconditions for responsibilities or plug-ins further down the path. One can think of assertions being made along the path and being used further down the path. Introduction à la notation UCM/URN

Notation UCM – Parallélisme & Alternatives
Exemple: Navette - Autobus (Enfichable) personne lire Dilbert X transport prendre bus X prendre 95 X prendre 182 X prendre 97 allé en bus [Am99] An OR-join merges two (or more) overlapping paths while an OR-fork splits a path into two (or more) alternatives. Alternatives may be guarded by conditions represented as labels. Concurrent and synchronized segments of routes are represented through the use of a vertical bar. An AND-join synchronizes two (or more) paths together while an AND-fork splits a path into two (or more) concurrent segments. Note: the stub - plug-in map relationship is not purely hierarchical. The exemple shows the same “Transport” component on the plug-in map as is shown on the root map and, in addition, the “Person” component. Fourche ET Fourche OU Jonction OU Jonction ET Introduction à la notation UCM/URN

Notation UCM – Place d’attente / Minuterie
Exemple: Prendre ascenseur - Défaut (Enfichable) ascenseur demande ascenseur X X choisit étage arrivé arrivé prendre ascenseur ascenseur arrive X prend l’escalier [Am99] Timer is a special waiting place triggered by the timely arrival of a specific event. It can also trigger a timeout path when this event does not arrive in time. The exact behavior of a waiting place or timer has to be specified, e.g. 1) regular waiting place where both paths synchronize, 2) memory for collecting events from the triggering path, 3) signal where the path continues with a Yes assertion if there was a triggering event or with No assertion if there was no event, 4) delay (no separate timeout path), 5) timer (with timeout path) Minuterie (place d’attente spéciale) Place d’attente Chemin d’expiration Introduction à la notation UCM/URN

Notation UCM - Enfichables et souches
Exemple: Sécuriser Maison - Défaut (Enfichable) maison alarme quitte X barre porte in out1 X utilise autre système d’alarme out2 parti reste à la maison This default plug-in implies that one always locks the door. The default plug-in for the alarm stub may be just a basic path without any responsibilities (does not do anything). If required, an alarm may be set by selecting a different plug-in. use alternative alarm system: place bucket of water above door, spread poison ivy on floor, or put up string of cans Path segments coming in and going out of stubs can be identified on a use case map. Although they are not required to be shown visually, their presence helps to achieve unambiguous bindings of plug-ins to stubs. There may be any number of private end points as long as an end point is bound to an out path of the stub and the scenario terminates at this point. UCMs do not have to be well-nested (e.g. there is an AND fork on the plug-in map (bottom middle) but an AND join does not have to follow the AND fork) Introduction à la notation UCM/URN

Notation UCM – Enfichable de 2e niveau
Exemple: alarme – Installée (enfichable) maison pas d’alarme [quitte] système d’alarme accepte code X X vérifie code alarme alarmé [pareils] Direction [différents] Exemple: alarme – Non-installée (enfichable) maison fin début Introduction à la notation UCM/URN

Introduction à la notation UCM/URN
Données en UCM La notation UCM inclut un langage de données simple pour les conditions et les expressions Sous-ensemble du langage de données SDL (Rec. Z.100), mais supportant seulement 3 types: Boolean, Integer, et Enumeration Syntaxe textuelle concrète qui supporte à la fois les opérateurs et expressions SDL et Java/C x>100 && jour==LUNDI if (var1 || var2) then var3=35; Introduction à la notation UCM/URN

Use Case Maps – Exécution de scénario (1)
Ce scénario démarre au point de départ “prendre bus”, et se termine au point d’arrivée “bus pris” Exemple: Navette - Autobus (Enfichable) 1ère définition se scénario: Bus95 = false; personne lire Dilbert X 2e définition se scénario : Bus95 = true; transport prendre bus X prendre 95 X prendre 182  X prendre 97  allé en bus Conditions de branchement:  Bus95  !Bus95 Introduction à la notation UCM/URN

3e définition de scénario Installée= true; QuitteEnToutCas= false; ResteMaison= false; UtiliseAutreAlarme= false; 3e scénario: débute à “quitte”, termine à “parti” 4e scénario: débute à “quitte”, termine à “reste à la maison” Politique de sélection : Enfichable «Alarme– Installée»: Installée Enfichable «Alarme – Non-installée»: ! Installée Exemple: Sécuriser Maison - Défaut (Enfichable) maison quitte alarme X Barre porte in out1   X utilise autre système d’alarme out2 reste à la maison parti  4e définition de scénario Installée= true; QuitteEnToutCas= false; ResteMaison= true; UtiliseAutreAlarme= false; Conditions de branchement:  QuitteEnToutCas  UtiliseAutreAlarme  ResteMaison Introduction à la notation UCM/URN

Exemple: alarme – Installée (enfichable) maison pas d’alarme [quitte] Conditions de branchement:  Pareils  !Pareils système d’alarme accepte code X X vérifie code alarme alarmé 3e définition de scénario Pareils= true; Quitte = false;  [pareils]   Conditions de branchement:   Quitte [différents]  !Quitte 4e définition de scénario Pareils= true; Quitte = true; Exemple: alarme – Non-installée (enfichable) maison début fin Introduction à la notation UCM/URN

Sommaire de la notation UCM de base
Composante Point de départ Responsabilité Stub dynamique Fourche ET Condition Telephone Switch Telephone Switch Telephone Switch Telephone Switch Fourche OU Originating upd vrfy chk IN1 IN1 IN1 IN1 IN1 OUT1 OUT1 OUT1 OUT1 OUT1 [idle] ring [allowed] req b) OCS plug-in map plug-in map b) OCS plug-in map c) default c) default plug-in map s1 s1 s1 e1 e1 e1 [busy] pd [denied] pb prb OUT2 OUT2 OUT2 e2 e2 e2 sig Point d’arrivée a) Basic Call map b) OCS plug-in map Chemin Jonction OU parent: Default parent: Default parent: Default Jonction ET s1 s1 s1 e1 e1 e1 Place d’attente c) default plug-in map Minuterie Stub statique (un seul plug-in) Introduction à la notation UCM/URN

Notation UCM – Exemples de stubs avancés
UCMs are used as a visual notation for describing causal relationships between responsibilities of one or more use cases (scenarios). UCMs show related use cases (scenarios) in a map-like diagram. A path shows the progression of a scenario along a use case by connecting path elements such as start points, responsibilities, and end points. Start points may have preconditions attached, while responsibilities and end points may have post-conditions. Responsibilities are generic and represent processing (e.g. actions, activities, operations, tasks to perform, and so on). The UCM notation includes simple operators for causally linking responsibilities in sequences, as alternatives, and in parallel. The relationships between responsibilities are said to be causal because they link causes (e.g., preconditions and triggering events) to effects (e.g. postconditions and resulting events). Stubs link to sub-maps called plug-ins. Static stubs contain only one plug-in and enable hierarchical decomposition of complex maps. An in-path/start point and end point/out-path binding specifies how the sub-map is plugged into the stub. This Examples illustrates how UCM descriptions abstract from messages, data and control, while focusing on general causal flows between causes, responsibilities, and effects. UCMs are neither dataflow diagrams nor control flow diagrams (where control is often associated to procedure calls or method invocations). This example also shows that basic UCMs can be quite easily expressed with activity diagrams. Explain Tiny Telephone System example (verify whether called party is idle or busy, update system status, prepare busy signal, prepare ringback signal, check whether call should be allowed or denied, prepare call denied signal, OCS … originating call screening) Introduction à la notation UCM/URN

Notation UCM – Composants en paramètres (“Component Bindings”)
Définit la relation entre un composant sur le UCM contenant le stub et un composant sur le UCM de l’enfichable (en supplément de la relation entre les entrées/sorties du stub et les points de départ/arrivée de l’enfichable) Option c: le composant parent joue un rôle, p.e. dans un motif (pattern) architectural ou comportemental C2 parent: Nom C1 b) raffinement c) rôle a) Pas lié d) service Avancé Introduction à la notation UCM/URN

Pourquoi la notation UCM?
Comble l’écart conceptuel entre scénarios, exigences, et conception Relie comportement et structure de façon explicite et visuelle Offre un cadre comportemental pour prendre des décisions architecturale à un haut niveau d’abstraction Décrit le comportement de l’architecture une fois qu’elle est choisie Présente beaucoup d’information sous une forme compacte Les UCM intègrent plusieurs scénarios les uns aux autres Permet de raisonner sur d’éventuels conflits ou interactions indésirables entre scénarios “UML includes several implicit links between these two sets of diagrams (e.g., sequence and collaboration diagrams can use the entities defined in class diagrams). However, UML does not emphasize any first-class and compact way of describing large-scale units of behavior that emerge from the collective efforts of many system components (e.g., transactions spanning a network).” [Am99-2] “There exists a large conceptual gap between use cases and their realization in terms of behavioral diagrams where the system’s internals are refined with sub-components. Reasoning about this gap and the big picture using the current UML diagrams is often puzzling since much mental effort is required to integrate many details from many diagrams of different styles.” [Am99-2] Introduction à la notation UCM/URN

Pourquoi la notation UCM?
Offre la possibilité de modéliser des systèmes dynamiques complexes où les scénarios et la structure peuvent changer lors de l’exécution Services Web, systèmes répartis à base d’agents, systèmes de commerce électronique… Documentation de processus d’affaires et de workflows Bon outil d’apprentissage pour des personnes non familières avec le domaine Un modèle UCM peut être transformé (p.ex. vers MSC, UML, tests, modèles de performance, etc.) Introduction à la notation UCM/URN

Où sont les limites du système?
MonSystème1 MonSystème2 CS CS NA NA Personne IC IC S S CB CB PBA PBA Mêmes scénarios! On peut allouer les responsabilités au système ou encore à son environnement (personnes ou machines). Même chose pour les points de départ et d’arrivée. Notions d’acteur ( ) supportée par la notation. Introduction à la notation UCM/URN

jUCMNav supporte Notation UCM Plusieurs diagrammes par modèle Intégration avec GRL Introduction à la notation UCM/URN

jUCMNav: Connecter enfichables et stubs
Introduction à la notation UCM/URN

Métamodèle abstrait de URN / UCM (I)

Intégration GRL - UCM Approche orientée but Se concentre sur le « pourquoi » Exigences fonctionnelles et non-fonctionnelles Approche orientée scénario Se concentre sur le « quoi » Les buts sont rendus opérationnels grâce aux tâches, elles-mêmes reliées à des scénarios UCM Permet de répondre aux questions sur le « comment » Ces buts permettent aussi de guider la sélection d’une architecture particulière pour les scénarios UCM Permet l’analyse de complétude et de cohérence Buts sans scénarios, ou scénarios sans buts Introduction à la notation UCM/URN

Liens URN (typés) URN permet des liens entre n’importe quelle paire d’éléments URN, tout en permettant de les caractériser. jUCMNav supporte quelques liens communs entre: Acteurs GRL et composantes UCM Tâches (et autres éléments intentionnels) GRL et enfichable/responsabilités UCM Actor Intentional Element Map Component Responsibility Introduction à la notation UCM/URN

Intégrer GRL et UCM Traçabilité entre: Buts/tâches et modèles UCM (ou définitions de scénarios) Tâches et responsabilités UCM Granularité différente Gestion des exigences Autre… Sous-spécification et sur-spécification Découverte de nouveaux buts et scénarios Retrait de buts et scénarios inutiles Exemples: Pourquoi y a-t-il un scénario UCM sans lien vers un but GRL? Pourquoi y a-t-il un but GRL sans lien en provenance d’un scénario ou modèle UCM? Raffinements de solutions alternatives De GRL (identification) vers UCM (évaluation) Introduction à la notation UCM/URN

Intégration UCM-GRL dans l’analyse
Chaque élément intentionnel GRL peut avoir une variable entière UCM correspondante (qui reflète le niveau de satisfaction de l’élément) Une option dans jUCMNav Ces variables peuvent être utilisées dans des conditions UCM, ou mise à jour dans responsabilités. Une stratégie GRL peut donc influencer le choix de chemins UCM à parcourir pendant l’exécution d’un scénario. L’exécution d’un scénario UCM peut donc aussi influencer la satisfaction d’un élément intentionnel GRL Introduction à la notation UCM/URN

URN — Pièce manquante du casse-tête?
Données ASN.1 URN — Pièce manquante du casse-tête? Diagrammes structurels SDL (UIT), ou diagrammes de classes, d'objets, de composantes, déploiement (UML) ? Diagrammes d’activités et de scénarios (use case) UML Exigences informelles, scénarios d'usage textuels URN-NFR / GRL Buts, exigences non-fonctionnelles, altern., raisonnements Les UCM représentent visuellement les scénarios d'usage en terme de relations causales entre responsabilités URN-FR / UCM Superpose visuellement le comportement système sur une structure de composantes abstraites. Remplace les diagrammes de scénarios (use cases) et d'activités d'UML Les UCM sont reliés aux opérations (tâches) des modèles GRL Les UCM combinent visuellement comportement et structure au niveau système Diagrammes comportementaux MSC/SDL (UIT), ou diag. de collabo., de séq., d'états (UML) Langage de test et d'analyse de performance TTCN (UIT), LQN Les UCM offrent un cadre de travail pour prendre des décisions de haut niveau et pour guider la description de modèles plus détaillés GRL and UCM represent essential pieces of the OMG/SG17 language puzzle. Some of the key points are: Goal-based (e.g. GRL) and scenario-based (e.g. UCMs) notations complement each other. GRL and UCMs, as part of the User Requirements Notation (URN), propose to fill a void in methodologies based on ITU-T languages UCMs offer more capabilities than UML use case diagrams and activity diagrams for requirements-level descriptions and analysis Compared to other scenario notations, UCMs are graphical, do not require components with interactions/messages, and support dynamic behavior and structures well URN fits well into scenario-based software development methodologies GRL provides the decision making framework for software engineering activities, and supports the documentation of decisions UCMs become the focal point for early activities in software development, bringing together stakeholders with expertise in many different areas UCMs provide a good basis for design-time feature interaction detection and for model construction (TTCN tests, performance/LQN, MSC / Sequence Diagrams, LOTOS, and others). Data types in ASN.1 can be used at all steps, although no particular binding to URN exists. Why yet another notation? Sometimes we cannot commit to data types because we do not know enough about the messages that will be required Sometimes we cannot commit to messages and component behaviour because we are not sure about what entities will be involved in our system Sometimes we cannot even commit to particular functionalities because stakeholders have conflicting goals that remain unresolved This is where URN can help! Introduction à la notation UCM/URN

UCM, cas d’usage UML, et cas de mésusage

Relation d’inclusion UML
Clarifie un cas d’usage en isolant et en encapsulant des détails complexes, et en augmentant la cohérence. Le cas d’usage de base nécessite le cas d’usage inclus pour l’exécution de son scénario. Solution: Utilisez un stub statique sur le chemin du cas de base Le stub cache les détails contenus dans son plug-in (le cas d’usage inclus) Le plug-in peut être utilisé dans plusieurs stubs, augmentant ainsi l’uniformité et la cohérence des UCMs. Introduction à la notation UCM/URN

Relation d’inclusion: Exemple
Basic Call Originating « include » Terminating « include » OCS Call « include » Originating Terminating req msg ring Basic Call req msg ring OCS OCS Call Terminating Introduction à la notation UCM/URN

Relation d’extension UML
Montre qu’une portion d’un cas d’usage est: (Potentiellement) optionnelle; Exécutée seulement dans certaines conditions; Insérée à un point d’extension dans un cas d’usage de base; Non requise par le cas de base pour l’exécution de son scénario. Solution: Utilisez des OR-forks ou stubs dynamiques dans le cas de base. Les points d’extension sont visuels. Pour les stubs dynamiques, il y a un plug-in par défaut qui représente le cas de base original. Introduction à la notation UCM/URN

Relation d’extension: Exemple
Basic Call Busy Treatment « extend » OCS Feature « extend » Selection Strategy req ring Basic Call Originating upd msg [idle] [busy] mb OCS plug-in in1 out2 out1 chk [allowed] [denied] md OCSlist in1 out1 Default plug-in Introduction à la notation UCM/URN

Relation de généralisation UML
Deux cas d’usage (ou plus) ont un comportement, une structure ou un but en commun. La partie commune peut donc être décrite dans un nouveau cas d’usage parent qui est spécialisé par ses enfants. Solution: Utilisez des OR-joins et OR-forks, ou plusieurs stubs dynamiques. Le parent contient les stubs dynamiques pour le comportement qui diverge. Le cas d’usage spécialisé est le parent + ses plug-ins. Introduction à la notation UCM/URN

Relation de généralisation: Exemple
Phone Session Basic Call OCS Call req msg ring Phone Session Originating UserO AgentO UserT AgentT OCS Call = Phone Session + OCS plug-in Basic Call = Phone Session + Originating plug-in Introduction à la notation UCM/URN

Que dire des Misuse Case Maps (MUCM)?
Composante serveur avec un scénario régulier et un scénario où une faiblesse est exploitée P. Karpati, G. Sindre and A.L. Opdahl: Visualizing Cyber Attacks with Misuse Case Maps, REFSQ 2010, June 2010, p Introduction à la notation UCM/URN

Attaque sur un système bancaire

UCM: Utilisations Introduction à la notation UCM/URN

Utilisations typiques d’URN
Modélisation et documentation Exigences (utilisateur et système), explications Domaines: systèmes OO, réactifs et répartis, services, processus d’affaires… Analyse des objectifs d’entreprise Évaluations d’exigences et de solutions alternatives (stratégies) Découverte de compromis optimisant le degré de satisfaction de buts conflictuels Analyse d’architectures Basée sur les exigences non-fonctionnelles et les contraintes de conception Analyse de performance Génération de scénarios individuels Formation, documentation Détection de conflits Transformation vers MSC et cas de test Rétro-ingénierie Vue dynamique abstraire du système existant Introduction à la notation UCM/URN

Quelques domaines d’application…
Télécommunication et services Systèmes sans-fil Conception OO Systèmes multi-agents Applications / services Web Contrôle ferroviaire Systèmes embarqués Interfaces utilisateurs Contrôle d’accès Protocoles réseaux Commerce électronique Applications en santé Familles de produits Systèmes d’exploitation Systèmes d’information Communication véhiculaire Conformité légale… Introduction à la notation UCM/URN

Transformations de modèles UCM?
Pourquoi? Différentes notations sont mieux adaptées à différentes phases du cycle de développement Il faudrait réutiliser les informations contenues dans les scénarios pour combler l’écart entre les phases En accord avec l’esprit de la vision Model Driven Architecture (MDA) de l’OMG: Platform-independent model  Platform-specific model Comment? UCM  MSC et diagrammes d’interactions UML pour la conception UCM  LQN, pour l’analyse des performance UCM  LOTOS, ASM et SDL, pour le prototypage et la validation des exigences UCM  TTCN-3, pour la génération de tests de validation UCM  UML2 Code  UCM (Architecture-Driven Modernization, de l’OMG) Introduction à la notation UCM/URN

Définitions de scénarios et parcours d’UCM
Extraction de scénarios individuels Conditions associées aux points de sélection Initialisation de variables globales, et sélection des points de départ Transformations vers MSC, UML, tests…. Introduction à la notation UCM/URN

Métamodèle abstrait de URN / UCM (II)

Définitions de scénarios avec jUCMNav
Partie 3 : Tutoriel URN

Définitions/exécution de scénarios
jUCMNav supporte Définition de scénarios (avec types de données, points de départ/arrivée, et inclusion de scénario) “Problems View” de Eclipse Trace en couleur Partie 3 : Tutoriel URN

Options pertinentes dans jUCMNav

UCM: Définitions de scénarios et traversée
ServiceInMSC_OK: StartConnection, authorization variable is true ([Ok]), SvcInMSC plug-in selected ServiceInMSC_DataInSN_NotOK: StartConnection, authorization variable is false ([NotOk]), SvcInMSC_DataInSN plug-in selected Partie 3 : Tutoriel URN

jUCMNav: Transformation et visualisation de MSC
jUCMNav supporte Visualisation MSC Export vers images Ordonnancement des instances (lignes vert.)

Génération de MSC Partie 3 : Tutoriel URN

Scénario ServiceInMSC_OK en MSC

Autre exemple (relié à celui vu pour GRL)
UCM model that addresses privacy protection in a hospital environment Researchers want access to patient data but the Health Information Custodian (HIC – i.e., the hospital) needs to protect patient privacy, as required by law (PHIPA in Ontario). The process of accessing databases must ensure privacy. As required by law, a Research Ethics Board (REB) is usually involved in assessing privacy risks for the research protocol proposed by a researcher. DB administrators also want to ensure that DB users are accountable for their acts. Introduction à la notation UCM/URN

Stubs et plug-ins S S Introduction à la notation UCM/URN IN1 OUT1 IN1
Static Stub Dynamic Stub OUT1 [ST] S IN1 Synchronizing Stub with Synchronization Threshold OUT1 [ST] IN1 S X B Blocking Stub with Synchronization Threshold & Replication Indicator Introduction à la notation UCM/URN

Visualisation d’un scénario comme UCM
Start Points RequestData Ready Variables CheckAccountability = TrustUser; ReviewResult = OK, Introduction à la notation UCM/URN

Visualisation d’un scénario comme MSC

Points importants – Définitions de scénarios
Améliorent la compréhension de (longs) scénarios Validation et tests de régression Le modèle de donnée pour chemins UCM n’est pas un modèle de donnée du domaine d’application Base nécessaire pour fonctionnalités avancées utilisant le mécanisme de parcours des UCM mise en évidence génération de MSC, UML, TTCN… L’automatisation de ce processus rapporte beaucoup de bénéfices par rapport à l’effort investi Introduction à la notation UCM/URN

Évaluation qualitative de performance avec UCM (info seulement)
Caractéristiques de ressources Processeurs, disques, DSP, services externes… Facteurs de vitesse Caractéristiques d’arrivée Exponentielle, ou Déterministe, ou Uniforme, ou Erlang, ou Autre Taille de population Contribuable Sécurité Comptable_E VerBio Continue Accède Prêt Rejette Composants Responsabilités allouées Allocation à un processeur Fourches OU et stubs dynamiques Poids relatifs (probabilités) Responsabilités Demande de ressources Multiplcité… Traduction automatisée vers Core Scenario Model (CSM) pour évaluations analytiques et simulations. Introduction à la notation UCM/URN

Métamodèle abstrait de URN / UCM (III)

Gestion de ressources Introduction à la notation UCM/URN

Gestion de demandes et de charges

De UCM vers Core Scenario Model (CSM)
Traduction de CSM vers LQN, QN, … Introduction à la notation UCM/URN

Génération automatique de modèles LQN
Layered Queueing Networks Modèles LQN analysés et simulés par des outils spécialisés: Sensibilité (importance ou impact de certains paramètres) Extensibilité (et si on ajoutait plus d’utilisateurs ou de requêtes?) Concurrence (et si on ajoutait/enlevait des threads?) Déploiement et configuration (différentes distributions des services sur le matériel) [D.B. Petriu et al., 2003] Introduction à la notation UCM/URN

Résultats typiques en analyse de performances…
Statistiques générales: temps requis par le système… Quantités mesurables: demandes en services, nombre d’invocations bloquées et non-bloquées, délais en invocation ou en synchronisation. Temps de service, utilisation, débits: pour composantes ou activité/responsabilité, avec des intervalles de confiance et des variances (lorsqu’appropriées). Informations: Introduction à la notation UCM/URN

Génération de tests à partir de UCM? (info)
Basées sur des patrons de tests orientés UCM Stratégies de sélection “boîte grise”, appliquées aux scénarios d’exigences Manuelle Basées sur des définitions de scénarios UCM UCM + modèle de donnée simple, contexte initial, et algorithmes de parcours du modèle Semi-automatique Basées sur des transformations vers langages formels Parcours exhaustif Correspondance vers un langage formel (p.e., LOTOS, ASM) Automatique Introduction à la notation UCM/URN

Définitions de scénarios Transformations automatiques
Comparaison Patrons de test Définitions de scénarios Transformations automatiques Automatisation    Scénarios irréalisables  Communication Suite exhaustive Couverture  Passage à l’échelle Évolution du modèle Convivialité Transformations Maturité Outils Introduction à la notation UCM/URN

Vers la génération de cas de tests
Communication et invocations Messages, paramètres, interfaces, protocoles... Données Doivent aussi assurer que le scénario soit réalisable Information temporelle Les minuteries UCM n’ont pas de notion quantitative du temps Mise en place et nettoyage Beaucoup d’autres défis encore! Cependant, il y a quelques résultats dans l’automatisation de bout en bout… Utilisation de UCMNav, définitions de scénarios, et Fitnesse pour générer des tests exécutables sur une application Web typique Introduction à la notation UCM/URN

Génération de tests pour applications Web
[Amyot, Roy et Weiss, 2005] Introduction à la notation UCM/URN

Rétro-ingénierie de modèles UCM à partir du code? (info)
Les traces d’exécutions peuvent nous aider à comprendre les fonctionnalités et autres aspects dynamiques d’un programme existant Mais elles sont énormes et incompréhensible Parfois des millions d’événements! Besoin d’abstraction et de visualisation Les UCMs offrent une vue abstraite des scénarios [A. Hamou-Lhadj et al., 2005] Instrumenter et exécuter Traces d’exécution Filtrer les “utilités” Abstraction Génération de modèle UCM Modèle UCM Validation Lisible? [non] [oui] Introduction à la notation UCM/URN

Correspondance des éléments UCM (exemple) Trace element UCM element Symbol Package Component (Agent), shown as a rectangle with thick border. Class Component (Team), shown as a rectangle with narrow border. Object Component (Object), shown as a rounded-corner rectangle. Thread Component (Process), shown as a parallelogram. Beginning / End of trace Start point (circle) / End point (bar) (also used as connectors for linking sub-scenarios to the parent stub) Instruction Responsibility (shown as a X on a path) Block of 3 or more instructions in the same class/object Stub (diamond) with the name of the first instruction that is not a constructor. This stub contains a plug-in (another sub-map) showing the sub-sequence with one responsibility per instruction. Repeated instruction Responsibility with repetition count (number between curly brackets) {2} Repeated sequence Loop (with loop count between curly brackets) Condition Condition (between square brackets) [cond] {2} … … IN1 OUT1 … Introduction à la notation UCM/URN

Exemple de trace visualisée (TConfig) Start End Introduction à la notation UCM/URN

Intégration jUCMNav et DOORS (au lab)
Permet de faire: Gestion d’exigences Traçabilité de/vers des exigences externes ou d’autres modèles - Analyse d’impact, etc. Introduction à la notation UCM/URN

Modélisation de processus d’affaires
Nous devons adresser les questions W5 Where, What, Who, When and Why Goal-oriented Requirement Language (GRL) But/objectif d’affaire ou du système (Why) Qualité (Why) Solutions/Tâches (What) Acteurs (Who et Where) Use Case Maps (UCMs) Responsabilités (What) Composantes (Who et Where) Scénarios et processus (When) GRL & UCMs Liens ( ) entre processus et objectifs d’affaires, pour traçabilité, complétude, alignement, comformité, situations “what if”, et évolution X Introduction à la notation UCM/URN

Analyse et surveillance de processus d’affaires
Comment modéliser et surveiller les processus d’affaires pour déterminer s’ils atteignent leurs buts et satisfont leurs exigences de performance? Peut-on aligner les processus et leurs buts? Key Performance Indicator (KPI) Model ? Introduction à la notation UCM/URN

Trois vues connectées Process Model Performance Model Goal Model Introduction à la notation UCM/URN

UCM, GRL et KPI pour BPM  Introduction à la notation UCM/URN

Intégration avec outils de BI (Cognos 10)

Points importants – Casse-tête URN
Des notations basées sur les buts (GRL) et sur les scénarios (UCM) se complètent bien URN permet de combler un vide notationnel chez UML et les langages de l’UIT Les UCM offrent plusieurs avantages par rapport aux diagrammes d’activités et de scénarios UML GRL offre un cadre descriptif et décisionnel pour plusieurs activités en génie logiciel et en ingénierie des exigences URN permet à plusieurs partie prenantes de partager un même modèle et de le relier à d’autres types de modèles Les UCM offrent un bon cadre analytique (conflits, couverture, performance) et permet la génération de modèles plus détaillés UCM et GRL peuvent être utilisés de façons itérative et indépendante Introduction à la notation UCM/URN

Conclusions URN Permet aux gens de découvrir et de spécifier des exigences pour un système nouveau ou existant, et d’analyser ces exigences. Combine buts et scénarios Est utilisable dans des milieux industriels et de normalisation Fait le pont entre des concepts informels et formels, et entre des modèles d’exigences et de conception Grands bénéfice pour peu d’investissement, même lorsque utilisé de façon informelle GRL Pour exigences provisoires, incomplètes, floues, non-fonctionnelles Buts, objectifs, raisonnements, et décisions qui façonnent le système UCM Pour exigences fonctionnelles et opérationnelles Possibilité d’analyse et de transformation Alternatives architecturales et systèmes dynamiques Introduction à la notation UCM/URN

Sommaire de la notation UCM (comportement)

Sommaire de la notation UCM (structure)
Team Process Object Agent Actor Components: parent: Protected Component Context-dependent Component Introduction à la notation UCM/URN

Objectifs: Introduction à la notation Use Case Maps (UCM)

Présentations similaires

Présentation au sujet: "Objectifs: Introduction à la notation Use Case Maps (UCM)"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Objectifs: Introduction à la notation Use Case Maps (UCM)

Présentations similaires

Présentation au sujet: "Objectifs: Introduction à la notation Use Case Maps (UCM)"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back