Distributed object architecture

Transkript

1 Forelesning IMT April 2009 Tema: forts. arkitektur og design av programvare Oppsummering fra forrige gang Programvarearkitektur i distribuerte systemer Programvarearkitektur i RUP Eksempler på arkitekturvurderinger OL veiviseren og IHID-løsningen Tidligere studentprosjekter BUSTA Objektorientert Design (k.14) Pensum litteratur : Sommerville (Kap.12,14), Software Architecture Document-artefaktet i RUP Distributed object architecture (Sommerville fig ) o1 o2 o3 o4 S (o1) S (o2) S (o3) S (o4) Software bus o5 S (o5) o6 S (o6) Distribuert objekt arkitektur Ligner Klient - Tjener arkitekturen i at man har objekter som forespør tjenester av andre objekter. Skiller seg fra Klient - Tjener ved at man ikke skiller mellom klienter og tjenere. Hvert objekt har grensesnitt der de tilbyr tjenestene sine til omgivelsene. Krever bruk av Middleware for styring av kommunikasjonen mellom de distribuerte objektene. (eks1. CORBA/OMA/MDAfraObject OMA /MDA Object Management Group) (eks 2. COM / COM+ / DCOM /.NET fra Microsoft ) (eks 3. RMI / EJB / Jboss fra Java-kretser) + ressursdeling, åpenhet, samtidighet, fleksibilitet, feiltoleranse og skalerbarhet - kompleksitet, uforutsigbarhet, sikkerhetsproblematikk, utfordrende å bevare oversikt over systemet IMT 2243 : Systemutvikling 1

2 CORBA application structure (Sommerville fig ) Inter-ORB communications (Sommerville fig ) Trender innen arkitektur : Model Driven Architecture ( Problemer med Distribuert Objektarkitektur : Skrikende mangel på standardisering Svært mye teknologifokus for å få ting til å fungere (brukernes krav og ønsker druknet dels I teknokratstyrte prosjekter) Man ble sterkt knyttet til valgt Middleware leverandør, og det var komplekst å forholde seg til flere MDA : Rundt årtusenskiftet utformet Object Management Group ( Model Driven Architecture (en sentral spesifikasjon klar i 2001) med fokus på interoperabilitet En målsetting var å fristille seg fra bestemte teknologier/utviklingsplatformer og utforme løsninger gjennom modellering. Man forsøkte i stor grad automatisere steget med implementere løsningen i miljøer. IMT 2243 : Systemutvikling 2

3 Trender innen arkitektur : Model Driven Architecture ( ( Trender innen arkitektur : Service Oriented Architecture Web Sevices er en standardisert måte å gjøre gjenbrukbare komponenter tilgjenglige og anvendbare på web. Tjenestene er basert på betal etter bruk og man kan i prinsippet skifte leverandør etter ønske. Tankegangen på å dele inn applikasjoner basert på en tjenesteorientert struktur med tjeneste tjenestetilbyder og tjenesteforespørrer har etter hvert blitt adoptert og forbedret til også intern bruk i organisasjoners IT-systemer. SOA er blitt en toneangivende arkitektur for IT-løsninger de senere årene. SOA - basert på XML-baserte standarder som SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) og UDDI (- Universal Description, Discovery and Integration). Service Oriented Architecture I perioden 2004 og frem til idag har SOA fått en svært fremtredende rolle når man snakker om trender innen programvarearitektur. Utgangspunktet for SOA er at man lar forretningsprosessene og behovet for fleksibilitet til å endre disse prege inndelingen og organiseringen av IT-systemene. Man har fokus på de tjenester som IT-systemene skal levere til virksomhetens forretningsprosesser. Istenden for å ha ulike systemer som eies av ulike avdelinger i virksomheten med delvis overlappende funksjonalitet, er idealet at man kartlegger alle tjenester som ønskes. Tjenestene innkapsles med veldefinerte grensesnitt og gjenbrukes i alle ledd av organsisasjonen som har dette behovet. Tjenestene kan også videreutvikles eller skiftes ut med nye ettersom kravene endrer seg. IMT 2243 : Systemutvikling 3

4 Service Oriented Architecture 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.) Arkitektur Eksempler på arkitektur-vurderinger IHID-løsningen og OL-veiviseren Athletic Manager, NorBud, Interaktiv Opplæring (se projekter) BUSTA Forventninger til arkitekturvurderingene i prosjektene deres (lev. 3 frist for evt. utkast 18.april) IMT 2243 : Systemutvikling 4

5 Detaljert design På det detaljerte dypdykket i prosjektleveranse 3 står dere fritt til å velge tema bare dere kan argumentere for hvorfor dette området er relevant å se nærmere på i nettopp deres prosjekt. Eksempler på aktuelle tema : GUI-design, Informasjonssikkerhetsvurdering, Databasedesign (evt. XML), Objektorientert t t design på kritisk k del, Grensesnittdesign i mot omkringliggende systemer, aktuelle utviklingsmiljøer og deres innflytelse på design, Dere oppfordres til benytte ekspertise dere har i gruppa innen det aktuelle feltet. (Et enkelt eksempel er lagt ut under Ressurser innen GUI-design referer til kilder dere selv benytter). Pensummessig er Objektorientert Design det eneste temaet vi ser nærmere på i IMT2243 når det gjelder detaljert design. 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. På denne måten kan man oppnå en løsning preget av klasser med høy funksjonell styrke og lave koblinger. Gevinsten er en programvare som er mer vedlikeholdbar, tilpasningsdyktig og fleksibel. Design Klassediagram og Sekvensdiagrammer er sentrale UMLdiagrammer innen objektorientert design. Hva er ObjektOrientert Design? Bevissthet i tildeling/fordeling av ansvar til softwareklasser for å ivareta systemoperasjonene. Design Patterns (ikke pensum) gir innspill i form av generelle løsningsskisser til gjentagende problemstillinger. Vi dekker kun Grunnleggende prinsipper for ansvarstildeling Craig Larman om ansvar som kan ligge på et objekt : 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 IMT 2243 : Systemutvikling 5

6 Diagrammene I OOD står to UML-diagrammer sentralt : Design Klasse Diagrammet (fig ) Sekvensdiagrammet (fig ) Hva med Monopol spillet og fordeling av ansvar mellom softwareobjektene når Use Caset Spill omgang skal gjennomføres? - løser denne etter påske, nå kun trekke opp scenariet IMT 2243 : Systemutvikling 6