Komponentbasert Systemutvikling - Hva, Hvorfor, Hvordan Øyvind Matheson Wergeland Master student 23. 1. 2004 Typiske bruksområder for komponenter Sammensatte dokumenter Microsoft OLE og ActiveX (COM) Distribuerte enterprise-systemer Enterprise JavaBeans Microsoft COM+ Microsoft.Net assemblies
Komponenter - typiske karakteristikker Enhet for selvstendig klargjøring og installasjon Enhet for komposisjon av tredjepart Ingen (ekstern) observerbar tilstand Blåkopi vs. instans Objekter - typiske karakteristikker Enhet for instansiering Har unik identitet Kan ha observerbar tilstand Innkapsler tilstand og oppførsel En klasse er et objekts blåkopi
Szyperskis komponentdefinisjon «A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties» Grensesnittskontrakter Funksjoner defineres både syntaktisk og semantisk int add(int a, int b) pre: a + b <= Integer.MAXINT post: result = a + b Ekstra-funksjonelle krav Garanti: Retur innen 10 ms Betingelse: Trenger 1000 CPU-sykler Krav til formalisme? FOCUS (Broy og Stølen), samt videre arbeid av Broy
Eksplisitte kontekstkrav Komponentmodell Definerer reglene for komposisjon Komponentplattform Definerer reglene for installasjon og aktivering av komponenter Rammeverk/beholder Implementasjonen av plattformen Påkrever-grensesnitt Tilbys av andre komponenter tilgjengelig i rammeverket Installering og komposisjon En komponent må kunne installeres alene, men typisk så pakker man sammen et sett atomiske komponenter som er beregnet til å virke sammen Komponenter fra flere leverandører vil kunne inngå i samme komposisjon
Hvorfor komponentbasert systemutvikling? Utvikling av store systemer er komplekst tidskrevende dyrt inkrementell Den klassiske løsningen er abstraksjon gjenbruk Kandidatteknologier Prosedyreorienterte bibliotek Objektorientering Tjenester
Polymorfi Komponenter har bruk for polymorfi Støtte flere versjoner av et grensesnitt Støtte forskjellige grensesnitt samtidig Alternative implementasjoner OO støtter polymorfi gjennom arv Så er klasser en god kandidat for komponenter? Objektorientering og arv Implementasjonsarv Subklassing Grensesnittarv Subtyping Utbyttbarhet
Problemer med prosedyrer og objekter Tilbakekall i asynkrone bibliotek Oppoverkall mellom objekter «The fragile base class problem» (FBC) Tilbakekall Går oppover i arkitekturlagene Må ivareta gyldig observervar tilstand i biblioteket inntil alle tilbakekall er fullført Resultatet av et tilbakekall kan være at tilstanden endrer seg pga. nytt kall (nedover) Abstrakt Lag n+1 Lag n Registrering av tilbakekall Tilbakekall Usynlig Konkret Lag n-1 Konsistent
Oppoverkall mellom objekter Et kall fra A til B er i virkeligheten et (mulig utilsiktet) oppoverkall A (n) foo() bar() B (n+1) bar() sd foo1 :A foo() bar() sd foo2 :A :B foo() bar() «The fragile base class problem» sd foobar foobar() A foo() bar() B foobar() :B :A foo() bar() Hva skjer når det kommer en ny versjon av A? Problemet må betraktes: Syntaktisk: Fungerer B uten å rekompileres? Semantisk: Fungerer B uten å reprogrammeres?
Kan FBC-problemet løses? Det grunnleggende problemet er at implementasjonsarv ødelegger innkapsling Grensesnittet for å kalle metoder i et objekt utenfra er definert Grensesnittet til en subklasse kan defineres i et spesialiseringsgrensesnitt Java: public + protected metoder Ved å deklarere avhengigheter mellom metoder, er det mulig å ordne metoder lagvis i grupper. Metoder som er gjensidig avhengig av hverandre utgjør en gruppe Metoder må overstyres gruppevis i subklasser Stata-Guttag-klasser Klasser deles opp i grupper av både tilstand og oppførsel Som ved spesialiseringsgrensesnitt, må grupper overstyres i sin helhet
Komponering med objekter En Stata-Guttag-klasse kan transformeres til en komposisjon av objekter En slik komposisjon støtter også dynamisk og sen komposisjon Hva med identitet? A A B C C B Hva inneholder komponenter? Andre komponenter Klasser Script Prosedyrebibliotek...
Størrelse på komponenter Audio Source Audio Decoder Decoder Buffer RTP Sink Påkrevergrensesnitt Tilbydergrensesnitt Queue Maksimering av gjenbruk minimerer bruk. Krav til komponentmodeller Trygghet (safety) Versjonering/bakoverkompabilitet Modulær innkapsling Abstraksjon Eksplisitte kontekstkrav Sen binding og lasting Uavhengig installasjon Polymorfi
Trygghet Type-trygghet Minne-trygghet Aksess Søppeltømming Modul-trygghet Komponenter må ikke få kalle vilkårlige tjenester Hvilke tjenester som trengs må spesifiseres Støttes av f.eks. Java/JVM og C#/.Net CLR Versjonering/bakoverkompabilitet COM: må tilordne unike ID-er til et grensesnitt (IID) når det genereres CORBA: kan tilordne repository ID til et grensesnitt (typisk når det publiseres) Java: ikke støttet Trenger polymorfi for for å støtte forskjellige versjoner samtidig
Polymorfi Komponenter må være utbyttbare Versjonering Praktisk å kunne støtte forskjellige grensesnitt i en komponent Grensesnittarv er praktisk (for typehierakier) Eksempler på komponentmodeller Java: JavaBeans, EJB, Servlets/JSP, Portlets CORBA CCM (supersett av EJB) Microsoft VBX, COM/COM+,.Net assemblies
Komponentrammeverk En dedikert og fokusert arkitektur Definerer reglene og grensesnittene for interaksjon mellom komponenteme som plugges inn i rammeverket Kan finnes i flere ordner 1. ordens rammeverk er komponenter i et 2. ordens rammeverk Eksempel: Open ORB II Mediering i komponentrammeverk 2. CFI 1. CFI CI Rammeverkene kan stå for mediering mellom komponentene, eller la de kommunisere direkte med tilgjengelige mekanismer i komponentmodellen
Sette sammen komponenter Forbindelsesorienert programmering Eksplisitte bindinger mellom komponenter Stor-skala-programmering Arkiketurbeskrivelsesspråk skiller mellom komponenter og forbindelser Statisk (før bruk) Visuell med design/kjøretids-modi Dynamisk (under bruk) Sluttbrukere Adapterende systemer Utviklingsmetodikker UML 1.x har dårlig støtte for komponenter Et god del metodikker har prøvd å bøte på dette, bl.a. COMET UML 2.0 støtter komponenter Metodikker basert på UML 2.0 vil lett kunne støtte komponentbasert utvikling Catalysis
Problemer med komponentbasert utvikling Versjonering av grensesnitt Begrenset mulighet i CORBA Mangler fullstendig i Java-baserte komponentmodeller (f. eks. JavaBeans og EJB) Tungt å integrere mellom forskjellige komponentrammeverk Har manglet støtte i UML Dårlig støttet i programmeringsspråk Forholdsvis lite marked for komponenter Andre utviklingstrender Oppdaterte metodikker basert på UML 2.0 Innføring av «adskillelse av interesseområder» i komponenter Subjektorientert programmering Samme objekt har forskjellig tilstand og oppførsel avhengig av observatøren Aspektorientert programmering Komponering av aspekter på tvers av funksjonalitet
Referanser Berre et al. (2003): «COMET Methodology Handbook with documentation of the COMET metamodels», v. 2.3 http://www.ifi.uio.no/~mm/generic/handbooks/comet_v23.pdf Blair et al. (2002) «The design of a configurable and reconfigurable middleware platform». Distributed Computing, vol. 15, nr. 2, s. 109-126 Broy (2003): «Services and layered architectures specification and multi view modelling of software systems» (under arbeid) http://heim.ifi.uio.no/~ketils/sardas/031014.manfred-broy.pdf D Souza og Wills (1999): «Object, Components and Frameworks with UML: The Catalysis Approach», Addison-Wesley Szyperksi (2002): «Component Software: Beyond Object-Oriented Programming», 2. utgave, Addison-Wesley Spørsmål?