Software Architectures


Lecture 1

This course at:
 Has 5 sp
 Weeks 44-51:
 Tuesdays and Thursdays, during 10:15-12,

@ Cobol (B3040)
 Components
 Lectures: 9-12 (18-24h)
 Exercises: 3 individually returned studies
 Tests: 16.12.2011, 20.1.2012, 17.2.2012, 4.5.2012

@ Alpha Auditorium, during 12-16
 Register 7 days in advance to any test


Software Architectures, Lecture 1




Software Architectures, Lecture 1


 C. Hofmeister, R. Nord, D. Soni: Applied Software

Architecture, Addison-Wesley, 2000.
 M. Shaw and D. Garlan: Software Architecture Perspectives on an Emerging Discipline,
Prentice-Hall, 1996.
 L. Bass, P. Clements, and R. Kazman: Software
Architecture in Practice, Addison-Wesley, 2003.
 P. Clements, R. Kazman, M. Klein: Evaluating
Software Architectures, Addison-Wesley, 2002.


Software Architectures, Lecture 1


Software Architecture
 Architecture
 Old art and ancient engineering discipline
 Software
 The industry begun in late 40s
 Software architecture
 Much less mature than computer hardware
 Common excuses
 Software industry is young and unique
 Yet: our economy relies on software


Software Architectures, Lecture 1


”Our society runs on Software”
 Software today allows a brother in San Jose to call a sister in St.

 Software today speeds the process of drug discovery, potentially
curing Alzheimer's.
 Software today drives the imaging systems that allow the early
detection of breast cancer and other maladies.
 Software controls the passive restraint systems and antilock
breaking systems that save children's lives in automobiles every
 Software powers our communication and transportation
 Software allows us to peer deep within ourselves and study the
human genome.
 Software allows us to explore and understand our universe.
 And, make no mistake about it, we are just getting started
Paul Levy

Software Architectures, Lecture 1


What does SA address?
 Complexity of software systems increased
 Developing software: hundreds/ thousands person-years
 Many software systems: complex as skyscrapers

 Designing software
 Beyond algorithms/ data structures of the computation
 New kind of problem: overall system structure


Software Architectures, Lecture 1


Producing software systems
 Criteria have changed
 Computer hardware improved, affordable
 Need for software applications exploded
 How to specify requirements for new products and

implement the software quickly, cheaply
 Earliest software product on market
 Quality?

 New criterion: does it have a good SA, understood

by stakeholders and developers?


Software Architectures, Lecture 1


Software architecture

Provides a design plan of a system
 Blueprint
 Implies purpose


Is an abstraction that helps in managing the
complexity of a system

 Software architects limited by
 Lack of standardized ways to represent architecture
 Lack of analysis methods to predict whether an

architecture will result in an implementation that
meets the requirements

Software Architectures, Lecture 1


SA as a design plan
 Structural plan that describes
 The elements of a system
 How they fit together
 How they work together to fulfill requirements
 Used as blueprint during development

 Used to negotiate system requirements
 Used to set expectations with
 Customers
 Marketing/management personnel

Software Architectures, Lecture 1


SA as design plan
 Project manager uses the design plan as input to

the project plan

Domain analysis,
Requirements analysis,
Risk analysis

SA design


Detailed design,
Integration, Testing

Software Architectures, Lecture 1


encapsulated into elements of the SA  SA should describe elements at a coarse level of granularity  How elements fulfill the requirements  Element interactions  Element dependencies on execution platform 12 Software Architectures. Lecture 1 1-Nov-11 .SA as an abstraction  SA not a comprehensive decomposition of a system  Implementation details abstracted away.

Design tradeoffs  Resolving tradeoffs may lead to  Sacrificing some desired qualities  E. modifiability. Lecture 1 1-Nov-11 .g.. etc 13 Software Architectures. simplicity  Compromising some requirements  Renegotiating  Reducing portability.

Lecture 1 1-Nov-11 .SA goal  One should strive for a good architecture  When system is implemented according to the architecture. it meets its requirements and resource budget  It is possible to implement system according to architecture  Not good enough when  Not explicit or not comprehensive or not consistent or not understandable 14 Software Architectures.

SA terminology Architectural style/pattern 1. Lecture 1 1-Nov-11 .    15 Defines element types and how they interact Sometimes defines a mapping of functionality to architectural elements Defines element types and how they interact They apply to a particular domain They define how the domain functionality is mapped to architectural elements Software Architectures.   Reference/domain specific architecture 2.

Lecture 1 1-Nov-11 . how they interact.g.SA terminology.    Applies to a set of products within a company Defines element types.. how the product functionality is mapped to them May also define some of the instances of the architectural elements  16 E. 2 Product-line architecture 3. error-reporting components would be common to many products of the product line Software Architectures.

    17 Applies to one system Describes element types. how the product functionality is mapped to them Describes the instances that exist in the system Level of specificity needed to design a system Software Architectures. how they interact.3 Software architecture 4. Lecture 1 1-Nov-11 .SA terminology.

4 Defines element types and how they interact Defines the mapping of functionality to architecture elements Defines instances of architecture elements yes sometimes no yes yes no yes yes sometimes yes yes yes Term An architectural style A reference architecture A product-line architecture A software architecture .SA terminology.

SA terminology.  Gives notation for architectural elements      19 As types and instances. final ADL (architectural description language) 5. also interconnecting instances to form configurations Mostly in research communities In theory: architects can use an ADL to describe any of the 1-4 terms In practice: not all ADLs support all the 1-4 terms Some ADLs have accompanying tools Software Architectures. Lecture 1 1-Nov-11 .

as well as design them 20 Software Architectures. Lecture 1 1-Nov-11 .HENCE:  We need to study software architecture  Our society is software-reliant  Software systems are complex  Software architecture  Addresses the complexity of the systems to build  Course goal  Understand what SA is  SA very much an emerging discipline  The philosophy  One should not focus on designing the ideal architecture  Instead: focus on carefully examining tradeoffs  We will learn to recognize and evaluate architectures.

The job 21 Software Architectures.Contents of this course  L1: What is SA? Quality Attributes (today)  L2: Architectural tactics and styles  L3: Case studies Design. Research  L9: Product lines. COTS. Recognize  L4: Creating an architecture  L5+6: Architectural views Documenting  L7: Analysing and evaluating an architecture  L8: Architectural Description Languages Generalization. Lecture 1 1-Nov-11 . Software architects Automating the architecting.

The ABC cycle  SA – result of technical. influence future SAs  This is the ABC cycle of influences: Architecture Business Cycle  Organizational goals  requirements  SA  systems  future new organizational goals  … 22 Software Architectures. business. subsequently. and social influences  A SA also influences technical. Lecture 1 1-Nov-11 . business. and social influences  That.

low cost  Customer: timely delivery. performance. Lecture 1 1-Nov-11 . not changed often  End user: behavior. keep people employed  Marketing: short time to market. security  Maintenance: modifiability 23 Software Architectures.Stakeholders  Architectures influenced by stakeholders  Management: low cost.

behavior  Sometimes the only development concern  Systems often need to be redesigned for Maintainability  Portability  Scalability  Speed  Security etc  Compromise  24 Software Architectures.The business considerations  Determine qualities to be part of the system’s architecture  Quality attributes  Such qualities are non-functional  Functionality  Basic statement of the system’s capabilities. services. Lecture 1 1-Nov-11 .

Lecture 1 1-Nov-11 .More on functionality  Functionality and quality attributes: orthogonal  We therefore need to separate concerns  Functionality: the ability of the system to do the work for which it was intended  Functionality can be achieved by using various possible structures  System can exist also as a monolithic module with no structure 25 Software Architectures.

Architecture and quality attributes  Quality attributes considered during  Design. implementation. deployment  No attribute is dependent only on one phase  Architecture critical for realizing many quality attributes  These qualities designed and evaluated at architectural level  Architecture does not achieve these qualities  They are achieved via details (implementation) 26 Software Architectures. Lecture 1 1-Nov-11 .

security. modifiability. testability. performance. usability  Business qualities  Time-to-market. etc  Architecture qualities  Conceptual integrity.Quality attributes  System qualities  Availability. etc 27 Software Architectures. Lecture 1 1-Nov-11 .

own communities  Problems  Non-operational definitions  Aspects belong to which quality  Distinct vocabularies 28 Software Architectures.System qualities  Of interest to software people since 70s  Many definitions. Lecture 1 1-Nov-11 .

Lecture 1 1-Nov-11 . containing  Source of stimulus  Stimulus  Environment  Artifact  Response  Response measure 29 Software Architectures.Quality attribute scenarios  Quality-attribute-specific requirement.

QA scenario parts  Source of stimulus  Human/computer system/other actuator generating the stimulus  Stimulus  Condition that needs to be evaluated when arrives at the system  Environment  The conditions the system is in (overload/running/failed etc) 30 Software Architectures. Lecture 1 1-Nov-11 .

2  Artifact  Something that is stimulated (whole system/ certain system part)  Response  Activity undertaken upon stimulus arrival  Response measure  Response should be measurable in some manner so that the requirement can be tested 31 Software Architectures. Lecture 1 1-Nov-11 .QA scenario parts.

Lecture 1 1-Nov-11 .QA scenarios  General QA scenarios  System independent  Can potentially pertain to any system  Concrete QA scenarios  Specific to the particular system under consideration  Same role as use cases for specifying functional requirements 32 Software Architectures.

but not disciplined enough recording  We generate concrete QA scenarios  First create general scenarios from tables  From them derive system-specific scenarios 33 Software Architectures.QA Scenario Generation  We need to generate meaningful QA requirements for a system  Requirements gathering phase  Starting point. Lecture 1 1-Nov-11 .

Availability  Readiness of usage  Concerned with system failures and consequences  Failure  Deviation from intended functional behavior  Observable by system users  Failure vs fault  Fault: event which may cause an error  Error: incorrect internal system state 34 Software Architectures. Lecture 1 1-Nov-11 .

Availability concerns  How system failure is detected  How frequently system failure may occur  What happens when a failure occurs  How long is a system allowed to be unoperable  When can failures occur safely  How to prevent failures  What kind of notifications are required when a failure occurs 35 Software Architectures. Lecture 1 1-Nov-11 .

Repairments and maintenance  Time to repair:  time until failure is no longer observable  Automatic repair  Maintenance: scheduled downtimes  Probability  Mean time to fail/(mean time to fail+mean time to repair) 36 Software Architectures. Lecture 1 1-Nov-11 .

communication channels. availability time. processes Environment Normal operation or degraded mode Response Response measure Detect event and record it/notify appropriate parties/disable event sources causing faults/failures/ be unavailable for an interval/ continue Time interval of available system. repair time .Availability general scenarios Source Internal/external to system Stimulus Fault: omission. response Artifact System’s processors. persistent storage. time interval of degraded mode. timing. crash.

tested. Upon specifying a change     38 What can change the artifact? When and by whom is the change made? New implementation must be designed. 2. Lecture 1 1-Nov-11 .Modifiability Concerns cost of change  1. implemented. deployed All these cost time and money Time and money can be measured Software Architectures.

modifiability  Capacity  Number of users supported. MW  System environment  Systems to interoperate with. communication protocols  System qualities  Reliability.What can change (the artifact)?  Any aspect of a system: add/ delete/ modify  The functions the system computes  The platform the system exists on (=> portability)  HW. OS. performance. Lecture 1 1-Nov-11 . of supported operations 39 Software Architectures.

system administrator 40 Software Architectures. end users.When and by whom is the change made?  Implementation  Modifying source code  Compile-time  Build  Configuration setup  Execution  By  developers. Lecture 1 1-Nov-11 .

QA. system that interoperates with target system Environment Runtime. extent to which this affects other QAs. effort. design time Response Locates place in architecture to modify. system administrator Stimulus Wishes to add/delete/modify/vary functionality. build time. platform. etc Artifact System UI. deploys modif. capacity.Modifiability general scenarios Source End user.. money. makes modification w/o affecting other func.. compile time. functions . environment. Response measure Costs in terms of number of elements affected. tests modif. developer.

Lecture 1 1-Nov-11 . requests from users. passage of time  Complication  Number of event sources and arrival patterns 42 Software Architectures. messages.Performance  Concerned with timing  how long it takes a system to respond when an event occurs  Events  Interrupts.

g. every 10 ms  Most often seen in real-time systems  Stochastic  Events arrive according to some probabilistic distribution  Sporadical 43 Software Architectures..Arrival pattern for events  Periodic  E. Lecture 1 1-Nov-11 .

System responses  Latency  Time between stimulus arrivaland system’s response to it  Deadlines in processing  Throughput in the system  Number of transactions system can process in a second  Jitter of the response  Variation in latency  Number of events not processed  Because system too busy to respond  Lost data  Because system too busy 44 Software Architectures. Lecture 1 1-Nov-11 .

deadline. throughput. changes level of service 1-Nov-11 Latency. Lecture 1 45 . miss rate. data loss Software Architectures. jitter. overload mode Response Response measure Processes stimuli.Performance general scenarios Source Independent sources (possibly from within system) Stimulus Periodic or stochastic or sporadic events occur Artifact System Environment Normal mode.

Security  Measure of system’s ability  to resist unauthorized usage  to provide services to legitimate users  Attack: attempt to breach security  Unauthorized attempt to access data/services  Unauthorized attempt to modify data  Attempt to deny services to legitimate users 46 Software Architectures. Lecture 1 1-Nov-11 .

Example attacks  Theft of money by electronic means  Theft of credit card numbers  Destruction of files on computer systems  Denial-of-service attacks by worms. Lecture 1 1-Nov-11 . viruses 47 Software Architectures.

Security components  Nonrepudiation  Transaction cannot be denied by any of its parties  Confidentiality  Data/service protected from unauthorized access  Integrity  Data/services delivered as intended  Assurance  Parties in a transactions are who they say they are  Availability  System ready for legitimate use  Auditing  System tracks activities within it to be able to reconstruct them 48 Software Architectures. Lecture 1 1-Nov-11 .

firewalled or open Response Response measure various 1-Nov-11 various Software Architectures. reduce availability Artifact System services. Lecture 1 49 . data within system Environment On/offline.Security general scenarios Source Individual/system: identity. access system services. internal/external. change/delete data. access Stimulus Try to: display data. authorization. (dis)connected.

Lecture 1 1-Nov-11 .Security scenario response          50 Authenticates user Hides identity of user Blocks/allows acces to data/services Grants/withdraws permission to access data/services Records access/modification or attempts Stores data in certain formats Recognizes access/usage roles Informs users on other systems Restricts availability of services Software Architectures.

identifying attacker Percentage of services still available under DoS attack Restore data/services Extent to which data/services damaged or legitimate access denied Software Architectures. Lecture 1 1-Nov-11 .Security scenario response measure  Time/effort/resources for circumventing security     51 measures successfully Probability of detecting attack.

Lecture 1 1-Nov-11 .Testability  Easiness with which SW can demonstrate its faults through testing  Testing: 40% costs of developing good systems  Probability that SW will fail on its next test execution  Assuming the software has at least one fault  Response measures  Effectivness of tests (in finding faults)  How long do satisfiable tests last 52 Software Architectures.

Testable system  It must be possible  to control each component’s internal state and inputs  To observe the outputs  Test harness  Specialized software designed for exercizing the SW under test 53 Software Architectures. Lecture 1 1-Nov-11 .

Who and what  Who does it  Various developers. testers. verifiers. Lecture 1 1-Nov-11 . users  Last step of SW development cycle  What to test  Portions of code  Design  Complete system 54 Software Architectures.

at deployment time Response Provides access to state values. prepares test environment Response measure Percent executable statements executed. architecture. length of time to prepare test environment .Testability general scenarios Source Unit developer. at compile time. client acceptance tester. code part. system delivered Artifact Design part. complete application Environment At design time. system user Stimulus Analysis. subsystem integration completed. at development time. class. increment integrator. probability of failure if fault exists. system verifier. provides computed values. design. length of longest dependency chain in a test. time to perform tests.

Lecture 1 1-Nov-11 .Usability  Concerned with  How easy it is for the user to accomplish a desired task  User support type the system provides  Usability problems are usually discovered during prototype building and user testing  Later in process and deeper in architecture the repair needs to go: the more expensive 56 Software Architectures.

Lecture 1 1-Nov-11 .Usability areas  Learning system features  Using a system efficiently  Minimizing the impact of errors  Adapting system to user needs  Increasing confidence and satisfaction 57 Software Architectures.

feel comfortable Artifact System Environment At runtime and configure time Response Various Response measure Task time. user knowledge gain. minimize impact of errors.Usability general scenarios Source End user Stimulus Wants to learn system features. number of errors. adapt system. number of problems solved. amaount of time/data lost . use system efficiently. user satisfaction. ratio of successful operations to total operations.

Usability scenario response  System provides responses to support  learn system features  use system efficiently  minimize impact of errors  adapt system  feel comfortable 59 Software Architectures. Lecture 1 1-Nov-11 .

Lecture 1 1-Nov-11 .Communicating concepts  General scenarios  Need to make stakeholders communicate  Each attribute community has own vocabulary  Different terms can mean the same thing  Stimuli can occur during runtime or before  Architect’s job: understand which stimuli  Represent the same ocurence  Are aggregates of other stimuli  Are independent  When stimuli relations are clear  Communicate them to stakeholders  Use appropriate language for each stakeholder category 60 Software Architectures.

architecture. minimize impact of errors.Stimuli Availabiliy Unexpected event. adapt system. etc Performance Periodic or stochastic or sporadic events occur Security Tries to: display data. subsystem integration completed. system delivered Usability Wants to learn system features. Lecture 1 61 . feel comfortable 1-Nov-11 Software Architectures. platform. use system efficiently. nonoccurence of expected event Modifiability Request to add/delete/modify/vary functionality. design. class. change/delete data. access system services. QA. capacity. reduce availability Testability Analysis.

Lecture 1 1-Nov-11 .Today’s take away  Software architecture is about  Balance  Abstraction  Structure(s)  Quality attributes  Are the requirements for SA  Have to be captured  Scenarios 62 Software Architectures.

UK  read  e Search “Grady Booch on Architecture”  Papers and other downloads on SA 63 Software Architectures. Lecture 1 1-Nov-11 .org/portal/web/computingno w/onarchitecture Grady Booch’s podcast “On Architecture”  http://www. Peter

Software Architectures Lecture 2 .

2011 .11.Roadmap of the course  What is software architecture?  Designing Software Architecture  Requirements: quality attributes or qualities  Today  How to achieve requirements : tactics  Next time:  How do tactics lead to architectural styles  Case studies on architectural styles 2 8.

11.Tactics  Qualities achieved via design decisions  What design decisions needed for achieving a specific quality?  Tactic  Design decision that influences the control of a quality attribute response  Architectural strategy  Collection of tactics 3 8.2011 .

