INF 6001 Chapitre 9

1. INF 6001 Chapitre 9 Vers une méthodologie de développement des protocoles w3.uqo.ca/luigi INF6001 Chap 8

2. Des exigences directement à l’implantation? Spec d’exigences (langue naturelle, notation logique) Spécification du comportement Spécification de l’implantation (comportement utilisant des composantes données) Implantation INF6001 Chap 8

3. Dérivation automatique des implantations • La théorie moderne du génie logiciel est orientée vers la génération automatique de code à partir des exigences • Beaucoup de travail dans cette direction a été effectué dans le cadre de UML • Universal Modeling Language • Model-Driven Architecture (MDATM): contient un cadre conceptuel concernant les transformations entre modèles et langages • Including code, DB schemas, etc. http://www.omg.org/mda/ INF6001 Chap 8

4. Three important steps • Create Platform-independent-model (PIM) by specifying a system independently of the platform that supports it. Choose a platform(s) for the system • Create platform-specific-model (PSM) by transforming the system specification into a model for the specified platform • Observer la similaritéentre les concepts de PIM et PSM et les concepts de spec de comportement et spec d’implantation mentionnés au Chap 1 INF6001 Chap 8

5. Mostly text Requirements PSM PIM Analysis MDA Process Low-level design Coding Code Testing Code Deployment MDA software development life cycle Source: Kleppe et al. MDA Explained: The model Driven Architecture: practice and Promise INF6001 Chap 8

6. PIM PSM PSM Code Code Transformation types 1 - PIM to PSM : models are transformed by adding platform artifacts that are specific to a given platform. 2 - PSM to Code : Code is generated from a platform-specific model EJB, .NET, Corba, … 3 - PIM to PIM : model refinement without platform information 4 - PSM to PSM : model refinement that needs platform information 5 - PSM to PIM : Abstracting existing models to a platform independent model. (Reverse-engineering) Aussi, autres Reverse Engineering: Code to PSM? Code to PIM? 3 5 1 1 4 2 2 Source: Kleppe et al. MDA Explained: The model Driven Architecture: Practice and Promise INF6001 Chap 8

7. Role des composantes et patrons de conception (design patterns) • Beaucoup de recherche a été dédiée au développement de ‘patrons de conceptions’, • solutions communes à plusieurs problèmes • ‘Component-based-design’ utilise des composantes préfabriquées et réutilisables pour créer des nouveaux systèmes • Ces concepts sont relativement nouveaux dans le domaine des protocoles et leur utilité n’est pas clairement établie • Ni y a-t-il une méthodologie établie d’usage INF6001 Chap 8

8. La spécification des besoins • Point faible de toute méthodologie de ce type • Les besoins pourraient en principe être très informels • Besoin d’un protocole pour transférer des données de façon fiable sur un support non fiable • Cependant à un certain point dans la méthodologie ils devront être formalisés • Car un processus de traduction automatique exigera un langage ayant syntaxe et sémantiques précises INF6001 Chap 8

9. À quel point mettre la frontière du formalisme? • Si la 1ère spec formelle est en SDL, la frontière du formalisme est très près de l’implantation • Des langages de type algébrique tel que LOTOS, CCS, CSP sont un peu plus abstraits • La logique temporelle pourrait être considérée un langage d’exigences • UML contient plusieurs langages à plus. niveaux d’abstraction: lequel utiliser comme base? • OCL, Object Constraint Language est un langage logique • Implantation pas évidente • StateCharts, langage très semblable à SDL • Diagrammes de séquence: très semblables à MSC • http://uml.free.fr/ INF6001 Chap 8

10. Formalismes de spécification exécutables ou non • Les formalismes de spéc peuvent être exécutables ou non • Exemples de formalismes exécutables: SDL, LOTOS • Peuvent être interprétés ou traduits en code exécutable • Exemple de formalismes non-exécutables: logique • Des sous-ensembles de la logique sont exécutables, p.ex. Prolog • Une spéc dans un formalisme exécutable peut être considérée un modèle ou prototype du système • Cependant un formalisme non-exécutable peut permettre une spéc plus directe des exigences • Donc nous avons la progression • Exigences  formalisme non exec  formalisme exec. INF6001 Chap 8

