Tom Røise IMT 2243 : Systemutvikling 1. Forelesning IMT Mars Designfasen i SU-prosjekter : Generelle steg i Designprosessen

Transkript

1 Forelesning IMT Mars 2007 Tema : Design av programvare Hva ønsker vi å oppnå i designfasen? Generelle steg ved design av programvare Softwarearkitektur Struktur og organisering Dekomponering Kontrollmekanismer Innledende diskusjon rundt arkitekturvurderinger i eksemplene IHID, OL Veiviser, m.m. Pensum litteratur : Sommerville (Kap.11) Designfasen i SU-prosjekter : Målet : Finne en programvare-løsning som tilfredsstiller kravene som er spesifisert Lage et design som legger til rette for å komme frem til en løsning med RIKTIG kvalitet på en rasjonell og effektiv måte Få definert løsningen i tilstrekkelig detalj til i neste omgang å realisere den Avklare organiseringen og inndelingen av programvareløsningen Generelle steg i Designprosessen 1. Problemforståelse : Sette seg inn i kravspesifikasjonen 2. Identifisere en eller flere mulige løsninger : Vurdere ulike alternativer og velge den beste 3. Beskrive løsningen på et overordnet og abstrakt nivå (softwarearkitektur) 4. Detaljspesifisere den enkelte del av løsningen etter behov ( modulinndeling, databasedesign, GUI-design etc) IMT 2243 : Systemutvikling 1

2 The software design process Fig. 4.7 side 77 i Sommerville Software Arkitektur Hensikten med å arbeide med software arkitektur er å få bestemt hvordan den nye programvaren skal organiseres / struktureres for best mulig å tilfredsstille kravene. Sommervilles omtale av arkitektur design : Architectural design is a creative process where you try to establish a system organisation that will satisfy the functional and non-fuctional system requirements. Design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural design The output of this design process is a description of the software architecture Definisjoner på softwarearkitektur Bass m.fl. : The software architecture of a program or computer system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationship among them. T. Quatrani (Rational): It is a range of artifacts that are used to specify the strategic decisions about the structure and behavior of the system, the collaborations anmong the system elements, and the physical deployment of the system. IMT 2243 : Systemutvikling 2

3 Softwarearkitektur Å etablere en softwarearkitektur er første aktivitet i designfasen. Her tas beslutninger om hvilke prinsipper man skal følge for inndelingen av løsningen. Arkitekturvalgene danner rammeverket for det detaljerte designet som følger. Arbeidet går ut på koble : kunnskaper om teknologiske alternativer og muligheter forståelse for og innblikk i det problemet man skal løse som gjør en i stand til å identifisere og organisere helheten i en struktur som vil fungere godt på aktuell teknologi Softwarearkitektur Arkitektur modeller : Man bør utvikle systemmodeller / beskrivelser som ser programvaren fra ulike perspektiver. Eksempler (Sommerville s. 246) : Static structural model vise sub-systemer som separate enheter Dynamic process model viser et run-time bilde systemet med fokus på kontrollmekanismer Interface model vise hvilke tjenester hvert sub-system tilbyr, og med hvilket grensesnitt Relationship models fokuserer på koblingene mellom de ulike delsystemene Distribution model vise løsningens maskinvare topologi Systemstruktur Tre grunnleggende modeller omtalt i Sommerville : Repository modell - en sentralisert database holder på informasjonen, og sub-systemene aksesserer denne Klient-Tjener modell - definerer hvordan man skal distribuere data og prosessering i systemet Abstrakt maskin modell (Lagdelingsmodell) - vise grensesnittene mellom sub-systemene IMT 2243 : Systemutvikling 3

4 Struktur 1 : Repository model (fig i Sommerville) Design editor Code generator Design translator Project repository Program editor Design analyser Report generator Struktur 2 : Client - Server model (fig i Sommerville) Client 1 Client 2 Client 3 Client 4 Wide-bandwidth network Catalogue server Catalogue Video server Film clip files Picture server Digitized photographs Hypertext server Hypertext web Struktur 3 : Layer model Presentasjon Applikasjon Domene Datalagring IMT 2243 : Systemutvikling 4

