Modeling SW-Architectures using UML-RT/UML 2.0

Transcription

1 Modeling SW-Architectures using UML-RT/UML 2.0 Ingolf H. Krueger Department of Computer Science & Engineering University of California, San Diego La Jolla, CA , USA California Institute for Telecommunications and Information Technologies La Jolla, CA , USA

2 Overview UML: Good Enough for Specifying Architectures? UML-RT/UML 2.0 Overview Capsules Ports and Connectors Protocols Behavior Description Evaluation Example: Autononomous Transport System Summary and Outlook Ingolf H. Krueger CSE 2

3 Is the UML Good Enough? The UML offers a plethora of description techniques for many aspects of software architectures The UML has, however, also significant deficits especially when it comes to modeling complex, service-oriented systems! In particular, we miss: An adequate notation for services A non-technical component notion Clear concepts for hierarchy Strong concepts and description techniques for logical component distribution non-technical interfaces Formal means for behavior descriptions with respect to interfaces Ingolf H. Krueger CSE 3

4 Overview UML: Good Enough for Specifying Architectures? UML-RT/UML 2.0 Overview Capsules Ports and Connectors Protocols Behavior Description Evaluation Example: Autononomous Transport System Summary and Outlook Ingolf H. Krueger CSE 4

5 Examples of profiles of the UML: embedded real-time systems ( UML-RT ) automotive web applications... What is UML-RT? Origin: ROOM [SGW94] + UML Read: UML with component notion Focus of UML-RT/ROOM: component-oriented development all components are potentially active units signal-/message-oriented communication time concept quality of service (in preparation) Ingolf H. Krueger CSE 5

6 The Component Model of UML-RT Description Techniques of UML-RT for Structure and Behavior capsules UML-statecharts ports MSCs connectors structure behavior Ingolf H. Krueger CSE 6

7 Hierarchical Composition in UML-RT Port Capsule Connector :CommandSource communication link between ports drives protocol concrete active object realization or passive of an container interface by means of an object communication equipped with a with protocol the environment list signal-based of incoming/outgoing (asynchronous messages/signals :CLSexchange) (signal exclusively flow) via interface objects (ports) the supports aid for hierarchical encapsulation composition and :CommandHandler separation of concerns lm:motor :MotorControl rm:motor lm:motor Ingolf H. Krueger CSE 7

8 Example:UML-statecharts h.lock/l.down wld l.ready/r.down wrd r.ready/h.done UNLD LCKD r.ready/h.done wru l.ready/r.up :CLS wlu :CommandHandler h.unlock/l.up l h :MotorControl r Ingolf H. Krueger CSE 8

9 Signal-Based Communication Capsules receive and send signals via their ports Signals, which cannot be processed immediately, are stored in a queue :CLS lock unlock lock :CommandHandler down ready :MotorControl ready down Ingolf H. Krueger CSE 9

10 Signalbasierte Kommunikation Capsules receive and send signals via their ports Signals, which cannot be processed immediately, are stored in a queue :CLS :CommandHandler unlock lock :MotorControl Ingolf H. Krueger CSE 10

11 Overview UML: Good Enough for Specifying Architectures? UML-RT/UML 2.0 Overview Capsules Ports and Connectors Protocols Behavior Description Evaluation Example: Autononomous Transport System Summary and Outlook Ingolf H. Krueger CSE 11

12 Capsules Every capsule represents a potentially active object Communication between capsule and environment: exclusively via ports no public data no public methods Hierarchical decomposition into subcapsules Every capsule has (at most) one state automaton describing the capsule s behavior capsule is controller for its subcapsules see architectural pattern recursive control Ingolf H. Krueger CSE 12

13 Capsules Upon its instantiation a capsule builds its internal structure (subcapsules) The capsule can change its internal structure over time Architectural integrity Name of Capsule Capsule CLS Port Name ports cp : CommandHandler mp[2] : Initiator Protocol Role Ingolf H. Krueger CSE 13

