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

35 Selv om disse ikke er en del af UML, kan CRC, Class-Responsibilty-Collaborator cards, kort være til hjælp under tildeling af ansvar. Dette er indekserede kort, et for hver klasse, hvor ansvaret for hver klasse beskrives kort sammen med en liste over de objekter der samarbejder med klassen. GRASP patterns kan selvfølgelig anvendes ved udfyldelsen af disse. Datamatikeruddannelsen forår/efterår 2005 Side 35 av 67

36 Use case realisering med GRASP patterns Objektdesign - Interaktionsdiagrammer Kilden kan være domæne-modellen, en use case eller en kontrakt til en systemhændelse, hvis det er lavet. Dette vurderes ud fra hvor langt i projektet man er kommet osv Use case realisering er en beskrivelse af hvordan en use case realiseres i Design modellen i form av samarbejdende objekter. Udtrykkes i Interaktionsdiagrammer. I kollaborationsdiagrammer: Et pr use case I sekvensdiagrammer: Kan slå alle use case's sammen i et diagram, men der bliver ofte lavet et sekvensdiagram pr use case for at det skal være overskuelig Udgangspunktet kan være kravspecifikation i form af domænemodellen eller system operations kontrakter. OBS Kravene er ikke at betragte som komplette, og kan godt indeholde fejl. begrebsmæssige klasser fra domænemodellen kan godt bruges som udgangspunkt for klasser i designmodellen, men ikke nødvendigvis. "Opskrift" Designet starter med at man tager udgangspunkt i en systemhændelse fra en use case 1. Vælg kontollerklasse, enten en eksisterende klasse, en kontroller eller en session Opret en decideret kontroller klasse hvis systemhændelsen er så kompleks at dette er nødvendig. 2. Evt opret nyt objekt. Identificer Creator ud fra f.eks Creator mønsteret. Vurder valget ud fra mønstrene Lav Kobling og Høj Binding og Information Expert 3. Evt udfør handling ud fra system kaldet. Vurder valget ud fra mønstrene Lav Kobling og Høj Binding 4. Opdater interaktionsdiagram. Når det ikke drejer sig om at oprette et objekt eller at identificere en kontroller, er Information Expert det mønster man først overvejer ud fra, ellers er Creator/Controller førstevalg. En anden måde at finde den oprettende klasse (Creator) på er at anvende Information Expert. Vurder hvordan Creator vil fungere, ud fra mønstrene Lav Kobling og Høj Binding. Andre mål for design arbejdet: Low representational gap Design af opstart. - Designes sidst i processen for at sikre at al nødvendig information er skaffet til veje i det forudgående arbejde med design. Opret et initial domain object, som det første objekt der oprettes og får ansvar for at oprette childobjekter - f.eks Store, der opretter Register. Persisterende objekter er objekter der gemmes f.eks på harddiskene, ItemSpecifications. Under opstart kan disse indlæses i RAM Datamatikeruddannelsen forår/efterår 2005 Side 36 av 67

37 Visibilitet i designmodellen Designmodellen: Bestemme Visibilitet For at et objekt skal kunne sende en melding til et andet objekt, må afsenderobjektet være synlig for modtager. Dvs at afsender må have en slags reference eller pointer til modtagerobjektet Når man designer interaktionsdiagrammer må man forvisse sig om at der er den visibilitet mellem klassen til stede der er nødvendig for at understøtte interaktionen ved hjælp af meldinger UML notation for visibilitet: Normalt er visibilitet evnen for klasser til at se hinanden, eller at have en reference til hinanden. Mere generelt handler det om en klasses naturlige arbejdsområdet. Er en ressource, såsom en instans af en klasse(objekt) indenfor en anden klasses naturlige arbejdsområdet? Kriteriet for at vurdere synlighed: For at et objekt A skal kunne sende en melding til et objekt B, må B være synlig for A Man taler om 4 måder at opnå synlighed på Attribut synlighed - Objektet B er en attribut til objektet B Parameter synlighed - B er et parameter til en metode i A Lokal synlighed - B er en lokal variabel i en metode i klassen A Global synlighed - B er på en eller anden måde synlig globalt i klassen A Datamatikeruddannelsen forår/efterår 2005 Side 37 av 67

38 Attribut synlighed Attribut synlig fra objekt A til objekt B foreligger når A har B som attribut. Dette er en relativt permanent synlighed eftersom den eksisterer så længe der findes et objekt af klassen A. Dette er en almindelig type synlighed i et objektorienteret system. Denne type synlighed er nødvendig f.eks hvis A har behov for metoder i objektet B. Parameter synlighed Parameter synlighed fra A til B foreligger når en metode i klassen A tager en instans af B som attribut. Dette er en midlertidig synlighed, da den bare eksisterer indenfor den aktuelle metodes arbejdsområde. Det er almindelig at omgøre en parameter synlighed til attribut synlighed. Dette sker ved at man opretter en instans af klassen B under initialiseringen af klassen A. I dennes konstruktør. Så vil man initialisere B i en klassevariabel og man taler så om attribut synlighed. Lokal synlighed Lokal synlighed fra A til B foreligger når B oprettes som en lokal variabel i en metode i A. Dette er også en midlertidig synlighed eftersom den bare eksisterer i metodens arbejdsområde. Lokal synlighed kan opnås på måder: Opret en ny lokal instans af B og læg den i en lokal variabel. Tildel en lokal variabel et objekt som resultat af et lokalt metodekald. En anden måde at opnå lokal synlighed på et ved at bruge resultatet af et metodekald som et parameter til en metode: anobject.getfoo().dobar Som med parameter synlighed, vil man ofte omgøre en lokal synlighed til en attribut synlighed. Global synlighed Global synlighed fra A til B foreligger når B er en global variabel i forhold til A. Dette kan bl.a. opnås ved at erklære B for en global variabel (Environment variable). Dette er ikke mulig i Java, men kan gøres under f.eks. C++. Dette er en relativt permanent synlighed, da den eksisterer så længe A og B eksisterer. Datamatikeruddannelsen forår/efterår 2005 Side 38 av 67

39 UML notation for synlighed UML anvender stereotyper for at markere type af synlighed i collaborations diagrammer. Disse bruges imidlertid bare når det er nødvendig for forståelsen Datamatikeruddannelsen forår/efterår 2005 Side 39 av 67

