Notater til Systemudvikling. Vidar Jon Bauge 2005

Save this PDF as:
 WORD  PNG  TXT  JPG

Størrelse: px
Starte visningen fra side:

Download "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

Noter til dm529. Jonas Nyrup. 11. november 2011

Noter til dm529. Jonas Nyrup. 11. november 2011 Noter til dm529 Jonas Nyrup 11. november 2011 Indhold 1 Kravdisciplinen: Kravmodellen og Indfangning af Krav 2 1.1 (ikke)-funktionelle krav...................... 2 1.2 Kravattributter...........................

Læs mere

Software Design (SWD) Spørgsmål 1

Software Design (SWD) Spørgsmål 1 Spørgsmål 1 Unified Process Du skal give en beskrivelse af Unified Process. Beskrivelsen skal indeholde forklaring på følgende begreber: Phase Iteration Discipline Activity Milestone Artifact Spørgsmål

Læs mere

Software Design (SWD) Spørgsmål 1

Software Design (SWD) Spørgsmål 1 Spørgsmål 1 Unified Process Du skal give en beskrivelse af Unified Process. Beskrivelsen skal indeholde forklaring på følgende begreber: Phase Iteration Discipline Activity Milestone Artifact Spørgsmål

Læs mere

UML til kravspecificering

UML til kravspecificering UML til kravspecificering UML mini-kompendium - til brug i forbindelse med modellering af kravspecifikationer. Copyright 2006 Teknologisk Institut, IT-Udvikling Aktivitetsdiagram 2/9 Aktion Aktionsnavn

Læs mere

Software Design (SWD) Spørgsmål 1

Software Design (SWD) Spørgsmål 1 Spørgsmål 1 Unified Process Du skal give en beskrivelse af Unified Process. Beskrivelsen skal indeholde forklaring på følgende begreber: Phase Iteration Discipline Artifact Milestone Du skal relaterer

Læs mere

Hassansalem.dk/delpin User: admin Pass: admin BACKEND

Hassansalem.dk/delpin User: admin Pass: admin BACKEND Hassansalem.dk/delpin User: admin Pass: admin BACKEND 1/10 Indledning Dette projekt er den afsluttende del af web udvikling studiet på Erhvervs Lillebælt 1. semester. Projektet er udarbejdet med Del-pin

Læs mere

Obligatorisk opgave i objektorienteret analyse og design

Obligatorisk opgave i objektorienteret analyse og design Obligatorisk SD-opgave s. Obligatorisk opgave i objektorienteret analyse og design Løs følgende, som en indviduel opgave. I må gerne samarbejde i grupper, men alle har ansvar for at udfærdige sin egen

Læs mere

Assignment #5 Toolbox Contract

Assignment #5 Toolbox Contract Assignment #5 Toolbox Contract Created by: René Kragh Trine Randløv E mail address cph rk70@cphbusiness.dk 23 11 2014 1 Introduktion Dette dokument indeholder en vertikal kontrakt for et system som skal

Læs mere

Elaboration fase 2. semester projekt 2008-04-11. Gruppe 4

Elaboration fase 2. semester projekt 2008-04-11. Gruppe 4 Indholdsfortegnelse Analysemodeller... 4 Domænemodel... 4 ER-model... 5 Designmodeller... 7 Designklassediagram... 7 Sekvensdiagram... 9 Relationel model... 10 Diskussion af datastrukturer, algoritmer

Læs mere

Eksempel: et ordresystem note 5 Lagdeling s. 1

Eksempel: et ordresystem note 5 Lagdeling s. 1 Eksempel: et ordresystem note 5 Lagdeling s. 1 Eksempel: et ordre-system NiceHair er et firma, som sælger udstyr, inventar og frisørartikler til frisørsaloner over hele landet. Det er ejet af et ægtepar

Læs mere

Side 1. Databaser og SQL. Dagens gang. Databasebegreber. Introduktion til SQL Kap 1-5

Side 1. Databaser og SQL. Dagens gang. Databasebegreber. Introduktion til SQL Kap 1-5 Databaser og SQL Introduktion til SQL Kap 1-5 1 Dagens gang Databaser Database begreber Mapning af klasser til relationel model Normalisering Opgaver til næste gang 2 Databasebegreber A database is a:

Læs mere

Databasesystemer, forår 2005 IT Universitetet i København. Forelæsning 3: E-R modellering. 17. februar 2005. Forelæser: Rasmus Pagh

Databasesystemer, forår 2005 IT Universitetet i København. Forelæsning 3: E-R modellering. 17. februar 2005. Forelæser: Rasmus Pagh Databasesystemer, forår 2005 IT Universitetet i København Forelæsning 3: E-R modellering 17. februar 2005 Forelæser: Rasmus Pagh Forelæsningen i dag Datamodellering hvad, hvornår, hvorfor og hvordan? Business

Læs mere

SOFTWARE PROCESSES. Dorte, Ida, Janne, Nikolaj, Alexander og Erla