14 Overview UML: Good Enough for Specifying Architectures? UML-RT/UML 2.0 Overview Capsules Ports and Connectors Protocols Behavior Description Evaluation Example: Autononomous Transport System Summary and Outlook Ingolf H. Krueger CSE 14

15 Port Ports and Connectors belongs to precisely one capsule (the capsule creates and destroys its ports) has identity and state has behavior implements the role of its capsule in a protocol Kinds of ports Relay-Ports relay signals between capsuels and their subcapsules controlled interface export End-Ports relay signals between capsules and their state automata have queues for signals already received, but not yet processed Ingolf H. Krueger CSE 15

16 Ports and Konnektoren Simplified Representation Port Name CLS ports cp : CommandProtocol.Handler; mp[2] : MotorProtocol.Initiator; Protocol-Role (qualified with protocol name) Ingolf H. Krueger CSE 16

17 Ports and Connectors Simplified Representation in Collaboration Diagrams :CommandSource Port Symbol cp:commandprotocol.handler lm:motor mp[1]: MotorProtocol.Initiator :CLS mp[2]: MotorProtocol.Initiator rm:motor lm:motor Port Name and Protocol-Role Ingolf H. Krueger CSE 17

18 Ports and Connectors End-Port Relay-Port Relay-Port :CLS :CommandHandler lm:motor :MotorControl rm:motor lm:motor Ingolf H. Krueger CSE 18

19 UML2 Notation Ingolf H. Krueger CSE 19

20 Overview UML: Good Enough for Specifying Architectures? UML-RT/UML 2.0 Overview Capsules Ports and Connectors Protocols Behavior Description Evaluation Example: Autononomous Transport System Summary and Outlook Ingolf H. Krueger CSE 20

21 Protocols Example: Simple Communication Protocol SenderRole ReceiverRole req_start ack_start data ack_data data ack_data req_end ack_end Ingolf H. Krueger CSE 21

22 Protocols Example: Simple Communication Protocol «protocolrole» SenderRole incoming ack_start ack_data ack_end outgoing req_start data req_end SenderRole ReceiverRole req_start ack_start data ack_data data ack_data req_end ack_end «protocolrole» ReceiverRole incoming req_start data req_end outgoing ack_start ack_data ack_end Ingolf H. Krueger CSE 22

23 Protokols Example: Simple Communication Protocol «protocolrole» SenderRole incoming ack_start ack_data ack_end outgoing req_start data req_end «protocolrole» ReceiverRole incoming req_start data req_end outgoing ack_start ack_data ack_end Conjugated sender role Ingolf H. Krueger CSE 23

24 Protocols Simplification for Point-to-Point Protocols «protocol» Transmission incoming ack_start ack_data ack_end outgoing req_start data req_end Base Role Base Role for Protocol (Sender View) Sender sp: Transmission Receiver rp: Transmission~ Conjugated (Inverse) Role Ingolf H. Krueger CSE 24

25 Overview UML: Good Enough for Specifying Architectures? UML-RT/UML 2.0 Overview Capsules Ports and Connectors Protocols Behavior Description Evaluation Example: Autononomous Transport System Summary and Outlook Ingolf H. Krueger CSE 25

26 Behavior Description in UML-RT Every capsule that has its own behavior is associated with a UML-statechart Max one statechart per capsule Hierarchical composition: every sub-capsule can have its own statechart Ingolf H. Krueger CSE 26

27 Behavior Description in UML-RT Doing without AND-states Concurrency via separate capsules Synchronization via explicit communication Result: stronger decoupling Ingolf H. Krueger CSE 27

28 Behavior Description in UML-RT Encapsulation on the Level of States Chain State entry/ae e1/a1 /a2 /a3 exit/ax States become exchangeable entities Helps avoid stub states Ingolf H. Krueger CSE 28

29 Overview UML: Good Enough for Specifying Architectures? UML-RT/UML 2.0 Overview Capsules Ports and Connectors Protocols Behavior Description Evaluation Example: Autononomous Transport System Summary and Outlook Ingolf H. Krueger CSE 29