11. Ce qui existe déjà • Les outils pour SDL contiennent souvent des traducteurs qui permettent de traduire une spéc SDL en C++ • L’outil CADP pour LOTOS contient l’outil CAESAR qui traduit LOTOS en C • Un outil semblable existe pour StateCharts dans l’environnement Rational Rose de l’IBM • Un outil comme LTL2BA obtient des automates exécutables à partir de la logique temporelle, mais difficilement ces automates pourraient être considérés des implémentations • Dans tous les cas, la résultat n’est pas une implémentation complète • Il est une squelette d’implantation fournissant des points de repère où insérer des détails d’implantation, des appels à des librairies de plateforme, etc. • Des erreurs critiques peuvent se glisser à cette étape! • Comme aussi dans l’étape de transformation des besoin en langages comme SDL, LOTOS. INF6001 Chap 8

12. Les Cas d’Usage de UML (Use Cases) • A use case defines a goal-oriented set of interactions between external actors and the system under consideration. Actors are parties outside the system that interact with the system. An actor may be a class of users, roles users can play, or other systems. • A use case is initiated by a user with a particular goal in mind, and completes successfully when that goal is satisfied. It describes the sequence of interactions between actors and the system necessary to deliver the service that satisfies the goal. It also includes possible variants of this sequence, e.g., alternative sequences that may also satisfy the goal, as well as sequences that may lead to failure to complete the service because of exceptional behavior, error handling, etc. The system is treated as a "black box", and the interactions with system, including system responses, are as perceived from outside the system. • A scenario is an instance of a use case, and represents a single path through the use case. Thus, one may construct a scenario for the main flow through the use case, and other scenarios for each possible variation of flow through the use case (e.g., triggered by options, error conditions, security breaches, etc.). Scenarios may be depicted using sequence diagrams. • http://www.bredemeyer.com/use_cases.htm INF6001 Chap 8

13. Cas d’usage non liés et liés • Cas d’usage non liés (unbound): • décrivent les séquences d’événements sans faire référence aux éléments fonctionnels du système qui sont responsables pour les différents événements • Cas d’usage liés (bound): • Les responsabilités sont attribuées à des éléments fonctionnels INF6001 Chap 8

14. Cycle de raffinement des besoins spécifiés par scénarios(D. Amyot) Towardsimplementation Towardsimplementation test suite Scenarios non-liés Structure du système Results (Functions) Testing Modify if necessary Results (Coverage) Prototype (SDL, LOTOS) Requirements Add tests if necessary Test Suite (TTCN?) Construction Test Cases Generation Scénarios liés Allocation SPEC-VALUE INF6001 Chap 8

15. Explications • Scénarios non-liés spécifient des séquences d’actions sans dire qui en est responsable • Scénarios liés disent quelles composantes sont responsables pour quelles actions • Le cycle le plus interne se préoccupe d’obtenir une suite de test qui couvre complèt. les exigences • Le cycle le plus externe se préoccupe de modifier les exigences selon les résultats des tests • Il y a intervention humaine: • Au point 1, pour décider si les tests ont couvert toutes les possibilités • Au point 2, pour décider si tous les scénarios désirés ont été considérés dans les besoins • Les produitsde ce procédé sont: • Prototypes SDL et LOTOS qui peuvent être compilés  implantation • Test suites qui peuvent être utilisées pour tester l’implantation 2 1 composantes alloc des resps aux compos INF6001 Chap 8

16. Use Case Maps (UCM): une notation pour la spéc de cas d’usage • Exemple: UCM non lié pour système téléphonique Failure [Timeout] AllocateResources Timer GetAnswer InitiateCall GetNoAnswer StatusReported Daniel Amyot INF6001 Chap 8

17. Terminologie UCM End Point [Timeout] Timer Responsibility Responsibility Start Point Responsibility End Point INF6001 Chap 8

18. User System Resource Manager Failure [Timeout] AllocateResources Timer Switching Center GetAnswer InitiateCall GetNoAnswer StatusReported UCM lié(bound) pour système téléphonique Daniel Amyot INF6001 Chap 8

19. Un exemple de dérivation de MSC à partir de UCM INF6001 Chap 8

20. WIN: Wireless Intelligent Network • WIN est une norme qui ajoute des fonctionnalités élaborées (intelligentes) au fonctionnement de base de systèmes mobiles • Objet de normalisation comme partie de IS-41, la norme nord-américaine de la téléphonie mobile • Une recherche Google sur ces mots clés vous donnera des bons résultats pour en savoir davantage... INF6001 Chap 8

