Kapittel 5 System modellering

Presentasjon om: "Kapittel 5 System modellering"— Utskrift av presentasjonen:

1 Kapittel 5 System modellering
Carl-Fredrik Sørensen

2 Innhold Modellering: hvorfor, hva, når, hvem UML Case studie
Konklusjon

3 Modellering Modellering ≠ Programmering En modell er en abstrakt representasjon av et system som ignorerer detaljer om systemet. Komplementære modeller kan utvikles til å vise systemets kontekst/sammenheng, interaksjoner, struktur og oppførsel (adferd). Hvorfor, hva, når, hvem

4 Bruk av modeller Spesifikasjon (forstå problem og kunde)
Støtte og forenkle diskusjon om et eksisterende eller foreslått system Ukomplette og ukorrekte modeller er OK siden rollen er å skape diskusjon. Konstruksjon (forstå løsning/struktur for implementering) Implementering (automatisering – ikke fokus i TDT4140) Modeller må være komplett og korrekt Forvaltning/evolusjon (forstå på et abstrakt nivå) Dokumentere eksisterende systemer – struktur og operasjon Modeller bør være en presis representasjon av systemet, men trenger ikke å være komplett.

5 Perspektiver Ekstern: Modellering av konteksten eller miljøet et system opptrer i. Interaksjon: Modellering av interaksjoner mellom et system og miljøet systemet opptrer i, eller mellom komponenter i systemet. Strukturell: Modellering av hvordan systemet er organisert, eller strukturen av informasjonen som blir prosessert av systemet. Oppførsel: Modellering av den dynamiske oppførselen av et system og hvordan det reagerer på hendelser.

6 Konteksten av MHC-PMS Figur 5.1
mental-health-organization.class.violet A mental health case patient management system. Context models are used to illustrate the operational context of a system - they show what lies outside the system boundaries. Social and organisational concerns may affect the decision on where to position system boundaries. Architectural models show the system and its relationship with other systems. Context models simply show the other systems in the environment, not how the system being developed is used in that environment. System boundaries are established to define what is inside and what is outside the system. They show other systems that are used or depend on the system being developed. The position of the system boundary has a profound effect on the system requirements. Defining a system boundary is a political judgment There may be pressures to develop system boundaries that increase / decrease the influence or workload of different parts of an organization.

7 Visuell modellering Modellering ved å benytte en standard grafisk notation. Benyttes til å: Representere forretningsprosesser, objekter/klasser og logikk. Analysere og designe applikasjoner/systemer. Håndtere kompleksitet. Definere programvarearkitektur. Promoterer gjenbruk. UML, BPM, ER, DDF etc.

8 UML – Unified Modeling Language
Ikke en utviklingsprosess eller metode for programvare Kombinerer det beste fra Datamodelleringskonsepter (ER Diagrams) Forretningsmodellering (workflow) Objektmodellering Komponentmodellering

9 UML Standard språl for visualisering, spesifisering, konstruksjon/design og dokumentasjon av problemer/løsninger i er programvare-intensivt system Kan bli benyttet i alle prosesser/faser i en utviklingssyklys, på tvers av forskjellige implementeringsteknologier.

10 UML Konsepter UML blir benyttet til å:
Vise hovedfunksjoner og avgrensning i et system ved å benytte use cases og actors (aktører). Illustrere use case realisering ved å benytte interaksjonsdiagrammer. Representere en statisk systemstruktur ved å benytte klassediagrammer. Modellere oppførsel på objekter ved å benytte tilstandsdiagrammer (state diagrams). Vise implementering av den fysiske arkitekturen ved å benytte komponent- og deployment- diagrammer. Utvide funksjonaliteten ved å benytte stereotyper.

11 UML Tools Nødvendig å benytte et UML verktøy for modellering:
Tegne konsistente diagrammer i UML notasjon Prosesstøtte Vedlikeholde Sporbarhet Utvidelse Dokumentasjon Kodegeneratorer (Java, C++, SQL etc.)

