Génie logiciel Modèliser des grands systèmes Philippe Dugerdil 07.10.2009 Problème: Problématique Maîtrise de la fonctionnalité globale Modélisation détaillée Modélisation à plusieurs niveaux Système (superordinate use-case model) Sous-systèmes (subordinate use-case model) Systèmes et sous-systèmes SS S-Syst1 SS S-Syst2 SS S-Syst3 Système
Use-cases associés Communication entre sous systèmes superordinate subordinate Environnement d un sous-système extérieur autres sous systèmes. Modélisation de la communication entre sous-systèmes : acteurs internes. Externe A1? A2 Sous-système 1 Sous-système 2 A1 Niveaux conceptuels différents! Externe Sous-système 1 Sous-système 2 Contraintes entre niveaux Exemple: station d essence Chaque use-case du superordinate model correspond à un ensemble de use-cases des subordinate models. Chaque UC du subordinate model est associé à un sous-système. Cas dégénéré : un seul subordinate UC pour un superordinate UC. Chaque acteur du superordinate model correspond à exactement t un acteur du subordinate model. borne de paiement Station d'essence pompe
Exemple: station d essence Système et sous-systèmes Nom: Prélever du carburant Acteur: primaire: client, secondaire: lecteur de carte, système de l office de crédit Déclencheur: l utilisateur introduit sa carte de crédit dans le système Flot de base 1. Le lecteur de carte détecte une carte de crédit. 2. Le système affiche: entrer votre code PIN 3. Le client entre le code PIN 4. Le système affiche: choisir la pompe correspondant au produit. 5. Le client sélectionne la pompe 6. Le système détecte le décrochement du pistolet de remplissage 7. Le système détecte la remise du pistolet de remplissage 8. Le système comptabilise le volume prélevé é 9. Le système communique le débit auprès de l'office de crédit 10. Le système demande au lecteur d éjecter la carte de crédit Sous-système: borne de paiement Nom: Sélectionner le produit Acteur principal: p Client, secondaire: lecteur carte, pompe, p système de l office de crédit Déclencheur: Le client introduit la carte de crédit dans la borne de paiement. Flot de base 1. Le lecteur de carte détecte une carte de crédit. 2. Le système affiche: saisir le code PIN. 3. Le client saisit son code PIN 4. Le système vérifie le code et affiche: choisir la pompe correspondant au produit. 5. Le client sélectionne la pompe 6. Le système communique à la pompe qu'elle est déverrouillée. 7. La pompe retourne au système le volume prélevé ainsi que la somme correspondante. 8. Le système appelle l'ordinateur de l'office de crédit et lui transmet le numéro de carte, le montant et le nom de la station d'essence. 9. Le système demande au lecteur d éjecter la carte de crédit Sous-système: pompe Nom: Prélever le produit Acteur: Client, secondaire: borne de paiement Déclencheur: La pompe reçoit un signal de déverrouillage de la borne de paiement Flot de base 1. La pompe reçoit un signal de déverrouillage de la borne de paiement 2. Le système détecte le décrochement du pistolet de remplissage 3. La pompe remet ses compteurs à 0 4. Le système détecte la remise du pistolet de remplissage 5. La pompe comptabilise le volume délivré ainsi que le prix a payer. 6. La pompe envoie à la borne de paiement le volume livré et le prix.
Discipline: spécification «définir le système» Supplementary specifications 1. Legal & administrative constraints 2. Non-functional specifications: quality attributes 3. General functional specifications 4. Technical constraints (OS, plateform, hardware, COTS, Legacy, ) Figures: Copyright 1987-2003 Rational Software Corporation «Ultimately, the non functional requirements are every bit as important to the end user community as are the functional requirements.» [Krutchen Ph. The Rational Unified Process. An Introduction. Addison-Wesley Inc. 2000.]. Quality attributes (QA) Any global property of a system that is expressed in non- functional terms. It is «orthogonal» to the functionality. Example Performance Availability Modifiability Testability Fiability Usablity Portability The satisfaction of these quality attributes largely depends on the architecture of the system Quality attributes (continued) Often QA are categorized in two sets: Visible to the end user (disponibility, performance, ) Invisible to the end user (modifiability, y,portability, ) But invisible QA can have visible side-effects effects! Central property that t influences many QA: System complexity
Expressing quality attributes Traditional approach Since the quality attributes are important to design the architecture t of the system, they must be expressed early. However, what do «high maintainability» or «high performance» really mean? what is «maintainability» what is «high» Source: Barbacci M.R et al. - Quality Attribute Workshops (QAWs),3rd Edition, CMU/SEI-2003-TR-016 Aug. 2003 Specifying QA QA precise semantics and measurement value are highly hl contextual t Design of a QA scenario to express it Source Stimulus Atif Artifactt Environment Response Measure Performance scenario example QA: performance Source: user Stimulus: input some information through the screen and launches the transaction Atif Artifact: t whole system Environment: normal operation Response: any information that t is output t from the system due to the stimulus Response measure: time for the information to be outputted. Source: Bass L., Clements., Kazman R. Software Architecture in Practice. Second Edition Adison-Wesley Inc. 2003. 2
QA: modifiability Modifiability scenario values Source: end user, developper, system administrator i t Stimulus: whishes to add/delete/modify/vary functionality, capacity Atif Artifact: t user interface, plateform, component. Environment: runtime, compile time, build time, design time Response: locate places where changes must be made, change made without t disturbing the rest of the system, test the system, deploy modification Response measure: time and cost or (alternatively) number of elements affected, effort, extent to which this affects other functions or QA. Exemple: modifiabilité «Le système doit être facilement modifiable»???? Source: Bass L., Clements., Kazman R. Software Architecture in Practice. Second Edition Adison-Wesley Inc. 2003. The IBM/Rational approach : Significant Architecture Requirement (SAR) Requirements with significant architectural implications Requirements that are difficult to meet Requirements most likely to change Requirements that are important to the customer Requirements considered risky Categorizing SARs FURPS+ Functionality Functional Requirements Useability Reliability Non-Functional Requirements Performance (system quality attributes) Supportability Design requirement Implementation requirement Interface requirement Constraints Physical requirement
Eliciting SARs 1. Maintain a complete list of SARs 2. For each SAR, formulate question(s) that assist in the specification of the SAR Must be understood by the stakeholders 3. Assist the stakeholder by giving visibility to the impact of answering a question one way or another 4. Capture stakeholders responses 5. Ensure that each SAR is given a priority/weighting by stakeholder SAR Elicitation Technique: Requirements questionnaire example Requirement Questions Business Impact Answer Priority Are there any The higher the availability, Availability is a Reliability High the longer the time to (Availability) market. Platform Support requirements regarding system up time? This may be specified in terms of Mean Time Between Failures (MTBF). What platforms must the system support? Development for a single platform shortens the time to market. It also allows closer integration with platform features. Development for multiple platforms lengthens the time to market. Close integration with platform features is lessened, increasing the maintenance of the system. key product feature. The product must have a MTBF of 60 days. The product will be released on the following UNIX platforms: Sun Solaris IBM AIX HPUX High Etude du template du document de spécifications supplémentaires Voir aussi: https://sourceforge.net/docman/display_doc.php?docid php?docid=17414&group_id=70060