21. Location-Based ServicesFleet and Asset Management Location-based services is a large class of WIN services that take into consideration the location of the user Another one is location-based charging, where the user could get charged one rate when she is at home, a different rate when she is at the neighbor’s house The design of these services does not consider how the location is determined: it is assumed that some mechanism exists to do this: GPS? Fleet and Asset Management: a class of WIN services where the location information is made available for management purposes E.g. management of a fleet of moving trucks, taxis etc. INF6001 Chap 8

22. ‘Stage 1’ description • Fleet and Asset Management (FAM) Service allows a supervisor to track the location and status of his/her subordinates, and allows the subordinates to use feature codes to communicate status information back to the supervisor. Two operation modes are defined: Push: the MS will inform supervisor periodically or upon predefined events of the current location Pull: the location is communicated on supervisor ’s demand The user ’s profile will tell who is the supervisor and whether it is a push or pull situation INF6001 Chap 8

23. Unbound UCM (partial) for WIN LBSS FAM Status Change SetActive [Pull] NotifyFAM NotifySV SetInactive PowerOff [Push] notify status, if in push also position UpdLoc GetProfile PowerOn V_Profile SetupMonitoring SendLoc H_Profile FAM: Fleet and Asset Management Pull: On demand positioning, Push: Periodic update Profile tells if MS has pull or push option Notify FAM: notify SCP of change of user status INF6001 Chap 8

24. Description • L’usager peut allumer ou éteindre son terminal mobile • S’il allume, l’info qui l’identifie est cherché dans les bases de données • Locale: V-Profile • De son lieu d’origine: H-Profile • Il peut activer ou désactiver la fonctionnalité FAM • Ces événements sont rapportés à l’entité qui gère la fonctionnalité FAM • Si la fonctionnalité est en mode pull, il n’y a qu’à notifier le superviseur du changement d’état • Si elle est en mode push, il y a des opérations additionnelles à faire: • Setup monitoring, SendLoc, UpdLoc • Le résultat est que le superviseur obtient la position du subordonné: INF6001 Chap 8

25. INF6001 Chap 8

26. Composantes principales du ‘core network’ • MSC, Message Switching Center, la centrale de commutation (telephone switch) • VLR, Visitor Location Register, une base de données volatile qui contient les profils des utilisateurs courants du réseau • Inclus ceux qui viennent d’autres réseaux et sont des ‘visiteurs’ • HLR une base de données permanente qui contient les profils des usagers permanemment inscrits à ce réseau INF6001 Chap 8

27. Procédure d’identification • Quand une station mobile initie un appel dans un réseau, • On cherche avant tout s’il s’agit d’un usager déjà connu par le VLR • Sinon, on détermine où il est abonné et on cherche son profil sur le HLR de ce réseau là • On met son profil dans le VLR • Il peut alors communiquer INF6001 Chap 8

28. Les composantes: la plateforme Supervisor FAM MS MSC NotifyFAM GetProfile VLR MPC V_Profile HLR H_Profile INF6001 Chap 8

29. Les composantes(la plateforme) • MS station mobile • MSC le commutateur (switch) • VLR (Visitor Location Register) base de donnée contenant les information pour les usagers actifs dans une zone • Qu’ils soient abonnés résidents dans la zone, ou qu’ils s’y trouvent temporairement • HLR (Home Location Register) base de données contenant les informations concernant les usagers qui appartiennent à une zone géographique, qu’ils soient actifs ou non • La 1ère fois qu’un usager devient actif, ses informations essentielles sont exportées de l’HLR au VLR de la zone où il est actif • FAM entité fonctionnelle qui dirige l’exécution du service FAM • MPC (Mobile Positioning System) entité fonctionnelle qui interagit directement avec le module qui détermine la position de l’MS: • Ce dernier pourrait être un GPS • Ce dernier module n’est pas pris en considération dans la norme, il est laissé à l’implantation INF6001 Chap 8

30. Setup Monitoring • In mode push, when MS becomes active, or powers on, the MPC will automatically start transmitting location • This activity will cease when MS becomes inactive or power-off • This activity is not shown in the UCM, which treats only the case of status change INF6001 Chap 8

31. Bound UCM for LBSS WINFAM Status Change Supervisor FAM MS MSC SetActive [Pull] NotifyFAM NotifySV SetInactive PowerOff [Push] UpdLoc GetProfile PowerOn VLR MPC V_Profile HLR SetupMonitoring SendLoc (auteur: J. Sincennes) H_Profile MS: Mobile Station MSC: Mobile Switching Center FAM: Unité qui impante le service MPC: Mobile Positioning Center VLR: Visitor Location Register HLR: Home Location Register INF6001 Chap 8