40 Skabe Design Class Diagrams Med fuldførelsen af interaktionsdiagrammerne for use case realisations for den aktuelle iteration, er det muligt at identificere specifikationerne for software-klasserne og interfaces. UML-notationen har notation for at vise design detaljer i klassediagrammer Design Class Diagrams. Når udvikles DCD Almindeligvis bliver interaktionsdiagrammerne og DCD udviklet samtidig. Mange klasser, metoder og forhold mellem klasser kan ridses op tidlig ved hjælp af mønstre for ansvarstildeling, før man laver interaktionsdiagrammer. Det er mulig, og ønskelig, at arbejde lidt på interaktionsdiagrammerne, opdatere DCD, udvide interaktionsdiagrammerne osv. Disse klassediagrammerne kan bruges som et alternativt, mere grafisk alternativ til CRC-cards for at nedfælde ansvar og samarbejde. DCD og UP terminologi Et Design Class Diagram illustrerer specifikationerne til softwareklasser og interfaces. Klasser, associationer og attributter Interfaces med deres operationer og konstanter Metoder Informationer om type af attributter Navigering Afhængigheder I modsætning til klasser i domænemodellen, der viser begrebsmæssige klasser, viser DCD definitioner for softwareklasser. UP definerer ikke specifikt Design klassediagrammer, dette er et begreb der slår sammen betydningen Klassediagram i Design Modellen, og er en alment brugt betegnelse. Skabe en Design Class Diagram 1. Identificer de klasser der deltager i software løsningen. Disse kan findes ved at gennemgå alle interaktionsdiagrammerne og lave en liste over klasser. 2. Tegn et klassediagram for disse klasserne og sæt på de attributter der findes i domænemodellen, og som også bruges i design. 3. Læg til metodenavne. Metoderne til hver klasse kan identificeres ved at gennemløbe interaktionsdiagrammerne. Navngivning af metoder. Følgende tages i betragtning ved navngivning af metoder: Forståelsen af create meldingen Create meldingen er en uafhængig UML-melding. Implementeret i programkode skal den kalde sprogets facilitet for instanciering af et nyt objekt(java - new). Dannelsen af metoder for adgang Accessor og mutator metoder (get og set) udelades p.g.a høj noise-to-value-ratio Forståelse for meldinger til multiobjekter En melding til et multiobjekt skal forstås som en melding til dennes container/collectorklasse. Disse er almindeligvis predefinerede biblioteksklasser(java.util) og udelades derfor normalt pga noise-to-value Datamatikeruddannelsen forår/efterår 2005 Side 40 av 67

41 Sprog-afhængig syntaks Nogle programmeringssprog har en syntaks der adskiller sig fra almindelig UML-format. Man bør alligevel holde sig til UML-format. Oversættelsen bør finde sted først ved programmering. Mængde informationer Vurderes ud fra: Hvis den skabes som en case tool til automatisk generering af kode, skal al tænkelig information inkluderes. Hvis diagrammet er som dokumentation til software udviklere, skal man nøje overveje noise-tovalue-niveauet. Associationer og navigering Hver ende af en association kaldes en rolle. I DCD'er kan rollen bl.a. indeholde navigeringspile, der viser synlighed fra kilde til målklasse.. Navigering er en egenskab ved en rolle der indikerer at det er muligt at navigere begge veje langs en association. Navigering implicerer visibilitet vanligvis attribut synlighed. De aller fleste, om ikke alle, associationer i en DCD bør udstyres med navigeringspile. Den nødvendige synlighed og association mellem klasser kan findes i interaktionsdiagrammerne. Her er almindelige situationer hvor en association skal udstyres med navigeringspile: A sender en melding til B A opretter en instans af B A behøver at opretholde en forbindelse til B Dependenciy relationships UML inkluderer en generel afhængigheds forbindelse der inkluderer at et element(objekt, use case osv) har kendskab til et andet element. Dette illustreres med en prikket linje mellem klasserne (ikke associationer s. 295) Default visibility Hvis visibilitet ikke er angivet for attributter eller metoder, betyder dette bare ikke specificeret hvad angår UML. Det er imidlertid en almindelig konvention at attributter er private og metoder er public. DCD og UP Inception Design Modellen of DCD bliver vanligvis ikke startet før i elaboration, da dette kræver design beslutninger der er for tidlige i inception Elaboration løbet af denne fase vil optræde DCD'er sammen med use case realisation interaktionsdiagrammer. De kan blive oprettet for de fleste arkitektonisk vigtige systemelementer. Construction DCD vil blive generet fra source kode som en visualisering af de statiske strukturer i systemet. Datamatikeruddannelsen forår/efterår 2005 Side 41 av 67

42 Implementationsmodellen - Mapping design til kode Når interaktionsdiagrammerne og Design Class Diagrammet er fuldført for den aktuelle iteration, de der tisltrækkeligt med detaljer til at begynde kodning. UML artefakterne dre skabes under Design, interaktionsdiagrammerne og DCD'erne, vil blive brugt som input til kodningen. Implementation model UML definerer implementation model.denne indeholder implementations artefakter som kildekode, database definitioner, JSP/XML/HTML sider osv. Udvikling og ændringer under implementation En del beslutninger og en del nyskabning blev udført under arbejdet med design. I løbet af kodningen og testing vil dette arbejdet blive forbedret eftersom detaljerede problemer dukker op og bliver løst. Hvis design artifakterne er godt lavet, vil de resultere i en solid kerne, der ekspanderer efterhånden som man støder på nye problemer under kodningen. Ændringer i koden og den iterative proces En styrke i den iterative udvikling er at resultaterne fra den forrige iteration bruges som input til den næste. Dette vil sige at resultater fra følgende analyse og design forbedres som følger af tidligere arbejde med implementation. Overføre design til kode. Implementering i et objektorienteret programmeringsprog indebærer kodning af: Klasse og interface definitioner Metode definitioner Skabe klassedefinitioner fra DCD'erne Som det mindste kan man finde følgende information fra DCD'erne: Klasse- og interfacenavne, superklasser, metodesignaturer og simple klasse attributter. Definer en klasse med metoder og simple attributter Definer software-klasser med (tomme) metoder og deres attributter samt klassevariabler ud fra klasserne i DCD'et. Læg til reference attributter En reference attribut er en attribut i form af en reference til et andet komplekst objekt, og ikke en primitiv data type. Reference attributterne til en klasse er udtrykt som associationer og navigering i DCD'et, og de fleste reference attributterne til en klasse er impliceret, heller end eksplicit udtrykt. Sæt reference attributterne i koden. Reference attributter og rollenavne Rollenavne i DCD'en kan f.eks. bruges som variabelnavne i koden Datamatikeruddannelsen forår/efterår 2005 Side 42 av 67