SOFTWARE PROCESSES. Dorte, Ida, Janne, Nikolaj, Alexander og Erla SOFTWARE PROCESSES Dorte, Ida, Janne, Nikolaj, Alexander og Erla Hvad er en software proces? Et struktureret sæt af AKTIVITETER, hvis mål er udvikling af software. En software proces model er en abstrakt

Læs mere

Projekt 2, 3. semester WEBPROJEKT

Projekt 2, 3. semester WEBPROJEKT Projekt 2, 3. semester WEBPROJEKT Aflevering d. 11/10-2013 CPH Business URL: www.thorleifbæk.dk/projekt2/index.php Gruppe 2 Shiko, Thorleif, Pernille og Annemette MUL 3A Indholdsfortegnelse s. 3 Factsheet

Læs mere

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet.

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet. MOX og APOS2 Forord Dette dokument er en del af APOS version 2 manualerne. APOS version 2 (APOS2 herefter) er et organisation, klassifikation og personale system baseret på Sag & Dokument standarderne.

Læs mere

Indhold. Side 2 af 26

Indhold. Side 2 af 26 Tema Design Design, Programmering og test af Adressebog Fra d. 17 april til 20 april 2012 Vejledere: Gunhild Marie Andersen Kis Boisen Hansen Gruppe B Deltagere Side 1 af 26 Indhold Indledning.... 3 Kodestandard...

Læs mere

Uge 5.3: (Search,) Select & implement and development methods

Uge 5.3: (Search,) Select & implement and development methods Innovationsprocesser Uge 5.3: (Search,) Select & implement and development methods A A R H U S U N I V E R S I T E T Department of Computer Science 1 Innovation & ICT development *** Innovation *** * ***

Læs mere

Miniprojekt2011. Formålet er at lære og indlære god objektorienteret programudvikling og programmering med Java, samt undervejs at opfylde studiekrav.

Miniprojekt2011. Formålet er at lære og indlære god objektorienteret programudvikling og programmering med Java, samt undervejs at opfylde studiekrav. Miniprojekt2011 Projektbeskrivelse Der skal fremstilles en lille java application på PC, hvor brugeren kan foretage interaktioner med en simpel database på disken via et grafisk brugerinterface. Formålet

Læs mere

Hvem er vi? Kursus Introduktion. Kursuslærerne. Agenda for i dag

Hvem er vi? Kursus Introduktion. Kursuslærerne. Agenda for i dag Hvem er vi? Kursus Introduktion Anne Haxthausen ah@imm.dtu.dk Informatics and Mathematical Modelling Technical University of Denmark 100 studerende med forskellig baggrund: software teknologi It og Kom

Læs mere

DE BEAR TECHNOLOGY. o Processer, metoder & værktøjer. e-mail: info@dbtechnology.dk WWW.DBTECHNOLOGY.DK

DE BEAR TECHNOLOGY. o Processer, metoder & værktøjer. e-mail: info@dbtechnology.dk WWW.DBTECHNOLOGY.DK Mission Critical o Projekt Information management o Processer, metoder & værktøjer. Side 1 of 11 Projekt information Projekt information management inkluderer alle de processer, som er nødvendige for at

Læs mere

SYSTEM DESIGN. 18. december 2012 [Mink Farm Rapport] Dette projekt bruger UP model, som er et krav for dette semesters projekt.

SYSTEM DESIGN. 18. december 2012 [Mink Farm Rapport] Dette projekt bruger UP model, som er et krav for dette semesters projekt. SYSTEM DESIGN Dette projekt bruger UP model, som er et krav for dette semesters projekt. Unified Process (UP) er en iterativ og gradvis softwareudvikling proces ramme, der bruges til at modellere hvad,

Læs mere

Kursusgang 11. Oversigt: Sidste kursusgang Værktøjer til udvikling og implementering af HCI-design Oversigt over Java Swing

Kursusgang 11. Oversigt: Sidste kursusgang Værktøjer til udvikling og implementering af HCI-design Oversigt over Java Swing Kursusgang 11 Oversigt: Sidste kursusgang Værktøjer til udvikling og implementering af HCI-design Oversigt over Java Swing Design af brugerflader 11.1 Samme sted Forskellige steder Sidste kursusgang Samtidigt

Læs mere

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning:

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning: Introduktion til EA3 Mit navn er Marc de Oliveira. Jeg er systemanalytiker og datalog fra Københavns Universitet og denne artikel hører til min artikelserie, Forsimpling (som også er et podcast), hvor

Læs mere

Eksamensopgave Bacheloruddannelse i Informationsvidenskab (2007-studieordning)

Eksamensopgave Bacheloruddannelse i Informationsvidenskab (2007-studieordning) Eksamensopgave Bacheloruddannelse i Informationsvidenskab (2007-studieordning) Eksaminator: Afleveringsdato: Datalogi modul: Digitale repræsentationer, intern bestået/ikke bestået Digitale modeller, intern

Læs mere

