Software Architecture Specification III GruiaCatalin Roman and Christopher

Software Architecture Specification III Gruia-Catalin Roman and Christopher Gill Washington University in St. Louis

2. 5 Architectural Notation n Components n Tasks and concurrency control n n n Connectors and actuators Design Diagrams Meta-level specifications 2 • 2

2. 5. 2 Tasks and Concurrency Control n A task is a sequential process having its own thread of control – Its execution results in invocation of methods on objects in the system n task Task execution may be – periodic • time triggered (e. g. , by a timer) semantics: symbols or labels – reactive, a. k. a. aperiodic • event triggered (e. g. , by a sensor) n 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 timeslice (RR) or not (FIFO) 2 • 3 trigger task

Task Activation n n Each task actuator is n associated with some trigger condition Trigger conditions must be n 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? 2 • 4 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

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

Semantics of Concurrency n n 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 ; y : = x + 1 n n n or || or [] 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 2 • 6

Synchronization n n 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. n At design level, express synchronization by specifying mutual exclusion requirements 2 • 7 n Java model ignored the lock and active separate threads n object passed the lock and active blocked and waiting in the queue lock

Java Notification n 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 n n The notify. All(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 2 • 8 active object active blocked and in the queue waiting to try again after notification lock

Object Level Synchronization n n The notation is the same for classes and objects and so are the semantics Synchronized objects specify mutual exclusion among all methods @ class method 1 method 2 method 3 2 • 9 n n Notation and semantics may be adjusted for different settings Synchronized methods limit mutual exclusion to identified methods class @ method 1 @ method 2 method 3

Expressiveness n Containment n Hidden synchronization panel @ interval clear … set start set duration … start date 2 • 10 end date @ safe panel

Expressiveness n Adapter n Synchronized wrapper panel @ service clear … serve … @ safe panel @ adaptation clear … serve {A. method} … A method … 2 • 11

Active Objects n Equivalent to wrapping a task in an “object veneer” class method 1 @ method 2 @ method 3 method 4 – Controls the execution of a specific “service” method n Execution of a thread in an active object may be periodic or reactive trigger method 1 @ method 2 @ method 3 method 4 trigger / method 2 • 12 class

2. 5. 3 Connectors n 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 n 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 2 • 13

Connector Types n 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” n 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 n Transparent connectors have no symbol tying the points of origin and processing – event notification – publish/subscribe 2 • 14

Connector Instances n Message passing interactions – channels (1 to 1) – ports (n to 1 or 1 to n) – mailboxes (n to m) n n 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 2 • 15

Sample Connectors message queue intruder water field condition auto watering manual watering timer sprayer ph sensor field bus 2 • 16 sensor loss incident logging

2. 5. 4 Design Diagrams n n 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) 2 • 17

Cost Effective Design Process n Effective design – focuses on early investments in creative thinking – delays documentation until stability is reached n Typical stages in architectural design – – – – 2 • 18 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

Architectural Sketch dispatcher station incident records 2 • 19 dispatcher station tracking station ambulance status incident records ambulance status tracking station

Architectural Design RPC protocol dispatching tracking records proxy t=4 d = 12 emergency records fault tolerant database repository ambulance a = 12 2 • 20

Software/Hardware Allocation n The allocation of software components to the underlying hardware is – a defining feature of the architecture – a critical design decision affecting • • • n 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 n If the allocation is transparent – it requires no explicit graphical notation – it affects analysis and evaluation 2 • 21

Allocation Alternatives desktop display process control robot control remote server 2 • 22 manufacturing specifications code repository

Allocation Alternatives PDA display micro controller control board process control robot control manufacturing specifications code repository 2 • 23 remote server

Remember to Control Complexity n n n 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 2 • 24

Multiple Views n Customer service – sample partition ATM customer proxy authentication 2 • 25 secure log entry transaction secure data entry customer record verification data bank

Multiple Views n Code management – alternate viewpoint – strict version control ATM 2 • 26 customer proxy code manager secure log entry authentication transaction secure data entry customer record verification data bank

Dynamic Structures n Sensor grid protection – mobile agent based application – agent cloning maintains the structure 2 • 27

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

Impact on Architecture Design n Simplify the object definition process – class diagrams n Capture fundamental relationships among objects – class diagrams n Define interaction protocols – sequence diagrams n Formalize behavior patterns for analysis or specification – sequence diagrams – activity diagrams n Capture interaction or processing scenarios – use cases – activity diagrams 2 • 29

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

Sequence Diagram customer proxy ATM code manager authentication transaction n 2 • 31 Is the most recent code being used? Can authentication be bypassed? etc. customer proxy code manager authentication transaction

Activity Diagram n n n An activity diagram is a specialized finite state machine—action 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 moving next position next cell full next cell empty pack clone verify clean up die 2 • 32 ack

Use Cases n Actors – model the environment and the users – initiate activity by providing stimuli – can be primary or secondary n 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) 2 • 33 authorization uses phone call extends charging

Concluding Remarks n Development of a software architecture is complex – multiple perspectives – different notations – significant and sophisticated analysis n n n 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 2 • 34