View
64
Download
2
Category
Tags:
Preview:
DESCRIPTION
Session 11: Introduktion til Systemudvikling. Krav Design Realisering Test. Hvad er systemudvikling?. Få en ide / Identificer behov find krav design løsning realiser ide vedligehold løsningen. Proces-tilgange. - PowerPoint PPT Presentation
Citation preview
Hvad er systemudvikling?
UCN AK IT: Softwarekonstruktion 2
Få en ide /
Identificer behov
find krav design løsning realiser ide
vedligehold løsningen
2013-02-05
Proces-tilgange
UCN AK IT: Softwarekonstruktion 3
• Vandfaldsmodel: Et sekventielt gennemløb gennem hovedaktiviteterne.
• Iterativ model: Planlægning af aktiviteter sker successivt og tilpasset omstændighederne
2013-02-05
IT-udviklingsprocesser
2013-02-05 5
• Klassisk opfattelse:– Processen er plandreven:
• Er dokumenterbar• Kan gentages• Er forudsigelig
– Hviler på den antagelse• at problemet er velforstået inden start• at en præcis kravspecifikation foreligger/kan
udarbejdes
UCN AK IT: Softwarekonstruktion
IT-udviklingsprocesser
UCN AK IT: Softwarekonstruktion 6
• Brugerne ved ikke hvad de vil have, før de reelt har fået IT systemet.
• Analysis paralysis.• Nye muligheder dukker op. • Krav ændres. Brugernes/kundens
prioriteter ændres.
2013-02-05
IT-udviklingsprocesser
2013-02-05 7
• Moderne udviklingsprocesser er agile:– Situationsbestemte– Iterative og inkrementelle– Eksperimenterende
• Udviklerne lærer, mens de udvikler• Ofte opdages nye behov og muligheder
undervejs
UCN AK IT: Softwarekonstruktion
IT-udviklingsprocesser
2013-02-05 8
• Klassisk • Agil
Specifikation
Løsning
Specifikation
Løsning
…og specifikationen ændrer sig undervejs…
UCN AK IT: Softwarekonstruktion
Udviklingsmodel, metode og notation
UCN AK IT: Softwarekonstruktion 10
• En udviklingsmodel er en samling af aktiviteter, der fører frem til det færdige IT system
• En metode er konkrete retningslinjer for, hvordan de enkelte aktiviteter skal udføres– UP er både en udviklingsmodel og en metode
• En notation er et sprog til beskrivelse og visualisering– Unified Modelling Language (UML) er en fælles standard
for visualisering af modeller og understøttes af forskellige case-værktøjer
– UP og mange andre metoder benytter UML.
2013-02-05
Discipliner, aktiviteter og produkter
UCN AK IT: Softwarekonstruktion 11
Krav : Domænemodel: hvilke informationer skal håndteres i systemet (klasser) Use cases: hvilke funktioner skal der være i systemet Ikke-funktionelle krav: brugervenlighed, svartider, sikkerhed, vedligeholdelsesvenlighed…
Design løsning: arkitektur database klassedesign (metoder og objektinteraktion) hvordan skal skærmbilleder se ud (GUI)
Realiser Programmer og test Database
2013-02-05
Domænemodel• Find entiteter/objekter, som systemet skal håndtere.• Objekterne skal komme fra domænet – være fra brugerens verden.• Beskriv deres sammenhæng (associeringer, aggregeringer,
specialiseringer)
• Se tidligere lektioner.
2013-02-05 UCN AK IT: Softwarekonstruktion 12
Indhold af kravsspecifikation
2013-02-05 UCN AK IT: Softwarekonstruktion 13
En kravspecifikation skal indeholde flg.:1. Funktionelle krav til IT systemet (use cases)2. Information som IT systemet skal registrere
(domænemodel)3. Ikke-funktionelle krav
I det følgende drejer det sig om 1. og 2. – use cases og domænemodel
Hvad er en use case?
2013-02-05 UCN AK IT: Softwarekonstruktion 14
• Use cases er beskrivelser af systemets funktionalitet set fra en brugers (kaldet aktør) perspektiv.
• Gennem use casen fortælles historien om hvordan en aktør bruger et system og herigennem illustreres de funktionelle krav.
• En use case kan defineres som en samling af relaterede succes og fejlscenarier, som beskriver hvordan en aktør bruger systemet til at opnå et bestemt mål.
Gode og dårlige use cases
2013-02-05 UCN AK IT: Softwarekonstruktion 15
Gode eller dårlige?– Administration af
bøger– Registrer bogens
titel– Udlån af bog– Ret reservation– Slet reservation
• Kriterier:– Afsluttede; målet er nået; kaffepause– Små beslægtede opgaver bundtes i én beskrivelse
(CRUD)
Kontrol: Er alle opgaver med?– Er alle aktørernes
opgaver dækket?– Er kritiske opgaver
med?– Kan alt data
registreres, ændres, slettes (CRUD)?
Eksempel: Hændelsestabel fra et ordresystem
Hændelse Aktivitet Step i brugen af IT systemet Aktør
Kunde afgiver ordre
Registrer ordre
Registrere varerRegistrere kundenGemme ordrenUdskrive ordreseddel og faktura
Ekspedient
Faktura sendt til kunden
Overvåg ordre
Sammenligne betalingsfrist med dags datoGenfremsende hvis overskredet (hændelse ”Tid til betaling”)…..
System
……
…….
……
16
= Use case Step i use case
”Rolle” der bruger systemet
2013-02-05 UCN AK IT: Softwarekonstruktion
Use case diagram – første version for ordrestyring
• Er en grafisk model over systemets funktionalitet og kommunikationen med dets aktører
• Omfatter:– Use cases– Aktører– Associeringer mellem use
cases og aktører– Systemafgrænsning (ikke
vist)
2013-02-05 UCN AK IT: Softwarekonstruktion 17
Udvidelse af use case diagrammet for ordrestyring
• Afvigelser fra et normalt flow i forretningsscenariet, fx– Annuller ordre– Registrer returvare osv…
• Vedligeholdelse af varebeholdning– Registrer vare– Find vare– Ændre vareoplysninger– Slet vare
• Vedligeholdese af kundekartotek– Registrer kunde osv
2013-02-05 UCN AK IT: Softwarekonstruktion 18
Samles i use casen: Håndter vare - CRUD
Samles i use casen: Håndter kunde - CRUD
Opsummering: Find aktører
2013-02-05 UCN AK IT: Softwarekonstruktion 20
• Tag udgangspunkt i hvem/hvad der bruger systemet og hvilken rolle de spiller? – Generaliser.
• Ud over de aktører der deltager i forretningsprocessen kan der være andre, fx systemadministrator, leder.
• Brug en tidsaktør til tidsafhængige funktioner.• Aktørerne navngives, og beskrives ud fra et
forretningsperspektiv.• Eksempel:
– Navn: Ekspedient– Opgave: Er ansvarlig for at modtage og registrere
ordrer fra kunder, samt vedligeholdelse af kundekartotek
Opsummering: Find use cases
2013-02-05 UCN AK IT: Softwarekonstruktion 21
• Forretningskritiske use cases findes ved at kortlægge hændelser i forretningsområdet, der initierer aktiviteter, som skal understøttes af IT.
• Herudover kan man kigges på de primære aktører og deres formål med at bruge systemet.
• Ud over de forretningskritiske use cases vil der typisk være use cases for afvigelser i forretningsprocessen samt til vedligeholdelse.
• Fokus i afgrænsningen af use-cases skal være, at use casen skal give aktøren en observerbar nytteværdi (kaffe pause testen: fortjener aktøren at holde kaffepause efter use casen er afsluttet?).
• En hyppig fejl er at use cases fastlægges på et for lavt niveau, fx er Udskriv bekræftelse som regel en del af noget andet.
Beskrivelsesformater for use cases
2013-02-05 UCN AK IT: Softwarekonstruktion 22
• Overordnede tekstuelle beskrivelser i en kort summeret form (kunderettet)– brief: tekstuel beskrivelse af happy days scenariet
– casual: variationer af happy days scenarier
• Detaljerede beskrivelser i en “expanded” form - fully dressed– Trinene i use casen og variationer heraf beskrives i detaljer
• En grafisk visning af interaktionen i use casen i et systemsekvensdiagram – SSD (udviklerrettet)
• Alle use cases beskrives brief og/eller causal. Kun de kritiske beskrives fully dressed med tilhørende SSD og kontrakter
Use case beskrivelse:Kort- eller oversigtsform (brief)
• ”Steps” fra hændelsestabellen samt mock up’s af skærmbilleder giver input til use case beskrivelserne.
• Template for brief beskrivelse : – Use case: Navn på use casen– Beskrivelse: En overordnet men komplet beskrivelse
af hvem der initierer use casen, de forventede systemhandlinger og responsen herpå, der tilføjer værdi for aktøren.
2013-02-05 UCN AK IT: Softwarekonstruktion 23
Eksempel: Brief use case beskrivelse
Hændelsestabel giver input til beskrivelse af use case:
2013-02-05 UCN AK IT: Softwarekonstruktion 24
Hændelse Aktivitet Step i brugen af IT systemet Aktør
Kunde afgiver ordre
Registrer ordre
Registrere varerRegistrere kundenGemme ordrenUdskrive ordreseddel og faktura
Ekspedient
Brief beskrivelse, Use case: Registrer Ordre• En kunde henvender sig for at afgive en ordre. Ekspedienten bruger
systemet til at oprette en ny ordre, tilføje varer til ordren, registrere kundeoplysninger, gemme ordren og udskrive ordreseddel og faktura. Undervejs viser systemet detaljer om varerne, deltotal og total.
Prioritering af use cases
2013-02-05 UCN AK IT: Softwarekonstruktion 25
• Systemet designes, implementeres og testes igennem et antal iterationer jf. UP modellen.
• De højest prioriterede use-case analyseres, designes og kodes i de første iterationer (så må man formode at resten også kan laves).
• Trin i udvikling af use-cases:1. Use-cases identificeres og de vises i et UML use-case diagram.2. Dernæst beskrives de på brief eller casual form.3. På dette grundlag prioriteres use-cases (ud fra arkitekturmæssig
vigtighed, risici og forretningsværdi), og derefter analyseres de vigtigste med henblik på design ved prototyper og ”fully dressed” beskrivelser.
Use case beskrivelse: ”Fully dressed”
2013-02-05 UCN AK IT: Softwarekonstruktion 26
• Detaljering af use cases i step (flow of events): – Aktørhandling < - > Systemsvar.
• Tilføjelse af aktører samt pre- og post betingelser. • Brief-beskrivelser bruges som udgangspunkt for ”fully
dressed” beskrivelser.
Use case: Registrer Ordre
Flow of events i fully dressed beskrivelse :1. Use casen starter med at en kunde henvender
sig telefonisk for bestille varer.
2. Ekspedienten påbegynder en ny ordre.
3. Systemet opretter en ny ordre.
4. Ekspedienten angiver id på de ønskede varer.
5. Systemet returnerer varebeskrivelse, pris, deltotal , samt løbende total.
6. Ekspedienten tilføjer det ønskede antal varer.
7. Systemet tilføjer varen.
8. Trin 4-7 gentages indtil alle varer er tilføjet.
9. Ekspedienten angiver leveringsoplysninger.
10. Systemet validerer oplysningerne og registrer kunden.
11. Ekspedienten afslutter orden.
12. Systemet gemmer ordren.
13. Ekspedienten beder om en ordreseddel og faktura.
14. Systemet udskriver en bekræftelse.2013-02-05 UCN AK IT: Softwarekonstruktion 27
2. Respons på vare nr 1231
Mock UP’s fra test:
1. Start på registrering af varer
Domænemodel vs. use cases
• I systemudviklingskredse diskuteres:– ”Model før krav”
(skandinavisk skole).
– ”Use cases før model”(amerikansk skole).
• De udvikles ”hånd-i-hånd”. (og skal noget komme først, så hælder denne forelæser til ”model-før-krav”).
2013-02-05 UCN AK IT: Softwarekonstruktion 29
?
Design
UCN AK IT: Softwarekonstruktion 30
Design løsning: arkitekturdatabaseklassedesign (metoder og objektinteraktion)hvordan skal skærmbilleder se ud (GUI)
2013-02-05
2013-02-05 UCN AK IT: Softwarekonstruktion 31
N-tier (multi-tier) Architecture
WebServer
Browser
Client
Internet
Dedicated Client
• Database access layer: All code to access database is here. Makes it possible to change data store.
• Web server accesses application layer – not the database directly.
• Easier maintenance:• No business logic in the web
server (or other clients).• Application server: All (almost)
business logic is re-used.• New client may be added without
code duplication.
DB
DatabaseServer
Application Server
Database Access Layer
Backend
New Dedicated Client
Mobile
Client
Client accessing web services
Databasedesign
• Tabeller designes ud fra domænemodellen
– En tabel pr. objekt– Customer– (Bank)Account
Meget mere i næste fag:-)
2013-02-05 UCN AK IT: Softwarekonstruktion 32
1- n associeringen fra Customer tilBankAccount implementeres i databasen ved at inkludere custNo som fremmednøgle i Account.
Klassedesign• Designklassediagram:
– Metoder på klasser og objektinteraktion fastlægges.– Controllere tilføjes.– Data access klasser.
2013-02-05 UCN AK IT: Softwarekonstruktion 33
2013-02-05 34
Om test
• Test udføres altid i henhold til specifikationer.• En test kan aldrig påvise korrekthed - kun
tilstedeværelse af fejl!• En succesfuld test finder fejl!!!• Udvikleren skal ikke teste sig selv.• Et system er færdigtestet, når hyppigheden af fejl er
reduceret til et forretningsmæssigt acceptabelt niveau!!
UCN AK IT: Softwarekonstruktion
2013-02-05 35
Testmodel
En samling af– Test-cases– Test-procedurer– Eksekverbare komponenter, som tester
Omfatter typer af test:– Modultest eller unit-test (klasseniveau)– Integrationstest– Systemtest– Accepttest
UCN AK IT: Softwarekonstruktion
Test model
Krav
Arkitektur
Accepttest
Integrationstest
Design
Design metoder Test af metoder
Test af klasser
2013-02-05 UCN AK IT: Softwarekonstruktion 36Kodning
2013-02-05 37
Modultest (unit-test)
• Alle en klasses metoder skal testes• Black-box test ud fra specifikation
(pre- og post-betingelser)• White-box test udfra kendskab til
intern struktur:– test grænsetilfælde og normaltilfælde
UCN AK IT: Softwarekonstruktion
2013-02-05 38
Integrations- og systemtest
• Integrationstest skal finde fejl i måden moduler spiller sammen på og udføres efter hvert build. (Design by Contract er vigtigt.)
• Systemtest skal finde fejl i systemet som helhed og udføres i slutningen af hvert gennemløb af implementationsprocessen
UCN AK IT: Softwarekonstruktion
2013-02-05 39
Test-cases
• Test-cases findes udfra use-case modellen• Hver test-case tester et scenarium for en use-
case• En test-case skal specificere input, forventet
output og evt. betingelser for testen• Husk også belastningstest!!!
UCN AK IT: Softwarekonstruktion
2013-02-05 40
Test-procedurer og komponenter
• Test-procedurer specificerer, hvordan en test gennemføres– kan være manuelle– eller - bedre - automatiske
• Test-komponenter - eller drivere– automatisering af testprocedurer
• Tilstræb design af test-procedurer og -komponenter, så der er så meget genbrug som muligt
UCN AK IT: Softwarekonstruktion
Recommended