ITO... 5. Problemformulering... 5. Indledning... 5. Organisation og Ledelse... 5. Generel beskrivelse af logistik og produktionssystemer...

ITO... 5. Problemformulering... 5. Indledning... 5. Organisation og Ledelse... 5. Generel beskrivelse af logistik og produktionssystemer... ITO... 5 Problemformulering... 5 Indledning... 5 OrganisationogLedelse... 5 Generelbeskrivelseaflogistikogproduktionssystemer... 7 Produktionslayout... 7 Funktionslayout... 7 Gruppelayout... 8 Produktstyring...

Læs mere

Objektorienteret Analyse & Design

Objektorienteret Analyse & Design Objektorienteret Analyse & Design Lars Mathiassen, Andreas Munk-Madsen, Peter Axel Nielsen og Jan Stage ISBN: 87-7751-153-0 Udgave: 3. udgave Udgivelsesår: 2001 Antal sider: 452 Pris: Kr. 410,00 På de

Læs mere

Sporbarhed og Rapportering i Quality Center. Kim Stenbo Nielsen NNIT Application Management Services

Sporbarhed og Rapportering i Quality Center. Kim Stenbo Nielsen NNIT Application Management Services Sporbarhed og Rapportering i Quality Center Kim Stenbo Nielsen NNIT Application Management Services Indhold INTRODUKTION Hvem er jeg Hvad vil jeg fortælle om QC std. rapporteringsfaciliteter EXCEL RAPPORTER

Læs mere

Kapitel 21: Softwarearkitektur designprincipper

Kapitel 21: Softwarearkitektur designprincipper Kapitel 21: Softwarearkitektur designprincipper Miriam Tang Jacob Jensen Lars Christensen Jacob Atzen Onsdag 9/3 Dagens program Definitioner Analyseværktøjer Designprocessen Raffinering Afrunding Design

Læs mere

Procedurer for styring af softwarearkitektur og koordinering af udvikling

Procedurer for styring af softwarearkitektur og koordinering af udvikling LEVERANCE 2.3 Procedurer for styring af softwarearkitektur og koordinering af udvikling Procedurerne vil omfatte: Planlægning af udfasning af gamle versioner af OpenTele Planlægning af modning af kode

Læs mere

Vejledning - Udarbejdelse af gevinstdiagram

Vejledning - Udarbejdelse af gevinstdiagram Vejledning - Udarbejdelse af gevinstdiagram Maj 2015 INDHOLD 1. INDLEDNING... 1 1.1 FORMÅL... 1 1.2 VEJLEDNINGENS SAMMENHÆNG MED DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL... 1 1.3 GEVINSTDIAGRAMMET... 2 1.4

Læs mere

Løsningsforslag til Camp Let. Case Beskrivelse: Camp Let

Løsningsforslag til Camp Let. Case Beskrivelse: Camp Let Løsningsforslag til Camp Let Case Beskrivelse: Camp Let Firmaet Camp Let har til formål at udleje forskellige typer transportable ferieboliger. Det drejer sig i øjeblikket om campingbusser, campingvogne,

Læs mere

Fra Computer til Virkelighed. TPE-kursus Elektroniske Systemer P1

Fra Computer til Virkelighed. TPE-kursus Elektroniske Systemer P1 Fra Computer til Virkelighed TPE-kursus Elektroniske Systemer P1 Fra Computer til Virkelighed En kort introduktion til kurset Systems Engineering Projektfaser Opsamling og opgave Om kurset Mål: at I lærer

Læs mere

Databasesystemer, forår 2006 IT Universitetet i København. Forelæsning 3: E-R modellering. 16. februar 2006. Forelæser: Rasmus Pagh

Databasesystemer, forår 2006 IT Universitetet i København. Forelæsning 3: E-R modellering. 16. februar 2006. Forelæser: Rasmus Pagh Databasesystemer, forår 2006 IT Universitetet i København Forelæsning 3: E-R modellering 16. februar 2006 Forelæser: Rasmus Pagh Forelæsningen i dag Datamodellering hvad, hvorfor og hvordan? Business rules

Læs mere

Studieordning del 4-2014

Studieordning del 4-2014 Studieordning del 4-2014 Fagbeskrivelser Datamatiker AP Graduate in Computer Science Version 1.1 Revideret august 2014 Side 0 af 8 Indhold del 4 Fagbeskrivelser 1. Faget Programmering (PRO)...2 2. Faget

Læs mere

Programmering C Eksamensprojekt. Lavet af Suayb Köse & Nikolaj Egholk Jakobsen

Programmering C Eksamensprojekt. Lavet af Suayb Köse & Nikolaj Egholk Jakobsen Programmering C Eksamensprojekt Lavet af Suayb Köse & Nikolaj Egholk Jakobsen Indledning Analyse Læring er en svær størrelse. Der er hele tiden fokus fra politikerne på, hvordan de danske skoleelever kan

Læs mere

2. En mere fleksibel løsning der er endnu nemmere at anvende for den enkelte bruger