32. Scénario choisi • La station mobile est allumée (p.ex. un camion arrive dans une ville est allume son système de positionnement) • Le VLR ne la connaît pas donc il demande le profil de l’usager à l’HLR • Il faut informer l’SCP(FAM) de l’existence d’un nouveau usager • Le profil de l’usager indique si • PULL: C’est le superviseur qui est censé demander périodiquement la position de la station mobile • PUSH: Ou si cette position doit être envoyée périodiquement par le système de positionnement au superviseur • Nous supposons être dans le cas PUSH, donc le système doit établir un système de notifications regulières (setup monitoring) • En plus il informe tout de suite le superviseur de la position courante de la station mobile INF6001 Chap 8

33. Ce qui n’est pas montré • Soit que la station mobile soit en mode push ou pull, il faudra avoir des communications ultérieures de sa position au superviseur • Ceci n’est pas montré dans l’UCM, • il montre seulement les premières actions du système après allumage INF6001 Chap 8

34. Génération d’échange messages • Nous voulons maintenant montrer l’échange de messages requis dans un scénario spécifique: • La station mobile vient d’entrer dans la zone • Donc le VLR ne la connait pas et doit demander ses informations à la base de données dans la ‘maison’ de la station mobile • Le système est en ‘push’ mode • Donc le FAM doit communiquer la position au superviseur • Et enfin la notif au superviseur INF6001 Chap 8

35. Scénario choisi Supervisor FAM MS MSC SetActive [Pull] NotifyFAM NotifySV SetInactive PowerOff [Push] UpdLoc GetProfile PowerOn VLR MPC V_Profile HLR SetupMonitoring SendLoc H_Profile J. Sincennes INF6001 Chap 8

36. Message Sequence Chart pour scénario FAM Status Change = PowerOnSynthesized from the UCM MS MSC VLR HLR FAM MPC SV MS MSC VLR HLR FAM MPC SV PowerOn getProfile getProfile profile profile notify FAM SetupMonitoring Location notifySV case ‘push’

37. MS MSC VLR HLR FAM MPC SV MS MSC VLR HLR FAM MPC SV PowerOn getProfile getProfile profile profile notify FAM SetupMonitoring Location notifySV INF6001 Chap 8 37

38. Méthode (entièrement automatisée) • Les UCMs avaient été faits par nous et approuvés par le comité de normalisation • Un outil appelé UCM Navigator permet d’éditer les UCM et de les transformer dans une représentation interne • Nous avons implanté un programme de traduction de UCM en rep interne à LOTOS • L’UCM de FAM devient donc une spéc LOTOS • La spéc LOTOS est exécutée pour obtenir des chemins d’exécution • Chaque chemin est puis traduit en MSC • Thèse de maîtrise de Ruoshan Guan • Éventuellement la spec LOTOS peut être compilée dans une squelette C (outil CADP) • Le programme est complété à la main utilisant des librairies INF6001 Chap 8

39. Méthodologie de conception de norme ITU-T • Stage 1: Spécification informelle, point de vue de l’usager du service • Stage 2: Messages et leur séquences: Message Sequence Charts • Stage 3: Spécification détaillée du système, incluant spécs des algorithmes et structures de données • UCM se place entre stage 1 et stage 2 INF6001 Chap 8

40. Utilité de ce procédé • Les UCM sont une notation de scénario d’utilisation assez intuitive • La traduction automatique de UCM à LOTOS permet de: • Obtenir des scénarios MSC à partir de l’UCM • Obtenir des implantations en C du système en utilisant l’outil CADP • Obtenir des cas de test en suivant les méthodes de dérivation de test à partir d’une spec LOTOS • Quelque chose de semblable aurait été possible utilisant les outils SDL INF6001 Chap 8

41. Par rapport au modèle de transformations • PIM: Platform Independent Model • Il est représenté par les UCM ‘non liés’ • Tranformation tool: • Un outil comme l’Use Case Map Navigator, qui aide l’usager à ‘lier’ les scénarios à un modèle structurel • PSM: Platform Specific Model • Il est représenté par les UCM ‘liés’ • Transformation tool: • Traducteur de UCM liés à LOTOS ou SDL • Traducteur d’un de ces derniers à Code C, Java…