Forelesning IMT Mars 2011

Transkript

1 Forelesning IMT Mars 2011 Tema: forts. arkitektur og OOD (ObjektOrientert Design) Eksempler på arkitekturvurderinger Yummy Inc., BUSTA, Tidligere studentprosjekter Prosjekt del 3 Designfasen Forventninger til denne leveransen Objektorientert Design Pensumlitteratur : Sommerville Kap.7 (side ). Figurene i denne presentasjonen er hentet derfra.

2 Oppsummering av arkitektur i RUP Software Architect - en obligatorisk rolle i RUP prosjekter Life Cycle Architecture milepælen som avlutter Elaboration-fasen sier sitt om arkitekturfokusen i RUP Software Architecture Document (SAD). Info dere finner om dette i RUP-infobasen er pensum. RUP har en meget sterk fokus på å se arkitekturen fra ulike perspektiver ( n View) Use Case view Logical view Deployment view Process view Implementation view ( + Data view, Security view,.)

3 Programvarearkitektur - eksempler Kommentarer / tavlegjennomgang på : Yummy Inc Et RUP Software Architecture Documet eksempel knyttet til Rational sine modelleringsverktøy : download Kommentarer til arkitekturvurderinger gjort i BUSTA-prosjektet (Stabburet) Kommentarer til noen av Arkitektur-eksemplene dere har tilgang til fra tidligere studentprosjekter

4 Prosjektleveranse 3 Råd til hvordan dere bør legge opp arkitekturvurderingen i prosjektet Les pensumlitteratur og spesifikke kilder dere selv finner Tenk her på samme måte rundt produktet (programvaren) som vi la opp til rundt prosessen (systemutviklingsaktivitetene) i punkt 4 og punkt 7 i prosjektplan. trekk frem karakteristika fra deres utviklingsscenario og kravspesifikasjon (funksjonelle og ikke-funksjonelle) som er arkitekturbestemmende og kommenter hvilke implikasjoner disse gir. Diskuter + / - ved de å bruke de ulike arkitekturmodellene i deres setting. NB! Husk at dette ikke skal være noen teoretisk innføring i modellene. Bestem dere for arkitektur i deres programvare (evt. en kombinasjon av flere grunnmodeller) og dokumenter så hvordan arkitekturen deres blir med utgangspunkt i dette. Figurer og beskrivelser i en kombinasjon. Det er ikke noe krav å bruke RUP, men prinsippet den har med å vise den fremtidige programvaren sett fra ulike perspektiver har stor nytte. Velg et relevant dypdykk ut fra deres prosjektsetting. Veiledningen (etter påske) blir annerledes denne gangen. Dere forventes å spille en mer aktiv rolle.

5 Fra OOA til OOD Ved å benytte Objektorienterte metoder både i analyse og design i et programutviklingsprosjekt kan man bygge videre på de spesifikasjoner og modeller man allerede har bygget når man skifter fokus fra HVA til HVORDAN. Kjernen innen Objektorientert Design er å øke bevisstheten rundt plassering av ansvar på de ulike enhetene (komponentene/klassene) i løsningen. Målet er å utvikle en løsning preget av komponenter/klasser med høy funksjonell styrke og lave koblinger. Gevinsten ligger i en programvare som er mer vedlikeholdbar, tilpasningsdyktig og fleksibel. Design Klassediagram og Sekvensdiagrammer er sentrale UMLdiagrammer innen objektorientert design.

6 Hva er ObjektOrientert Design? Bevissthet i tildeling/fordeling av ansvar til softwareklasser for å ivareta systemoperasjonene. Vi dekker kun Grunnleggende prinsipper for ansvarstildeling Ansvar som kan ligge på et objekt (hentet fra Craig Larman): Handling (Doing) : Doing something itself, such as creating an object or doing calculation Initiating action in other objects Controlling and coordination activities in other objects Kunnskap (Knowing): Knowing about private encapsulated data Knowing about related objects Knowing about things it can derive or calculate

7 UML-Diagrammer i Design Vi ser på tre UML-diagrammer som benyttes i OOD : Design Klasse Diagrammet (Class Diagram - et diagram for hele løsningen ) Sekvensdiagrammet (Sequence Diagram - ofte et diagram pr. Use Case ) Tilstandsdiagrammet (State Diagram - dekker sentrale tilstander et sentralt objekt i løsningen kan ha og hva som trigger endring) Vi flytter nå fokus over fra modeller av den virkelige verden til modeller av innholdet i programvaren. Dermed introduseres en rekke programvarespesifikke klasser som tildeles ansvar for å realisere kravene. Grensesnittklasser og Prosesskontrollklasser er eksempler på det.

8 Figure 7.2 Weather station use cases

9 Figure 7.3 Use case description - Report weather(sommerville) System Use case Actors Description Stimulus Response Comments Weather station Report weather Weather information system, Weather station The weather station sends a summary of the weather data that has been collected from the instruments in the collection period to the weather information system. The data sent are the maximum, minimum, and average ground and air temperatures; the maximum, minimum, and average air pressures; the maximum, minimum, and average wind speeds; the total rainfall; and the wind direction as sampled at fiveminute intervals. The weather information system establishes a satellite communication link with the weather station and requests transmission of the data. The summarized data is sent to the weather information system. Weather stations are usually asked to report once per hour but this frequency may differ from one station to another and may be modified in the future.

10 Figure 7.4 High-level architecture of the weather station

11 Figure 7.5 Architecture of data collection system

12 Figure 7.6 Weather station objects

13 Figure 7.7 Sequence diagram describing data collection

14 Figure 7.8 Weather station state diagram

15 Figure 7.9 Weather station interfaces

16 Hvordan angripe OOD-temaet? Bruk de tre eksemplene vi har tatt for oss i tilknytning til emnet i semesteret : Biblioteksløsningen, Monopoleksemplet og OL- Veiviseren. Tenk gjennom hvilke brikker må på plass i programvaren for å løse de samlede funksjonelle krav. - skisser sekvensdiagram for sentrale Use Case (Lån bok, Reserver bok, Send purring) (Sett opp spill, Spill omgang) ( Vis Ti-på-topp, Generer reiserute) - ta utgangspunkt i Konseptuelt klassediagram og legg på operasjoner på klassene + legg inn nye programvarespesifikke klasser (grensesnittklasser og kontrollerklasser) - skisser tilstandsdiagram for sentrale klasser (Eksemplar, Brikke, Publikummer)