modeling sw-architectures using uml-rt/uml 2 · uml2 notation. february 26, 2007 ©ingolf h....
TRANSCRIPT
California Institute for Telecommunications and Information TechnologiesLa Jolla, CA 92093-0405, USA
Department of Computer Science & EngineeringUniversity of California, San DiegoLa Jolla, CA 92093-0114, USA
Modeling SW-Architectures using UML-RT/UML 2.0
Ingolf H. [email protected]
© Ingolf H. Krueger 2February 26, 2007 CSE
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 3February 26, 2007 CSE
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 4February 26, 2007 CSE
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 5February 26, 2007 CSE
• Examples of “profiles” of the UML:
– embedded real-time systems (“UML-RT”)
– automotive
– web applications
– ...
• Origin: ROOM [SGW94] + UML
• 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)
What is UML-RT?
Read: UML with component notion
© Ingolf H. Krueger 6February 26, 2007 CSE
behaviorstructure
The Component Model of UML-RT
Description Techniques of UML-RT for Structure and Behavior
capsules
ports
connectors
UML-statecharts
MSCs
© Ingolf H. Krueger 7February 26, 2007 CSE
Hierarchical Composition in UML-RT
«capsule»:CLS
«capsule»lm:Motor«capsule»rm:Motor
«capsule»lm:Motor
«capsule»:CommandSource
«capsule»:CommandHandler
«capsule»:MotorControl
Port
• concrete realization of an interface by means of an object
• equipped with a protocol
• list of incoming/outgoing messages/signals
• (signal flow)
• the aid for “encapsulation” and “separation of concerns”
Connector
• communication link between ports
• “drives” protocolCapsule
• active object or “passive” container
• communication with the environment
• signal-based (asynchronous message exchange)
• exclusively via interface objects (ports)
• supports hierarchical composition
© Ingolf H. Krueger 8February 26, 2007 CSE
«capsule»:CLS
«capsule»:CommandHandler
«capsule»:MotorControl
l rh
Example:UML-statecharts
UNLD
wldh.lock/l.downl.ready/r.down
wrd
LCKD
r.ready/h.done
wru wlur.ready/h.done
l.ready/r.up
h.unlock/l.up
© Ingolf H. Krueger 9February 26, 2007 CSE
Signal-Based Communication
• Capsules receive and send signals via their ports
• Signals, which cannot be processed immediately, are stored in a queue
downreadydownready
«capsule»:CLS
«capsule»:CommandHandler
«capsule»:MotorControl
lock unlock lock�
© Ingolf H. Krueger 10February 26, 2007 CSE
Signalbasierte Kommunikation
• Capsules receive and send signals via their ports
• Signals, which cannot be processed immediately, are stored in a queue
«capsule»:CLS
«capsule»:CommandHandler
«capsule»:MotorControl
unlock lock
© Ingolf H. Krueger 11February 26, 2007 CSE
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 12February 26, 2007 CSE
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 13February 26, 2007 CSE
Capsules
• Upon its instantiation a capsule builds its internal structure (subcapsules)
• The capsule can change its internal structure over time
⇒ Architectural integrity
«capsule»CLS
ports
cp : CommandHandler
mp[2] : Initiator
Capsule
Name of Capsule
Port Name
Protocol Role
© Ingolf H. Krueger 14February 26, 2007 CSE
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 15February 26, 2007 CSE
Ports and Connectors
• Port
– 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 16February 26, 2007 CSE
Ports and Konnektoren
«capsule»CLS
ports
cp : CommandProtocol.Handler;
mp[2] : MotorProtocol.Initiator;
Simplified Representation
Protocol-Role(qualified with protocol name)
Port Name
© Ingolf H. Krueger 17February 26, 2007 CSE
Ports and Connectors
Simplified Representation in Collaboration Diagrams
«capsule»:CLS
«capsule»lm:Motor«capsule»rm:Motor
«capsule»lm:Motor
«capsule»:CommandSource
mp[1]:MotorProtocol.Initiator
mp[2]:MotorProtocol.Initiator
cp:CommandProtocol.Handler
Port Symbol
Port Name and Protocol-Role
© Ingolf H. Krueger 18February 26, 2007 CSE
Ports and Connectors
«capsule»:CLS
«capsule»lm:Motor«capsule»rm:Motor
«capsule»lm:Motor
«capsule»:CommandHandler
«capsule»:MotorControl
End-Port
Relay-PortRelay-Port
© Ingolf H. Krueger 19February 26, 2007 CSE
UML2 Notation
© Ingolf H. Krueger 20February 26, 2007 CSE
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 21February 26, 2007 CSE
Protocols
ReceiverRoleSenderRole
req_start
ack_start
data
data
req_end
ack_data
ack_data
ack_end
Example: Simple Communication Protocol
© Ingolf H. Krueger 22February 26, 2007 CSE
Protocols
Example: Simple Communication Protocol
«protocolRole»SenderRole
incoming
ack_startack_dataack_end
outgoing
req_startdata
req_end
«protocolRole»ReceiverRole
incoming
req_startdata
req_end
outgoing
ack_startack_dataack_end
req_start
ack_start
data
data
req_end
ack_data
ack_data
ack_end
ReceiverRoleSenderRole
© Ingolf H. Krueger 23February 26, 2007 CSE
«protocolRole»ReceiverRole
incoming
req_startdata
req_end
outgoing
ack_startack_dataack_end
Protokols
Example: Simple Communication Protocol
«protocolRole»SenderRole
incoming
ack_startack_dataack_end
outgoing
req_startdata
req_end
“Conjugated” sender role
«protocolRole»ReceiverRole
incoming
req_startdata
req_end
outgoing
ack_startack_dataack_end
© Ingolf H. Krueger 24February 26, 2007 CSE
Protocols
Simplification for Point-to-Point Protocols
«protocol»Transmission
incoming
ack_startack_dataack_end
outgoing
req_startdata
req_end
Base Role for Protocol(Sender View)
«capsule»Receiver
«capsule»Sender
rp:Transmission~
sp:Transmission
Base Role
Conjugated (Inverse) Role
© Ingolf H. Krueger 25February 26, 2007 CSE
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 26February 26, 2007 CSE
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 27February 26, 2007 CSE
Behavior Description in UML-RT
Doing without AND-states
• Concurrency via separate capsules
• Synchronization via explicit communication
• Result: stronger decoupling
© Ingolf H. Krueger 28February 26, 2007 CSE
Behavior Description in UML-RT
Encapsulation on the Level of States
/a2e1/a1
exit/ax
/a3
entry/ae
Chain State
• States become exchangeable entities
• Helps avoid “stub states”
e1/a1
exit/ax
© Ingolf H. Krueger 29February 26, 2007 CSE
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 30February 26, 2007 CSE
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 31February 26, 2007 CSE
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 32February 26, 2007 CSE
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 33February 26, 2007 CSE
MachineTools
• process workpieces
• post jobs to be processed (“deliver workpiece”)
• negotiate with Holons via broadcasting
Example Application: Autonomous Transport System
InStorage
• holds workpieces yet to be processed
Holons
• carry workpieces between source and destination
• negotiate with OutStorage and Machinetoolsfor jobs
• hold internal database representing the system’s status
OutStorage
• holds workpieces after processing
• holds “production plan/program”(number/kind of workpieces to be processed per day)
© Ingolf H. Krueger 34February 26, 2007 CSE
Example Application: Autonomous Transport System
Architectural Aspects:
MachineTool1 MachineTool2 MachineTool3
Holon1
InStorage OutStorage
Holon2 Holon3
• components • p2p communication
• broadcasting• interfaces/behavior
• hierarchy/decomposition
DB
Control
Dispo
© Ingolf H. Krueger 35February 26, 2007 CSE
CommunicationSystem
HTS
Domain Model
Workpiece
Storage
MachineTool
*Status
1
1
1
Location
0..1
2
0..1
*
0..1
*
0..1
Database1
Job1 *
*
1
0..1
*
ProdProg
1
*
1
1
OutStorageInStorage
CommunicationSystem
*
1
11
© Ingolf H. Krueger 36February 26, 2007 CSE
ProdSys
BroadcastSystem
n
HTS
n
MachineTool
InStorage
OutStorage
BroadcastSystem
Architectural Pattern for Broadcasting
HTS_IOSystem
Disponent Database
HTS
SingleJobControl
© Ingolf H. Krueger 37February 26, 2007 CSE
Sequence Charts for Broadcasting
m:MachineTool h:HTS l:HTS
requestWP()
releaseWP()
drive tolocation 1
jTransporting(jobno)
updateJobStatus()
updateJobStatus()
time
component axis
signal exchange
local action
broadcasting
© Ingolf H. Krueger 38February 26, 2007 CSE
Sequence Charts for Broadcasting
m:MachineTool h:HTS l:HTS
compute bid
waitingwaiting
compute bid
store job
waitingwaiting
jOrder(jobno)
jBid(jobno, h)
jBid(jobno, l)
jEndOfNegotiation(jobno)
state label
© Ingolf H. Krueger 39February 26, 2007 CSE
ProdSys
Derivation of Component Structure
BroadcastSystem
n
HTS
n
MachineTool
InStorage
OutStorage
Captured scenarios & domain model indicate:
BroadcastSystem
• active vs. passive components
• Point-to-point communication requirements
• broadcasting requirements
© Ingolf H. Krueger 40February 26, 2007 CSE
Derivation of Interface Behavior
Captured scenarios indicate also:
n
HTS
• names and types of signals
• ordering of signal flow
m:MachineTool h:HTS l:HTS
requestWP()
releaseWP()
drive tolocation 1
jTransporting(jobno)
updateJobStatus()
updateJobStatus()
m:MachineTool h:HTS l:HTS
compute bid
waitingwaiting
compute bid
store job
waitingwaiting
jOrder(jobno)
jBid(jobno, h)
jBid(jobno, l)
jEndOfNegotiation(jobno)
© Ingolf H. Krueger 41February 26, 2007 CSE
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 42February 26, 2007 CSE
• 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?
Summary and Outlook
© Ingolf H. Krueger 43February 26, 2007 CSE