43 F.eks fra klassen SalesLineItem: Skabe metoder fra interaktionsdiagrammer Et interaktionsdiagram viser de meldinger der bliver sendt som respons på et metodekald. Rækkefølgen af disse meldingene oversættes til en serie statements i selve metodedefinitionen. Container/collectionklasser i koden Det er ofte nødvendig for et objekt at beholde synlighed til en gruppe af andre objekter. Behovet for dette kan ses ud fra multiplicitet i et klassediagram. I OO programmering bliver disse ofte implementeret ved hjælp af en container eller collectionklasse. En klassen med multiplicitet 1 definerer en reference attribut der peger på en container/collection klasse indeholdende instancer af klassen med mange multiplicitet. Datamatikeruddannelsen forår/efterår 2005 Side 43 av 67

44 Implementering af metoden makelineitem efter collaboration diagram: Rækkefølge af implementerering Klasser implementeres, og helst gennemtestet, fra den mindst koblede til den mest koblede. Test-først programmering En practice hentet fra Extreme Programming(XP), og som kan anvendes på UP, er test-først programmering. Efter denne praksis, bliver testkode skrevet før produktionskoden. Den grundlæggende rytme er at først skrive lidt test kode, så skrive produktionskode, der gennemtestes. Sådan fortsætter det. Fordele: Testkode bliver faktisk skrevet Tilfredsstillelse for programmøren Man får rent faktisk testet sin kode. Det er til tilfredsstillelse for programmøren at vide at koden rent faktisk virker Opklaring omkring interfaces og opførsel Skrivning af testkode vil afdække en klasses eksakte interface og opførsel Synlig verificering af koden undervejs Man kan nemmere ændre ting når man har testkode tilrådighed Opsummering Overføringen fra DCD til klassedefinitioner og fra interaktionsdiagrammer til metoder er relativt ligefrem. Der er imidlertid masser af plads for beslutninger, ændringer i design og udforskning under programmering. Men de store ideer omkring design er selvfølgelig været vurderet inden programmeringen. Datamatikeruddannelsen forår/efterår 2005 Side 44 av 67

45 Programmering og udviklingsprocessen Når interaktionsdiagrammerne og DCD i den pågående iteration er ferdige, har man tilstrækkelig dokumentation til at påbegynde domænelaget i applikationen. UP definerer Implementation Model, der består af artifacts som kildekode, database definitioner, JSP/XML/HTML-sider osv Kodning er ikke en del af OOA/D, det er målet med den. De dokumenter der fremstilles i UP Design Model giver den nødvendige information til at skabe programkode. Styrken ved OOA/D og OO programmering er at man får en sammenhængende vej fra kravspecifikation til programmering, og dokumentation og programmeringsmetode passer sammen. Programmering De beslutninger der er taget omkring design i de foregående iterationer er ikke endelige, og vil blive påvirket af arbejdet med at skabe programkode. Artifacts fra design giver et godt udgangspunkt for at skabe programkode, men vi forventer at problemer og udfordringer i selve programmeringsarbejdet og implementation, vil føre til ændringer i designmodellen. En af styrkene ved iterativ/incremental systemudvikling er at resultatet af den foregående iteration er input for den næste. Dvs at hvis der ikke er samstemmighed mellem programkode og design modellen ved udgangen af en iteration, bliver dette udgangspunkt for arbejde med den næste. Datamatikeruddannelsen forår/efterår 2005 Side 45 av 67

46 Implementering i et objekt orienteret programmeringssprog indebærer at man skriver kildekode for: Klasse og interface definitioner Metode definitioner Definere klassedefinitioner fra DCD's Definer en klasse med metoder og simple attributter Som det mindste, definerer DCD navne på klasser og interfaces, metoder og simple variabler for hver klasse. Dette er nok til at skrive grundlæggende klassedefinitioner i et objektorienteret programmeringssprog. Rollenavne der optræder i collaborationsdiagrammerne skal implementeres i programkoden Skabe metoder fra interaktionsdiagrammerne Interaktionsdiagrammerne viser meldinger der er sendt som respons på et metodekald. Rækkefølgen af disse meldingene oversættes til en serie af kommandolinjer i klassen, som metodedefinitioner Container/Collection klasser Det er ofte nødvendig for et objekt at have synlighed til en gruppe af andre objekter. Behov for dette fremgår som regel fra multipliciteten i et interaktionsdiagram. I OO programmering implementeres disse ved at definere en container eller collection klasse. Den ene klassen har så en reference til Container/Collection klassen, der indeholder mange objekter af den samme klasse. Valget af container klasse er afhængig af hvilke behov der skal opfyldes. En ordnet liste implementeres som List (F.eks. Java ArrayList). Skal man bruge en nøgle til at slå op i data, implementeres dette med en Map (F.eks. Java HashMap). Datamatikeruddannelsen forår/efterår 2005 Side 46 av 67

