A UML Profile for Modeling Complex A UML Profile for Modeling - - PowerPoint PPT Presentation

a uml profile for modeling complex a uml profile for
SMART_READER_LITE
LIVE PREVIEW

A UML Profile for Modeling Complex A UML Profile for Modeling - - PowerPoint PPT Presentation

A UML Profile for Modeling Complex A UML Profile for Modeling Complex Real-Time Architectures Real-Time Architectures Bran Selic Bran Selic Rational Software Inc. Rational Software Inc. bselic@rational.com bselic@rational.com Overview


slide-1
SLIDE 1

A UML Profile for Modeling Complex Real-Time Architectures A UML Profile for Modeling Complex Real-Time Architectures

Bran Selic Rational Software Inc. bselic@rational.com Bran Selic Rational Software Inc. bselic@rational.com

slide-2
SLIDE 2

Overview Overview

! Complex real-time systems ! Requirements for modeling real-time system architectures ! Architectural modeling constructs in UML ! Summary ! Complex real-time systems ! Requirements for modeling real-time system architectures ! Architectural modeling constructs in UML ! Summary

slide-3
SLIDE 3

Complex Real-Time Systems Complex Real-Time Systems

! Complex real-time systems characterized by:

" extreme dependability (reliability, availability) " diverse and feature-rich functionality " continuous feature upgrades (evolutionary requirements) " physical distribution

! Encountered mostly in telecom (e-business infrastructure and internet access devices), defense, aerospace, and industrial control ! Complex real-time systems characterized by:

" extreme dependability (reliability, availability) " diverse and feature-rich functionality " continuous feature upgrades (evolutionary requirements) " physical distribution

! Encountered mostly in telecom (e-business infrastructure and internet access devices), defense, aerospace, and industrial control

slide-4
SLIDE 4

Modeling Requirements for Complex Systems Modeling Requirements for Complex Systems

! This complexity requires focussed modeling support in at least the following areas:

" Timeliness and performance modeling " Time-aware communication models " Concurrency management " Resource modeling " Distributed system modeling " Fault tolerance (detection, treatment, analysis, recovery) " Architectural modeling

! This complexity requires focussed modeling support in at least the following areas:

" Timeliness and performance modeling " Time-aware communication models " Concurrency management " Resource modeling " Distributed system modeling " Fault tolerance (detection, treatment, analysis, recovery) " Architectural modeling

slide-5
SLIDE 5

