Modeling Real-Time System Architectures with UML 2.0

Transcription

1 Modeling Real-Time System Architectures with UML 2.0 Bran Selic Principal Engineer IBM Software Group Rational Software Objectives Define architecture and its role in software design Identify requirements for modeling software architectures Describe how UML 2 and MDA can be used for modeling software architectures of embedded systems 2 1

2 A Parable Lisle, Illinois: ring road Lab Building Architectural decay, caused by: Lack of high-level (architectural) view ( the forest vs the trees ) Difficulties in enforcing architectural decisions 3 Presentation Overview Software architecture and its role Requirements for architectural modeling The role of UML 2 and MDA in architectural modeling Example system Architectural patterns for embedded software 4 2

3 (Run-Time) Architecture An abstract view of a system that identifies only the important elements and relationships We will focus only on run-time architectures: The run-time organization of significant software components interacting through interfaces, those components being composed of successively smaller components and interfaces 5 Why Architecture is Important Enables communication between stakeholders exposes how individual requirements are handled Drives system construction decomposition into units of responsibility and parallel development Determines a system s capacity for evolutionary growth A X A X Mediator B C B C 6 3

4 Presentation Overview Software architecture and its role Requirements for architectural modeling The role of UML 2 and MDA in architectural modeling Example system Architectural patterns for embedded software 7 Example Complex Architecture Spec Example telecom system architecture Structure Channel1 TerminalA TerminalB Application Layer Channel2 Services Layer Behavior 8 4

5 Basic Run-Time Architectural Patterns Peer-to-peer communication: PartA PartB Containment: Container Container Part Part composition (existence dependency) Layering Layer N+1 Layer N aggregation (information hiding) 9 Architectural Component Design Library Channel1 System1 Terminal TerminalA TerminalB Channel Channel2 Terminal Tester TerminalA System2 Terminal Tester 10 5

6 Refining Architectures (Reuse) Channel1 TerminalA TerminalB Channel1 TerminalA TerminalB Channel2 11 Architectural Decay The (usually) gradual divergence between an architectural model and its corresponding program implementation Caused by: Misunderstandings of architectural intent Design disagreements Implementation (coding) errors Lab Building Often occurs during low-level maintenance work 12 6

7 Summary of Requirements Need the ability to specify software architectural patterns in a direct and and expressive way Need to provide reuse of architectural-level components Need to prevent architectural decay 13 Presentation Overview Software architecture and its role Requirements for architectural modeling The role of UML 2 and MDA in architectural modeling Example system Architectural patterns for embedded software 14 7

8 UML 2.0 and Architectural Modeling UML 2.0 adds two fundamental capabilities for modeling software architectures Structured classes for modeling structural aspects: - parts, ports, and connectors - reusable architectural components (Complex) interactions for modeling behavior sender receiver Call loop AckCall (parms) XRparms(parms) Data AckData Hangup AckHangup FaxCall c c sender:fax receiver:fax remote remote 15 What About Architectural Decay? Ensure visibility and enforcement of architectural intent Achieved by: Requiring that all design work to take place at the model level Automatically generating implementations directly from models i.e., use model-driven development 16 8

9 Structured Object Semantics Run-time assertion: the complete internal structure of a composite is automatically created (recursively, if necessary) when the object is created f1 := create(faxcall); sender:fax receiver:fax f1:faxcall 17 Benefits of Run-Time Assertion Architectural enforcement: only explicitly prescribed architectural structures can be instantiated it is not possible to bypass (corrupt) the architecture by lowlevel programming Simplification: low-level program code that dynamically creates (destroys) components and the connections between them is eliminated in some systems this can be as much as 35% of all code Major net gain in productivity and reliability 18 9

10 Summary: UML as an ADL UML 2.0 seems to have the necessary level of expressive power to specify software architectures directly (= architectural description language) By supporting the class/object paradigm at the architectural level it enables definition of reusable architectural components Combined with Model-Driven Development (MDD) methods, it can also ensure architectural enforcement 19 Presentation Overview Software architecture and its role Requirements for architectural modeling The role of UML 2 and MDA in architectural modeling Example system Architectural patterns for embedded software 20 10

11 Design Patterns A design pattern is a proven generalized solution to a generalized problem that can be used to derive a specific solution to a specific problem Represent distilled reusable experience Major benefits of using patterns: Simplify and speed-up design Reduce risk Facilitate communications between designers 21 Example System A multi-line packet switch that uses the alternating-bit protocol as its link protocol End user AB sender AB protocol End user End user line card 1... AB receiver line card N unreliable transmission medium AB receiver AB sender SWITCH 22 11

12 Alternating Bit Protocol (1) A simple one-way point-to-point packet protocol packetizer Sender Receiver unpacker data(1) pkta data(1) AB protocol ack data(2) ack acka pktb ackb etc. ack data(2) ack 23 Alternating Bit Protocol (2) State machine specification Sender SM AcceptPktA Receiver SM RcvdPktA data/^pkta timeout/^pktb ackb/^ack ack/^acka timeout/^ackb pkta/^data WaitAckA WaitAckB WaitPktB WaitPktA timeout/^pkta timeout/^acka acka/^ack data/^pktb pktb/^data ack/^ackb AcceptPktB RcvdPktB 24 12