2. En mere fleksibel løsning der er endnu nemmere at anvende for den enkelte bruger CatMan Solution V3 er klar til at blive rullet ud Vi arbejder hele tiden på mange fronter, for at sikre jer endnu bedre og hurtigere adgang til den viden der kan genereres fra store mængder af data. Lancering

Læs mere

Analyse af capabiliteter

Analyse af capabiliteter Analyse af capabiliteter Ressourceanalysen deles op indenfor fire områder [s245]: Kapitel 6: Analysing resources basics Kapitel 7: Analysing human resources Kapitel 8: Analysing financial resources Kapitel

Læs mere

Excercises til Virtuelle Bygn. 2005., gr. 2.117

Excercises til Virtuelle Bygn. 2005., gr. 2.117 Excercises til Virtuelle Bygn. 2005., gr. 2.117 Excercise A Et scenarie er en analyse af udfordringer og fremtidige muligheder for udvikling. Scenariet skal hjælpe med at kommunikere og opnå indsigt i

Læs mere

Software Construction 1 semester (SWC) Spørgsmål 1

Software Construction 1 semester (SWC) Spørgsmål 1 Spørgsmål 1 Objekter #1 Giv en kort præsentation af begrebet objekt, samt hvorledes du erklærer(declare), opretter(create) og bruger objekter Du kan beskrive o Datatyper o Variable / Instans variable /

Læs mere

Design by Contract Bertrand Meyer Design and Programming by Contract. Oversigt. Prædikater

Design by Contract Bertrand Meyer Design and Programming by Contract. Oversigt. Prædikater Design by Contract Bertrand Meyer 1986 Design and Programming by Contract Michael R. Hansen & Anne Haxthausen mrh@imm.dtu.dk Informatics and Mathematical Modelling Technical University of Denmark Design

Læs mere

Rolf Fagerberg. Forår 2013

Rolf Fagerberg. Forår 2013 Forår 2013 Mål for i dag Dagens program: 1 2 3 4 5 6 Forudsætninger: DM536 og DM537 Timer: 50% forelæsninger, 50% øvelser Forudsætninger: DM536 og DM537 Eksamenform: Skriftlig eksamen: Timer: 50% forelæsninger,

Læs mere

Oversigt over artefakter

Oversigt over artefakter Oversigt over artefakter Disciplin Artefakt Inception Elaboration Henvisning Afgrænsning og forståelse Design Implementering Vision s u Bilag 1 Feltnotater fra interviews s Use Cases s u Bilag 2 Use Case

Læs mere

Visuel prototyping og agil BPM. Copyright 2013 Visuel it ApS

Visuel prototyping og agil BPM. Copyright 2013 Visuel it ApS Visuel prototyping og agil BPM Copyright 2013 Visuel it ApS Visuel it s udviklingsmetode TM Det er vanskeligt at udvikle it-systemer Visionen er uklar og fordelene er ikke kvantificerbare Designfasen trækker

Læs mere

Anvendelse af BPT til manuel test

Anvendelse af BPT til manuel test DIAS 1 Konference HP Test brugergruppen Anvendelse af BPT til manuel test Agenda DIAS 2 _ Præsentation af mig selv _Manuel BPT _ Manuel BPT i KMD _Konklusion _ Diskussion og spørgsmål Præsentation DIAS

Læs mere

BAAN IVc. Brugervejledning til BAAN Data Navigator

BAAN IVc. Brugervejledning til BAAN Data Navigator BAAN IVc Brugervejledning til BAAN Data Navigator En udgivelse af: Baan Development B.V. P.O.Box 143 3770 AC Barneveld Holland Trykt i Holland Baan Development B.V. 1997. Alle rettigheder forbeholdes.

Læs mere

INTERAKTIONSDESIGN PROCESSEN (KAP 9), REPETITION, KÅRING AF ÅRETS BEDSTE MUSIKVIDEO OG PROJETK

INTERAKTIONSDESIGN PROCESSEN (KAP 9), REPETITION, KÅRING AF ÅRETS BEDSTE MUSIKVIDEO OG PROJETK INTERAKTIONSDESIGN PROCESSEN (KAP 9), REPETITION, KÅRING AF ÅRETS BEDSTE MUSIKVIDEO OG PROJETK Marianne Graves Petersen Associate Professor Computer Science Dept, University of Aarhus Center for Interactive

Læs mere

Case: Svømmeklubben Delfinen

Case: Svømmeklubben Delfinen 1. Semesterprojekt Datamatikeruddannelsen, 2. Obligatoriske opgave, efterår 2017 Case: Svømmeklubben Delfinen Svømmeklubben Delfinen er en mindre klub, der er i vækst. Klubbens ledelse ønsker derfor udviklet

Læs mere

Sammenligning af metoder

Sammenligning af metoder Sammenligning af metoder Hvorfor sammenligne? Den ideelle metode Generelle frameworks (NIMSAD/Andersen) Wood-Harper framework til sammenligning Problemer med sammenligning af metoder Hvorfor sammenligne?