47 Modellere generaliseringer i Domænemodellen Generalisering og specialisering er fundamentale principper i domænemodellen. Disse sikrer en økonomisk beskrivelse af domænet, og er til inspiration ved senere definition af software klasser. Generalisering Aktivitet hvor man identificerer begrebsmæssige klassers fælles egenskaber, og ud fra dette definerer begrebsmæssige superklasser (Generelt koncept) og subklasser (Specialiseret koncept). Definere subklasser og superklasser En begrebsmæssig definition af en superklasse er mere generel eller vejledende end en definition af en subklasse. Der er to regler der gælder ved definition af et klassehiearki. Disse regler kan også bruges som hjælpemidler ved definitionen af super- og subklasser % regelen 100% af definitionen til den begrebsmæssige superklasse skal gælde for den begrebsmæssige subklasse. Subklassen må overholde superklassens definition 100% angående: attributter associationer 2. Er en regelen En begrebsmæssig klasse skal være et medlem af det sæt der udgør superklassen Dette indebærer at subklassem er en slags af superklassen. KontantBetaling (subklassen) er en Betaling UML notation En korrekt defineret subklasse skal overholde begge disse reglerne! Begrundelser for at dele begrebsmæssige op i subklasser 1. Subklassen har yderligere attributter der er interessante at beskrive. 2. Subklassen har yderligere associationer der er interessante at beskrive. 3. Subklassen behandles, reageres på eller manipuleres anderledes end superklassen, eller andre subklasser. 4. Subklassen representerer en ting i bevegelse, f.eks. et dyr eller en robot, der opfører sig Datamatikeruddannelsen forår/efterår 2005 Side 47 av 67

48 anderledes end superklassen eller de andre subklasser. Ud fra disse regler, er det interessant at dele Betaling op i de forskellige betalingstyper fordi de har forskellige attributter og ikke behandles ens ud fra hvilken type betaling man taler om. Når skal man anvende begrebsmæssige superklasser Når den potentielle subklassen repræsenterer en variant af et lignende koncept. Subklassen overholder både 100% regelen og er en regelen. Alle subklasserne har fælles attributter som kan beskrives i en superklasse. Alle subklasserne har fælles associationer som kan beskrives i en superklasse. Klassen Betaling er relevant at dele op i et hiearki, da de definerede subklasser alle repræsenterer varianter af klassen betaling. Alle subklasserne overholder de 2 regler der er sat op. Alle subklasserne har en fælles attribut Beløb der kan beskrives i en superklasse, og endelig er de alle associeret med klassen Udleje, der skal betales via klassen Betaling. Ved definition af super- og subklasser i domænemodellen, skal man kun beskrive det der er relevant og der bidrager til at fremme forståelsen. Hvis beskrivelse i et hiearki gør diagrammet uforståeligt uden at bidrage væsentlig til at beskrive domænet, skal man vurdere at forenkle sin domænemodel! Abstrakte begrebsmæssige klasser. Hvis alle medlemmer af klassen Betaling, også er et medlem af en subklasse, så er klassen Betaling en abstrakt begrebsmæssig klasse. En abstrakt klasse noteres i UML ved at klasssenavnet skrives med kursiv skrift. Modellering af klassers tilstande. En klasses forskellige tilstande skal ikke modelleres i et klassehiearki. Klassers tilstande modelleres i domænemodellen ved at Definer et hiearki med klassens tilstande, og lav en association til denne Lad være med at beskrive tilstande til begrebsmæssige klasser i domænemodellen. Hiearkier af klasser og arv Software klasser i et hieraki arver attributter og metoder fra de tilhørende superklasser. Dette er ikke aktuelt i domænemodellen hvor nyttige begrebsmæssige klasser beskrives. Derfor er det ikke aktuelt at tale om arv i de hiearkier af klasser der beskrives i domænemodellen. Datamatikeruddannelsen forår/efterår 2005 Side 48 av 67

49 Viderefør domænemodellen Associationsklasser I en associationsklasse kan man tilføre nye egenskaber til en association. Hvis en klasse C kan have mange samtidige værdier i en attribut A, skal man ikke placere attributten i klassen C, men placere attributten A i en anden klasse der er associeret med klassen C. En person kan have mange personnumre. Placer telefonumrene i en ny klasse, f.eks. Telefonumre, og lav en association til klassen Person. Associationsklasser kan være aktuelle når: En attribut er relateret til en association. Instancer af associationsklassen har evig afhængighed af associationen. Der er en mange-til-mange association mellem to koncepter, og information er knyttet til selve associationen. Tilstedeværelsen af mange-til-mange associationer er en almindelig indikator for at det kan være nyttigt at oprette en associationsklasse. Aggregation og komposition Aggregation er en slags association som bruges til at modellere helhed-dele forhold mellem ting. Helheden kaldes composite. Fysiske samlinger, kan f.eks. organiseres i aggregationer. Et eksempel på dette er at en hånd aggregerer fingre. Composite agregation Fyldt rombe Dette betyder at de enkelte dele kun er med i et helheds objekt. Dette implicerer at helheden ekslusivt ejer delene, og at de kan organiseres i en træ struktur. Dette er den mest almindelige form for aggregering. En finger er en del af kun en hånd! Hvis multipliciteten på composite objektet er en, kan delene ikke eksistere uden composite objektet. Hvis multipliciteten er 0..1, er dette muligt. Delt aggregering Åben rombe Delt aggregering betyder at multipliciteten på det objektet der repræsenterer helheden kan være mere end 1. Dette implicerer at delene kan være en del af flere objekter der repræsenterer en helhed. Dette er sjældent for aggregeringer der repræsenterer fysiske strukturer, men anvendes mest på ikke fysiske koncepter. Datamatikeruddannelsen forår/efterår 2005 Side 49 av 67

50 Hvordan identificere en aggregation I nogle tilfælde er brugen af aggregeringer oplagt, specielt hvis man skal repræsentere fysiske genstande. Ellers er det ikke alltid klart. Hvis man er i tvivl: Udelad aggregeringer. Vurder at bruge aggregering når: Når en del, i hele sin livscyklus er bundet til en helhed der er en opret-slet afhængighed. Der er et oplagt del-helhed fysisk eller logisk helhed. Operationer på helheden får de samme konsekvenser for delene, så som sletning, flytning, gem. Fordele ved at vise aggregering Det at identificere og illustrere aggregeringer er ikke meget vigtigt. Mange systemudviklere har brugt unødig tid på diskussioner om emnet under arbejde med domænemodellen. De fleste fordele er relateret til design, hvorfor repræsentation af aggregering kan udelades fra domænemodellen: Det klargør begrænsninger i domæne, om hvorvidt dele i en helhed kan eksistere udenfor helhedens eksistens. Dette har konsekvenser for opret-slet afhængigheder mellem helhed og deler i softwareklasser og database elementer (referentiel integritet og cascade ved sletning). Det understøtter identifikationen af creator (objektet der repræsenterer helheden) ved hjælp af GRASP Creator pattern. Operationer, så som kopier og slet, anvendt på helheden får som regel den virkning på delene. Associationers rolle navne Hver ende af en association er en rolle med ulige egenskaber, så som Navn identificerer enden på en association, og beskriver den rollen objektet spiller i associationen. Kan udelades. Associationens navn er da lig med rollenavnet. Multiplicitet Roller som koncepter versus roller i associationer Fordelen ved brugen af roller i associationer er at det giver et nøjaktig udtryk. På den anden side, udelader dette muligheden for at tilføje associationer og andre associationer. Datamatikeruddannelsen forår/efterår 2005 Side 50 av 67

