Forelesning IMT Mars 2011

Transkript

1 Forelesning IMT Mars 2011 Tema : Design av programvare Hva er målet i designfasen? Generelle steg ved design av programvare Softwarearkitektur Struktur og organisering Kontrollmekanismer Dekomponering Arkitektur i OL Veiviseren og Athletic Manager Hva bør diskuteres i innledende arkitekturvurderinger her? Pensum : Sommerville (Kap.6 unntatt 6.4)

2 Målet : Designfasen i SU-prosjekter : Å få bestemt seg for hvordan den nye programvare-løsningen skal utformes. Man etterstreber å tilfredsstille kravene som er spesifisert samtidig med at man holder seg innen rammebetingelsene som er gitt for utviklingsprosjektet Utforme et design som legger til rette for å komme frem til en løsning med RIKTIG kvalitet på en rasjonell og effektiv måte Få beskrevet løsningen i tilstrekkelig detalj til i neste omgang å realisere den.

3 Generelle steg i Designprosessen 1. Problemforståelse : Sette seg inn i kravspesifikasjonen og de omkringliggende rammer 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å (programvarearkitektur) 4. Detaljspesifisere den enkelte del av løsningen etter behov ( modulinndeling, databasedesign, GUI-design etc)

4 The software design process tidl. versjon av Sommerville

5 Programvarearkitektur Hensikten med å arbeide med programvarearkitektur er å få bestemt hvordan den nye programvaren skal organiseres / struktureres for best mulig å tilfredsstille kravene. Sommervilles omtale av arkitekturdesign : 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

6 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 among the system elements, and the physical deployment of the system.

7 Ulike arkitekturmodeller Det er viktig å betrakte programvaren man skal utvikle fra ulike perspektiver og diskutere alternative utforminger. Sommerville: 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

8 Programvarestruktur Tre grunnleggende modeller omtalt i Sommerville : Repository modell - en sentralisert database holder på informasjonen hvor sub-systemene aksesserer denne Klient-Tjener modell - definerer hvordan man skal distribuere data og prosessering i systemet Lagdelingsmodellen - hvor fokus er på å strukterere programvaren i ulike lag som tilbyr omgivelesene definerte tjenester og der grensesnittene mellom lagene er veldefinerte

9 Struktur 1 : Repository model (fig. 6.9 i Sommerville) Design editor Code generator Design translator Project repository Program editor Design analyser Report generator

10 Struktur 2 : Client - Server model (fig i Sommerville) Client 1 Client 2 Client 3 Client 4 Wide-bandwidth network Catalogue server Video server Picture server Hypertext server Catalogue Film clip files Digitiz ed photographs Hypertext web

11 Struktur 3 : Layer model Presentasjon Applikasjon Domene Datalagring

12 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

13 3 lags klient - tjener arkitektur Client HTTP interaction Client Web server Account service provision SQL query Datab ase server SQL Customer account database Client Client

14 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. Sentralisert kontroll call-return model manager model Hendelsesbasert kontroll broadcast model interrupt-driven models

15 Kontroll 1 a : Sentralisert : call-return Main program (tidl. Sommerville) Routine 1 Routine 2 Routine 3 Routine 1.1 Routine 1.2 Routine 3.1 Routine 3.2

16 Kontroll 1 b : Sentralisert : manager (tidl. Sommerville) Sensor processes Actuator processes System contr oller Computation processes User interface Fault handler

17 Kontroll 2 a : Hendelses basert : Broadcast (tidl. Sommerville) Sub-system 1 Sub-system 2 Sub-system 3 Sub-system 4 Event and messa ge handler

18 Kontroll 2 b : Hendelses basert : Interrupt-driven (tidl. Sommerville) Interrupts Interrupt vector Handler 1 Handler 2 Handler 3 Handler 4 Process 1 Process 2 Process 3 Process 4

19 Modul dekomponering Etter å ha bestemt seg for hvilke prinsipper man skal basere inndelingen av programvaren på, deles også det enkelte sub-system opp i mindre komponenter / moduler. Ved å dekomponere oppnår man å reduserer kompleksiteten bevare oversikten over totalitet og detaljer gir mulighet for parallelt utviklingsarbeid bedre endrings- og gjenbruksmulighetene Dekomponering er et generelt prinsipp som benyttes innen alle former for Programvaredesign.

20 Modulstyrke (Cohesion) Modulstyrke er et mål på de interne forholdene i en systemmodul. Det er et ideal å komme frem til sterke moduler innen design 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

21 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

22 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

23 Neste gang : Design i RUP Vi ser nøyere på dette neste forelesning. RUP : Software Architect er en av de mest sentrale rollene i RUP Fokus på å komme frem til en robust og fleksibel programvarearkitektur ved utgangen av Elaboration-fasen. (Life Cycle Architecture). Dokumenteres i artefaktet SAD (Software Architecture Document) View - fokus på å se løsningen fra ulike perspektiv