Læs mere

Succesfuld implementering af automatiseret test

Succesfuld implementering af automatiseret test Succesfuld implementering af automatiseret test Forudsætningerne og faldgruberne John Fodeh john.fodeh@hp.com 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject

Læs mere

Læseplan for valgfaget teknologiforståelse. (forsøg)

Læseplan for valgfaget teknologiforståelse. (forsøg) Læseplan for valgfaget teknologiforståelse (forsøg) Indhold Indledning 3 Trinforløb for 7.- 9. klassetrin 4 Design 4 Programmering 5 Indledning Valgfaget teknologiforståelse er etårigt og kan vælges i

Læs mere

Et bud på regulatorisk strategi og niveau(er) for nye MedTech virksomheder

Et bud på regulatorisk strategi og niveau(er) for nye MedTech virksomheder Presentation title 1 Et bud på regulatorisk strategi og niveau(er) for nye MedTech virksomheder Peter Bøge Senior Controls manager, Novo Nordisk; Formand for Medicoindustriens ekspertgruppe for Safety

Læs mere

IT projekt. sæt et mål og nå det med omtanke!

IT projekt. sæt et mål og nå det med omtanke! IT projekt sæt et mål og nå det med omtanke! Det overordnede FORMÅL med dias-showet er at fortælle hvordan vi gennemfører IT projekter med succes ved hjælp af Microsoft Solutions Framework MSF modeller:

Læs mere

DM507 Algoritmer og datastrukturer

DM507 Algoritmer og datastrukturer DM507 Algoritmer og datastrukturer Forår 2016 Projekt, del III Institut for matematik og datalogi Syddansk Universitet 20. april, 2016 Dette projekt udleveres i tre dele. Hver del har sin deadline, således

Læs mere

Workshop Persistence

Workshop Persistence Workshop Persistence University College Nordjylland Datamatikeruddannelsen Klasse: dmaa0216 Titel: Workshop Persistence Versionskontrol-sti: https://github.com/mrurb/workshop-persistans/invitations versionsnummer:

Læs mere

Semesterbeskrivelse cand. it uddannelsen i it-ledelse 2. semester.

Semesterbeskrivelse cand. it uddannelsen i it-ledelse 2. semester. Semesterbeskrivelse cand. it uddannelsen i it-ledelse 2. semester. Semesterbeskrivelse Oplysninger om semesteret Skole: Statskundskab Studienævn: Studienævn for Digitalisering Studieordning: Studieordning

Læs mere

Vejledning til udviklingsprocessen for projekt 2

Vejledning til udviklingsprocessen for projekt 2 Vejledning til udviklingsprocessen for projekt 2 Versionshistorik Ver. Dato Initialer Beskrivelse 0.01 17.11.14 KBE Første version 0.02 24.11.14 TFJ Rettet efter 1. review 0.03 26.11.14 KBE Omskrevet analyse

Læs mere

DM507 Algoritmer og datastrukturer

DM507 Algoritmer og datastrukturer DM507 Algoritmer og datastrukturer Forår 2017 Projekt, del III Institut for matematik og datalogi Syddansk Universitet 6. april, 2017 Dette projekt udleveres i tre dele. Hver del har sin deadline, således

Læs mere

Objektorientering. Programkvalitet

Objektorientering. Programkvalitet 1 PROSA-Bladet nr. 4 1993 Objektorientering = Programkvalitet? Af Finn Nordbjerg, adjunkt ved Datamatikeruddannelsen, Aalborg Handelskole 1. Indledning Objektorientering er blevet et edb-fagets mest udbredte

Læs mere

Design by Contract. Design and Programming by Contract. Oversigt. Prædikater

Design by Contract. Design and Programming by Contract. Oversigt. Prædikater Design by Contract Design and Programming by Contract Anne Haxthausen ah@imm.dtu.dk Informatics and Mathematical Modelling Technical University of Denmark Design by Contract er en teknik til at specificere

Læs mere

Analyse, problemområde, anvendelsesområde

Analyse, problemområde, anvendelsesområde OOA&D, kap. 1-5 Fiktiv case Det supermarked I dagligt handler i, skal have et integreret kasse-, lagerstyrings- og EDI-system. Systemet skal gøre det muligt at sænke varebeholdningen uden at der kommer

Læs mere

Model og Metode til Programudvikling. Jens Dalsgaard Nielsen

Model og Metode til Programudvikling. Jens Dalsgaard Nielsen Model og Metode til Programudvikling v/ Jens Dalsgaard Nielsen 1 Hvem er vi? Jens Dalsgaard Nielsen, Afd for Proceskontrol, I8 Distribuerede RT-Systems group Realtid, kerner, operativsystemer, netværk,..

Læs mere

Design af genbrugeligt objektorienteret software

Design af genbrugeligt objektorienteret software Velkommen Design af genbrugeligt objektorienteret software Evaluering af software ved hjælp af statiske mål. 24 februar 2004 Specialeforsvar af: Søren Gaardbo Jensen Design af genbrugeligt objektorienteret

