Kursinformation
Metodik för
programvaruutveckling
Föreläsning 5
Martin Höst
• Inlämningar i v. 7
– enligt kursprogram: projektdefinition,
projektplan, disposition till kravspecifikation,
disposition till litteraturstudien, samt svar till
de reflekterande frågor som behandlar
projektdefinition och projektplan.
• Två övningar kvar innan sommaren
– V5: arbete med projekt och litteraturstudien
– V6: Kravhantering
Idag
• Designprocessen
• Arkitekturdesign
–
–
–
–
Systemmodeller
Kontrollmodeller
Design på modulnivå
Generiska modeller och referensmodeller
• Distribuerade arkitekturer
• Design med återanvändning
Designprocessen (från kap. 3)
•
•
•
•
•
•
Arkitekturdesign – fokus idag
Abstrakt specifikation
Design av gränssnitt
Komponentdesign
Design av datastrukturer
Design av algoritmer
– Metoder
– Design för återanvändning
Arkitekturdesign
• Systemstruktur
– Uppdelning i delsystem, specifikation av
kommunikation mellan delsystem
• Kontrollmodell
– Hur kontroll mellan delar av systemet
fördelas
• Uppdelning i moduler
– För varje delsystem
Moduler/delsystem
• Delssystem “fristående”, moduler
delar av delsystem
• Gränssnitt / Implementation
Varför göra arkitekturdesign?
• Åskådliggöra systemet för alla
intressenter – underlättar
kommunikation
• Möjliggöra systemanalys – t ex med
avseende på prestanda
• Identifiera möjlig återanvändning
Arkitekturdesign påverkas t ex
av krav på:
• Prestanda
– Få delsystem, lite kommunikation
• Säkerhet mot intrång
– Bygg i lager med kritisk information innerst
Vad är en bra arkitekturdesign?
Och hur uppnår man en sådan?
Uppdelning i delsystem
• Blockdiagram som visar interaktion
mellan delsystem
• Tre exempel på viktiga modeller:
– ”Repository”-modellen
– ”Client-server”-modellen
– Abstrakt maskin
• Säkerhet vid användande
– Samla kritiska delar i ett system
• Tillgänglighet
– Redundanta komponenter
• Underhållbarhet
– Delar som är enkla att förstå och ändra
Repository-modellen
gemensam information
”repository”
Delsystem
1
Delsystem
2
…
Delsystem
n
Repository-modellen
Fördelar:
• Effektivt med
mycket data
• De som producerar
data måste inte
veta så mycket om
mottagaren
• Backup, etc lätt
Svårigheter:
• Alla delsystem har
samma dataform
• Vidareutveckling
svårt eftersom
mycket bygger på
en viss datamodell
• Olika krav på detta
”Client-server”-modellen
”Client-server”-modellen
Presentation
Klient
1
Klient
2
…
Klient
n
Nätverk
Betj.
1
Betj.
2
…
Betj.
m
”Client-server”-modellen
• Fördelar:
– Distribuerad arkitektur
– Lätt att lägga till klienter och betjänare
• Svårigheter:
– Nya enheter måste kanske anpassas
– Ingen gemensam datamodell
Kontrollmodeller
• Centraliserad tilldelning
– Call-return
– Manager model
• Händelsebaserad tilldelning
– Broadcast models
– Avbrottsstyrda modeller
Tunn
klient
Klient
Stor
klient
Presentation
Applikation
Klient
Tre-lager
modell
Klient
Betjänare:
Applikation
Datahantering
Betjänare:
Datahantering
Presentation
Betjänare:
Applikation
Abstrakt maskin
…
...
Nivå 3
Nivå 2
Nivå 1
Design på modulnivå
• Objektorienterade modeller
• Dataflödesmodeller
Betjänare:
Datahantering
Dataflödesmodell, exempel
Ta emot
beställning
Sök i
lager
Uppdatera Leverera
lager
komponent
Fördelar/svårigheter
Objektorienterad
modell
Dataflödesmodell
Fördelar
Svårigheter
Välkända
Naturliga objekt
Intuitivt
Återanvändning
Bra språk
Intuitivt
Återanvändning
Vidareutveckling
enkelt
Explicita referenser
Behov av lika
dataformat
[Sommerville, pp. 229-232]
•
•
•
•
•
•
Generiska modeller
Referensarkitektur
Exempel Kompilator
Exempel OSI
Lexikalisk analys
Bygg symboltabell
Syntaxanalys
Bygg syntaxträd
Semantisk analys
Kodgenerering
Uppgifter
• 10.1
• 10.9
7
6
5
4
3
2
1
7
6
5
4
3
2
1
7
6
5
4
3
2
1
7
6
5
4
3
2
1
Distribuerade system
Viktiga egenskaper
• Dela resurser
• Öppna
• Parallella processer
• Skalbara
• Feltoleranta
• Transparenta
Svårigheter
• Komplexa
• Säkerhet svårt
• Svårt underhålla
• Oförutsägbara
Återanvändning av
programvara
CORBA (Common Object Request
Broker Architecture)
Application objects
Domain facilities
Horizontal CORBA
facilities
• Återanvändning på applikationsnivå
– Förhållandevis vanligt
• Återanvändning av komponenter
– Svårare
Object Request Broker
• Återanvändning av funktioner
– Förhållandevis vanligt
CORBA services
Varför återanvändning?
•
•
•
•
Lägre kostnad
Bättre tillförlitlighet
Lägre osäkerhet -> lägre risk
Effektivare användning av
specialister
• Mer standardisering (t ex menyer
som liknar varandra)
• Snabbare utveckling
Svårigheter
• Högre underhållskostnader
• Verktygsstöd inte anpassat efter
återanvändning
• ”Not-invented-here”-syndromet
• Vem ska se till att det finns
återanvändbara komponenter? Underhåll
av bibliotek dyrt
• Svårt att hitta, förstå och anpassa
komponenter
Utveckling med
återanvändning
• Utkast till krav
• Leta efter återanvändningsbara
komponenter
• Anpassa krav
• Arkitekturdesign
• Leta efter återanvändningsbara
komponenter
• Design av systemet
Komponentbaserad utveckling (CBSE)
Komponent
• Fristående exekverbar
enhet
• Definierat gränssnitt (men
kräver
erbjuder
inte nödvändigtvis källkod)
• Olika abstraktionsnivå
–
–
–
–
–
funktioner
grupper av funktioner
dataabstraktion
ramverk
system
Utveckling för återanvändning
• Komponenter baserade på stabila begrepp
inom domänen
• Inte visa hur tillstånd representeras
• Komponenter ska vara olika och
användbara var för sig
• Ta hand om undantag
• Avvägning mellan användbarhet och
återanvändbarhet!
Applikationsfamiljer
• Specialiseringar för olika
operativsystem
• Specialiseringar för olika
hårdvaruplattformar
• Specialiseringar för olika
funktionskrav (byggda på samma
programvaruplattform)
Svårigheter med komponentbaserad utveckling
• Inte kontroll över funktionalitet
• Problem att få olika COTS att fungera
tillsammans
• Ingen kontroll över
vidareutvecklingen av COTS
• Inte alltid bra support från COTStillverkare
Platforms in Product Development
Not a software specific concept!
Black & Decker
“Battery Pack,
Motor Pack …”
Car industri
“Peugeot, Fiat,
Toyota, etc …”
Plattformsbaserad utveckling
Produkt
1
Produkt
2
Plattform
…
Produkt
n
Questions proposed to be asked about work
with software platforms
Questions proposed to be asked about work
with software platforms
• Q1: How is the
responsibility and
empowerment for
the group
responsible for the
platform defined?
• Q2: Describe the
stakeholder
interaction
• Q5: Describe how the
architecture is
validated.
• Q3: Which
procedures are
used to identify
architectural
requirements?
• Q4: What design
process is used?
[M. Höst, E. Johansson, A. Norén, L. Bratthall, “Benchmarking of Processes
for Managing Product Platforms - a Case Study”, IEE Proceedings – Software,
Vol. 159, Issue 5, pp. 137-142, 2002.]
Frågor
• 14.1
• 14.3
• 14.9
• Q6: Describe how the
architecture is
distributed.
• Q7: Describe how it is
ensured that software
architecture has its
self-evident place in
the software
development process.
• Q8: How is the
product-line
architecture
controlled?