30 Evaluation UML-RT is much better suited for the specification of software architectures and services than pure UML: hierarchic component model, precise behavior descriptions interface concept protocols and connectors Potentials for improvement (among others): m2m communication instead of p2p association of interaction patterns with ports/connectors methodological guidelines for iterative service development Future: (methodological!) treatment of Quality-of-Service aspects Ingolf H. Krueger CSE 30

31 Overview UML: Good Enough for Specifying Architectures? UML-RT/UML 2.0 Overview Capsules Ports and Connectors Protocols Behavior Description Evaluation Example: Autononomous Transport System Summary and Outlook Ingolf H. Krueger CSE 31

32 Systematic Construction of Reliable SW-Systems 1. Develop/Refine domain model 2. Capture interaction patterns 3. Derive interface specification messages/signals, types behavior 4. Decompose components hierarchically Ingolf H. Krueger CSE 32

33 Example Application: Autonomous Transport System Holons carry workpieces between source and destination InStorage OutStorage holds workpieces negotiate yet holds to with be workpieces OutStorage processedafter and processing Machinetools for jobs holds production plan/program hold internal (number/kind database of representing workpieces the to be system s MachineTools processed status per day) process workpieces post jobs to be processed ( deliver workpiece ) negotiate with Holons via broadcasting Ingolf H. Krueger CSE 33

34 Example Application: Autonomous Transport System Architectural Aspects: MachineTool1 MachineTool2 MachineTool3 Holon1 Dispo Control Holon2 Holon3 DB InStorage OutStorage components interfaces/behavior hierarchy/decomposition p2p communication broadcasting Ingolf H. Krueger CSE 34

35 Domain Model Status 1 * 0..1 MachineTool * * Workpiece Job * Location * * * * Database HTS Storage 1 1 ProdProg 1 InStorage OutStorage 1 1 CommunicationSystem 1 Ingolf H. Krueger CSE 35

36 Architectural Pattern for Broadcasting HTS Disponent Database SingleJobControl HTS_IOSystem ProdSys InStorage HTS n MachineTool n OutStorage BroadcastSystem Ingolf H. Krueger CSE 36

37 Sequence Charts for Broadcasting time component axis local action m:machinetool h:hts l:hts requestwp() releasewp() drive to location 1 signal exchange jtransporting(jobno) update JobStatus() update JobStatus() broadcasting Ingolf H. Krueger CSE 37

38 Sequence Charts for Broadcasting state label m:machinetool h:hts l:hts jorder(jobno) waiting waiting jbid(jobno, h) compute bid compute bid jbid(jobno, l) jendofnegotiation(jobno) store job waiting waiting Ingolf H. Krueger CSE 38

39 ProdSys Derivation of Component Structure Captured scenarios & domain model indicate: active vs. passive components Point-to-point communication requirements broadcasting requirements InStorage HTS n MachineTool n OutStorage BroadcastSystem Ingolf H. Krueger CSE 39

40 Derivation of Interface Behavior Captured scenarios indicate also: names and types of signals ordering of signal flow m:machinetool h:hts l:hts drive to m:machinetoollocation 1 requestwp() h:hts l:hts waiting releasewp() jorder(jobno) jtransporting(jobno) compute bid jbid(jobno, h) update JobStatus() jendofnegotiation(jobno) waiting compute bid update JobStatus() jbid(jobno, l) HTS n store job waiting waiting Ingolf H. Krueger CSE 40

41 Overview UML: Good Enough for Specifying Architectures? UML-RT/UML 2.0 Overview Capsules Ports and Connectors Protocols Behavior Description Evaluation Example: Autononomous Transport System Summary and Outlook Ingolf H. Krueger CSE 41

42 Summary and Outlook Modeling in the real world : often if at all done using UML/UML-RT/UML 2.0 UML-RT/UML 2.0 better equipped for modeling software architectures than UML versions < 2.0 Starting point for component- and service-oriented development: domain model, interaction scenarios How to avoid over-modeling and over-engineering? Ingolf H. Krueger CSE 42

43 Ingolf H. Krueger CSE 43