Læs mere

Lavet af Danni jensen og David Olsen

Lavet af Danni jensen og David Olsen Projekt Delfin Lavet af Danni jensen og David Olsen 19/5-2008 Indholdsfortegnelse. Side 1: Indholdsfortegnelse og forord. Side 2: Kravsliste. Side 3: Use Case Model. Side 4: Formandens aktørbeskrivelse

Læs mere

CCS klassifikation og identifikation

CCS klassifikation og identifikation UDVEKSLINGSSPECIFIKATION klassifikation og identifikation Udgivet 01.09.2017 Revision 0 Molio 2017 s 1 af 19 Forord Denne udvekslingsspecifikation beskriver, hvilke egenskaber for klassifikation og identifikation,

Læs mere

Abstrakte datatyper C#-version

Abstrakte datatyper C#-version Note til Programmeringsteknologi Akademiuddannelsen i Informationsteknologi Abstrakte datatyper C#-version Finn Nordbjerg 1/9 Abstrakte Datatyper Denne note introducerer kort begrebet abstrakt datatype

Læs mere

Vejledning - Udarbejdelse af gevinstdiagram

Vejledning - Udarbejdelse af gevinstdiagram Vejledning - Udarbejdelse af gevinstdiagram Januar 2014 INDHOLD 1. INDLEDNING... 1 1.1 FORMÅL... 1 1.2 VEJLEDNINGENS SAMMENHÆNG MED DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL... 1 1.3 GEVINSTDIAGRAMMET... 2 1.4

Læs mere

Introduktion til projekter

Introduktion til projekter Introduktion til projekter v. 1.0.3 Introduktion I dette materiale ser vi overordnet på, hvad projekter egentlig er, hvordan de er skruet sammen og hvilke begreber, som relaterer sig til projekter. Vi

Læs mere

Rejsekort A/S idekonkurence Glemt check ud

Rejsekort A/S idekonkurence Glemt check ud Rejsekort A/S idekonkurence Glemt check ud 9. marts 2015 1 Indhold 1 Introduktion 4 1.1 Problembeskrivelse........................ 4 1.2 Rapportens opbygning...................... 4 2 Ordliste 5 3 Løsning

Læs mere

FRA USECASE TIL TESTCASE HP TEST BRUGERKONFERENCE, 10. APRIL 2014

FRA USECASE TIL TESTCASE HP TEST BRUGERKONFERENCE, 10. APRIL 2014 FRA USECASE TIL TESTCASE HP TEST BRUGERKONFERENCE, 10. APRIL 2014 LIDT OM MIG SELV Erfaring NIELS-HENRIK HANSEN 35+ års samlet IT erfaring 15+ år som test manager Certificeret Inspection Leader ISEB Foundation

Læs mere

Bilag 2 og 3 og værktøjer

Bilag 2 og 3 og værktøjer Bilag 2 og 3 og værktøjer Lars Erik Storgaard Geodatastyrelsen, laers@gst.dk Program for workshop Geodatastyrelsen Formål hvorfor workshop? Kvalificering af listen over myndigheder Temakammerater Opmærksomhed

Læs mere

Curriculum Vitae. Uddannelse: 2001 Civilingeniør fra Danmaks tekniske universitet, fagprofil: styring og regulering.

Curriculum Vitae. Uddannelse: 2001 Civilingeniør fra Danmaks tekniske universitet, fagprofil: styring og regulering. Curriculum Vitae Navn Gitte Brunn Fugmann Adresse Mosegård Park 9 3500 Værløse. Telefonnr +45 3927 7371 E-mail gbr@fugmann.net Fødselsdato 24. april 1974 Fødselssted Rigshospitalet, København Ægteskabelige

Læs mere

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø Høringssvar vedr. FESD GIS-integrationsmodel version 2.0 Geodata Danmark har

Læs mere

CCS Formål Produktblad December 2015

CCS Formål Produktblad December 2015 CCS Formål Produktblad December 2015 Kolofon 2015-12-14

Læs mere

En hjælpers vigtige værktøj.

En hjælpers vigtige værktøj. En hjælpers vigtige værktøj. Denne præsentation trækker sit materiale fra forskning og viden fra bevægelsesområdet. Jeg er dog ikke i tvivl om, at disse overvejelser også kan bruges på andre områder af

Læs mere

Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer

Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer INDLÆG 13 : DYNAMICS AX Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer Tonny Bybæk, Lau Bøgelund Larsen Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer

Læs mere

Opgaven fortsat. Opfølgning på Opgave 2 og Use Cases. Opgaven. Trin 1: Væsentlige begreber. Resultatliste: 100 bryst, herrer

Opgaven fortsat. Opfølgning på Opgave 2 og Use Cases. Opgaven. Trin 1: Væsentlige begreber. Resultatliste: 100 bryst, herrer Opfølgning på Opgave 2 og Use Cases originally by Michael R. Hansen modified/extended by Anne E. Haxthausen Informatics and Mathematical Modelling Technical University of Denmark Opgaven fortsat Efter

