Notater til Systemudvikling. Vidar Jon Bauge 2005

Transkript

1 Notater til Systemudvikling Vidar Jon Bauge 2005 Datamatikeruddannelsen forår/efterår 2005 Side 1 av 67

2 Indholdsfortegnelse Artifacts og UP en oversigt Hvad er objektorienteret analyse og design? Iterativ udvikling og Unified Proces Inception Forstå kravene FURPS Use Cases Skriv kravene i sammenhæng Identificer øvrige krav Supplementary Specifikationer Fra Inception til Elaboration Tegne System Sekvens Diagrammer (Elaboration)...16 Domænemodellen visualisering Domænemodellen Associationer Domænemodellen Attributter System Operation Contracts Fra Kravspecifikation til Design i Elaboration Interaktonsdiagrammer Notation GRASP Patterns - Design objekter med ansvar Use case realisering med GRASP patterns Objektdesign - Interaktionsdiagrammer Visibilitet i designmodellen Skabe Design Class Diagrams Implementationsmodellen - Mapping design til kode Programmering og udviklingsprocessen Modellere generaliseringer i Domænemodellen Viderefør domænemodellen Associationsklasser Aggregation og komposition Del op domænemodellen med pakker Modellér opførsel i tilstandsdiagrammer Kort oversigt over aktuelle GoF mønstre Design logisk arkitektur med mønstre Datamatikeruddannelsen forår/efterår 2005 Side 2 av 67

3 Artifacts og UP en oversigt Datamatikeruddannelsen forår/efterår 2005 Side 3 av 67

4 Hvad er objektorienteret analyse og design? Kritisk og fundamentalt er evnen til at tildele ansvar til softwarekomponenter GRASP-patterns Ni fundamentale principper i objektdesign og tildeling af ansvar er organiseret i GRASP-patterns, som er et hjælpemiddel til læring. Analyse Lægger vægt på at undersøge problem og krav heller end løsning Analyse er et vidt begreb der f.eks kan være analyse af krav eller analyse af objekter. Design Design lægger vægt på en begrebsmæssig løsning der opfylder kravene heller end implementering. I den sidste ende kan design implementeres. Objektorienteret analyse lægger man vægt på at finde og beskrive objekter eller begreber i problemområdet. Dice game en meget kort præsentation af processen(up) Definer use cases Definer en domænemodel Definer Interaktionsdiagrammer Definer Design class diagram Definer use case Krav analyse kan indeholde en beskrivelse af relevante processer i domænet. Disse beskrives som use cases. Use cases er ikke objektorienterede. De er bare skrevne historier der beskriver en proces. Definer en domænemodel Objektorienteret analyse går ud på at beskrive domænet ved at klassificere objekter. En opdeling af domænet går ud på at beskrive det i begrebsmæssige klasser, associationer og attributter. Resultatet kan udtrykkes i en domænemodel der viser domænets koncepter og objekter. Definer Interaktionsdiagrammer Objektorienteret design finder software objekter og samarbejde mellem dem. Dette illustreres i interaktionsdiagrammer, hvor interaktioner mellem objekter/klasser vises som meldinger. Software objekt design lader sig inspirere af den virkelige verden, men er ikke en direkte model eller simulering af denne. Definer Design class diagram Datamatikeruddannelsen forår/efterår 2005 Side 4 av 67

5 Iterativ udvikling og Unified Proces UP's vigtigste ide: Iterativ udvikling UP introducerer flere bedste praktiker, men den vigtigste og mest centrale er den iterative udvikling. Udviklingen deles op i korte, tidsbestemte (f.eks. 4 uger), mini-projekter der kaldes iterationer. Resultatet af hver enkelt af disse er et testet, integreret og eksekverbart system. Hver iteration har sine egne kravsanalyse, design, implementering og testaktiveter. Resultatet af hver iteration er et lille, ufuldstændig, men eksekverbart system måske efter iterationer begynder det at blive klart for produktion. Iterationerne generer ingen prototyper eller eksperimentel kode. Selvom hver iteration generelt håndterer nye krav, kan man også gå tilbage og forbedre tidligere udviklet software. En iteration kan f.eks. fokusere på at forbedre ydelsen til et subsystem i stedet for at tilføre nye egenskaber. Output fra hver iteration er input for den næste, og på denne måde står man med et større og mere færdig system for hver iteration iterativ og incrementel udvikling. Åben for ændringer: Tilbagemeldinger og tilpasning Hvert iteration tager for sig en lille del af kravene, designer, implementerer og tester. I tidlige iterationer kan man gå til modtager/bruger og få tilbagemelding på det der er lavet. Dermed kan ændringer implementeres tidlig. Eftersom dette sker i hver iteration, får man tidlig tilbagemelding der kan ændre forbedre systemet. Fordele ved iterativ udvikling Tidlig imødegåelse af høj risici(tekniske, krav, mål, anvendelighed osv) Tidlig synlig fremgang Tidlige tilbagemeldinger og indragelse af kunden. Dette giver et bedre tilpasset system der bedre møder kundens krav Kontrolleret kompleksitet - teamet bliver ikke overvældet af analyse i store mængder eller lange og komplekse trin i udviklingen Det man lærer i løbet af den enkelte iteration kan bruges til at forbedre udviklingen i de kommende iterationer Iterationernes længde og timeboxing UP anbefaler at iterationernes længde er på 2-6 uger afhængig af projektets størrelse. Ved særlig store projekter, hvor teamet er på mer end 100 personer kan iterationerne blive længre pga behov for kommunikation og koordination. Alligevel frarådes det at man går over 6 mndr. Andre af UP's bedste processer og koncepter Håndter høj risici og høj værdi problemstillinger tidlig i forløbet Fortløbende indragelse af brugere for evaluering, feedback og kravspecificering Bygger en sammengængende kernearkitektur i tidlige iterationer Bruger use cases Visuel software modellering (med UML) God håndtering af krav. Evne til ændringer efter ønske UP's faser og begreber for tidsplanlægning Datamatikeruddannelsen forår/efterår 2005 Side 5 av 67

