Software Architecture Specification III

1
Software Architecture Specification III

• Gruia-Catalin Roman and Christopher Gill
• Washington University in St. Louis

2
2.5 Architectural Notation

• Components
• Tasks and concurrency control
• Connectors and actuators
• Design Diagrams
• Meta-level specifications

3
2.5.2 Tasks and Concurrency Control

• A task is a sequential process having its own
  thread of control
• Its execution results in invocation of methods on
  objects in the system
• Task execution may be
• periodic
• time triggered (e.g., by a timer)
• reactive, a.k.a. aperiodic
• event triggered (e.g., by a sensor)
• Tasks are usually scheduled at a given priority
• One common convention lower number represents a
  higher priority
• Higher priority tasks preempt lower priority
  tasks
• Tasks at same priority may time-slice (RR) or not
  (FIFO)

?
task
semanticssymbols or labels
trigger
task
4
Task Activation

• Each task actuator is associated with some
  trigger condition
• Trigger conditions must be defined outside the
  diagram
• Different notations should be used for different
  triggers
• Important can the trigger mechanism be
  implemented?
• Also are its non-functional properties (timing
  precision) ok?

• Actuators can hide complex implementation details
  and simplify design
• Sample trigger conditions
• clock signal
• timer expiration
• system event (e.g., failure, power up, reboot)
• application event
• message arrival
• system condition that can be assessed
  independently

5
Concurrency Implications

• Multitasking is both necessary and convenient
• Complicates design analysis
• starvation due to deadlocks or priority inversion
• missed deadlines or low performance
• Requires an understanding of
• fundamentals of concurrency
• system characteristics
• Special notation needs to be introduced to help
  design analysis

6
Semantics of Concurrency

• Certain concepts are fundamental to any form of
  concurrent processing
• In the absence of a clear definition for these
  concepts both design and programming become
  impossible
• x y 1
• or or
• y x 1
• Atomicity addresses the issue of minimal
  guarantees of non-interference among operations
• Fairness is concerned with minimal assumptions
  that can be made about the scheduling of
  operations
• Synchronization deals with the mechanics by which
  concurrent operations coordinate their executions

7
Synchronization

• Synchronization defines a structured mechanism
  for coordination among tasks
• Mutual exclusion is a general synchronization
  mechanism implementable in most systems
• Mechanics of synchronization are
  platform/language specific
• Ada tasks, Java synchronized methods, C/C
  mutexes, etc.
• At design level, express synchronization by
  specifying mutual exclusion requirements

• Java model

ignored the lock and active
object
passed the lock and active
separate threads
blocked and waiting in the queue
lock
8
Java Notification

• The wait(object) operation blocks thread (in a
  wait queue)
• the object lock is released
• A time period may be specified
• thread is removed from wait queue when timer
  expires
• The notifyAll(object) operation removes all the
  threads from the wait queue (wakeup)
• In both cases the released threads must be
  scheduled and must acquire the lock
• Optimization check a condition before competing
  for the lock

active
object
active
blocked and in the queue
waiting to try again after notification
lock
9
Object Level Synchronization

• The notation is the same for classes and objects
  and so are the semantics
• Synchronized objects specify mutual exclusion
  among all methods

• Notation and semantics may be adjusted for
  different settings
• Synchronized methods limit mutual exclusion to
  identified methods

_at_ class
class
method 1method 2method 3
_at_ method 1_at_ method 2 method 3
10
Expressiveness

• Containment

• Hidden synchronization

panel
_at_ interval
set startset duration
clear
start date
_at_ safe panel
end date
11
Expressiveness

• Adapter

• Synchronized wrapper

_at_ service
panel
clear
serve
_at_ adaptation
_at_ safe panel
serve A.method
clear
A
method
12
Active Objects

• Equivalent to wrapping a task in an object
  veneer
• Controls the execution of a specific service
  method
• Execution of a thread in an active object may be
  periodic or reactive

class
? method 1_at_ method 2_at_ method 3 method 4
class
trigger
method 1_at_ method 2_at_ method 3
method 4
trigger / method
class
13
2.5.3 Connectors

• Connectors relate components appearing in the
  design diagram
• allow components to interact
• constrain the nature of their interactions
• simplify the design by abstracting complex
  patterns of interaction
• Connectors can be specialized
• each connector is an instance of a class
• standard class definition methods are used
• specialized symbols are employed to simplify
  design

14
Connector Types

• Basic connectors
• reference relation constrains method invocation
  patterns
• can call anything you can point to
• aggregation relation is also a restricted form of
  reference
• can call anything you own
• Complex connectors
• can be two-party or multi-party (including
  interaction pattern)
• may be specialized for a particular design
• may use custom graphical representations and
  models
• Transparent connectors have no symbol tying the
  points of origin and processing
• event notification
• publish/subscribe

15
Connector Instances

• Message passing interactions
• channels (1 to 1)
• ports (n to 1 or 1 to n)
• mailboxes (n to m)
• Software bus (e.g., an object request broker)
• Remote procedure call (e.g., RPC, CORBA, Java
  RMI)