11.Architectural style  A package of tactics  Tactics can refine other tactics  Redundancy is refined by data redundancy. code redundancy  Example  One availability tactic: introduce redundancy  Implication: we also need synchronization of replicas  To ensure the redundant copy can be used if the original fails 4 8.2011 .

2011 .Availability tactics  Failure  Deviation from intended functional behavior  Observable by system users  Failure vs fault  Fault: event which may cause a failure  Availability tactics  Keep faults from becoming failures  Make possible repairments 5 8.11.

2011 .Availability tactics (2) Availability Detection Fault Recoverypreparation and repair Voting Ping/Echo Active Heartbeat redundancy Exception Passive redundancy Spare 6 Recoveryreintroduction Prevention Fault masked Removal Repair made Shadow from service State Transactions resynchronization Process Rollback monitor 8.11.

Fault detection: Ping/Echo  Comp. 2  Comp. 1 expects an ”echo” from comp.11.2011 . 2  Answer within predefined time period  Usable for a group of components  Mutually responsible for one task  Usable for client/server  Tests the server and the communication path  Hierarchy of fault detectors improves bandwidth usage 7 8. 1 issues a ”ping” to comp.

Fault detection: Heartbeat  Comp.11. 1 emits a ”heartbeat” message periodically  Comp.2011 . 1 assumed failed  Fault correcting comp. 2 listens for it  If heartbeat fails  Comp. 3 is notified  Heartbeat can also carry data 8 8.

response  When a fault class recognized. crash. timing.2011 .11.Fault detection: Exceptions  Fault classes: omission. exception is raised  A fault consequently is recognized  Exception handler  Executes in same process that introduced the exception  Typically does a semantic transformation of fault into a processable form 9 8.

Component recovery: Voting  Processes running on redundant processors take equivalent input and compute output  Output sent to voter  Voter detects deviant behavior from a single processor => it fails it  Method used to correct  Faulty operation of algorithm  Failure of a processor 10 8.2011 .11.

11.2011 .Component recovery: active redundancy  All redundant components respond to events in parallel => all in same state  Response from only one comp used  Downtime: switching time to another up-to-date component (ms)  Used in client-server config (database syst)  Quick responses are important  Synchronization  All messages to any redundant component sent to all redundant components 11 8.

2011 .Component recovery: passive redundancy  Primary component  responds to events  informs standby components of state updates they must make  Fault occurs:  System checks if backup sufficiently fresh before resuming services  Often used in control systems  Periodical switchovers increase availability 12 8.11.

2011 .Component recovery: spare  Standby spare computing platform configured to replace many different failed components  Must be rebooted to appropriate SW config  Have its state initialized when failure occurs  Checkpoint of system state and state changes to persistent device periodically  Downtime: minutes 13 8.11.

11.Component reintroduction: shadow operation  Previously failed component may be run in ”shadow” mode  For a while  To make sure it mimics the behavior of the working components  Before restoring it to service 14 8.2011 .

more lead to complicated SW 15 8.2011 .Component reintroduction: state resynchronization  Passive and active redundancy  Restored component upgrades its state before return to service  Update depends on  Downtime  Size of update  Number of messages required for the update  One preferable.11.

11. with detectably inconsistent state: system restored using  A previous checkpoint of a consistent state  Log of transactions occurred since 16 8.2011 .Component reintroduction: checkpoint/ rollback  Checkpoint  Record of a consistent state  Created periodically or in response to specific events  Useful when a system fails unusually.

t. s. the whole bundle can be undone at once  Process monitor  If process fault detected.Component prevention  Removal from service  Comp removed from operation to undergo some activities to prevent anticipated failures  Exp: rebooting comp to prevent memory leaks  Automatic (design architecture) or manual (design system)  Transactions  sequential steps bundled together. then monitoring process deletes non-performing process and creates new instance of it  initialized to some appropriate state as in the spare tactic .

11.2011 . modify and deploy changes  Sets of tactics  Localize modifications  Reduce nr of modules affected by a change  Prevent ripple effects  Limiting modifications to localized modules  Defer binding time  Controlling deployment time and cost 18 8. test.Modifiability tactics  Goal: controlling time and cost to implement.

11. Deployed Within Time and Budget 8. Tested.2011 .Modifiability tactics (2) Modifiability Localize changes Changes arrive 19 Semantic coherence Anticipate expected changes Generalize module Abstract common services Prevention of ripple effects Hide information Maintain existing interface Restrict comm paths Use an Intermediary Defer binding time Runtime registration Configuration files Polymorphism Component replacement Adherence to defined protocols Changes Made.

Localize modifications: maintain semantic coherence  Semantic coherence: relationships among responsibilities in a module  Goal: ensure all these responsibilities work together w/o excessive reliance on other modules  Goal achievement: design modules with responsibilities in semantic coherence 20 8.11.2011 .

2011 .Localize modifications: abstract common services  Subtactic of semantic coherence  Provides common services through specialized modules  Reuse and modifiability  Modifications to common services done only once rather than in every module using them  Modifications to modules using common services do not impact other users 21 8.11.

Localize modifications: anticipate expected changes  Considering the set of envisioned changes provides way to evaluate particular assignment of responsibilities  Questions  For a change: does proposed decomp.11.2011 . limit the set of modules needing modif?  Fundamentally diff. changes: do they affect the same modules?  Goal: minimizing effects of changes 22 8.

11.2011 .Localize modifications: generalize the module  Generalize a module by making it compute a broader range of functions due to its input type  Input  defining language for the module  Making constants input paramaters  Implementing the module as an interpreter and making the input parameters be programs in that interpreter’s language  The more general the module  The most likely is that requested changes can be made by adjusting input language 23 8.

Prevent ripple effects  Localize modifications vs limit modifications to localized modules  There are modules directly affected  Whose responsibilities are adjusted to accomplish change  There are modules indirectly affected by a change  Whose responsibilities remain unchanged BUT implementation needs to be changed to accommodate the directly affected modules 24 8.2011 .11.

11.2011 .Ripple effects  Ripple effect from a modification  The necessity of making changes to modules not directly affected by it  This happens because said modules are SOMEHOW dependent on the modules directly dealing with the modification 25 8.

sequence. quality of service. identity of interface.2011 .11. location of A. existence of A.Dependency types  We assume  Module A changed to accomplish particular modification  Module B changed only because A changed  There are several dependency types  Syntax. semantics. resource behavior of A 26 8.

Syntax dependency  Of data  B consumes data produced by A  Type and format of data in both A and B need to be consistent  Of service  B invokes services of A  Signature of services produced by A need to be consistent with B’s asumptions 27 8.2011 .11.

2011 .11.Semantics dependency  Of data  B consumes data produced by A  Semantics of data produced by A and consumed by B need to be consistent with B’s asumptions  Of service  B invokes services of A  Semantics of services produced by A need to be consistent with B’s asumptions 28 8.

11.Sequence dependency  Of data  B consumes data produced by A  B must receive the data produced by A in a fixed sequence  Of control  A must have executed previously within certain time constraints 29 8.2011 .

11.Identity of interface of A  A may have multiple interfaces  B uses one of them  For B to compile and execute correctly.2011 . the identity (name or handle) of the interface must be consistent with B’s assumptions 30 8.

Other dependencies  Runtime location of A  Must be consistent with B’s assumptions  Quality of service/data provided by A  Properties involving the above quality must be consistent with B’s assumptions  Existence of A  For B to execute.11.2011 . A must exist  Resource behavior of A  Must be consistent with B’s assumptions 31 8.

2011 .Tactics for ripple effect prevention  Information hiding  Maintain existing interfaces  Restrict communication paths  Use intermediary 32 8.11.

11.Information hiding  Decomposition of responsibilities into smaller pieces and choosing which information to make private and which public  Public information available through specified interfaces  Goal: isolate changes within one module and prevent changes from propagating to others  Oldest technique from preventing changes from propagating  Strongly related to ”anticipate expected changes” (it uses those changes as basis for decomposition) 33 8.2011 .

Maintain existing interfaces  B syntax-depends on A’s interface  Maintaining the interface lets B stay unchanged  Interface stability  Separating interface from implementation  How to implement the tactic  Adding interfaces  Adding adapter  Providing a stub for A 34 8.2011 .11.

2011 .11.Restrict communication paths  Restrict number of modules with which the given module shares data  Reduce nr of modules that consume data produced by given module  Reduce nr of modules that produce data consumed by given module ⇒Reduced ripple effect  Data production/consumption introduces dependencies 35 8.

Use an intermediary  B dependent on A in other ways than semantically  Possible to introduce an intermediary to manage the dependency  Data (syntax)  Service (syntax)  Location of A  Existence of A 36 8.2011 .11.

Defer binding time
 Decision can be bound into executing system at

various times
 Binding at runtime
 System has been prepared for that binding
 All testing and distribution steps already completed
 Supports end user/administrator making settings or

providing input that affects behavior



Tactics with impact at
 Runtime registration
 Plug-and-play operation, extra overhead to manage


set parameters at start-up
Polymorphism - late binding of method calls
Component replacement – loadtime binding

 Configuration files 

 Adherence to defined protocols
 Runtime binding of independent processes



Performance tactics
 Goal: generate response to an event arriving at

system within time constraint
 Event: single or stream
 Message arrival, time expiration, significant state

change, etc
 Latency: time between the arrival of an event and the

generation of a response to it
 Event arrives
 System processes it or processing is blocked



Performance tactics (2)

Events efficiency
Manage event
frequency of



time limit


Resource demand tactic
Source of resource demand: event stream
Demand characteristics

Time between events in resource stream (how
often a request is made in a stream)
How much of a resource is consumed by each

Reducing latency tactic


Reduce required resources
Reduce nr of processed events


Reduce required resources
 Increase computational efficiency
 Processing involves algorithms => improve

 Resources may be traded for one another
 Reduce computational overhead
 If no request for a resource => its processing needs

are reduced
 Intermediaries removed



Reduce nr of processed events
 Manage event rate
 Reduce sampling frequency at which environmental
variables are monitored
 Control frequency of samplings
 If no control over arrival of externally generated
events => queued requests can be sampled at a
lower frequency (request loss)
 Bound execution times
 Limit over how much execution time used for an
 Bound queue sizes
 Controls max nr of queued arrivals


Resource management
 Introduce concurrency
 Process requests in parallel
 Different event streams processed on different threads

(create additional threads)
 Load balancing

 Maintain multiple copies of data and

 Caching and synchronization

 Increase available resources
 Faster processors and networks, additional
processors and memory



Resource arbitration
 Resource contention => resource must be

 Architect’s goal
 Understand characteristics of each resource’s use

and choose compatible scheduling
 Understand possibly conflicting criteria for
 And effect of chosen tactic

 Scheduling policy
 Priority assignment
 Dispatching


 What: network, buffers, processors
 Competing criteria for scheduling
 Optimal resource usage
 Request importance
 Minimizing nr of used resources
 Minimizing latency
 Maximizing throughput
 Preventing starvation to ensure fairness

 Dispatching can happen only when assigned

resource available
 Pre-emptying might occur



Scheduling policies
 First in/first out (FIFO)
 OK if all requests are of equal importance and take same

 Fixed priority scheduling, priorities based on
 Semantic importance (domain specific)
 Deadline monotonic (real-time deadlines; shortest

deadline 1st)
 Rate monotonic (periodic streams, shorter period 1st)
 Dynamic priority scheduling
 Round robin
 Earliest deadline first

 Static scheduling

recovering from attacks  House defense analogy  Door lock  Motion sensor  Insurance 48 8.11. detecting attacks.2011 .Security tactics  Goal: resisting attacks.

Security tactics (2) Security Resisting attacks Attack Authenticate users Authorize users Maintain data confidentiality Maintain integrity Limit exposure Limit access Detecting attacks Recovering from attacks Restoration Intrusion detection Identification See availability System Detects. or Recovers from attacks Audit trail 49 8.2011 .11. Resists.

2011 . DMZ 50 8.Resisting attacks  Authenticate users  Passwords.11. digital certificates. hash results help  Limit exposure: limited services on each host  Limit access: firewalls. biometric id  Authorize users  Access control patterns  Maintain data confidentiality  Encryption to data and communication links  Maintain integrity  Checksums. one-time passwords.

payload size. addresses. port numbers 51  Must have  Sensor to detect attacks  Manager for sensor fusion  Databases for storing events for analysis  Tools for offline reporting and analysis  Control console to modify intrusion detection actions 8.2011 .11. TCP flags.Detecting attacks  Intrusion detection system  Compares network traffic patterns to database  Misuse => pattern compared to historical patterns of known attacks  Anomaly => pattern compared to historical baseline of itself  Filtering  Protocol.

Intrusion detectors  Sensor to detect attacks  Managers for sensor fusion  Databases for storing events for later analysis  Tools for offline reporting and analysis  Control console  Analyst can modify intrusion detection actions 52 8.11.2011 .

2011 . domain name services. access control lists.Recovering from attacks  Tactics for restoring state  Recovering a consistent state from an inconsistent one: availability tactics  Redundant copies of system adm data  Passwords. user profile data: special attention  Tactics for attacker identification  For preventive or punitive purposes  Maintain audit trail 53 8.11.

11.2011 .Audit trail  Copy of each transaction applied to data in the system + identifying information  Can be used to  Trace the actions of an attacker  Support non-repudiation  Provides evidence that a particular request was made  Support system recovery  Often attack targets  Should be maintained in trusted fashion 54 8.

Testability tactics  Goal: allow for easier testing when some increment of software development is completed  Enhancing testability not so mature but very valuable  40% of system development  Testing a running system (not designs)  Test harness  SW that provides input to the SW being tested and captures the output  Goal: find faults 55 8.11.2011 .

11.Testability tactics (2) Testability Manage Input/Output Completion of an Increment 56 Record/Playback Separate Interface from Implementation Specialized Access Routines/ Interfaces Internal Monitoring Built-In Monitors Faults detected 8.2011 .

input to another  Saved in repository  Allows test input for one component  Gives test output for later comparisons 57 8.2011 .11.I/O Tactics: record/playback  Refers to  Capturing info crossing an interface  Using it as input to the test harness  Info crossing an interface at normal operation  Output from one component.

I/O Tactics: interface vs implementation  Separating interface from implementation  Allows substitution of implementations for various testing purposes  Stubbing implementations let system be tested without the component being stubbed  Substituting a specialized component lets the component being replaced to act as test harness for the remainder of the system  Tactic also achieves modifiability 58 8.2011 .11.

11.2011 .I/O Tactics: specialize access routes/interfaces  Having specialized testing interfaces  Captures/specifies variable values for components  Via test harness  Independently from normal execution  Specialized access routes/interfaces  Should be kept separate from required functionality  Hierarchy of test interfaces  Test cases can be applied at any architectural level  Testing functionality in place to observe responses 59 8.

etc accessible through interfaces  Permanent interface or temporarily introduced for testing  Record events when monitoring states activated  Additional testing cost/effort  Increased visibility 60 8. performance load.11.Internal monitoring tactic  Built-in monitors  Component can maintain state. capacity.2011 . security.

11.2011 .Usability tactics  Usability concerns  How easy can a user accomplish desired task  What is the system support for the user  Tactics  Runtime: support user during system execution  Design time: support interface developer  Iterative nature of interface design  Related to modifiability tactics  Refinement of semantic coherence tactic to localize expected changes 61 8.

11.Runtime tactics  User feedback as to what is the system doing  Providing user with ability to issue usability commands  Cancel  Undo  Aggregate  Show multiple views 62 8.2011 .

system state 63 8. task.2011 .11.Initiatives  HCI terminology  User initiative  System initiative  Mixed initiative  User initiative  Architect designs response as for any other functionality  System initiative  System needs models: user.

Usability tactics Usability Runtime tactics user System initiative request User initiative 64 Design time tactics Separate user interface User given appropriate feedback and assistance 8.11.2011 .

Todays take away  There are many ways to achieve a QA – tactics  Can work well or less well  Can interact with other tactics for achieving other QAs  A Software Architecture – determined by the collection of tactics 65 8.11.2011 .

Software Architectures Lecture 3 .

Roadmap of the course  What is software architecture?  Designing Software Architecture  Requirements: quality attributes or qualities  How to achieve requirements : tactics  Today:  How do tactics lead to architectural styles  Case studies on architectural styles  to also observe the achieved qualities 2 10-Nov-11 .

pre/post conditions. event broadcast  Properties: specify info for construction & analysis  Examples: signatures. databases. ADTs  Connectors: mediate interactions of components  Examples: procedure calls. pipes. objects.Elements of Architectural Descriptions  The architectural definition of a system selects  Components: define the locus of computation  Examples: filters. RT specifications  An architectural style defines a family of architectures constrained by  Component/connector vocabulary  Topology rules  Semantic constraints 3 10-Nov-11 .

Some Architectural Styles  Data flow systems  Batch sequential  Pipes and filters  Call-and-return systems  Main program & subroutines  Hierarchical layers  OO systems  Virtual machines  Interpreters  Rule-based systems  Independent components  Communicating processes  Event systems  Data-centered systems (repositories)  Databases  Blackboards 4 10-Nov-11 .

Questions we ask of each style  What is the design vocabulary?  What are the allowable structural patterns?  What is the underlying computational model?  What are the essential invariants of the style?  What are some common examples of its use?  Advantages and disadvantages of using the style  Common specializations of the style 5 10-Nov-11 .

Data Flow Systems  The availability of data controls the computation  The structure of the design is dominated by the orderly motion of data from process to process  The pattern of data flow is explicit  No other interaction between processes  Types  Batch sequential  Pipes and filters  Feedback loop 6 10-Nov-11 .

transformation. latency 7 10-Nov-11 .Control flow vs Data flow  Control flow  Dominant question: how the locus of control moves throughout the execution  Data may accompany control but is not dominant  Reasoning is on the computation order  Data flow  Dominant question: how data moves through a collection of (atomic) computations  As data moves. control is activated  Reasoning is on data availability.

Batch Sequential Systems  Processing steps are independent programs  Each step runs to completion before next step starts  Atomic computations  Data transmitted as a whole between steps  Typical applications  Classical data processing  Program developments validate 8 sort update report 10-Nov-11 .

shares no state with other filters  Does not know identity of incoming and outgoing streams 9 10-Nov-11 .Pipes and Filters  Each component has  Set of inputs (read)  Set of outputs (produced)  Filter  Incrementally transforms some amount of the data at inputs to data at outputs  Stream-to-stream transformations  Local transformation  Uses little local context in processing stream  Independent.