6 1. Inception start vision, business case, system afgrænsning, estimater 2. Elaboration videre udvikling i iterationer, kernearkitektur 3. Construction videre udvikling i iterationer, forberedelse til ibrugtagning 4. Transition beta test, ibrugtagning Discipliner og faser Discipliner Et sæt aktiviteter med tilhørende artifacts omkring et område, f.eks kravs analyse artifact Generel betegnelse for et hvert dokument der skabes i en proces i forbindelse med systemet Business Modeling, Requirements, Design, Implementation, Environment Tilpasning af processen og Development Case I udgangspunktet er alle aktiviteter og artifacts i UP valgbare. Dvs man vælger de aktiviteter og artifacts der er nødendig for at løse den for hånden værende opgave. (Jfr mediciner) Development Case Valgte artifacts i et projekt kan noteres i en development case. Dette er et værktøj til at planlægge processen i forhold til disciplinerne Development case er en artifact fra Enviroment disciplinen Den fleksible UP UP er fleksibel i modsætning til Den sekventielle vandfaldsmodel, hvor man arbejder forløbende og ikke går tilbage og ændrer på tidligere arbejde Arbejde fleksibelt med UP: Reducer antallet af UP artifacts og aktiviteter keep it simple Eftersom UP er iterativ, påbegyndes implementering før requirements og design er færdige. Alle tre tilpasses i processen, bl.a. baseret på feedback Der er ikke en detaljeret plan for projektet. Der er en Phase Plan, på et højt niveau, hvor man anslår store mål, som hvornår projektet er færdig. Detaljeret planlægning findes i Iteration Plan, der planlægger den næste iteration Datamatikeruddannelsen forår/efterår 2005 Side 6 av 67

7 Inception Kort, indledende fase hvor man udforsker spørgsmål som Hvad er projektets vision og business case? Er det mulig, praktisk gennemførbart? Købe eller udvikle? Grov vurdering af kostnader Skal man fortsætte eller afslutte (Go/Not Go)? Man udforsker lige nok til at man får et grundlag for at afgøre om det er praktisk og økonomisk mulig at gennemføre projektet og bestemme om det er bryet værd at foretage en dybere udredning (i elaboration). Varighed: Ikke mere end nogle få uger. Mange artifacts bliver påbegynt, men ikke gjort færdig. Use Case modellen kan navngive de fleste eller alle use cases og aktører, men beskriver bare ca 10% i detaljer Kodning startes i inception, men mest for at give prototyper der illustrerer konceptet, eller er med til at afklare tekniske spørgsmål og for at lave progammerings key show stopper tekniske spørgsmål. Artifact Vision & Business Case Use-Case Model Supplementary Specification Glossary Risk List & Risk management plan Prototypes and proof-of-concepts Iteration Plan Phase Plan & Software Development Plan Development Case Kommentar High level mål & begrænsninger Opsummering af processen(anv. Området) Funktionelle krav og relaterede ikke funktionelle krav Andre krav Domæne terminologi Beskriver forretningsmæssige, tekniske, resourcemæssige, planlægningsmæssige risici og ideer til hvordan imødegå dem Forklarer visionen og bekræfter tekinske ideer Beskriver hvad der skal ske i den første iteration i Elaboration Formodning om Elaborations længde og anstegnelse. Verktøjer, personale, uddannelse og andre ressourcer En beskrivelse af planlagte UP aktiviteter T& artifacts. Datamatikeruddannelsen forår/efterår 2005 Side 7 av 67

8 Forstå kravene FURPS+ Krav Hvad skal systemet kunne og hvilke specifikation er skal det leve op til En primær udfordring er at finde, kommunikere og registrere (dokumentere) kravene i en form der udtrykker sig klart, både til klient/kunde og udviklerteamet. UP definere et sæt af bedst practises, en af hvilken er manage requirements Typer af krav FURPS+ Functional Features, hvad skal systemet kunne Usability Den menneskelige faktor, hjælpesystem, dokumentation Reliabilty Frekvens af fejl under kørsel, evne til genstart, forudsigelighed Performance Responstider, throughput, nøjaktighed, tilgængelighed, ressourceforbrug Supportability Grad af mulighed for tilpasning, vedligehold, internationalisering, konfigurering Plusset i FURPS+ Implementation Ressource begrænsninger, programmeringssprog, værktøjer, hardware etc Interfaces Begrænsninger pga kommunikation med andre systemer Operations Styring af systemet i det operative miljø Packaging Legal Juridiske aspekter licensiering osv Quality attributes Nogle af kravene kaldes quality attributes eller quality requirements. Dette gælder usabilty, reliabity, performance og supportablity. Functional/Non-functional Kravene deles vanligvis op i funktionelle eller ikke-funktionelle krav, dvs at funktionelle krav går på hvordan systemet opfører sig, handler. Alle andre krav er ikke funktionelle. De funktionelle krav behandles og dokumenteres i use case modellen og system features listen i Visionsdokumentet. Andre krav kan registreres i de use cases der er relevante, eller i Supplementary specifications Visionen opsummerer mål på et højt niveau, der bearbejdes i andre dokumenter. Glossay data dictionnary Glossary definere og registrerer ord der bl.a. bruges i kravene Prototyper Datamatikeruddannelsen forår/efterår 2005 Side 8 av 67

9 er en mekanisme til at vise hvad der er ønskelig eller muligt, ved at man laver en model af systemet, der f.eks. kan vise en GUI Datamatikeruddannelsen forår/efterår 2005 Side 9 av 67