12 UML: Unified Modelling Language
Klassediagrammer: klassene i systemet og assosiasjoner mellom disse klassene. Aktivitetsdiagrammer: aktivitetene som er involvert i en prosess Use case-diagrammer: samspillet mellom et system og dets omgivelser Sekvensdiagrammer: samspillet mellom aktører og systemet, og mellom systemkomponenter Tilstandsdiagrammer: hvordan systemet reagerer på interne og eksterne hendelser Package; 7. deployment; 8. object; 9. communication: 10. composite structures; 11. component; 12. collaboration; 13. interaction overview; 14. timing. See UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition) NOT SYLLABUS

13 Et pasientinformasjonssystem
Et system som brukes til å holde oversikt over personer som mottar omsorg for psykiske helseproblemer. Et pasientinformasjonssystem for å støtte psykisk helsevern er et medisinsk informasjonssystem som vedlikeholder informasjon om pasienter som lider av psykiske problemer og behandlinger som de har mottatt. De fleste psykiske pasienter krever ikke dedikert sykehusbehandling, men trenger å besøke spesialist regelmessig der de kan møte en lege som har detaljert kunnskap om deres problemer.

14 Mål: Gjøre det lettere for pasienter å benytte tjenestene. Klinikkene ikke bare på sentraliserte sykehus. De kan også være i lokale legekontorer eller andre egnede steder i distriktene. Generere styringsinformasjon som muliggjør at helsetjenesten ledere kan vurdere ytelse mot lokale og offentlige mål. Gi medisinsk personale riktig informasjon for å støtte behandling av pasienter.

15 Funksjoner Individuell omsorg: helsepersonell kan lage journalposter, redigere informasjonen i systemet, se pasientens medisinske historie, etc. Systemet støtter informasjons-sammendrag slik at leger raskt kan få informasjon om viktige problemer og foreskrevne behandlinger. Pasientovervåkning: Systemet overvåker journalen til pasienter som får behandling og gir en advarsel hvis mulige problemer blir oppdaget. Administrativ rapportering. Systemet genererer månedlige rapporter som viser antall behandlede pasienter ved hver klinikk, antall pasienter som har kommet og forlatt omsorgssystemet, antall pasienter «innesperret», medisiner foreskrevet og kostnader, etc.

16 Krav a) Personvern b) Sikkerhet (Safety)
Hvorfor? Et slikt system: det er viktig å forstå før man starter implementering a) Personvern Det er viktig at pasientinformasjon er konfidensiell og kun autorisert helsepersonell og pasienten selv har tilgang. b) Sikkerhet (Safety) Noen psykiske lidelser fører pasienter til å bli suicidal eller en fare for andre mennesker. Der det er mulig, skal systemet varsle medisinsk personell om potensielt suicidale eller farlige pasienter. Systemet må være tilgjengelig når det trengs, ellers kan det være umulig å foreskrive riktig medisin til pasienter.