Læs mere

Informationsforvaltning i det offentlige

Informationsforvaltning i det offentlige Informationsforvaltning i det offentlige 1 Baggrund Den omfattende digitalisering af den offentlige sektor i Danmark er årsag til, at det offentlige i dag skal håndtere større og større mængder digital

Læs mere

Generel projektbeskrivelse

Generel projektbeskrivelse 02121 Ingeniørarbejde Softwareteknologi Januar 2010 1 Introduktion Generel projektbeskrivelse Formålet med programmeringsprojektet er at give deltagerne erfaring med at designe og konstruere et simpelt

Læs mere

Object-Relational Mapping

Object-Relational Mapping Databaser for udviklere () Datamatiker TietgenSkolen Underviser: Allan Helboe 06-06-2010 Problemformulering Denne opgave er et forsøg på at beskrive problemerne der opstår ved anvendelsen af en relationel

Læs mere

Introduktion til DM507

Introduktion til DM507 Introduktion til DM507 Rolf Fagerberg Forår 2017 1 / 20 Hvem er vi? Underviser: Rolf Fagerberg, IMADA Forskningsområde: algoritmer og datastrukturer 2 / 20 Hvem er vi? Underviser: Rolf Fagerberg, IMADA

Læs mere

Katrines Kælder Kasseapparat

Katrines Kælder Kasseapparat Katrines Kælder Kasseapparat Projektdokumentation Aarhus Universitet Gruppe 4-4. Semester - E15 Vejleder: Lars Mortensen Dato 11-09-2015 David Heilesen Danielewicz - 201400148 - IKT Kalle Rønlev Møller

Læs mere

Undervisningsbeskrivelse

Undervisningsbeskrivelse Undervisningsbeskrivelse Programmering C ved mst Termin Juni 117 Institution Uddannelse Fag og niveau Lærer Hold Erhvervsskolerne Aars hhx Programmering C Michael Stenner (mst) 2-3g16 pro Forløbsoversigt

Læs mere

NemID DataHub adgang. morten@signaturgruppen.dk & jakob@signaturgruppen.dk. Doc. 25538-12, sag 10/3365

NemID DataHub adgang. morten@signaturgruppen.dk & jakob@signaturgruppen.dk. Doc. 25538-12, sag 10/3365 NemID DataHub adgang morten@signaturgruppen.dk & jakob@signaturgruppen.dk Agenda Funktionaliteten og brugeroplevelsen Arkitekturen og komponenterne bag NemID og digital signatur Datahub token Pause Udvikling

Læs mere

ADK 1.0 KRAVSPECIFIKATION

ADK 1.0 KRAVSPECIFIKATION ADK 1.0 KRAVSPECIFIKATION Dokumentets versioner (revisionshistorie) Version Dato Ansvarlig Beskrivelse 0.1 23-06-2014 MST Oprettelse af integrationskrav 0.2 25-06-2014 HAH Review for forståelighed og stringens.

Læs mere

Tietgenskolen - Nørrehus. Data warehouse. Database for udviklere. Thor Harloff Lynggaard DM08125

Tietgenskolen - Nørrehus. Data warehouse. Database for udviklere. Thor Harloff Lynggaard DM08125 Tietgenskolen - Nørrehus Data warehouse Database for udviklere Thor Harloff Lynggaard DM08125 Juni 2010 Indhold Beskrivelse... 3 Data warehouse... 3 Generelt... 3 Sammenligning... 3 Gode sider ved DW...

Læs mere

Projekt database. 3 Semester - Mul a Projekt 1. Yaser Osman cph-mo102@cphbusiness.dk. Dan Eskildsen cph-de32@cphbusiness.dk

Projekt database. 3 Semester - Mul a Projekt 1. Yaser Osman cph-mo102@cphbusiness.dk. Dan Eskildsen cph-de32@cphbusiness.dk Projekt database 3 Semester - Mul a Projekt 1 Yaser Osman cph-mo102@cphbusiness.dk Dan Eskildsen cph-de32@cphbusiness.dk Ammar Al-Basri cph-aa140@cphbusiness.dk Emre Kandemir cph-ek68@cphbusiness.dk Lotte

Læs mere

Hassansalem.dk/delpin User: admin Pass: admin INTERFACE DESIGN

Hassansalem.dk/delpin User: admin Pass: admin INTERFACE DESIGN Hassansalem.dk/delpin User: admin Pass: admin INTERFACE DESIGN 1/20 Indledning Dette projekt er den afsluttende del af webudvikling-studiet på Erhvervs Lillebælt 1. semester. Projektet er udarbejdet med

Læs mere

APEX i Praksis Martin B. Nielsen. Navn. MBNDATA Emne