10 Use Cases Skriv kravene i sammenhæng Use Case Modellen er en del af Requirement disciplinen. Kunder og slutbrugere har mål eller behov der skal opfyldes gennem brugen af systemet. Use cases er en mekanisme til at opfange og beskrive disse målene. Use casene beskriver målene, og opfyldelsen af dem ved hjælp af historier. Dette er enkelt og forståelig for kunder og brugere. Dermed bliver det enklere for disse at bidrage til udviklingen. Use Cases er kravene(use cases er kravene, men ikke alle kravene). Primært funktionelle krav, dvs F'et i FUPRS+, men beskriver også andre krav jmf punkter som special requirements Begreber Use case En samling af historier der beskriver en aktørs brug af systemet for at opnå sine mål Der findes 3 typer: brief, casual & fully dressed En use case er en samling af relaterede succes og fejl scenarier der beskriver en aktørs brug af systemet for at opnå et af sine mål. Actor Noget med opførsel, som en person(defineret med en rolle), et (andet) computer system, en organisation etc(, der får sine mål opfyldt ved brug af systemet) Scenario(Use case instance) En speciel sekvens af handlinger og interaktioner mellem aktører og systemet. Dette er en bestemt historie om brug af systemet, eller en mulig vej gennem en use case, f.eks. et scenario hvor en kunde køber en genstand og betaler kontant. Alternate Scenario (Extensions) Håndtering af situationer der ikke er planlagt, f.eks hvis der opstår en fejl, eller til forgreninger. RUP's definition af en use case: Et sæt af use case instanser hvor hver instans er en sekvens af handlinger systemet udfører, og der giver et resultat med målbar værdi. Målbar værdi er et nøglebegreb. Typer af use cases Black-box style use cases er den mest udbredte, og den vi bruger. Man lægger vægt på at beskrive hvad systemet skal skal kunne(funktionelle krav, heller end hvordan systemet skal udføre dem som jo er design. Use cases præsenteres i en black box i tre varianter: Brief, Casual & Fully dressed. Nøglespørgsmål/holdning i denne sammenhængen: Hvordan kan brug af systemet føre til målbar værdi, eller opfylde aktørens mål? Dette er vigtigere end at lave en smørrebrødsliste over hvad systemet skal kunde. Fully dressed- nøgleord: Datamatikeruddannelsen forår/efterår 2005 Side 10 av 67

11 Primary actor Stakeholder & interests Precondition Success guarantee (Post condition) Main success scenario Extensions(Alternate flow) Special requirements Technology & data variantions list Open issues Mål og område for en use case Identificering af use cases På hvilket niveau er det nyttig at udtrykke use cases EBP Elementary Business Processes Hjælp til at identificere brugernes mål ved brug af systemet: En opgave udført af en person på et sted, der resulterer i målbar værdi, og ændringer af data Denne definition er ikke absolut i den forstand at man godt kan afvige fra den hvis man skønner at dette er rigtig. Use Case og Goals Aktørene har mål de får opfyldt ved brugen af systemet. En use case på EBP niveau kaldes derfor user goal-level use case. Fremgangsmåden for at lave dem er som følger: 1. Find brugernes mål. 2. Definer en use case for hvert mål. - Fokuser på intension. Hvis man identificere et mål på et højere niveau end EBP tilsiger, kan man overveje om det skal være et sekundært mål, eller man kan prøve at dele det op. Find primære aktører, mål og use cases Use cases defineres for at opnå målene til de primære aktører: 1. Definer systemets grænse. Er det bare en software applikation, en enkelt bruger, eller en hel organisation? 2. Identificer de primære aktører altså de der har mål der skal opfyldes gennem systemet. - Hvem starter/stopper systemet -Hvem udfører systemadministration -osv 3. Hver, identificer deres mål som brugere. Definer dem/del dem op til det laveste mulige niveau EBP 4. Definer uses cases der opfylder brugernes mål. Lav en actor-goal list Aktører Primary actor Har mål der skal opfyldes vha systemet -> Bruger af systemet. Supporting actor Leverer en service til systemet f.eks.andet system der leverer data (DanBib) Offstage actor En aktør der har interesse i systemet, dvs data fra det. Skattesystemer, regnskabssystemer, statistik Datamatikeruddannelsen forår/efterår 2005 Side 11 av 67

12 osv. En off stage aktør leverer ikke data/tjenester til systemet, eller bruger det aktivt, bare modtager data. Use Case diagram UML definerer Use Case diagrammet til at vise aktørene, use casene og deres indbyrdes forhold. Arbejdet med use cases er at skrive tekst. Udarbejdelsen af et use case diagram er underordnet arbejdet med use casene. Low level feature list ID Feature FEAT 1.9 Systemet kan registrere hvert item FEAT 2.4 Systemet logger alle betalinger med kredit til regnskabssystemet Use casene er lavet for at afløse disse listerne. De kan være nyttige, men en komplet liste bliver lang og uoverskuelig. Use cases i UP Use casene påbegyndes i Inception, og videreudvikles i Elaboration: Man forventer i vores eksempel at efter inception er 10% af use casene beskrevet i detaljer, 30% efter 1. iteration, Elaboration, 50% efter 2. iteration, 70% efter 3. og 80-90% efter 4. iteration Man starter med systemets kernearkitektur og de kritiske komponenterne. Først ustabile, men efter hver iteration stabiliseres kravene & use casene mere & mere. Use casene færdiggøres og tilpasses endelig i Construction fasen. Datamatikeruddannelsen forår/efterår 2005 Side 12 av 67

13 Identificer øvrige krav Supplementary Specifikationer Supplementary specifikations Det er ikke tilstrækkeligt at lave use cases. Der er mange andre krav der skal identificeres og beskrives, så som dokumentation, pakking, licensiering osv. Dette gøres i Supplementary specifications. Glossary Her defineres ord og udtrykk, men kan også bruges som en data ordbog. Vision Her summeres visionen for projektet. Dvs en punktvis opsummering af det, hvorfor det skal udvikles, dets problemstillinger, hvem der har interesse i projektet og foreslåede løsninger. Visionen definerer investorenes vinkel til projektet, specifiseret i deres behov. Det indeholder et omrids af de centrale krav og giver den kontraktmæssig basis for de detaljerede tekniske krav. Supplementary specifications - oversigt 1. Introduction 2. Functionality Logging & error handling Pluggable business rules Security 3. Usability Human Factors 4. Reliability Recoverablity 5. Performance 6. Supportability Adaptabilty Configurabilty Implementation Constraints F.eks valg af programmeringssprog Purchased Components Free Open Source Components Interfaces Hardware interface Speciel hardware som stregkodelæser, touchscreen etc Software interface F.eks. Standarder til kommunikation med andre systemer, plugins etc Domaine (business)rules Regler der gælder anvendelsesområdet der har indflydelse på kravene, og dets grad af foranderlighed. Legal issues Juridiske aspekter ved systemet: Licensiering, love der gælder omkring anvendelsesområdet f.eks Datamatikeruddannelsen forår/efterår 2005 Side 13 av 67

14 skattelovgivning, garantiregler etc Information in domains of interest Al information der er relevant, men ikke direkte berører projektet(bagrundsinformation) Constraints er ikke opførsel, men restriktioner på projektet og/eller dets design. De kan være krav, men kendetegnes ved at de lægger begrænsninger på systemet. Quality attributes Krav der specificerer kvalitetsniveauet på de dele af systemet de beskriver, og de omfatter næsten altid alle andre egenskaber ved systemet end de funktionelle. Denne type attributter/krav indeholder ofte kompromiser: F.eks very reliable kan modstride easy to test Der er 2 typer kvalitetsattributtter: 1. Synlige når systemet kører Functionality, usability, reliabilty etc. 2. Ikke synlige når systemet kører Supportability, testabilty etc. Visionen Tidlig i arbejde med kravspecificering er det en god ide at samarbejde om en liste over problemstillinger RUP har en skabelon til formålet: Dette vil sikre ens opfattelse af projektets problemer. Vi har ikke brugt denne da den skal fremstilles i samarbejde med systemets aftager Disse samles i problem statement. The problem of... Affects... The impact which is... A successful solution would be... Introduction Positioning Business Opportunity Problem statement Se ovenstående afsnit Product position statement Altenatives and competition I vores projekt er disse punkter beskrevet i afsnittet Positioning and Problem Description Stakeholder Descriptions Market Demographics Stakeholder(Non user) Summary User summary Key high-level goals and problems of the stakeholders User Level goals User environment Product overview Product perspective Summary of benefits Assumptions and benefits Licensing and installation (Summary of) system features Other requirements and constraints Datamatikeruddannelsen forår/efterår 2005 Side 14 av 67

15 The problem statement Tidlig i arbejde med kravspecificering er det en god ide at samarbejde om en liste over problemstillinger RUP har en skabelon til formålet: Dette vil sikre ens opfattelse af projektets problemer. Vi har ikke brugt denne da den skal fremstilles i samarbejde med systemets aftager, og det er vigtigt at udviklerne klarlægger nøje disse problemerne. System features funktionelle krav Use casene er ikke det eneste sted man får dokumenteret funktionelle krav. Use casene er detaljerede. Kunden ønsker ofte en opsummering af de funktionelle krav. Dette kan gøres i en system feature liste, der giver en oversigt over funktionelle krav på et højere niveau end use casene. Glossary I sin enkleste form er glossary bare en liste over nævneværdige begreber og deres definition. Det sker forbavsende ofte at et almindelig ord anvendes med en lidt anderledes betydning hos de involverede i projektet. Glossary kan også anvendes som en opslagsbog over data, dvs et dokument der definere data om data dvs metadata. I inception bør glossary kun anvendes som glossary. Under elaboration kan man så give glossary rollen som data opslagsbog. Oplysninger glossary kan indeholde: aliases, beskrivelser, formater(enheder), forhold til andre elementer, range of values, validation rules Faserne: Inception SS og visionen påbegyndes, og bearbejdes let Elaboration Eftersom iterationerne skrider frem og og krave og use casene bliver mere og mere færdige(detaljerede) vil visionen og SS mere og mere afspejle de stabiliserede egenskaber ved systemet og de andre krav der er stillet op eg er blevet bearbejdet. I iterativ udvikling er det implicit at uanset hvor meget man anstrenger sig med kravene, vil det være nødvendig med ændringer. Dette gælder også forbedringer i systemet der giver ejeren konkurrencemæssige fordele. I iterativ udvikling er det en centralt pointe at man har et kontinuerlig samarbejde med kunden for evaluering og feedback, så de kan styre projektet i den retning de vil have det. Construction Nå skal kravene, både de funktionelle og alle de andre (Kvalitetsmæssige) være stabiliseret, men ikke nødvendigvis færdige Datamatikeruddannelsen forår/efterår 2005 Side 15 av 67

16 Fra Inception til Elaboration Opsummering af inception En kort kravs-workshop De fleste aktører, mål og use cases identificeret De fleste use cases er skrevet som Brief, ca 10-20% af use casene er beskrevet fully dressed De fleste 'influental' og risikobetonede kvalitets krav er identificeret Visionen og Supplementary Specifikations foreligger i version 1 Risk list: F.eks. Ledelsen vil have en demo af systemet klart til Demoworld om 18 måneder. Om dette kan nås kan ikke vurderes før der er lavet yderligere analysearbejde Tekniske proof-of-concepts prototyper og andre metoder er brugt for at fastslå om projektet er teknisk mulig( Understøtter Java Swing komponenter touchscreen?) UI-orienterede prototyper for at gøre de funktionelle krav i visionen klare Anbefalinger om hvilke komponenter der skal bygges, købes eller genbruges Høj niveau udkast til arkitektur og komponenter foreslåes dette er ingen nøjagtig beskrivelse, men de første overvejelser. Plan for første iteration Udkast til tools list Opsummering af Elaboration Elaboration er den første række af iterationer hvor man for alvor udforsker og analyserer, implementerer kerne-arkitekturen. I tillæg til dette bliver de de fleste krav identificeret og høj-risici områder håndteret. I UP er forretningsmæssig værdi at regne som en del af høj-risici området. Elaboration består ofte af 2-4 iterationer af 2-6 ugers varighed. Iterationerne er timeboxede, dvs at det man ikke når i den aktuelle iteration bliver overført til den næste. Det man laver af prototyper bliver brugt i det endelige system, så al kode skal have kvalitet som produktions kode. Korte timeboxede risk driven iterationer Start programmering tidlig Design, implementerer og test kernen og risikobetonede dele af arkitekturen Tilpas projekter efter feedback fra tester, brugere og udviklere. Skriv de fleste detaljerede use case og andre krav gennem en serie af workshops, en pr. iteration. Planlæg næste iteration Planlæg krav og iteration efter risiko, dækning(coverage) og grad af kritiskhed Risiko inkluderer både teknisk kompleksitet og andre faktorer som usikkerhed omkring indsats eller brugervenlighed(usability) Dækning(Coverage) betyder at alle store dele af systemet blive i det mindste berørt i tidlige iterationer. Måske en overfladisk men omfattende implementering der dækker mange komponenter Grad af kritiskhed(criticality) refererer til funktioner der har høj forretningsmæssig værdi. Disse kriterier bruges til at prioritere arbejde over iterationerne. Use cases og use case scenarios kommer før implementering. Tidlige iterationer implementerer de højest rangerede use casene. I tillæg bliver nogle krav udtrykt som high level features uden sammenhæng til nogen use case. Prioritering sker før man starter på en iteration. Datamatikeruddannelsen forår/efterår 2005 Side 16 av 67

17 Tegne System Sekvens Diagrammer (Elaboration) Et system sekvens diagram er hurtig og nemt at skabe. Det viser input og output events til systemet. Use casene beskriver hvordan eksterne aktører interagere med det system vi er ved at udvikle. Under denne interaktion, generer aktøren handlinger(events) til systemet og anmoder som regel en eller anden respons. F.eks når bibliotekaren indlæser et item nummer der skal udlånes. Et SSD er et billede der viser input/output events for et specielt scenario fra en use case. Alle systemer fremstår som bokse, og det vigtige er events der passerer over systemets grænse mellem dette og aktørene. Man laver kun SSD'er for en use cases main success sceanrio. SSD'er kan bruges til at vise samarbejde mellem systemer. SSD'erer viser events fra scenariet i et use case. SSD'erne er derfor baseret på en use case. Systemgrænsen kan angives med en lodret, stiplet streg ned i gennem SSD'et Navngivning af events Events skal navngives efter hensigt. Navnet kan indeholde parametre i parentes. Navngivningen bliver mere præcis hvis navnet starter med et verb. SSD og use cases I nogle tilfælde kan det være hensigtsmæssig at vise udsnit af use case tekst for at bedre forståelsen. Dette kan gøres som en note. SSD i UP SSD er en del af use case modellen, og er en visualisering af de interaktioner der er beskrevet i use casen. De fleste SSD'er bliver udarbejdet i Elaboration, hvor det er nyttigt at finde frem til detaljer i system events for at klargøre hvilke operationer systemet skal håndtere. Datamatikeruddannelsen forår/efterår 2005 Side 17 av 67

18 Domænemodellen visualisering Domænemodellen er alment brugt som inspiration når der skal designes software objekter, og tager input fra mange andre artifakter. Domænemodellen viser betydningsfulde begrebsmæssige klasser i en problemdomæne. Det essentielle punkt i objektorienteret analyse er at dele et problemområdet op i begrebsmæssige klasser eller objekter domænemodellen kan betagtes som en visuel ordbog over vigtige abstraktioner i domænet. begrebsmæssige klasser En begrebsmæssig klasse kan betragtes ud fra dets symbol, hensigt og extension Symbol ord eller billeder der repræsenterer en begrebsmæssig klasse. Hensigt Definitionen af en begrebsmæssig klasse. Extension Sæt af eksempler der gelder for en begrebsmæssig klasse. Identificering af begrebsmæssige klasser Det er bedre at overspecificere domænemodellen med mange detaljer, heller end at underspecificere den. Strategier til at identificere begrebsmæssige klasser 1. Liste over kategorier af begrebsmæssige klasser Kategori, begrebsmæssig klasse Eksempel Fysiske eller konkrete objekter Bog, kvittering Manualer, dokumenter,referencepapirer, bøger 2. Identificer substantiver fra use cases Der må udvises forsigtighed ved brug af denne metode, da substantiverne i en use case kan have uklar betydning. De ord man finder skal man derfor betragte som kandidater til begrebsmæssige klasser. Hvordan lave en domænemodel 1. List kandidaterne til begrebsmæssige klasser ved hjælp af kategorilisten. 2. Tegn dem ind i en domænemodel 3. Lav associationer mellem der hvor det er nødvendig at bevare information. 4. Læg til attributter der hvor dette er nødvendig for for at bevare information. Navngivning af begrebsmæssige klasser Brug navne fra domænet Fjern irrelevante ting Læg ikke noget til der ikke eksisterer Hvis man ikke tror at en begrebsmæssig klasse X er et tal eller en tekst, er X sandsynligvis en Datamatikeruddannelsen forår/efterår 2005 Side 18 av 67

19 begrebsmæssig klasse. Salg forretning eller Salg Forretning telefonnr begrebsmæssige klasser behøver ikke at repræsentere fysiske genstande. Et godt eksempel på dette er Specifikations-klasser (Kartoteker?) som ItemSpecification, tjenester som klassen Flight(s. 143). Reducere Representational gap Domænemodellen repræsenterer en visuel ordbog. Dette er en afgrundene til at man tilstræber at navngive de begrebsmæssige klasserne med ord fra domæneområdet. En anden vigtig grund er ganske enkelt at det gør dokumentationen nemmere at overskue. Domænemodellen i UP Inception Domænemodellen er ikke motiveret i inception eftersom formålet med inception ikke er dyberegående undersøgelser af problemområdet, men heller en hurtig undersøgelse for at fastslå om man skal lave en dybere undersøgelse i elaboration Elaboration Domænemodellen bliver primært skabt i løbet af iterationerne i elaboration. Her er behovet størst for at forstå begreberne, og man skal finde frem til klasser under arbejdet med design. Datamatikeruddannelsen forår/efterår 2005 Side 19 av 67

20 Domænemodellen Associationer En association er forholdet mellem to typer, eller mere specifikt forholdet mellem to instanser af typer, der indikerer en betydningsfuld og interessant forbindelse. I UML er associationer defineret som det semantiske forhold mellem 2 eller flere klasser, der involverer forbindelse mellem deres instancer. Kriterie for en nyttig association 1. Need-to-know association Associationer der betyder noget, implicerer vanligvis kendskab til et forhold der er nødvendig over en bestemt periode, fra nogle få millisekunder til årevis, alt efter sammenhængen. 2. Associationer defineret ud fra Common Associations List A er en fysisk del af B Kategori Eksempler (Penge?)Skuffe - Kasseapparat A er en hændelse relateret til B Udlån-kunde, Udlån-Item Læseretning navn Multiplicitet Associationer med høj prioritet A er en fysisk eller logisk del af B A er fysisk eller logisk indeholdt i B A bliver registreret i B Roller Hver ende af en association kaldes en rolle. Roller kan have: Navne Multiplicity udtryk Navigering Multiplicitet * - 0 eller flere en til nøjaktig 5 1..* - en eller flere 1 - en 3,5,8-3, 5 eller 8 Datamatikeruddannelsen forår/efterår 2005 Side 20 av 67

21 Hvor detaljeret skal associationerne være? Associationer er vigtige, men det at finde begrebsmæssige klasser er vigtigere, og det meste af tiden der bruges på domænemodellen bør gå til at identificere begrebsmæssige klasser. Navngivning af associationer Navnet til association skal bygges efter følgende skabelon: TypeNavn-VerbFrase-TypeNavn, der kan læses umiddelbart og giver en i sammenhængen fornuftig betydning. Ovenstående eksempel f.eks., der skal læses Item-recordedIn-Lend(Bemærk retningen) Default læseretning er fra venstre til højre, men i ovenstående tilfælde indikerer pilen modsat læseretning. Multiple associationer mellem 2 typer. To typer, eller objekter, kan godt have flere associationer i mellem sig. Dette er ikke specielt uvanlig. Associeringer og implementering Associeringer i domænemodellen repræsenterer ikke data flows eller instancer af software objekter. Det er bare et abstrakt udtryk for et betydningsfuldt forhold mellem to objekter i problemområdet. Under konstruktionen af domænemodellen kan man godt lave associationer der ikke vil blive implementeret i designmodellen. Man skal kun opdatere domænemodellen hvis dette er nødvendig, dvs hvis domænemodellen skal bruges i det senere arbejde. Ellers skal man holde sig til regelen om at man kun opdaterer artifakter der bliver brug senere. Kriterier for at inkludere associationer Fokuser på associationer der hvor forholdet mellem to objekter er nødvendig over tid(need-toknow) Undgå at vise redundante associationer og associationer der kan udledes(oplagte). Et strengt need-to-know kriterie for at beholde associationer kan imidlertid resultere i en minimal information model, der ikke giver tilstrækkelig information om problemområdet. I tillæg til at være en need-to-know domænemodel kan man også være interesseret i at formidle andre vigtige koncepter og deres forhold. Hvis dette er formålet med domænemodellen, skal man selvfølgelig inkludere andre typer associationer hvis dette er nødvendig for forståelsen. Datamatikeruddannelsen forår/efterår 2005 Side 21 av 67

22 Domænemodellen Attributter Det er vigtig at identificere de attributter i domænemodellen der er nødvendig for at formidle den information kravene forudsætter. En attribut er en logisk dataværdi i et objekt. Der gives følgende tommelfingerregel: Inkluder følgende attributter i domænemodellen: De kraven, f.eks. use casene, omtaler eller implicerer at det er nødvendig at bevare information om. UML notation og gyldige attributter Dato Lend int : antal Der er nogle ting man ikke skal inkludere som attributter, men heller som klasser med associationer. Attributter skal helst være simple datatyper, dvs et tal eller en streng i en eller anden form. Komplicerede datastrukturer, der i sig selv indeholder flere attributter, f.eks. objekter af en klasse skal tildeles sin egen klasse i domænemodellen. Så laver man en association for at vise sammenhængen. Under design og implementering gælder denne begrænsningen selvfølgelig ikke. DVS begrebsmæssige klasser skal relateres med associationer, softwareklasser kan godt tage andre softwareklasser som attributter. Data typer Dette er UML betegnelsen der implicerer et sæt af værdier hvor den unikke identitet ikke giver har betydning for vores model, eller system f.eks: Forskellige instancer af tallet 5 Forskellige instancer af strengen cat Forskellige instanser af adress der indeholder den samme adresse Ikke primitive data typer Betragt hvad der ved første blik kan betragtes som en primitiv data type, som ikke-primitiv hvis: Den indeholder flere sektioner telefonnr,navn Der er associerede operationer, f.eks. parsing cprno Det har andre attributter Tilbudspris der hat start og sluttidspunkt Det er en kvantitet med en enhed Beløb i en valuta Er en abstraktion med en af følgende kvaliteter EAN eller UPC kode Hvis man er i tvivl skal man definere noget som en ny begrebsmæssig klasse, heller end en attribut. Datamatikeruddannelsen forår/efterår 2005 Side 22 av 67

23 Kvalitetsattributter og enheder De fleste numeriske enheder repræsenteres som tal, f.eks. pris eller hastighed. Hvis vi designer et system der skal håndtere enheder ud fra f.eks. lokalisering(valuta) ville det være naturlig at give enheden sin egen begrebsmæssige klasse. Eftersom kvantitet betragtes som en data type, hvor den unikke værdi af en instans ikke er vigtig, er det acceptabelt at sætte dem ind som en attribut: Betaling beløb : Mængde Betaling beløb : Valuta Deriverede attributter Deriveret attribut beregnes ud fra antal items der er associeret med Lend I ovenstående eksempel kan 1 objekt af klassen Lend indeholde reference til 1 eller flere items. Antallet kan beregnes ud fra multipliciteten. Dette vises ved at placere et '/' foran attributten. Datamatikeruddannelsen forår/efterår 2005 Side 23 av 67

24 System Operation Contracts Kontakter for operationer er et hjælpemiddel til at beskrive systemet opførsel. De beskriver resultatet af system operationer i form af ændringer i tilstanden til domæneobjekter. SOC er en del af use case modellen Use casene er det primære redskab for at beskrive systemets opførsel, og er for det meste tilstrækkelig. Der er imidlertid nogle tilfælde hvor det er nødvendig med en mere detaljeret beskrivelse af systemhændelser. SOP beskriver detaljeret systemhændelser i form af en beskrivelse af ændringer i tilstanden til objekter i domænemodellen efter udførelsen af en SOP. System operationer er operationer systemet tilbyder sin interface til aktørene, og der håndterer indkommende systemhandlinger. System operationer defineres ud fra indkommende system events og findes i System Sequence Diagrammerne. Alle systemoperationer i et use case udgør tilsammen systemets eksterne interface. En SOC består af følgende komponenter Operation Operationens navn og parametre Cross Reference (Valgfri) De use cases denne operationen optræder i. Precondition En beskrivelse af systemets tilstand inden udførelse af operationen. Postcondition En beskrivelse af systemets tilstand efter udførelse af operationen. Contacts og use cases Use casene er det vigtigste redskab til at dokumentere kraven til systemet. I nogle tilfælde er imidlertid en system event så kompliceret at use casen ikke beskrive den tilstrækkelig. I disse tilfælde giver SSO en detaljeret beskrivelse,specielt i form af postconditions, der beskriver nøjaktig hvad der skete, hvilke objekter blev oprettet/slettet og hvilke attributter og associationer der blev ændret/oprettet/slettet. Skrive SSO'er 1. Identificer system operationer fra System Sequence Diagrammerne 2. Konstruer SSO'er for system operationer der er komplicerede eller behøver nærmere uddybning. 3. For at beskrive postcondition brug følgende kategorier: Oprettelse/Sletning af instanser Ændringer af attributter Associationer der blev oprettet/slettet Postcondition bør skrives i fortid: En item blev oprettet Faserne: Inception: SSO'er laves ikke her da de er for detaljerede. Elaboration: Hvis SSO'er ovehovede bruges, bliver de skrevet i Elaboration, hvor de fleste use cases skrives. SSO'er skrives kun på de mest komplekse eller uklare system operationer. Datamatikeruddannelsen forår/efterår 2005 Side 24 av 67

25 Fra Kravspecifikation til Design i Elaboration Under inception og Elaboration, 1. iteration, er analyse og kravspecificering den mest centrale aktivitet. Ved at følge retningslinjerne i UP, er ca 10% af kravene kortlagt i inception. Disse er videre bearbejdet i elaboration, 1. iteration. I det videre forløb, vil der finde sted en gradvis overgang af fokus fra krav til design, i hver iteration. I de tidlige iterationer, vil det være naturlig at arbejde med design og implementering vil føre til ændringer i kravene. Iterativt Gør de rigtige ting. Gør tingene rigtigt Kravspecificering og objektorienteret analyse har fokuseret på at lære at gøre de rigtige ting, dvs. at forstå de mål man sætter for systemet, samt regler og begrænsninger. I arbejde med design, vil man heller fokusere på at gøre tingene rigtig. Dvs designe en løsning der imødegår kravene for iterationen. Videre til design af objekter Under design af objekter, udvikles der en løsning baseret på objekter. Det centrale i denne, er interaktionsdiagrammerne, som illustrerer hvordan objekter samarbejder for at opfylde målet. Efter, eller parallellt med udviklingen af interaktionsdiagrammerne, kan der udvikles (design) klassediagrammer. Disse opsummerer definitioner på de klasser og interfaces som skal indgå i software'en. Disse artifakter indgår i Designmodellen. Vigtigheden af ferdigheder ved objektdesign versus tegning af UML notation. Det der er vigtig, er ferdigheder i at tænke i, og designe objekter. Dette er en færdighed der er langt vigtigere end at kende UML notation. Imidlertid er et standard visualiseringssprog vigtig for at præsentere sine idéer. Evner til objektdesign versus UML notation. Tegning af interaktionsdiagrammer reflekterer de beslutninger der er taget omkring design. Kunsten at designe objekter, er den færdighed der tæller, heller end hvordan tegne et UML diagram. Objektdesign kræver følgende kundskaber: Principper for tildeling af ansvar. Design mønstre Datamatikeruddannelsen forår/efterår 2005 Side 25 av 67

26 Interaktonsdiagrammer Notation Interaktonsdiagrammer viser hvordan objekter interagerer v.h.a meldinger 2 Typer interaktionsdiagrammer: Collaborations diagram Illustrerer objekterne i et "netværks-format", der minder lidt om et klassediagram -Kan være mindre overskuelig +Mere egnet til at vise meget komplekse strukturer Sequence diagram Objekterne har lodrette "liv-linjer" hvor meldinger vises nedadgående, og fra vestre mod højre. -Kræver stor arkbrædde +mere overskuelig Interaktionsdiagrammer bør ikke laves alene, men 2 sammen. Notation for Kollaborationsdiagram: Objekter: Salg Klasse :Salg Instans av klassen Sale s1:salg Instans s1 av klassen Sale Meldinger: Hvis objektet i modtagerklassen ikke er understreget, betyder det at det er en melding til hele klassen, altså en statisk metode. Datamatikeruddannelsen forår/efterår 2005 Side 26 av 67

27 Opret: Uml stereotypen «create» kan bruges hvis navngivningen ikke er åbenbar Betingelser: Iterationer & Løkker Iteration gennem alle elementene i en collection vises med 2 *'er og dobbel klasseboks Iteration for flere meldinger: Datamatikeruddannelsen forår/efterår 2005 Side 27 av 67

28 Notation for Sekvenssdiagram: Meldinger: Opret: Betingelser: Datamatikeruddannelsen forår/efterår 2005 Side 28 av 67

29 Iterationer & Løkker Iteration for en enkel melding: Iteration for flere meldinger: Datamatikeruddannelsen forår/efterår 2005 Side 29 av 67

30 Iteration over et multiobjekt Kalde klasser og statiske metoder Datamatikeruddannelsen forår/efterår 2005 Side 30 av 67

31 GRASP Patterns - Design objekter med ansvar Ansvar og metoder GRASP at tegne objekter med ansvar definere metoder Responsibility(ansvar) og metoder Der finde 2 typer ansvar: Knowing objekter har ansvar for at Kende til private indkasplede data Kende til relaterede data Kende til ting der kan udledes eller beregnes Doing Selv udføre noget, som skabe et objekt eller udføre en beregning Starte aktivitet i andre objekter Kontrollere og koordinere aktiviteter i andre objekter Ansvar er ikke en metode, men metoder bliver implementeret for at opfylde ansvar. Tildeling af ansvar bliver overvejet/besluttet under dannelsen af interaktionsdiagrammer. Pattern Et pattern er en navngivet beskrivelse af et problem, løsningen, når og hvordan løsningen skal bruges i nye sammenhænge. Pattern name: Patterns har altid navne der siger noget om hvad de handler om. Dette hjælper os til at huske dem, og bedrer derfor kommunikationen Solution: Tildel et ansvar til klassen, så ansvaret bliver fordelt Problem i solves: Efter hvilket princip vi tildeler objekter ansvar. GRASP - General Responsibilty Assignment Software Patterns Er mønstre der er hjælpemidler til at placere ansvar i software objekter. GRASP beskriver fundamentale principper omkring objekt design og tildeling af ansvar udtrykt i mønstre De første 5 GRASP-patterns Start tildeling af ansvar ved klart at udtrykke ansvaret der skal fordeles 1. Information Expert Pattern name: Information Expert eller Expert Solution: Tildel et ansvar til Information Expert den klassen der har den nødvendige information til at opfylde ansvaret Problem: Hvad er et generelt princip ved tildeling af ansvar til objekter? Information Expert bruges ofte. Det er et grundlæggende princip der bruges kontinuerlig ved design af objekter. Det udtrykker den grundlæggende ide at objekter udfører ting ud fra den information de har. Hvis oplysningerne er spredt over flere klasser, kan det være at disse må arbejde sammen for at opfylde ansvaret. Fordele: Indkapslet information beholdes, eftersom objekter bruger sin egen information til at løse opgaven. Dette understøtter vanligvis lav kobling der giver et mere robust system der er nemmere at vedligeholde Opgaver fordeles til objekter der har den nødvendige information. Dermed understøttes mere sammenhængende letvægts klasser der er nemmere at forstå og vedligeholde. Datamatikeruddannelsen forår/efterår 2005 Side 31 av 67

32 Bruges ikke: Hvem har ansvaret for at skrive et objekt til en database Selvom information ekspert måske vil pege på et objekt der indeholder de korrekte informationer, vil princippet om at adskille systemets hovedkomponeter tilsige at man har en klasse der er ansvarlig for indlogging og kommunikation med en (underliggende?) database. 2. Creator Pattern name: Creator Solution: Tilde ansvaret til klassen B hvis en eller flere af de følgende er sande B aggregerer A objekter B indeholder A objekter B gemmer instancer af A objekter B bruger A objekter B har de data der sendes til A når disse initialiseres og oprettes(b er expert) B er creator af A objekter Hvis mere end en af ovenstående er sandt, vælg en klasse B der indeholder eller aggregerer klasse A Problem Hvem er ansvarlig for at oprette en ny instans af en klasse? Oprettelse af objekter er en af de centrale aktiviteter i et objekt orienteret system. Det er derfor nyttigt at have et generelt princip for dette. Fordele: Hvis ansvaret for oprettelse tildeles rigtig, opnår man lav kobling, øget overskuelighed, indkapsling og genbrughed. Bruges ikke: I nogle tilfælde kan oprettelsen af et nyt objekt være kompleks, f.eks. ved betinget oprettelse baseret på en familie af klasser eller genbrug af instancer for at øge performance. I disse tilfælde vil man oprette er hjælpeklasse der kaldes Factory. 3. Low Coupling Pattern name: Low Coupling Solution: Tildel ansvar så man bevarer lav kobling Problem: Hvordan understøttes lav afhængighed, lav effekt af ændringer og øget genbrug? Lav kobling er et princip man skal have i baghovedet under hele design-processen. Det er et princip for at evaluere det arbejde der er gjort. Formålet er at undgå koblinger mellem objekter der gør objekterne mere afhængige end andre objekter end nødvendig. Dermed kan ændringer udføres i et objekt/element uden at dette påvirker andre, noget der gør systemet mindre overskuelig og sværere at vedligeholde. Der er ingen regel der siger at nu er koblingen for høj. Det der er vigtigt er at udviklerne kan måle graden af kobling og vurdere om det kan forårsage problemer. Datamatikeruddannelsen forår/efterår 2005 Side 32 av 67

33 Kontra: I objekt-orienterede sprog som Java og C++ optræder kobling i form af: TypeX har en attribut der refererer til en TypeY instans, eller TypeY selv. Et TypeX objekt kalder en metode i et TypeY-objekt TypeX har en metode der refererer til en instans af TypeY, eller TypeY selv. Dette inkluderer typisk en parameter eller lokalvariabel af TypeY, eller et objekt der returneres er af TypeY. TypeX er en direkte eller indirekte subklasse af TypeY. TypeY er en interface, og TypeX implementerer dette. Fordele: Ændringer i et element/objekt påvirker ikke andre elementer/objekter Elementer/objekter bliver nemmere at forstå alene Gør genbrug nemmere. 4. High Cohesion Pattern name: High cohesion Solution: Tildel ansvar så binding forbliver lav Problem: Hvordan styre kompleksitet? Når man taler om objektorienteret design, er binding et mål på hvor stærkt relateret og fokuseret ansvaret til et element er. Et element med stærkt relateret ansvar og som ikke laver for meget arbejde, har høj binding. En klasse med lav binding gør mange urelaterede ting, eller udfører for meget arbejde. Sådanne klasser er ikke ønskede, da det medfører følgende problemer: Vanskelige at forstå Vanskelige at genbruge Ømfindtlige overfor forandringer Klasser med lav binding repræsenterer ofte en grovkornet abstraktion, eller er blevet tildelt ansvar der skulle have været placeret andetsteds. Som én tommelfingerregel har en klasse med høj binding relativt få metoder, med højt relaterede funktioner, og den udfører ikke formeget arbejde. Den samarbejder med andre klasser om udførelsen af opgaven, hvis denne er for stor. Datamatikeruddannelsen forår/efterår 2005 Side 33 av 67

34 Fordele:Øget klarhed og forståelse af design. Vedligehold og forbedringer bliver nemmere God fordeling af nøje relateret funktionalitet understøtter øget genbrug da cohesive klasser kan bruges til specielle formål. Bruges ikke: Hvis man af tekniske grunde, vil samle alle f.eks. SQL kald i en klasse(en SQL tekniker) Netverkskald, hvor man vil samle kommunikationen i grupper af kald fremfor enkle beskeder for at spare båndbrædde. 5. Controller Pattern name: Solution: Tildel ansvaret for at modtage eller behandle en system event til en klasse der repræsenterer et af følgende valg: Repræsenterer hele systemet, eller dele af det (Facade contoller). Repræsenterer en use case hvor system event'en optræder kaldes ofte en <use case name>handler eller <use case name>session eller <use case name>coordinator Brug samme contoller for alle system event'er i use casen En session er en slags konversation med aktøren. De har ikke nogen bestemt længde, men er ofte organiseret efter use caser Problem: Hvem skal have ansvaret for at håndtere en input system event? En input system event er en hændelse der genereres af en ekstern aktør. De er associeret med system operationer, der er systemets svar på system events. Systemet modtager eksterne input events, f.eks. fra en UI eller eksterne beskeder fra sensorer etc. og koordinerer håndteringen af disse, vanligvis ved delegation til andre objekter. Det er ofte ønskelig at samle alle system events fra en use case i samme controller klasse., så det er muligt at beholde overblikket. Man kan godt vælge forskellige controllere til forskellige use cases. En almindelig fare ved controllere er at de tildeles for meget ansvar. Fordele: Ved at delegere ansvaret for system operationer til contollere, understøtter genbrug af applications kode (i domaine layer) fordi at denne ikke er bundet til interface layer. Dette kan udskiftes med et andet interface. En dårlig designet controller vil have lav binding og håndtere for mange ansvarsområder. Dette kaldes en bloated controller. Tegn på en bloated contoller er: Der er bare en enkelt contoller der modtager alle system events, og der er mange af dem. Contolleren udfører selv mange af de opgaver der skal til for at opfylde ansvaret. Dette indebærer sandsynligvis et brud på Information Expert og High Cohesion En contoller har mange attributter og vedligeholder meget information om systemet eller domænet, der skulle have været delegeret til andre objekter. Når man tildeler ansvar, hvor kigger man først, i domænemodellen eller designmodellen? 1. Hvis der er relevante klasser i Design modellen, led der først. 2. Hvis ikke, led i domænemodellen og prøv at bruge (eller udvide) dens klasser til at inspirere til dannelsen af tilsvarende software klasser. Interface Layer Domaine Layer Interface Layer indeholder en brugergrænseflade, f.eks en (G)UI, der modtager system events og sender dem til en controller, der håndterer og koordinerer dem dvs sørger for at udføre de opgaver der skaludføres. Ansvaret for opfyldelsen af ansvar påhviler klasser i domaine layer. CRC-cards Datamatikeruddannelsen forår/efterår 2005 Side 34 av 67