51 Qualified associations Association, hvor der peges på hvilken attribut der bruges når der peges på en samling objekter i domænemodellen. Denne må ikke bruges til at tage beslutninger om design her i domænemodellen, men bruges udelukkende til at beskrive de faktiske forhold i problemområdet. Refleksive associationer Når et objekt referer til sig selv. Ordnede elementer Datamatikeruddannelsen forår/efterår 2005 Side 51 av 67

52 Del op domænemodellen med pakker En domænemodel kan hurtig blive så stor at det er hensigtsmæssig at dele den op i pakker. Et element ejes af den pakke det er defineret i, men man kan godt associere til elementer i andre pakker. Så bruges følgende navngivningskonvention: Pakke::Pakke::Element Pakke afhængighed Vises med en stiplet linje med en pil, der angiver retningen. Hvis man ikke har tegnet et pakkediagram, men alligevel ønsker at oplyse hvilken pakke et element tilhører, kan dette oplyses i en UML note. Retningslinjer for opdeling af domænemodellen Grupper elementer der har følgende til fælles: har samme formål eller koncept er i samme klassehiearki deltager i de samme use case's er stærkt associatieret med hinanden Datamatikeruddannelsen forår/efterår 2005 Side 52 av 67

53 Det er nyttigt hvis alle elementene der er relateret til domænemodellen samles i en pakke med navnet Domæne, og at delte almindelige kærne koncepter samles i en pakke der kaldes Kærne Elementer eller Almindelige Koncepter, hvis man mangler en pakke at placere dem i. Datamatikeruddannelsen forår/efterår 2005 Side 53 av 67

54 Modellér opførsel i tilstandsdiagrammer Tilstandsdiagrammer bruges til at illustrere hændelser og tilstande til forskellige ting, f.eks. transaktioner, use cases, mennesker osv. Vi bruger først og fremst tilstandsdiagrammer på use cases, men de kan også bruges på enhver klasse. Hændelser, Tilstande og Overgange En hændelse er en signifikant eller bemærkelsesværdig optræden. F.eks. Telefonrøret løftes op. En tilstand er et elementets tilstand på et givet tidspunkt tidsrummet mellem 2 hændelser. En telefon er ledig fra røret lægges på til det løftes af igen. En overgang er et forhold mellem to tilstande, der indikerer at når en hændelse opstår, går den fra en tilstand til en ny. Når hændelsen løft røret opstår, går telefonen fra tilstanden ledig til tilstanden optaget. Tilstandsdiagrammer Tilstandsdiagrammer illustrerer interessante hændelser og tilstande til et objekt, og dettes reaktioner på en hændelse. Overgange vises med pile mærket med hændelsens navn. Tilstande vises med rektangler med runde hjørner. Det er almindelig at vise en start tilstand, der automatisk ændres når der oprettes en instans. Et tilstandsdiagram viser livscyklusen til et objekt. Hvilke hændelser det kan komme ud for, dets tilstande mellem hændelserne. Diagrammet behøver ikke at vise alle mulige hændelser. Hvis en hændelse opstår som ikke er beskrevet, ignoreres denne, hvad angår diagrammet. Dermed kan man lave mer eller mindre detaljerede diagrammer efter ens behov. Anvendelse Tilstandsdiagrammer kan bruges på mange UML elementer, f.eks. Klasser Både begrebsmæssige og software klasser. Use cases Eftersom et helt system ikke kan representeres med en klasse, kan det også få sit eget tilstandsdiagram. Tilstandsdiagrammer i UP Der findes ikke en tilstans model i UP. Tilstandsdiagrammer indgår som et element i de forskellige modeller, Domænemodellen, Designmodelen osv. Tilstandsdiagrammer til use cases Datamatikeruddannelsen forår/efterår 2005 Side 54 av 67

55 En nyttig anvendelse af tilstandsdiagrammer er at beskrive den gyldige sekvens af eksterne systemhændelser i en use case. I løbet af use casen Salg, må man ikke udføre hændelsen udførbetaling før hændelsen afslutsalg. Under use casen redigerdokument i en tekstbehandler, må man ikke udføre Fil- Gem før hændelserne Fil-Ny eller Fil- Åbn er udført. Et tilstandsdiagram der viser systemhændelserne og deres sekvens i en use case, kaldes en use case statechart diagram. Brugen af Use Case Tilstandsdiagrammer Dette kan være nyttig til en stor og kompleks use case med mange systemhændelser, som f.eks. brugen af en tekstbehandler. Her kan det være til stor hjælp med et tilstandsdiagram der viser sekvensen af systemhændelser, og deres korrekte rekkefølge. Under design og implementering er det nødvendig at skabe og implementere et design der ikke tillader at systemhændelser ikke sker i ukorrekt rækkefølge. Med et sæt use case tilstandsdiagrammer kan en designe systemet på en måde som sikrer korrekt rækkefølge i systemhændelser: Hard coded tester af betingelser på om hændelser optræder udenfor orden. Brug af State mønsteret. Slå af enheter i brugergrænsesnittet for at forhindre ulovlige systemhændelser. State machine interpreter der kører et tilstandstabel over use casen. Tilstandsafhængige objekter Hvis et objekt alltid reagerer på samme måde på en hændelse, er det at betragte som tilstandsuafhængig. Et tilstandsafhængig objekt reagerer forskellig på hændelser alt efter sin tilstand. Lav tilstandsdiagrammer for tilstandsafhængige objekter med en kompleks opførsel. Almindelige tilstandsafhængige klasser Objekter der ofte er tilstandsafhængige, og det derfor kan være nyttig at lave tilstandsdiagrammer for: Use cases Betragtet som en klasse, vil use casen Process Sale reagere anderledes på endsale, hvis et salg er forestående eller ikke. Stateful sessions Server software objekter der representerer kørende sessions eller kommunikation med klienter. En session kan f.eks representerere en use case. Datamatikeruddannelsen forår/efterår 2005 Side 55 av 67

