 Jens Bennedsen 2002Objektorienteret systemudvikling Arkitektur.

Præsentationer af emnet: " Jens Bennedsen 2002Objektorienteret systemudvikling Arkitektur."— Præsentationens transcript:

1  Jens Bennedsen 2002Objektorienteret systemudvikling Arkitektur

2  Jens Bennedsen 2002Objektorienteret systemudvikling 3 lags arkitektur Grænseflade- komponent Funktions- komponent Model- komponent >

3  Jens Bennedsen 2002Objektorienteret systemudvikling Hvad er arkitektur? OOA&D: –”Arkitekturen kan udtrykkes som en overordnet strukturering af dele, der modsvarer kriterier for systemets design…Arkitekturen sætter på afgørende vis vilkårene for resten af designet. En uklar arkitektur vil føre til meget spildt arbejde i resten ”

4  Jens Bennedsen 2002Objektorienteret systemudvikling Hvad er arkitektur? UML 1.3: –Architecture is the organizational structure of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts. Parts that interact through interfaces include classes, components and subsystems. Perry and Wolf –Software Architecture = { Elements, Form, Rationale } HvadHvordan Hvorfor

5  Jens Bennedsen 2002Objektorienteret systemudvikling Arkitektur (2) Shaw and Garlan –Software architecture [is a level of design that] involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns. Kruchten –Software architecture deals with the design and implementation of the high-level structure of software. Architecture deals with abstraction, decomposition, composition, style, and aesthetics.

6  Jens Bennedsen 2002Objektorienteret systemudvikling Practioner’s definitions The following definitions are samples from software architects and senior software engineers: –Software architecture is :  an overall view of the solution to a problem  the high-level design of modular components and how they interact  a foundation that one can build on to solve a problem (e.g., rules, policies, attributes, etc.)  an efficient method to meet a fixed set of well-defined attributes

7  Jens Bennedsen 2002Objektorienteret systemudvikling Arkitektur og krav. spec. Software arkitektur er den overordnede struktur af et software system. Vigtige egenskaber er bl.a:  Det er på et så højt abstraktionsniveau, at systemet kan ses som et hele.  Strukturen skal understøtte den funktionalitet der er krævet af systemet. Det vil sige, at den dynamisk opførsel af systemet skal tages med i betragtning når arkitekturen.  Arkitekturen skal passe til kvalitetskravene til systemet (også kendt som non-funktionelle krav). Disse krav inkluderer sandsynligvis performance, sikkerhed og krav om at det skal passe med det nuværende system samt krav om fleksibilitet og udvidbarhed i forbindelse med fremtidige krav til en rimelig pris. Disse krav kan konflikte og afvejninger mellem alternativer er en essentiel del af arkitektur design.  På arkitektur niveauet er alle implentationsdetaljer skjult.

8  Jens Bennedsen 2002Objektorienteret systemudvikling Kriterier

9  Jens Bennedsen 2002Objektorienteret systemudvikling Kriterier (2)

10  Jens Bennedsen 2002Objektorienteret systemudvikling Opdeling i delsystemer Skal hver klasse realiseres i sin.java fil? –I et lille skole system giver det ~50 filer –I et virkeligt system giver det ~2-500 filer Svært at holde styr på Svært at bruge som arbejdsenhed når der skal uddeles ”kodeansvar” Er dette et design- eller projektledelses problem? –Begge

11  Jens Bennedsen 2002Objektorienteret systemudvikling Moduler Moduler skal danne baggrund for hvad der måles på - ikke individuelle klasser Modul er en release enhed Modul er en genbrugsenhed I et modul er klasser tæt bundne med løst koblede til andre moduler Moduler i java understøttes af packages

12  Jens Bennedsen 2002Objektorienteret systemudvikling Moduler Klasserne i et modul skal være tæt bundne At være tæt bundet i et modul betyder 1 De skal være lukkede overfor de samme ændringer og immune over de samme andre ændringer 2 De skal genbruges sammen 3 De skal have en fælles funktionalitet eller politik Det er en prioriteret rækkefølge

13  Jens Bennedsen 2002Objektorienteret systemudvikling Afhængighed Forskellige typer af afhængighed –Arv (En klasse fra modul A arver fra modul B) –Instantiering (en klasse fra modul B skal instantieres i modul A) –Kald (En operation i modul A kalder en operation i modul B) –Association (En klasse i modul A er associeret til en klasse i modul B) –Aggregering (En klasse i modul A indeholder en forekomst fra modul B)

14  Jens Bennedsen 2002Objektorienteret systemudvikling Afhængighed Afhængighed: –Et modul A afhænger af modul B hvis en eller flere klasse i modul A det ikke kan oversættes og aftestes uden tilgang til mindst en klasse fra modul B UML Package Kan bruges til at lave –releaseplan –testplan –projektplan

15  Jens Bennedsen 2002Objektorienteret systemudvikling Afhængighed Afhængige vs. afhænger Afhængige af klassen FÅ MANGE Afhænger af andre FÅ MANGE Normal moduler Stabil Ustabil Der er mange der afhænger  svært at ændre afhænger af få  få grunde til at ændre Der er få der afhænger  let at ændre afhænger af mange  mange grunde til at ændre

16  Jens Bennedsen 2002Objektorienteret systemudvikling The main sequence Stabilitet vs. generalitet Generalitet, abstrakhed Lav Høj Stabilitet (Placering på forrige slide) Stabil Ustabil The main sequence Arkitektur/ Overordnet struktur Implementations detaljer

17  Jens Bennedsen 2002Objektorienteret systemudvikling Traditionel software DFD har den modsatte egenskab: Jo mere detaljeret en boble jo flere afhænger af den Ændringer i nedre lag propagerer opad Generalitet, abstrakhed Lav Høj Stabilitet Stabil Ustabil The main sequence Arkitektur/ Overordnet struktur Implementations detaljer

18  Jens Bennedsen 2002Objektorienteret systemudvikling Hvorfor omvendt ved OO?? interface klasser –Interfaces til begreber –Implementations detaljer gemmes længere nede –Mulighed for at genbruge procedurelle abstraktioner