APEX i Praksis Martin B. Nielsen. Navn. MBNDATA Emne APEX i Praksis Martin B. Nielsen Navn MBNDATA Emne Foredragsholderen Oracle/APEX Arkitekt/udvikler/DBA Siden Oracle v.5 (1988) APEX Siden 2007, men før (Database provider, HTMLDB) MBNDATA siden 1996 MBNDATA

Læs mere

LEVERANCE 1.3. Model for kvalitetssikring

LEVERANCE 1.3. Model for kvalitetssikring LEVERANCE 1.3 Model for kvalitetssikring Udarbejdelse af kvalitetssikringsmodel, krav til open source kode og dokumentation og godkendelsesprocedurer m.v. Samt fokus på understøttelse af CE-mærkning. 1

Læs mere

Standardisering af PLC Programmering. SESAM Præsentation 2. November 2016

Standardisering af PLC Programmering. SESAM Præsentation 2. November 2016 Standardisering af PLC Programmering SESAM Præsentation 2. November 2016 1 Agenda Introduktion TC Skjern Historien bag standardisering Hvad indeholder standarden? Struktureret Tekst programmering Uddannelse

Læs mere

3 Algebraisk Specifikation af Abstrakte Datatyper.

3 Algebraisk Specifikation af Abstrakte Datatyper. 3 Algebraisk Specifikation af Abstrakte Datatyper. Specifikation kontra program. Bestanddele af en algebraisk specifikation. Klassificering af funktioner i en ADT. Systematisk definition af ligninger.

Læs mere

Automatisk Vandingssystem. Rettelser. 1 af 14

Automatisk Vandingssystem. Rettelser. 1 af 14 Automatisk Vandingssystem Rettelser 1 af 14 Automatisk Vandingssystem Projektdokumentation Aarhus Universitet Gruppe 6-3. Semester - F15 vejleder: Michael Alrøe dato: 28-05-2015 Lærke Isabella Nørregård

Læs mere

Datalogi V-Systemdesign og HCI

Datalogi V-Systemdesign og HCI Datalogi V-Systemdesign og HCI 4. feb 2002 I kurset behandles emnerne interaktive systemer, systemudvikling og projektledelse. Fokus er indledende tilegnelse af metoder, teknikker og værktøjer, som effektivt

Læs mere

Videregående Programmering for Diplom-E Noter

Videregående Programmering for Diplom-E Noter Videregående Programmering for Diplom-E Noter 1. Uddelegering Ét af de væsentlige principper i objektorienteret programmering er, at enhver klasse selv skal kunne "klare ærterne". Enhver klasse skal altså

Læs mere

Vejledning til gevinstdiagram og gevinstprofiler

Vejledning til gevinstdiagram og gevinstprofiler Vejledning til gevinstdiagram og gevinstprofiler Januar 2014 Indhold 1. CENTRALE BEGREBER... 3 2. HVAD ER ET GEVINSTDIAGRAM OG GEVINSTPROFILER... 4 3. FORMÅL MED GEVINSTDIAGRAM OG GEVINSTPROFILER... 4

Læs mere

En hjælpers vigtige værktøj.

En hjælpers vigtige værktøj. En hjælpers vigtige værktøj. Denne præsentation trækker sit materiale fra forskning og viden fra bevægelsesområdet. Jeg er dog ikke i tvivl om, at disse overvejelser også kan bruges på andre områder af

Læs mere

3. SEMESTER 2. PROJECT MULB Gruppe 1. 20. september 2015

3. SEMESTER 2. PROJECT MULB Gruppe 1. 20. september 2015 PROJECT DATABASE 3. SEMESTER 2. PROJECT MULB Gruppe 1. 20. september 2015 Ved at underskrive dette dokument bekræfter vi, at det indsendte materiale alt sammen er vores eget materiale og arbejde. Andreas

Læs mere

POST IT! Cph Business Academy Multimediedesign 2. Semester flow april Kirstine Marie Rasmussen cph-

POST IT! Cph Business Academy Multimediedesign 2. Semester flow april Kirstine Marie Rasmussen cph- POST IT! Cph Business Academy Multimediedesign 2. Semester flow 3 9. april 2017 Kirstine Marie Rasmussen cph- kr141@cphbusiness.dk Mette Bejder cph- mb458@cphbusiness.dk Link til POST IT http://mbejder.dk/post-

Læs mere

Byg din informationsarkitektur ud fra en velafprøvet forståelsesramme The Open Group Architecture Framework (TOGAF)

Byg din informationsarkitektur ud fra en velafprøvet forståelsesramme The Open Group Architecture Framework (TOGAF) Byg din informationsarkitektur ud fra en velafprøvet forståelsesramme The Open Group Framework (TOGAF) Otto Madsen Director of Enterprise Agenda TOGAF og informationsarkitektur på 30 min 1. Introduktion

Læs mere

Grundlæggende OOA - OOD

Grundlæggende OOA - OOD Grundlæggende OOA - OOD Dette kursus henvender sig til personer, der har lille eller ingen erfaring med softwareudvikling. Med udgangspunkt i UML opbygges et solidt kendskab til softwareudviklingens kunst

Læs mere