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. 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) 2.5.2 Tasks and Concurrency Control  task semantics:symbols or labels trigger task

4. 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 Task Activation

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 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 Synchronization ignored the lock and active object passed the lock and active separate threads blocked and waiting in the queue lock

8. 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 Java Notification active object active blocked and in the queue waiting to try again after notification lock

9. 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 Object Level Synchronization @ class class method 1method 2method 3 @ method 1@ method 2 method 3

10. Containment Hidden synchronization Expressiveness panel @ interval clear… set startset duration… @ safe panel start date end date

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

12. 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 Active Objects class  method 1@ method 2@ method 3 method 4 class trigger method 1@ method 2@ 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 auto watering manual watering incident logging field condition intruder sensor loss water ph timer sprayer sensor field bus

17. 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.5.4 Design Diagrams

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. Customer service sample partition Multiple Views ATM customer proxy secure log entry secure data entry authentication transaction data bank customer record verification

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

27. Sensor grid protection mobile agent based application agent cloning maintains the structure Dynamic Structures

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 behavior analysis design diagram class diagrams class diagrams complex object definitions simple 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 code manager authentication transaction ATM customer proxy code manager authentication transaction

32. 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 Activity Diagram moving nextposition next cell full next cell empty pack clone ack verify clean up die

33. 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) Use Cases 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