56 Systemer Dette er en klasse der representerer hele systemet. Vinduer Edit-Paste hændelsen er kun gyldig hvis der er noget i udklipsholderen. Controllere Dette er GRASP controller objekter. Transaktioner Måden transaktioner (Salg, bestilling, reservation, betaling) reagerer på hændelser er ofte afhængig af dens aktuelle status i sin livscyklus. Enheder TV, mikrobøgeovn: De reagerer uligt på en bestemt hændelse efter hvilke tilstand de er i. Role mutators Dette er klasser der ændrer sin rolle. Illustrere eksterne og interne hændelser. Hændelser kan indeles i interne, eksterne og midlertidige hændelser: 1. Eksterne hændelser, eller systemhændelser En hændelse der er forårsaget af noe, f.eks. en aktør, udenfor systemet. SSD'erne beskriver disse. 2. Intern hændelse. En hændelse der forårsages af noget i systemet. Softwaremæssig taler man om en intern hændelse når en metode kaldes, f.eks. via et signal eller en melding der sendes fra et andet internt objekt. Meldinger i interaktionsdiagrammerne beskriver disse. 3. Midlertidig hændelse. Startes på en bestemt dato eller klokkeslæt. Softwaremæssig taler vi om events der udløses af en timer eller systemuret. Brug heller tilstandsdiagrammer til at vise eksterne og midlertidige hændelser, og reaktionen på disse, heller end på interne hændelser, der ofte bliver bedre beskrevet i interaktionsdiagrammer. Datamatikeruddannelsen forår/efterår 2005 Side 56 av 67

57 Yderligere UML notation for tilstandsdiagrammer. Tre vigtige elementer: 1. Overgangs handling - Transition actions Et elements overgang fra en tilstand til en anden, kan udløse en hændelse. I en software implementering kan dette f.eks. dreje sig om et bestemt metodekald. 2. Overgangs betingelsetransition guard conditions En overgang kan have en beskyttelse i form af en logisk test, der skal opfyldes før handlingen kan udløses. 3. Indlejrede tilstande - Nested states. En tilstand kan indeholde underliggende tilstande, der arver overgangen fra elementets tildligere tilstand. I diagrammet er der vist hvilke tilstande en telefon kan komme i når den (allerede) er i tilstanden Rør af. Datamatikeruddannelsen forår/efterår 2005 Side 57 av 67

58 Kort oversigt over aktuelle GoF mønstre Bruges ved design af use case realiseringer. GoF Gang of Four Et af 23 patterns i en anerkendt bog om systemudvikling skrevet af 4 forfattere Gang of Four Facade mønsteret Problem: En fælles interface for et sæt af implementeringer eller brugergrænsesnit, som inde i et subsystem, er nødvendig. Dette kan skyldes at der er nødvendig høj kobling til elementer inde i subsystemet, eller implementeringen af subsystemet kan ændres. Løsning: Definer et enkelt kontakt punkt til subsystemet et facade objekt der repræsenterer det. Dette facade objektet repræsenterer et enkelt brugergrænsesnit og er ansvarlig for opgaverne til de enkelte elementer i subsystemet. Observer/Publish-subscribe mønsteret Problem: Forskellige typer objekter (subscriber) har behov for informationer om ændringer i tilstand eller hændelser hos et publisher objekt, og skal reagere når publisher objektet udløser en hændelse. I tillæg skal der bevares lav kobling til publisher objektet. Løsning: Definer en subscriber eller listener interface. Subscriber implementerer dette interfacet. Publisher kan på en dynamisk måde registrere sunscribers, og underrette dem når en hændelse opstår. Singelton mønsteret Problem: Nøjagtig en instans af èn klasse er tilladt det er en singleton. Objekter har behov for et enkelt, globalt adgangspunkt. Løsning: Definer en statisk metode i klassen der returnerer denne singleton. Datamatikeruddannelsen forår/efterår 2005 Side 58 av 67

59 Design logisk arkitektur med mønstre Arkitektur Organiseringen og strukturer til de store elementene til et software system., og systemets opførsel, hvad angår systemets store komponenter og subsystemer og hvordan de arbejder sammen. Systemets arkitektur kan defineres ud fra flere vinkler: Den logiske arkitektur, der beskriver systemet ud fra dets begrebsmæssige organisering i lag, pakker, klasser, interfaces og subsystemer. Opsætningsarkitekturen, der beskriver systemet ud fra tildeling af processer til enheder, og netværks konfiguration. Mønstre for arkitektur og kategorier af mønstre 1. Arkitektoniske mønstre Relateret til store og grovkornet design. Bruges typisk i tidlig design (elaboration), når systemets overordnede struktur og forbindelser skal etableres. Layers mønsteret der bruges til at strukturere systemet i store lag 2. Design mønstre Bruges ved design af små og mellemstore objekter og frameworks. Anvendelig når de store enheder, der er etableret ved hjælp af Layers mønsteret, skal forbindes. Facade mønsteret der kan bruges til at danne en interface fra det ene laget til det andet. Strategi mønsteret der tillader pluggable algoritmer 3. Idiomer Lav niveau design orienteret ud fra implementering og programmeringssprog. Singleton mønsteret der sikrer global adgang til en enkel instans af en klasse. Mønster Layers Løsning: Organisere systemets store, logiske komponenter i diskrete lag med adskilte, relaterede ansvarsområder, med en ren sammenhængende opdeling af problemer. Dette på en sådan måde at de nederste lag er på lavt niveau, og med mere generelle tjenester og de højere lag er mere specifik for applikationen. Problem: Ændringer i kilde koden spredes ud i systemet mange dele af systemet er højt koblet. Applikationslogikken er blandet sammen med brugergrænsesnittet, og kan derfor ikke genbruges med et andet brugergrænsesnit, eller overføres til en anden proces node. Mulige generelle tekniske tjenester eller forretnings logiske enheder er blandet sammen med applikationsspecifik logik, så den ikke kan genbruges, distribueres til en anden node, eller erstattes med en anden implementering. Der er høj kobling mellem forskellige problemområder. Dette gør det vanskelig at dele arbejde op på en måde der er egnet for forskellige udviklere. Datamatikeruddannelsen forår/efterår 2005 Side 59 av 67