(Run-Time) Architecture (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 ! 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

slide-6
SLIDE 6

Why Architecture is Important 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 ! 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 A A C C C B B B Mediator Mediator Mediator X X X A A A C C C B B B X X X A A A C C C B B B Mediator Mediator Mediator

slide-7
SLIDE 7

Behavior Behavior

Services Layer Services Layer Application Layer Application Layer

TerminalA TerminalA TerminalA TerminalB TerminalB TerminalB Channel1 Channel1 Channel1 Channel2 Channel2 Channel2

Structure Structure Structure

Example Real-Time Architecture Spec Example Real-Time Architecture Spec

! Example telecom system architecture ! Example telecom system architecture

slide-8
SLIDE 8

Part Part Part

composition (existence dependency) composition (existence dependency) composition (existence dependency)

Basic Run-Time Architectural Patterns Basic Run-Time Architectural Patterns

! Containment: ! Containment:

aggregation (information hiding) aggregation (information hiding) aggregation (information hiding) Layer N+1 Layer N+1 Layer N+1 Layer N Layer N Layer N

Container Container Container Part Part Part Container Container Container Part Part Part PartB PartB PartB PartA PartA PartA

! Peer-to-peer communication: ! Peer-to-peer communication: ! Layering ! Layering

slide-9
SLIDE 9

Architectural Component Design Architectural Component Design

System2 System2 System2 System1 System1 System1

Library Library Library TerminalA TerminalA TerminalA TerminalB TerminalB TerminalB Channel1 Channel1 Channel1 Channel2 Channel2 Channel2 TerminalA TerminalA TerminalA Terminal Tester Terminal Terminal Tester Tester Terminal Terminal Terminal Channel Channel Channel Terminal Tester Terminal Terminal Tester Tester

slide-10
SLIDE 10

TerminalA TerminalA TerminalA TerminalB TerminalB TerminalB Channel1 Channel1 Channel1 Channel2 Channel2 Channel2 TerminalA TerminalA TerminalA TerminalB TerminalB TerminalB Channel1 Channel1 Channel1

Refining Architectures (Reuse) Refining Architectures (Reuse)

slide-11
SLIDE 11

Lab Building Lab Building

ring road ring road ring road

The Fate of Architectures: Architectural Decay The Fate of Architectures: Architectural Decay

! The gradual deterioration of an architecture through seemingly “minor” incremental changes ! The gradual deterioration of an architecture through seemingly “minor” incremental changes

slide-12
SLIDE 12

Preserving Architectures Preserving Architectures

! To ensure visibility and enforcement of architectural intent

" the architectural specification must be an integral part of the final implementation " not as documentation, but as part of the actual implementation

! This requires automated translation of the architectural spec into the implementation language

" automated translation is key since any manual intervention breaks enforcement capabilities " an architectural definition language (ADL)

! To ensure visibility and enforcement of architectural intent

" the architectural specification must be an integral part of the final implementation " not as documentation, but as part of the actual implementation

! This requires automated translation of the architectural spec into the implementation language

" automated translation is key since any manual intervention breaks enforcement capabilities " an architectural definition language (ADL)

slide-13
SLIDE 13

Encapsulation shell Encapsulation Encapsulation shell shell Ports Ports Ports

Capsules: Architectural Objects Capsules: Architectural Objects

! A special kind of active object ! A special kind of active object

slide-14
SLIDE 14

S1 S2 S3 S1 S2 S1

transitionS1toS2: {int x; x = 0; p2.send(s1); p3.send(s2); … }; transitionS1toS2: {int x; x = 0; p2.send(s1); p3.send(s2); … };

Capsules: Internal Behavior Capsules: Internal Behavior

! Optional hierarchical state machine (event handler with run-to-completion semantics) ! Optional hierarchical state machine (event handler with run-to-completion semantics)

slide-15
SLIDE 15

«capsule»

CapsuleClassX

«capsule» «capsule»

CapsuleClassX CapsuleClassX

#counter : int #x : char #counter : #counter : int int #x : char #x : char ports +portB : ProtocolA::master +portC : ProtocolB ports ports + +portB portB : ProtocolA::master : ProtocolA::master + +portC portC : ProtocolB : ProtocolB

Capsules: UML Modeling Capsules: UML Modeling

! Stereotype of Class concept («capsule») with specialized (executable) semantics ! Class diagram representation: ! Stereotype of Class concept («capsule») with specialized (executable) semantics ! Class diagram representation:

slide-16
SLIDE 16

call call call ack ack ack time time time number number number call call call ack ack ack talk talk talk transfer transfer transfer Caller Caller Caller Operator Operator Operator Callee Callee Callee

Protocols: Reusable Behavior Patterns Protocols: Reusable Behavior Patterns

! Interaction contracts between capsules

" e.g., operator-assisted call

! Interaction contracts between capsules

" e.g., operator-assisted call

slide-17
SLIDE 17

OperatorAssisted Call OperatorAssisted OperatorAssisted Call Call

Alice Alice Alice Charlie Charlie Charlie Bob Bob Bob

caller caller caller callee callee callee

  • perator
  • perator
  • perator

initial initial connected connected connecting connecting

protocol state machine protocol state machine protocol state machine

caller caller

  • perator
  • perator

callee callee

significant sequences significant sequences significant sequences

Dexter Dexter Dexter

Protocol Specifications Protocol Specifications

! A collaboration that may be required on multiple

  • ccasions and situations

! A collaboration that may be required on multiple

  • ccasions and situations
slide-18
SLIDE 18

signal signal signal source source source call call call caller caller caller number number number caller caller caller ack ack ack callee callee callee Incoming signals Incoming signals Incoming signals signal signal signal target target target call call call callee callee callee transfer transfer transfer caller caller caller ack ack ack caller caller caller Outgoing signals Outgoing signals Outgoing signals

OperatorRole OperatorRole OperatorRole

initial initial connected connected connecting connecting

protocol state machine protocol state machine protocol state machine

caller caller

  • perator
  • perator

callee callee

significant sequences significant sequences significant sequences

Protocol Roles Protocol Roles

! Specifies one party in a protocol ! Specifies one party in a protocol

slide-19
SLIDE 19

Protocol Refinement Protocol Refinement

! Using standard inheritance ! Using standard inheritance

signal signal signal source source source call call call caller caller caller number number number caller caller caller ack ack ack callee callee callee Incoming signals Incoming signals Incoming signals signal signal signal target target target call call call callee callee callee transfer transfer transfer caller caller caller ack ack ack caller caller caller Outgoing signals Outgoing signals Outgoing signals

OperatorRole OperatorRole OperatorRole

signal signal signal source source source call call call caller caller caller number number number caller caller caller ack ack ack callee callee callee Incoming signals Incoming signals Incoming signals signal signal signal target target target call call call callee callee callee transfer transfer transfer caller caller caller ack ack ack caller caller caller Outgoing signals Outgoing signals Outgoing signals reply reply reply caller caller caller query query query caller caller caller

Extended OperatorRole Extended Extended OperatorRole OperatorRole

slide-20
SLIDE 20

Environment Environment Environment

Capsule Capsule

S1 S1 S2 S2

Each port is typed with a single protocol role

Ports Ports

! Fully isolate a capsule’s implementation from its environment (in both directions) ! Fully isolate a capsule’s implementation from its environment (in both directions)

slide-21
SLIDE 21

Ports and Protocols Ports and Protocols

! Each port realizes a protocol role

" corresponds to the “type” of the port that can be used for static type checking " extension of the traditional object interface concept with a dynamic aspect

! Each port realizes a protocol role

" corresponds to the “type” of the port that can be used for static type checking " extension of the traditional object interface concept with a dynamic aspect

«capsule» «capsule»

CapsuleClassX CapsuleClassX

+portA : ProtocolA::master +portA : ProtocolA::master # #portB portB : ProtocolB : ProtocolB +portC : ProtocolB~ +portC : ProtocolB~ ports ports

slide-22
SLIDE 22

«capsule»

/anX:CapsuleClassX

«capsule» «capsule»

/ /anX anX:CapsuleClassX :CapsuleClassX

portA : ProtocolA::master portA : ProtocolA::master «port» «port»

/ /portA portA: :ProtocolA ProtocolA::master ::master

1 1

Ports: Collaboration Diagram Notation Ports: Collaboration Diagram Notation

! Shorthand notation for capsule instances

" iconified form

! Shorthand notation for capsule instances

" iconified form

slide-23
SLIDE 23

Connectors model communication channels Each connector supports a single protocol Static typing rules apply (compatible protocols) Connectors model communication channels Connectors model communication channels Each connector supports a single protocol Each connector supports a single protocol Static typing rules apply (compatible protocols) Static typing rules apply (compatible protocols)

«capsule»

sender : Fax

«capsule» «capsule»

sender : Fax sender : Fax

remote:FaxProt remote: remote:FaxProt FaxProt «capsule»

receiver : Fax

«capsule» «capsule»

receiver : Fax receiver : Fax

remote:FaxProt remote: remote:FaxProt FaxProt

Connector Connector Connector

Collaborating Capsules Collaborating Capsules

! Using connectors ! Using connectors

slide-24
SLIDE 24

FaxCall FaxCall FaxCall «capsule» /sender:Fax «capsule» «capsule» /sender:Fax /sender:Fax

remote:FaxProt remote: remote:FaxProt FaxProt

«capsule» /receiver:Fax «capsule» «capsule» /receiver:Fax /receiver:Fax

remote:FaxProt remote: remote:FaxProt FaxProt receiveCtrl : Control receiveCtrl receiveCtrl : Control : Control sendCtrl : Control sendCtrl sendCtrl : Control : Control

Relay port Relay Relay port port

c : Control c : Control c : Control c : Control c : Control c : Control

Composition: Structural Patterns Composition: Structural Patterns

slide-25
SLIDE 25

f1:FaxCall f1:FaxCall

«capsule» sender:Fax «capsule» «capsule» sender:Fax sender:Fax «capsule» receiver:Fax «capsule» «capsule» receiver:Fax receiver:Fax

f1 := create(FaxCall); f1 := create( f1 := create(FaxCall FaxCall); );

Composite Capsule Semantics Composite Capsule Semantics

! Run-time assertion: the complete internal structure of a composite is automatically created (recursively, if necessary) when the capsule is created ! Run-time assertion: the complete internal structure of a composite is automatically created (recursively, if necessary) when the capsule is created

slide-26
SLIDE 26

Benefits of Run-Time Assertion 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 low- level 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 ! Architectural enforcement: only explicitly prescribed architectural structures can be instantiated

" it is not possible to bypass (corrupt) the architecture by low- level 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

slide-27
SLIDE 27

Why Do We Need Capsules? Why Do We Need Capsules?

! Won’t “regular” objects do?

" Composite capsules explicitly capture complex structural patterns of concurrent objects

  • Structural assertions (enforced architectural intent)
  • Multiple levels of decomposition, if necessary

" Ports through protocols bind complex high-level interactions to objects " Capsules have distinct interfaces for different collaborators

  • Interfaces are objects with state and identity
  • Suitable for distributed system modeling

" Capsules can model layering relationships

! Won’t “regular” objects do?

" Composite capsules explicitly capture complex structural patterns of concurrent objects

  • Structural assertions (enforced architectural intent)
  • Multiple levels of decomposition, if necessary

" Ports through protocols bind complex high-level interactions to objects " Capsules have distinct interfaces for different collaborators

  • Interfaces are objects with state and identity
  • Suitable for distributed system modeling

" Capsules can model layering relationships

slide-28
SLIDE 28

«capsule» sender:Fax

c : Control

«capsule» receiver:Fax

c : Control

End Ports: Where Structure and Behavior Meet

! Ports directly connected to the state machine

receiveCtrl : Control~ senderCtrl : Control~ c : SystemControl

initial connected connecting

capsule state machine

Public End Port Implementation End Port

slide-29
SLIDE 29

Summary: Architecture Summary: Architecture

! Software architecture plays a major role in system definition, construction, and evolution ! Embedded systems require specialized support for common complex architectural forms (layering, concurrency, interactions, etc.) ! UML can be used as an ADL for real-time systems

" consists of just 4 basic concepts (capsules, ports, connectors, and protocols) " suitable for executable models and automatic code generation

! Directly supported by the Rose RealTime product ! Software architecture plays a major role in system definition, construction, and evolution ! Embedded systems require specialized support for common complex architectural forms (layering, concurrency, interactions, etc.) ! UML can be used as an ADL for real-time systems

" consists of just 4 basic concepts (capsules, ports, connectors, and protocols) " suitable for executable models and automatic code generation

! Directly supported by the Rose RealTime product

slide-30
SLIDE 30

Stereotype UML Metaclass «protocol» Collaboration «protocolRole» ClassifierRole «port» Class «capsule» Class

⇒supplemented by an optional notation

Summary: UML-RT Profile Elements Summary: UML-RT Profile Elements

! Only four UML stereotypes are sufficient ! (include formally defined constraints that ensure consistency/executability) ! Only four UML stereotypes are sufficient ! (include formally defined constraints that ensure consistency/executability)

slide-31
SLIDE 31

Bibliography Bibliography

! Bass, L., P. Clements, and R. Kazman, Software Architecture in Practice, Addison-Wesley, 1998. ! B. Selic, J. Rumbaugh, Using UML to Model Complex Real-Time Systems, Rational whitepaper:

(http://www.rational.com/sitewide/support/whitepapers/dynamic.jtmpl)

! B. Selic, G. Gullekson, P. Ward, Real-Time Object- Oriented Modeling, John Wiley, 1994. ! Bass, L., P. Clements, and R. Kazman, Software Architecture in Practice, Addison-Wesley, 1998. ! B. Selic, J. Rumbaugh, Using UML to Model Complex Real-Time Systems, Rational whitepaper:

(http://www.rational.com/sitewide/support/whitepapers/dynamic.jtmpl)

! B. Selic, G. Gullekson, P. Ward, Real-Time Object- Oriented Modeling, John Wiley, 1994.

slide-32
SLIDE 32

Questions? Questions?