5 Gartner Group sine nivåer i K/T modellen Viser 5 ulike nivåer å basere sin Klient / Tjener inndeling på : 1. Distribuert presentasjon : Klienten besørger deler av brukergrensesnittet, resten ligger sentralt 2. Remote presentasjon : Klienten besørger brukergrensesnitt og kall til sentralt system genereres. Resten ligger sentralt 3. Distribuert funksjon : Deler av applikasjonen ligger ute på klienten, resten ligger sentralt 4. Remote data : Kun dataene ligger på tjeneren. All prosessering skjer lokalt 5. Distribuerte data : Dataene ligger delvis på tjeneren og delvis på klienten 3 lags klient - tjener arkitektur (Sommerville fig. 12.8) Client HTTP interaction Client Web server Account service provision SQL query Database server Customer SQL account database Client Client Modul dekomponering Man deler her det enkelte sub-system opp i mindre komponenter / moduler. Tar utgangspunkt i modellene fra analysen DFD ved Funksjonsorientert Dekomponering Klassediagram og Sekvensdiagrammer ved Objektorientert Dekomponering Ved å dekomponere oppnår man å reduserer kompleksiteten bevare oversikten over totalitet og detaljer gir mulighet for parallelt utviklingsarbeid bedre endrings- og gjenbruksmulighetene IMT 2243 : Systemutvikling 5

6 Modulstyrke (Cohesion) Modulstyrke er et mål på de interne forholdene i en systemmodul. Det er et ideal innen design å komme frem til sterke moduler En modul som er sammensatt av enkle, tett sammenknyttede og veldefinerte oppgaver/funksjoner er sterk. Fordeler og ulemper med å tilstrebe høy modulstyrke : Høy stryke gir god vedlikeholdbarhet Overdreven dekomponering for å oppnå sterke moduler vil gi et kaos av mange små moduler Modulkobling (Coupling) Modulkobling er et mål på sammenkoblingene mellom modulene vi har satt opp i designet. Det er et ideal å komme frem til moduler med Lav kobling Sterk modulkobling vanskeliggjør vedlikehold. Ved lav kobling er endringer og feilsøking enklere, da datautvekslingen er minimal Ved å holde datastrukturene internt i den enkelte modul oppnår man en lavere koblingsgrad (innkapsling innen OO). Globale data er et skrekk-eksempel på Høy kobling - men mange benytter seg av det likevel Objektorientert arkitekturmodell (fig Sommerville) IMT 2243 : Systemutvikling 6

7 Funksjonsorientert arkitekturmodell (fig Sommerville) Kontroll modeller Etter å ha definert de overordnede trekk i systemstrukturen, bør det foretas bevisste valg for kontrollmekanismene for at riktig tjeneste leveres til riktig tid i systemet. Sommerville omtaler to ulike modeller for dette er : Sentralisert kontroll call-return model manager model Hendelsesbasert kontroll broadcast model interrupt-driven models Kontroll 1 a : Sentralisert : call-return Main program (fig i Sommerville) Routine 1 Routine 2 Routine 3 Routine 1.1 Routine 1.2 Routine 3.1 Routine 3.2 IMT 2243 : Systemutvikling 7

8 Kontroll 1 b : Sentralisert : manager (fig i Sommerville) Sensor processes Actuator processes System controller Computation processes User interface Fault handler Kontroll 2 a : Hendelses basert : Broadcast (fig i Sommerville) Sub-system 1 Sub-system 2 Sub-system 3 Sub-system 4 Event and message handler Kontroll 2 b : Hendelses basert : Interrupt-driven (fig i Sommerville) Interrupts Interrupt vector Handler 1 Handler 2 Handler 3 Handler 4 Process 1 Process 2 Process 3 Process 4 IMT 2243 : Systemutvikling 8

9 Designdokumentasjon Resultatet av Designarbeidet nedfelles i et Designdokument. Designfasen involverer mange, går ofte over lang tid og det blir mange endringer underveis. Det er kritisk å ha en komplett og konsistent dokumentasjon. Definer derfor: Struktur for designdokumentasjon Regler for å få enhetlighet i dokumentasjonen Ajourføringsregler IMT 2243 : Systemutvikling 9