60 På grund af høj kobling og sammenblanding af problemer, er det vanskelig at udvikle funktionaliteten, skalere op systemet eller opdatere det med ny teknologi. GUI rapporter HTML, XML, Javascript Præsentation Interface, UI, View Modtager beskeder fra Præsentation arbejdsgange Sesjoner side- eller vindusovergange Applikation Workflow, Proces, Mediator Afhængighed Mere applikationsspecifik Modtager beskeder fra Applikation Implementering af domæneregler Domæne tjenester Domæne Business tjenester, Model Generelle lav niveau business tjenester Bruges i mange forretningsdomæner Business infrastruktur Lav niveau business tjenester Høj niveau tekniske tjenester og rammer Tekniske Tjenester Teknisk infrastruktur Høj niveau tekniske tjenester Lav niveau tekniske tjenester, værktøjer og rammer -Data strukturer, tråde, DB, netværks I/O Foundation Kerne tjenester Lav niveau tekniske tjenester/infrastruktur Område for anvendelighed I de tidlige iterationer kan man se at i nogle tilfælde se at kun Præsentation, Domæne og Tekniske Tjenester er repræsenteret, da de første udkast til arkitekturen ofte er grove, unøjaktige skitser der bliver forbedret i takt med udviklingen af systemet. Eftersom udviklingen går iterativt, er det almindelig at lag diagrammet er enkelt i begyndelsen, og udvikles over iterationene i elaboration fasen. Det vigtigste i de tidlige iterationer er at etablere systemets kerne arkitektur, og nogle forløbige skitser der er mere omfattende og detaljeret. Nedenstående diagram er ikke så omfattende, og indeholder relativt få pakker. Dette er typisk for et arkitektonisk view. Det viser bare få, men interessante, elementer for at vise de grundlæggende ideer i arkitekturen. Datamatikeruddannelsen forår/efterår 2005 Side 60 av 67

61 Applikationslaget er udeladt i dette diagrammet. Det vil højst sandsynligvis komme i en senere iteration. Den eneste pakke der er vist, der naturlig tilhører applikationslaget er AnkomstHandler. Foundation Layer er ikke med, da det ikke vil vise nye eller interessante informationer. Datamatikeruddannelsen forår/efterår 2005 Side 61 av 67

62 I nogle systemer er applikationslaget ikke påkrævet, enten hvis systemet er lille, eller der er få objekter der styrer de forskellige use case sessioner. Applikationslaget er som regel nødvendig hvis: Mange brugergrænsesnit, f.eks. web sider og et grafisk brugergrænsesnit. Applikationslaget optræder som en adapter der styrer de nødvendige data til de forskellige brugergrænsesnit. I distribuerede systemer hvor Domænelaget og Præsentationslaget ikke er på samme node. Det er vanligvis nødvendig at have kontrol med status til de forskellige sesioner. Domænelaget kan, og bør ikke have kontrol over sesionerne Der er en defineret arbejdsgang med en kontrolleret rekkefølge af vinduer eller web sider der skal præsenteres. Scenarier med interaktioner mellem pakker og lag Pakkediagrammer viser statiske relationer. For at vise hvordan objekter kommunikerer gennelagene, bruger man interaktionsdiagrammer. Dette skal udformes så det bare viser interessante oplysninger om hvordan objekter kommunikerer gennem lag og pakkernes grænser. Stereotyper: Singleton refererer til brugen af Singleton mønsteret. Subsystem vises her som et objekt, men er i realiteten en diskret enhed med en interface og en bestemt opførsel. Beslutninger om design på et arkitektonisk niveau 1. Hvad udgør de store delene af systemet? 2. Hvordan er de forbundet? Pakker versus subsystemer Nogle pakker eller lag er bare en begrebsmæssig samling af elementer. Ægte subsystemer har i tillæg Datamatikeruddannelsen forår/efterår 2005 Side 62 av 67

63 en opførsel og sit eget brugergrænsesnit. I UML kan et subsystem identificeres med stereotypen «subsystem». Subsystemer og facade mønsteret. For de fleste pakker der udgør et subsystem, er GoF mønsteret facade det vanligste indgangspunktet. Dette vil sige at et public facade objekt repræsenterer en indgang til subsystemet. En facade skal helst kun vise et fåtal høj niveau tjenester. Ellers kan den blive usammenhængende. Hvis facaden placeres på en egen node, kan mange, høj niveau tjenester komme til at udgøre en flaskehals for netværket. Hvis melemskabet til et lag er svært at definere. Specielt mellem Tekniske Tjenester og Foundation og mellem Domain og Business Services kan det være svært at placere objekter i det rigtige lag. Det kan være svært at definere om et objekt er på højt eller lavt niveau, eller om det er specifikt eller generelt. I første omgang vil man placere objekterne der de ser ud til at høre hjemme. Man kan alltid flytte dem senere. Tekniske Tjenester og Foundation, kan i nogle tilfælde slås sammen til et lag Infrastructure Layer. Datamatikeruddannelsen forår/efterår 2005 Side 63 av 67

64 Session Facade og Applikationslaget I et system med mange system operationer, og der understøtter flere use cases, er det almindeligt at have flere objekter der står for kommunikation mellem Præsentationslaget og Domænelaget. Da er det hensigtsmæssig med et Applikationslag med objekter der sørger for kontrol med sesionerne for hver use case. Disse kaldes Sesion Facades, og anbefales brugt i GRASP Controller mønsteret. Controller mønsteret beskriver almindelige valg for Handlere på klient siden (Kontrollere), for systemoperationer der udgår fra Presentationslaget. Logisk eller Proces og Deployment som udgangspunkt for arkitekturen. Lagene i arkitekturen er en logisk måde at betragte denne på. Den viser ikke hvordan processer skal skal og proces noder skal stilles op. Dette er nemlig et spørgsmål om hvilken platform systemet skal køre på. Små systemer er beregnet på små enheder, kører måske alt på en node. Større systemer kan fordeles på flere noder. UP Deployment Model bruges til at tegne noders og precessers arkitektur. Denne modellen er stærkt influeret af både den hardware og software systemet skal køre på. Vertikale lag Horisontale partitioner Datamatikeruddannelsen forår/efterår 2005 Side 64 av 67

