Software Arkitektur - anno 2002

Transkript

1 Software Arkitektur - anno 2002 Faglig aften i datalogforeningen Århus den 24. januar 2002 Finn Overgaard Hansen Ingeniørhøjskolen i Århus ( Elektro- og IKT-afdelingen foh@e.iha.dk

2 Agenda Introduktion Hvorfor er arkitektur vigtig Udvikling inden for SW design State of the Art Architectural Styles Architectural- and Design Patterns Frameworks Nyere arkitektur begreber Dokumentation vha. views og udviklingsproces Opsummering SW arkitektur, 24. januar

3 Jørn Utzons Opera House Sydney Cost $AU 102,000,000 to build. Includes 1000 rooms. Is 185 m long and 120 m wide. Has 2194 pre-cast concrete sections as its roof. Has roof sections weighing up to 15 t. Has roof sections held together by 350 kms of tensioned steel cable. Has over 1 million tiles on the roof. Uses 6225 square metres of glass and 645 kilometres of electric cable. Was designed by Danish architect Jørn Utzon. Was opened 20 October SW arkitektur, 24. januar

4 Spreckelsens Grand Arche Paris Stod færdig i 1989, 200 år efter revolutionen! skulptur af Niki de Saint Phalle SW arkitektur, 24. januar

5 SW arkitektur en uformel skitse Real-time communication p1 pipe p2 pipe p3 Database access X-windows ADT (abstract data types) SW arkitektur, 24. januar

6 Udfordringer inden for SW udvikling SW arkitektur, 24. januar

7 Udfordringer inden for SW udvikling Stigende kompleksitet SW arkitektur, 24. januar

8 Udfordringer inden for SW udvikling Stigende kompleksitet Reduktion af Time to Market SW arkitektur, 24. januar

9 Udfordringer inden for SW udvikling Stigende kompleksitet Reduktion af Time to Market Større projekter flere skal arbejde sammen mere specialisering SW arkitektur, 24. januar

10 Udfordringer inden for SW udvikling Stigende kompleksitet Reduktion af Time to Market Større projekter flere skal arbejde sammen mere specialisering Fra stand alone systemer til netværk af distribuerede systemer SW arkitektur, 24. januar

11 Udfordringer inden for SW udvikling Stigende kompleksitet Reduktion af Time to Market Større projekter flere skal arbejde sammen mere specialisering Fra stand alone systemer til netværk af distribuerede systemer Fra enkeltstående apparater til produktlinier SW arkitektur, 24. januar

12 Udfordringer inden for SW udvikling Stigende kompleksitet Reduktion af Time to Market Større projekter flere skal arbejde sammen mere specialisering Fra stand alone systemer til netværk af distribuerede systemer Fra enkeltstående apparater til produktlinier WWW tilkobling (overvågning, konfigurering og opdatering) SW arkitektur, 24. januar

13 Udfordringer inden for SW udvikling Stigende kompleksitet Reduktion af Time to Market Større projekter flere skal arbejde sammen mere specialisering Fra stand alone systemer til netværk af distribuerede systemer Fra enkeltstående apparater til produktlinier WWW tilkobling (overvågning, konfigurering og opdatering) Sørre krav om genbrug - det er blevet for dyrt at starte forfra SW arkitektur, 24. januar

14 Udfordringer inden for SW udvikling Stigende kompleksitet Reduktion af Time to Market Større projekter flere skal arbejde sammen mere specialisering Fra stand alone systemer til netværk af distribuerede systemer Fra enkeltstående apparater til produktlinier WWW tilkobling (overvågning, konfigurering og opdatering) Sørre krav om genbrug - det er blevet for dyrt at starte forfra Mange nye og konkurrerende middelware teknologier CORBA, DCOM, RMI,.NET, Jini, SOAP Real Time udgaver på vej af RT-Linux, RT-CORBA, RT-Java SW arkitektur, 24. januar

15 Arkitektur i relation til øvrige udviklingsaktiviteter Requirements Hardware architecture Domain-, Requirement- and Risk analysis modifications modifications Software Architecture Design Hardware Architecture Design Software architecture Detailed design, Coding, Integration, Testing Implementation constraints SW arkitektur, 24. januar

16 Arkitektur i relation til øvrige udviklingsaktiviteter Domain-, Requirement- and Risk analysis Requirements modifications modifications System Architecture Software Architecture Design Hardware architecture Hardware Architecture Design Software architecture Detailed design, Coding, Integration, Testing Implementation constraints SW arkitektur, 24. januar

17 Definering af SW arkitektur SW arkitektur, 24. januar

18 Definering af SW arkitektur Eksempler på definition af SW arkitektur: SW arkitektur, 24. januar

19 Definering af SW arkitektur Eksempler på definition af SW arkitektur: The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components and the relationships among them Ref: Software Architecture in Practice, [Bass98] SW arkitektur, 24. januar

20 Definering af SW arkitektur Eksempler på definition af SW arkitektur: The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components and the relationships among them Ref: Software Architecture in Practice, [Bass98] is a set of concepts and design decisions about the structure and texture of sofware that must be made prior to concurrent engineering to enable effective satisfaction of architectural significant explicit functional and quality requirements and implicit requirements of the product family, the problem and the solution domains Ref: Software Architecture for Product families, [Jazayeri2000] SW arkitektur, 24. januar

21 Kontekst for SW arkitektur Architectural Styles Dokumentationsaspekt Architectural- & Design- Patterns SW arkitektur Agentteknologi Komponentteknologi Objektteknologi (UML) Frameworks Udviklingsproces Middelware standarder SW arkitektur, 24. januar

22 OO analyse OO arkitekturdesign Kravspec. og Use Case model Use Case x Aktør 1 Use Case x Ikke funkt. krav SW arkitektur, 24. januar

23 OO analyse OO arkitekturdesign Kravspec. og Use Case model OO analyse model Use Case x Aktør 1 Use Case x Ikke funkt. krav SW arkitektur, 24. januar

24 OO analyse OO arkitekturdesign Kravspec. og Use Case model OO analyse model Use Case x Aktør 1 Use Case x Ikke funkt. krav SW arkitektur, 24. januar

25 OO analyse OO arkitekturdesign Kravspec. og Use Case model OO analyse model Løsning 1. OO arkitektur design model Use Case x Node Aktør 1 Task1 Task2 Use Case x Ikke funkt. krav SW arkitektur, 24. januar

26 OO analyse OO arkitekturdesign Kravspec. og Use Case model OO analyse model Løsning 1. OO arkitektur design model Use Case x Node Aktør 1 Task1 Task2 Use Case x Løsning 2. Node1 Node2 Ikke funkt. krav Task1 Task2 Task3 SW arkitektur, 24. januar

27 Software beskrivelsesteknikker SW arkitektur, 24. januar

28 Software beskrivelsesteknikker Diagrammerings- og designteknikker Rutediagrammer, tilstandsdiagrammer Struktureret Programmering, Go-To less programming, Dijkstra 1968 Jackson Diagrammer, Jacksons JSP 1975 Structure Charts - Constantines Struktureret design 1975 Access graph - Brinch Hansens Concurrent Pascal 1977 SW arkitektur, 24. januar

29 Software beskrivelsesteknikker Diagrammerings- og designteknikker Rutediagrammer, tilstandsdiagrammer Struktureret Programmering, Go-To less programming, Dijkstra 1968 Jackson Diagrammer, Jacksons JSP 1975 Structure Charts - Constantines Struktureret design 1975 Access graph - Brinch Hansens Concurrent Pascal 1977 Ward & Mellors SA/SD-Real Time, 1985 Dataflow-, tilstands-, entitets relations - og struktur diagrammer SW arkitektur, 24. januar

30 Software beskrivelsesteknikker Diagrammerings- og designteknikker Rutediagrammer, tilstandsdiagrammer Struktureret Programmering, Go-To less programming, Dijkstra 1968 Jackson Diagrammer, Jacksons JSP 1975 Structure Charts - Constantines Struktureret design 1975 Access graph - Brinch Hansens Concurrent Pascal 1977 Ward & Mellors SA/SD-Real Time, 1985 Dataflow-, tilstands-, entitets relations - og struktur diagrammer OO Metoder f.eks. OMT 1991 Klasse-, tilstands-, dataflow diagrammer SW arkitektur, 24. januar

31 Software beskrivelsesteknikker Diagrammerings- og designteknikker Rutediagrammer, tilstandsdiagrammer Struktureret Programmering, Go-To less programming, Dijkstra 1968 Jackson Diagrammer, Jacksons JSP 1975 Structure Charts - Constantines Struktureret design 1975 Access graph - Brinch Hansens Concurrent Pascal 1977 Ward & Mellors SA/SD-Real Time, 1985 Dataflow-, tilstands-, entitets relations - og struktur diagrammer OO Metoder f.eks. OMT 1991 Klasse-, tilstands-, dataflow diagrammer UML (Unified Modelling Language) - OMG standard i 1997 Klasse-, tilstands-, interaktions-, deployment-, komponent- og Use Case diagrammer UML ver. 1.4 er aktuel version, ver. 2.0 er på vej. SW arkitektur, 24. januar

32 Indkapsling Udvikling inden for SW design 1. Abstrakte datatyper, objektbaseret programmering Eksterne/public funktioner, private funktioner og data Dokumentation: moduldiagrammer Realiseret i f.eks. Assembler, PLM, C, Pascal Modul A private data og funktioner public funktioner Modul B Modul C SW arkitektur, 24. januar

33 Udvikling inden for SW design 2. Objektorienteret Programmering Klasser og associationer Nedarvning og polymorfi Dokumentation: Klassediagrammer (UML) Eksempler på sprog: Smalltalk, C++, Java, C# Class A ændringer i B s grænseflade påvirker kun A og D B D C D1 D2 SW arkitektur, 24. januar

34 Concurrent Pascal accesgraf eksempel Foretag operatør kommunikation P Overvågnings- Specifikation M Foretag overvågning P Overvågningsenhed DM Operatør konsol DM Behandel alarmer P Alarm Tabel M indsætalarm() hentalarm() fjernalarm() P: Proces M: Monitor (klasse med udelelig adgang) DM: Device Monitor SW arkitektur, 24. januar

35 Udvikling inden for SW design 3. Nyere OO begreber (supporteret af UML): Vigtige ved udvikling af større systemer Composition Interfaces (understøttes af Java) Class A B C Class A B C SW arkitektur, 24. januar

36 Udvikling inden for SW design 3. Nyere OO begreber (supporteret af UML): Vigtige ved udvikling af større systemer Composition Interfaces (understøttes af Java) Class A B C Class A B Class A Class B +op1() +op2() if 1 +op3() if 2 Class D C op1() Class C op2() op3() SW arkitektur, 24. januar

37 Udvikling inden for SW design 4. Flere nyere OO begreber (supporteret af UML): Pakker (understøttes af Java) Anvendes til at vise både logisk og fysisk indkapsling Pakke J F G H SW arkitektur, 24. januar

38 Udvikling inden for SW design 4. Flere nyere OO begreber (supporteret af UML): Pakker (understøttes af Java) Anvendes til at vise både logisk og fysisk indkapsling Pakke J Pakke H Kunne være en Façade klasse Class A F G B D H C D1 D2 SW arkitektur, 24. januar

39 Udvikling inden for SW design 5. Flere nyere OO begreber (understøttet af UML): Aktive objekter Nodes Alarm Window «Task» Motor Supervisor «Monitor» Alarm Table «Task» Alarm Handler SW arkitektur, 24. januar

40 Udvikling inden for SW design 5. Flere nyere OO begreber (understøttet af UML): Aktive objekter Nodes Alarm Window «Task» Motor Supervisor «Monitor» Alarm Table «Task» Alarm Handler Base Station Controller Comm Server Mobil Switch Deployment diagram <<TCP/IP>> Application Server <<TCP/IP>> DB Server SW arkitektur, 24. januar

41 SW dokumentationsaspekter SW arkitektur, 24. januar

42 SW dokumentationsaspekter Dokumentation af statiske forhold: Klassediagrammer: Pakker, klasser og interfaces Komponentdiagrammer: viser ekseverbare komponenter og kodefiler Deployment diagrammer: viser nodes f.eks. processorer SW arkitektur, 24. januar

43 SW dokumentationsaspekter Dokumentation af statiske forhold: Klassediagrammer: Pakker, klasser og interfaces Komponentdiagrammer: viser ekseverbare komponenter og kodefiler Deployment diagrammer: viser nodes f.eks. processorer Dokumentation af dynamiske forhold: Interaktionsdiagrammer f.eks. sekvensdiagrammer Tilstandsdiagrammer for klasser med tilstandsafhængig opførsel Aktivitesdiagrammer: kan f.eks. vise synkroniserings-aspekter SW arkitektur, 24. januar

44 State of the Art for SW arkitektur Højniveau Lavniveau SW arkitektur, 24. januar

45 State of the Art for SW arkitektur Højniveau Architectural Styles Styles dominerer en given arkitektur Eksempler: Pipes and Filters, Layered architectural structure Lavniveau SW arkitektur, 24. januar

46 State of the Art for SW arkitektur Højniveau Architectural Styles Styles dominerer en given arkitektur Eksempler: Pipes and Filters, Layered architectural structure Architectural Patterns Retter sig mod System-wide design problemer Er ikke dominerende og kan ofte kombineres med andre mønstre Eksempler: concurrency og persistens Lavniveau SW arkitektur, 24. januar

47 State of the Art for SW arkitektur Højniveau Architectural Styles Styles dominerer en given arkitektur Eksempler: Pipes and Filters, Layered architectural structure Architectural Patterns Retter sig mod System-wide design problemer Er ikke dominerende og kan ofte kombineres med andre mønstre Eksempler: concurrency og persistens Design Patterns (GoF) Design mønstre har ofte mere lokal effekt Eksempler: Observer pattern, State Pattern Lavniveau SW arkitektur, 24. januar

48 State of the Art for SW arkitektur Højniveau Lavniveau Architectural Styles Styles dominerer en given arkitektur Eksempler: Pipes and Filters, Layered architectural structure Architectural Patterns Retter sig mod System-wide design problemer Er ikke dominerende og kan ofte kombineres med andre mønstre Eksempler: concurrency og persistens Design Patterns (GoF) Design mønstre har ofte mere lokal effekt Eksempler: Observer pattern, State Pattern Idioms Kodenære mønstre og mekanismer Eksempel: Counted pointer for C++ SW arkitektur, 24. januar

49 Architectural Styles (Shaw&Garlan) 1. Fem kategorier af Architectural Styles: Dataflow systems Batch sequentiel, Pipes and filters Call-and-return systems OO systems, Main program and subroutine, Hierarchical layers Independent compontents Event systems, Communicating processes Virtual machines Interpreters, Rule-based systems Data-centered systems (repositores) Databases, Hypertext systems, Blackboards Ref. [Shaw&Garlan96] SW arkitektur, 24. januar

50 Architectural Styles (Shaw&Garlan) 2. Eksempler på Architectural Styles: Pipes and filters Data abstraction and Object-Oriented organization Event-based, implicit invocation Layered systems Eksempler: OSI model, Adm. system: præsentation, logik og model lag Repositores Interpreters Process control Ref. [Shaw&Garlan96] SW arkitektur, 24. januar

51 Buschmann s tre mønster kategorier Arkitektur mønstre: Layers Pipes & Filters Blackboard Broker Model-View-Controller Shaw& Garlan Styles Presentation-Abstraction-Control (PAC) Microkernel Reflection Ref. [Bushmann 96] SW arkitektur, 24. januar

52 Buschmann s tre mønster kategorier Arkitektur mønstre: Layers Pipes & Filters Blackboard Broker Model-View-Controller Shaw& Garlan Styles Presentation-Abstraction-Control (PAC) Microkernel Reflection Design mønstre: Observer (GoF) Publisher-subscriber Strategy (GoF) Composite (GoF) Abstract Factory (GoF) Bridge (GoF) Proxy (GoF) Command Processor View Handler Master-slave Ref. [Bushmann 96] SW arkitektur, 24. januar

53 Buschmann s tre mønster kategorier Arkitektur mønstre: Layers Pipes & Filters Blackboard Broker Model-View-Controller Presentation-Abstraction-Control (PAC) Microkernel Reflection Ref. [Bushmann 96] Shaw& Garlan Styles Design mønstre: Observer (GoF) Publisher-subscriber Strategy (GoF) Composite (GoF) Abstract Factory (GoF) Bridge (GoF) Proxy (GoF) Command Processor View Handler Master-slave Idioms: Singleton (GoF) Factory Method (GoF) Counted pointer, Handle-Body Envelope-Letter SW arkitektur, 24. januar

54 Pipes & Filters so: Source f1: Filter1 p1: Pipe f2: Filter2 Dataflow arkitektur, hvor komponenterne kan være: Objekter Tasks (aktive objekter) Computere (maskiner) p2: Pipe f3: Filter3 si: Sink SW arkitektur, 24. januar

55 Pipes & Filters so: Source f1: Filter1 p1: Pipe f2: Filter2 Dynamisk konfiguering af processering f4: Filter4 p3: Pipe Dataflow arkitektur, hvor komponenterne kan være: Objekter Tasks (aktive objekter) Computere (maskiner) p2: Pipe f3: Filter3 si: Sink SW arkitektur, 24. januar

56 Todelt arkitekturmodel SW arkitektur, 24. januar

57 Todelt arkitekturmodel Kombinerer følgende to Shaw&Garlan Architectural Styles: Event-based Process Control (plus pipes & filters internt) SW arkitektur, 24. januar

58 Todelt arkitekturmodel Kombinerer følgende to Shaw&Garlan Architectural Styles: Event-based Process Control (plus pipes & filters internt) Denne kombination kan anvendes for mange apparatsystemer Eksempler på anvendelse: styring og regulering f.eks. en frekvensomformer til styring af en motor f.eks. en Danfoss frekvensomformer (trademark VLT). måleinstrumenter f.eks. et oscilloscop eller en støjmåler audio/video: f.eks. en CD spiller SW arkitektur, 24. januar

59 Todelt arkitekturmodel Kombinerer følgende to Shaw&Garlan Architectural Styles: Event-based Process Control (plus pipes & filters internt) Denne kombination kan anvendes for mange apparatsystemer Eksempler på anvendelse: styring og regulering f.eks. en frekvensomformer til styring af en motor f.eks. en Danfoss frekvensomformer (trademark VLT). måleinstrumenter f.eks. et oscilloscop eller en støjmåler audio/video: f.eks. en CD spiller Ref: [COT] Center for Objektteknologi projekt (Case 2) SW arkitektur, 24. januar

60 Todelt arkitekturmodel - et eksempel Danfoss frekvensomformer (VLT) Event controlled part VLT user VLT Control Continuos processing part Sensor Motor Controlling Motor SW arkitektur, 24. januar

61 Todelt arkitekturmodel - et eksempel Danfoss frekvensomformer (VLT) Event controlled part VLT user VLT Control Configuration Continuos processing part Sensor Motor Controlling VLT & Motor supervising Motor SW arkitektur, 24. januar

62 Anvendte Design Patterns i en OO-VLT Discrete event based part VLT user Command, State Sensor Motor Controlling VLT & Motor supervising Strategy, Pipes&Filters Observer Continuous processing part Motor SW arkitektur, 24. januar

63 Ventilator control as process control Danfoss frekvensomformer (VLT) Disturbances: heat production, heat loos, temperature outside, etc Setpoint: desired temperature Controller: VLT? Manipulated variables: frequency+ voltage Process: Motor + ventilator + room Controlled variable: roomtemperature Feedback: measured roomtemperature Example of closed-loop feedback control Shaw & Garlan process control style Ref. [Shaw&Garlan96] SW arkitektur, 24. januar

64 Speed Open loop controller: Frekvensomformer eksempel Blokdiagram for to forskellige driftsformer Reference Reference calculation Slip compensation Output f Frequency f f f Resonance f Frequency Ramp Bypass Damping Limits Voltage calculation f U angle transangle PWM generation f U Slip estimation I Process Closed Loop controller: Reference Reference calculation PID Controller Output f Frequency f f f Resonance f Frequency Ramp Bypass Damping Limits Voltage calculation f U angle transangle PWM generation f U Feedback Calcualation Feedback SW arkitektur, 24. januar

65 Objektdiagram for SpeedOpenLoopController :SpeedOpen LoopController Pipe komponenten er her implementeret som et simpelt funktionskald f=output(f) input frequency Der flyder en ny frekvens igennem filtrene hvert 2 ms :SlipFilter f=output(f) :BypassFilter f=output(f) :FreqLimiterFilter f=output(f) :RampFilter f=output(f) :ResonanceDamperFilter output frequency SW arkitektur, 24. januar

66 Two types of VLT Use Cases Control VLT Actor initiated Use Cases (discrete) VLT user Change VLT configuration parameters SW arkitektur, 24. januar

67 Two types of VLT Use Cases Control VLT Actor initiated Use Cases (discrete) VLT user Change VLT configuration parameters System initiated Use Cases (continuous) Motor Controlling Motor Protection Motor Sensor SW arkitektur, 24. januar

68 Architectural Style: todelt arkitekturmodel Event kontrolleret del Bruger Styring Konfigurering INPUT OUTPUT Kontinuert processerings del Sensor Processering Overvågning Aktuator Bruger SW arkitektur, 24. januar

69 Udvikling mod et framework SW arkitektur, 24. januar

70 Udvikling mod et framework Første udgave af motorstyringssoftware udviklet til een type af frekvensomformere, hvor motorsignalerne til effektdelen generes vha. en ASIC (Application Specific Integrated Circuit). SW arkitektur, 24. januar

71 Udvikling mod et framework Første udgave af motorstyringssoftware udviklet til een type af frekvensomformere, hvor motorsignalerne til effektdelen generes vha. en ASIC (Application Specific Integrated Circuit). SW arkitekturen var defineret vha. en OO model og impl. i C++ SW arkitektur, 24. januar

72 Udvikling mod et framework Første udgave af motorstyringssoftware udviklet til een type af frekvensomformere, hvor motorsignalerne til effektdelen generes vha. en ASIC (Application Specific Integrated Circuit). SW arkitekturen var defineret vha. en OO model og impl. i C++ Anden udgave af softwaren blev modificeret til en anden type frekvensomformer, hvor motorssignalerne til effekdelen genereres af en DSP (Digital Signal Processor). SW arkitektur, 24. januar

73 Udvikling mod et framework Første udgave af motorstyringssoftware udviklet til een type af frekvensomformere, hvor motorsignalerne til effektdelen generes vha. en ASIC (Application Specific Integrated Circuit). SW arkitekturen var defineret vha. en OO model og impl. i C++ Anden udgave af softwaren blev modificeret til en anden type frekvensomformer, hvor motorssignalerne til effekdelen genereres af en DSP (Digital Signal Processor). Medførte modifikationer til arkitekturen, men grundideerne holdt med den todelte arkitektur style som en vigtig del af arkitekturen. SW arkitektur, 24. januar

74 Udvikling mod et framework Første udgave af motorstyringssoftware udviklet til een type af frekvensomformere, hvor motorsignalerne til effektdelen generes vha. en ASIC (Application Specific Integrated Circuit). SW arkitekturen var defineret vha. en OO model og impl. i C++ Anden udgave af softwaren blev modificeret til en anden type frekvensomformer, hvor motorssignalerne til effekdelen genereres af en DSP (Digital Signal Processor). Medførte modifikationer til arkitekturen, men grundideerne holdt med den todelte arkitektur style som en vigtig del af arkitekturen. Softwaren er på vej til at blive et framework for motorstyringssoftwaredelen, der kan anvendes for en familie af forskellige frekvensomformer produkter. SW arkitektur, 24. januar

75 Udvikling mod et framework Første udgave af motorstyringssoftware udviklet til een type af frekvensomformere, hvor motorsignalerne til effektdelen generes vha. en ASIC (Application Specific Integrated Circuit). SW arkitekturen var defineret vha. en OO model og impl. i C++ Anden udgave af softwaren blev modificeret til en anden type frekvensomformer, hvor motorssignalerne til effekdelen genereres af en DSP (Digital Signal Processor). Medførte modifikationer til arkitekturen, men grundideerne holdt med den todelte arkitektur style som en vigtig del af arkitekturen. Softwaren er på vej til at blive et framework for motorstyringssoftwaredelen, der kan anvendes for en familie af forskellige frekvensomformer produkter. Ref: COT projekt og Alexandra Institut projekt vedr. distribueret OO komm. SW arkitektur, 24. januar

76 Taksonomi for Real-Time arkitektur Der anvendes i dag fire basale arkitektur styles for real-time systemer: Timeline Event-driven Pipeline Client-Server Ref: Doug Locke, TimeSys Corporation - Embedded System Conference, San Francisco, 2001 SW arkitektur, 24. januar

77 Timeline arkitektur Timeline Systemet designes som et antal procedurer, der hver har et bestemt tidskrav (p1: hver 25 ms, p2: hver 200 ms) Procedurer kaldes med faste tidsintervaller, hvis timeren er 25 ms - så aktiveres p1 hver gang og p2 kun hver fjerde gang. Lange procedurer må opdeles i mindre. Eksempel: Flight Control Computer 2-5 processorer, 1 MB RAM 1 task for hver computer, ingen synkronisering De fleste krav er Hard Real Time krav, typisk 20 ms Anvendesf.eks. i nyereairbus fly ogi Boeing 747 SW arkitektur, 24. januar

78 Event-driven arkitektur Event-driven Her anvendes afslutning af I/O operationer og timer events til at igangsætte ventende task Der anvendes operativsystem, hvor hvert Task har en prioritet Kræver synkronisering mellem task Eksempel: Aircraft Mission Processor 1-20 RISC processorer, MB RAM Soft Real Time krav, typisk i området fra 1 ms ms I/O Clock Task 1 Task 2 Output Manager I/O SW arkitektur, 24. januar

79 Pipeline arkitektur Pipeline Her anvendes også inter-proces meddelelser ud over afslutning af I/O operationer og timer events til at igangsætte ventende task En hændelse sendes gennem systemet fra source til destination og bevirker et sæt af task aktiveringer Eksempel: Air Traffic Control processorer, MB RAM Soft Real Time krav, typisk i området fra 100 ms - 6 sek Msg I/O Message Handler Task 2 Filter Output Manager I/O SW arkitektur, 24. januar

80 Client-server arkitektur Client-Server Som for pipeline anvendes også her inter-proces meddelelser ud over afslutning af I/O operationer og timer events til at igangsætte ventende task I modsætning til pipeline - så forbliver kontrollen her på en given node (klienten) Eksempel: Vehicle Training System processorer, MB RAM Soft Real Time krav, typisk i området fra 33 ms ms Msg I/O Message Handler Task 2 Filter Output Manager I/O SW arkitektur, 24. januar

81 To vigtige designprincipper SW arkitektur, 24. januar

82 To vigtige designprincipper Bertrand Meyers Open-Closed principle: Software entities (Classes, Modules, Functions etc) should be open for extension, but closed for modification Object Oriented Software Construction, B. Meyer, 1988 SW arkitektur, 24. januar

83 To vigtige designprincipper Bertrand Meyers Open-Closed principle: Software entities (Classes, Modules, Functions etc) should be open for extension, but closed for modification Object Oriented Software Construction, B. Meyer, 1988 Liskovs Substitution Principle (LSP): Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it (den pragmatiske udgave). Data Abstraction and Hierarchy, Barbara Liskov, SIGPLAN Notices, May 1988 SW arkitektur, 24. januar

84 To vigtige designprincipper Bertrand Meyers Open-Closed principle: Software entities (Classes, Modules, Functions etc) should be open for extension, but closed for modification Object Oriented Software Construction, B. Meyer, 1988 Liskovs Substitution Principle (LSP): Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it (den pragmatiske udgave). Data Abstraction and Hierarchy, Barbara Liskov, SIGPLAN Notices, May 1988 LSP anvendes til at realisere Open-Closed princippet. SW arkitektur, 24. januar

85 Proxy (stedfortræder) Pattern Client Watch settime() ProxyWatch RealWatch TestWatch settime() settime() settime() Objekter af RealWatch klassen befinder sig på en anden maskine end Client objektet. Et eksempel på en Remote Proxy - der kan karakterisers som et Architectural Pattern. SW arkitektur, 24. januar

86 Proxy objektdiagrammer Local processor Remote processor :Client settime() :TestWatch SW arkitektur, 24. januar

87 Proxy objektdiagrammer Local processor Remote processor :Client settime() :TestWatch :Client settime() :RealWatch SW arkitektur, 24. januar

88 Proxy objektdiagrammer Local processor Remote processor :Client settime() :TestWatch :Client settime() :RealWatch :Client settime() :ProxyWatch settime() :RealWatch SW arkitektur, 24. januar

89 Observer Pattern (push version) hour minute second Subject notify() addwatch(watch*) removewatch(watch*) * Watch destination gmtadjustment update(hour,min,sec) AtomControlledClock tick() DigitalWatch update(hour,min,sec) AnalogWatch update(hour,min,sec) SW arkitektur, 24. januar

90 Observer Pattern (push version) hour minute second Subject notify() addwatch(watch*) removewatch(watch*) * Watch destination gmtadjustment update(hour,min,sec) AtomControlledClock DigitalWatch update(hour,min,sec) AnalogWatch update(hour,min,sec) tick() pla= new AnalogWatch( Los Angeles,-8); AtomControlledClock::Instance().addWatch(pLA); pcph= new DigitalWatch( Copenhagen,+1); etc. SW arkitektur, 24. januar

91 Observer Pattern (push version) Subject hour min sec notify() addwatch(watch*) removewatch(watch*) * Watch destination gmtadjustment update(hour,min,sec) AtomControlledClock tick() DigitalWatch update(hour,min,sec) AnalogWatch update(hour,min,sec) læs tid fra modtagen meddelelse ind i hour, min, sec og kald notify() SW arkitektur, 24. januar

92 Observer Pattern (push version) Subject hour min sec notify() addwatch(watch*) removewatch(watch*) * Watch destination gmtadjustment update(hour,min,sec) AtomControlledClock tick() DigitalWatch update(hour,min,sec) AnalogWatch update(hour,min,sec) læs tid fra modtagen meddelelse ind i hour, min, sec og kald notify() notify() { for all in list pw->update(hour,min,sec); } SW arkitektur, 24. januar

93 Observer Pattern (push version) Subject hour min sec notify() addwatch(watch*) removewatch(watch*) * Watch destination gmtadjustment update(hour,min,sec) AtomControlledClock DigitalWatch update(hour,min,sec) AnalogWatch update(hour,min,sec) ProxyWatch update(hour,min,sec) tick() læs tid fra modtagen meddelelse ind i hour, min, sec og kald notify() notify() { for all in list pw->update(hour,min,sec); } SW arkitektur, 24. januar

94 Sekvensdiagram for Observer :AtomControlledClock pcph:digitalwatch pla:analogwatch :ProxyWatch SW arkitektur, 24. januar

95 Sekvensdiagram for Observer :AtomControlledClock pcph:digitalwatch pla:analogwatch :ProxyWatch tick SW arkitektur, 24. januar

96 Sekvensdiagram for Observer :AtomControlledClock pcph:digitalwatch pla:analogwatch :ProxyWatch tick notify() update(hour,min,sec) SW arkitektur, 24. januar

97 Sekvensdiagram for Observer :AtomControlledClock pcph:digitalwatch pla:analogwatch :ProxyWatch tick notify() update(hour,min,sec) update(hour,min,sec) SW arkitektur, 24. januar

98 Sekvensdiagram for Observer :AtomControlledClock pcph:digitalwatch pla:analogwatch :ProxyWatch tick notify() update(hour,min,sec) update(hour,min,sec) update(hour,min,sec) SW arkitektur, 24. januar

99 Frameworks SW arkitektur, 24. januar

100 Frameworks Frameworks opbygges med fordel vha. Design Patterns SW arkitektur, 24. januar

101 Frameworks Frameworks opbygges med fordel vha. Design Patterns Forskellige slags framework: Applikationsframework ofte til et specifikt domæne og udvikles til en hel produktfamilie Serviceorienterede frameworks som f.eks. Kommunikationsframework Databaseframework Multiprogrammeringsframework SW arkitektur, 24. januar

102 Frameworks Frameworks opbygges med fordel vha. Design Patterns Forskellige slags framework: Applikationsframework ofte til et specifikt domæne og udvikles til en hel produktfamilie Serviceorienterede frameworks som f.eks. Kommunikationsframework Databaseframework Multiprogrammeringsframework Disse kan være implementeret som: Whitebox framework Blackbox framework SW arkitektur, 24. januar

103 Whitebox Framework Her skal man kende den indre struktur for at kunne anvende Frameworket til en konkret applikation f.eks. ved at man tilføjer nye specialiserede klasser til de eksisterende klassehierarkier Applikationsspecifik kode SW arkitektur, 24. januar

104 Blackbox Framework Her er det ikke nødvendigt at kende detaljer i Frameworket, da man tilføjer den ønskede funktionalitet vha. Composition dvs. at man instantierer objekter, der hægtes på Frameworket obj3: Class3 obj1: Class1 Applikationsspecifik kode obj2: Class2 SW arkitektur, 24. januar

105 Eksempel: ATM protokol SW framework ATM: Asynkron Tranfer Mode ATM netværk Århus ATM forbindelse Bern ATM switche ATM projekt vedr. dynamisk oprettelse og nedlæggelse af ATM forbindelser (kaldes for signalisering). SW arkitektur, 24. januar

106 Eksempel: ATM protokol SW framework ATM: Asynkron Tranfer Mode ATM netværk Århus ATM forbindelse Bern ATM switche ATM projekt vedr. dynamisk oprettelse og nedlæggelse af ATM forbindelser (kaldes for signalisering). SW arkitektur, 24. januar

107 ATM protokol stak Call control Call control Lag 3 Q.2931/ ATM-Forum Q.2931/ ATM-Forum Lag 2 SSCF Q2130 SSCOP Q2110 PDU s SSCF Q2130 SSCOP Q2110 SAAL AAL5 lag AAL5 lag Lag 1 ATM lag ATM lag Fysisk lag Fysisk lag 53 bytes ATM pakker SW arkitektur, 24. januar

108 ATM protokol stak Call control Call control Framework Lag 3 Q.2931/ ATM-Forum Q.2931/ ATM-Forum anvendelser Lag 2 SSCF Q2130 SSCOP Q2110 PDU s SSCF Q2130 SSCOP Q2110 SAAL AAL5 lag AAL5 lag Lag 1 ATM lag ATM lag Fysisk lag Fysisk lag 53 bytes ATM pakker SW arkitektur, 24. januar

109 ATM protokol stak Call control 2 konkurerende standarder på lag 3 Call control Framework Lag 3 Q.2931/ ATM-Forum Q.2931/ ATM-Forum anvendelser Lag 2 SSCF Q2130 SSCOP Q2110 PDU s SSCF Q2130 SSCOP Q2110 SAAL AAL5 lag AAL5 lag Lag 1 ATM lag ATM lag Fysisk lag Fysisk lag 53 bytes ATM pakker SW arkitektur, 24. januar

110 Overordnet arkitektur beslutninger «Unix process» Lag 3 SW: OOFramework 1. Hvert lag er een process (Unix) 2. Der skal være en C grænseflade 3. Der kommunikeres en byte strøm mellem lagene C grænseflade «socket comm.» bytestream messages «Unix process» Lag 2 SW: OOFramework OOFramework (white box) bytestream messages SW arkitektur, 24. januar

111 System arkitektur User Application SW Signalling Software ATM lines Switch HW (ASIC) 650 Mbit/sek ATM lines SW arkitektur, 24. januar

112 System arkitektur User Application SW ATM: User plane Control plane Management plane Signalling Software ATM lines Switch HW (ASIC) 650 Mbit/sek ATM lines SW arkitektur, 24. januar

113 System arkitektur ATM: User plane Control plane Management plane User Application SW Signalling Software Diskret kontrol del Kontinueret behandlingsdel Diskret kontrol del Kontinueret behandlingsdel ATM lines Switch HW (ASIC) 650 Mbit/sek ATM lines SW arkitektur, 24. januar

114 Anvendelse af GoF design Patterns Frameworket er opbygget vha. følgende 8 GoF patterns: FactoryMethod (creational) Singleton (creational) Adapter (structural) Composite (structural) Strategy (behavioral) Visitor (behavioral) Command (behavioral) State (behavioral) Ref. [Gamma95] SW arkitektur, 24. januar

115 Centrale Design Patterns SW arkitektur, 24. januar

116 Centrale Design Patterns Af disse 8 patterns er følgende de centrale i Frameworket: SW arkitektur, 24. januar

117 Centrale Design Patterns Af disse 8 patterns er følgende de centrale i Frameworket: Composite (kaldt Mux og Conduite) benyttes til at opbygge selve protokolstrukturen SW arkitektur, 24. januar

118 Centrale Design Patterns Af disse 8 patterns er følgende de centrale i Frameworket: Composite (kaldt Mux og Conduite) benyttes til at opbygge selve protokolstrukturen Command (kaldt Messenger) Commandobjekter genereres ud fra modtagne meddelelser SW arkitektur, 24. januar

119 Centrale Design Patterns Af disse 8 patterns er følgende de centrale i Frameworket: Composite (kaldt Mux og Conduite) benyttes til at opbygge selve protokolstrukturen Command (kaldt Messenger) Commandobjekter genereres ud fra modtagne meddelelser Visitor transporterer et Commandobjekt gennem Composite strukturen SW arkitektur, 24. januar

120 Centrale Design Patterns Af disse 8 patterns er følgende de centrale i Frameworket: Composite (kaldt Mux og Conduite) benyttes til at opbygge selve protokolstrukturen Command (kaldt Messenger) Commandobjekter genereres ud fra modtagne meddelelser Visitor transporterer et Commandobjekt gennem Composite strukturen State implementerer protokollernes tilstandsmaskiner SW arkitektur, 24. januar

121 Grundstruktur i Frameworket Composite Pattern composite component 1-2 Conduit * connected to leaf composite ConduitFactory Protocol Adapter Mux SW arkitektur, 24. januar

122 Grundstruktur i Frameworket Composite Pattern composite component 1-2 Conduit * connected to leaf composite ConduitFactory Protocol Adapter Mux SscfProtocol SscopProtocol Specifik for den aktuelle anvendelse af Frameworket til lag 2 protokollen SW arkitektur, 24. januar

123 Framework objektdiagram :TopAdapter :IOController topmux: Mux assap1:ssapaccessor sscf1: SscfProtocol sscf-n: SscfProtocol Idle: SscfState1 sscop1: SscopProtocol sscopn: SscopProtocol Idle: SscopState1 bottommux: Mux assap2:ssapaccessor :BottomAdapter :IOController SW arkitektur, 24. januar

124 Framework objektdiagram :TopAdapter :IOController topmux: Mux assap1:ssapaccessor sscf1: SscfProtocol sscf-n: SscfProtocol Idle: SscfState1 sscop1: SscopProtocol sscopn: SscopProtocol Idle: SscopState1 bottommux: Mux assap2:ssapaccessor PDU :BottomAdapter :IOController modtages som en bytestream SW arkitektur, 24. januar

125 Framework objektdiagram :TopAdapter :IOController topmux: Mux assap1:ssapaccessor sscf1: SscfProtocol sscf-n: SscfProtocol Idle: SscfState1 sscop1: SscopProtocol sscopn: SscopProtocol Idle: SscopState1 bottommux: Mux assap2:ssapaccessor et MessageTransporter objekt (en visitor), der transporterer et Messenger objekt af den modtagne PDU type PDU :BottomAdapter :IOController modtages som en bytestream SW arkitektur, 24. januar

126 Framework objektdiagram :TopAdapter :IOController topmux: Mux assap1:ssapaccessor sscf1: SscfProtocol sscf-n: SscfProtocol Idle: SscfState1 sscop1: SscopProtocol sscopn: SscopProtocol Idle: SscopState1 bottommux: Mux assap2:ssapaccessor et MessageTransporter objekt (en visitor), der transporterer et Messenger objekt af den modtagne PDU type PDU :BottomAdapter :IOController modtages som en bytestream SW arkitektur, 24. januar

127 Framework objektdiagram :TopAdapter :IOController topmux: Mux assap1:ssapaccessor sscf1: SscfProtocol sscf-n: SscfProtocol Idle: SscfState1 sscop1: SscopProtocol sscopn: SscopProtocol Idle: SscopState1 bottommux: Mux assap2:ssapaccessor et MessageTransporter objekt (en visitor), der transporterer et Messenger objekt af den modtagne PDU type PDU :BottomAdapter :IOController modtages som en bytestream SW arkitektur, 24. januar

128 Framework objektdiagram :TopAdapter :IOController topmux: Mux assap1:ssapaccessor sscf1: SscfProtocol sscf-n: SscfProtocol Idle: SscfState1 sscop1: SscopProtocol sscopn: SscopProtocol Idle: SscopState1 bottommux: Mux assap2:ssapaccessor et MessageTransporter objekt (en visitor), der transporterer et Messenger objekt af den modtagne PDU type PDU :BottomAdapter :IOController modtages som en bytestream SW arkitektur, 24. januar

129 Framework objektdiagram :TopAdapter :IOController topmux: Mux assap1:ssapaccessor sscf1: SscfProtocol sscf-n: SscfProtocol Idle: SscfState1 sscop1: SscopProtocol sscopn: SscopProtocol Idle: SscopState1 bottommux: Mux assap2:ssapaccessor et MessageTransporter objekt (en visitor), der transporterer et Messenger objekt af den modtagne PDU type PDU :BottomAdapter :IOController modtages som en bytestream SW arkitektur, 24. januar

130 Framework objektdiagram :TopAdapter :IOController topmux: Mux assap1:ssapaccessor sscf1: SscfProtocol sscf-n: SscfProtocol Idle: SscfState1 sscop1: SscopProtocol sscopn: SscopProtocol Idle: SscopState1 bottommux: Mux assap2:ssapaccessor et MessageTransporter objekt (en visitor), der transporterer et Messenger objekt af den modtagne PDU type PDU :BottomAdapter :IOController modtages som en bytestream SW arkitektur, 24. januar

131 Framework objektdiagram :TopAdapter AAL primitiv :IOController topmux: Mux assap1:ssapaccessor sscf1: SscfProtocol sscf-n: SscfProtocol Idle: SscfState1 sscop1: SscopProtocol sscopn: SscopProtocol Idle: SscopState1 bottommux: Mux assap2:ssapaccessor et MessageTransporter objekt (en visitor), der transporterer et Messenger objekt af den modtagne PDU type PDU :BottomAdapter :IOController modtages som en bytestream SW arkitektur, 24. januar

132 Framework objektdiagram :TopAdapter AAL primitiv :IOController topmux: Mux assap1:ssapaccessor :SSAPConduitFactory sscf1: SscfProtocol sscf-n: SscfProtocol Idle: SscfState1 sscop1: SscopProtocol sscopn: SscopProtocol Idle: SscopState1 bottommux: Mux assap2:ssapaccessor et MessageTransporter objekt (en visitor), der transporterer et Messenger objekt af den modtagne PDU type PDU :BottomAdapter :IOController modtages som en bytestream SW arkitektur, 24. januar

133 Oprettelses scenario Oprettelse af protokolobjekter :TopAdapter topmux: Mux assap1:ssapaccessor :SSAPConduitFactory bottommux: Mux assap2:ssapaccessor :BottomAdapter SW arkitektur, 24. januar

134 Oprettelses scenario Oprettelse af protokolobjekter :TopAdapter topmux: Mux assap1:ssapaccessor :SSAPConduitFactory bottommux: Mux assap2:ssapaccessor :BottomAdapter 1. amt (MessageTransporter with an addprotocol) SW arkitektur, 24. januar

135 Oprettelses scenario Oprettelse af protokolobjekter :TopAdapter topmux: Mux assap1:ssapaccessor :SSAPConduitFactory 2. amt bottommux: Mux :BottomAdapter assap2:ssapaccessor 1. amt (MessageTransporter with an addprotocol) SW arkitektur, 24. januar

136 Oprettelses scenario Oprettelse af protokolobjekter :TopAdapter topmux: Mux assap1:ssapaccessor :SSAPConduitFactory 3. create sscf1: SscfProtocol sscop1: SscopProtocol 2. amt bottommux: Mux :BottomAdapter assap2:ssapaccessor 1. amt (MessageTransporter with an addprotocol) SW arkitektur, 24. januar

137 Oprettelses scenario Oprettelse af protokolobjekter :TopAdapter topmux: Mux assap1:ssapaccessor 4. aninstaller1 :SSAPConduitFactory 3. create 4. aninstaller2 2. amt sscf1: SscfProtocol sscop1: SscopProtocol bottommux: Mux :BottomAdapter assap2:ssapaccessor 1. amt (MessageTransporter with an addprotocol) SW arkitektur, 24. januar

138 Oprettelses scenario Oprettelse af protokolobjekter :TopAdapter topmux: Mux assap1:ssapaccessor 4. aninstaller1 5. :SSAPConduitFactory 3. create 4. aninstaller2 2. amt sscf1: SscfProtocol sscop1: SscopProtocol 5. bottommux: Mux :BottomAdapter assap2:ssapaccessor 1. amt (MessageTransporter with an addprotocol) SW arkitektur, 24. januar

139 Test af protokolsoftware Test script file test input og forventet output Test værktøj (interaktivt + file input) Test in/out file i/o fra/til overliggende lag Protocol SW (OO) der testes i/o fra/til underliggende lag Log file SW arkitektur, 24. januar

140 Test af protokolsoftware Test script file test input og forventet output Test værktøj (interaktivt + file input) Test in/out file i/o fra/til overliggende lag Protocol SW (OO) der testes Test resultat file Test merge program i/o fra/til underliggende lag Log file SW arkitektur, 24. januar

141 Test af protokolsoftware Test meddelelser behandles ligesom PDU meddelelserne, dvs. de transporteres af MessagTransporter visitoren indtil de behandles ved besøg af protokolobjekterne. Messenger upprotocol BeginMessenger upprotocol EndMessenger upprotocol TestMessenger upprotocol kan sætte protokol objekternes tilstand og bevirke at disse udskrives på en logfile SW arkitektur, 24. januar

142 Erfaring med anvendelse af et framework Fordele: Genbrug af basisklasser og struktur i Frameworket Genbrug af serviceklasser Kan opbygges vha. GoF design patterns (er veldokumenterede) Samme SW struktur for forskellige protokoller Letter dokumentation Letter vedligeholdelsen pga. færre klasser og samme struktur Muliggør en hurtigere protokolimplementering, da man kan koncentrere sig om det protokolspecifikke Fremmer inkrementel udvikling SW arkitektur, 24. januar

143 Framework erfaringer - fortsat Ulemper: Kræver indgående kendskab til Frameworket for at kunne genbruge dette til en ny protokol Frameworket bliver først stabilt efter mindst 2 implementeringer Senere ændringer til Framework strukturen bliver dyrere, da flere projekters SW skal tilpasses Kaldestrukturen er mere kompliceret og dermed sværere at teste og debugge SW arkitektur, 24. januar

144 Nyere arkitektur begreber Ref. [Shaw&Garlan96] SW arkitektur, 24. januar

145 Nyere arkitektur begreber En arkitektur kan generelt opbygges og beskrives vha. komponenter og konnektorer Ref. [Shaw&Garlan96] SW arkitektur, 24. januar

146 Nyere arkitektur begreber En arkitektur kan generelt opbygges og beskrives vha. komponenter og konnektorer I praksis fokuseres der næsten udelukkende på komponenter og for lidt på konnektorer: Der defineres grænseflader for komponenterne Komponenterne kan indeholde andre komponenter (vha. compositon) Der er brug for, at konnektorer også bliver første klasses designelementer på niveau med komponenter Ref. [Shaw&Garlan96] SW arkitektur, 24. januar

147 Nyere arkitektur begreber En arkitektur kan generelt opbygges og beskrives vha. komponenter og konnektorer I praksis fokuseres der næsten udelukkende på komponenter og for lidt på konnektorer: Der defineres grænseflader for komponenterne Komponenterne kan indeholde andre komponenter (vha. compositon) Der er brug for, at konnektorer også bliver første klasses designelementer på niveau med komponenter Der bør udvikles ADL s (Architecture Description Language) Ref. [Shaw&Garlan96] SW arkitektur, 24. januar

148 Architectural Language Element Component Connector Specification Type Unit of association Implementation Interface Component type Player Implementation Protocol Connector type Role Implementation Gross Structure of an Architectural Language Ref. [Shaw&Garlan96] SW arkitektur, 24. januar

149 Central design activity (Hofmeister) Ref. [Hofmeister2000] SW arkitektur, 24. januar

150 Central design activity (Hofmeister) 1. Define component and connector types Ref. [Hofmeister2000] SW arkitektur, 24. januar

151 Central design activity (Hofmeister) 1. Define component and connector types 2. Define how component and connector types interconnect Ref. [Hofmeister2000] SW arkitektur, 24. januar

152 Central design activity (Hofmeister) 1. Define component and connector types 2. Define how component and connector types interconnect 3. Map the system functionality to component and connectors concentrating functional behaviour in the components and control aspects in the connectors Ref. [Hofmeister2000] SW arkitektur, 24. januar

153 Central design activity (Hofmeister) 1. Define component and connector types 2. Define how component and connector types interconnect 3. Map the system functionality to component and connectors concentrating functional behaviour in the components and control aspects in the connectors 4. Define the instances of the component and connector types that exist in the product, and how they are interconnected Ref. [Hofmeister2000] SW arkitektur, 24. januar

154 UML Meta-model for conceptual architecture view - 1 Conceptual Configuration 1 1 * * CComponent CConnector During the conceptual configuration acitivity you define the relations among your components and connectors. Components and connectors are interconnected through their ports and roles. Ref. [Hofmeister2000] SW arkitektur, 24. januar

155 UML Meta-model for conceptual architecture view - 1 * 0..1 * CComponent * CConnector * * cbinding * * CPort * cconnection * * obeys Protocol * 1 1 * CRole * obeys conjugate * cbinding NB! klassediagrammet er suppleret med et sæt af constraints Ref. [Hofmeister2000] SW arkitektur, 24. januar

156 Definering af protokoller «ccomponent» Packetizer Protokollen definerer: Indgående og udgående meddelelsestype samt lovlige rækkefølger «cport» rawdatainput obeys «protocol» RawData SW arkitektur, 24. januar

157 Definering af protokoller «ccomponent» Packetizer Protokollen definerer: Indgående og udgående meddelelsestype samt lovlige rækkefølger «cport» rawdatainput obeys «protocol» RawData «protocol» RawData incoming dataready rawdata(rd) outgoing requestdata Packetizer dataready requestdata rawdata(rd) SW arkitektur, 24. januar

158 Eksempel: Components & Connectors :IS2000 probe Commands :Acquisition user AcqControl sender receiver :Control imagingcontrol acqcontrol probe Data :Imaging user AcqDisplay imagesout imagesin source :Data dest :Exporting user Image Export networkaccess SW arkitektur, 24. januar

159 UML diagram with stereotyped classes :IS2000 probe Commands :Acquisition user AcqControl Ports sender receiver :Control imagingcontrol acqcontrol Connector Components probe Data :Imaging user AcqDisplay imagesout imagesin Roles source :Data dest :Exporting user Image Export networkaccess SW arkitektur, 24. januar

160 Delopsummering vedr. connectorer, porte mm. Nogle af ideerne stammer fra ROOM metoden ( Real- Time Object-Oriented Modeling, af Bran Selic, G. Gullekson and Poul T. Ward, Wiley Implementeret først i det kommercielle værktøj ObjecTime, der idag er opkøbt af Rational og sælges som Rational Rose Real-Time. Begreberne og notationen kan defineres i UML vha. UML s udvidelsesmuligheder (stereotyper med brugerdefinerede ikoner). Ser ud til at være nyttige abstraktioner ved udvikling af realtidssystemer SW arkitektur, 24. januar

161 Views for arkitektur SW arkitektur, 24. januar

162 Views for arkitektur Der er her flere forskellige view modeller: Kruchten, 4+1 view model Hofmeister, 4 view model Nokia model, 3+1 view model SW arkitektur, 24. januar

163 Views for arkitektur Der er her flere forskellige view modeller: Kruchten, 4+1 view model Hofmeister, 4 view model Nokia model, 3+1 view model Alle er enige om at det er nyttigt at have flere views, hvor hvert view har forskelligt indhold og forskellige interessenter SW arkitektur, 24. januar