17 UML: Unified Modelling Language
Klassediagrammer: klassene i systemet og assosiasjoner mellom disse klassene Aktivitetsdiagrammer: aktivitetene som er involvert i en prosess Use case-diagrammer: samspillet mellom et system og dets omgivelser Sekvensdiagrammer: samspillet mellom aktører og systemet, og mellom systemkomponenter Tilstandsdiagrammer: hvordan systemet reagerer på interne og eksterne hendelser (--) Violet open source by By Cay S. Horstmann ( and Alexandre de Pellegrin ( TDT4100 Objekt-orientert programmering

18 UML Klasser og assosiasjoner
1 = cardinality Class name Is associated with Violet fil figure5.8 klassediagrammer bidrar til å etablere et vokabular om problemet og løsningen Structural models of software display the organization of a system in terms of the components that make up that system and their relationships. Structural models may be static models, which show the structure of the system design, or dynamic models, which show the organization of the system when it is executing. You create structural models of a system when you are discussing and designing the system architecture. Class diagrams are used when developing an object-oriented system model to show the classes in a system and the associations between these classes. An object class can be thought of as a general definition of one kind of system object. An association is a link between classes that indicates that there is some relationship between these classes. When you are developing models during the early stages of the software engineering process, objects represent something in the real world, such as a patient, a prescription, doctor, etc.

19 Klasser og assosiasjoner i MHC-PMS
Figure 5.9 Fil mental-health.class.violet Flere pasienter henvender seg til en spesialist En pasient kan lide av en eller flere medisinske tilstand En tilstand kan være assosierte med en eller flere pasienter Allmennlege, møter opp, sykehuslege kjører konsultasjon, foreskriver behandling, medisinering

20 Consultation class name attributes methods Figur 5.10
mental-health-consultation.class.violet

21 Generaliseringshierarki
Figur 5.11 mental-health-5.11.class.violet

22 Generaliseringshierarki med flere detaljer
Figur 5.12 -- violet En allmennlege er en lege og derfor har han navn, tel, , register og de-register. I tillegg har han en praksis og en adresse er

23 The aggregation association
Figur 5.13 mental-health-5.13.class.violet Består av

24 UML: Unified Modelling Language
Klassediagrammer: klassene i systemet og assosiasjoner mellom disse klassene Aktivitetsdiagrammer: aktivitetene som er involvert i en prosess (!) Use case-diagrammer: samspillet mellom et system og dets omgivelser Sekvensdiagrammer: samspillet mellom aktører og systemet, og mellom systemkomponenter Tilstandsdiagrammer: hvordan systemet reagerer på interne og eksterne hendelser (--)

25 Aktivitetsdiagram (Activity Diagram)
Figur 5.2 mental-health.activity.violet bekrefte forvaring avgjørelse start Finne sikkert sted Bare en activity Informere Myndighet Join Fork flow Fork Begge Parallelt stop Decision Bare en Informere pårørende informere pasienten om rettigheter innleggelse UML activity diagram. These diagrams are particularly useful in connection with workflow and in describing behavior that has a lot of parallel processing. Start – little ball Fork (between confirm decision and inform/record) Branch and merge branch – only one see dangerous and not dangerous fork – parallel Eksterne systemer

26 UML: Unified Modelling Language
Klassediagrammer: klassene i systemet og assosiasjoner mellom disse klassene Aktivitetsdiagrammer: aktivitetene som er involvert i en prosess Use case-diagrammer: samspillet mellom et system og dets omgivelser Sekvensdiagrammer: samspillet mellom aktører og systemet, og mellom systemkomponenter Tilstandsdiagrammer: hvordan systemet reagerer på interne og eksterne hendelser (--)

27 Use cases in the MHC-PMS involving the role ‘Medical Receptionist’
Figur 5.5 mental-health.ucase.violet

28 Use case i MHC-PMS actor Use case actor Actor: Rolle Ekstern system
Figur 5.3 mental-health2.ucase.violet actor Use case actor La merke at Patient Record system er et annet system Actor: Rolle Ekstern system

29 Tabellbeskrivelse av ‘Transfer data’ use-case
MHC-PMS: Transfer data Actors Medical receptionist, patient records system (PRS) Description A receptionist may transfer data from the MHC-PMS to a general patient record database that is maintained by a health authority. The information transferred may either be updated personal information (address, phone number, etc.) or a summary of the patient’s diagnosis and treatment. Data Patient’s personal information, treatment summary Stimulus User command issued by medical receptionist Response Confirmation that PRS has been updated Comments The receptionist must have appropriate security permissions to access the patient information and the PRS.

30 Use case modellering Use cases ble opprinnelig utviklet for å støtte utforming av krav og er en del av UML. Hvert use case representerer en oppgave som innebærer ekstern samhandling med en aktør Et use case forteller en historie om å oppnå et mål, eller som et sett av historier om både å oppnå og å feile. Aktører i et use case kan være mennesker eller andre systemer. Use case-beskrivelser er skjematisk og i en mer detaljert tekstlig form Modeling user interaction is important as it helps to identify user requirements. Modeling system-to-system interaction highlights the communication problems that may arise. Modeling component interaction helps us understand if a proposed system structure is likely to deliver the required system performance and dependability. Use case diagrams and sequence diagrams may be used for interaction modeling.

31 UML: Unified Modelling Language
Klassediagrammer: klassene i systemet og assosiasjoner mellom disse klassene Aktivitetsdiagrammer: aktivitetene som er involvert i en prosess Use case-diagrammer: samspillet mellom et system og dets omgivelser Sekvensdiagrammer: samspillet mellom aktører og systemet, og mellom systemkomponenter Tilstandsdiagrammer: hvordan systemet reagerer på interne og eksterne hendelser (--)

32 Sekvensdiagram for ‘View patient information’
Figur 5.6 mental-health.seq.violet Participant Message Return Life line Activation Self-call

33 Sekvensdiagrammer Sekvensdiagrammer er en del av UML og brukes til å modellere samspillet mellom aktører og objekter innenfor et system. Et sekvensdiagram viser rekkefølgen av interaksjoner som finner sted i et bestemt use case Objektene og aktører involvert er oppført langs toppen av diagrammet, med en prikket linje trukket ned vertikalt Interaksjoner mellom objekter er merket med kommenterte piler.

34

35 Sekvensdiagram for Transfer Data
mental-health5.7-Info.seq.violet Sekvensdiagram for Transfer Data

36 UML: Unified Modelling Language
Klassediagrammer: klassene i systemet og assosiasjoner mellom disse klassene Aktivitetsdiagrammer: aktivitetene som er involvert i en prosess Use case-diagrammer: samspillet mellom et system og dets omgivelser Sekvensdiagrammer: samspillet mellom aktører og systemet, og mellom systemkomponenter Tilstandsdiagrammer: hvordan systemet reagerer på interne og eksterne hendelser (--)

37 Tilstandsdiagram for en mikrobølgeovn
Initial state State Transition Event Final state Superstate; concurrent boundary Condition (later) Figur 5.16 Figure5.16microoven.state.violet These model the behaviour of the system in response to external and internal events. They show the system’s responses to stimuli so are often used for modelling real-time systems. State machine models show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another. Statecharts are an integral part of the UML and are used to represent state machine models.

38 Tilstander og stimuli for en mikrobølgeovn (a)
State Description Waiting The oven is waiting for input. The display shows the current time. Half power The oven power is set to 300 watts. The display shows ‘Half power’. Full power The oven power is set to 600 watts. The display shows ‘Full power’. Set time The cooking time is set to the user’s input value. The display shows the cooking time selected and is updated as the time is set. Disabled Oven operation is disabled for safety. Interior oven light is on. Display shows ‘Not ready’. Enabled Oven operation is enabled. Interior oven light is off. Display shows ‘Ready to cook’. Operation Oven in operation. Interior oven light is on. Display shows the timer countdown. On completion of cooking, the buzzer is sounded for five seconds. Oven light is on. Display shows ‘Cooking complete’ while buzzer is sounding.

39 Tilstander og stimuli for en mikrobølgeovn (b)
Stimulus Description Half power The user has pressed the half-power button. Full power The user has pressed the full-power button. Timer The user has pressed one of the timer buttons. Number The user has pressed a numeric key. Door open The oven door switch is not closed. Door closed The oven door switch is closed. Start The user has pressed the Start button. Cancel The user has pressed the Cancel button.

40 Operasjon av mikrobølgeovn
Figur 5.16 -violet

41 Konklusjon Modellering: forstå problem og løsning
UML er ikke et programmering språk Class – statisk synspunkt Activity: flyt/dynamikk Use case: roller og mål Sekvens: oppførsel mellom objekter State: Tilstander i en komponent Lysark tilgjengelig, les alle Les kapittel 5 Øvingstime: Tid for repetisjon med fokus på eksempler Modeller eksemplene vha. Violet

42 2. Time Referansegruppe – plan Eksempler og mer dypdykk i UML

43 Use case diagram

44 Sequence diagram

45 Collaboration diagram
Production Test Planner «user» :EcUsProductionTestConfiguration «external» :EcBsProductionSystem::EcBsProductionSystem :EcBsProductionSystem::EcBsTestSeparator :EcBsProductionSystem::EcBsWell :EcBsProductionSystem::EcBsTemplate :EcBsProductionSystem::EcBsFlowline :EcBsProductionSystem::EcBsFacility «business» :EcBsProductionTest Select Production System() 1 : Select Facility() 4 : Select Flowline() 7 : Select Well() 10 : Select Separator() 15 : Apply() 18 : load() 2 : getProductionSystem() 3 : findFacilities() 5 : getFacility() 6 : findFlowlines() 8 : getFlowline() 9 : findTestSeparators() 16 : getTestSeparator() 17 : getTemplate;2() 11 : findWells() 12 : getWell() 14 : getName() 13 : save() 19 :

46 Class diagram «business» ::EcBsProductionTest productionSystem_
facilityId_ separatorId_ primaryWell_ flowline_ noWells_ startTime_ endTime_ startStableTime_ endStableTime_ recentWells_ selectedWells_ debug_ systemVersion_ EcBsProductionTest;1 EcBsProductionTest;2 EcBsProductionTest;3 getConnectionString getDebug createInterface initialise getProductionSystem getFacility getSeparator getPrimaryWell setPrimaryWell getFlowline setFlowline getStartTime getEndTime getWellAssignment getWells getEnumWells getNoWells getSelectedWells setWells saveWellAssignment addWellToRecordset removeWellFromRecordset getProductionTestData getProductionTestResult setStablePeriod getStablePeriod getStablePeriodStart getStablePeriodEnd proposeStablePeriod createResult save loadTest isWellSelected

47 State diagram Producing Injecting Testing Closed Established

48 Component diagram EcDsProsty.dll EcBsProductionSystem.dll
EcBsProductionTest.dll EcBsPVT.dll

49 UML support in software development
Development processes and UML diagrams Prestudy Requirements specification/analysis Construction/design Implementation

50 Prestudy Activity diagrams should be used to model/describe the current/future business processes, dataflow etc. Try to investigate/model the processes at the same abstraction level (used for communication). Refine processes until the problem space is understood in enough detail to ”find” req’ts. Do not overdo it (analysis paralysis).

51 Activity Diagrams Stereotypes may be used to define special activity classes to obtain/show additional information. Do not use to many colours…

52 Prestudy continued Use cases and Use case diagrams may be used to describe functional req’ts in existing systems. Remember that the cardinality between use cases and dialogues is not necessarily 1:1.

53 UML support in software development
Development processes and UML diagrams Prestudy Requirements specification/analysis Construction/design Implementation

54 Requirement Specification
Functional requirements. Non-functional requirements. Not supported directly in UML. Very important for the design of the software architecture, influence design/ implementation/ selection of support software. Architectural and system description. May use implementation diagrams as a sketch.

55 Functional requirements
Use cases and Use case diagrams. Interaction diagrams (sequence). Class diagrams (business model). State diagrams.

56 Use cases A use case tells a story of reaching a goal, or a set of stories of both getting and failing. A use case is performed by one actor in a timely manner, i.e. should be achieved in a reasonable time. Examining the Goals the system supports makes good functional requirements.

57 Use cases Naming: active verb first. Use cases may be numerated.
To many use case (50+) may mean a wrong understanding/use of use cases.

58 Use cases Use cases address “how to make functional requirements readable, reviewable.” Use cases hold functional requirements in an easy-to-read, easy-to-track, text format. A use case collects how a goal succeeds/fails; A scenario shows one specific condition; Scenarios & use cases nest. Use cases show only the functional req’ts. They make a framework for non-functional requirements & project details. Design is not done only in use case increments.

59 Use cases Use cases do not collect formulae, state, cardinality. Capture them separately (e.g. in the scenario descriptions). Pre- and post-conditions should be used to show dependencies between use cases.

60 Use case diagrams If you find common behaviour in several use cases, this behaviour may be added in a new use case that the other use cases ”inherits” by use of the <<uses>> stereotype. Some use cases may represent alternative or exceptions scenarios for an important use case. These use cases may be extensions of the main use case. This may represent optional behaviour.

61 Use case diagrams Use cases may be organised in diagrams:
Together with related use cases (same business process/area). For each actor. Remember that actors represents active roles, not named people or passive systems/people.

62 Use cases and Interaction diagrams
Write the use case scenarios so that you can use the stepwise description directly as steps in interaction diagrams (especially sequence diagrams). Each use case is normally realised by an interaction diagrams.

63 Business Class Model Only address business/domain classes.
Classes may be found: Statically by studying the functional requirements/domain knowledge. Dynamically from the interaction diagrams. Show associations, optionally cardinality. Assign associations when classes need to know about another. Look both ways.

64 Business Class Model Add important methods/attributes, e.g. from the construction of interaction diagrams. Remember the meaning of using interaction diagrams in this context; do not dig to deep (then you are designing). Use analysis patterns where applicable. May uncover use cases.

65 Business Class Model If the model grows large, use packages.
Use state diagrams if classes have interesting life cycles. Build in teams. CRC Cards may be useful. Use inheritance to make abstractions of common classes. A super class may replace many subclasses/associations.

66 Baseline architecture
Consists of: Use cases. Domain model. Technology platform. Non-functional requirements. Foundation for construction/implementation.

67 Persistence Schemas may be modelled by using class diagrams.
Class = Entity. Association = Relation. Association cardinality. Needs generally to solve M:N relationships. Tools will normally have functionality to data modelling (ER). Stereotypes may be used to distinguish persistent classes and relations from the business/design class model.

68 UML support in software development
Development processes and UML diagrams Prestudy Requirements specification/analysis Construction/design Implementation

69 Construction/design Class and Object diagrams. Interaction diagrams.
State diagrams. Activity diagrams.

70 Construction/design Transform the business model to a design model. Use stereotypes to show where the classes belong, some tools may relate these class variants. Every business class will not be design class. Some business classes and processes may be modelled as interfaces. Interfaces are independent of implementation.

71 Construction/design Classes that implement interfaces ”refines” the interfaces. Interaction/activity diagrams may be used to model algorithms (important functions).

72 Construction/design Avoid mixing groups of classes that is not related in the same diagram. Try to achieve loose coupling and high cohesion! Look for reuse of designs from e.g. design patterns.

73 Construction/design Remember that all relationships (associations, dependencies, aggregations) means coupling. Coupling is however necessary to make the system do something, to collaborate. Use packages to handle complexity, to minimize coupling, and keeping the model elements cohesive.

74 Construction/design Use case scenarios provide the basis for design with responsibilities. Assign responsibilities to classes that have the knowledge to perform an activity. Responsibility-based design is based on role-playing a walkthrough of a scenario.

75 Construction/design Multiple scenarios provide the basis for asserting that the design delivers the required function. Use of failure scenarios make the design complete & robust. Split large classes, join small classes. Decide how to implement cardinalities. Consider Design by Contract.

76 Software Architecture
UML does not address important non-functional requirements that influence the software architecture. Use implementation diagrams to model the software architecture. Identify components and interfaces. Model component interactions. Use class diagrams and interactions diagrams.

77 Software Architecture
Components are typically abstractions at a coarser level than classes. Components and interfaces may represent a use case at different levels. Split persistence (data), control (business) and user interface.

78 UML support in software development
Development processes and UML diagrams Prestudy Requirements specification/analysis Design Implementation

79 Implementation Implementation issues affects design models.
Programming Language mechanisms. Architectural issues. Navigation in associations may be revealed/changed. Use round-trip engineering to create/update code from design/design from code. Dependencies may have been introduced. Some classes may have appeared/disappeared. Associations may have appeared/disappeared.

80 Testing Use case scenarios are a good starting point for an acceptance test. Pre- ,post-conditions and invariants may be of help in defining integration and unit tests (these may be modelled formally by OCL).

81 Summary Use case (diagrams). Capture requirements.
Planning and controlling iterations. Design/implement the most critical/important use cases first. Grouping of use cases.

82 Summary Class/Object diagrams. Business/domain modelling (prestudy).
Specification models (construction). Do not try to use all available notations. Start with the single stuff (classes, associations, attributes and generalisation). Introduce other notations only if you need them. Do not model everything, concentrate on key areas. Keep in mind which stage the model are supposed to be used in.

83 Summary Interaction diagrams - Shows collaborations.
Looks at the behaviour of several objects within a use case. May be used to look at the behaviour of business methods, outline algorithms (class method).

84 Summary Activity diagrams. Analysing work flow. Analysing a use case.
Understanding workflow across many use cases. Dealing with multi-threaded applications.

85 Summary Implementation diagrams. State diagrams. Handle complexity.
Show architecture as components. Show dependencies. Show physical implementation (in little use). State diagrams. Model interesting object life cycles (across several use cases). Important in real-time systems.

86 References G.Booch, J. Rumbaugh, I. Jacobson: The Unified Modeling Language User guide, Addison-Wesley 1999 Martin Fowler: UML Destilled, Addison-Wesley 2004 (3rd ed.)