Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Kapittel 5 System modellering Carl-Fredrik Sørensen.

Liknende presentasjoner


Presentasjon om: "Kapittel 5 System modellering Carl-Fredrik Sørensen."— Utskrift av presentasjonen:

1 Kapittel 5 System modellering Carl-Fredrik Sørensen

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

3 3 Modellering 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). Modellering ≠ Programmering

4 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 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

7 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 8 UML – Unified Modeling Language Ikke en utviklingsprosess eller metode for programvare Kombinerer det beste fra –Datamodelleringskonsepter (ER Diagrams) –Forretningsmodellering (workflow) –Objektmodellering –Komponentmodellering

9 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 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 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 12 UML: Unified Modelling Language 1.Klassediagrammer: klassene i systemet og assosiasjoner mellom disse klassene. 2.Aktivitetsdiagrammer: aktivitetene som er involvert i en prosess 3.Use case-diagrammer: samspillet mellom et system og dets omgivelser 4.Sekvensdiagrammer: samspillet mellom aktører og systemet, og mellom systemkomponenter 5.Tilstandsdiagrammer: hvordan systemet reagerer på interne og eksterne hendelser 6.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 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 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 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 16 Krav 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. Hvorfor? Et slikt system: det er viktig å forstå før man starter implementering

17 17 UML: Unified Modelling Language 1.Klassediagrammer: klassene i systemet og assosiasjoner mellom disse klassene 2.Aktivitetsdiagrammer: aktivitetene som er involvert i en prosess 3.Use case-diagrammer: samspillet mellom et system og dets omgivelser 4.Sekvensdiagrammer: samspillet mellom aktører og systemet, og mellom systemkomponenter 5.Tilstandsdiagrammer: hvordan systemet reagerer på interne og eksterne hendelser (--) Violet open source by By Cay S. Horstmann (http://www.horstmann.com) and Alexandre de Pellegrin (http://alexdp.free.fr) TDT4100Objekt-orientert programmering

18 UML Klasser og assosiasjoner Class name Is associated with 1 = cardinality Violet fil figure5.8 klassediagrammer bidrar til å etablere et vokabular om problemet og løsningen

19 Klasser og assosiasjoner i MHC-PMS 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 Figure 5.9 Fil mental-health.class.violet

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 er En allmennlege er en lege og derfor har han navn, tel, , register og de-register. I tillegg har han en praksis og en adresse Figur violet

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

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

25 Aktivitetsdiagram (Activity Diagram) start stop activity Fork Begge Parallelt Decision Bare en Join Fork Eksterne systemer flow Figur 5.2 mental-health.activity.violet bekrefte forvaring avgjørelse informere pasienten om rettigheter Finne sikkert sted innleggelse Informere Myndighet Informere pårørende

26 26 UML: Unified Modelling Language 1.Klassediagrammer: klassene i systemet og assosiasjoner mellom disse klassene 2.Aktivitetsdiagrammer: aktivitetene som er involvert i en prosess 3.Use case-diagrammer: samspillet mellom et system og dets omgivelser 4.Sekvensdiagrammer: samspillet mellom aktører og systemet, og mellom systemkomponenter 5.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 28 Use case i MHC-PMS actor Use case actor Actor: Rolle Ekstern system Figur 5.3 mental-health2.ucase.violet

29 Tabellbeskrivelse av ‘Transfer data’ use- case MHC-PMS: Transfer data ActorsMedical receptionist, patient records system (PRS) DescriptionA 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. DataPatient’s personal information, treatment summary StimulusUser command issued by medical receptionist ResponseConfirmation that PRS has been updated CommentsThe receptionist must have appropriate security permissions to access the patient information and the PRS.

30 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

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

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

33 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

36 36 UML: Unified Modelling Language 1.Klassediagrammer: klassene i systemet og assosiasjoner mellom disse klassene 2.Aktivitetsdiagrammer: aktivitetene som er involvert i en prosess 3.Use case-diagrammer: samspillet mellom et system og dets omgivelser 4.Sekvensdiagrammer: samspillet mellom aktører og systemet, og mellom systemkomponenter 5.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

38 Tilstander og stimuli for en mikrobølgeovn (a) StateDescription WaitingThe oven is waiting for input. The display shows the current time. Half powerThe oven power is set to 300 watts. The display shows ‘Half power’. Full powerThe oven power is set to 600 watts. The display shows ‘Full power’. Set timeThe 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. DisabledOven operation is disabled for safety. Interior oven light is on. Display shows ‘Not ready’. EnabledOven operation is enabled. Interior oven light is off. Display shows ‘Ready to cook’. OperationOven 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) StimulusDescription Half powerThe user has pressed the half-power button. Full powerThe user has pressed the full-power button. TimerThe user has pressed one of the timer buttons. NumberThe user has pressed a numeric key. Door openThe oven door switch is not closed. Door closedThe oven door switch is closed. StartThe user has pressed the Start button. CancelThe user has pressed the Cancel button.

40 Operasjon av mikrobølgeovn Figur violet

41 Konklusjon Lysark tilgjengelig, les alle Les kapittel 5 Øvingstime: –Tid for repetisjon med fokus på eksempler –Modeller eksemplene vha. Violet leditor/page.php 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 41

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

43 43 Use case diagram

44 Sequence diagram

45 Collaboration diagram

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 49 UML support in software development Development processes and UML diagrams –Prestudy –Requirements specification/analysis –Construction/design –Implementation

50 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 51 Activity Diagrams Stereotypes may be used to define special activity classes to obtain/show additional information. Do not use to many colours…

52 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 53 UML support in software development Development processes and UML diagrams –Prestudy –Requirements specification/analysis –Construction/design –Implementation

54 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 55 Functional requirements Use cases and Use case diagrams. Interaction diagrams (sequence). Class diagrams (business model). State diagrams.

56 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 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 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 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 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 > 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 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 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 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 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 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 66 Baseline architecture Consists of: –Use cases. –Domain model. –Technology platform. –Non-functional requirements. Foundation for construction/implementation.

67 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 68 UML support in software development Development processes and UML diagrams –Prestudy –Requirements specification/analysis –Construction/design –Implementation

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

70 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 71 Construction/design Classes that implement interfaces ”refines” the interfaces. Interaction/activity diagrams may be used to model algorithms (important functions).

72 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 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 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 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 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 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 78 UML support in software development Development processes and UML diagrams –Prestudy –Requirements specification/analysis –Design –Implementation

79 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 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 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 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 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 84 Summary Activity diagrams. –Analysing work flow. –Analysing a use case. –Understanding workflow across many use cases. –Dealing with multi-threaded applications.

85 85 Summary Implementation 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 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.)


Laste ned ppt "Kapittel 5 System modellering Carl-Fredrik Sørensen."

Liknende presentasjoner


Annonser fra Google