• Shared tuple spaces
• Event dispatchers and event channels

16
Sample Connectors
message queue
incident logging
field condition
auto watering
manual watering
sensor loss
intruder
water
ph
timer
sprayer
sensor field bus
17
2.5.4 Design Diagrams

• The design diagram is an abstract view of the
  system structure and key behavior constraints
• The design diagram identifies the key software
  system components and the relevant connectors
• Components and connectors are defined outside the
  scope of the diagram
• Annotations allow one to communicate additional
  information for which there is no precise
  notation
• implementation directives
• timing constraints
• software binding requirements (COTS)

18
Cost Effective Design Process

• Effective design
• focuses on early investments in creative thinking
• delays documentation until stability is reached
• Typical stages in architectural design
• initial diagram layout
• diagram refinement and informal object
  specifications
• informal design review
• specification of object interfaces
• analysis of critical design issues
• preliminary design review
• complete specification
• formal architecture design review

19
Architectural Sketch
tracking station
dispatcher station
tracking station
dispatcher station
incident records
ambulance status
incident records
ambulance status
20
Architectural Design
RPC protocol
dispatching
tracking
records proxy
records proxy
t 4
d 12
emergency records
fault tolerant database repository
ambulance
a 12
21
Software/Hardware Allocation

• The allocation of software components to the
  underlying hardware is
• a defining feature of the architecture
• a critical design decision affecting
• quality of service
• analysis and evaluation
• software interfaces
• coordination/communication protocols
• maintenance procedures
• If the allocation is explicit (static or dynamic)
• it can be captured in the form of annotations
• each software components is mapped to exactly one
  hardware component
• If the allocation is transparent
• it requires no explicit graphical notation
• it affects analysis and evaluation

22
Allocation Alternatives
desktop
display
process control
manufacturing specifications
robot control
remote server
code repository
23
Allocation Alternatives
PDA
display
micro controller
process control
control board
remote server
manufacturing specifications
robot control
code repository
24
Remember to Control Complexity

• Packages may be used to define subsystems (rather
  than code management)
• Simple interfaces among subsystems facilitate
  hierarchical decomposition of the system
• Decoupling among components facilitates
  partitioning of the system
• Multiple views, while difficult to keep
  consistent, may be critical in support of
  analysis
• Typical configurations can assist in providing a
  finite, thorough description of a dynamic system

25
Multiple Views

• Customer service
• sample partition

ATM
customer proxy
secure log entry
secure data entry
authentication
transaction
data bank
customer record
verification
26
Multiple Views

• Code management
• alternate viewpoint
• strict version control

ATM
customer proxy
secure log entry
code manager
secure data entry
authentication
transaction
data bank
customer record
verification
27
Dynamic Structures

• Sensor grid protection
• mobile agent based application
• agent cloning maintains the structure

28
2.5.5 Meta Level Specifications

• A strict definition of the design diagram
• enables rapid and cost effective design
• focuses the design process on fundamentals
• Component specifications complete the picture by
  providing
• precise interface specifications
• exact behavior specifications
• Meta level specifications provide additional
  support for
• definition
• analysis
• specification

29
Impact on Architecture Design

• Simplify the object definition process
• class diagrams
• Capture fundamental relationships among objects
• class diagrams
• Define interaction protocols
• sequence diagrams
• Formalize behavior patterns for analysis or
  specification
• sequence diagrams
• activity diagrams
• Capture interaction or processing scenarios
• use cases
• activity diagrams

30
Documentation Revisited
use cases
processing scenarios
sequence diagrams activity diagrams finite state
diagrams
sequence diagrams finite state diagrams
protocol specifications
design diagram
behavior analysis
class diagrams
class diagrams
simple object definitions
complex object definitions
object relations
narrative, pseudocode, finite state diagrams, etc.
31
Sequence Diagram

• Is the most recent code being used?
• Can authentication be bypassed?
• etc.

customer proxy
authentication
transaction
code manager
ATM
customer proxy
code manager
authentication
transaction
32
Activity Diagram
moving

• An activity diagram is a specialized finite state
  machineaction termination controls transitions
• When used to describe the behavior of one object,
  all actions are local
• When used to capture global behavior, actions
  are distributed

nextposition
next cell empty
next cell full
pack
clone
ack
verify
clean up
die
33
Use Cases

• Actors
• model the environment and the users
• initiate activity by providing stimuli
• can be primary or secondary
• Use cases
• are complete courses of action initiated by
  actors (basic or alternative)
• can be extended by (interrupt analogy) or use
  other use cases (call analogy)

authorization
uses
phone call
extends
charging
34
Concluding Remarks

• Development of a software architecture is complex
• multiple perspectives
• different notations
• significant and sophisticated analysis
• Complexity of notation and concepts should be
  minimized
• The design process should focus mainly on
  fundamentals and on the creative activities
• Precise and complete documentation is crucial but
  is not the dominant activity