65 Begreber. Lag den vertikale opdeling af arkitekturen Partitioner den horisontale opdeling af arkitekturen Tier Har traditionelt vært brugt om den horisontale logiske opdeling af arkitekturen, men betyder også en fysisk node. Fordele & ulemper ved lagdelt arkitektur. Ulemper Fordele I nogle sammenhænge vil indførelsen af lage betyde forringet ydelse. For eksempel i grafisk intensive spil, hvor der kræves hurtig kommunikation til grafik komponenterne. Layers mønsteret er et af flere for kernearkitekturen. Det kan ikke bruges i alle situationer. Et alternativ kan være Pipes and Filters. Dette er nyttig hvis applikationen skal sende noget igennem en serie af beregninger, såsom billedbehandling. Opdeling af ansvar, og opdeling af komponenter på højt og lavt niveau. Dette reducerer kobling og afhængigheder, forbedrer helheden og gør det nemmere at genbruge kode Komplekse komponenter indkapsles og deles op Nogle lag kan skiftes ud med nye implementeringer. Dette er normalt ikke muligt for Foundation og Tekniske Tjenester. Lagene på højere niveau, Presentation, Domæne og Applikation er bedre egnet til dette. De laveste lag indeholder kode der kan genbruges. Nogle lag, først og fremmest Domæne og Tekniske Tjenester, kan genbruges. Udvikling i teams fremmes på grund af den logiske opdeling. Implementering: Fra pakker og lag til kildekode. Dele af UP's Implementations Model er organiseringen af koden. For sprog som Java og C# er dette relativt enkelt, eftersom sprogene understøtter dette. I de tidlige stadier af implementeringen er dette vigtigere end senere. Efterhånden som systemet implementeres vil man heller reversere koden ved hjælp af et UML Case Tool og se om de diagrammer der skabes stemmer overens med Design Modellen. For at understøtte genbrug af kode, vil man om muligt navngi pakker mest muligt uafhængigt af applikationen. Specielt komponenter der er generelle og på et lavt niveau. Datamatikeruddannelsen forår/efterår 2005 Side 65 av 67

66 Den klassiske Tre Tier Arkitektur. En tidlig beskrivelse af hvordan en lagdelt arktitektur kan tage sig ud. 1. Interface Vinduer, rapporter etc. 2. Applikationslogik Opgaver og regler der styrer processen. 3. Lagring Permanent lager af data. Hovedfordelen ved en tre tier arkitektur er at al logik placeres i en logisk enhed midt i systemet, og brugergrænsesnittet er helt Lagring Database frit for applikationslogik. Den midterste tier, eller node kommunikerer men den nederste tier, der står for lagring af data. I kontrast til en tre tiers arkitektur står to tiers arkitektur, hvor applikationslogikken er placeret i brugergrænsesnittet. Dette lag kommunikerer direkte med databasen. Der er ingen tier i midten. Denne arkitektur der er egnet for nogle applikationer, f.eks. CRUD Create, Retrieve, Update, Delete. Data intensive systemer. Interface Applikations logik UML notation for en node Interface Applikations logik Gæst Ankomst Beregn Beløb til regning Godkend Udlejning Interface Applikations logik Klassisk 3 tiers arkitektur med 2 noder Klassisk 3 tiers arkitektur med 3 noder Datamatikeruddannelsen forår/efterår 2005 Side 66 av 67

67 Model-View separation prinsippet. Hvilken type synlighed skal andre pakker have til Presentationslaget? Hvordan skal klasser uden vinduer kommunikere til klasser der opretter vinduer? Det er ønskeligt at der ikke er nogen direkte kobling fra andre komponenter til vindues objekter. Vinduer er relaterede til en specifik applikation, mens de andre komponenter helst skal kunne genbruges i andre applikationer, eller udstyres med nye vindues objekter få udskiftet brugergrænsesnittet. I denne sammenhængen er Model et synonym for domænelaget og View et synonym for Præsentationslaget. Gode grunde til at bruge Model-View separation Understøtte en sammenhængende definition af modeller der fokuserer på processerne i domænemodellen, heller end brugergrænsesnittet. Tillade separat udvikling af systemet og brugergrænsesnittet. Minimere ændringer i domænelaget som følge af ændrede krav til brugergrænsesnittet. Tillader at nye views lægges til systemet uden ændringer i domænelaget. Tillade kørsel af systemet udenom brugergrænsesnittet, f.eks. i batch mode, generering af rapporter etc. Model View separation og kommunikation op gennem lagene. Pull-from-above versus push-from-below Hvordan får vinduer informationer der skal vises på skærmen? Normalt er det tilstrækkeligt at de sender forespørgsler til objekter i domænelaget, der vises i vinduer og dialogbokse. Dette kaldes polling eller pull-from-above metode til at vise informationer. I nogle tilfælde er polling ikke hensigtsmæsig, hvis mange objekter skal polles for få ændringer. Typisk for dette er Overvågningsapplikationer, som f.eks. overvåger telekommunikationsnetværk Simulatorer, der kræver visualisering, som applikationer til aerodynamisk modellering. I sådanne tilfælde, kan man anvende en push-from-below model til at opdatere en applikations display. På grund af begrænsningene i Model-View Separation, opstår behovet for indirekte kommunikation fra lavere objekter til vindus objekter i præsentationslaget. Der er to almindelige løsninger: 1. Observer mønsteret. GUI objektet gør sig synlig, som objekt; ved at implementere en interface, som f.eks. PropertyListener. Gæst Ankomst Reservation UIFacade 2. Et Face objekt i Præsentationslaget der modtager anmodninger nedenfra. Gæst Ikke en GUI klasse, men en klasse der giver indirekthed til GUI objekter UIFacade bruges af og til ved behov for push-from-below kommunikation er påkrævet. Datamatikeruddannelsen forår/efterår 2005 Side 67 av 67