typed pipes  Batch sequential systems: degenerated pipeline 10 10-Nov-11 . bounded pipes.Pipes and Filters cont’d  Pipe  Move data from a filter output to a filter input  Pipes form data transmission graphs  Overall computation  Run pipes and filters (non-deterministically) until no more computations are possible  Correctness of p&f network’s output should not depend on ordering  Specializations  Pipelines.

code generation  Signal processing domains  Parallel programming  Distributed programming 11 10-Nov-11 . semantic analysis.Pipe and filter examples  Programs written in Unix shells  Filters: Unix processes  Pipes: runtime mechanisms for implementing them  Compilers (exp of pipeline)  (phases often not incremental)  Lexical analysis. parsing.

deadlock analysis)  Support concurrency  Disadv  Often lead to a batch organization of processing  Not good at handling interactive applications  Quite complex  Not so performant 12 10-Nov-11 . improvement  Allow analysis (throughouput.Advantages and disadvantages  Adv  Overal I/O is a composition of the behavior of independent filters  Support reuse  Maintainability.

ADT  (Hierarchical) layers 13 10-Nov-11 .Call-and-Return systems  The control moves from a module to another and back  Different from monolithic systems or pipe and filter systems  Abstraction made possible  Types  Main program and subroutine  OO.

Main Program and Subroutines  Hierarchical decomposition  Based on definition-use relationship  Single thread of control  Supported directly by programming languages  Subsystem structure implicit  Subroutines typically aggregated to modules  Hierarchical reasoning  Correctness of a subroutine depends on the correctness of the subroutines it calls 14 10-Nov-11 .

15 10-Nov-11 .

Abstract data types and OO  ”If you get the data structures right. the rest of the program much simpler” 16 .

Object-orientation  Object: collection of data and operations  Class: description of set of objects  Subclass: class with additional properties  More restrictive than class => fewer members  Instance: object of a class  Method: procedure body implementing operation  Dynamically bound  Message: procedure call. support REUSE 17 10-Nov-11 . request to execute method  Properties: intuitive.

Object architectures  Encapsulation  Restrict access to certain information  Object responsible for preserving integrity of its representation (invariant)  Inheritance  Share one definition of shared functionality  Dynamic binding  Determine actual operation to call at runtime  Management of many objects  Provide structure on large set of definitions  Reuse and maintenance  Exploit encapsulation and locality 18 10-Nov-11 .

19 10-Nov-11 .

Advantages and disadvantages  Advantages  Maintainability: modifiability of method bodies  Architecture anticipates (some) changes  Reuse  Disadvantages  Identity of interacting objects need to be known -> and needs to be changed in all objects interacting with an object whose identity was modified  Side effect problems  Managing many objects (additional structuring needed) 20 10-Nov-11 .

often set of procedures  Various scoping regimes  Opaque versus translucent layers 21 10-Nov-11 .Layered Systems  Each layer provides certain facilities  Hides part of lower layer  Provides well-defined interfaces  Serves various functions  Kernels: provide core capability.

22 10-Nov-11 .

Advantages and disadvantages of layered systems  Advantages  Abstraction (deals with complexity)  Modifiability  Changing one layer influences only the two adjacent layers  Reuse  Different implementations easy to substitute  Interfaces  Disadvantages  Not all systems suitable for this  Performance may require other coupling  Abstraction quite hard 23 10-Nov-11 .

Interpreters  Execution engine simulated in software  Data  Representation of program being interpreted  Data (program state) of program being interpreted  Internal state of interpreter  Control resides in “execution cycle” of interpreter  But simulated control flow in interpreted program resides in internal interpreter state  Syntax-driven design 24 10-Nov-11 .

25 10-Nov-11 .

Rule-based systems  Store and manipulate knowledge to interpret information in a useful way  Especially used in artificial intelligence  Exp  Doctor diagnoses based on symptoms  Game move deduced  Components  List of rules or rule base  An inference engine  Temporary working memory  User interface 26 10-Nov-11 .

27 10-Nov-11 .

Communicating Processes  Components: independent processes  Typically implemented as separate tasks  Connectors: message passing  Point-to-point  Asynchronous and synchronous  RPC and other protocols can be layered on top 28 10-Nov-11 .

Event Systems  Components: objects or processes  Interface defines a set of incoming procedure calls  Interface also defines a set of outgoing events  Connectors: event-procedure bindings  Procedures are registered with events  Components communicate by announcing events at “appropriate” times  When an event is announced the associated procedures are (implicitly invoked)  Order of invocation is non-deterministic  In some treatments connectors are event-event bindings 29 10-Nov-11 .

Advantages and disadvantages of event systems  Advantages  Support reuse: any component can be introduced in the system simply by registering it for the events of the system  Implicit invocation => easy evolution (modifiability)  Disadvantages  No control over the overall computation  Component does not know what other components respond  Component may know who responds but does not know order  Data exchange  Can provoke performance problems  Reasoning about correctness: problematic 30 10-Nov-11 .

Classical Databases
 Central data repository
 Schemas designed specifically for application
 Independent operators
 Operations on database implemented
independently, one per transaction type
 Interact with database by queries and updates
 Control
 Transaction stream drives operation
 Operations selected on basis of transaction type





The Blackboard Model
 Knowledge sources
 World and domain knowledge partitioned into
separate, independent computations
 Respond to changes in blackboard
 Blackboard data structure
 Entire state of problem solution
 Hierarchical, nonhomogeneous
 Only means by which knowledge sources interact to
yield solutions
 Control
 In model, knowledge sources self-activating




Some case studies



 In his paper (1972) David Parnas proposed

the following problem
The KWIC (Key Word in Context) index system
accepts an ordered set of lines; each line is an
ordered set of words, and each word is an ordered
set of characters. Any line may be “circularly
shifted” by repeatedly removing the first word and
appending it at the end of the line. The KWIC index
system outputs a listing of all circular shifts of all
lines in alphabetical order.
(On the Criteria to be Used in Decomposing Systems into
Modules - discusses the important design decisions that
impact how we modularize our software systems)


Architectural solutions for KWIC
 Shared data
 Abstract Data Types
 Implicit invocation
 Pipe-and-filter



KWIC design issues
 Changes in the processing algorithm
 Line shifting on each line after it is read, on all lines

after they are read or on demand
 Changes in the data representation
 Enhancement to system function
 Performance
 Reuse



Main Program/Subroutine with
shared data
 Problem decomposed according to 4 basic

 Input, shift, alphabetize, output

 Components coordinated by main program

that sequences through them
 Data in shared storage
 Communication: unconstrained read-write
 Coordinator ensures sequential access to data



KWIC – shared data solution



Shared data, pro and cons
 Advantages
 Data can be represented efficiently
 Intuitive appeal

 Disadvantages
 Modifiability
 Change in data format affects all components
 Change in overall processing algorithm
 Enhancements to system function
 Reuse not easy to do



with interfaces  Data is not shared by computational components  Accessed via interfaces 42 10-Nov-11 .Abstract data types (ADT)  Similar set of five modules.

ADT solution 43 10-Nov-11 .KWIC.

pro and cons  Advantages  Logical decomposition into processing modules similar to shared data  Algorithms/data can be changed in individual modules w/o affecting others  Better reuse (module has fewer assumptions about other modules)  Disadvantages  Enhancing the function  Modify existing modules -> bad for simplicity.ADT. integrity  Add new modules -> performance penalties 44 10-Nov-11 .

Implicit invocation  Shared data as the integration mechanism  More abstract data interfaces  Data accessed as a list/set  Computations invoked implicitly when data is modified  Line added -> event to shift module  Circular shifts produced in another shared data store -> event to alphabetizer. invoked 45 10-Nov-11 .

implicit invocations 46 10-Nov-11 .KWIC.

pro and cons  Advantages  Functional enhancements easily  Data changes possible  Reuse  Disadvantages  Difficult to ctrl processing order of implicitly invoked modules  Data representation uses more space 47 10-Nov-11 .Implicit invocation.

alphabetize.Pipe and filter  Four filters  Input. shift. output  Process data and send it to the next  Distributed ctrl  Data sharing  Only the one transmitted on pipes 48 10-Nov-11 .

KWIC. pipes and filters 49 10-Nov-11 .

Pipe and filter. pros and cons  Advantages  Maintains intuitive flow of processing  Reuse supported  New functions easily added  Amenable to modifications  Disadvantages  Impossible to modify design to get interactive system  Data is copied between filters –> space used inefficiently 50 10-Nov-11 .

invocation Pipe and filter Changes in the processing algorithm - - + + Changes in the data representation - + - - Enhancement to system function + - + + + - + + - + Performance Reuse 10-Nov-11 51 .Comparison Shared data ADT Impl.

Instrumentation software  Develop a reusable system architecture for oscilloscopes  Rely on digital technology  Have quite complex software  Reuse across different oscilloscope products  Tailor a general-purpose instrument to a specific set of users  Performance important  Rapid configuration of software within the instrument => Domain-specific software architecture 52 10-Nov-11 .2.

53 10-Nov-11 .

trigger modes.Object-oriented model of software domain  Clarified the data types used for oscilloscopes  Waveforms. …  No overall model to explain how the types fit together  Confusion about partitioning of functionality  Should measurements be associated with types of data being measured or represented externally?  Which objects should the user interface interact with? 54 10-Nov-11 . measurement. signals.

55 10-Nov-11 .

Layered model of the oscilloscope  Well-defined grouping of functions  Wrong model for the application domain  Layer boundaries conflicted with the needs of the interaction among functions  The model suggest user interaction only via Visualization. etc) 56 10-Nov-11 . but in practice this interaction affects all layers (setting parameters.

Pipe-and-filter model  Signal transformers used to condition external signals  Acquisition transformers derive digitized waveforms     from these signals Display transformers convert these waveforms into visual data Oscilloscope functions were viewed as incremental transformers of data Corresponds well with the engineers’ view of signal processing as a dataflow problem Main problem:  How should the user interact? 57 10-Nov-11 .

58 10-Nov-11 .

Modified pipe-and-filter model  Each filter was associated with a control interface  Provides a collection of settings to be modified dynamically by the user  Explains how the user can make incremental adjustments to SW  Decouples signal-processing from user interface  Signal-processing SW and HW can be changed without affecting the user interface as long as the control interface remains the same 59 10-Nov-11 .

60 10-Nov-11 .

Modified pipe-and-filter model. more  Further specialization  Pipe-and-filter lead to poor performance  Problems with internal storage and data exchange between filters  Waveforms have large internal storage => not practical for filters to copy waveforms every time they process them  Filters may run at radically different speeds  Not good to slow faster filter just to keep the pace with slower ones  Solution: several types of pipes (distinct colours)  Some allowed data processing w/o copying  Slow filters allowed to ignore incoming data when already processing other data  => the pipe/filter computations more tailorable 61 10-Nov-11 .

62 10-Nov-11 .

Instrumentation software summary  Case study shows  Some issues for developing architectures for industrial SW  Different styles => different effects on solution  Software must be typically adapted from pure forms to specialized styles (domain specific)  Here the result depended on properties of pipeand-filter architecture adapted to satisfy the needs of the product family 63 10-Nov-11 .

3. …  Build software to control the robot  External sensors and actuators  Real-time  Input provided by sensors  Control the motion  Plan the future path 64 10-Nov-11 . space vehicle. submarine. Mobile Robotics  The system controls a manned or partially manned vehicle  Car.

Mobile Robotics con’t  Complicating factors  Obstacles may block the path  Imperfect sensor input  Robot might run out of power  Accuracy in movement  Manipulation with hazardous material  Unpredictable events might lead to need of rapid response 65 10-Nov-11 .

Mobile Robotics con’t  Consider four (4) architectural designs  Control loop  Layered design  Implicit invocation  Blackboard 66 10-Nov-11 .

performance  Req 4: flexibility  Application development requires experimentation and reconfiguration 67 10-Nov-11 . safety.Mobile Robotics con’t  Design considerations  Req 1: deliberative and reactive behaviour  Coordinate robot actions with environment reactions  Req 2: uncertainty  The robot needs to act based on incomplete and unreliable information  Req 3: account for dangers  Fault tolerance.

application depends on complexity and predictability  Robot in another planet => fault tolerance  The four requirements guide the evaluation of the four architectural alternatives 68 10-Nov-11 .Mobile Robotics con’t  Requirements of different kind.

Solution 1: control loop  A mobile robot uses a closed-loop paradigm  The controller initiates robot actions and monitors their consequences. adjusting plans 69 10-Nov-11 .

simplicity a problem in unpredictable environments Implicit assumption: continuous changes in environment require continuous reaction  Robots face discrete events  Switch between behaviour modes .how to change between modes?   How to decompose the software into cooperating components? 70 10-Nov-11 .Solution 1 con’t  The four requirements?  Req 1: deliberative and reactive behaviour  + simplicity of paradigm  .

Solution 1 con’t  The four requirements?  Req 2: uncertainty  . motors) separate and replaceable 71 10-Nov-11 .A trial-and-error process  Req 3: account for dangers  + simplicity makes duplication easy  Req 4: flexibility  + the major components (supervisor. sensors.

Solution 1 con’t  Summary:  Paradigm appropriate for simple robotics  Can handle only a small number of external events  No really for complex decomposition of tasks 72 10-Nov-11 .

joints.Solution 2: layered architecture  Eight (8) levels:  Level 1: Robot control routines (motors. …)  Levels 2&3: input from the environment  Sensor interpretation and integration  Level 4: robot’s model of the real world  Level 5: navigation  Levels 6&7: scheduling and planning of robot actions  Dealing with problems in level 7  Level 8: user interface and supervisory functions 73 10-Nov-11 .

does not fit the actual data and control-flow patterns  .5-8) 74 10-Nov-11 .does not separate the data hierarchy (1-4) from the control hierarchy (1.Solution 2 con’t  The four requirements?  Req 1: deliberative and reactive behaviour  + More components to delegate tasks to  + indicates concerns that must be addressed  Sensor integration  + defines abstraction levels to guide the design  Robot ctrl vs navigation  .

complex relationships between layers can become difficult to manage 75 10-Nov-11 .interlayer dependencies an obstacle  .Solution 2 con’t  The four requirements?  Req 2: uncertainty  + abstraction layers manage this  Req 3: account for danger  + managed by the abstraction mechanism: data and commands are analysed from different perspectives  Fault tolerance and passive safety ok. active safety not ok  Req 4: flexibility  .

Solution 2 con’t  Summary:  Provides a framework for organizing components  Precise about roles of layers  Problems when adding detail at implementation level  The communication pattern in a robot will not follow the scheme of the architecture 76 10-Nov-11 .

Solution 3: implicit invocation  Task-control architecture  Based on hierarchies of tasks  Task trees  Parent tasks initiate child tasks  Software designer can define temporal dependencies between tasks  Dynamic reconfiguration of task trees at run time  Uses implicit invocation to coordinate interaction between tasks  Tasks communicate by multicasting messages via a message server (redirects msgs to tasks registered to handle them) 77 10-Nov-11 .

Solution 3 con’t  TCA’s implicit invocation of msgs supports:  Exceptions: exception handling override tasks  Change processing mode  Can abort or retry tasks  Better suited for managing spontaneous events  Wiretapping: intercept messages by superimposed tasks  Safety-checks of outgoing commands  Monitors: read information and execute actions  Fault-tolerance issues using agents to supervise the system 78 10-Nov-11 .

though in practice limited by the central message server ⇒ .Solution 3 con’t  The four requirements?  Req 1: deliberative and reactive behaviour  + Separation of action and reaction via the task trees and exceptions.relies on a central control point 79 10-Nov-11 . wiretapping and monitors  + concurrency explicit: multiple actions can proceed simultaneously and independently  .

monitors  + fault tolerance by redundancy Multiple handlers registered for same signal. one fails another takes over  Multiple occurrences of same request: concurrently   Req 4: flexibility  + implicit invocation allows incremental development and replacement of components  80 Often sufficient to register new handlers in central server 10-Nov-11 .not explicitly in the model  Maybe via task trees and exceptions  Req 3: dangers  + exception. wiretapping.Solution 3 con’t  The four requirements?  Req 2: uncertainty  .

Solution 3 con’t  Summary:  TCA offers a comprehensive set of features for coordinating tasks  Appropriate for complex robot projects 81 10-Nov-11 .

Solution 4: blackboard  Based on the following components:      82 Captain: overall supervisor Map navigator: high-level path planner Lookout: monitors the environment Pilot: low-level path planner and motion controller Perception subsystem: raw input from sensors and its integration to an interpretation 10-Nov-11 .

control flow must be coerced to fit the database mechanism  Components do not communicate directly  Req 2: uncertainty  + blackboard the means for resolving conflicts and uncertainties  All data available in the database 83 10-Nov-11 .Solution 4 con’t  The four requirements?  Req 1: deliberative and reactive behaviour  + components interact via the shared repository  .

wiretapping.Solution 4 con’t  The four requirements?  Req 3: account for dangers  + communication via a central service. the database  Exception handling. monitors can be implemented by adding modules that watch the database for certain signs of problematic situations  Req 4: flexibility  + Supports concurrency  + Decouples senders from receivers  84 Facilitates maintenance 10-Nov-11 .

Solution 4 con’t  Summary:  The architecture is capable of modelling the cooperation of tasks  Coordination  Resolving uncertainty  Slightly less powerful than TCA  Not the only possibilities for robotics … 85 10-Nov-11 .

invocation Blackboard +- - ++ + - +- +- + ++++- +++- ++ ++ ++ + + + + + 86 .Comparison Control loop Layers Task coordination Dealing with uncertainty Fault tolerance Safety Performance Flexibility 10-Nov-11 Impl.

Today’s take away  A basic collection of architectural styles is necessary  Small case studies are useful for illustrative purposes  Same (rather basic) ideas come back in our field  Dropbox  Cloud computing  Wikipedia 87 10-Nov-11 .

Software Architectures Lecture 4 .

Roadmap of the course  What is software architecture?  Designing Software Architecture  Requirements: quality attributes or qualities  How to achieve requirements : tactics  How do tactics lead to architectural styles  Case studies on architectural styles. observe the achieved qualities  Today: how to build an architecture with ADD method  First exercise set is available on the web 2  Return answers in 1 week 15-Nov-11 .

    3 Applies to one system Describes element types.SA terminology.3 Software architecture 4. how they interact. how the product functionality is mapped to them Describes the instances that exist in the system Level of specificity needed to design a system 15-Nov-11 .

Requirements analysis. Integration. Coding.Architecture in the life cycle  Evolutionary Delivery Life Cycle  User and customer feedback  Iterate through several releases before final release  Adding of functionality with each iteration Domain analysis. Risk analysis SA design Hardware Architecture design Detailed design. Testing 4 15-Nov-11 .

Evolutionary delivery life cycle 5 15-Nov-11 .

Requirements  Architecture is shaped by requirements  Functional. and business requirements  Called architectural drivers  Identifying drivers  Determine highest priority business goals (few!)  Turn these business goals into quality scenarios  Choose the ones with most impact on architecture: these are the architectural drivers (less than 10) 6 15-Nov-11 . quality.

at each stage  Tactics are chosen to satisfy some qualities  Functionality is added to instantiate the module types provided by the tactic  Input: the set of quality scenarios for drivers  Key drivers may change during design.Attribute-Driven Design (ADD) method  Method to design architecture so that both functional and quality requirements are met  Defines SA by decomposing based on the quality attributes  Recursive decomposition process. due to  Better understanding or changing of requirements 7 15-Nov-11 .

ADD output  First several levels of a module decomposition view of an architecture  Not all details of the views result from applying ADD  Necessarily coarse grained  System described as  a set of containers for functionality  the interactions among the containers  Critical for achieving desired qualities  Provides framework for achieving the functionality  Difference between ADD output and an architecture ready for implementation  Detailed design decisions postponed  Flexibility 8 15-Nov-11 .

Case study  Garage door opener  Responsible for raising and lowering the garage door. via  Switch  Remote control  Home information system  It is possible to diagnose problems of opener from the home information system (HIF)  Product line architecture! (PLA) 9 15-Nov-11 .

Sample input  ADD assumes functional requirements and constraints as input  ADD also needs the quality requirements  Set of system-specific quality scenarios  These provide a checklist to be used for the development of system-specific scenarios  Only the necessary detail 10 15-Nov-11 .

Case study: quality scenarios  Device and controls for opening and closing the door are different for the different products in the product line  May include controls from within the HIF  Product architecture for a specific set of controls should be directly derivable from the PLA  Processor used in different products will differ  Product architecture for each specific processor should be directly derivable from the PLA 11 15-Nov-11 .

1 second  Garage door opener should be accessible for diagnosis and administration from within the HMI  Using a product-specific diagnosis protocol  Should be possible to directly produce an architecture that reflects this protocol 12 15-Nov-11 .Case study: quality scenarios 2  If an obstacle (person/object) is detected by garage door during descent. it must halt or re-open within 0.

ADD Steps  Choose the module (initially whole system) to decompose  Required input available for that module  Refine the module according to following steps  Choose architectural drivers  Choose architectural tactic/style that satisfies the drivers  Instantiate modules and allocate functionality  Define interfaces of child modules  Verify and refine use cases and quality scenarios and make them constraints for child modules  Repeat steps above for every module that needs further decomposition 13 15-Nov-11 .

submodule  Case study:  Garage door opener is the system  One constraint: opener must interoperate with the home information system (HIS) 14 15-Nov-11 .Choose module to decompose  Modules: system. subsystem.

Choose architectural drivers  Architectural drivers: functional and quality requirements that shape the architecture  Among the top priority requirements for the module  To be addressed in the initial decomposition of the system  Case study:  Real-time performance  Modifiability to support product lines  Online diagnosis supported 15 15-Nov-11 .

More on architectural drivers  Determining these drivers is not only in the beginning of the process  Exp: we need to see an example of a garage door to know we want it stopped in 0.1 sec  Less important requirements are satisfied within the constraints of the most important  We decompose based on drivers 16 15-Nov-11 .

Choose architectural style  For each quality attribute there are  Identifiable tactics and styles to implement them  Each tactic is designed to realize one/more attributes  The styles in which the tactics are embedded have impact on other attributes  Balance between qualities needed  We need to identify child modules required to implement the tactics 17 15-Nov-11 .

Choose architectural style 2  Goal of this step  Establish overall style consisting of module types  Style should satisfy drivers  Constructed by composing selected tactics  Selection guided by  Drivers  Side effects of pattern on other qualities 18 15-Nov-11 .

sensors.Choose architectural style: exp 1  Modifiability at design time  “localize changes” tactic: semantic coherence and information hiding  Separate responsibilities dealing with user interface. communication. diagnosis  First 3 virtual machines: they will vary for the different products to be derived from the PLA 19 15-Nov-11 .

Choose architectural style: exp 2  Performance  “resource demand” and “resource arbitration” tactics: increase computational efficiency and choose scheduling policy  Performance-critical computations made efficient  Performance-critical computations scheduled to achieve the timing deadline 20 15-Nov-11 .

Instantiate modules and allocate functionality  Allocate functionality  Use case for parent module => understand distribution of functionality  Add/remove child modules to fulfill required functionality  Every use case of parent module: representable by a sequence of responsibilities within child modules  Discover necessary info exchange  Information and producer/consumer roles 21 15-Nov-11 .

Instantiate modules and allocate functionality 2  Represent architecture with views  Dynamic and deployment info required to analyze achievement of qualities  We need additional views  Module decomposition view  Concurrency view  Deployment view 22 15-Nov-11 .

Concurrency view  Models dynamic aspects  Parallel activities  Synchronization  Identifies  Resource contention problems  Possible deadlock situations  Data consistency issues  Leads to uncover new responsibilities in the modules and possibly new modules  Recorded in module decomposition view  Exp new module: resource manager 23 15-Nov-11 .

cancels.Concurrency view 2  Component-and-connector view  Components: instances of modules  Connectors: carriers of virtual threads  Virtual thread: execution path through system or parts of it  Virtual versus operating system threads  Synchronizes with. starts. communicates with 24 15-Nov-11 .

Concurrency view 3  Shows instances of modules in module decomposition view for understanding mapping between views  Synchronization point located in a certain module  This responsibility assigned at right place  Crossing of two virtual threads: sign that some synchronization needed 25 15-Nov-11 .

Concurrency view 4  Use cases  Two users doing similar things at the same time  One user performing multiple activities simultaneously  Starting up the system  Shutting down the system 26 15-Nov-11 .

Concurrency view 5  Concurrency might also be a point of variation  Sequential initialization for some products. parallel for others  In this case the decomposition should support techniques to vary the initialization method  Exchanging component 27 15-Nov-11 .

Deployment view  New responsibilities from need to deploy  On multiple processors or specialized hardware  Deployment view decomposes virtual threads  Virtual threads on distinct processors  Messages between them  Basis for analyzing network traffic. see possible congestion 28 15-Nov-11 .

Deployment view 2  Decide if multiple instances of some modules are needed  Reliability  Supports reasoning about using special-purpose hardware  Architecture drivers help determining the allocation of components to hardware  Replication vs real-time scheduling 29 15-Nov-11 .

Define interfaces of child modules  Module interface  Services and properties provided and required  Different from signatures  Documents what others can use and on what they can depend  Module decomposition view documents  Producers/consumers on information  Patterns of interaction requiring modules to provide and use services 30 15-Nov-11 .

Define interfaces of child modules 2  Concurrency view documents  Interactions among threads. blocks calls 31 15-Nov-11 . sequentializes. leading to module interface providing or using a service  The info that a component is active  Own thread running  The info that a component synchronizes.

Define interfaces of child modules 3  Deployment view documents  Hardware requirements (special purpose HW)  Timing requirements  Exp: computation speed of processor  Communication requirements  Exp: information updates not more than once per second 32 15-Nov-11 .

Verify and refine  Decomposition into modules needs to be verified  Child modules need preparation for their own decomposition  Done for  Functional requirements  Constraints  Quality requirements 33 15-Nov-11 .

Functional requirements  Child modules have responsibilities  Derived from functional requirements decomposition  Use cases for the module  Split and refine parent use cases  traceability  Exp: use cases that initializes the whole system  Broken into initialization of subsystems 34 15-Nov-11 .

Case study  Initial responsibilities  Open/close door on request  Locally or remotely  Stop door within 0.1 sec when detect obstacle  Interact with HIS  Support remote diagnostics 35 15-Nov-11 .

Case study 2  Decomposition of responsibilities  User interface: recognize user requests and translate them into form expected by the raising/lowering door module  Raising/lowering door module:  control actuators to raise/lower door  Stop door when fully closed or fully open  Obstacle detection 36 15-Nov-11 .

Case study 3
 Decomposition of responsibilities, more:
 Communication VM
 Manage communication with HIS
 Sensor/actuator VM
 Manage interaction with sensors and actuators
 Scheduler
 Guarantee deadline
 Diagnosis
 Manage interaction with HIS for diagnosis



 Constraints of parent module satisfied by
 Decomposition satisfies the constraints
 Using certain OS
 Constraint satisfied by single child module
 Special protocol
 Constraint satisfied by multiple child modules
 Web usage requires two modules (client and server)



Case study
 Constraint: communication with HIS is maintained
 Communication virtual machine will recognize if this

is unavailable
 Constraint satisfied by a single child



Quality scenarios
 Need to be refined and assigned to child

 Possibilities
 QS completely satisfied by decomposition
 QS may be satisfied by decomposition with

constraints on child modules
 Layers and modifiability

 Decomposition neutral wrt QS
 QS assigned to child modules
 QS not satisfiable by decomposition
 Decomposition reconsidered or reason for this recorded
 Typical trade-offs



Case study
 Device and controls for opening and closing

the door are different for the different products
in the product line
 May include controls from within the HIF
 QS delegated to user interface module

 Processor used in different products will differ
 Product architecture for each specific processor
should be directly derivable from the PLA
 QS delegated to all modules



Case study 2
 If an obstacle (person/object) is detected by

garage door during descent, it must halt or reopen within 0.1 second
 QS delegated to scheduler and obstacle detection

 Garage door opener should be accessible for

diagnosis and administration from within the
 Using a product-specific diagnosis protocol
 QS split between diagnosis and communication



Step outcome
 Decomposition of module into children
 Each child has
 Set of responsibilities
 Set of use cases
 Interface
 Quality scenarios
 Collection of constraints
 Enough for next iteration of decomposition



Iteration progress
 Vocabulary of modules and their responsibilities
 Variety of use cases and quality scenarios and

understood some of their ramifications
 Information needs of modules
 Their interactions

 Not decided yet
 Communication language, algorithm for obstacle

detection, etc



Iteration outcome
 We defined enough to allocate work teams and

give them charges
 If we design a large system

 We can proceed to next iteration and decide on

answers for the questions
 If we design small system



Forming the team structure
 When modules fairly stable
 They can be allocated to development teams
(existing, new)
 Team structure mirror module decomposition
 Each team creates its own internal work

practices (or adopts a system-wide set)

Bulletin boards
Web pages
Naming conventions for files
Configuration control system

 Quality assurance and testing procedures set

up for each group

 Coordinate with others

Team communication
 Intra team
 High bandwidth

 Inter team
 Low bandwidth

 Assumes system designed based on separation

of concerns
 As software systems, the teams should strive for
loose coupling and high cohesion



unified set of services to the users  Domain – specialized knowledge or expertise  Examples  Module – user interface layer of systems  UI tools independent of UI communication with other modules  Module – process scheduler  Process number and algorithms: hidden  Most effective  Assign team members according to their expertise 48 15-Nov-11 .Modules as mini-domains  Modules encapsulate changeable details  They exhibit only the interface  Interface – common.

Organization  Architecture  The expertise determines the architecture  Database specialist  Telecom specialist 49 15-Nov-11 .

process synchronization. rule engine. CS coordination  Or install  Then: simplest functionality in each component  Then order decreasingly according to importance to project  Evolutionary Delivery Life Cycle (EDLC) .Creating a skeletal system  Provide underlying capability for implementing functionality  In order advantageous for project  Classical software engineering: stubbing out  Architecture-driven: sequence becomes clear  First  Implement the SW dealing with execution and interaction of arch comps  Scheduler.

Microsoft and EDLC  Complete skeletal system is early formed  Low-fidelity ”working” system  Rebuilt frequently (nightly)  => features can be judged if enough or not  Possible problem  First development team to complete portion of system defines interfaces  Penalty for more complex parts of the systems  Alleviation: negotiate interfaces in skeletal system early 51 15-Nov-11 .

Flight simulation example  Most sophisticated SW     Highly distributed Rigurous time requirements Modifiability needed Also integrability  The ease with which separately developed elements can be made to work together under SW requirements  Tactics  Keeping interfaces simple. stable  Adhering to defined protocols  Loose coupling. small. minimal dependencies  Components 52 15-Nov-11 .

Boeing simulators 53 15-Nov-11 .

Some history of the simulator  Very large (1.5 million LOC)  Long lifetimes (~40 years)  Stringent real-time and fidelity requirements  Simulator should behave EXACTLY like the real aircraft  Normal flight  Emergency maneuvers  Equipment failures  1987: Air Force investigates OO techniques  Existing simulators since 1960s. problems  Integration phase was increasing exponentially with size and complexity  Cost of modifications > cost of original system 54 15-Nov-11 .

surrounded by instruments  Look at visuals and need to take actions  How to operate the aircraft  How to perform maneuvers: mid-air refuelling  How to respond to situations: attack  Fidelity important  Environment  Individuals. initiate training situations 55 15-Nov-11 .Roles in the simulator  Crew  Inside a motion platform. atmosphere. threats. other aircraft  Instructor  Monitors. weapons.

nearby aircraft  The more fidelity. the more computational complexity 56 15-Nov-11 . local weather.Fidelity of models  Exp: air pressure  Model considers just the aircraft altitude  Model considers the aircraft altitude and local weather  Model considers the aircraft altitude.

testing  SA in the centre 57 15-Nov-11 .Today’s takeout  ADD aims to create a skeleton system  Working interactions  Give a priority to implementing modules  Assign teams to modules  Main idea  Incrementtal developing.

Software Architecture Lecture 5 .

Roadmap of the course
 What is software architecture?
 Designing Software Architecture
 Requirements: quality attributes or qualities
 How to achieve requirements : tactics
 How do tactics lead to architectural styles
 Case studies on architectural styles, observe the achieved qualities
 The ADD method

 Documenting software architecture
 Today: Bass and all
 Next time: Hofmeister and all


22 November 2011

SA definition
 Software architecture of a program or

computing system is the structure or
structures of the system, which comprise
software elements, the externally visible
properties of those elements, and the
relationships among them. (Bass et al)
 Software architecture describes the element
types, how they interact, how functionality is
mapped to them, and the instances that exist
in the system. (Hofmeister et al)

22 November 2011

What is a view?
 Modern software systems are complex
 We focus at any time on a small number of

structures of the system (view)
 View – representation of a coherent set of
architectural elements, as read/written by system
stakeholders (plus relations)
 Structure – set of architectural elements as they
exist in software or hardware


22 November 2011

Architectural structures
 Module structures
 Component-and-connector structures
 Allocation structures


22 November 2011

SA structures






Shared data





22 November 2011

Module structures
 Elements:
 Modules – units of implementation
 Code-based way of considering the system
 Assigned areas of functional responsibility
 Less emphasis on how resulting SW manifests at

 Questions answered here:
 Primary functional responsibility of each module
 What other SW elements can this module use
 Hierarchies


22 November 2011

Component-and-connector structures
 Elements:
 Runtime components – main units of computation
 Connectors – communication vehicles between

 Questions answered here:
 Major executing components and their interactions
 Major shared data stores
 Replicated parts, data flows, parallel system parts
 Changes in system structure as it executes


22 November 2011

Allocation structures
 Show the relationship between software

elements and elements in one/more external
 Where SW is created and executed

 Questions answered here:
 Processors each SW element executes on
 Files for storing elements during system lifetime
 Assignment of SW elements to development teams


22 November 2011

Structures and decision types
 How is the system to be structured as a set of

code units (modules)?
 How is the system to be structured as a set of
elements with running behavior (component) and
interactions (connectors)?
 How is the system to relate to non-SW structures
in the environment
 CPUs, file systems, networks, development teams


22 November 2011

Module-based structures
 Decomposition
 Shows how larger modules are decomposed into

smaller ones
 Units: modules related by “is a submodule of”
 Recursive decomposition
 Common starting point of design
 Architect enumerates what the SW units will do
 Assigns each item to a module for subsequent design or



22 November 2011

Module-based structures, 2
 Decomposition
 Modules often have associated products
 Interface specs, code, test plans
 Provides for system modifiability
 Often used as basis for project organization
 Structure of documentation, integration, test plans
 Units often have organization-specific names


22 November 2011

3  Uses  Important. often overlooked structure  Units: modules.Module-based structures. procedures. resources on the interface of modules  Units related by “uses” relation  Unit A uses unit B if the correctness of A requires the presence of a correct version of B  As opposed to a stub  Used to engineer extendable systems 13 22 November 2011 .

Module-based structures. 4  Layered  Uses relation controlled in a particular way  Layer: coherent set of related functionality  Layer n may only use services of layer n-1  Many variations occur in practice  Relaxing this structural restriction  Layers designed as abstractions that hide implementation specifics below from layers above 14 22 November 2011 .

Module-based structures. incremental addition of functionality 15 22 November 2011 . 5  Class/generalization  Units: classes  Relation: inherits-from. is-an-instance-of  Supports reasoning about  Collections of similar behaviors or capabilities  Parameterized differences (sub-classing)  Reuse.

exclusion operations  Relation: attachment  Describes how component and connector related to each other  Important to system’s execution performance and availability 16 22 November 2011 .Component-and-connector-based structures  Process (communicating processes)  Orthogonal to module-based structures  Deals with dynamic aspects of a running system  Units: processes or threads  Connected by communication. synchronization.

Component-and-connector-based structures. 2  Concurrency  Units: components connected by “logical threads”  Logical thread  Sequence of computation  Can be allocated to a physical thread later  Allows architect to determine  Opportunities for parallelism  Location where resource contention may occur  Used early in design to identify concurrent execution issues 17 22 November 2011 .

3  Shared data. repository  Comprises components and connectors that  Create.Component-and-connector-based structures. store. access persistent data  Useful for systems structured around shared data repositories  Shows how data is produced and consumed by runtime SW elements  Can be used to ensure performance and data integrity 18 22 November 2011 .

4  Client-server  Useful for systems built as cooperation of clients and servers  Components: clients and servers  Connectors: protocols.Component-and-connector-based structures. messages between them. for carrying out the system work  Useful for  Separation of concerns (modifiability)  Physical distribution  Load balancing (runtime performance) 19 22 November 2011 .

Allocation-based structures  Deployment  Shows how SW is assigned to HW-processing and communication elements  Elements  SW (process from C&C view)  HW entities (processors)  Communication pathways 20 22 November 2011 .

Allocation-based structures. security  Of particular interest in distributed or parallel systems 21 22 November 2011 . 2  Relations  Allocated-to: shows on which physical units the SW elements reside  Migrates-to: if allocation is dynamic  Allows engineer to reason about  Performance. data integrity. availability. 2  Deployment.

3  Implementation  Shows how SW elements (modules) are mapped to the file structure(s) in  The system’s development  Integration  Configuration control  Critical for management of  development activities  build processes 22 22 November 2011 .Allocation-based structures.

Allocation-based structures. 4  Work assignment  Assigns responsibility for implementing and integrating the modules to appropriate teams  Emphasizes that decision about who does what has architectural and management implications  Architect knows expertise required of each team  Large. multi-sourced distributed development projects  This structure allows to have units of functional commonality implemented by a single team rather than by everybody 23 22 November 2011 .

Relating structures to each other  Each structure provides a different perspective and design handle on a system  Structures not independent  We need to reason about the relations  Typically many-to-many  Sometimes one structure is dominant  Other structures cast in terms of it  Exp: Module decomposition 24 22 November 2011 .

Relating structures to each other. 2  Not all systems consider many structures  Big vs small  Structures  Main engineering leverage points of an architecture  Bring with them the power to manipulate one/more quality attributes  Powerful separation of concerns approach  Useful for architecture documentation 25 22 November 2011 .

1995:  Conceptual. module. Nord. Hofmeister.Which structures to choose?  Many approaches  Kruchten. execution. development. code 26 22 November 2011 . 1995: Four+1  Focus on four structures  Logical. process. physical  Ensure they are not in conflict and do the job:  Key use cases as a check  Rational Unified Process  Soni.

Which structures?  Among architect’s obligations  Understand how the various structures lead to quality attributes  Choose the structures that will best deliver those attributes 27 22 November 2011 .

project structuring. presence of. encapsulation. planning. engineering presence of extensions Layered Requires the correct Incremental development. configuration control Uses Requires the correct Engineering subsets. shares secret with Resource allocation. uses implementing systems on top of the services of. information hiding. “virtual machines” portability provides abstraction to Class Communicates with. In OO design systems producing depends on almost-alike implementations from common template .Summary of architectural structures Software structure Relations Useful for Decomposition Is a submodule of.

separation of concerns. 2 Software structure Relations Useful for Client-server Communicates with. consumes data Performance. join. Scheduling analysis. precedes.Summary of architectural structures. depends on Distributed operation. may run concurrently performance analysis with. data integrity. where threads may fork. be created or be killed Shared data Produces data. modifiability . excludes. load balancing Process Runs concurrently with. etc Concurrency Runs on the same logical thread Identifying locations where resource contention exists. performance analysis.

management of commonality . best use of expertise. test activities Work assignment Assigned to Project management. availability.Summary of architectural structures. security analysis Implementation Stored in Configuration control. migratesto Performance. 3 Software structure Relations Useful for Deployment Allocated-to. integration.

4  We often think of system’s structure in terms of its functionality  There are system properties in addition to functionality  Physical distribution  Process communication  Synchronization. etc  Each structure: related to quality attributes  Uses structure: engineered to build an extendable system  Process structure: engineered to eliminate deadlocks and bottlenecks  Decomposition structure: engineered to build a modifiable system 31 22 November 2011 .Summary of architectural structures.

mining efforts  Conceptual glue  For all phases of the project  For all stakeholders 32 22 November 2011 . maintenance.Using SA  Blueprint for system and project developing it  Defines work assignments  Primary carrier of system qualities  Artifact for early analysis  Post-deployment system understanding.

Documenting SA  Crowning step to crafting it  Good architecture is useless if not understood or wrongly understood  Architecture should be described  in sufficient details  without ambiguity  organized for information retrieval 33 22 November 2011 .

Uses of SA documentation  “one size fits all” does NOT work  Documentation depends on how SA will be used  Documentation should be  Abstract enough for new employees  Detailed enough as analysis blueprint  Specific for specific stakeholders  Security analysis. new 34 22 November 2011 . programmers  Experienced.

SA documentation  Prescriptive  Prescribes what should be true by placing constraints on decisions to be made  Descriptive  Describes what is true by recounting decisions already made about system design  Different stakeholders have different needs  For information kinds. levels. treatments  Stakeholder should quickly find the relevant documentation 35 22 November 2011 .

SA documentation 2  Single documentation suite and a roadmap  Different stakeholders can navigate through it  Easy to read  One important user of the documentation  The architect in the project’s future  Same architect: repository of thought. storehouse of design decisions  Different architect: check how predecessors tackled difficult tasks. why some decisions made  Key means to educate people who need an overview 36 22 November 2011 .

 Documenting the relevant views Adding documentation that applies to more than one view Parts in documenting 1.Views and SA documentations  Basic principle of documenting SA: Documenting the architecture is a matter of 1. Choosing relevant views 2. Documenting each relevant view 3. 2. Documenting info that applies to more than one view 37 22 November 2011 .

Choosing relevant views  Needed documentation package is based on  Who the stakeholders are  The future uses of documentation  Quality attributes  Different views  Support different goals and uses  Highlight different elements and relationships  May be specific to the system 38 22 November 2011 .

high detail 39 22 November 2011 .Choosing relevant views 2  Produce candidate view list (matrix)  List stakeholders  List needed views  Fill in cell with amount info: none. overview only. moderate detail.

Example of table 40 22 November 2011 .

Choosing relevant views 3  Combine views  Too many views  Remove views with “overview only” info  See if stakeholders of the above can be served by other views with more needed info  Combine views  Prioritize  Decide what to do first 41 22 November 2011 .

Documenting a view  Need for standard organization  Allocating specific info to specific sections =>  Documentation writer can approach the task  Documentation writer can recognize completion  Documentation reader finds info of interest 42 22 November 2011 .

Documenting a view – 7 parts  Primary presentation  Element catalog  Context diagram  Variability guide  Architecture background  Glossary of terms  And brief description of each  Other info 43 22 November 2011 .

44 22 November 2011 .

exception and error handling in other parts  Usually graphical. sometimes tabular 45 22 November 2011 .Primary presentation  Elements that populate the view and relationships among them  Not necessarily all of them  Should contain the info to be conveyed about system  Exp: normal operation here.

Element catalog  Details at least the elements and relationships shown in primary presentation  Backup for primary presentation  Elements and relations omitted from primary presentation  Belong here  Introduced and explained  Describes  The behavior of elements  The interfaces of elements 46 22 November 2011 .

Context diagram  Shows how system in the view relates to environment in the vocabulary of view  Exp: C&C view  Show which component and connectors interact with external components and connectors  Via which interfaces and protocols 47 22 November 2011 .

runtime 48 22 November 2011 . including  The options among which the choice is to be made  Module view: various parameterizations of modules  C&C view: constraints on replication. protocol choice  Allocation view: conditions of allocation  The binding time of the option  Design.Variability guide  Shows how to exercise any variation points part of the architecture in the view  Exp of variability: product lines  Includes documentation about each point of variation in architecture. scheduling. build.

Architecture background  Explains why the design reflected in the view came to be  Why it is as it is  Provides convincing argument that it is sound  Includes  Rationale: why decisions reflected in view were made and why alternatives were rejected  Analysis results: justifies design or explain what would have to change in case of modification  Assumptions reflected in the design 49 22 November 2011 .

Other information  Contents of this section vary according to standard practice of the organization  Non-architectural info can come here  May include  Management information  Authorship. change histories. configuration control data  References to specific sections of a requirements document for traceability  By the architect  First part of this section must detail its specific contents 50 22 November 2011 .

Documenting behavior  Structural information (views) not enough  Exp. deadlock possibilities not captured  Behavior descriptions add info on  Ordering of interactions among elements  Opportunities for concurrency  Time dependencies of interactions  Behavior documented about  An element or elements working together 51 22 November 2011 .

What behavior to model  Real-time embedded system  Timing properties  Time of events  Banking system  Event sequence more important than actual time  Atomic transaction  Rollback procedure 52 22 November 2011 .

5 s?”  Sequence diagrams  Document sequences of stimuli exchanges  Collaboration in terms of component instances and their interactions  Time sequence shown  Can reply to “what parallel activities occur when the system is responding to these specific stimuli under these specific conditions?” 53 22 November 2011 .Behavior notations  Statechart diagrams     Describe reactive systems Reason about the whole system Abstraction and concurrency Can reply to “will the response time to this stimulus always be less than 0.

Documenting interfaces  Interface: boundary between entities  Over boundary elements interact and communicate  Interfaces are architectural  They carry the properties externally visible to other elements  Documenting interfaces consists of  Naming and identifying interface: signature  Document its syntax and semantics 54 22 November 2011 .

whether or not their value changed by program  C/C++ header file. data type.Signature  Exp: interface resources are invokable programs  Signature names the programs  Signature defines their parameters  Parameters defined by their  Order. Java interface 55 22 November 2011 .

Signature use  Can enable automatic build-up checking  Signature matching  Guarantees a system compiles or links successfully  Does not guarantee if the system operates successfully  We need semantics of interface for that  What happens when resources are brought into play 56 22 November 2011 .

on externally visible phenomena  Not on how the element is implemented! 57 22 November 2011 .What’s in an interface specification?  Statement of element properties the architect chooses to make known  Architect should choose:  The permissible and appropriate information to be assumed about the element  The information unlikely to change  Balance needed  Focus on how elements interact in their operational environment.

Document only once  Modules correspond to one/more elements in C&C view  These elements are likely to have similar/identical interfaces  A module may appear in more than one module view  Module decomposition view  Uses view  Documenting in several places: needless duplication  Refer to the earlier specified interface and only add the info specific to the later specified view 58 22 November 2011 .

Data type definition 4. Variability provided by interface 6. Resources provided  Resource syntax. Exception definition 5. Interface identity 2. Rationale and design issues 9. semantics. Usage guide 59 22 November 2011 . one possibility 1. Element requirements 8. Quality attribute characteristics of interface 7.Template for documenting interfaces  Needed. usage restriction 3.

Documenting element interface 60 22 November 2011 .

version number 61 22 November 2011 .Interface identity  For elements with multiple interfaces  Identify individual interfaces to distinguish them  Naming.

etc  Their semantics: result of invoking the resource  Any restrictions on their use 62 22 November 2011 .Resources provided  Heart of an interface document: resources that the element provides  Their syntax: resource signature  Includes the information another program will need for writing a syntactically correct program that uses the resource  Resource name. names and data types of arguments.

Resource semantics  In natural language. or traces. sent messages  Future behavior of other resources as result of using the resource  Humanly observable results  Resource execution: atomic/suspended/interrupted 63 22 November 2011 . or Boolean algebra. or pre/post-conditions  What:  Assignment of values to data accessible by the actor invoking the resource  Signaled events.

Resource usage restrictions  The circumstances under which the resource may be used  Needed initialization or methods to be invoked before  Limit on number of actors that can interact with the resource  Read/write accesses  Security issues  etc 64 22 November 2011 .

Data type definitions  If interface resources employ non-standard data type. the architect needs to communicate the definition of that type  If defined by another element: reference  Programmers need to know  How to declare variables and constants of the data type  How to write literal values in the data type  What operations and comparisons may be performed on members of data type  How to convert values of data type into other data types 65 22 November 2011 .

Exception definition  Exceptions raised by the interface resources  Same exception may be raised by more than one resource  List each resource’s exceptions  Define them in a dictionary  Common exception handling also defined here 66 22 November 2011 .

Variability provided by the interface  Does interface allow element configuration?  If so. performance of underlying algorithms  What  Name and range of values for each parameter  Time when its actual value is bound 67 22 November 2011 . document  the configuration parameters  Their effect on the semantics of interface  Exp: capacities of visible data structures.

Quality attribute characteristics of interface  Document the quality attribute characteristics the interface makes known to the element users  Exp: constraints on implementations of elements that will realize the interface 68 22 November 2011 .

named resources provided by other elements  Syntax. any usage restrictions  Often convenient to document this info as a set of assumptions that the element has made about the system  They can be reviewed by experts who can confirm or repudiate the assumptions before design has progressed too far 69 22 November 2011 . semantics.Element requirements  Specific.

compromises  Considered alternative designs  Why the above rejected  Insight the architect has about changing interface in the future 70 22 November 2011 .Rationale and design issues  Architect needs to record the reasons for an element interface design  Motivation behind design. constraints.

Usage guide  Semantics of resource:  Provided resources + element requirements  Sometimes not enough  Semantics need to be reasoned about in terms of HOW a broad number of individual interactions interrelate  Protocol: sequence of interactions documented  Complete behavior of interaction. or  Patterns of usage the element designer expects to come up repeatedly  Static behavioral model useful (statechart)  Examples as sequence diagrams 71 22 November 2011 .

Documentation across views  Captures info applicable to    More than one view The documentation package as a whole 3 major aspects 1. project glossary 3. list of elements and where they appear. the way views relate to each other. How the documentation is laid out and organized. What the architecture is  Short system overview informing about purpose of system. Why the architecture is the way it is  72 Context of the system. so that stakeholder finds info efficiently and reliably  View catalog and view template 2. rationale for coarse grained large-scale decisions 22 November 2011 . external constraints for the architecture shape.

Documentation across views 73 22 November 2011 .

How the documentation is organized to serve stakeholder  View catalog  Reader’s introduction to views included in the documentation suite  Using documentation suite as basis for  Communication: necessary for a new reader to determine where particular info is  Analysis: necessary to know which views contain the info needed for a particular analysis 74 22 November 2011 .

relation types. location and owner of view document) 75 22 November 2011 . 2  View catalog. properties  Description of what the view is for  Management info about the view document (latest version.How the documentation is organized to serve stakeholder. 2  One entry per each view in documentation suite  Each such entry  View name and what style it instantiates  Description of the view’s element types.

3  View template  Standard organization for a view  Helps reader navigate quickly to a section of interest  Helps writer organize the info  Helps writer establish criteria for knowing how much work is left to do 76 22 November 2011 .How the documentation is organized to serve stakeholder.

What the architecture is  System overview  Short prose description of  What the system’s function is  Who its users are  Any important background/constraints  Intent  Provide readers with consistent mental model of the system and its purpose  If system at large has this. then here we just refer to it 77 22 November 2011 .

2  Mapping between views  Any two views have much in common  Mappings provide clarification of the views relationships  We choose the ones that provide most insight  Generally: parts of view elements can map to other view elements  Exp: class maps to its object instances  Complications: runtime elements of system do not exist as code elements at all  Imported at runtime. incorporated at build/load time 78 22 November 2011 .What the architecture is.

their meaning  Reference to an already existing glossary 79 22 November 2011 .What the architecture is. 3  Element list  Index of all the elements that appear in all the views  A pointer to where each element is defined  Project glossary  Lists and defines terms unique to the system that have special meaning  List of acronyms.

Why the architecture is the way it is  Cross view rationale  Explains how the overall architecture is a solution to the requirements  It may explain  Implications of system-wide design choices on meeting the requirements/satisfying constraints  Effect on architecture when adding foreseen new requirement. or changing existing one  Constraints on developer in implementing a solution  Rejected design alternatives: why?  why a decision was made  what are the implications in changing a decision 80 22 November 2011 .

UML notation Interfaces 81 22 November 2011 .

UML notation Modules 82 22 November 2011 .

UML notation Relations 83 22 November 2011 .

UML notation Decomposition 84 22 November 2011 .

UML notation Generalization 85 22 November 2011 .

UML notation Layers 86 22 November 2011 .

UML notation Instantiation 87 22 November 2011 .

UML notation Ports 88 22 November 2011 .

UML notation Deployment 89 22 November 2011 .

Today’s take away  Systems today are complex  One can only apprehend several views of the system  5 blind men and an elephant. modern version from Grady Booch:  http://www.html  Documentation is key  And needed in industry anyway  Structures and styles? 90 22 November 2011 0088.

encapsulation. uses implementing systems on top of the services of. configuration control Uses Requires the correct Engineering subsets. planning. engineering presence of extensions Layered Requires the correct Incremental development. presence of. In OO design systems producing depends on almost-alike implementations from common template . project structuring. shares secret with Resource allocation. “virtual machines” portability provides abstraction to Class Communicates with.Summary of architectural structures Software structure Relations Useful for Decomposition Is a submodule of. information hiding.

2 Software structure Relations Useful for Client-server Communicates with. etc Concurrency Runs on the same logical thread Identifying locations where resource contention exists. Scheduling analysis. consumes data Performance. data integrity. join. modifiability . be created or be killed Shared data Produces data. may run concurrently performance analysis with. excludes. where threads may fork. precedes. performance analysis. load balancing Process Runs concurrently with. depends on Distributed operation. separation of concerns.Summary of architectural structures.

availability. integration. test activities Work assignment Assigned to Project management. migratesto Performance. 3 Software structure Relations Useful for Deployment Allocated-to. best use of expertise.Summary of architectural structures. security analysis Implementation Stored in Configuration control. management of commonality .

Some Architectural Styles  Data flow systems  Batch sequential  Pipes and filters  Call-and-return systems  Main program & subroutines  Hierarchical layers  OO systems  Virtual machines  Interpreters  Rule-based systems  Independent components  Communicating processes  Event systems  Data-centered systems (repositories)  Databases  Blackboards 94 22-Nov-11 .

Software Architectures Lecture 6 .

Roadmap of the course  What is software architecture?  Designing Software Architecture  Requirements: quality attributes or qualities  How to achieve requirements : tactics  How do tactics lead to architectural styles  Case studies on architectural styles. observe the achieved qualities  The ADD method  Documenting software architecture  Bass and all  Today: Hofmeister and all  the “four views” 2 23 November 2011 .

complex INDUSTRIAL systems  Study purpose  Understand architectural issues facing designers  Understand current practices.The four views origin  Study on SA for large. and best practices  Find out commonalities across domains  Find out underlying principles leading to good and useful SA 3 23 November 2011 .

successors of the product 4 23 November 2011 . other products in the same family. maintenance. evolution.Precise study goals  For each system  Understand the problem  Understand the SA and how it addresses the problem  Find out the methods and approaches used by architects in designing the SA  Find out how the SA was used during development.

module. and code views 5 23 November 2011 . execution.Study broad result  SA is separated into views  Not a new idea  Not a general agreement on what views are the most useful  Separating different aspects into different views helps in managing COMPLEXITY  Conceptual.

The four views  Based on practical observations  Architects do not necessarily recognized them as separate views  Address different engineering concerns  Each describes a different kind of structure  Structures loosely coupled between views 6 23 November 2011 .

coordination. files and directories  Module view  Decomposition of system and partitioning of modules into layers  Due to complexity  Execution view  Allocation of functional components to runtime entities. synchronization between them. libraries. tied closely to application domain 7 23 November 2011 . communication. then in turn into versions. mapping to HW  Conceptual view  Description of system in terms of its major design elements and relationships among them.What the four views are  Code view  Organization of source code into object code. binaries.

interface definition 8 23 November 2011 .Design tasks for each view  Global analysis  Identify external influencing factors and critical requirements that could affect architecture  Analyze the above to come up with strategies for designing architecture  Central design task  Define elements of the view and their relationships. how they are configured  Global evaluation: ongoing task  Which source of info at which time (from multiple input sources)  Do decisions here have impact on prior design tasks?  Evaluate central design decisions for impact on each other  Final design task  Exp: resource budgeting.

Global analysis  Purpose  Identify external factors that influence the architecture  Analyze the above and develop strategies for accommodating them into architecture  Factor tables  Meant to complement risk analysis and requirements analysis  Factors  Organizational  Technological  Product 9 23 November 2011 .

Organizational factors  Constrain design choices  Some apply only to developing product (development schedule. make changes if needed 10 23 November 2011 . budget)  Some apply to all products of an organization (organizational attitudes. SW process)  Record results of analysis process  Individual developers should use them when making decisions to address specific design choices  Architect should monitor the efficacy and relevance of the chosen strategies.

standards  Changes over time  Product factors  Primary influence over the architecture  Functional features of the product  Qualities  Should support future changes 11 23 November 2011 .Technological and product factors  Technological factors  Obvious influence on architecture  Hardware. software.

Global Analysis activities 12 23 November 2011 .

Analyze factors  Identify and describe factors that  Have a significant global influence  Can the factor’s influence be localized?  Factor important during which stages of development  New expertise and skills for this factor?  Could change during development  Are difficult to satisfy  With which there is little experience 13 23 November 2011 .

Analyze factors. 2  Factor flexibility: what is negotiable  With any stakeholders  Info needed when factors conflict or cannot be fulfilled  How to determine  Possible to influence/change factor so that architecture task becomes easier?  How can be influenced?  To what extent can be influenced? 14 23 November 2011 .

3  Factor changeability: what can change  In the factor itself  In the way you use it in the future  How to determine  In what way could the factor change?  How likely will it change during/after development?  How often?  Will factor be affected by changes in other factors? 15 23 November 2011 .Analyze factors.

4  Analyze impact of factors  On the architecture  If one factor was to change. which will be affected and how:  Other factor?  Components?  Modes of system operation?  Other design decisions? 16 23 November 2011 .Analyze factors.

Factor tables 17 23 November 2011 .

recovery 18 23 November 2011 .Develop strategies  Identify issues and their influencing factors  Issue may arise from limitations/constraints imposed by factors  Exp: aggressive schedule cannot include all requirements  Issue may result from need to reduce impact of changeability of factors  Exp: reduce cost of porting to another OS  Issue may develop due to difficulty in satisfying product factors  Exp: high throughput may overload CPU  Issue may arise from need to have a common solution to global requirements  Exp: error handling.

2  Develop solutions and specific strategies that address the goals:  Reduce or localize the factor’s influence  Reduce the impact of the factor’s changeability on the design and other factors  Reduce or localize required areas of expertise or skills  Reduce overall time and effort 19 23 November 2011 .Develop strategies.

3  Identify related strategies  No strategy duplication  Standard format (issue card) to describe  Each issue. its influencing factors and their impact  General discussion of its solution  Strategies that addresses it  Meaningful names for strategies 20 23 November 2011 .Develop strategies.

Issue card 21 23 November 2011 .

strengths. reporting. recovery P6: service P7: Product cost .Typical categories of influencing factors Organizational factors Technological factors Product factors O1: Management T1: general purpose hardware P1: Functional features O2: Staff skills. weaknesses T2: domain-specific hardware P2: User interface O3: Process and development environment T3: software technology P3: performance O4: development schedule T4: architecture technology P4: dependability O5: development budget T5: standards P5: failure detection. interests.

Typical Organizational factors .

Example .

Example 2 .

Example 3 .

Example 4 .

Example 5 .

COTS  Means communication and control understood  Components: independently executing peers  Functionality  Only simple control  Connectors: communication and control aspects 29 23 November 2011 . interconnected conceptual components and connectors  Appealing due to reuse potential.Conceptual architecture view  Closest to application domain  Product = collection of decomposable.

control  Exp: performance. make sure it’s fulfilled 30 23 November 2011 .Global properties  In addition to communication. dependability  Not all properties can be considered in the conceptual view  Portability in module view  The considered properties should be reconsidered in other views  Exp: performance also in execution view.

Conceptual view usage  Conceptual architecture view completed:  We can reason about the system ability to fulfill functional requirements and global properties  All use cases /scenarios used to capture desired system behavior should be satisfied by the conceptual view 31 23 November 2011 .

Design activities for conceptual view  Global Analysis  Central design task: tightly coupled tasks:  Conceptual components  Conceptual connectors  Global evaluation  Conceptual configuration  Final design task: resource budgeting  Assign resources to components and connectors  Refined in execution view 32 23 November 2011 .

Design tasks .

global properties 23 November 2011 . system qualities.Global analysis  Prior to this. other interacting systems Modes of operation for system Functional requirements. consider        34 Product requirements Use cases System requirements and interactions Understand interface to environment Understand users.

development schedule. architecture technology. domain-specific standards  Organizational factors: management.Global analysis for conceptual view  Focus on factors most relevant to conceptual view  All product factors  Closest view to domain  Technological factors: domain-specific HW. development budget 35 23 November 2011 .

Central design tasks  Define components and connector types  Define how component and connectors interconnect  Map system functionality to components and connectors  Functional behavior in components  Control behavior in connectors  Define instances of both and their interconnections 36 23 November 2011 .

Conceptual components  Both types and instances  Have ports – interaction points for component  Both incoming and outgoing messages (operations)  Each port has associated protocol  Mandates how incoming and outgoing operations can be ordered  Concentrate the system functionality in them 37 23 November 2011 .

diagram 38 23 November 2011 .

Conceptual connectors  Both types and instances  Have roles – points of interaction with other architecture elements  Obey associated protocol  Behavior also needs to be described  The control aspects 39 23 November 2011 .

diagram 40 23 November 2011 .

Conceptual configuration  Define relations among components and connectors  Conceptual configuration between types  Constrains how instances of the types will be interconnected  Conceptual configuration containing instances  Defines which instances are in the product and how they interconnect 41 23 November 2011 .

Final task: resource budgeting  Allocates resources to component and connector instances  Rather late in typical design process 42 23 November 2011 .

Module view  Main purpose:  Get closer to the system’s implementation in software  Conceptual view  Functional relationships explicit  Module view  Functionality mapping to modules (implementation) is explicit  Relationships among implementing elements explicit  How the system uses SW platform (e. OS)  Not only a refinement of the conceptual view: also a 43 repartitioning 23 November 2011 .g.

Conceptual vs module view  Conceptual view  Functionality resides in components  Interaction via connectors  Sophisticated control functionality  Module view  Functionality + control into modules  Modules require and provide interfaces  No implementation  No configuration  Comes in the execution view 44 23 November 2011 .

connectors. interface design  Central design uses  Issue cards from global analysis  Components. plus in the central design tasks of execution and code views  Feedback 45 23 November 2011 .Design tasks  Global analysis. layers  These will be used in interface design. central design. subsystems. configuration from conceptual view  Central design produces  Modules.

Design tasks 46 23 November 2011 .

reporting. portability. reuse  Also related to performance. development budget  Technological: general-purpose hardware. process and development environment. recovery 47 23 November 2011 . failure detection. standards  Specific strategies  Related to modifiability. dependability. software technology.Global analysis  Specific factors  Organizational: staff skills.

Central design task  To do  Map conceptual elements to subsystems and modules  Create layers  Assign modules to layers  Guidelines  Strategies from global analysis  Experience with prior products  General SW engineering experience 48 23 November 2011 .

Modules  Map conceptual elements to subsystems and modules  Subsystem  Higher level conceptual component (contains other components and connectors)  Can contain other subsystems and modules  Module  Corresponds to one conceptual element or many  Can be decomposed into other modules  Parent module just a container. only leaf modules correspond to code 49 23 November 2011 .

diagram 50 23 November 2011 .

Subsystems and modules metamodel  Module  Encapsulates data and operations to provide a service  Provided services defined by the provided interfaces  Required services defined by the required interfaces  Use dependency  Require and provide relations 51 23 November 2011 .

Defining the modules  Conceptual elements mapped to modules  Modules  Get responsibility  Decomposition  Use dependency  After initial mapping  Refine and split modules (for independent development)  Combine modules (for efficiency) 52 23 November 2011 .

2  Add new (supporting) modules  No counterparts in conceptual view  Due to factors not pinned down to specific component  Failure recovery. detection  Due to services needed by existing modules but not provided by SW platform  Decomposition until understanding well  module responsibilities  Implementation and integration risks 53 23 November 2011 .Defining the modules.

3  Container module  Contained modules more tightly coupled than modules contained in a subsystem  Assigned as such to only one team/person to develop  Leaf modules  Still abstract! 54 23 November 2011 .Defining the modules.

Layers  Organize modules into a partially ordered hierarchy  Module in a layer  Can use any other module in that layer  Can use modules in other layers too  Required and provided interfaces of such modules are also required and provided by the layer  Used to constrain the use dependency  Can contain sub-layers  Additional structuring within layer 55 23 November 2011 .

diagram 56 23 November 2011 .

HW  Separate system services from user interface SW  Support reuse  Assign common services to an application services layer  Provide for design independence  Change in OS does not affect whole system 57 23 November 2011 .Layers use  Reduce complexity  Encapsulate external components  COTS SW.

they refine the layer model  Add additional layers for domain-specific functionality  Create sublayers when too complex layer 23 November 2011 . modules assigned to layers  Layers are guide for defining modules  Typically: a combination  Architects have a broad layer division in mind  Application.Modules or layers first?  Start identifying layers when identifying modules  Bottom up  Layers and dependencies among them grow from module responsibilities and their dependencies  Top down  Begin with set of layers (experience with other projects in the domain)  When identified. UI. system services 58  As modules defined.

Global evaluation  Multiple sources of guidance for central design task  Conceptual view design  Global analysis strategies  SA experience  General knowledge of SA and SW engineering  What info source at what time 59 23 November 2011 .

Global evaluation. issues. 2  Second GE aspect  Look for feedback to tasks and decisions earlier made in the design  Look for additional factors. strategies to feed back to the global analysis  Any decision about modules and layers will change something in the conceptual view design 60 23 November 2011 .

3  Third aspect  Evaluate module view decisions with respect to each other  Adjust modules and subsystems based on layer decisions and vice versa  Define new interfaces  Revise interfaces 61 23 November 2011 .Global evaluation.

Final design task: interface design  Describe the interfaces for each of the identified modules and layers  Detailed design  Done after central design task complete  May need to  Define new interfaces  Split/combine interfaces  Feedback to central design task 62 23 November 2011 .

Example interface 63 23 November 2011 .

other views  Items to be traceable:  Critical requirements  Factor tables and issue cards capture product features and requirements affecting SA  Some traced to conceptual elements.Traceability  Describing the relationships of module view to  Requirements. some to modules or layers  Impact of changes in requirements to module view  Organizational and technological factors  Elements in the conceptual view 64 24 November 2011 . external factors.

Module view usage  Module view: starting point to reason about  Management of module interfaces  Change impact analysis  Consistently checking of interface constraints  Confogurationmanagement  Effort estimation  Can be used for testing 65 24 November 2011 .

replication of runtime instances 66 23 November 2011 . threads. migration. address spaces  Captures  How system’s functionality is assigned to the runtime platform elements  How resulting runtime instances communicate  How physical resources are allocated to them  Location. processes.Execution view  Main purpose:  Describes system structure in terms of runtime platform elements  OS tasks.

debugging. monitoring. tuning. 2  Driving forces  Performance. HW)  Used for  Performance analysis. single process)  Provides better preparation for change: This view will likely change more often than other views because  Strong dependency on SW and HW platform => adapt to changes/advances in technology  Tightly coupled with performance and distribution requirements  Tuning of execution view during development 67 23 November 2011 . runtime platform (SW. service maintenance  Sometimes trivial (single thread.Execution view. distribution requirements.

central design. to be mapped into runtime entities HW architecture also input here  Central design produces  Runtime entities. configuration from conceptual view Modules. execution configuration  Runtime entities input to code view  Influence system implementation (source code)  Final design task: resource allocation  Could uncover resource constraints that require some decision changes (infrequent)  Feedback  New factors. resource allocation  Central design uses     Issue cards from global analysis Components. communication paths. strategies feed back to global analysis  Updates in conceptual view decisions. connectors. issues. module repartitioning 68 23 November 2011 .Design tasks  Global analysis.

Design tasks 69 23 November 2011 .

Global analysis  Specific factors  Performance requirements. scheduling policies  Sometimes these are only known later  Analysis of HW and SW platforms 70 23 November 2011 . communication mechanisms  Dependability  Specific strategies  Resource sharing.

HW platform  List of HW components used in the system  Topology or interconnection of them  Determine  Which parts of HW platform could change  The likelihood of change  When the change would occur 71 23 November 2011 .

SW platform  Need to know the infrastructure SW in between the HW platform and the product  OS (traditionally)  OS + network software + middleware layers + DBMS (nowadays)  Products within a company share common SW platform (product line products especially)  List platform elements to use in this view 72 23 November 2011 .

diagram 73 23 November 2011 .

time. impact of change  SW may change as result of HW change 74 23 November 2011 . 2  Determine  Which parts of SW platform could change  The likelihood.SW platform.

Runtime entities  To do  Map (conceptual components and) modules to identified platform elements  Runtime entity allocated to a platform element  Runtime entities with no direct correspondence to modules  Demons. other server processes 75 23 November 2011 .

2  Resource  Sharing  Allowed or required among runtime entities  Files. buffers. replication. other resource sharing policies 76 23 November 2011 .Runtime entities. concurrency control used. servers. etc  Replication  Distribution across hosts  Decisions recorded as runtime characteristics of each runtime entity  Exp: host type.

Communication paths  Expected and allowed communication paths between runtime entities  Mechanisms and resources (platform elements) used for that communication  Communication mechanism can use platform elements such as queues. files  Implementation of protocols for paths  Distributed among runtime entities participating in the communication  New runtime entities can be introduced if protocol too complex  Exp: links to special HW 77 23 November 2011 . buffers.

diagram 78 23 November 2011 .

Execution configuration  The runtime topology of the system  Instances of runtime entities and how they are connected  Determine runtime instances and their attributes  Corresponding runtime entity and host name  Resource allocation of each instance  Info about creation and destruction 79 23 November 2011 .

Execution configuration. paths  Execution configuration diagram  Entities and instances of them  Rarely static  Need to determine and describe How the configuration changes over time  How are the changes controlled   Operating phase. start-up and shut-down  Some systems: configuration that changes during operation 80 23 November 2011 . 2  Describe interconnection of runtime instances  Which runtime instances communicate  Temporary and permanent comm.

dependability  Modules and their dependencies  Constrain runtime entities and their communication  HW architecture  HW resources. that execution configuration must support  Global analysis strategies  Performance. constraints on SW platform  Implementation cost.Global evaluation  Multiple inputs for central design task  Conceptual view design  Concurrency among conceptual components. avoid complex algorithms  What info source at what time  Balance these guidelines and restrictions 81 23 November 2011 .

Global evaluation. 2  Performance experiments or simulations  Analytic techniques not enough  Results of global evaluation  Adjust/refine boundaries of runtime entities  Modify their characteristics accordingly 82 23 November 2011 .

budgets defined in configuration task  Allocate them to particular HW resources  Assign specific values to the budgeted attributes  Exp: setting process priorities  Global analysis  Identified resources to be allocated.Final design task: resource allocation  Consider runtime instances. HW. and SW platforms => resulting resources  SW platform  Fixed or configurable number of each type of platform elements 83 23 November 2011 .

Final design task: resource allocation 2  Allocation decisions  Fairly localized  Often made at build time  Intention: use standard techniques from global analysis  And specific strategies  Exp: RMS (rate monotonic scheduling) used to assign priorities to processes 84 23 November 2011 .

libraries. testing 85 23 November 2011 . configuration files  How the above components related to each other via intermediate components  How all of these are organized according to the development environment of organization  Design decisions related to configuration management. multiple releases.Code view  Describes how SW implementing system is organized  Source components implement individual elements in module view  Deployment components instantiate runtime entities in execution view  Executables.

Primary goal of code view  Facilitate system  Construction  Integration  Installation  Testing  While respecting integrity of all other views 86 23 November 2011 .

and dependencies are mapped to language-specific components and dependencies Module and execution view are languageindependent How much of a module’s functionality is implemented in each release How source components and intermediate libraries are released to other teams for integration and testing 23 November 2011 . its interfaces.Use of code view  Isolates the construction and development aspects of     87 a system in a separate view => flexibility Code view describes how a module.

development process 88 23 November 2011 . development environment. 2  Sometimes straightforward  One executable.Code view. small development team  For complex systems not so  Multiple executables  Shared components  Large team  Concurrent development  Driving forces  Implementation language. development tools.

compile. integration. build. abstraction. 3  Organizes code components to support  Daily concurrent development tasks  Edit. allowed dependencies  Configuration management of different system versions 89 23 November 2011 .Code view. testing  Ease of maintenance and change  Enforcement of architectural design decisions  Encapsulation. test  Building system parts and releasing them to different teams for installation.

Design tasks  Global analysis. intermediate. and deployment components  Components relationships to module and execution views are made explicit  Evaluate continually the decisions  Final design task  Detailed decisions referring to build procedures and configuration management 90 23 November 2011 . central design. final design task  Global analysis  Identify and review inputs to design process  Factors and strategies that influence the code view  Goal: develop strategies specifically for constructing the system and building in flexibility  Central design task  Organize source.

Design tasks 91 23 November 2011 .

necessary or feasible to cross-platform development  Development process  Identify process and testing requirements  Development schedule  Analyze whether product released in stages  Analyze whether developers and testers will work concurrently on multiple releases 92 23 November 2011 . configuration mgmt.Global analysis  Specific factors  Development platform  Development environment  Capabilities of various tools.

Central design task  Map elements from module and execution views to code components  Organize them according to criteria established during global analysis 93 23 November 2011 .

Source components  Identify source components  Map elements and dependencies from module view to source components and dependencies  Organize source components using storage structures (directories. files) 94 23 November 2011 .

Source components. 2  Typically source components for language- specific interfaces and modules. or for components that generate them  Dependencies between source components  Import: compile-time dependency  Generate: source comp generated from another source comp (exp: preprocessing) 95 23 November 2011 .

shared repository 96 23 November 2011 . 3  Module view elements mapped into language- specific source components implementing them  Organize source components so that they can be developed and tested by individual developers  Directory hierarchy  Database.Source components.

files) 97 23 November 2011 . static libraries  Identify their dependencies on source components and each other  Organize them using storage structures (directories.Intermediate components  Identify intermediate components  Binary components.

2  Intermediate components specific to the implementation language and development environment  Organize intermediate components to facilitate sharing  Time for edit-compile-link reduced  Static libraries 98 23 November 2011 .Intermediate components.

Deployment components  Identify and map runtime entities and dependencies in execution view to deployment components and their dependencies  Organize deployment components 99 23 November 2011 .

2  Deployed at runtime to instantiate runtime entities  Executables  Same as dynamic libraries. but also related to dynamic libraries by a link dependency  Dynamic libraries  Related to binary components and static libraries by a link dependency  Configuration descriptions  Can describe processes and resources 100 23 November 2011 .Deployment components.

Deployment components. 3  Organize deployment components  Small system: simple. one/two packages containing files for an executable and its configuration descriptions  Large system: can be very complex  Exp: separate file system for storage of data and for shared memory areas  Exp: separately organize each executable and associated components (required resources and data) 101 23 November 2011 .

Global evaluation  Input from  Strategies in global analysis  Design decisions in module and execution views  Development environment. uniformity of design decisions  Evaluates all design decisions against these criteria 102 23 November 2011 . simplicity. execution platform  Major evaluating criteria  Preserving integrity of architectural decisions  Integrating smoothly with development environment. external components  Other criteria  Consistency.

Final design task  Add detail to decisions made in central design tasks  Build procedure  Design procedure for building and installing intermediate and deployment components  Configuration mgmt  Determine design decisions related to mgmt of versions and releases of components 103 23 November 2011 .

future generations  Product lines  Impact of changes in requirements or domain 23 November 2011 .Conceptual view: engineering concerns  System functionality mapped to conceptual     components Coordination and data exchange handled by connectors Independence from SW and HW techniques Logical flow of control Concerns  How does system fulfill requirements?  COTS components  Incorporated domain-specific HW/SW  Functionality partitioned into product releases 104  Prior generations of product.

where? Testing support How to minimize dependencies between modules How to maximize reuse of modules/subsystems How to protect the product from changes in COTS SW. SW platform.Module view: engineering concerns  Components and connectors mapped into subsystems and modules  Conceptual solution realized with current SW and HW technologies and platforms  Concerns       105 How is the product mapped to SW platform? System support or services used. changes in the standards 23 November 2011 .

replication. reconfiguration requirements  Balancing resource usage  Necessary concurrency. distribution w/o adding much complexity to control algorithms?  Minimize impact of changes in runtime platform 106 23 November 2011 . HW assignment)  Flow of control as seen from the runtime platform  Concerns  How does system meet its performance. and these mapped to HW architecture  Defines the system’s runtime entities and their attributes (memory usage. recovery.Execution view: engineering concerns  Modules mapped into runtime platform elements.

executables)  Modules mapped to source components  How source components produce deployment components  Concerns      107 Reduce time and effort for product upgrades Management of product versions and releases Reduce build time Needed tools for development environment Support for integration and testing 23 November 2011 .g.Code view: engineering concerns  Runtime entities mapped to deployment components (e.

Use of the four views  Prioritize design decisions and determine dependencies among them  Result: set of design activities and an order based on their dependencies  Not all decisions can be made up front  Architect makes the most reasonable decisions  Iterate back to the architecture and make changes when necessary 108 23 November 2011 .

Expectations from using the four views  Tracing influencing factors and requirements throughout architecture  Sequencing design activities  Making design trade-offs  Supporting system qualities (performance…)  Supporting general qualities (buildability…)  Ensuring no aspects of architecture are overlooked  Producing useful documentation of architecture 109 23 November 2011 .

Today’s takeaway  Another set of views  Derived based on the software architecture of existing (industrial) systems  How are they compared to Bass et al? 110 24 November 2011 .

Software Architectures Lecture 7 .

observe the achieved qualities  The ADD method  Documenting software architecture  Bass and all  Hofmeister and all  the “four views”  Today: Evaluating an architecture 2 29 November 2011 .Roadmap of the course  What is software architecture?  Designing Software Architecture  Requirements: quality attributes or qualities  How to achieve requirements : tactics  How do tactics lead to architectural styles  Case studies on architectural styles.

why  Architecture tells about system properties  Effects of design decisions are predictable => architecture is analyzable  Architecture drives the software system => economic value  Good evaluation methods => low-cost risk mitigation  Architecture evaluation  good to be standard part of every architecture-based development method 3 29 November 2011 .Architectural evaluation .

Architectural evaluation . inherited system.when  Cost-effective: early in lifecycle  Easier to correct problems  Quality cannot be appended to a system later in lifecycle  Developing architecture  Evaluate taken/under consideration decisions  Choose among alternatives or competing architectures  Other times in lifecycle  Completed architecture: validate it before development  Legacy system under consideration. large software system to be aquired  Rule for ”when”  When development teams start to make decisions based on the architecture  When the cost of undoing such decisions > evaluation cost 4 29 November 2011 .

Discovery review  Very early mini-evaluation  Establishes and prioritizes problematic requirements  Fewer stakeholders  People with decision power on the requirements  Output  Stronger set of requirements  Initial approach to satisfy the requirements 5 29 November 2011 .

sponsor (not always) 6 29 November 2011 .who  Evaluation team  Stakeholders  Project decision maker  Architect  Component designers  Management  Customer.Architectural evaluation .

not blame pointing 7  Counteract the skepticism  Architectural approaches for dealing with/ analyzing QA do not vary much  Fresh eyes.Architectural evaluation – why should they believe you?  Evaluators = outsiders  Stakeholders can be  Scared  Skeptical  They are the experts. new perspective 29 November 2011 . evaluators cannot teach them about their system  What to do  Counteract the fear  Purpose is architecture improval.

Results of Architectural evaluation  Concretely: a report  Primarily: information  Is the architecture suitable for the system for which it was devised?  Which of two competing architectures is most suitable for the system at hand?  Architecture is suitable if  The system that results from it will meet its quality goals  The system can be built using the resources at hand (architecture is buildable) 8 29 November 2011 .

Architecture suitable with respect to…  A system is modifiable or not wrt a specific kind of     9 change A system is secure or not wrt a specific kind of threat A system is reliable or not wrt a specific kind of fault occurrence A system performs well or not wrt specific performance criteria An architecture is buildable or not wrt specific time and budget constraints 29 November 2011 .

cost  Cost = staff time required of the participants  Aproximative cost for AT&T: 70 staff-days  300 full scale architecture reviews for projects requiring minimum 700 staff-days  ATAM reviews: about 36 staff-days  For evaluation team  Other stakeholders’ time counts too  Time included for training the evaluation team! 10 29 November 2011 .Architectural evaluation .

decreased budget risk 11 29 November 2011 .benefits  Financial  Forced preparation for the review  Captured rationale  Early detection of problems  Validation of requirements  Improved architectures  Overall: increased quality. controlled cost.Architectural evaluation .

Architectural evaluation . prototypes 12 29 November 2011 .or questionaire-based  Measuring techniques  Rely on quantitative measures over existing artifact  Architectural metrics  Simulations.techniques  Questioning techniques  Rely on thought experiments to check architecture suitability  Hypothetical architectures too  Scenario-based  ATAM  CBAM  Checklist.

ATAM  Architecture Tradeoff Analysis Method  How well an architecture satisfies particular goals?  Provides insight into how quality goals interact. how they trade off  Has its origins in  SAAM (Software Architecture Analysis Method) from the early 1990s  Architectural styles  Quality attribute analysis communities 13 29 November 2011 .

Participants in ATAM  The evaluation team  Project decision makers  Architecture stakeholders 14 29 November 2011 .


Present architecture  Investigation and analysis (assessing key QAs) 4. Analyze architectural approaches  Reporting 16 9. Present the ATAM 2. Identify architectural approaches 5. Present business drivers 3.Summary of ATAM  Preparation (presentations) 1. Brainstorm and prioritize scenarios 8. Analyze architectural approaches  Testing (results to date against stakeholders) 7. Present the results 29 November 2011 . Generate quality attribute utility tree 6.

Step 1: present ATAM  Evaluation team leader  ATAM steps in brief  Techniques to be used for elicitation and analysis  Utility tree generation  Architecture-based elicitation and analysis  Scenario brainstorming and prioritization  Outputs of evaluation  Elicited and prioritized scenarios  Questions used to understand and evaluate the architecture  Utility tree of QA  Discovered risks and non-risks  Sensitivity points and tradeoffs 17 29 November 2011 .

managerial.Step 2: Present business goals  Describe  The system’s most important functions  Any relevant technical. economic. or political constraints  The business goals and context as they relate to the project  The major stakeholders  The architectural drivers (the major quality attribute goals) 18 29 November 2011 .

interoperability. time to market. driving requirements. interoperation with other systems. customer demands.) (1-3 slides) Description of the technical constraints (e. required hardware or software platform.g..g.. performance. availability. cost.Business Context/Drivers Presentation  (~ 12 slides. standards. etc. integrability) and what business needs these are derived from (2-3 slides) Glossary (1 slide) 29 November 2011 . market     19 differentiators. stakeholders. COTS.) (1-3 slides) Quality attributes desired (e. etc. 45 minutes)  Description of the business environment. current need and how the proposed system will meet those needs/requirements (3-4 slides) Description of business constraints (e.. security.g. reuse of legacy code. history. modifiability.

measurable quantities associated with these.Step 3: Present architecture  Driving architectural requirements. standards/models/approaches for meeting these  Important architectural information  Context diagram  Module or layer view  Component and connector view  Deployment view 20 29 November 2011 .

patterns. what quality attributes they address and how they address those attributes  Use of COTS and their integration  Most important use case scenarios  Most important change scenarios  Issues/risks wrt meeting the driving requirements 21 29 November 2011 . tactics employed.Step 3: Present architecture cont  Architectural approaches.

storage. domain elements along with their dependencies. include the run-time resources consumed for each scenario (1-3 slides)  Trace of 1-3 of the most important change scenarios.Architecture Presentation  (~20 slides. 60 minutes)  Driving architectural requirements (e. callback. external devices/sensors along with the networks and communication devices that connect them  Architectural approaches or styles employed. (1-3 slides)  Architectural issues/risks with respect to meeting the driving architectural requirements (2-3 slides)  Glossary (1 slide) . or interfaces. functions that populate these and the relations among them (e. connectors. data flow  module/layer/subsystem: the subsystems... including what quality attributes they address and a description of how the styles address those attributes (3-6 slides)  Use of COTS and how this is chosen/integrated (1-2 slides)  Trace of 1-3 of the most important use case scenarios. along with the objects.g. If possible.  process/thread: processes. describe the change impact (estimated size/difficulty of the change) in terms of the changed components. layers. and any existing standards/models/approaches for meeting these (2-3 slides)  High Level Architectural Views (4-8 slides)  functional: functions.g. and events that connect them  hardware: CPUs. availability. performance. integrability). modules that describe the system’s decomposition of functionality. If possible. security. containment). key system abstractions. modifiability. procedure call. data flow. method invocation. procedures. interoperability. the measurable quantities you associate with these requirements. threads along with the synchronization.

Step 4: identify architectural approaches  Catalog the evident patterns and approaches  Based on step 3  Serves as the basis for later analysis 23 29 November 2011 .

prioritized.Step 5: Generate quality attribute utility tree  Utility tree  Present the quality attribute goals in detail  Quality attribute goals are  Identified. refined  Expressed as scenarios  ”Utility” is an expression of the overall goodness of the system  Quality attributes form the second level being components of utility 24 29 November 2011 .

Step 5: Generate quality attribute utility tree cont  Scenarios are prioritized  Depending on how important they are and  Depending on how difficult it will be for the architecture to satisfy a scenario 25 29 November 2011 .

26 29 November 2011 .

Step 6: Analyze architectural approaches  Examine the highest ranked scenarios  The goal is for the evaluation team to be convinced that the approach is appropriate for meeting the attribute-specific requirements  Scenario walkthroughs  Identify and record a set of sensitivity points and tradeoff points. risks and non-risks  Sensitivity and tradeoff points are candidate risks 27 29 November 2011 .

sensitivity points. non-risks.Step 6 outputs  Architectural approaches relevant to each high- priority utility tree scenario  Analysis questions associated with each approach  Pointed to the QA associated to the scenario  The architect’s responses to the questions  Risks. tradeoffs associated with the achievement of one/more QA wrt the QA questions that probed the risk 28 29 November 2011 .

More on Step 6  Utility tree shows how to probe the architecture  Architect responds with the architectural approach that answers this need  Evaluation team can use the QA-specific questions to probe the approach more deeply  The QA-specific questions help team to  Understand the approach in detail and how it was applied in the instance  Look for well-known weaknesses with the approach  Look for the approach’s sensitivity and tradeoff points  Find interactions and tradeoffs with other approaches 29 29 November 2011 .


Step 7: Brainstorm and prioritize scenarios  Utility tree shows the architect’s view on the quality attributes  Here the focus is on the other stakeholders’ view on the quality attributes and scenarios based on these  Which are the most meaningful and important scenarios wrt users etc.  Scenario brainstorming works well in larger groups  The prioritized list of scenarios compared to utility tree scenarios 31 29 November 2011 .

how the architecture might be stressed by changes  Dramatic new performance or availability requirements.Step 7: Brainstormed scenarios  Use case scenarios  How stakeholders expect system to be used  Growth scenarios  How the architecture is expected to accommodate growth and change  Expected modifications. integration with other software  Exploratory scenarios  Extreme forms of growth. porting to other platforms. changes in performance or availability. major changes in infrastructure or system mission 32 29 November 2011 .

and draws the line there 33 29 November 2011 .Step 7: Prioritizing scenarios  First stakeholders merge scenarios they believe represents the same behaviour / QA concern  Then stakeholders vote on scenarios they believe are most important  Each stakeholder gets a number of votes equal to 30% of the number of scenarios rounded up  Then they vote in any way  Vote is public  Evaluation leader sorts the scenarios. detects the sharp drop-off in number of votes.

Retarget a collection of diverse vehicles to handle an emergency situation in less than 10 seconds after commands are issued. Split the management of a set of vehicles across multiple control sites. [23] 12. [13] 14. Dynamically replan a dispatched mission within 10 minutes. Change vendor analysis tools after mission has commenced without restarting system. [26] 10. Change the data distribution mechanism from CORBA to a new emerging standard with less than six personmonths’ effort. [12] 34 29 November 2011 .Vehicle dispatching system exp 4. [28] 27.

Availability 10 23 Integrability 12 13 Performance 14 12 Modifiability 29 November 2011 .Highly ranked scenarios with QA annotations 35 Scenario #Votes Quality Attributes 4 28 Performance 27 26 Performance. Modifiability.

Step 7: Comparison  Scenario prioritization compared to utility tree  Agreement or disagreement  Each high-priority brainstormed scenario is placed in appropriate leaf node in utility tree  Prior to this. identify the QAs the scenario addresses  When brainstormed scenario placed in utility tree:  Scenario matches and duplicates already existing leaf node  Scenario goes onto a new leaf of existing branch  Scenario fits in no branch of the tree (QA not previously accounted for) 36 29 November 2011 .

provide focus for validate QA goals elicited via utility the rest of the evaluation tree Approach General to specific.Utility tree vs Scenario Brainstorming 37 Utility trees Scenario Brainstorming Stakeholders Architects. 5-10 project related personnel Primary goals Elicit. begin with scenarios. make concrete and prioritize Foster stakeholder communication to the driving QA. 2-3 project personnel Evaluators. begin with QA. refine until scenarios emerge Specific to general. then identify QAs they express 29 November 2011 . project leader All stakeholders Typical group size Evaluators.

Stakeholders and Architect  Architect should be present at evaluation!  Cannot identify architect: trouble  Architect sees all stakeholders together. important step  Architect takes items to work on from evaluation  Has to present the architecture  Identify kinds of stakeholders and names!  Evaluators suggests kinds  Client provides names 38 29 November 2011 .

Step 8: Analyze architectural approaches  Highest ranked scenarios from step 7 are presented to the architect  Architect explains how relevant architectural decisions contribute to realizing each one  Previously discussed architectural approaches should come in here  Same activities as in Step 6  Ideally: just testing  If step 7 did not produce any high-priority scenarios not already covered 39 29 November 2011 .

Step 9: Present results  Verbal report and slides  Written report  Outputs:  The architectural approaches documented  The set of scenarios and their prioritization from the brainstorming  The utility tree  The risks discovered  The non-risks documented  The sensitivity points and tradeoff points found 40 29 November 2011 .

Step 9: Risk themes  Risks can be grouped together based on some common underlying concern. systemic deficiency  Exp  Documentation given insufficient consideration  Inadequate doc  Out-of-date doc  Insufficient attention to backup capability or provision of high availability  System cannot function when various SW/HW fails  Risk theme <-> affected business drivers  Closure and risks pointed out to management 41 29 November 2011 .

Outputs of the ATAM  A concise presentation of the architecture  Articulation of the business goals  Quality requirements in terms of a collection of scenarios  Mapping of architectural decisions to quality requirements  A set of identified sensitivity and tradeoff points  A set of risks and non-risks  A set of risk themes 42 29 November 2011 .

Other outputs  Secondary outputs  Architecture representation survives evaluation  Scenarios too  Analysis can serve as statement of rationale for architectural decisions  Made or not  Mitigation strategies  Intangible goals  Social. community sense  Better communication  Improved understanding 43 29 November 2011 .

Phases of the ATAM  Phase 0  Partnership and preparation  Phase 1  Evaluation. stakeholders-centric  Phase 3  Follow-up 44 29 November 2011 . architecture-centric  Phase 2  Evaluation continued.

Steps of evaluation phase 1  Step 1  Present the ATAM  Step 2  Present business drivers  Step 3  Present architecture  Step 4  Identify architectural approaches  Step 5  Generate quality attribute utility tree  Step 6  Analyze architectural approaches 45 29 November 2011 .

Steps of evaluation phase 2  Step 7  Brainstorm and prioritize scenarios  Step 8  Analyze architectural approaches  Step 9  Present results 46 29 November 2011 .

formal notations and languages 47 29 November 2011 .Other methods  CBAM  Cost-Based Analysis Method  Uses ATAM  Measuring technics  Answer specific questions about specific qualities  Need the presence of a design/implementation artifact (the object to measure)  RMA – rate monotonic analysis: quantitative technique for ensuring that a set of fixed-priority processes can be scheduled on a CPU  Can be performed as architecture is being evolved  ADL.

benefits. schedule implications  Basic idea of CBAM  Architectural strategies  quality attributes  benefits for stakeholders (utilities) 48 29 November 2011 . risks.CBAM  Biggest trade-offs influence economics  Resources  Earlier: costs  Of building system. not long term  Now also: benefits  Economic models needed  Consider costs.

desired-case response  interpolation  Side effects 49 29 November 2011 .CBAM Utilities  Architectural strategy  Provides specific level of utility to stakeholders  Has cost  Takes time to implement  Return On Investment (ROI)  Ratio of benefit to cost  Utility-response curves  Depicts how the utility derived from a particular response varies as the response varies  Best-case. worst-case. current-case.

j × Wj)  bi.Some formulas  Overal utility of architectural strategy across scenarios  Strategy i  Scenario j  Benefit Bi  Benefit bi.j = Uexpected-Ucurrent  Ri = Bi/Ci 50 29 November 2011 . cost Ci  Bi = ∑j (bi.j  Weight Wj  Utility U  Return over investment Ri.

Properties of successful evalution  Clear goals and requirements for architecture  Controlled scope  Cost-effectiveness  Key personnel availability  Competent evaluation team  Managed expectations  Final report 51 29 November 2011 .

Software Architectures Lecture 8 .

observe the achieved qualities  The ADD method  Documenting software architecture  Bass and all  Hofmeister and all  Evaluating an architecture  Today: ADLs and short discussion of formal approaches to architectures 2 1.2011 .Roadmap of the course  What is software architecture?  Designing Software Architecture  Requirements: quality attributes or qualities  How to achieve requirements : tactics  How do tactics lead to architectural styles  Case studies on architectural styles.12.

12.2011 .Linguistic character of architectural description  Common patterns in different architectures  common kinds of elements  common inter-module connection strategies  Languages describe complex relations among primitive elements and combinations of these  Semantic constructs => There is an appropriate linguistic basis in architectural descriptions 3 1.

2011 . data relation  Boxes and lines may mean different things  For different described systems  For different people  Supplemented with prose. control.12. no precise meaning  Informal terms  Still useful 4 1.Common patterns of SW organization  SA description often  Box-and-line diagrams  boxes  major components  lines  communication.

12.2011 .Usage of common patterns  Informal terms  Often refer to common patterns used to organize the system  Used among SW engineers in high-level descriptions of designs  More precise definitions of these  (would be) Beneficial for SW developers  In the forms in which they appear  In the classes of functionality and interaction they provide 5 1.

symbol table. transforms  Memory  Shared collection of persistent structured data  Exp: Database.2011 . user interface 6 1. servers  Controller  Governs time sequences of other’s events  Exp: Scheduler.12. no retained state  Exp: Math functions. synchronizer  Link  Transmits information between entities  Exp: Communication link. hypertext  Manager  State and closely related operations  Exp: Abstract data type.Common component classes  (pure) Computation  Simple input/output relations. filters. file system.

multiuser databases  Instantiation  Instantiator uses capabilities of instantiated definition by providing space for state required by instance  Exp: using abstract data types 7 1. discrete hand-off of data.12. automatic garbage collection  Message passing  Independent processes interact by explicit.Common interactions among components  Procedure call  Single thread of control passes among definitions  Exp: Ordinary procedure call. remote procedure call  Dataflow  Independent processes interact through streams of data  Exp: Unix pipes  Implicit invocation  Computation is invoked by the occurrence of an event. no explicit interactions among processes  Exp: Event systems.2011 . may be synchronous or asynchronous  Exp: TCP/IP  Shared data  Components operate concurrently (probably with provisions for atomicity) on the same data space  Exp: Blackboard systems.

2011 ./  Abstraction  Rules for naming expressions of components and operators  Exp: definition of macros and procedures  Closure  Rules to determine which abstractions can be added to the classes of primitive components and operators  Exp: procedures or user-defined types .*. informal (in reference manual) 8 1. conditional constructs. strings.12.first class entities  Specification  Association of semantics to the syntactic form  Formal. records.Critical elements of a design language  A (programming) language requires  Components  Primitive semantic elements and their values  Exp: integers. arrays  Operators  Functions that combine components  Exp: iteration. floating-point numbers. +.-.

The language problem for SA  SA deals with  Allocation of functionality to components  Data and communication connectivity  Quality attributes and system balance  Quite different from the (conventional) programming language concerns  Specific forms of the various language elements are also different 9 1.12.2011 .

Exp: client-server relation  Closure  Conditions in which composition can serve as a subsystem in development of larger systems  Specification  Not only of functionality.2011 .12.Critical elements of a SA design language  Components  Module-level elements. but also of quality attributes 10 1. component classes listed before  Operators  Interaction mechanisms as listed before  Patterns/ abstraction  Compositions in which code elements are connected in a particular way.

for combining them into subsystems and systems  Such a language would support  Simple expressions of connections among simple modules.12.Implication of the critical elements  Basis for designing ADLs provided by  Identification of architectural components  Identification of architectural techniques. plus  Subsystems  Configurations of subsystems into systems  Common paradigms for such combinations  Expression of quality attributes and functional properties 11 1.2011 .

12 describe architectural components and their interactions To handle large-scale.2011 . 5. 4. high-level designs To support the adaptation of designs to specific implementations To support user-defined abstractions To support application-specific abstractions To support the principled selection of architectural paradigms 1.12. notations. To provide models. tools to 2. 6. 3.Requirements for ADLs 1.

2011 .12.ADL and environment  Close relation between ADL and its environment  ADL: precise descriptions  Environment: (re)uses the descriptions  Ideal ADL should support  Composition  Abstraction  Reusability  Configuration  Heterogeneity  Analysis 13 1.

Composition  Describe a system as composition of independent components and connections  Aspects  Divide a complex system (hierarchically) into smaller parts  Assemble a large system from constituent elements  Independent elements  Can be understood in isolation from the system  Separate issues of implementation-level from those of architectural level 14 1.2011 .12.

Composition.2011 . 2  Another name: modularity  Closure rule: can see entities as both primitives and composites  At different levels of abstraction  Independence rule: can reuse parts of a composite 15 1.12.

12. 3  Need for explicit and abstract composition rules  Pipe and filter  Sequence of pipes and filters  Layered systems  Collection of abstract layers interacting according to certain rules  Filter can internally be decomposed in  Another pipe and filter system  Instance of something else  Filter may be used in any data stream transformation system  Pipe may be used for any data transmission 16 1.2011 .Composition.

register usage suppressed. reveals use dependencies 1. 17 sequential control flow abstractions revealed • Interface: suppresses implementation issues.Abstraction  Allows to describe the abstract roles of elements and their interaction within SA at a level well understood by designers  Clearly  Explicitly  Intuition  Suppress unneeded detail but reveal important properties • high-level pgm languages.12.2011 .

2011 .12. to reveal high-level structure  Distinct roles of each element in the high-level structure are clear  Example: client-server relationship 18 1. 2  Necessary to represent new architectural patterns and new forms of interaction between them as first class abstractions  Architectural level of design  Different form of abstraction.Abstraction.

architectural styles in different architectural descriptions  Reuse generic patterns of components and connectors  Families of SA as open-ended sets of architectural elements  Structural and semantic constraints  Differs with respect to reusing components from libraries  Those are completely closed / parameterized components. retain identities. indefinite replication of relations.2011 . connectors.Reusability  Reuse components. are leaves of “is-composed-of” system structure  Reusing generic patterns of components and connectors: further instantiation.12. structured collections of internal nodes 19 1.

Reusability.12. 2  Systems rarely conceived in isolation  Instances of a family of similar systems that share many architectural properties  Shared properties  Structural: specific topology of component and connectors  Constraints on using certain architectural elements 20 1.2011 .

Configuration  Architectural descriptions should localize the description of system structure  Independently of the elements being structured  Dynamic reconfiguration permissible  Evolvability  Create/remove components.12. interactions initiated  Allows to understand and change architectural structure  Without examining individual components  ADL: should separate descriptions of compositions from those of elements  Reason about composition as a whole 21 1.2011 .

heterogeneous architectural descriptions  Ability to combine different architectural styles in a single system  Component A communicates with component B via a pipe.2011 . but also accesses a shared database with a query  Different levels of architectural description should be allowed to use different architectural idioms  Ability to combine components written in different languages  Architectural description is at a higher level of abstraction than the algorithms and data structures used for implementation 22 1.Heterogeneity  Combine multiple.12.

2011 . investigate deadlock and resource usage.12.Analysis  Possible to perform rich and varied analyses of architectural descriptions  Each style facilitates a certain type of properties  Pipe and filter: possible to analyze throughput. deduce the system I/O behavior from that of the filters  Should be possible to tailor special purpose analysis tools to architecture types  Automated and non-automated reasoning about architectural descriptions 23 1.

2  Important for architectural formalisms  Many of the interesting architectural properties are dynamic  Exp  If connector associated with protocol.2011 . connectors. styles 1. resource usage may aid in reasoning if SA adequate  Variety of analyses => no single semantic framework will be enough  Should be possible to associate specifications with 24 architectures as they become relevant to particular components.12. performance.Analysis. is the use of connector correct in its context?  Timing.

connections is ignored 25 1.12.First-class connectors  SA treats SW systems as composition of components  Focus on components  Description of interactions among components is implicit. hard to identify  When interfaces explicit: import/export lists of data and procedures  Implicit interactions: include files => Info organized around components. significance of interactions.2011 . distributed.

Poor support for legacy systems 26 1. Mixed concerns in programming language specification 5. Poor support for components with incompatible packaging 6. Inability to localize info about interactions 2.2011 . Lack of structure on interface definitions 4.Problems with this practice 1. Poor abstractions 3.12. Poor support for multi-language or multiparadigm systems 7.

12. distinct ways  Correspond to compilation units (roughly)  Connectors mediate interactions among components  Establish rules that govern component interaction  Specify any auxiliary mechanisms required  Do not correspond to compilation units 27 1.Fresh view of software system composition  Systems composed of identifiable components of various distinct types  These interact in identifiable.2011 .

Connectors  Manifest as  Table entries  Instructions to a linker  Dynamic data structures  System calls  Initialization parameters  Servers with multiple independent connections  Define a set of roles that specific named entities of the components must play 28 1.12.2011 .

Connectors.12. etc)  Are of some type/subtype  Roles to be satisfied: specific.2011 . 2  Place of relations among components  Mediate interactions  Have protocol specifications defining their properties  Rules about types of interfaces they are able to mediate for  Assurances about properties of interactions  Rules about order in which things happen  Commitments about interaction (ordering. performance. visible named entities in the protocol of a connector 29 1.

Components  Place of computation and state  Have interfaces specifying their properties     Signatures Functionality of resources Global relations Performance properties  Are of some type/subtype  Interface points: specific.2011 . visible named entities in the interface of a component 30 1.12.

Primitive vs composite: components  Primitive components coded in the programming language  Composite components define configurations in independent notation  Constituent components and connectors identified  Match connection points of components with roles of connectors  Check integrity of the above 31 1.2011 .12.

12.Primitive vs composite: connectors  Of different kinds      Shared data representations Remote procedure calls Dataflow Document-exchange standards Standardized network protocols  Rich enough set to require taxonomy to show relations among similar connector kinds 32 1.2011 .

2011 .12.Primitive connectors  Built-in mechanisms of programming languages  System functions of the OS  Shared data  Entries in task/routing tables  Interchange formats for static data  Initialization parameters  etc 33 1.

multiplicity.Summing up principles for ADL  Purpose: define roles and relationships instead of algorithms and data structures  Must support  System configuration  Independence of entities (reusability)  Abstraction  Analysis of functional properties and QA  Has syntax and  Defines semantics for connectors and their compositions  Generalize from import/export rules to rules with symmetry. abstraction.12. components. naming  Defines type structures for system organizations. connectors. primitive units of associations of these  Sets out appropriate rules for architectural abstractions 34 1. locality.2011 .

2011 .12.Large grained structure of ADL 35 Component Connector Interface Component type Player Implementation Protocol Connector type Role Implementation 1.

related specs => no more name matching 36 1. but implemented in a programming language  Non-primitive element  Implementation: list of parts.On ADL structure  Specify whether element primitive  Not further defined at architectural level. composition instructions.12.2011 .

and performance  ADLs can support automatic generation of software systems  The negatives  There is no universal agreement on what ADLs should represent.2011 .12. particularly wrt the behavior of the architecture  Representations currently in use are relatively difficult to parse and are not supported by commercial tools  Most ADL work today has been undertaken with academic rather than commercial goals in mind  Most ADLs tend to be very vertically optimized toward a particular kind of analysis 37 1. ambiguity.Architecture Description Languages  The positives  ADLs provide a formal way of representing architecture  ADLs are intended to be both human and machine readable  ADLs support describing a system at a higher level than previously possible  ADLs permit analysis of architectures – completeness. consistency.

Software Architecture: ADL Perspective  The ADL community generally agrees that Software Architecture is a set of components and the connections among them.2011 .12.  components  connectors  configurations  constraints 38 1.

ADLs  Leading candidates  ACME (CMU/USC)  Rapide (Stanford)  Wright (CMU)  Unicon (CMU)  Secondary candidates  Aesop (CMU)  MetaH (Honeywell)  C2 SADL (UCI)  SADL (SRI)  Others  Lileanna  UML  Modechart 39 1.12.2011 .

extensible infrastructure for describing. representing.ACME  Acme was developed jointly by Monroe. generating. Garlan (CMU) and Wile (USC)  Acme is a general purpose ADL originally designed to be a lowest common denominator interchange language  Now  common interchange format for architecture design tools  foundation for developing new architectural design and analysis tools  simple architectural descriptions  Acme language and Acme Tool Developer's Library (AcmeLib)  provide a generic.12. and analyzing software architecture descriptions 40 1.2011 .

caller.12.receive-request to rpc. server.send-request to rpc.An ADL Example (in ACME) System simple_cs = { Component client = {Port send-request} Component server = {Port receive-request} Connector rpc = {Roles {caller.2011 . callee}} Attachments : {client.callee} } rpc client send-request 41 caller callee server receive-request 1.

Rapide  Developed by David Luckham.12. including data types and operations Rapide analysis tools focus on posets  matching simulation results against patterns of allowed/prohibited behaviors  some support for timing analysis  focus on causality Rapide has some generation capability since Rapide specifications are executable Rapide has a fairly extensive toolset 1.2011 . Stanford  General purpose ADL designed with an emphasis on simulation     42 yielding partially ordered sets of events (posets) Fairly sophisticated.

12. object-oriented. event-based simulation     43 language Defines and simulates behavior of distributed object system architectures Produces a simulation represented by a set of events (poset)  Events are ordered with respect to time and causality System requirements are expressed as constraints on time and concurrent patterns of events Posets enable visualization and analysis of an execution 1.The Rapide Model  Concurrent.2011 .

12.2011 .Rapide Architectural Elements Components components Architecture connections constraints Components interface interface Component architecture interface module 44 1.

2  Components  Interface objects  Architecture that implements an interface  Module that implements an interface  Connections  Connects “sending interfaces” to “receiving interfaces”  Components communicate through connections by calling actions or functions in their own interface  Events generated by components trigger event pattern connections between their interfaces  Three types of connections:  Basic connections  Pipe connections  Agent connections 45 1.Rapide Architectural Elements.2011 .12.

Architectural Elements (cont’d) Components provides part requires part Interface Components action part in actions out actions service part state Components behavior part state transitions constraint part pattern constraints Components private part 46 functions objects types interface with no private part 1.2011 .12.

behavior (?X in Integer) Receive(?X) => Ack(?X).2011 . action in Reply(N : Integer).A Simple Specification in Rapide type Producer (Max : Positive) is interface action out Send (N: Integer). action out Ack(N : Integer). behavior Start => send(0). 47 1. (?X in Integer) Reply(?X) where ?X<Max => Send(?X+1). type Consumer is interface action in Receive(N: Integer). Cons : Consumer. Cons.12.Send(?n) => Cons.Ack(?n) => Prod. end Producer. connect (?n in Integer) Prod. end Consumer architecture ProdCon() return SomeType is Prod : Producer(100).Reply(?n). end architecture ProdCon.Receive(?n).

Communicating Sequential Processes.  Any CSP analysis tool or technique could be used to analyze the behavior of a Wright specification Wright does not currently have a generation capability Wright has minimal native tool support (but CSP tools could be used) . connectors. process algebra developed by C. R. A. Hoare Focuses primarily on the basic component/connector/system paradigm  Similar syntactically to ACME and Aesop Wright analysis focuses on analyzing the CSP behavior specifications.Wright  Developed by David Garlan at CMU  Wright is a general purpose ADL designed with an emphasis on     analysis of communication protocols  Uses a variation of CSP to specify the behaviors of components. and systems  CSP .

invoke!x -> callee.A Simple Specification in Wright System simple_cs Component client = port send-request = [behavioral spec] spec = [behavioral spec] Component server = port receive-request= [behavioral spec] spec = [behavioral spec] Connector rpc = role caller = (request!x -> result?x ->caller) ^ STOP role callee = (invoke?x -> return!x -> callee) [] STOP glue = (caller. 49 1.return?x -> callee.caller server.callee end simple_cs.request?x -> callee.12.2011 .result!x -> glue) [] STOP Instances s : server c : client r : rpc Attachments : client.send-request as rpc.receive-request as rpc.

UML as an ADL  The Positive  lowers entry barrier. both too much and too little 50 1. tools  Shortcomings of UML as an ADL  Weakly integrated models with inadequate semantics for (automated) analysis  Connectors are not first class objects  Visual notation with little generation support.12. mainstreams modeling. hidden and ambiguous relationships between views.2011 .

Hence  There is a rich body of research to draw upon  Much has been learned about representing and analyzing architectures  Effort is needed now to bring together the common knowledge and put it into practice 51 1.2011 .12.

stanford.For More Information  ACME: http://www.html Unicon: http://www.cs.2011 .html Aesop: ADML: http://www.html C2 SADL:  Wright:      52  Rapide: SSEP: http://www.

2011 .Formalisms  Formal models and techniques are cornerstones of a mature engineering discipline  Engineering disciplines used models and techniques in different ways  Provide precise. abstract models  Provide analytical techniques based on models  Provide design notations  Provide basis for simulations … 53 1.12.

What to formalize?  Architecture of a specific system  Allow the architect to plan a specific system  Becomes part of the specification of the system  Augments the informal characteristics of the SA  Permits specific analyses of the system 54 1.2011 .12.

What to formalize?  Architectural style  Describe architectural abstractions for families of systems  Purposes:  Make common idioms.2011 .12. patterns and reference architectures precise  Show precisely how different architectural representations can be treated as specializations of some common abstraction 55 1.

What to formalize  Theory of software architecture  Clarify the meaning of generic architectural concepts  Architectural connection. architectural style  Provide deductive basis for analyzing systems at an architectural level  Might provide rules for determining when an architectural description is well formed  Compositionality 56 1.12. hierarchical architectural representation.2011 .

2011 .What to formalize  Formal semantics of ADL:s  Architectural description is a language issue  Apply traditional techniques for representing semantics of languages 57 1.12.

12.2011 .Today’s takeaway  SA has a linguistic character  Programming languages are useful for comparison  Connectors are needed in addition to components  ADLs may grow in the future 58 1.