13 Additional Considerations Support infrastructure AB receiver AB sender AB lines manager SWITCH operator interface DB interface System operator DBase 25 Control The set of (additional) mechanisms and actions required to bring a system into the desired operational state and to maintain it in that state in the face of various planned and unplanned disruptions For software systems this includes: system/component start-up and shut-down failure detection/reporting/recovery system administration, maintenance, and provisioning (on-line) software upgrade 26 13

14 Retrofitting Control Behavior JustCreated GettingData Hardware Audit ReadyToGo Analysing Failure AcceptPktA Failed WaitAckA WaitAckB AcceptPktB 27 The Control Automaton In isolation, the same control behavior appears much simpler JustCreated GettingData Hardware Audit Analysing Failure ReadyToGo Failed Operational 28 14

15 Control versus Function Control behavior is often treated in an ad hoc manner, since it is not part of the primary system functionality typically retrofitted into the framework optimized for the functional behavior leads to controllability and stability problems However, in highly-dependable systems as much as 80% of the system code is dedicated to control behavior! 29 Some Important Observations Control predicates function before a system can perform its primary function, it first has to reach its operational state Control behavior is often independent of functional behavior the process by which a system reaches its operational state is often the same regardless of the specific functionality of the component 30 15

16 Presentation Overview Software architecture and its role Requirements for architectural modeling The role of UML 2 and MDA in architectural modeling Example system Architectural patterns for embedded software 31 The Recursive Control Architectural Pattern 32 16

17 Basic Design Principles Separate control from function separate control components from functional components separate control interfaces from functional interfaces imbed functional behavior within control behavior Centralize control (decision making) if possible, focus control in one component place control policies in the control components and control mechanisms inside the controlled components 33 The Basic Structural Pattern Set of components that need to be controlled in a coordinated fashion Control interface Central Controller Controlled Controlled... Component 1 Component N Functional (service) interface 34 17

18 Hierarchical control Recursive Application scales up to arbitrary number of levels Central Controller Central Controller Central Controller Controlled Component 1... Controlled Component N... Controlled Component 1... Controlled Component N 35 Behavior Ports Ports directly connected to the state machine Implementation Behavior Port c : SystemControl Behavior Port container state machine senderctrl : Control~ receivectrl : Control~ initial connecting c : Control connected c : Control sender:fax receiver:fax 36 18

19 Realization with Ports and Objects Composite plays role of centralized controller CompSet JustCreated GettingData Hardware Audit ReadyToGo Analysing Failure Failed c1:comp1 Operational cn:compn 37 Exploiting Inheritance Abstract control classes can capture common control behavior and structure Different subclasses capture function-specific behavior AbstractControllee ports controlport: CtrlProtocol Sender Receiver

20 Exploiting Hierarchical States JustCreated GettingData Hardware Audit Analysing Failure Failed AbstractControllee ports controlport: CtrlProtocol Sender ReadyToGo Operational 39 The Run-Time Layering Architectural Pattern 40 20

21 Semantics of Layering (1) A fundamentally different type of structural relationship AB sender operator interface Operating System Layering is different from containment Higher-layers do not contain lower layers Formally, the lower layers contain the higher layers (existence dependency) but they do not encapsulate them 41 Semantics of Layering (2) In complex systems, layering is a complex multidimensional relationship e.g., 7-layer model of Open System Interconnection (OSI) Level 7 Level 6 Level 5 Level 4 Network Link Hardware Operating System 42 21

22 Inadequate Representations of Layering Staircase model Toaster model Application Specialized Services General Services Operating System 43 More on the OSI Model Two distinct kinds of interfaces: peer and SAP Public Interface Layer N + 1 Public or Private Interface? Layer N + 1 SAP Layer N 44 22

23 Implementation Components Private sub-components required to realize the functionality offered by component through its public interface Internal implementation component External implementation component A B C D AB sender operator interface Timing Service 45 Usage Interface Interface Types for Layering Need to differentiate two interface types: Usage interface: implementation-independent interface through which a component provides its services (function and control) Implementation interface (service access point): implementation-specific interface through which a component accesses an external service Front-end/back-end views: Implementation Interface 46 23

24 Implementation Interfaces Implementation interfaces are public interfaces but can be viewed as being in a different plane (dimension) from service interfaces A B C D AB sender operator interface 90 o Timing Service 47 Modeling Layers with Ports and Objects Implementation interfaces are modeled by implementation end ports that can be connected directly to service ports of other objects Service access point UpperLayer InternalComp TimingService 48 24

25 Summary: Architectural Patterns Architecture plays a fundamental role in software design and evolution To prevent architectural decay we need to Specify architectures directly, clearly, and easily Enforce architectural specifications The combination of UML 2 and MDA enables us to meet these objectives We have demonstrated this ability by showing how these concepts can be used to model two high-level architectural patterns common in embedded system design 49 25