Software Architecture

Software Architecture
CS-545 Syllabus - Fall 2002 Rev 0.21 Haig F. Krikorian

General Issues Me: Office Hours: e-mail: Web Site:
Mr. Haig Krikorian, 25+ yrs. developing SW intensive systems Office Hours: 30 min. before and after class, Rm. 419. Web Site: Class Notes at: Class Notes at : Phone: (dept.) Course Time & Place: Monday (7-10) here Prerequisites: as specified How many are currently working in a SW position ? Fall 2002 CS-545-Fall-2002

Class Book & References Used
Required: Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996. Many IEEE, ACM, ELSEVIER, and Open Source papers that you are required to read I have prepared a packet of copyrighted papers that you need to purchase for this class. We will use these papers throughout the semester to drive home the key lesson concepts Other references actively used in this class: Evaluating Software Architectures: Methods & Case Studies, Addison-Wesley, ISBN X. Design & Use of Software Architectures: Adopting and Evolving a Product Line Approach: ISBN: SEI Selected Papers: USC Selected Papers: UCI Selected Papers: Other References & Standards discussed in this class IEEE 1471, ISO RM-ODP IEEE 1220, EIA-632, EIA-731, DO-178B, J-STD Fall 2002 CS-545-Fall-2002

Other Referenced Sites
Primary References: (ACM Copyrighted Papers) (IEEE Copyrighted papers) (Elsevier Copyrighted material) (Lots of open source materials) (Lots of open source materials) (Lots of open source materials) (Lots of open source materials) (A ton of open source materials) (Links to other sites) (Links to other sites) (Ontologies) (Architecture Definition Languages) Fall 2002 CS-545-Fall-2002

Secondary References Used: (Garlan’s Class on SA) Fall 2002 CS-545-Fall-2002

Tools: (xADL 2.0 ) (xADL) (xUml) (ACME SW) (RAPIDE) (Z) Fall 2002 CS-545-Fall-2002

Academic Dishonesty Cheating Inventing false information
Homework is individual Inventing false information Your work is individual Wrong citations (NA this class) Plagiarism Keep it that way… Collaboration this class Your projects are individual. Fall 2002 CS-545-Fall-2002

Ethics in Software Architecture Development
Aircraft disasters Airbus disasters Launch Disasters International launch disasters Domestic launch disasters Space Mission disasters Mars mission disasters Mars rover Space Shuttle Problems Space Station Problems Commercial Disasters Automotive disasters So who is responsible ? You … cannot blame loss of life, property, program funding, failure or customer dissatisfaction on “Oh …we did not know that was a requirement … or … We did not know you wanted it to work that way … or … We did not know that was an important consideration … or … That was to hard to implement so we ignored it … or … Our re-used code does not work as well as we had hoped for your problem… or We didn’t debug it enough….but we’ll get it next time around…” So…what discipline do YOU bring to architecture development? Fall 2002 CS-545-Fall-2002

Simple Case Study Three vendors have been asked to submit bids for work that tracks student credentials… All vendors supply demonstration systems that: Seem to meet the requirements Are all within similar cost estimates. All other things being equal … Who do you pick ? You ask them to come in and describe their architecture so as to get a better understanding of the long term costs to maintain and adapt the system to your planned expansions. Fall 2002 CS-545-Fall-2002

The Vendors The We Know Better. Com -> TheWKB.com
An medium to large experienced company that has developed a wide range of similar products over several years for a variety of customers. The Minority Owned Business. Com -> TheMob.com A small company that has developed a similar product and is looking to expand their business The Wet Behind the Ears. Com -> TheWBTE.com A grad students run venture that is looking to capture the contract in order to acquire start up funding. Fall 2002 CS-545-Fall-2002

The Proposed Architectures
TheWKB.com depicts what they call an architecture by showing the allocation of functional pieces to hardware. TheMob.com depicts what they call an architecture by showing a functional block diagram. TheWBTE.com depict what they call an architecture by showing a logical view of the functional elements and their interconnection dependencies. The System UI Functions.. DBMS WS (1) WS (…) WS (n) These depictions and others have been used to describe architectures – So who is correct ? What’s missing ? Fall 2002 CS-545-Fall-2002

So how do you even start to evaluate and compare the architectures against each other ?
How do determine (measure) which one is better at capturing: Functional relationships ? Data Flow ? Control Flow ? Event Handling ? Fault-Tolerance ? Operational capabilities: How do measure which one is better at addressing the issues wrt.: Homogenous vs. Heterogeneous systems? Expandability ? Interoperability ? Maintainability ? Upgradeability ? Responsiveness ? … etc.. WS (1) WS (…) WS (n) UI UI UI Functions.. Functions.. DBMS Do the boxes and lines have the same meaning both internal to an architecture and across competing architectures ? The System UI Functions.. DBMS DBMS Functions.. UI Who do you give the contract to? It should be obvious then that there needs to be a better (more formal) way of describing and evaluating an architecture ! Fall 2002 CS-545-Fall-2002

Industry Concerns Industry - We need to be able to:
Industry - We need to be able to: Construct the Best Architecture to meet the requirements Evaluate Competing Product Architectures Share methods, techniques, patterns, idioms for structuring complex systems Exploit commonalities in specific domains to provide a reusable framework for product families. Educate ourselves on technique and formal methods So what then what is meant by “Software Architecture”? What are the issues that SW Architecture must address? Fall 2002 CS-545-Fall-2002

What You Should Learn Understand the essential features of a given problem and then make the most appropriate architectural choices. How we are going to do this Recognize major architecture styles (paradigms) in existing software systems. Understand and evaluate existing software designs from an architectural perspective Generate reasonable architecture alternatives Understand how formal notations and models can characterize and reason about a formal design Describe an architecture adequately Present examples of architectures that serve as models for new designs. Understand how to use domain knowledge to specialize an architecture. Construct a medium sized architecture that satisfies an architectural perspective Fall 2002 CS-545-Fall-2002

Proposed Grading Policy
Readings 20% Assesses your ability to express fundamental software architecture themes and concepts Derived from Dr. Garlan’s (CMU) + Dr. Medvidovic (USC) class readings + the ones I assign Homework 20% Primarily: Derived from the Architecture Tradeoff Analysis Method Secondarily: Derived from Dr. Medvidovic’s (USC) class on Software Architecture Midterm-Final Question 10% (open notes) Tests your understanding of issues in transferring architectural decisions to designs and implementations. Project Notebook 40% Assesses your ability to actually apply what you have learned to an evolutionary software architecture. You will be given baseline requirements that will evolve thereby forcing you to evolve your design to address several architectural alternatives. My assessment 10% This class is an ACTIVE discussion between me and you. There are many required and suggested readings for this class. If you do NOT put the time and effort into the readings you will NOT be successful in either your project, the homework, or class. Fall 2002 CS-545-Fall-2002

Proposed Course Outline & Schedule (*)
Week 6: Independent Components: Models of Event Systems Implementation of Event Systems Communicating Process Architectures Week 7 Virtual Machines: Interpreters, Rule-Based Systems Week 8: Data Centered Systems Repositories Databases and Client-Server Systems Blackboard Systems, Hypertext Systems Week 3: DSSA: AESOP, UniCON, Cyberspace Info Architectures Week 9: Architecture Evolution & Issues Week 10: Formal Models of Processes Week 11: Architecture evaluation, analysis: ADL, ATAM Week 12: Connectors Heterogeneity & Mismatched Parts Interface Matching Week 13: Architecture Dynamics Week 14: Architecture design & selection Week 15: Architecture-based development and evolution Week 1: Course Introduction Background & Origins Introduction to Mega-programming Architecture Terms Architecture Styles: Week 2 Background Objects Decomposition Issues Building Blocks Formal Models (Z) Week 4 Data Flow Systems Batch Sequential & Pipeline Case Study Pipes & Filters (Unix Pipes) Formal Models for Data Flow Week 5: Call & Return Systems Main Program & Subroutine Object Oriented Systems Hierarchical Layers (*) We are in no hurry… I want to ensure you understand the material. The proposed as topics will spill over from week-to-week. Fall 2002 CS-545-Fall-2002

Organization of the Materials
Fall 2002 CS-545-Fall-2002

General Class Outline Lecture (3) hours:
We discuss the papers and the topics of interest I present the materials and we actively compare and contrast the different techniques. Last 15 minutes I answer any questions & concerns You can expect to spend ~9-12 hrs/week individually outside of class reviewing the material and working on homework & project. This class is an ACTIVE discussion between you and me on the topics as they apply to defining an architecture for our class project. Immerse yourself into the readings and the other papers I have made available to you. Fall 2002 CS-545-Fall-2002

Software Architecture
CS-545 Class Notes Haig F. Krikorian

CS-545 Week 1 Introduction

Problem Statement from Our Case Study
How do determine (measure) which one is better at capturing: Functional Flow ? Data Flow ? Control Flow ? Event Handling ? Fault-Tolerance ? Operational capabilities: How do measure which one is better at addressing the issues wrt.: Homogenous vs. Heterogeneous systems? Expandability ? Interoperability ? Maintainability ? Upgradeability ? Responsiveness ? … etc.. WS (1) WS (…) WS (n) UI UI UI Functions.. Functions.. DBMS Do the boxes and lines have the same meaning both internal to a unique architecture and across competing architectures ? The System UI Functions.. DBMS DBMS Functions.. UI Who do you give the contract to? It should be obvious then that there needs to be a better (more formal) way of describing and evaluating an architecture ! Fall 2002 CS-545-Fall-2002

Industry - We need to be able to: Construct the Best Architecture to meet the requirements Evaluate Competing Product Architectures Share methods, techniques, patterns, idioms for structuring complex systems Exploit commonalities in specific domains to provide a reusable framework for product families. Educate ourselves on technique and formal methods So what then what is meant by “Software Architecture”? What are the issues that SW Architecture must address? Fall 2002 CS-545-Fall-2002

SEI: Bib. Architecture Definition excerpts (What’s missing from these definitions?)
[Lane 90]: …structure and performance of software systems…. aspects include the division of functions among system modules, the means of communication between modules, and the representation of shared information. [Bhansali 92]: …. A topological organization of a set of parameterized modules, ….. [Garlan 92]: ….global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; composition of design elements; ….and selection among design alternatives. [Perry 92]: …. processing elements ….data elements; … connection elements …. rationale for the various choices… [Crispen 94]: … a partitioning strategy and (b) a coordination strategy. [Clements 94-2]: (organization of ..) components, connections, constraints, and rationale. [Moriconi 94]: …Component:… Interface: …Connector, …Configuration: …Mapping….Architectural style: [Garlan 94]: … high-level organization of computational elements and interactions between those elements. [FHayes-Roth 94]:….components described in terms of their behaviors and interfaces and ….interconnections. [Abowd 95]: components …. protocols of interaction … global system properties , …life-cycle issues [Garlan 95]: The structure of components … their interrelationships, and design and evolution guidelines over time. [ATA 96]: …minimal set of rules governing the arrangement, interaction, and interdependence of the parts . Fall 2002 CS-545-Fall-2002

What is Software Architecture ?
“There is no standard, universally-accepted definition of the term, for software architecture is a field in its infancy, although its roots run deep in software engineering” Definitions from recent books on software architecture. "Classic Definitions,“ through some of the more influential ones. Definitions from the SEI-CMU software architecture bibliography. Definitions provided to SEI-CMU via feedback definition forms link: So…What is your definition of software architecture? Fall 2002 CS-545-Fall-2002

What is a Software Architecture?
Paulisch, Frances. "Software Architecture and Reuse- An Inherent Conflict?" 214. Proceedings of the 3rd International Conference on Software Reuse. Rio de Janeiro, Brazil, November 1-4, Los Alamitos, CA: IEEE Computer Society Press, 1994 Architecture of the system An architecture is considered to consist of components and the connectors (interactions) between them Definitions of architecture, component, and connector (protocols) vary among researchers, this definition of architecture serves as a baseline for this technology description. Design vs Architecture Design explicitly addresses functional requirements Architecture explicitly addresses functional and non-functional requirements such as: reusability, maintainability, portability, interoperability, testability, efficiency, and fault-tolerance and the other Quality Attributes Fall 2002 CS-545-Fall-2002

The Goal of SW Architecture
Enable the construction of very large system architectures. Many, many connections Dynamic creation of components and dynamically de-selectable connections. Support for a Hierarchical design Process So we can gradually introduce the ranked ordered set of quality attributes we care about. Test & Validate partially instantiated architectures Especially true in large systems (QA: subsetability) Flexibility in allowing modules to be assigned to interfaces (QA: Interoperability) So How do we do this ? Fall 2002 CS-545-Fall-2002

Issues in Software Architecture
Architecture design or selection: ? create or select an architecture based on a set of functional, performance, and quality requirements? Architecture representation: ? communicate an architecture? ? represent an architectures?: ? select the set of information represented with a language. Architecture evaluation and analysis: ? analyze an architecture to predict qualities about the systems ? compare and choose between competing architectures Architecture-based development and evolution: ? build and maintain a system where components may not exist or are incompatible Architecture recovery: (See references) ? evolve a legacy system when changes may affects its architecture? ? extract architecture from supplied documentation.: Architecture: Static vs Dynamic View: (See References) Fall 2002 CS-545-Fall-2002

Architecture Design or Selection: Initial Rules on Selecting An Architecture
M. Shaw and P. Clements. A Field Boxology: Preliminary Classification of Architectural Styles for Software Systems. April (Open Lit.) If the problems is decomposable into sequential stages: Then consider data Flow (batch sequential or pipeline) If your problem involves passing rich data representations,: Then avoid pipelines restricted to ASCII. If in addition each stage is incremental, so that later stages can begin before earlier stages finish: Then consider a pipeline architecture. Else If the problem involves transformations on continuous streams of data (or on very long streams): If a central issue is understanding the data of the application, its management, and its representation: Then consider a repository or abstract data type architecture. If the data is long-lived: THEN focus on repositories. If the representation of data is likely to change over the lifetime of the program then define abstract data types in order to confine changes to particular components. If the input data is noisy (low signal-to-noise ratio) and the execution order cannot be predetermined Then consider a blackboard [Ni86] (We will add to this as the blackboard is probably the best place to start for real-time architecture with distributed data) If the execution order is determined by a stream of incoming requests and the data is highly structured Then consider a database management system. Give Examples of Each Kind of Real Problem Fall 2002 CS-545-Fall-2002

Architecture Design or Selection: Initial Rules on Selecting An Architecture
M. Shaw and P. Clements. A Field Boxology: Preliminary Classification of Architectural Styles for Software Systems. April (Open Lit.) If your system involves controlling continuing action, is embedded in a physical system, and is subject to unpredictable external perturbation so that preset algorithms go awry: Then consider a closed loop control architecture [Sh95]. If you have designed a computation but have no machine on which you can execute it Then consider an interpreter architecture. If your task requires a high degree of flexibility, configurability, loose coupling between tasks, and reactive tasks, Then consider interacting processes. If you have reason not to bind the recipients of signals from their originators: Then consider an event architecture. If the tasks are of a hierarchical nature: Then consider replicated worker or heartbeat style. If the tasks are divided between producers and consumers: Then consider client/server. If it makes sense for all of the tasks to communicate with each other in a fully connected graph: Then consider a token passing style. Give Examples of Each Kind of Real Problem Fall 2002 CS-545-Fall-2002

Architecture Representation Concepts
(Computer 2) Core Architecture Refinement: IEEE Transactions on Software Engineering, Vol 21, No .4 April 1995, pgs Component: An object with independent Existence, i.g. A module, process, procedure, or variable Interface: A typed object that denotes a logical point of interaction between a component and its environment. Connector: A typed Object relating interface points, components, or both Configuration: A collection of Constraints that wire the objects into a specific architecture Mapping: A relationship that defines a syntactical translation from the language of an abstract architecture to the language of a concrete architecture Architectural Style: A vocabulary of design elements, constraints that determine how they are to be used and a semantic definition of the connectors associated with this style. What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Architecture Evaluation and Analysis: SEI: Architecture Quality Attributes Used for Evaluation & Analysis Need Satisfaction Measures Effectiveness Necessity of Characteristics Sufficiency of Characteristics Responsiveness Correctness Completeness / Incompleteness Consistency Traceability Provably Correct Verifiability Testability Performance Measures Dependability Availability Reliability Accuracy Safety Trustworthiness Vulnerability Integrity Confidentiality Denial of Service Survivability Accountability Auditable Security Efficiency / Utilization Capacity Real-Time Responsiveness Throughput Usability / Human Engineering Error Proneness Operability Fidelity What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Architecture Evaluation and Analysis: SEI: Architecture Quality Attributes Used for Evaluation & Analysis Maintenance Measures Maintainability Understandability Complexity Simplicity Structuredness Readability Adaptive Measures Interoperability Compatibility Openness Portability Scalability Reusability Functional Scope Retrievability Organizational Measures Cost of Ownership Cost of Operation Operations Personnel Training Operations System Cost of Maintenance Maintenance Personnel Maintenance Control HW Maintenance SW Maintenance Requirements Growth Life-Time Operational Capability Acquisition Cycle Time Software Change Cycle Time Productivity What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Architecture Evaluation and Analysis: ISO: Architecture Quality Attributes
ISO/IEC 9126: Information Technology – Software Product Evaluation – Quality characteristics and guidelines for their use, 1991. Functionality Suitability, Accuracy, Interoperability, Compliance, Security What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Reliability Maturity, Fault-Tolerance, Recoverability Usability Understandability, Learn ability, Operability Efficiency Time behavior, Resource Behavior Maintainability Analyzability, changeability, Stability, Testability Portability Adaptability, Install ability, Conformance, Replace ability Fall 2002 CS-545-Fall-2002 ISO vs. SEI Differences?

Architecture Recovery: Some References
How can we reconstruct an architecture from the implementation? Melissa P. Chase, Steven M. Christey, David R. Harris and Alexander S. Yeh, "Recovering software architecture from multiple source code analyses", Proceedings of Workshop on Program Analysis for Software Tools and Engineering, June 16, 1998, Montreal Canada, pp Huw Evans and Peter Dickman, "Zones, Contracts and Absorbing Changes: An Approach to Software Evolution", Proceedings of OOPSLA'99, November 1-5, 1999, Denver, CO, USA, pp D. R. Harris, H. B. Reubenstein, A. S. Yeh, "Reverse Engineering to the Architectural Level ", Proceedings of the 17th Int'l Conference on Software Engineering, 1995, pp D. Garlan, R. Allen, and J. Ockerbloom, "Architectural Mismatch, or why it's hard to build systems out of existing parts“, Proceedings of the 17th. Int'l Conference on Software Engineering, Seattle, WA, April 1995, pp Fall 2002 CS-545-Fall-2002

Architecture Representations: Static View vs. Dynamic View
“Current software architecture research assumes a system's architecture is static, …it does not evolve during execution.” Architectures must be able to evolve during execution. “First, the architectures of many existing systems change during execution, and are poorly modeled using existing techniques. Examples include systems built using OLE, OpenDOC, or CORBA, in which new components may be loaded and unloaded during execution.” “Second, many systems would benefit from the dynamism afforded by a dynamic architecture. Examples include systems characterized as long running and mission critical since the delays and risks associated with shutting down these systems for upgrades may be expensive.” Give Examples of Real World Problems (Internet?) Fall 2002 CS-545-Fall-2002

Architecture Representations
Three Important Recent Advancements: Development of Architecture Definition Languages (ADLs) and Tools Emergence of product line engineering and architectural standards Codification and dissemination of architecture design expertise. Fall 2002 CS-545-Fall-2002

Background Cont: Why an ADL: (NOT UML !!!) Why Not Use UML Directly??
Why an ADL: (NOT UML !!!) Provide abstract description of the system Expose certain properties and hide others Allows designers to reason about the ability of a system to satisfy requirements Provides a foundation for system construction and composition Why Not Use UML Directly?? Note We go from ADL -> UML -> Implementation UML alone is not suited for: representing architectural concepts and therefore restricts our ability to automate the analysis of architectural properties. UML needs to be augmented with a Constraint Language to capture architecture issues There are Tools (xUML based) that permit the exercise of UML models in order to investigate performance related requirements Fall 2002 CS-545-Fall-2002

Roles of an ADL Understanding Reuse Construction Evolution Analysis
Understanding Exposes the high level constraints on a system and RATIONALE for specific Choices (see also EIA-632) Reuse Supports Product Line and Domain Specific Architectures Descriptions Construction Supports defining components and their dependencies Evolution Support the definition of reconfiguration of components and connections to handle more quality attributes Analysis System constraint checking, conformance to: style imposed constraints, quality attributes, module and connection dependencies, and domain specific architectures. Management Supports the need for critical evaluation of architecture to understand requirements, implementation strategies, and risks. Fall 2002 CS-545-Fall-2002

Background Cont: ADLs Adage: Description of avionics navigation and guidance C2: Supports the description of UI systems using event based style Darwin: Supports the Analysis of Distributed Message Passing Systems Meta-H: Provides guidance for real-time avionic control software RAPIDE: Permits architectural designs to be simulated SADL: Provides a formal basis for Architectural Refinement UniCon: Provides a high-level compiler for architecture designs that supports a mixture of heterogeneous component and connector types Wright: Supports the Formal Specification & Analysis of interactions between architectural components Fall 2002 CS-545-Fall-2002

Background Cont: Advances in ADLS has promoted the development of ways to integrate these tools into a common framework. ACME: Framework for describing architectural structures and mechanisms for adding semantics to that structure The XML of Architecture Description: DOWNLOAD THE SW !!! You WILL Present your architectures in ACME and UML. Also DOWNLOAD THE xUML SW !!! Unfortunately all the ADLS are still in a ‘research” state… so … do not expect them to install and execute as a commercial product. Fall 2002 CS-545-Fall-2002

Background Cont: Product line engineering and architectural standards
Design & Use of Software Architectures: Adopting and Evolving a Product Line Approach: ISBN: Product line engineering and architectural standards Need to consider the requirement relationships between products Need to address Reuse Need for Cross Vendor Integration Standards What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Codification and dissemination of architecture design expertise. Lack of common representations Emergence of Architectural Styles Design Vocabulary, constraints on vocabulary use and semantic assumptions on the vocabulary Each Style is typically associated with a set of analyses I,e. processing latencies vs. transaction rates. Enables the adoption of architectural patterns !!! (Don’t need to start from scratch !!) Fall 2002 CS-545-Fall-2002

Background Cont: Trends in Software Architecture Development
Trends in Software Architecture Development Build vs. Buy tradeoff The need for industry Architecture standards to support the integration of COTS components. Network Centric Computing Pervasive Computing Fall 2002 CS-545-Fall-2002

Background Cont: Challenges of Network Centric Computing
Design & Use of Software Architectures: Adopting and Evolving a Product Line Approach: ISBN: Challenges of Network Centric Computing The need for architectures that scale up to the size and variability of the Internet. The need to support computing with dynamically formed, task-specific, coalitions of distributed autonomous resources (Service Based Architectures like Jini) The need for architectures to be flexible in accommodating commercial application service providers. The need for architectures that permit the end-user to do their own system composition. Fall 2002 CS-545-Fall-2002

Background Cont: Challenges of Network Centric Computing The need for architectures suited for resource constrained systems (You are to overloaded …I will go find some where else to execute) The need for architectures to handle dynamic reconfiguration while ensuring availability (New products and services are introduced.. Yet I still want to provide uninterrupted service) The need for architectures to better handle user mobility Provide more automated control over management of resources and services across different environments. Fall 2002 CS-545-Fall-2002

CS-545 Week 2 Origins

Week 2 Origins Review of Readings Origins of Software Architecture
Architecture Terms and Description Project Contents General Overview of Architectural Styles Suggested Readings Fall 2002 CS-545-Fall-2002

Architecture Terms that get thrown about
The System UI Functions.. DBMS WS (1) WS (…) WS (n) Asynchronous: Since connections and applications are intermittent, service requesters and providers may not be accessible at the same time, necessitating support for asynchronous communication What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Atomic: After a transaction executes, either all or none of its operations take effect Awareness: Highly distributed, decentralized, mobile, applications must be aware of their execution context in order to properly adapt to any context changes. For this reason, the middleware must be able to monitor and inform the running application of its execution context. How are these issues addressed in each architecture? Fall 2002 CS-545-Fall-2002

Behavior: (dependencies between events) What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Causality: Being able to depict the causal history between events time, and response process execution time Centralized: (Have class explain) Component based Style Software components may be written in different programming languages. They can more readily be reused and/or substituted with other components in an architecture. The System UI Functions.. DBMS WS (1) WS (…) WS (n) How are these issues addressed in each architecture? Fall 2002 CS-545-Fall-2002

Consistency: (Of States): (Have class explain) What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Correctness:(Have class explain) Delivery guarantees: In resource-constrained and embedded systems, the utility of a service often directly depends on how many and at what times it has been delivered. The middleware should thus provide support for service delivery guarantees and real-time constraints. Disconnected operation : Due to the nature of mobile devices, their network connections are intermittent, with periods of disconnection [38]. The middleware should support system operation during such periods. The System UI Functions.. DBMS WS (1) WS (…) WS (n) How are these issues addressed in each architecture? Fall 2002 CS-545-Fall-2002

Efficiency : The middleware should impose minimal overhead on an application's execution. The goal is to enable efficient execution of applications on platforms with varying characteristics (e.g., speed, capacity, network bandwidth). What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Decentralized: (Have class explain) Durability: Under failures, how does the system behave. The System UI Functions.. DBMS WS (1) WS (…) WS (n) How are these issues addressed in each architecture? Fall 2002 CS-545-Fall-2002

Efficient: (Have class explain) What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Events: (Patterns of Events) Fault-tolerance: The System UI Functions.. DBMS WS (1) WS (…) WS (n) How are these issues addressed in each architecture? Fall 2002 CS-545-Fall-2002

Flexible: Multiple users may be interacting with the system. Multiple dialogs may be active and described in different formalisms. Multiple tool kits and media types may be employed. Architectures may be changed dynamically. A conceptual architecture is distinct from an implementation architecture; multiple implementation architectures may realize the same conceptual architecture. Modules can be added and assigned to interfaces What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? The System UI Functions.. DBMS WS (1) WS (…) WS (n) How are these issues addressed in each architecture? Fall 2002 CS-545-Fall-2002

Heterogeneity – In order to maximize the flexibility of application implementations and the potential for reuse of off-the-shelf (OTS) components, the middleware should support heterogeneous programming languages (PL), operating systems (OS), hardware platforms, and network protocols. What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Interfaces: (& types) (Have class explain) The System UI Functions.. DBMS WS (1) WS (…) WS (n) How are these issues addressed in each architecture? Fall 2002 CS-545-Fall-2002

Interoperable: The ability to operate with other languages and systems. What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Isolation: (Of transactions) (Have class explain) Mainframe The System UI Functions.. DBMS WS (1) WS (…) WS (n) How are these issues addressed in each architecture? Fall 2002 CS-545-Fall-2002

Mobile: Ownership change of a resource, or the movement of processing entities, communication links Hardware devices are highly mobile and resource constrained. Properly addressing these characteristics may require “on-the-fly” distribution of non-essential parts of a system to external devices, and migration of data and code to accommodate context changes What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Maintainable: (Have class explain) The System UI Functions.. DBMS WS (1) WS (…) WS (n) How are these issues addressed in each architecture? Fall 2002 CS-545-Fall-2002

Portable: (Have class explain) What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Re-configurable: Constantly changing environments in which PitM applications execute require seam-less adaptation to the changes without shutting down the application The middleware should thus support dynamic system reconfiguration. Reusable: The System UI Functions.. DBMS WS (1) WS (…) WS (n) How are these issues addressed in each architecture? Fall 2002 CS-545-Fall-2002

Scalable: Components may be of various granularity. They may be running in a distributed, heterogeneous environment. There is no assumption of shared address space among components and each component may have its own thread(s) of control In order to effectively manage the large numbers of devices, components, and communication events present in PitM systems, the middleware should be scalable. What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? The System UI Functions.. DBMS WS (1) WS (…) WS (n) How are these issues addressed in each architecture? Fall 2002 CS-545-Fall-2002

Security – All nodes in a (changing) network comprising a application cannot be trusted a priori. For this reason, the middleware should support secure communication between components. What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? (have class explain) Structured-ness: Time sharing computing: The System UI Functions.. DBMS WS (1) WS (…) WS (n) How are these issues addressed in each architecture? Fall 2002 CS-545-Fall-2002

Testable: (have class explain) What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Triggers: Understandable: Usable: The System UI Functions.. DBMS WS (1) WS (…) WS (n) How are these issues addressed in each architecture? Fall 2002 CS-545-Fall-2002

What is Software Architecture
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996. Structural Issues: Composition Organization, Control Structures, Protocols, synchronization, data access, logical to physical design assignments, design composition, physical distribution of elements, scaling and performance, evolutionary paths, and design alternatives ….(other quality attributes) Architectural Styles: Client-server, etc… Formal Notations: ADL, ATAM, ABAS, MILs, etc.. Software Design Levels Fall 2002 CS-545-Fall-2002

An engineering discipline for Software
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996. What is Engineering “The critical difference is the ability to put together little pieces of the problem that are relatively well known, without having to generate custom solution for every application.” Design Options? How to choose between options? Fall 2002 CS-545-Fall-2002

The Current state of Software Technology
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996. Maturity of the Supporting Science We have not really been developing SW all that long!! Formalism for Software Architecture really are in their infancy Interaction between Science & Engineering Codification through abstract Mechanisms Regular increases in abstraction levels 1950: High Level Languages with simple execution patterns first introduced 1960: Introduction of Modules to protect data and algorithms. 1970: Abstract Data Types converted to reality 1975: How do connect things together? First MILs to declare export and import of variables and functions. 1990: “MILs, interface languages, formalisms, and analysis techniques, only support simple interconnection between programming modules through procedure calls and data sharing. They assume ..” simple name matching can be used to infer inter-module interaction … all modules are written in the same language … all modules are available during system construction … module interfaces describe the other modules with which they interact.” (What advances are you aware of since then) Fall 2002 CS-545-Fall-2002

MIL Continued Current Approach: Benefits: Drawbacks:
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996. Current Approach: Each module defines or provides a set of facilities available to other modules and uses facilities provided by other modules. Benefits: Maps to current programming langauges Supports Compiler name resolution Supports type checking and automated checks. Drawbacks: Fail to distinguish between implementation and interaction relationships between modules. Still Open Issue: How do I express an architecture? Fall 2002 CS-545-Fall-2002

The Status of Software Architecture
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996. (1995) No formal mechanism to describe (characterize) an architecture Develop Architecture Definition Languages (ADL) Develop Architecture Patterns (Codification) Develop Framework for Specific Domains Develop Formalisms for Reasoning about Architectures See Shaw page 17, second paragraph, on current drawbacks. See the “What You Should Learn” Chart Fall 2002 CS-545-Fall-2002

The Plan of The Text Book
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996. Primary: Understand architectural abstractions Codifying ways in which components interact Distinguishing between the various architectural principles. Secondary: Emerging Notations Architecture Selection Techniques Formal Models of Architectures and Architecture Style Architecture Description Languages Architecture Construction Tools Fall 2002 CS-545-Fall-2002

Towards Defining an Architecture
System Decomposition Parnas 72 Modular Structure and Composition of Complex Systems Parnas 85 Software Module Interface Specification Module Interconnection Prieto-Diaz 86 Mega Programming From Modules to Systems Fall 2002 CS-545-Fall-2002

System & Component Decomposition Issues
How to best determine the elements of? Components, connectors, their configuration What level of granularity is required? What constraints on decomposition are imposed by functional requirements non-functional requirements envisioned design patterns system scale computing environment customers/users Fall 2002 CS-545-Fall-2002

Components & Connector Interactions
What assumptions can elements make about one another? How do components interact? (Control & Data Interaction) What are the connectors in the system? What is the role of connectors? Coordination (Control Topology? Events? State?) Communication (Data Topology?) What is the nature of connectors? type of interaction degree of concurrency degree of information exchange Fall 2002 CS-545-Fall-2002

System Decomposition Cont.
Modules: Mechanisms for improving system flexibility and comprehension A responsibility (Role) rather than a subprogram Localizes Role unique design decisions Modular Programming Modules do not know the internals of other modules Able to replace modules without system reassembly. Fosters independent development groups. Able to assign roles to modules. Fall 2002 CS-545-Fall-2002

Decomposition & Information Hiding
Make each major processing step a module Is this still valid? Information Hiding Each module represents a Role and its associated design decisions. Interface definitions reveal only what is necessary System details likely to change are kept hidden Each data structure is kept in only one module Access to other modules internal structures is through access methods. Fall 2002 CS-545-Fall-2002

Modular Structure & Composition of Systems
How do we determine which elements are needed? (hint..See Use case Analysis) Where in architecture do we locate existing Components (hint..See Use case Analysis) Connectors (hint..See Use case Analysis) Configurations (hint..See Use case Analysis) How do we know we have the right composition and configuration of elements? Fall 2002 CS-545-Fall-2002

Module Guide Example Goals: Describes Module:
Understand module responsibility w/o knowing module internals Identify relevant modules from w/o knowing complete picture Defines criteria used to assign module responsibility Defines scope and content of design documents. Describes Module: Roles (See Supporting Activity Diagrams) Internal Operations (See Use case internal sequence desc.) Design Decisions (See Use case descriptions) Capabilities provided by each module (See Use case descriptions) Interdependencies (See Use case sequence diagrams) We can fulfill the intent of Parnas through our Use Case Analysis Method Fall 2002 CS-545-Fall-2002

Parnas: A7-E Module Guide Example
SWA/papers/parnas84-mod-structure.pdf Hardware Hiding Module (HHM) Those items affected by hardware changes Contains data structures and algorithms to implement the virtual HW (HW API Classes) Behavior Hiding Module (BHM) (Requirements Document) Function Driver Module Shared Services Module These programs determine the values sent to the virtual HW devices provided by the HHM Note that the focus was on the observable behavior Software Decision Module (SDM) Hides SW design Decision Application Data Type Module Physical Model Module Data Module (Not in Requirements Documents) Parnas: Use of Information hiding in systems is practical but NOT enough. Need a design guide for the modules. Need a way to describe how the pieces will fit together. Note the additions by D.L. Parnas to his original discussion in We can fulfill the intent of Parnas through our Use Case Analysis Method Fall 2002 CS-545-Fall-2002

Module Interconnect Languages (MILs) Main Concepts
Separate Language to Describe the System Perform Static Type Checking at Inter-module level of Decomposition Consolidate design & module construction process in a single description Control different versions and families of a system. Fall 2002 CS-545-Fall-2002

Module Interconnection Language Background
As software system size and complexity increase, the task of integrating independently-developed subsystems becomes increasingly difficult. In the 1970s, manual integration was augmented with various levels of automated support, including support from module interconnection languages (MILs). The first MIL, MIL75, was described by DeRemer and Kron, who argued with integrators and developers about the differences between programming in the small, for which typical languages are suitable, and programming in the large, for which a MIL is required for knitting modules together. MILs provide formal grammar constructs for identifying software system modules and for defining the interconnection specifications required to assemble a complete program. Fall 2002 CS-545-Fall-2002

Module Interconnection Language Background
MILs increase the understandability of large systems They formally describe the structure of a software system They consolidate design and module assembly in a single language. MILs improve the maintainability of a large system They can be used to prohibit maintainers from accidentally changing the architectural design of a system They can be integrated into a larger development environment in which changes in the MIL specification of a system are automatically reflected at the code level and vice versa. Fall 2002 CS-545-Fall-2002

Module Interconnect Languages (MILs)
Prieto-Diaz, Ruben & Neighbors, James. "Module Interconnection Languages." Journal of Systems and Software 6, 4 (1986): Frank DeRemer and Hans H. Kron, Programming in the large vs Programming in the Small, IEEE Transactions on Software Engineering, Jun e1976 A MIL identifies the system modules and states how they fit together to implement the system's function Express the intent of the system MILs are not concerned with what the system does how the major parts of the system are embedded in the organization, or how the individual modules implement their functions Fall 2002 CS-545-Fall-2002

Module Interconnect Languages (MILs)
Prieto-Diaz, Ruben & Neighbors, James. "Module Interconnection Languages." Journal of Systems and Software 6, 4 (1986): Tichy, W. F. "Software Development Control Based on Module Interconnection," Proceedings of the 4th International Conference on Software Engineering. Munich, Germany, September 17-19, New York, NY: IEEE Computer Society Press, 1979. Cooprider, Lee W. The Representation of Families of Software Systems (CMU-CS ). Pittsburgh, PA: Computer Science Department, CMU, 1979. Frank DeRemer and Hans H. Kron, Programming in the large vs Programming in the Small, IEEE Transactions on Software Engineering, Jun e1976 A MIL specification of a system constitutes a written description of the system design. A MIL specification can be used to enforce system integrity and inter-modular compatibility. Support incremental modification. Modules can be independently compiled and linked; full recompilation of a modified system is not needed. Enforce version control. Different versions (implementations) of a module can be identified and used in the construction of a software system. Allows different versions of subsystems to be defined in terms of different versions of modules. MILs can be used to describe families of modules and systems Fall 2002 CS-545-Fall-2002

MILs Continues MIL Example: MILs have been extended with
Garlan, David & Allen, Robert. "Formalizing Architectural Connection," Proceedings of the 16th International Conference on Software Engineering. Sorrento, Italy, May 16-21, Los Alamitos, CA: IEEE Computer Society Press, 1994. MIL Example: See Module XYZ Provides … Requires … Consists-Of … : MILs have been extended with notions of communication protocols and constructs for defining semantic properties of system function. These extended MILs are referred to as Architecture Description Languages (ADLs). Fall 2002 CS-545-Fall-2002

? Environments support Mega programming ?
Frank DeRemer and Hans H. Kron, Programming in the large vs Programming in the Small, IEEE Transactions on Software Engineering, Jun e1976 An approach to the development of large scale complex systems to exploit commonness of components, across a specific domain A technology that interconnects large, independent, and isolated information management systems from different organizations so that they function together as one unified system. This paradigm suggests that information management environments of large organizations can be linked together to form "mega- applications." The building blocks of these applications consist of the software systems belonging to each of the individual entities or government agencies that compose the overall system. In this model, the information management system of an entire corporation would be referred to as a single mega-module component of the overall system. This architecture is typically a collection of geographically distributed modules linked by high-capacity dedicated networks. ? Environments support Mega programming ? Fall 2002 CS-545-Fall-2002

Architecting Approaches
Process-driven approach Tailorable Dynamic generality vs. practical usefulness Guided by analysis of the problem Scenario (Use case) Driven Approach Checklist-driven approach domain-specific Static Practical Guided by analysis of solutions Enumerate the design alternatives Experience has shown that you really need some combination of both, the process driven approach to identify the components and the checklist driven approach to ensure completeness. Fall 2002 CS-545-Fall-2002

Week 3,4 and 5 Architectural Styles
CS-545 Week 3,4 and 5 Architectural Styles

The Proposed Architectures
TheWKB.com depicts what they call an architecture by showing the allocation of functional pieces to hardware. TheMob.com depicts what they call an architecture by showing a functional block diagram. TheWBTE.com depict what they call an architecture by showing a logical view of the functional elements and their interconnection dependencies. The System UI Functions.. DBMS WS (1) WS (…) WS (n) These depictions and others have been used to describe architectures – So who is correct ? What’s missing ? What analysis can I perform ? Fall 2002 CS-545-Fall-2002

So how do you even start to evaluate and compare the architectures against each other ?
How do determine (measure) which one is better at capturing: Functional relationships and Distribution? Data Topology (Distribution) & Flow ? Control Topology Flow ? Event Handling ? Fault-Tolerance ? Operational capabilities: How do measure which one is better at addressing the issues wrt.: Homogenous vs. Heterogeneous systems? Expandability ? Interoperability ? Maintainability ? Upgradeability ? Responsiveness ? … etc.. WS (1) WS (…) WS (n) UI UI UI Functions.. Functions.. DBMS Do the boxes and lines have the same meaning both internal to an architecture and across competing architectures ? The System UI Functions.. DBMS DBMS Functions.. UI Who do you give the contract to? It should be obvious then that there needs to be a better (more formal) way of describing and evaluating an architecture ! Fall 2002 CS-545-Fall-2002

Industry - We need to be able to: Construct the Best Architecture to meet the requirements Evaluate Competing Product Architectures Share methods, techniques, patterns, idioms for structuring complex systems Exploit commonalities in specific domains to provide a reusable framework for product families. Educate ourselves on technique and formal methods Fall 2002 CS-545-Fall-2002

Research in Architectures
ftp:se.uwaterloo.ca/~jmatlee/papers/fse00.ps Formalisms (like those below) for reasoning about properties of component-based systems do not exist. Milner's Calculus of Communicating Systems (Milner, 1980) Hoare's Communicating Sequential Processes (Hoare, 1981) A calculi to reason about component topologies of architectures is proposed in: Fall 2002 CS-545-Fall-2002

What is a Software Architecture?
Paulisch, Frances. "Software Architecture and Reuse- An Inherent Conflict?" 214. Proceedings of the 3rd International Conference on Software Reuse. Rio de Janeiro, Brazil, November 1-4, Los Alamitos, CA: IEEE Computer Society Press, 1994 Architecture of the system There is no standard, universally-accepted definition of the term, for software architecture is a field in its infancy, although its roots run deep in software engineering An architecture is considered to consist of components and the connectors (interactions) between them. Architecture explicitly addresses functional and non-functional requirements such as: reusability, maintainability, portability, interoperability, testability, efficiency, and fault-tolerance and the other Quality Attributes Design vs Architecture Design explicitly addresses functional requirements Fall 2002 CS-545-Fall-2002

Issues in Software Architecture
Architecture representation: (this session) How does one communicate an architecture? How does one represent an architectures?: How does one select the set of information represented with a language. Architecture design or selection: (intro in this session: covered later in another session) How does one create or select an architecture based on a set of functional, performance, and quality requirements? Architecture evaluation and analysis: (covered in another session) How does one analyze an architecture to predict qualities about the systems How does one compare and choose between competing architectures Architecture-based development and evolution: (covered in another session) How does one build and maintain a system where components may not exist or are incompatible Architecture recovery: (covered in another session) How does one evolve a legacy system when changes may affects its architecture? How does one extract architecture from supplied documentation.: Architecture: Static vs Dynamic View: (covered in another session) Fall 2002 CS-545-Fall-2002

Architecture Representation Concepts
(Computer 2) Core Architecture Refinement: IEEE Transactions on Software Engineering, Vol 21, No .4 April 1995, pgs Component: An object with independent Existence, i.g. A module, process, procedure, or variable Interface: A typed object that denotes a logical point of interaction between a component and its environment. Connector: A typed Object relating interface points, components, or both Configuration: A collection of Constraints that wire the objects into a specific architecture Mapping: A relationship that defines a syntactical translation from the language of an abstract architecture to the language of a concrete architecture Architectural Style: A vocabulary of design elements, constraints that determine how they are to be used and a semantic definition of the connectors associated with this style. The differences in the considerations for a local vs distributed homogeneous vs distributed heterogeneous system drive the definition of the particular architecture style. Fall 2002 CS-545-Fall-2002

Architecture Evaluation and Analysis: ISO: Architecture Quality Attributes
ISO/IEC 9126: Information Technology – Software Product Evaluation – Quality characteristics and guidelines for their use, 1991. Functionality Suitability, Accuracy, Interoperability, Compliance, Security What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Reliability Maturity, Fault-Tolerance, Recoverability Usability Understandability, Learn ability, Operability Efficiency Time behavior, Resource Behavior Maintainability Analyzability, changeability, Stability, Testability Portability Adaptability, Install ability, Conformance, Replace ability Fall 2002 CS-545-Fall-2002

Architectural Style An architectural style is a description of component types and their topology. It also includes a description of the pattern of data and control interaction among the components and an informal description of the benefits and drawbacks of using that style. Architectural styles define classes of designs along with their associated known properties. They offer experience-based evidence of how each class has been used historically, along with qualitative reasoning to explain why each class has its specific properties. (patterns) Fall 2002 CS-545-Fall-2002

Architecture Styles M. Shaw, "Patterns for Software Architectures", Proceedings of PLoP '94 Conference, Pattern Languages of Program Design (PLoPD), Edited by J. O. Coplien and D. C. Schmidt, Addison-Wesley, 1995, Chapter 24, pp M. Shaw and P. Clements. A Field Boxology: Preliminary Classification of Architectural Styles for Software Systems. April P. Inverardi and A. L. Wolf, "Formal Specification and Analysis of Software Architecture Using the Chemical Abstract Machine Model, IEEE Transactions on Software Engineering, Vol. 21, No. 4, April 1995 Looking for a Uniform Description of an Architecture Which kinds of Components and connectors are used in the style Examples: programs, objects, processes, filters The allowable kinds of components and connectors are primary discriminants among the styles, however the following four items also contribute to defining the particular style How is control shared, allocated m and transferred among the components Topology : ? Linear (non-branching) , ? A cyclical, ? Hierarchical, ? Star , ? Arbitrary, ? Static or Dynamic Synchronicity: ? Lockstep (sequential or parallel depending on the threads of control) , ? Synchronous, ? Asynchronous How is data communicated through the system Data Flow Topology as above for control Continuity: Continuous Flow: fresh data available at all times, Sporadic Flow, High-Volume vs Low Volume (see USB) (? How much network band-with is / can be dedicated to data synchronization) Mode: Describes how data is made available throughout the system Object style: data is passed from component to component Shared data style: data is made available in a place accessible to all Copy out- Copy In mode, vs. broadcast or multicast, How do Data and control interact (data flow & topology vs. control flow & topology) Pipe & Filter (data & control pass together) vs. Client-Server control flows into the servers and data flows in to the clients. What type of reasoning (analysis) is compatible with the style Asynchronously operating components (Non-deterministic) vs. fixed sequence of atomic steps, Fall 2002 CS-545-Fall-2002

Capturing an Architectural Style
M. Shaw and P. Clements. A Field Boxology: Preliminary Classification of Architectural Styles for Software Systems. April (Open Lit.) Y. Morisawa et. al Architectural Styles for distributed processing systems and practical selection method Information and Software Technology 44 (2002) Style Constituent Parts Control Issues Data Issues Control/Data Interaction Comp-onents Conn-ectors Topology Synch-ronicity Binding Time Continuity Mode Isomorphic Shapes Flow Direction Data Flow Style dominated by the motion of data through the system, with no upstream content control by reciepient Variant One : Variant (n) Key to Column Entries Fall 2002 CS-545-Fall-2002

A View of Architecture Styles
M. Shaw, "Patterns for Software Architectures", Proceedings of PLoP '94 Conference, Pattern Languages of Program Design (PLoPD), Edited by J. O. Coplien and D. C. Schmidt, Addison-Wesley, 1995, Chapter 24, pp M. Shaw and P. Clements. A Field Boxology: Preliminary Classification of Architectural Styles for Software Systems. April Data Flow (1) Batch Sequential (traditional systems) & Pipeline Systems (2) Pipes & Filters (Linked Stream transformers) Call & return (3) Main Program & Subroutine (4) OO Systems (5) Hierarchical Layers Independent Components (6) Communicating Processes (7) Event Systems Virtual Machines (8) Interpreters (9) Rule-Base systems Data-Centered Systems (Repository) (10) Databases (11) Hypertext Systems (12) Blackboards (13) Distributed Processing Styles (14) Process Control Style (15) : (16) : Fall 2002 CS-545-Fall-2002

Batch Sequential General Constructs: Advantages: Disadvantages:
General Constructs: Processing Steps are independent programs Each steps runs to completion before the next program starts Data is transmitted in complete data sets between programs Historically used in Data processing Needs a scheduler to submit the jobs (jcl) Advantages: Allows the designer to understand the system in terms of business process steps. Easy to maintain (supposedly) and add new or replace programs. However experience has shown that program and data stores are really tied to the business process. Disadvantages: Not good at interactive applications Limited Support for concurrent execution as each program needs ALL the data before it starts. Need to get ALL the data through the system before we can really see results. Not responsive to changes, No Event Handling, No Fault Tolerance, Many many problems if tapes are run out of sequence. Fall 2002 CS-545-Fall-2002

Suggested Batch Sequential Style
Scheduler Data Store (1) Data Store (2) Program 1 Program 2 Program (n) Components are the Programs and Data stores. Connectors are one way pipes that transfer bulk data sets. Fall 2002 CS-545-Fall-2002

Pipe & Filter (Pipeline)Architecture Styles
General Constructs: Pipes move data between filters. The Filters must be independent entities and do NOT share state with other filters. Filters Do NOT know their sources and sinks of data. The correctness of the output of a pipe & filter network should not depend on the order in which the filters preformed their processing. Examples: Image Processing, Unix pipe shell programs, Compilers Advantages: Allow the designer to to understand the system in terms of composition of filters. Support Re-Use Easy to maintain and add new or replace old filters. Permit specialized analyses: (Throughput & deadlock) Each filter can be implemented as a separate task and executed in parallel with other filters. Disadvantages: Not good at interactive applications, incremental display updates May need to maintain connections between separate yet related streams. Different filters types may therefore require a common representation (packing & unpacking costs) Each event handled from font to back. Program 1 Program 2 Program (n) Fall 2002 CS-545-Fall-2002 Can I embed commands and data together and have the stream self executing?

One way Data Flow Through a Network of Filters
Gregory R. Adams. Paradigms for Process Interaction in Distributed Programs. ACM Computing Surveys, 23(1):49-90, March 1991. Filters can be interconnected in different ways As long as the input assumptions and output behaviors are the same, one filter process or a network of filters can be replaced by a different implementation of a filter process or network that accomplish the same tasks. What does this impose on the rest of the filters if they are written in a different language or have a different implementation? The output of a filter process is a function of its input This specification relates the value of messages sent on output channels to the values of messages received on input channels. The actions a filter takes in response to receiving input must ensure this relation every time the filter sends output. Requires us to understand and specify our communication and underlying data assumptions. The output produced by one filter meet the input assumptions of another. Fall 2002 CS-545-Fall-2002

Call & Return Style: Mainframe
General Constructs: All intelligence is within the central host computer. Users interact with the host through a terminal that captures keystrokes and sends that information to the host. Advantages: Mainframe software architectures are not tied to a hardware platform. User interaction performed with workstations. Disadvantages: A limitation of mainframe software architectures is that they do not easily support graphical user interfaces or access to multiple databases from geographically dispersed sites. Mainframes have found a use as a server in distributed client/server architectures UI Note the connectors may be two-way as contrasted with the dataflow style as we have control from UI to Mainframe and Data from the Mainframe to UI Fall 2002 Main Frame CS-545-Fall-2002

Call & Return Style: File Sharing
General Constructs: The original PC networks were based on file sharing architectures, where the server downloads files from the shared location to the desktop environment. The requested user job is then run (including logic and data) in the desktop environment. Advantages: File sharing architectures work if shared usage is low, update contention is low, and the volume of data to be transferred is low. Disadvantages: In the 1990s, PC LAN (local area network) computing changed because the capacity of the file sharing was strained as the number of online user grew (it can only satisfy about 12 users simultaneously) and graphical user interfaces (GUIs) became popular (making mainframe and terminal displays appear out of date). Addendum: PCs are now being used in client/server architectures. Fall 2002 CS-545-Fall-2002

Suggested File Sharing Architecture
Application Application (n) Buffer : Buffer Data Control Buffer : Buffer : Main frame File File (n) Fall 2002 CS-545-Fall-2002

Data Abstraction & OO Architecture
Barber, K.S.; Graser, T.J. Tool support for systematic class identification in object-oriented software architectures, Technology of Object-Oriented Languages and Systems, TOOLS-Pacific Proceedings. 37th International Conference on , 2000, Page(s): 82 –93 Taylor, P. Designing persistent object-oriented software architectures, Technology of Object-Oriented Languages, TOOLS 28. Proceedings , 1998, Page(s): 14 –26 Bosch, J. Specifying frameworks and design patterns as architectural fragments, Technology of Object-Oriented Languages, TOOLS 27. Proceedings, 1998, Page(s): General Constructs: Data representations and their associated operations encapsulated in an abstract data type. The components are the objects and connectors operate through procedure calls (methods). Objects maintain the integrity of a resource and the representation is hidden from others. Advantages: Server is able to change an implementation without affecting the client. Grouping of methods with objects allows for more modular design and therefore decomposes the problems into a series of collections of interacting agents. Disadvantages: For one object to interact with another, the client object must know how to interact with the server object and therefore must know the identity of the server. If the server changes its interface ALL interacting clients must also change. Services declared as PUBLIC and IMPORTED into the CLIENT Also need to consider side affects, A uses B , B uses C and we mod C Fall 2002 CS-545-Fall-2002

Hierarchical Layered Architecture Styles
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, Layered Systems General Constructs A layered system is organized hierarchically with each layer providing service to the layer above it and serving as a client to the layer below. In some systems inner layers are hidden from all except the adjacent outer layer. Connectors are defined by the protocols that determine how layers will interact. Constraints include limiting interactions to adjacent layers. The best known example of this style appears in layered communication protocols OSI-ISO (Open Systems Interconnection - International Standards Organization) communication system. Lower levels describe hardware connections and higher levels describe application. GUI Application Layer DBMS OS Layer Fall 2002 CS-545-Fall-2002

Issues: No one agrees exactly on what a 'layer' is. For example, some layering schemes have very little relationship to the runtime. Others confuse layers with a 'tiered' runtime architecture where the various layers are not only split by build-time packaging, but by running in different processes and possibly different nodes at run time. Clearly separate the idea of 'tiers' from ‘layers'. A tier is a structure for runtime component interaction that implies nothing about the construction of the build time. For example, a 3 tier system may be composed of a web browser, web server/asp pages, and database. Note that each tier runs in a different process and possibly many different system nodes. Fall 2002 CS-545-Fall-2002

Layers is a pattern for 'application architectures'. Layers are normally thought of as a build-time structuring technique for building an application or service that will execute in a single process. There are many variations on the layers pattern. Four-layer architecture (analysis) Layered and sectioned architecture ( Layered architecture Layers (from POSA1) Patterns for generating a layered architecture Relational database access layer ( Secure access layer (analysis) GUI Application Layer DBMS OS Layer Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, Layered Systems Advantages: Layered systems support designs based on increasing levels of abstraction. Complex problems may be partitioned into a series of steps. Enhancement is supported through limiting the number of other layers with which communication occurs. Disadvantages: Disadvantages include the difficulty in structuring some systems into a layers. Performance considerations may not be well served by layered systems especially when high level functions require close coupling to low level implementations. It may be difficult to find the right level of abstraction especially if existing systems cross several layers. Fall 2002 CS-545-Fall-2002

Communicating Processes
Each component has it's own thread of execution. The Provider/Observer Role Pattern Push and Pull Interaction Patterns Opaque Interaction Patterns Synchronous Opaque Interaction Patterns Asynchronous Opaque Interaction Patterns Monitorable Interaction Patterns Pull-Monitorable Interaction Patterns Push-Monitorable Interaction Patterns Abortable Interaction Patterns Abortable Async Opaque Interaction Patterns Abortable Pull-Monitorable Interaction Patterns Abortable Push-Monitorable Interactions Patterns Handshaking Patterns Combining Patterns The components are the objects and connectors operate through message passing. Components are often in separate process spaces Object 1 Object 2 Fall 2002 CS-545-Fall-2002

Independent Components:Event Based Architecture Styles
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996. Event-Based Implicit Invocation (Look at Jini) General Constructs: A component announces (broadcasts) one or more events. System Components register interest in an event by associating a procedure with it. The system invokes all events which have registered with it. Event announcement ``implicitly'' causes the invocation of procedures in other models. This style originates in constraint satisfaction (Planning), daemons, and packet-switched networks. Used in Planning Domains Architectural components are modules whose interface provides both a collection of procedures and a set of events. Procedures may be called normally or be registered with events in the system. Implicit invocation systems are used in: programming environments to integrate tools database management systems to ensure consistency constraints user interfaces to separate data from representation Fall 2002 CS-545-Fall-2002

Event Based Architecture Styles
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996. Event-Based Implicit Invocation Advantages: Allows any component to register for events Eases system evolution by allowing components to be replaced without affecting the interfaces of other components in the system. Disadvantages: Components relinquish control over the computation performed by the system. A component cannot assume that other components will respond to its requests A component does not know in which order events will be processed. In systems with a shared repository of data the performance and accuracy of the resource manager can become critical. Reasoning about correctness can be difficult because the meaning of a procedure that announces events will depend on the context in which it was invoked. Fall 2002 CS-545-Fall-2002

Event Based Architecture Styles
Using Events to build Distributed Systems (Open Lit) The first paper predates (1996) the JINI Architecture (1999) and proposes three services Event Specification (by services) Event Classification Event Registration (by clients at Services) Event Templates Event Binding to identify UNIQUE service “that printer” ,not “this printer” Event Timestamps Event Notification (by network) Lookup Service (n) Lookup Service (1) Service Registration Event Registration Event Notification Service Provider Client (n) Fall 2002 Communication with Service CS-545-Fall-2002

Interpreter Architecture Styles
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996. Interpreters Interpreters create a virtual machine in software. There are generally four components to an interpreter, the program being interpreted, the state of the program, the state of the interpreter, and the interpreter itself. This style is used to narrow the gap between the computing engine in hardware and the semantics of a program. Programming languages that provide a virtual language machine include: Pascal, Java, BASIC. Fall 2002 CS-545-Fall-2002

Interpreter Example: Planning
Developed my own Frame based language in C++ I wanted the ability to define and operate on domain elements at run-time. I also wanted to create a structure (Constraint) whose attribute values were maintained in other structures, thereby effectively creating an instance of a class that maps over the instances of other data types. (defclass Location :Float longitude :Float latitude :Float altitude) (defclass City :readOnly :noCopy :derivedFrom Location :String cityName) (defclass PathSegment :String route :City from :City to) (defclass Route :String routeName :Array segments) (defclass aTractor :bindsTo (Tractor tractor Tractor ctr)) (defclass aCustomer :bindsTo (Customer customer)) (defclass simpleOption :bindsTo (aDriver driver aDriver hoursToDate aDriver hrsThisMonth aTractor tractor aTractor ctr aCustomer customer) :Float pw) (defclass PlanNode :Driver driver :Tractor tractor :Customer customer :PlanNode parent :Float pw :Float fw) System reads this input and other data items at Run –Time and based on the constraints assigns the best combination of Driver to Truck to Customer to Route. Text Processor on-line interpreter, Compiler Data Store GUI Fall 2002 CS-545-Fall-2002

Rule Based Style Working Memory Rule base Fact memory Knowledge base
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Lee Brownston, et al. Programming Expert Systems in OPS5: An Introduction to Rule-Based Programming, Addison Wesley, Jan. 1986 Working Memory Rule base Fact memory Knowledge base Interpreter Rule & Data Element Selection Selected Rule Selected Data Inputs Outputs New Facts New Active Rules Trigger Data Data & Updates Active Rules & Facts Select and and Execute Rules based on the Current State and Derived Facts What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? The Example in the book shows how the Architecture Elements For a Rule-based Systems are realized using a number of Architecture Types. Fall 2002 CS-545-Fall-2002

Rule-Based Style Unfinished Action Inactive Rules Active Facts
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Lee Brownston, et al. Programming Expert Systems in OPS5: An Introduction to Rule-Based Programming, Addison Wesley, Jan. 1986 Inactive Rules Active Facts Why the Distinction Between Inactive & Active? What Architectural Style would we have if this data was maintained remotely? Activation/ Deactivation Active Rules & Facts Rule & Fact Compiler Regardless of whether or not you are actually building a rule based system You can use this general approach to build A scheduler to identify the Tasks required to be scheduled When investigating Aberrant or interesting conditions in the environment Execution Stack Control Procedures Interpreter Scheduler Selected Actions Next Action Unfinished Action Outputs Incomplete Trigger Data Matching Rule/Data Pairs Data Flow Network for Partially Evaluated Rule Sets Delete Completed Activations Candidate Rule/Data Activations Rule & Fact Compiler Prioritized Activations Agenda Fall 2002 Meta Control Rules CS-545-Fall-2002

Data Repository Architecture Styles
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996. Repositories General Constructs: Repository style systems have two distinct components: A central data structure which represents the current state, and A collection of independent components which operate on the data-store. Two methods of control exist for these systems. If input transactions select the processes to execute then a traditional database can be used as a repository. (Client-Server) If the state of the data-store is the main trigger for selecting processes then the repository can be a blackboard. Fall 2002 CS-545-Fall-2002

Client-Server: Continued
Client/server architecture. C/S architecture emerged due to file sharing architectures limitations This approach introduced a database server to replace the file server. Using a relational database management system (DBMS), user queries could be answered directly. The C/S architecture reduced network traffic by providing a query response rather than total file transfer. C/S improves multi-user updating through a GUI front end to a shared database. C/S architectures, use (RPCs) or standard query language (SQL) statements to communicate between the client and server. Fall 2002 CS-545-Fall-2002

Repository: Client-Server Cont.
Edelstein, Herb. "Unraveling Client/Server Architecture." DBMS 7, 5 (May 1994): 34(7). The term client/server was first used in the 1980s in reference to personal computers (PCs) on a network. The client/server model started gaining acceptance in the late 1980s. The client/server software architecture is a versatile, message-based and modular infrastructure that is intended to improve usability, flexibility, interoperability, and scalability as compared to centralized, mainframe, time sharing computing A client is defined as a requester of services and a server is defined as the provider of services. A single machine can be both a client and a server depending on the software configuration. Fall 2002 CS-545-Fall-2002

Client Server Architecture Types
Two Tiered Three components distributed in two tiers: User System Interface Processing Management process development, process enactment, process monitoring, and process resource services) Database Management (such as data and file services) Three Tiered Three tier with transaction processing monitor technology Three tier with message server. Three tier with an application server. Three tier with an ORB architecture. Distributed/collaborative enterprise architecture. Fall 2002 CS-545-Fall-2002

Two Tiered Client-Server Architectures
General The user system interface is usually located in the user's desktop environment in two tier client/server architectures. The database management services are usually in a server that is a more powerful machine that services many clients. Processing management is split between the user system interface environment and the database management server environment. The database management server provides stored procedures and triggers. Software vendors provide tools to simplify development of applications for the two tier client/server architecture. GUI DBMS Engine Data Store Fall 2002 CS-545-Fall-2002

Two Tiered Client-Server Architectures
Advantages: Good solution for distributed computing when work groups are defined as a dozen to 100 people interacting on a LAN simultaneously. Disadvantages: Server performance deteriorates as number of clients increases as a result of maintaining a connection with each client (even when no work is being done) Vendor proprietary database implementations restricts flexibility and choice of DBMS for applications. Current implementations provide limited flexibility in repartitioning program functionality from one server to another without manually regenerating procedural code. Fall 2002 CS-545-Fall-2002

Two Tiered VS Three Tiered C/S
Thin Clients Middle Tier Fat Clients DBMS Engine DBMS Engine Data Store Data Store Fall 2002 CS-545-Fall-2002

Three Tiered Client-Server Architectures
Proposed to overcome two tier architecture limitations A middle tier added between the UI client environment and the DBMS. There are a variety of ways of implementing this middle tier, such as transaction processing monitors, message servers, or application servers. Middle tier performs queuing, application execution, and DB staging. For example, if the middle tier provides queuing, the client can deliver its request to the middle layer and disengage because the middle tier will access the data and return the answer to the client. Middle layer adds scheduling and prioritization for work in progress. The three tier client/server architecture improves performance for groups with a large number of users (in the thousands) and improves flexibility when compared to the two tier approach. Flexibility in partitioning can be a simple as "dragging and dropping" application code modules onto different computers in some three tier architectures. Difficult Development environments Fall 2002 CS-545-Fall-2002

Three tier with transaction processing monitor technology
Middle layer consisting of Transaction Processing (TP) monitor technology. TP is a type of message queuing, transaction scheduling, and prioritization service where the client connects to the TP monitor (middle tier) instead of the database server. The transaction is accepted by the monitor, which queues it and then takes responsibility for managing it to completion, thus freeing up the client. TP monitor technology also provides the ability to update multiple different DBMSs in a single transaction connectivity to a variety of data sources including flat files, non-relational DBMS, and the mainframe the ability to attach priorities to transactions robust security. Fall 2002 CS-545-Fall-2002

Three tier with transaction processing monitor technology
When the capability is provided by third party middleware vendors it is referred to as "TP Heavy" because it can service thousands of users. When the capability is embedded in the DBMS (and could be considered a two tier architecture), it is referred to as "TP Lite" because experience has shown performance degradation when over 100 clients are connected. A three tier client/server architecture with TP monitor technology is a considerably more scalable environment than with a two tier architecture with direct client to server connection. TP Heavy has been reported as one of the most effective solutions for systems with thousands of users A limitation to TP monitor technology is that the implementation code is usually written in a lower level language (such as COBOL), and not yet widely available in the popular visual toolsets. Fall 2002 CS-545-Fall-2002

Three tier with message server
(See Java Message System) Messaging is a way to implement three tier architectures. Messages are prioritized and processed asynchronously. Messages consist of headers that contain priority information, and the address and identification number. The message server connects to the relational DBMS and other data sources. The difference between TP monitor technology and message server is that: the message server architecture focuses on intelligent messages, TP Monitor environment has the intelligence in the monitor, and treats transactions as dumb data packets. Messaging systems are good solutions for wireless infrastructures. Fall 2002 CS-545-Fall-2002

Three tier with an application server (TTAS).
TTAS allocates the main body of an application to run on a shared host rather than in the user system interface client environment. The application server does not drive the GUIs; rather it shares business logic, computations, and a data retrieval engine. Less software on the client -> less security to worry about Applications are more scalable, and support and installation costs are less on a single server than maintaining each on a desktop client. The application server design should be used when security, scalability, and cost are major considerations. Fall 2002 CS-545-Fall-2002

Three tier with an ORB architecture
Industry is working on developing standards to improve interoperability. Client/server systems that support distributed objects holds great promise, as these technologies support interoperability across languages and platforms, as well as enhancing maintainability and adaptability of the system. There are currently two prominent distributed object technolgoies: Common Object Request Broker Architecture (CORBA) COM/DCOM (see Component Object Model (COM), DCOM, and Related Capabilities). Industry is working on standards to improve interoperability between CORBA and COM/DCOM. The Object Management Group (OMG) has developed a mapping between CORBA and COM/DCOM that is supported by several products. Fall 2002 CS-545-Fall-2002

Distributed/collaborative enterprise architecture
This architecture emerged in 1993 This architecture is based on Object Request Broker (ORB) technology, but goes further than the Common Object Request Broker Architecture (CORBA) by using shared, reusable business models (not just objects) on an enterprise-wide scale. Standardized business object models and distributed object computing are combined to give an organization flexibility to improve effectiveness organizationally, operationally, and technologically. An enterprise is defined here as a system comprised of multiple business systems or subsystems. This architecture is limited by a lack of commercially-available object orientation analysis and design method tools that focus on applications. Fall 2002 CS-545-Fall-2002

Messaging communication (MC) hides the following from business applications: the implementation details of networking and protocols the location and distribution of data, process, and hosts production environment services such as transaction management, security, messaging reliability, and persistent storage MC links the organization and connects it to computing and information resources via the organization's LAN or WAN. MC component forms an enterprise-wide standard mechanism for accessing computing and information resources. MC becomes a standard interface to heterogeneous system components. Fall 2002 CS-545-Fall-2002

Distributed/collaborative enterprise architecture (DCAE)
DCAE allows a business to analyze its internal processes in ways that are defined by changing business opportunities instead of by preconceived systems design (such as monolithic data processing applications). In DCAE an object model represents all aspects of the business what is known, what the business does the constraints, and their interactions and the relationships. In this architectural design, an object model A business model is used to integrate and migrate parts of legacy systems to meet the new business profile. Work flow manager Fall 2002 CS-545-Fall-2002

DCAE builds new business applications on top of distributed business models and distributed computing technology. Applications are built from standard interfaces with "plug and play" components. The infrastructure core is an off-the-shelf, standards-based, distributed object computing, messaging communication component such as an Object Request Broker (ORB) that meets Common Object Request Broker Architecture (CORBA) standards. Fall 2002 CS-545-Fall-2002

Hypertext Style Three hypertext architectures variants:
Reflections on "Seven Issues": Hypertext in the Era of the Web Frank G. Halasz Charles J. Kacmar , John J. Leggett, PROXHY: a process-oriented extensible hypertext architecture . ACM Transactions on Information Systems (TOIS) October 1991, Volume 9 Issue 4 Wolfe, M. A hypertext architecture for distributed decision-making across divergent cognitive topologies, Systems, Man, and Cybernetics, 'Decision Aiding for Complex Systems,Conference Proceedings., 1991 IEEE International Conference on , 1991, Page(s): vol.3 Antonina Dattolo and Vincenzo Loia Collaborative version control in an agent-based hypertext environment, Information Systems, Volume, 21, Issue 2, April 1996, Pages Three hypertext architectures variants: Linear, hierarchical, and relational/hierarchical Reference Models The HAM or Hypertext Abstract Machine, as described by Campbell and Goodman. The Trellis model, a reference model by Stotts and Furuta. The Dexter model, a reference model by Halasz and Schwartz, written in the specification language Z. The Formal Model by B. Lange, a reference model written in the specification language VDM. The Tower Model, a more general object-oriented model by De Bra, Houben and Kornatzky. Fall 2002 CS-545-Fall-2002

HAM Reference Model : Hypertext Style
HAM is a transaction-based server for a hypertext storage system. The server is designed to handle multiple users in a networked environment. The storage system consists of a collection of contexts, nodes, links, and attributes that make up a hypertext graph.” HAM sits in between the file system and the user interface. Campbell and Goodman envisioned the graphical representation given below: HAM is a lower level machine, tied closely to the storage (file) system, while having a looser connection to the applications and user interfaces. HAM is only part of this architecture and not the whole system. User Interface Application Tools Hypertext Abstract Model (HAM) Fall 2002 Host File System CS-545-Fall-2002

Trellis Reference Model : Hypertext Style
Richard Furuta and P. David Stotts developed a hypertext system, based on Petri Nets, called the Trellis System. From the Trellis model they deduced a meta-model, which they called the Trellis hypertext reference model, abbreviated as r-model. The r-model is separated into five logical levels, as shown in the figure below. Within each level one finds one or more representations of part or all of the hypertext. In contrast to the HAM (and the other reference models) the levels represent levels of abstraction, not components of the system. The levels may be grouped into three categories: abstract, concrete and visible. Abstract Component Level Abstract Hypertext Level Concrete Context Level Concrete Hypertext Level Visible Hypertext Level Fall 2002 CS-545-Fall-2002

Dexter Reference Model : Hypertext Style
The goal of the model is to provide a principled basis for comparing systems as well as for developing interchange and interoperability standards. The focus of the Dexter model is on the storage layer, which models the basic node/link network structure that is the essence of hypertext. The storage layer describes a "database" that is composed of a hierarchy of data-containing "components" (normally called "nodes") which are interconnected by relational "links". The storage layer focuses on the mechanisms by which the components and links are "glued together" to form hypertext networks. The components are treated in this layer as generic containers of data. The model is divided in three layers, with glue in between, as shown in the figure below: Runtime layer Storage layer Within Component layer Fall 2002 CS-545-Fall-2002

A Formal Model of Hypertext
The main motivation for the definition of this formal model is the lack of means to interchange and communicate between existing hypertext systems. Hypertext research is driven mostly by user interface and implementation considerations. Very few attempts have been made to provide a formal basis for the research field. David Lange chose the Vienna Development Method (VDM) [BJ82,Jones-86] because it supports the top-down development of software systems specified in a notion suitable for formal verification. Like the Dexter model Lange's model emphasizes the data structure of hyper-documents. Therefore Lange calls it a data-model of hypertext. This data-model defines nodes, links, network structures, etc. The model goes further than the Dexter model in looking inside the nodes of a hyper-document to find slots,buttons and fields. The basic data-model is then extended with features to become an object-oriented model for hypertext. Fall 2002 CS-545-Fall-2002

Tower Reference Model: Hypertext Style
Background: Trellis model describes the "abstract component level" in a way that makes it sound like there would be no need for containers containing containers (or in more common terminology: composites containing composites). The Dexter model allows undirected (and bidirectional) links, but only between two nodes (called components). Links between more than two nodes are allowed but must be directed (they must have at least one "destination" or "TO" endpoint). Another restriction in the Dexter model is that, while the model allows composites within composites, the hierarchy of composites must be acyclic, thus forbidding so called "Escher effects". The Tower model contains basic structural elements, nodes, links and anchors, tower objects and city objects. The tower objects are used to model different descriptions of an object, somewhat like the layers in the Dexter model. Type, storage structure, presentation, etc. are all levels of the tower object. Cities represent sets of views onto (tower) objects. The model allows every kind of object to be a virtual object (i.e. the result of a function or algorithm). Operators for defining virtual structures are Apply-to-All, Filter, Enumeration and Abstraction (or grouping). Fall 2002 CS-545-Fall-2002

Blackboard Style BB Metaphor:
BB Metaphor: A group of specialists work cooperatively to solve a problem, using a blackboard as the workplace for developing the solution. The problem and initial data are written on the blackboard. The specialists watch the blackboard, and when a specialist finds sufficient information on the board to make a contribution, he records his contribution on the blackboard. Fall 2002 CS-545-Fall-2002

BB Architecture Overview
Penny Nii, Blackboard Systems at the Architecture Level, Expert Systems with Applications, Vol 7, pp43-54, 1994 Blackboard Layers KS KS consist of a Condition (Trigger) Section and the Body Essentially what happens is: An event has occurred that has resulted in the BB state changing. If am registered to Accept events on that level of the BB and if the event satisfies my curiosity and any constraints (Trigger conditions), then I will apply the KS body to evaluate the Event and perform the requested operation KS KS KS KS Controller Control Data Fall 2002 CS-545-Fall-2002

Repository Architecture Styles: Blackboard
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996. P. Nii, "Blackboard Systems: The Blackboard Model of Problem Solving and the Evolution of Blackboard Architectures", AI Magazine, Summer 1986, pp. 38 AI Expert 6(9): 40-47, September 1991 A blackboard model usually has three components: General Constructs The knowledge source: independent pieces of application specific knowledge. Interaction between knowledge sources takes place only through the blackboard. The blackboard data structure: state data, organized into an application-dependent hierarchy. Knowledge sources make changes to the blackboard that lead incrementally to a solution to the problem. Control: driven by the state of the blackboard. Knowledge sources respond opportunistically when changes in the blackboard make them applicable. General Operation Invocation of a knowledge source is dependent upon the state of the blackboard. Control can be implemented in the knowledge source, the blackboard, externally, or a combination of these. Blackboard systems have traditionally been used for applications requiring requiring complex interpretations of signal processing. Programming environments can be considered as having a shared repository of programs and program fragments. Fall 2002 CS-545-Fall-2002

Independence of Expertise Each knowledge source is a specialist at solving certain aspects of the problem. No KS requires other KSs in making its contribution. Once it finds the information it needs on the blackboard, it can proceed without any assistance from other KSs. KSs can be added, removed, and changed without affecting other KSs. (Actually A Primary key to evolving a product’s functionality and architecture) Diversity in Problem Solving Techniques Internal KS representation and inference machinery is hidden from view. Flexible Representation of Blackboard Information The blackboard model does not place any prior restrictions on what information can be placed on the blackboard. One blackboard application might require consistency, another might allow incompatible alternatives. Common Interaction Language There must be a common understanding of the representation of the information on the blackboard, understood by all KSs. There's a tradeoff between representational expressiveness of a specialized representation shared by only a few KSs and a representation understood by all. Fall 2002 CS-545-Fall-2002

Positioning Metrics When the blackboard gets full, we must still have a way for the KSs to immediately see the information important to them. Often we have multiple or subdivided blackboards, or information is sorted alphabetically or by reference. Efficient retrieval is also important. Event Based Activation KSs are triggered in response to events (they don't actively watch the blackboard). The board knows what kind of event each KS is looking for, and considers it for activation whenever that kind of event occurs. Need for Control A control component separate from the individual KSs is responsible for managing the course of problem solving. The control component doesn't share the specialties of the KS's, but looks at each KSs evaluation of its own contribution to decide which one gets to go. Fall 2002 CS-545-Fall-2002

The Blackboard Model of Problem Solving Incremental Solution Generation Blackboard systems are effective when there are many steps towards the solution and many potential paths involving these steps. It works opportunistically, exploring the paths most effective in solving the particular problem and can outperform a solver that uses a predetermined approach Knowledge Sources Each KS is separate and independent of all other KSs. Each KS does not need to know of their expertise or even existence. KSs must understand the state of the problem-solving process and the representation of relevant information on the blackboard. Each KS knows its triggering conditions -- the conditions under which it can contribute. KSs are not active, but KS activations -- combinations of KS knowledge and a specific triggering condition -- are the active entities competing for executing instances. KSs are static repositories of knowledge. Ks activations are the active processes. Fall 2002 CS-545-Fall-2002

The Blackboard The blackboard is a global structure available to all KSs. It is a community memory of raw input data, partial solutions, alternatives, final solutions, and control information. It is a communication medium and buffer. It is a KS trigger mechanism. Control Component An explicit control mechanism directs the problem solving process by allowing KSs to respond opportunistically to changes on the blackboard. On the basis of the state of the blackboard and the set of triggered KSs, the control mechanism chooses a course of action. At each step to the solution, the system can execute any triggered KS, or choose a different focus of attention, on the basis of the state of the solution. Fall 2002 CS-545-Fall-2002

Uses of the Blackboard Style
It has been used for sensory interpretation, design and layout, process control, planning and scheduling, computer vision, case based reasoning, knowledge based simulation, knowledge based instruction, command and control, symbolic learning, and data fusion.. Why Use the Blackboard Problem Solving Approach When many diverse, specialized knowledge representations are needed. When an integration framework for heterogeneous problem solving representations and expertise is needed When the development of an application involves numerous developers. When uncertain knowledge or limited data inhibits absolute determination of a solution, the incremental approach of the blackboard system will still allow progress to be made. When multilevel reasoning or flexible, dynamic control of problem-solving activities is required in an application. Fall 2002 CS-545-Fall-2002

A task Allocation Model For Distributed Computing Systems, IEEE Transactions on Computers, Vol. C-31, No , January 1982 Optimal File Allocation in a Multiple Computer System, IEEE Transactions on Computers, Vol. C-18, No. 10, , Oct 1969 Load Balancing in Distributed Systems, IEEE Transactions on Software Engineering, Vol. SE-8, No , July 1982 Load Redistribution under Failure in Distributed Systems, IEEE transactions on Computers, Vol. C-32, NO.9, September 1983 Advantages: Provides an explicit forum for the discussion of data access, distribution, synchronization Provides an explicit forum for the discussion of Task Allocation Policies Provides an explicit for the discussion of control and task sequencing and prioritization Provides an explicit forum for the discussion of Load Redistribution. Disadvantages: Blackboard systems to not seem to scale down to simple problems, but are only worth using for complex applications (Disagree.. The BB Paradigm is usually the best starting point as it forces us to address the constraints and conditions unique to each piece of the puzzle at first independently, then across the integrated data, processing, and control issues. Experience has shown that we can easily morph the BB architecture to support any type of processing and throughput required, even real-time control of signal processing and tight feed-back control loops.) Fall 2002 CS-545-Fall-2002

Conclusion: I have found architecture style to be able to subsume the styles others to a great extent. Even for Real-Time Video processing !! I usually start with this view and then relax the architecture to accommodate the functional and performance requirements with attributes of the other styles Fall 2002 CS-545-Fall-2002

Simple BB Architecture Example
Design a system that understands how to close the cargo loading door on a warehouse that has an articulated loading ramp with fork-lift tines. The aft end of the Loading Ramp has Rollers that will pop out of the floor to pick up the cargo and rotate the cargo so that it may be moved into the warehouse. The fork-lift tines allow the ramp to go under the cargo on pallets on the trucks, pick the cargo off the truck and load the cargo onto the aft ramp. Both forward and aft sections of the Loading Ramp have moveable and retractable belts and rails to move and guide the cargo in to the warehouse. There are floor sensors that detect the location and orientation of cargo pallets on the ramp sections. : Fall 2002 CS-545-Fall-2002

Simple BB Architecture Example
Potential Knowledge Sources KS 1 Close the Doors KS 2 Retract the Tines KS 3 Extend the Tines KS 4 Operate the Tines KS 5 Level the Articulated Ramp KS 6 Align the Complete Ramp KS 7 Raise the Drive Belts KS 8 Lower the Drive Belts KS 9 Raise the Guide Rails KS 10 Lower the Guide Rails KS 11 Accept Discrete Inputs KS 12 Apply Discrete Outputs KS 13 Accept Analog Inputs KS 14 Power the Drive Belts KS 15 Control Guide Pins : (Actual system had ~65 KS) KS System Mode Controller Note the Independence of each KS Fall 2002 CS-545-Fall-2002

Simple BB Example C++ Code Snippet Cont.
void execTaskList(taskInstance tl[]) { // Simple Task Execution int index = 0; // taskInstance *ti; // TCB *tcb; // while(tl[index].taskNumber) // Go down the task list { ti = &(tl[index]); // get task info tcb = &allTasks[ti->taskNumber]; // grab the task control block if(!tcb-> currentFrameTime) // do I execute? tcb->currentFrameTime = tcb->timer; tcb->taskData = ti->taskData; // so we process task unique data tcb->execTask(); // execute the task } // if else { tcb->currentFrameTime--; // next FrameTime } // else index++; // get the next task } // while } // execTaskList taskInstance initTaskList[]= { {tskWindows,0}, {tskInitialize,0}, {tskDisplay,0}, {tskDisplayDebug,0}, {tskNoTask,0} }; taskInstance suTaskList[]= {tskInputs,0}, {tskErrorHandle,0}, {tskPowerOn,0}, : {tskOutputs,0}, : // Situation Specific Task Lists void taskControl(int,void *) // Situation Driven Task Control { //establish the agenda and execute the tasks if(rqst[tskInitialize]) execTaskList(initTaskList); else if(rqst[tskPowerOn]) execTaskList(suTaskList); else if(MODES[XXX]) execTaskList(xxxTaskList); : else if(MODES[RUNALL]) execTaskList(allTasksList); }; Fall 2002 CS-545-Fall-2002

Simple BB Example C++ Code Snippet
class TCB; // Task Control Block typedef int (*pfunc)(TCB *); class TCB // task control block { public: int type; // TASK control block char *name; // name int *rqst; // Have I been Requested ? int *sema; // Am I Busy ? int priority; // my Priority, 0 = HIGHEST int currentFrameTime; // can I run int (**states)(TCB *); // the states int index; // controlling functions pfunc func; // function to execute pfunc reset; // reset TCB states and data void *taskData; // local TCB instance data void execTask(); void execReset(); void init(); int timeout(); }; TCB allTasks[]={ {TASK,"No Task",NULL,NULL,TASK_TIMER,0, NULL ,0,NULL,NULL,NULL}, {TASK,"Windows Handler" ,&rqst[tskWindows], &sema[tskWindows],TASK_TIMER,0, windowsControlStates,0,NULL ,NULL,NULL}, {TASK,"Initialize", &rqst[tskInitialize], &sema[tskInitialize],TASK_TIMER,0, initVarStates,0,NULL ,NULL,NULL}, {TASK,"Inputs" , &rqst[tskInputs], &sema[tskInputs],TASK_TIMER,0, inputControlStates,0,NULL ,NULL,NULL}, {TASK,"ErrorHandle" , &rqst[tskErrorHandle], &sema[tskErrorHandle],TASK_TIMER,0 ,errorControlStates ,0,NULL ,NULL,NULL}, {TASK,"PowerOnTest" , &rqst[tskPowerOn] , &sema[tskPowerOn],TASK_TIMER,0, powerOnStates ,0,NULL ,NULL,NULL}, : } From what you know, classify my BB approach.. What do I need to change in order to address a homogeneous, vs heterogeneous realization approach? What about Quality Attributes ? Fall 2002 CS-545-Fall-2002

A View of Distributed Architecture Styles
Y. Morisawa et. al Architectural Styles for distributed processing systems and practical selection method, Information and Software Technology 44 (2002) ISO/IEC Information Technology – Open Systems Interconnection, Distributed Transaction Processing Part 1, OSI TP Model, 1992 Distributed Processing is classified into nine styles from the viewpoint of the location of data and the processing type between client and server. Data is classified as Centralized or Distributed Processing as either synchronous or asynchronous Transaction Type Atomic, Consistency, Isolation, Durability Query Type A reply from the server is synchronized with a request from the client For Asynchronous processing: A Notification type indicates that the server process is not synchronized with a client request Fall 2002 CS-545-Fall-2002

A View of Distributed Architecture Styles Cont:
Y. Morisawa et. al Architectural Styles for distributed processing systems and practical selection method Information and Software Technology 44 (2002) ISO/IEC Information Technology – Open Systems Interconnection, Distributed Transaction Processing Part 1, OSI TP Model, 1992 Transaction Types Centralized: Single DB, Single Server Distributed: Multiple DBs on Multiple Servers with Synchronous processing between Servers. Asynchronous: Multiple DB on Multiple Servers with Asynchronous processing between Servers. Query Types Centralized: Query and Reply Processing Distributed: Simultaneous access to to multiple data bases and support query intensive immediate processing Asynchronous: Suited to asynchronous sharing of data (partial DB downloads) Notification Types Centralized: Automation of simple workflow, shipping memos, etc. Distributed: Distributed transaction and data processing from mobile clients Asynchronous: Supports loose integration of independent multiple applications or systems. Fall 2002 CS-545-Fall-2002

Process Interaction in Distributed Programs Cont.
Gregory R. Adams. Paradigms for Process Interaction in Distributed Programs. ACM Computing Surveys, 23(1):49-90, March 1991. Asynchronous Message Passing Channel has unlimited capacity Send & receive do not block Different communication channels are used for different kinds of messages. Synchronous Message Passing Channel has fixed capacity Sending process waits for receiving process ready to receive, hence synchronized Buffered Message Passing Send is delayed only when the channel is full Generative Communication Send & Receive processes share a single communication channel called tuple space. Associative naming distinguishes message types in the tuple space Remote Procedure Call & Rendezvous Calling process delays until the request is serviced and results returned. Fall 2002 CS-545-Fall-2002

PIPD: Requests & Replies between clients & Servers
Server vs. monitors A server is active, whereas a monitor is passive Clients communicate with a server by sending and receiving messages, whereas clients call monitor procedures. A monitor is a synchronization mechanism that encapsulates permanent variables that record the state of some resource and exports a set of procedures that are called to access the resource. The procedures execute with mutual exclusion; they use condition variables for internal synchronization. Fall 2002 CS-545-Fall-2002

A View of Distributed Processing Styles Cont.
Y. Morisawa et. al Architectural Styles for distributed processing systems and practical selection method Information and Software Technology 44 (2002) ISO/IEC Information Technology – Open Systems Interconnection, Distributed Transaction Processing Part 1, OSI TP Model, 1992 Architectural Styles for Transaction Types Centralized vs. Distributed vs. Asynchronous Transaction Messages Architectural Styles for Query Types Centralized vs. Distributed vs. Asynchronous Query Messages Architectural Styles for Notification Types Centralized vs. Distributed vs. Asynchronous Notification Messages Centralized Distributed Synchronous Asynchronous Synchronous Processing Transaction Type (ACID) Centralized Transactions Distributed Transactions Asynchronous Transactions Query Type Query Distributed Query Asynchronous Query Asynchronous Processing Notification Type Centralized Notification Distributed Notification Asynchronous Notification Location of Data Processing Types between C/S Processing Type Between Servers Msg. Type Fall 2002 CS-545-Fall-2002

Process Interaction in Distributed Programs (PIDP)
Gregory R. Adams. Paradigms for Process Interaction in Distributed Programs. ACM Computing Surveys, 23(1):49-90, March 1991. Cooperating Message Passing Processes: One way Data Flow Through a Network of Filters Request & Replies between clients & servers Heartbeat Interaction between neighboring processes Probes & Echoes in Graphs Broadcasts between processes in complete graphs Token passing along edges in a graph Coordination between centralized server processes Replicated workers sharing a bag of tasks Fall 2002 CS-545-Fall-2002

Distributed Processes Architecture Styles
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996. Y. Morisawa et. al Architectural Styles for distributed processing systems and practical selection method Other familiar architectures Distributed processes – have developed a number of common organizations for multi-process systems. Some are defined by their topology (e.g. ring, star) Others are characterized in terms of the kind of inter-process protocols that are used (e.g. heartbeat algorithms). A common form of distributed system architecture is client-server. A server provides services to the clients. The server does not usually know the number or identity of the clients which will access it. The clients know the identity of the server (or can find it out through another name-server) and access it through a remote procedure call. Main program/subroutine organizations: The primary organization of many systems mirrors the programming language in which the system is written. Domain Specific Software Architectures (DSSA) State-transition systems: A common organization for many reactive systems. Define in terms of a set of states and a set of named transitions Fall 2002 CS-545-Fall-2002

Process Control Architecture Styles
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996. Process Control Process Control Paradigms Usually associated with real-time control of physical processes. The system maintains specified properties of the output process near a reference value Open Loop Systems: If the process is completely defined, repeatable, and the process runs without surveillance Space Heater Closed Loop Systems: Output is used to control the inputs to maintain a monitored value Speed Control, etc. Feed back and Feed Forward controller. General Constructs: Computational Elements Data Elements Control Loop Paradigm Concerns We need to worry about the physical control laws (s-domain) versus the time sampled control laws (Z-Domain) and the introduction of poles and zeroes into the transfer function. Fall 2002 CS-545-Fall-2002

Heterogeneous Architecture Styles
Gregory R. Adams. Paradigms for Process Interaction in Distributed Programs. ACM Computing Surveys, 23(1):49-90, March 1991. Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996. Y. Morisawa et. al Architectural Styles for distributed processing systems and practical selection method Heterogeneous Architectures Most systems involve the combination of several styles. Components of a hierarchical system may have an internal structure developed using a different method. Connectors may also be decomposed into other systems (e.g. pipes can be implemented internally as FIFO queues). A single component may also use a mixture of architectural connectors. An example of this is Unix pipes-and-filter system in which the file system acts as the repository, receives control through initialization switches, and interacts with other components through pipes. Fall 2002 CS-545-Fall-2002

Week 6 Case Studies (Domain Specific Architectures)
CS-545 Week 6 Case Studies (Domain Specific Architectures)

Case Studies Key Word in Context
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Key Word in Context The System accepts a ordered set of lines, each line is an ordered set of words, each word 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 system outputs a listing of all circular shifts of all lines in alphabetical order. How does an architecture change wrt to changes in Processing Algorithm Data representation Data Flow Control Flow How are these changes evaluated wrt: System enhancements? Performance? Reuse? Other Quality Attributes ? What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Main Program with Shared Data
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Master Control Subroutine Calls Input Circular Shift Alphabetizes Output DMA Output Medium Input Medium Characters Index Alphabetized Index Disadvantages: Change in data storage format affects all modules Ease of Upgrade to different algorithms? Reusable in different domains? Advantages: Efficient Control Flow Mechanism Efficient Data Representation Efficient Data Flow between modules What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Abstract Data Types Master Control Subroutine Calls Input Output
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Master Control Subroutine Calls Input Output Input Medium Characters Set Char Char Word Setup Set Char Char Word Alpha Ith Output Medium Circular Shift Alphabetic Shifts Data is no longer shared by the modules Each module provides an interface that permits other modules to access data only by invoking procedures in its interface. Advantages: Both algorithms and data representations can be changed in each module without affecting the other modules. Better reuse as the modules make few assumptions about the others in which they interact. Disadvantages: Adding new functions requires the other modules to be modify existing modules or add new modules. What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Implicit Invocation Master Control Input Circular Shift Alphabetizer
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Master Control Input Circular Shift Alphabetizer Output Medium Subroutine Calls Lines Insert Delete I th Data Interface is more abstract: Accesses data as a list or set of lines Computations invoked implicitly as data is modified New lines causes events to the shift module, producing data shifts in a separate data store, which in turn causes an event to the alphabetizer to alphabetize the lines. Note that NEW modules can be added to the system and they register for the events of interest. Reuse is enhanced as modules only respond to registered events. Disadvantage: May be difficult to control the processing order and activation of the event driven modules. Data driven invocation tend to use more memory. One of the problems I have encountered with the blackboard, in that if you are not specific in the events and trigger activation conditions you get all kinds of computational activity happening when you least expect it or want it. What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Pipes & Filters Advantages: Disadvantages: Input Circular Shift
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Output Medium Input Circular Shift Alphabetizer Output Input Medium Advantages: Maintains the intuitive processing flow Each filter can function in isolation New functions easily added to the processing flow Filters are logically independent of one another Disadvantages: Impossible to modify the design for interaction Data design is inefficient as all data must be copied throughout the system. What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Suggested Comparisons
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Shared Data Abstract Data Type Implicit Invocation Pipe & Filter (The other styles) Algorithm Changes - + : Data Representation Changes Function Changes Performance Reuse Control Score +2 Quality attribute concerns at each level of the architecture will swing the vote further Fall 2002 CS-545-Fall-2002

Instrumentation Software
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Instrumentation Software An OO Model How does the data and model fit together which led to issues on partitioning and measuring. How does the user interact with it ? A Layered Model Nice at first thought, however the boundaries of abstraction enforced by the layers, conflicted with the needs for interaction between the wave form processing functions. A Pipe & Filter Model Corresponded well with the engineers understanding of signal processing and data flow between signal processing functions. What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Case Studies Filter (n) Couple Acquire To:X-Y Clip
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Instrumentation Software A Modified Pipe & Filter Added a control interface to the architecture to allow an external entity to set parameters of operation for the filters. This is especially true in signal processing domains where we have a flow of data through a series of algorithms at break-neck speeds and we want to conduct real-time performance enhancements and tuning. A Control interface addresses the ability to interact with the processing and tailor the processing dynamically. Decouples the signal processing software from changes in the control parameters. Further Specialization Introduced several kinds of pipes and filters to address different waveforms to address the memory requirements of the waveforms and constraints of the system. Summary Know the benefits of each architectural style Know how to tailor each style to address your particular needs Filter (n) Couple Acquire To:X-Y Clip Control Variables Fall 2002 CS-545-Fall-2002 What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?

Ch. 3 Case Studies Mobile Robotics Design Considerations
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Mobile Robotics Design Considerations Req. (1) Architecture must Accommodate Deliberate and Reactive Behavior Robot (system) must coordinate the actions to achieve the desired objectives based on the constraints and its operating environment. Req. (2) Architecture must allow for Uncertainty Robot (system) actions are never fully predictable Robot (system) must be able to operate (decide) with incomplete and unreliable information. Req. (3) Architecture must account for dangers present in its environment or its operation Robot architecture must balance fault-tolerance, safety, performance (Especially when people are placed in harms way or do not have immediate access to emergency services) Robot must be able to understand how to maintain its integrity, operators, and environment (you really don’t want it to go bang (or cause a bang) in an explosive, corrosive, or contaminated environment) ..I.e power conservation, detect unexpected failures, etc. Req. (4) Architecture must provide designer flexibility in application development, experimentation, and reconfiguration (new uploads) What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Case Studies Control Loop Approach Req. (1) Architecture must:
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Control Loop Approach Req. (1) Architecture must: Accommodate Deliberate and Reactive Behavior Closed Loop (real-time) feedback systems are very simple. (Book:) Note that feedback control loops assume changes in the environment are continuous and require continuous reactions. (Note that this is Not necessarily true -> Some feedback systems (especially weather prediction systems) can take months of sample and analysis before we are able to update predicted data. If the system is required to have an immediate reaction to an environment then we should consider this approach. We will find that there are better architecture approaches (I.e. simplified BB) for control of this type of problem, even for the control of real-time video. What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Case Studies Req. (2) Architecture must allow for Uncertainty
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Req. (2) Architecture must allow for Uncertainty In a control loop approach, the expected output signal is fed back to the input. The difference between the input signal and the predicted output signal generates an error signal that drives the control loop algorithm. This is the only uncertainty allowed. If more detailed uncertainty in the observed sampled inputs are required to be used in the control laws then we might go to an optimal estimator. However if “Uncertainty” implies that we want “Emergent” as of yet undefined behavior from our system in response to unplanned or unforeseen inputs, then a simple control loop architecture will not be able to handle the requirement. “I.e I want the Mars Rover to “Investigate” any situation that appears “interesting”. (Dynamic task prioritization) What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Case Studies Control Loop Approach
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Control Loop Approach Req. (3) Architecture must account for dangers present in its environment or its operation Fault-tolerance and safety are supported by this architecture style to the extent that it is “SIMPLE” and therefore reduces the errors that can enter the system. This is often not the case -> sensors fail, redundancy and voting logic must now be incorporated into the system, adding weight, power, and cost. Req. (4) Architecture must provide designer flexibility in application development, experimentation, and reconfiguration (new uploads) As is the case hardware components can often be easily replaced… What would you have to do control this architecture in order to update a new software load? Conclusion: Control Loop Architecture appears to be the best for SIMPLE robotic systems that handle a few number and types of inputs within a PREDICTABLE environment What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Case Studies Layered Architecture
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Layered Architecture Define Levels of Control: This in essence delegates the control and design to an appropriate level. Level 1: Manage Robot Actuators Level 2: Manage Inputs (A/D, DI/O, D/A) Level 3: manage Sensor Integration Level 4: Maintain Robot Situation Awareness Level 5: Navigates the Robot Level 6: Schedule Robot Activities Level 7: Re-Plan Robot Activities Req. (1) Architecture must Accommodate Deliberate and Reactive Behavior Nice breakout and localization of complexity Note however that it does not separate the control and the data hierarchy. Also note that each command must traverse ALL the layers. There is really no straightforward way to do Immediate commanding. What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Case Studies Req. (2) Architecture must allow for Uncertainty
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Req. (2) Architecture must allow for Uncertainty Note that we localize uncertainty management into the Situation Awareness Level. Req. (3) Architecture must account for dangers present in its environment or its operation We can easily add a Fault-Detection and Isolation Layer, however this addition adds to the complexity fo each command and each received input. We can easily isolate processing that discovers interesting relationships in the domain to a level. Req. (4) Architecture must provide flexibility in application development, experimentation, and reconfiguration (new uploads) If the layers are dependent on each other, then minor tweaks in one layer can have major adverse impact on the processing at the next layer, especially if the layer dependencies are complex !! Fall 2002 CS-545-Fall-2002

Case Studies Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Implicit Invocation This architecture uses events to coordinate the interactions between tasks . Tasks communicate by registering for certain events. Tasks can then be separated into Exception handlers, Monitors, and Observers (Wiretapping in your book). Req. (1) Architecture must Accommodate Deliberate and Reactive Behavior Allows the tasks to be concurrent !! The other model do not address concurrency directly. Req. (2) Architecture must allow for Uncertainty Not to clear how to build and control a task tree to handle uncertainty Need to define what we man by uncertainty. It is mechanical components that fail to operate correctly, or is it unexpected observations in the environment of interest. Ie. Is a High temperature, or sudden increase in temperature “interesting”. One approach is to define sensor LIMITS, and correlations between data that are “Interesting” and then direct the processing according to the observations. What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Case Studies Implicit Invocation
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Implicit Invocation Req. (3) Architecture must account for dangers present in its environment or its operation Fault-Tolerance can be handled by redundant task trees and A task tree that contains the voting logic between the redundant tasks can be added (More hardware, -> more cost, more power, you must now also know how the hardware will typically fail.) In some systems I have worked anywhere between 50-80% of the code is spent on error detection, handling, and recovery. Req. (4) Architecture must provide designer flexibility in application development, experimentation, and reconfiguration (new uploads) Making everything even driven makes the incremental development and replacement of functionality quite easy. We just register new components with the events they are interested in monitoring. Note !!! Existing architecture is NOT Affected… True.. Yes but we often get unexpected behavior (and rather humorous ones) when we do not fully account for the interaction between events, the processing, and the events they cause when system state is updated. What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Case Studies Blackboard Architecture
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Blackboard Architecture Req. (1) Architecture must Accommodate Deliberate and Reactive Behavior “Control Flow has to be coerced into the database mechanisms… One way to avoid this pitfall and ensure that all processing gets a chance to run is using the simple control approach I showed you earlier. By taking control in this manner you are taking control over (or ignoring all together) the actual processing of the events. You can write a single (or several) Control Knowledge sources (KS) that are scheduled to run just like all the other KS. These control KS maintain the system state and assess the situation just as easily as any other KS that gets scheduled to run. Req. (2) Architecture must allow for Uncertainty Individual KSs can be developed to look for aberrancies and trends in the environment. Am I overheating ? Why am I overheating ? What are the common failures and do I have the functionality to detect them? Have I designed the system to be able to isolate the faults or provide an override value? What tasks or behavior need to be reprioritized so as to not overheat ? What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Case Studies Blackboard Architecture
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Blackboard Architecture Req. (3) Architecture must account for dangers present in its environment or its operation One can easily construct a KS like before to look for events that require immediate action. Req. (4) Architecture must provide designer flexibility in application development, experimentation, and reconfiguration (new uploads) This architecture supports concurrency and decouples all the functionality, thus facilitating maintenance, and field upgrades to individual KS. This is especially true when you have limited bandwidth to perform remote updates. Your program may be several HUNDRED MEGABYTES, sending all that over a Modem takes SO LONG.. So …Consider sending only send the updates you need. So we write an update KS that disables the offending KS, accepts and verifies the updates, and then links the new KS into the task Lists !! What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Case Studies Comparisons
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Comparisons Control Loop Layers Implicit Invocation BB Task Coordination +/- - +/+ + Dealing with Uncertainty Fault Tolerance Safety Performance Flexibility Other Quality Attributes … ? Distributed Processing Final Selection What do YOU think is the best architecture given the current requirements and why ? How does your answer change if we are required to address more quality attributes ? How does your answer change for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Case Studies Cruise Control OO Approach vs. Control Loop Architecture
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Cruise Control OO Approach vs. Control Loop Architecture Note that the difference in the approaches requires a restatement of the problem so that we are open to consider architecture alternatives. Often a customer tells you what he wants in terms of indirect remarks at their view of an expected solution, rarely in terms of real requirements that would then permit you the freedom to design the best solution. Be brave enough to really take the time time to understand the requirements and then make the necessary architectural tradeoffs and the right decisions. What are the expected INPUTS ? What are the expected OUTPUTS? What is the user or system expected to do with the INPUTS? What is the user or system expected to do with the OUTPUTS? Object View of Cruise Control Based on Parnas.. Is the decomposition and the resultant Objects for the Object Correct ? Why or Why Not ? In controls a System is defined as being Observable and Controllable.. Does the the decomposition and the resultant Objects support this definition of a System? Does the Decomposition Directly Address the Requirements? How does your answer change for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Case Studies Cruise Control Process View of Cruise Control
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Cruise Control Process View of Cruise Control Computational Elements Process Definition Control Algorithm Data Elements Controlled Variables Manipulated Variables Set Points: Input Sensor Variables Notice the Restatement of the Problem and how it was developed Whenever the system is active, determine the desired speed Control the Engine the engine throttle to maintain the speed How where we able to restate the problem ? What did we do to give us the proper insight ? How does your answer change for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Case Studies Analysis & Discussion NOTE:
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Analysis & Discussion NOTE: The selection of the Architecture commits the Designer to a particular View of a Problem. How does your answer change for a local vs distributed homogeneous vs distributed heterogeneous system ? First… Understand the requirements, then select and morph the architecture into one that best address the requirements. DO NOT TRY TO FORCE a square peg solution on a round hole problem !!!! If you do, you will not adequately address the Quality Attributes for your specific system’s requirements. Often your resultant architecture will be a blend of several techniques. Notice the OO Approach: An Object is an entity that is characterized by actions that is performs and that it required of other objects. The Primary Criteria for decomposition is that each module in the system represents a major step in the overall process. So Which ABSTRACTION of the Problem is most appropriate. Was the proper abstraction selected, Why or why not ? Select a Different Abstraction and discuss the alternatives? How do I control or guarantee a given sequence in the OO approach? Fall 2002 CS-545-Fall-2002

Case Studies Control View
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Control View Leads us to specify the output as the actual speed of the vehicle. (Observable) Separation of Control from Processing makes output explicit and supports validation (Controllable) Permits explicit decisions concerning the control decisions and algorithms to be used. (EIA-632) Control Paradigm discriminates between input types and make the feedback loop more obvious (Controllable) Clear separation between manual and automatic operations Set point determination explicit and easier to verify (Observable) See Issue with Booch’s design in your text. How does your answer change for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Case Studies Methodology Implications Choose the Control Principle
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Methodology Implications Choose the Control Principle Timing Synchronization ? Especially in Distributed Systems !… Allowable Control Errors? Choose the Control Variables Local or Global ? If Global how do we keep the state of these variables synchronized ? Choose the Measured Variables How ? What are is our criteria for selecting these variables? Create the Subsystems (See Below) Choose the Data Distribution, Organization, and Maintenance Policies ? Global Status vs. Local Status ? Incremental State Update vs. Global State Update ? Choose the Task Allocation, Organization and Maintenance Policies ? How Controlled ? (Local or Global) How Updated ? Chose the Failure Detection, Handling, and Recovery Policies ? Identify the QA impacts to the architecture at each level. How does your answer change for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Case Studies Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Summary “Our exploration of Cruise Control has shown that the significant high-level decisions are better elicited by a methodology based on process control than on the more common object-oriented methodology.” Actually this is more true than you may think and is applicable to just about any problem you might conceive or be faced with. All systems accept an input, perform some function wrt that input, and then generate an output. (whether it’s a processing event, time event, data event, or network event) All systems therefore MUST be “Observable” and “Controllable” Observable – I need to be able to monitor the States of Concern of my system Is it doing the right thing ? Controllable – I need to be able to take my system from state to state in a well defined, repeatable manner. If you do NOT take this view then: You will end up developing a system that does something, but its operation cannot be verified. It may even do the right thing but it will rarely meet the stringent control, boundary, and quality attributes requirements or support upgradeability. Fall 2002 CS-545-Fall-2002

Mid-term and Final Question
NASA has asked you to develop a remote Rover to go into Volcanoes. However due to their contracting policies different vendors must supply their own boxes to address their unique functionality Re-design the Speed Controller as a Distributed blackboard system Identify the Knowledge Sources Develop the Overall Use Case Flow Exercise the Architecture against a Quality Attribute of your choosing. Discuss Pros and Cons for the Approach Discuss the Control Architecture Discuss the Data Architecture Discuss the KS (Functional Architecture) Discuss Fault-Detection, Handling, and Recovery Policies Fall 2002 CS-545-Fall-2002

Case Studies Mixed Vignettes in Mixed Style
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Mixed Vignettes in Mixed Style Layered Design with different styles for the layers Perfectly Acceptable.. Remember…. Often your resultant architecture will be a blend of several techniques. Configure and use the Architecture best suited to address the Requirements for that level or elements of the architecture At some level of abstraction, every architecture (or element of an architecture) must eventually talk to the OS, especially for I/O. So I might have an KS just dedicated to handling I/O with the OS. How does your answer change for a local vs distributed homogeneous vs distributed heterogeneous system ? Fall 2002 CS-545-Fall-2002

Case Studies An interpreter using different idioms for the components
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Lee Brownston, et al. Programming Expert Systems in OPS5: An Introduction to Rule-Based Programming, Addison Wesley, Jan. 1986 An interpreter using different idioms for the components Working Memory Rule base Fact memory Knowledge base Interpreter Rule & Data Element Selection Selected Rule Selected Data Inputs Outputs New Facts New Active Rules Trigger Data Data & Updates Active Rules & Facts Select and and Execute Rules based on the Current State and Derived Facts What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ? The Example in the book shows how the Architecture Elements For a Rule-based Systems are realized using a number of Architecture Types. Fall 2002 CS-545-Fall-2002

Simple Rule System Example
Facts: (23 is a known-number) (23 is a known-odd-number) Rule : (IF ( ( ? Is CONTAINED IN known-number) and ( ? known-number) IS CONTAINED IN (? Known-odd-number)) and ( ? known-number IS NOT CONTAINED IN (? Known-prime-number)) (THEN (? NUMBER IS CONTAINED IN (? Possible-prime-numbers))) : : Need more rules to determine if the number is prime. Fall 2002 CS-545-Fall-2002

Case Studies Unfinished Action Inactive Rules Active Facts Execution
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Lee Brownston, et al. Programming Expert Systems in OPS5: An Introduction to Rule-Based Programming, Addison Wesley, Jan. 1986 So why the Distinction Between Inactive & Active? What Architectural Style would we have if this data was maintained remotely? Inactive Rules Active Facts Activation/ Deactivation Active Rules & Facts Rule & Fact Compiler Execution Stack Control Procedures Interpreter Scheduler Selected Actions Next Action Unfinished Action Outputs Incomplete Trigger Data Matching Rule/Data Pairs Regardless of whether or not you are actually building a rule based system You can use this general approach to build A scheduler to identify the Tasks required to be scheduled When investigating Aberrant or interesting conditions in the environment Data Flow Network for Partially Evaluated Rule Sets Delete Completed Activations Candidate Rule/Data Activations Rule & Fact Compiler Prioritized Activations Agenda Fall 2002 Meta Control Rules CS-545-Fall-2002

Case Studies A Blackboard globally cast as an Interpreter
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Lee Brownston, et al. Programming Expert Systems in OPS5: An Introduction to Rule-Based Programming, Addison Wesley, Jan. 1986 A Blackboard globally cast as an Interpreter See the Examples and be ready to Discuss them… Fall 2002 CS-545-Fall-2002

Week 7 Case Studies (Domain Specific Languages)
CS-545 Week 7 Case Studies (Domain Specific Languages)

Domain Specific Languages: PLP
Programming Language Perspective A programming language dedicated to a particular domain or problem. It provides appropriate built-in abstractions and notations; It is usually small, more declarative than imperative, and less expressive than a general-purpose language (GPL). Fall 2002 CS-545-Fall-2002

Domain Specific Languages: SLP
Specification Language Perspective DSLs can hide much of the implementation details DSLs may considered more as specification languages than programming languages. Those specifications are often executable, though. The key characteristics are still specific abstractions and notations as well a restricted (or rather focused) expressive power. Fall 2002 CS-545-Fall-2002

Domain Specific Languages: SLP
E.g. Make (Yes …make really is a DSL) Determines automatically which pieces of a large program need to be recompiled, and issues the commands to recompile them. The language of makefiles is small (at least in the early versions of make) and mainly declarative, although it also contains some imperative constructs. Its expressive power is limited to updating task dependencies; actual recompilation actions are delegated to a shell. It hides implementation details like file last-modification time and provides domain abstractions such as file suffixes and implicit compilation rules. As a result, the user may concisely and precisely express update dependencies. Fall 2002 CS-545-Fall-2002

Why Use a DSL Three crucial properties for the software industry:
Three crucial properties for the software industry: Productivity: programming, maintenance and evolution are much easier (in some cases, development time can be ten times faster); Re-use is systematized: A DSL offers guidelines and built-in functionalities which enforce re-use. A DSL captures domain expertise, either implicitly by hiding common program patterns in the DSL implementation, or explicitly by exposing appropriate parameterization to the DSL programmer. Thus, any user necessarily re-uses library components and domain expertise. Verification: it becomes possible or much easier to automate formal proofs of critical properties of the software: security, safety, real time, etc.. The semantics of a DSL can be restricted to make decidable some properties that are critical to a domain. For example, make reports any cycle in dependencies and thus totally prevents non-termination (assuming the individual actions do not loop). However, most DSL approaches and techniques are still ad hoc Fall 2002 CS-545-Fall-2002

Domain Specific Languages: SAP
A Software Architecture Perspective Parameterization mechanism A program or a library can be more or less generic depending on the scope of the problems it addresses [Boo87]. For example, a scientific library can be highly generic considering the vast variety of problems it can be used for. Pushing the idea of genericity further leads to complex parameters that can be seen as DSLs. For example, the format string argument of function printf can be seen as both a complex parameter and a very simple DSL. Considering a DSL program as a complex argument to a highly parameterized component may sound contrived but it actually is the final step of a chain of increasingly expressive power in parameterization. This situation is illustrated by Unix commands grep, sort, find, sed, make, awk, etc., and the progression from simple command-line parameters to program files. At the end of the spectrum, the data parameter ends up being a program to be processed, yielding increased parameterization power. Fall 2002 CS-545-Fall-2002

A Software Architecture Perspective Interface to a library As a library becomes larger or more generic, its usability decreases due to the multiplication of entry points, parameters and options offered. As a result, the library might be ignored by programmers because it is too complex to use. A DSL therefore can offer a domain-specific interface to the library so that the programmer does not have to directly manipulate numerous highly-parameterized building blocks; the complexity is hidden. Another common situation is when some patterns of library calls occur frequently. In this case, a DSL interface can provide direct access to those commonly used combinations. E.g. Unix shells are interfaces to standard Unix libraries. SQL hides low level queries to a database. This idea is shared by scripting languages, that glue together a set of powerful components written in traditional programming languages. Fall 2002 CS-545-Fall-2002

A Software Architecture Perspective Program family A DSL program designates a member of a program family. A program family is a set of programs that share enough characteristics that it is worthwhile to study them as a whole [Par76]. A program family can also be seen as providing a solution to a problem family, i.e., a set of related problems. Drivers, for a given type of device, form a natural example of a program family: in addition to having the same API (for a given operating system), they all share similar operations, although they vary according to the hardware. Fall 2002 CS-545-Fall-2002

When to Develop a DSL Does the program to be developed address an isolated problem OR could it be a member of a future program family? DSLs have been used in various domains such as graphics, financial products, telephone switching systems, protocols, operating systems, device drivers, routers in networks and robot languages. Fall 2002 CS-545-Fall-2002

How does one Develop a DSL ?
D.L. Parnas. On the design and development of program families. IEEE Transactions on Software Engineering, 2:1-9, March 1976. Ontology: Ontologies enabling knowledge sharing and reuse. an ontology therefore is a specification used for making ontological commitments. An ontology can be described as a set of definitions of formal vocabulary. Although this isn't the only way to specify a conceptualization, it has some nice properties for knowledge sharing among programs Fall 2002 CS-545-Fall-2002

D.L. Parnas. On the design and development of program families. IEEE Transactions on Software Engineering, 2:1-9, March 1976. An ontological commitment is an agreement to use a vocabulary (i.e., ask queries and make assertions) in a way that is consistent (but not complete) with respect to the theory specified by an ontology. We build agents that commit to operating over an ontology. We design Ontologies so we can share knowledge with and among these agents. The Bottom Line to all this – How do we intend to Codify the domain and permit one to operate over and manipulate that domain efficiently. What are the Data Types ? … What is their Inheritance Structure ? What are the Operations ? …. Fall 2002 CS-545-Fall-2002

Ontology research and design is performed using knowledge representation tools descended from KL-ONE. KL-ONE was the basis for much work in the field of knowledge representation. KL-ONE implemented “structural inheritance networks”: networks containing descriptions of named concepts with generalisation / specialization links between them. Descendants of KL-ONE include LOOM and a http family of logics called description logics or terminological Fall 2002 CS-545-Fall-2002

KL-ONE and LOOM knowledge bases are structured to allow inferences to be performed efficiently on the user-defined concepts: Subsumption: Is a given concept description more general or more specific than another, or can no such relation be established? Coherence: Is a concept description logically coherent, i.e. can there be an instance of this term? Identity: Do two concept descriptions refer to the same concept? Compatibility: Can two concept descriptions have common instances? Common specialization: What are the properties of the common specialization of two concept descriptions? Infrastructure (such as query planning agents), it is certainly possible to use other reasoning engines. Fall 2002 CS-545-Fall-2002

J. C. Cleaveland. Building application generators. IEEE Software, pages 25-33, July 1988. A. van Deursen and P. Klint. Little languages: Little maintenance? Journal of Software Maintenance, 10:75-92, 1998. [Analysis] (1) Identify the problem domain. (2) Gather all relevant knowledge in this domain. A prerequisite therefore to developing a DSL is mature domain knowledge !!! (Or a really good idea of how to conceptualize the domain) (3) Cluster this knowledge in a handful of semantic notions and operations. (4) Design a DSL that concisely describes applications in the domain. [Implementation] (5) Construct a library that implements the semantic notions. (6) Design and implement a compiler that translates DSL programs to a sequence of library calls. [Use] (7) Write DSL programs for all desired applications and compile them How does this simplify our local vs distributed homogeneous vs distributed heterogeneous system dilemma? Fall 2002 CS-545-Fall-2002

K. Czarnecki and U. Eisenecker. Generative Programming: Methods, Techniques and Applications. Addison-Wesley, 1999. K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, and A. S. Peterson. Feature-oriented domain analysis (FODA) feasibility study. Technical Report CMU/SEI-90-TR-21, Software Engineering Institute, Carnegie Mellon University, 1990. R. N. Taylor, W. Tracz, and L. Coglianese. Software development using domain-specific software architectures. ACM SIGSOFT Software Engineering Notes, 20(5):27-37, 1995. Domain engineering refers to the activity of systematically modeling domains. Domain engineering originates from research in the area of software reuse, and can be used when constructing domain-specific reusable libraries, frameworks or languages. Several domain engineering methodologies exists, of which ODM (Organizational Domain Modeling), FODA (Feature-Oriented Domain Analysis) and DSSA (Domain-Specific Software Architectures) are best known. Fall 2002 CS-545-Fall-2002

Coplien, D. Hoffman, and D. Weiss. Commonality and variability in software engineering. IEEE Software, pages 37-45, November/December 1998. Strongly related to domain engineering is the notion of program families which are sets of similar programs. Family-Oriented Abstraction, Specification and Translation (FAST) approach, which has been successfully applied to over 25 different domains Program families are in turn related to software product lines. These emphasize features shared by all products, and are focused on the needs of a selected market. Fall 2002 CS-545-Fall-2002

DSL Pros & Cons The benefits of DSLs include:
The benefits of DSLs include: Allows solutions to be expressed in the idiom and at the level of abstraction of the problem domain. Consequently, domain experts themselves can understand, validate, modify, and often even develop DSL programs. Programs are concise, self-documenting to a large extent, and can be reused for different purposes. Enhances productivity, reliability, maintainability, and portability. Embodies domain knowledge, and thus enable the conservation and reuse of this knowledge. Allow validation and optimization at the domain level. Improves testability. Fall 2002 CS-545-Fall-2002

DSL Pros & Cons The disadvantages of the use of a DSL are:
The disadvantages of the use of a DSL are: The costs of designing, implementing and maintaining a DSL. The costs of education for DSL users. The limited availability of DSLs. The difficulty of finding the proper scope for a DSL. The difficulty of balancing between domain-specificity and general-purpose programming language constructs. The potential loss of efficiency when compared with hand-coded software. Fall 2002 CS-545-Fall-2002

Using UML & OCL to Capture a DSL
Benefits of using UML and Object Constraint Language (OCL) OCL include the following: UML has a very large and rapidly expanding user community. Users are more likely familiar with this notation and therefore use will it There is a standard graphical representation for models expressed in UML. Such a graphical representation is important to allow users of distributed information systems to browse an ontology and discover concepts that can appear in their queries. In contrast, a description logic has a linear syntax but no standard graphical representation. Although UML currently has no standard linear syntax, the OMG is in the process of adopting XMI (XML Model Interchange) as a standard for stream-based model inter-change OCL allows the expression of constraints that cannot be de-scribed using description logic. See the references for using UML and OCL to capture a domain Fall 2002 CS-545-Fall-2002

UML Alone Limitations to Capture a DSL
Class Diagrams Class Parts: Class Name, Attributes, Operations Relationships: Generalization: (Roles) Association: Links & Association Classes (I use association classes to capture constraint relationships between classes Aggregation: Object Diagrams Capture instances of the objects and links between them Limited semantics to define ordering of objects and operations over those objects. Fall 2002 CS-545-Fall-2002

CS-545 Week 8 Developing an Architecture
Given Set of Requirements, how do we choose the best Architecture?

Architecture Design Alternatives
Develop an architecture design decision-making process that: helps a designer choose amongst architectural options, during both initial design and its subsequent periods of upgrade, while being constrained to finite resources. Architecture design decision-making involves addressing tradeoffs due to the presence of economic and the other quality attribute constraints. Our approach incorporates the costs and benefits of architectural design decisions and (the) means of making decisions. Our approach provides a structured integrated assessment of the technical and economic issues and architectural decisions. Our approach uses techniques from decision analysis, optimization, and statistics to help characterize the uncertainties in an architecture and choose the best informed subset. Fall 2002 CS-545-Fall-2002

Which Architectural Style or Styles should I use?
Jan Bosch, Design & Use of Software Architectures: Adopting and Evolving a Product Line Approach: ISBN: Which style(s) best addresses the quality attributes for each level of the system Which style(s) best addresses the control issues Which style(s) best addresses the data issues Which style(s) best addresses the control/data interaction issues Which style(s) best addresses the functional issues Which style(s) best addresses the communication issues? Which style(s) best addresses the development and deployment, and operational constraints. The tendency is to start with the style you are most comfortable with and then try to adapt the architecture to address all the requirements.… This approach results in a spaghetti design and code. Do the Analysis …Look at each of the issues above individually, then collectively against the requirements and select the best hybrid style Fall 2002 CS-545-Fall-2002

From Requirements to Design
Jan Bosch, Design & Use of Software Architectures: Adopting and Evolving a Product Line Approach: ISBN: Develop the Quality Attributes: Identify and rank the 21 Quality Attributes Develop the QA Utility Trees Identify the decisions and scenarios at each level for your system Perform the Quality Function Deployment Map the Requirements to the Possible Architectural Styles. Identify the Styles that directly support the Quality Attributes. Identify the Architectural decisions to meet the Quality Attributes. Identify the transformations (design patterns or functional repartitioning) that solve the problem spots in the architecture Select and Perform the transformations on the architecture Fall 2002 CS-545-Fall-2002

Identify and rank the 21 Quality Attributes for the system
For each quality attribute, develop a utility tree. Identify the inputs to the architecture that exercise this quality attribute for each level of the architecture. These inputs can be anything from events to change requests Identify the response by the architecture to the events These are typically couched in terms of Identify the domain specific decisions for a given architectural layer for the quality attribute Identify the decisions required for the different architecture layers Used to verify the architecture meets the Quality requirements. Select the set of inputs, decisions, and response criteria for your problem domain. This identifies the scope of the trade studies Fall 2002 CS-545-Fall-2002

QFD Map the Requirements against the Possible Architectural Styles.
QFD for Support and Correlation strengths and weaknesses Map the Possible Architectural Styles that directly support the Quality Attributes. Identify the Architectural decisions wrt to meeting the Quality Attributes. Perform Design Space analysis Identify the transformations (design patterns or functional repartitioning) that will solve the problem spots in the architecture Select and Perform the transformation Select the design pattern Reorganize the functionality to suite the selected pattern. Update Design Space analysis Fall 2002 CS-545-Fall-2002

Architecture Analysis and the Quality Attributes

Architectural Analysis
ATAM: Architecture trade-Off Analysis SAAM: Software Architecture trade Off Analysis ABAS: Attribute Based Architectural Styles ARID: Active reviews for Intermediate Designs SNA: Survivable Network Analysis Method Fall 2002 CS-545-Fall-2002

Architecture Trade-Off Analysis Method
Why should an organization analyze a software or system architecture? A cost-effective way of mitigating the substantial risks associated with this highly important artifact. Architectures are the blueprints for a system, and the carriers of the system's quality attributes. Most software systems are required to be modifiable and have good performance. They may also be a requirement to be secure, interoperable, portable, and reliable…. What precisely do these quality attributes - modifiability, security, performance, reliability - mean? for a particular system, Can a system be analyzed to determine these desired qualities? How soon can such an analysis occur? How do you know if a software architecture for a system is suitable without having to build the system first? Fall 2002 CS-545-Fall-2002

Architecture Trade-Off Analysis Method
Quality attributes of large software systems live principally in the system's software architecture. The achievement of qualities attributes depends more on the overall software architecture than on code-level practices such as language choice, detailed design, algorithms, data structures, testing, and so forth. It is critical that we determine, before a system is built, whether it will satisfy its desired qualities. Methods for analyzing software systems with respect to specific quality attributes exist BUT these analyses are often been performed in isolation and dependencies are not understood. See ISO Quality Attribute Link and previous slide introductions Fall 2002 CS-545-Fall-2002

ATAM Continued The attributes - and therefore hence their analyses – interact Performance affects modifiability. Availability affects safety. Security affects performance. Everything affects cost. : There is no codified method for characterizing them There is no particular method for characterizing their interactions. Fall 2002 CS-545-Fall-2002

Consequences Software architectures are often designed "in the dark."
Tradeoffs are made - but they are (often) made in an ad hoc fashion. Techniques that are used try to mitigate the risks of having to choose an architecture to meet a broad palette of quality attributes. A designer will choose one pattern because it is "good for portability" and another because it is "easily modifiable." But the analysis of patterns doesn't go any deeper than that. A designer using these patterns does not really know how portable, or modifiable, or robust an architecture is until it has been built. Fall 2002 CS-545-Fall-2002

ATAM Continued The ATAM is based upon a set of attribute-specific measures of the system some analytic, based upon formal models (e.g., performance and availability) some qualitative, based upon formal inspections (e.g., modifiability, safety, and security). We now have a stable process for carrying out ATAMs, including a set of steps, and a set of reusable architectural styles and analytic models, called ABASs, that we use during the course of an ATAM. ATAM benefits include: clarified quality attribute requirements improved architecture documentation documented basis for architectural decisions identified risks early in the life-cycle increased communication among stakeholders Fall 2002 CS-545-Fall-2002

ATAM Process The most important results are improved architectures.
The ATAM elicits sets of quality requirements along multiple dimensions, analyzing the effects of each requirement in isolation, and then understanding the interactions of these requirements. Both processes involve technical and social aspects. The technical aspects deal with how architectural information is collected, represented, and analyzed. The social aspects deal with the interactions among the system's stakeholders and area-specific experts, allowing them to communicate using a common framework, to make the implicit assumptions in their analyses explicit, and to provide an objective basis for negotiating the inevitable architecture tradeoffs. The output of an ATAM is an out-brief presentation and/or a written report that includes the major findings of the evaluation. Fall 2002 CS-545-Fall-2002

ATAM Process These are typically: the architectural styles identified
a "utility tree" - a hierarchic model of the driving architectural requirements the set of scenarios generated and the subset that were mapped onto the architecture a set of quality-attribute specific questions that were applied to the architecture and the responses to these questions a set of identified risks a set of identified non-risks It is not necessary to have a full fledged architecture before some of the ATAM benefits can be achieved. Under some circumstances, an organization might wish to identify potential risks even earlier and use this information as guidance for developing a system's architecture. The workshop identifies potential sensitivities, tradeoffs, and risks and use these as early warnings to the architecture developers. Fall 2002 CS-545-Fall-2002

ATAM Products Prioritized Statement of Quality Attribute Requirements
Paul Clements, et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Prioritized Statement of Quality Attribute Requirements Mapping of Approaches to Quality Attributes Identification of Risks and Non-Risks Catalog of Architectural Approaches Used Approach & Quality-Attribute Specific Analysis Questions Sensitivity Points and Trade-offs. Fall 2002 CS-545-Fall-2002

ATAM QA mapped to ISO QA Functionality: Functionality Reliability:
Paul Clements, et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Functionality: Security: Reliability: Availability: (Efficiency) Performance: (Maintainability) Modifiability: Subsetability: Conceptual Integrity: Variability: Portability: ISO/IEC 9126: Information Technology – Software Product Evaluation – Quality characteristics and guidelines for their use, 1991. Functionality Suitability, Accuracy, Interoperability, Compliance, Security Reliability Maturity, Fault-Tolerance, Recoverability Usability Understandability, Learn ability, Operability Efficiency Time behavior, Resource Behavior Maintainability Analyzability, changeability, Stability, Testability Portability Adaptability, Install ability, Conformance, Replace ability Fall 2002 CS-545-Fall-2002

Issues with Quality Attributes
Paul Clements, et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X ISO/IEC 9126: Information Technology – Software Product Evaluation – Quality characteristics and guidelines for their use, 1991. QA do not exist as absolute quantities, they exist in the context of a particular goal. A system is modifiable (or not) wrt a specific kind of 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. A system performs (or not) wrt a specific perf. criteria A system is suitable (or not) wrt an envisioned product line : See the other ISO Quality Attributes: Use USE CASE Scenarios are used to understand the intended interaction of the end user with the system to verify the acceptability of the system to address the QA. Fall 2002 CS-545-Fall-2002

ATAM in Practice: 9 Step Program
Paul Clements, et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Toward Deriving Software Architectures From Quality Attributes Goal: Understand a precise statement of the quality attributes Present the ATAM Approach Present the Business Drivers Present the Architecture Identify the Architectural Approaches Generate the Quality Attribute Utility Tree Understand a precise statement of the architecture design decisions Analyze the Architectural Approaches Brainstorm & Prioritize Scenarios Analyze the Architecturally Significant Approaches Present the Results Fall 2002 CS-545-Fall-2002

ATAM in Practice: Present the ATAM
Paul Clements, et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Scenario based Analysis of Software Architecture Describe the elicitation techniques (use cases) Describe the categories of use cases Show how use cases capture the external influences on the system Show how use cases capture the internal system components interaction Show how use cases capture, events, connections, risks, notes, and issues Describe the Utility tree generation A PRIMARY output that describes and prioritizes the architectural: Requirements Architectural approaches Development, Deployment, Installation, Operational, etc. Risks Fall 2002 CS-545-Fall-2002

ATAM in Practice: Present the ATAM cont.
Describe the Architecture centric elicitation & analysis Identify the possible use case scenario categories With a assembled team, select those use cases categories and scenarios that exercise major ARCHITECTURAL transitions or that are expected to highlight major requirement dependencies. Describe the Scenario brainstorming techniques Note that you need NON-SW personnel when developing a system!! SW is NOTHING MORE THAN A PART (even though a critical part) in a system. SW has to work with EVERYTHING else. I.e hardware chips, its resident cards, other cards, interfaces, etc. If the driving scenarios are manufacturing related then get the manufacturing engineers. Fall 2002 CS-545-Fall-2002

ATAM in Practice: Present the Business Drivers
Adapted from: Paul Clements, et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Systems most Important Functions NOT just the Operational Ones. Also consider the ONES that DRIVE the overall system (not just SW) Architecture I.e startup, shutdown, backup, suspend, resume, recover, sequences, etc. Constraints Business Time to market, standards. Customer Operational, Installation, training, maintenance… etc. Life-Cycle Phase Dependent Constraints Life-Cycle Phase Independent Constraints Fall 2002 CS-545-Fall-2002

Adapted from: Paul Clements, et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Business Goals (BG) and context as they relate to the project Product that meets requirements AND constraints. How do the architecture options intend to do this? Product built on schedule How does the architecture development address the schedule commitments? Product built on budget How does the architecture development address the cost commitments? Product that’s easy to maintain When there is problems or requested updates, how does the intended architecture support the changes. Define the QUALITY ATTRIBUTES pertinent to (BG) and HOW the architecture intends to address them !! Fall 2002 CS-545-Fall-2002

Adapted from: Paul Clements, et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Identify the DRIVING Architectural Requirements Functional Normal modes Degraded modes Training modes Testing modes Deployment modes : Operational Startup/Shutdown Backup/Restore Suspend/Resume Fall 2002 CS-545-Fall-2002

Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Identify the DRIVING Architectural Policies Task Allocation and updates, throughput, and latency Data Distribution and Consistency Updates Fault Detection, isolation, reporting (local & global), and recovery Event Handling and Logging (global vs. local) Health & Status monitoring and reporting (global vs. local) Architecture Dynamics How are new components expected to announce themselves? How is the architecture self-aware of its surroundings? Ontology Fall 2002 CS-545-Fall-2002

ATAM in Practice: Present the Architecture
Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Define the architectural constraints Requirement constraints Development constraints Test Constraints Manufacturing Constraints Installation Constraints Operational Constraints Training Constraints Deployment Constraints Transportation Constraints Here we are concerned with identifying the constraints that DRIVE the architecture!! Identify and define scenarios that will exercise the critical constraints and requirements against the architecture Fall 2002 CS-545-Fall-2002

ATAM in Practice: Present the Architecture
Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Present the Architecture: Use as many CONSISTENT VIEWS of the Architecture as necessary to convey HOW the architecture has addressed the REQUIREMENTS and CONSTRAINTS. Logical Physical Timing Control and Sequencing Concurrency, Synchronization, Data flow, Functional Flow, layers, etc.. COTS Use and internal reuse approach Most important (architecturally significant) use case scenarios Most important (architecturally significant) growth use case scenarios Fall 2002 CS-545-Fall-2002

ATAM in Practice: Identify Architecture Approaches
Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Identify the architectural approaches, styles, patterns, and mechanisms employed to address the requirements and constraints. Define the features, benefits, and drawbacks of each style used Data and control interactions Connection types External environment interfaces Define HOW that style addresses the QA. This leads to attribute-specific questions related to the style Performance-oriented ABAS highlights style decisions relevant to performance. Map the above approaches to the prioritized QA they are intended to address Fall 2002 CS-545-Fall-2002

ATAM in Practice: Generate the Quality Attribute Utility Tree
Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Adapted from : ISO/IEC 9126: Information Technology – Software Product Evaluation – Quality characteristics and guidelines for their use, 1991. Functionality Each ISO QA is decomposed into a set of design specific analyses, verifications, and scenarios for YOUR domain. These attributes are the KEY to the success of your system. Get the stakeholders concerns Reliability Usability Utility Efficiency Maintainability Portability Fall 2002 CS-545-Fall-2002

Functionality Quality Attribute Utility Tree Decomposition Example
Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Adapted from: ISO/IEC 9126: Information Technology – Software Product Evaluation – Quality characteristics and guidelines for their use, 1991. Operators Suitability Trainers Functionality Installers : Accuracy Algorithm Precision : Reliability Data Precision Timing Precision Other Systems Interoperability Utility : Usability Other Protocols IEEE Standards Efficiency Compliance : Other Industry Standards Other Customer Standards Maintainability Data Confidentiality Internal Program Access : Data Access Security External Program Access Portability Domain Specific concerns examples ISO Fall 2002 CS-545-Fall-2002

Reliability Quality Attribute Utility Tree Decomposition
Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Adapted from: ISO/IEC 9126: Information Technology – Software Product Evaluation – Quality characteristics and guidelines for their use, 1991. Background BIT Functionality Maturity Detection Commanded BIT Isolation Reliability Fault-Tolerance Handling Usability Utility Reporting Efficiency Resumption of Service Maintainability : Recoverability DB Recovery Domain Specific concerns examples Portability ISO Fall 2002 CS-545-Fall-2002

Usability Quality Attribute Utility Tree Decomposition
Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Adapted from: ISO/IEC 9126: Information Technology – Software Product Evaluation – Quality characteristics and guidelines for their use, 1991. Functionality Installers Understandability Maintainers : Reliability Operators Trainers Usability Utility Learn ability Dedicated Training Time : Efficiency OJT Training Time Personnel Requirements Maintainability : Operability Workstation Requirements Portability ISO Domain Specific concerns examples Fall 2002 CS-545-Fall-2002

Efficiency Quality Attribute Utility Tree Decomposition
Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Adapted from: ISO/IEC 9126: Information Technology – Software Product Evaluation – Quality characteristics and guidelines for their use, 1991. Concurrency Functionality : Time Behavior Reliability Synchronization Start Constraints : Usability Completion Constraints Utility Resource Behavior Processor Loading & Performance Efficiency Memory Loading & Performance Interface Loading & Performance : Data Storage Loading & Performance Maintainability Portability ISO Domain Specific concerns examples Fall 2002 CS-545-Fall-2002

Maintainability Quality Attribute Utility Tree Decomposition
Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Adapted from: ISO/IEC 9126: Information Technology – Software Product Evaluation – Quality characteristics and guidelines for their use, 1991. Utility Maintainability Reliability Usability Efficiency Functionality Portability Analyzability Testability Stability Domain Specific concerns examples Changeability Health & Status Logging Event Logging Trending Global Logging Local Logging Testing Sequence Subsetability Sequence Testing Equipment MTTR MTBF Number of Failures HW Update Design SW Update Design ISO Fall 2002 CS-545-Fall-2002

Portability Quality Attribute Utility Tree Decomposition
Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Adapted from: ISO/IEC 9126: Information Technology – Software Product Evaluation – Quality characteristics and guidelines for their use, 1991. OS Upgrade Functionality Adaptability Different OS Reliability Different HW Platform Installability Remote Distributed Utility Usability Local Existing HW Efficiency Conformance Planned HW Maintainability Replaceability On-Line Portability ISO Domain Specific concerns examples Fall 2002 CS-545-Fall-2002

Maintainability Domain Specific Quality Attribute Utility Tree Expansion Example
Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Adapted from: ISO/IEC 9126: Information Technology – Software Product Evaluation – Quality characteristics and guidelines for their use, 1991. HW Update Add CORBA MW in 6 months Analyzability Functionality (X,Y) SW Update Reliability Stability Change Web UI in 2 months Usability Utility (X,Y) MTTR Efficiency Changeability (X,Y) Prioritization (X) = Importance (Y) = Difficulty Now define a Use Case that encompasses these actions !! (QA Scenarios) Maintainability Testability Portability ISO Domain Specific Expansion Fall 2002 CS-545-Fall-2002

ATAM in Practice: Analyze the Architectural Approaches
Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Inputs: A set of the Architecture styles used in the architecture A prioritized set of quality attribute requirements and scenarios Processing: Do the styles support the QA requirements and scenarios? What are the Risks ? Sensitivity Points ? Tradeoffs? Outputs: See next Slide Fall 2002 CS-545-Fall-2002

Architectural Analysis Template Example
Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Scenario (XXX) Analysis Scenario # Scenario Name Add CORBA MW in 6 months Quality Attribute Attributed Related Stimuli: Attributed Related Response: Notes: Issues: Assumptions: Architectural Decisions (Sensitivities) Reasons….. Tradeoff – Risk Tracking Architectural Decisions relevant to this scenario that affect the quality attribute response Model Reference Diagrams AS-101 Number of CPUs Decision Reason R-5 AS-102 Number of Data Channels NR-4 AS-103 Watchdog timer removal T-1 R-6 AS-104 Heartbeat removal NR-5 Fall 2002 CS-545-Fall-2002

Performance Quality Attribute Characterization Example
Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Events that cause the architecture to change that affect this quality attribute Performance Architectural Stimuli Architectural Decisions Architectural Responses Decisions that directly affect the response of this quality attribute of the architecture. The measurable, observable elements of the architecture in response to the stimuli Fall 2002 CS-545-Fall-2002

Performance Stimuli Characterization Example
Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Internal Event Architectural Stimuli Source Clock Event External Event : Architectural Decisions Periodic Performance Arrival Pattern : sporadic : A periodic Distribution : You must define these and the specific stimuli for your architecture and domain Architectural Responses Fall 2002 CS-545-Fall-2002

Performance Decision Characterization Example
Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Resource Type Processors Architectural Stimuli Memory Resource Scheduling Networks : Resource Allocation Performance Architectural Decisions Resource Consumption : Architectural Responses You must define the specific decisions for your architecture and domain Fall 2002 CS-545-Fall-2002

Performance Response Characterization Example
Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Response Window Architectural Stimuli Latency : Criticality : Architectural Decisions Expected Performance Throughput Performance Criticality : : Expected Performance Architectural Responses Criticality : Precedence Expected Performance You must define the specific observables for your architecture and domain Fall 2002 CS-545-Fall-2002

ATAM in Practice: Brainstorm & Prioritize Scenarios
Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Review Utility Tree for Non-Covered Attributes. Develop Scenarios as appropriate Review Review Operational Scenarios Develop additional scenarios as appropriate Review Growth Scenarios Add capability …. Review Exploratory Scenarios Improve reliability…. Analyze the Architectural Approaches against these new scenarios Fall 2002 CS-545-Fall-2002

ATAM in Practice: Present the Results
Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Documented Architecture Approaches Prioritized Scenarios Attribute based Questions The Utility Tree Risks and Non-Risks Identified The trade studies identified Fall 2002 CS-545-Fall-2002

SAAM in Practice: 6 Step Program
Paul Clements, et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Toward Deriving Software Architectures From Quality Attributes Goal: Quickly assess an architecture against changes in its quality attributes Primary input is a set of scenarios that represent known or expected changes to the architecture Develop expansion scenarios of the architecture. Present the Architecture (see ATAM) Classify and Prioritize the Scenarios Direct Scenarios: Currently satisfied by the architecture Indirect Scenarios: One that requires architecture modification to be realized Map the Scenarios to the architecture Assess Scenario Interactions High interaction show low separation of concerns in the scenario or the architecture. The Higher the interaction typically the higher the defects. Highlights architecture decomposition and documentation inadequacies Present the results Fall 2002 CS-545-Fall-2002

SAAM Results Architecture (1) Architecture (n) : - Fall 2002 Scenario
Number - ID Priority Description Direct – Indirect Items Requiring change Number of changes or added components Complexity Cost Schedule : - Architecture (n) Fall 2002 CS-545-Fall-2002

SAAM: Assess Scenario Interactions
High interaction between use cases shows low separation of concerns in the scenario or the architecture. The Higher the interaction between use cases typically the higher the defects. Highlights architecture decomposition and documentation inadequacies Fall 2002 CS-545-Fall-2002

Attribute Based Architectural Style (ABAS)
ABASs provide a foundation for more precise reasoning about architectural design by explicitly associating a reasoning framework (whether qualitative or quantitative) with an architectural style. These reasoning frameworks are based on quality attribute-specific models, which exist in the various quality attribute communities (such as the performance and reliability communities). Architectural styles provide a designer with the concentrated wisdom of many preceding designers faced with similar problems. ABASs provide the groundwork to create an engineering discipline of architectural design--to make design a predictable process rather than an ad hoc one. Fall 2002 CS-545-Fall-2002

Attribute-Based Architectural Style
Attribute-Based Architectural Styles (ABASs) are architecture patterns that can be used as building blocks for designing software architectures. ABASs build on architectural styles by explicitly associating a reasoning framework (whether qualitative or quantitative) with an architectural style. ABASs allow an architect to reuse the collected wisdom of the architecture design community … as design patterns have given …. designers access to a vast array of experience in the object-oriented design community. Linking analytic models (styles of reasoning) to architectural styles allows an architect to reuse the collected wisdom of the various attribute communities. (The) emphasis on analysis (by) ABASs … leads to a more precise understanding of the impact of architectural decisions on achieving quality attribute requirements. Fall 2002 CS-545-Fall-2002

ABAS in Practice Approach … Pros …. Cons … Issues …. Fall 2002
Be Prepared to discuss Section 3. Of the reference Approach … Pros …. Cons … Issues …. Fall 2002 CS-545-Fall-2002

ARID: Active Reviews for Intermediate Designs
Paul Clements, et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN X Toward Deriving Software Architectures From Quality Attributes Goal: Ensure Architecture addresses its QA during development Address units of completeness Address suitability of the design Preparation Identify reviewers Prepare the design briefing Prepare the seed scenarios Prepare the materials Review. Present ARID Present the Design Brainstorm the scenarios Apply the scenarios Summarize Fall 2002 CS-545-Fall-2002

SNA: Survivable Network Analysis Method
System Definition: The characteristics of the system that make it vulnerable to attack Define the essential: Services: those that must be maintained while under attack Assets: those to which we must maintain integrity based on their Quality Attributes and failure consequences. Define the components of the architecture most likely to be effected by an intrusion Perform Survivability Analysis Ability to recognize an attack ? Ability to repel the attack ? Ability to maintain essential services during attack, limit the damage, and restore full services following the attack. Fall 2002 CS-545-Fall-2002

Week 9 Design Space Analysis
Quality Function Deployment

Architectural Design Guidance
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Morisawa et. Al. Architectural Styles for Distributed Processing Systems and Practical Selection Method, Elsevier, Information and Software Technology, 44 (2002), , So How do I evaluate all these architectural alternatives ? Guidance for Architectures Design Space & Rules A multi-dimension design space that classifies the system architecture”. Choose some dimension that reflects requirements or evaluation criteria, while other dimensions reflect structure.” Or better …yet see the examples of spider charts from the references Attribute (1) Attribute (n) Required Actual Determine the Attributes in the Design Space Determine the Values of the Attributes Is the contained area meaningful to the selection? Do the attributes represent cost to fix ?, a delta cost, a delta-performance, a performance/cost ratio ? Fall 2002 CS-545-Fall-2002

Design Space Analysis Required Actual
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Morisawa et. Al. Architectural Styles for Distributed Processing Systems and Practical Selection Method, Elsevier, Information and Software Technology, 44 (2002), , Determine the Attributes in the Design Space Memory Size Available, Vs Required ? Throughput required vs Available ? Or are the a combination of a Functional Vs Structural Design Dimension? Determine the Values of the Attributes Are values simple scalar quantities? Is a higher number Better, Faster? Do the numbers represent the inherent capability over the required capability ? Do the numbers represent the cost to fix or upgrade to meet the required capability Is the contained area meaningful to the selection? What is the Cost to Fix ? Often an Attributes is the Delta-Cost to fix the System to meet the Requirements over the planned cost of the system. Your text echoes similar concerns over defining a design space If you want to be able to compare the Required Area that defines the attributes, vs Actual Area defined by the product, then the values of the attributes must be similar (ie. cost planned vs cost to obtain). Attribute (1) Attribute (n) Required Actual Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Interactive Behavior User Customizability High: Do we need to add new and update commands at run-time? Medium: Do we need to modify UI details but not semantics? Low: Is little or no UI customizability is required? User Interface Adaptability None: Are all aspects of behavior the same across all supported devices? Local Behavior Changes Only: Are the only changes local to the type of deployment (Windows vs Motif) ? Global Behavior Change: Are their major changes to the basic interface classes Basic Interactive Behavior Menu Selection: (context dependent menus?) Form Filling: (forms presented with default or last used values?) Command Language: (macro availability?) Natural Language: (~3000 grammar rules for English, requires syntactic, lexical, and discourse analysis in order to know who is doing what to whom, when, and why so ambiguity resolution may be impractical for all but structured English sentences. Direct Manipulation: (Does the program require direct manipulation of the data as it executes?) Application Semantics: Based on the Application, the user interface must react differently (e.g. continuous update and display of variables (push), vs on demand (pull). Discuss the different levels of architecture complexity Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Practical Considerations Computer System Organization Uni-processing: Will only one application run at a time? Better yet, what do I require vs what am I getting and how do I rank the differences? Multi-Processing: Will multiple applications execute concurrently? Distributed Processing: Is there a distributed computing environment? Application portability (See also the Other ISO Quality Attributes) High: Are applications required to be portable across different styles If the answer is YES and your architecture does not allow it then your architecture will not score high in this category. Medium: Are applications required to be independent of minor variations? If the answer is NO, but your application already allows it to be very portable, then you need to decide if this added capability is a good thing (for example to meet expected expansion later down the line), or if you do not care about this inherent capability. Low: Is it acceptable for the application to be changed when modifying the user interface? Note: The differences presented in class vs. your book. How you phrase the question of “Portability” and the Other Quality Attributes affects how you compare one design against another! Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Structural Considerations Division of functions and Knowledge among the modules Module decomposition Module Interfaces Module internal data Representation of the issues Data representation within the system (remember our ontology example) Meta data (explicit vs implicit) Control, communication, and synchronization. Issues related to dynamic behavior and interaction with the data. Discuss the different levels of architecture complexity as it relates to your project Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Division of functions and Knowledge among the modules Monolithic Programs No separation between application specific and shared code. Experience ha shown that is never really a good idea, regardless of the code size Even for video games Always create classes or structures that give you an API to the devices. HW Registers, register operations. Etc. Abstract Device: Always stage the data… Always be in control of every CPU cycle!! Update all the data, then draw the updates. This allows tight control over the computing actions, i.e. screen updates. (Very easy to do even in Windows and is especially required for real-time video update programs) (Go back to BB example) Discuss the different levels of architecture complexity as it relates to your project Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Toolkit: Shared Code: need to watch threading issues. Is the library code re-entrant? Interaction Manager with fixed data types: Use the Abstract device approach to ensure separation between internal and external representations Interaction Manager with extensible data types Ability to specify the I/O conversions. This is very similar to being able to define the formatting string for a specific data item. I.e. “%f5.2” Actually you really want to do this regardless of the data type. Some data types may display themselves as different bitmap (even moving) images (not just numbers) as a function of their value Extensible Interaction manager This is likened to sending text that describes a button and its state between machines. Discuss the different levels of architecture complexity as it relates to your project Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Abstract Device Variability “We view the device interface as an abstract device for the device-independent code to manipulate. The design space classifies the abstract devices according to the degree of variability perceived by the device-dependent code.” Ideal Device: Ideal vs As close as practical ? Parameterized Device: See Windows and X Device with Variable Operations: Direct manipulation not well supported Ad-Hoc Device: Need to develop an API to achieve portability Discuss the different levels of architecture complexity as it relates to your project Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Representation Issues Implicit in shared user shared user-interface code Supports strong user-interface conventions Implicit in Application Code External Declarative Notation: An external grammar table External Procedural Notation: User accessible procedural mechanism like emacs and zmacs. Internal Declarative Notation: Discuss the different levels of architecture complexity as it relates to your project Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Control Flow, Communication, and Synchronization Issues Basis of Communication is a communication dimension: “This dimension classifies the systems according to whether communication between modules depends upon shared state, events, or both” Events: Pure State: State with Hints: State plus Events: Control-Thread Mechanism is a control dimension Discuss the different levels of architecture complexity as it relates to your project Fall 2002 CS-545-Fall-2002

Control Flow, Communication, and Synchronization Issues Basis of Communication is a communication dimension Control-Thread Mechanism is a control dimension None: Standard Process: Lightweight Processes: Non-Preemptive Processes: Event Handlers: Interrupt-Service Routines: Discuss the different levels of architecture complexity as it relates to your project Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 A Design Space for UI Architectures Functional vs Structural Dimensional Considerations We will generalize to any architecture, reorganize slightly, and focus on the quality attributes Functional Dimensions External requirements (Addresses the requirements particular to an application, users, I/O, and constraints) External event Handling Are we required to not handle external events ? Are we required to process Events while waiting for Input ? External Events expected to preempt user commands ? Interactive Behavior Practical Considerations Discuss the different levels of architecture complexity Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Design Rules for UI Architectures See Book Applying the Design Space A Validation Experiment How the Design Space was prepared See Book.. How is the design space impacted by all the other ISO quality attributes? Summary Yes.. We really do work from design requirements to completed design in several steps.. We don’t go just hack it up and see what works.! Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Studying Software Architectures through Design Spaces and Rules, CMU/SEI-90-TR-18 The Quantified Design Space Overview The dilemma: Formal specification languages allow designers to make assertions about a design but there is still no tool for systematic and quantitative analysis of designs.” Remember the first day of class ? We raised the question …How does one really assess a design ? “A key part of the design space approach is to choose some dimensions that reflect requirements or evaluation criteria (function and/or performance), while other dimensions reflect structure (or other available design choices). Then, any correlations found between these dimensions can provide direct design guidance: they show which design choices are most likely to meet the functional requirements for a new system.” Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Studying Software Architectures through Design Spaces and Rules, CMU/SEI-90-TR-18 Background The QFD is based on two concepts, the design space and the quality function deployment. Design Space Dimensions: A multi-dimensional design space classifies a system’s architecture. Each dimension of a design space describes variation in one system characteristic or design choice. Values along a dimension correspond to alternative requirements or design choices. I.e. response times, means of inter-process synchronization (e.g., messages or semaphores). A specific system design corresponds to a point in the design space, identified by the dimensional values that correspond to its characteristics and structure. Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Studying Software Architectures through Design Spaces and Rules, CMU/SEI-90-TR-18 Design Space Rules : Be careful.. Weight assignments are subjective and to assign subjective measures to subjective rules can have serious consequences. I have found it better to use some information theoretical approach to combine the evidence for a given architecture using the taxonomy of the design space rules using something like Dempster-Shafer (See Shortliffe Paper). This allows us to assemble both positive and negative influences for an architecture in the same taxonomy. We could also use the approach suggested by Wolfgang Spohn in ranking the plausibility (actually the implausibility) of one architecture alternative over another. Rules must be broken down into relationships (define the correlations) between alternatives of different dimensions. See the real-world approach later in the lessons. Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Studying Software Architectures through Design Spaces and Rules, CMU/SEI-90-TR-18 Metrics for design Space Exploration of Heterogeneous Multiprocessor Embedded Systems: QFD: “The voice of the customer must be maintained at each step of the product development process” Use the use case description form and approach I gave you as a start to capture the design issues, notes, and assumptions. The description of the operation of the architecture through the use case will be constrained by the physical configuration of the end-item product. Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Developing the Design Space with Design Space Analysis QFD Process: (We will compare the book’s approach against recent published papers) Establish the scope of the architecture being developed (Rows): not as easy as it sounds especially if your system has to interoperate with another system that requires modification to work with yours. Include the Quality Attributes !!!!, not just functionality !!! Identify the (Potential) Realization Mechanisms (Columns) Create a matrix of customer requirements to realization mechanisms : (See book example) Establish Target Values for each realization mechanism Note the need to be Objectively Verifiable! Not their location on the Matrix. Design Space rules can be captured in these values Establish the Relationship (row/column correlation strength) between each (potential) mechanism and the customer need. (Identify) the mechanism which (we believe) are most important to achieving customer needs. (note the use by the author to use Strong, Medium, Weak relationship indicators) Design Space rules can be captured in these relationship and correlations values Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Developing the Design Space with Design Space Analysis Identify any positive or negative correlation between the realization mechanisms. Note that by themselves, a realization mechanism my be favored over another, but when used in conjunction with each other may not provide the best set of realizations. Design Space rules can be captured in these relationship and correlations values (See the DBMS vs. ASCII Text File realization comparisons) Implementation Difficulty of each realization is also recorded in the matrix. Design Space rules can be captured in these values Technical Importance rating of each customer need is also recorded in the matrix. Matrix Analyzed and the “best” realizations are selected for the next level of decomposition Fall 2002 CS-545-Fall-2002

QFD Example: House of Quality
Correlations H Realization Mechanisms Customer Requirements Importance Arch Style Variant (1) Variant (n) Implementation Difficulty (not considered in calc) 10 2 Req A 5 H (6) (30) M (4) (20) Req B 6 L (3) (18) H (6) (36) : Objective Target Values Absolute Technical Importance 48 56 Relative Technical Importance 1 Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Quantified Design Space A way of presenting design trade study and the rationale for selecting a design. Organizes the choices available for a particular design into a hierarchy of dimensions and realization alternatives. First correlate Requirements, to Realizations to Functional Dimensions See table on pg. 121 of your book Concepts Priority Functional Dimension #1 (HW-SW-People) Functional Dimension # (n) Realization Alt #1 Realization Alt # (:) Realization Alt #(n) Alt #1 Alt # (:) Realization Alt #(n) Req. #1 10 1 9 2 : Req. #(n) 3 4 Total Weight 19 93 20 Req #1 90 Req. #(:) Req #(n) 12 Realization Design Decision - Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Then correlate functional dimension alternatives to structural dimension alternatives: We could also break out the results by Requirement (which best combination of functional and structural dimensions best suits a given requirement) Concepts Alternatives Structural Dimension #1 (Patterns) Structural Dimension # (n) (Patterns) Dimensions Weight Alt #1 Alt # (:) Alt #(n) Functional Dimension #1 Alt (1) 1 : Alt (n) 100 Functional Dimension (n) 50 3 4 Calculated Weights 19 93 20 Req #1 10 90 Req. #(:) Req #(n) 9 12 Realization Design Decision - Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Conclusion Additional correlation functions can be developed and then use a statistical analysis method for selecting the best alternatives. Spectrum Analysis: Measures the overall goodness of a set of design decisions. Note the use of both CONFORMING and DISCONFORMING measures. Contribution Analysis: Identifies the degree to which a system can be improved if the design choice in the ith dimension is changes to the best choice.. Therefore the dimensions with the largest contribution indices are the best candidates for improvement. Design Selection Analysis: Computes the number of dimensions where a particular system implements the best design choices. Direct Comparison Analysis: Compares two sets of design choices to determine the amount by which one is an improvement over another. See the next series of charts to examine a real-world approach to Design Space Analysis. !!! Fall 2002 CS-545-Fall-2002

Developing an Architecture
Arriving at an Architecture T. Korson and J.D. McGregor. Understanding Object-Oriented: A Unifying Paradigm. Communications of the ACM, September 1990. W. M. Tepfenhart and J. J. Cusick, "A Unified Object Topology", IEEE Software, January 1997, pp J. O. Coplien, "Idioms and Patterns as Architectural Literature", IEEE Software, January 1997, pp R. T. Monroe, A. K. Kompanek, R. Melton, and D. Garlan, "Architectural Styles, Design Patterns, and Objects", IEEE Software, January 1997, pp N. L. Kerth and W. Cunningham, "Using Patterns to Improve Our Architectural Vision", IEEE Software, January 1997, pp S. Shlaer and S. J. Mellor, "Recursive Design of an Application-Independent Architecture", IEEE Software, January 1997, pp P. Oreizy, N. Medvidovic, R. N. Taylor, and D. S. Rosenblum, "Software Architecture and Component Technologies: Bridging the Gap", Workshop on Compositional Software Architectures, December 7, 1997 Fall 2002 CS-545-Fall-2002

Week 9-10 Design Analysis Space in Practice
CS-545 Week 9-10 Design Analysis Space in Practice

Design Space Analysis in Practice
An Example of the components of a design space using the QOC notation Option (1) Criteria (1) Question Option (2) Criteria (n) “This representation of a design space provides the rationale for the design by placing it in a broader context which highlights how it might be different and why it is the way it is.” “(This) representation …supports communication between people with different backgrounds and goals, …between the original designers and designers of a later generation system who want to re-use parts of the original design, and even between the designers and users ….” Fall 2002 CS-545-Fall-2002

Developing the Design Space (*) Use Questions to Generate Options Use Options to Generate Questions Use Options to Generate Criteria Consider Distinctive Options Look for Novel Combinations of Options Represent Both Positive And Negative Criteria Overcome Negative, But Maintain Positive, Criteria Design to a Set of Criteria Search for Generic Questions (*) QFD: The voice of the customer must be maintained at each step of the product development process” Do not forget to look for architecturally significant operations, states, modes, and their transitions in developing Architecture Alternatives. Iterative Do not forget to consider a local vs. distributed homogeneous vs. distributed heterogeneous system view. Do not forget to consider Functional, Data, Control Architectures and the impact of fault-tolerance. Fall 2002 CS-545-Fall-2002

D. Scuito et. Al, Metrics for Design Space Exploration of Heterogeneous Multiprocessor Embedded Systems, ACM. This research focused on developing a measure of an affinity of functionality towards a specific type of processing element (GPP, DSP, ASIC, FPGA) In other words this piece of the architecture prefers itself to execute on a GPP, or DSP or ASIC or FPGA for the following reasons…. “The affinity A(n) … of a method (m) is a triplet of values over the interval [0,1] that provides a quantification of the matching between structural and functional features of the functionality implemented by the method and the architectural features for each one of the considered executor classes (GPP, DSP, ASIC, FPGA) “ Why is “Affinity” important to this domain? What is architecturally significant about the way the author has approached this particular problem. Fall 2002 CS-545-Fall-2002

Design Space Analysis Data Oriented Metrics: Structural Metrics:
D. Scuito et. Al, Metrics for Design Space Exploration of Heterogeneous Multiprocessor Embedded Systems, ACM. Data Oriented Metrics: Data Ratio: Ratio of number of one of the data types to the number of another data type. This is an odd one (but a really good one) .. Do you know why is this important to this particular domain ? Structural Metrics: Control Flow Complexity: For each method, this metric defines the ratio between the number of source lines of code that contain loops or branches and the total number of SLOC. Do you know why is this important to this particular domain ? Loop Ratio: For each method, this metric defines the ration between the number of SLOCs that contain loop statements and the total number of SLOCs Fall 2002 CS-545-Fall-2002

Design Space Analysis DSP Oriented Metrics:
D. Scuito et. Al, Metrics for Design Space Exploration of Heterogeneous Multiprocessor Embedded Systems, ACM. DSP Oriented Metrics: The goal is to identify the function suitable for execution by a DSP and therefore consider those issues that exploit the DSP architectural features of such an executor class. Circular Buffering: Identify subsets of code that access a linear data structure(one dimensional array, row, or column of a bi-dimensional array) What does this metric give us insight into ? MAC Operations: Identify subsets of the operations that express a particular instruction mix Super Harvard Architecture: Identify subsets of the architecture to exploit concurrent memory accesses to instructions and data Notice that the approach considers both CONFIRMING and DISCONFIRMING measurements !!! Fall 2002 CS-545-Fall-2002

DSP Oriented Metrics MAC Metrics: Harvard Metrics:
D. Scuito et. Al, Metrics for Design Space Exploration of Heterogeneous Multiprocessor Embedded Systems, ACM. Circularity Metrics: Strong Circularity degree: The ratio between the number of SLOC that contain vector add or subtraction and the total SLOCs Weak Circularity degree: The ratio between the number of SLOC that contain vector or scalar multiply and the total SLOCs MAC Metrics: Strong MAC degree: The ratio between the number of SLOC inside a loop that contain scalar add or subtraction and the total SLOCs Weak MAC degree: The ratio between the number of SLOC outside a loop that contain scalar add or subtraction and the total SLOCs Harvard Metrics: Strong Harvard degree: The ratio of SLOC that contain, inside a loop, expressions with the following structure v[I] op w[I] or q op w[I] and the total number of lines where v & w are vectors and op is an operator different from “=“. Weak Harvard degree: The ratio of SLOC that contain, outside a loop, expressions with the following structure v[I] op w[I] or q op w[I] and the total number of lines where v & w are vectors and op is an operator different from “=“. Fall 2002 CS-545-Fall-2002

GPP Oriented Metrics GPP Oriented Metrics: Conditional Ratio:
D. Scuito et. Al, Metrics for Design Space Exploration of Heterogeneous Multiprocessor Embedded Systems, ACM. GPP Oriented Metrics: The goal is to identify the functions that significantly rely on operations that involve conditional dependent control flows, complex data structures, and complex I/O management. Conditional Ratio: CR = the CFC – LR CFC: Control Flow Complexity LR: Loop Ratio What does this metric give us insight into ? I/O Ratio: IOR is the ratio between the number of SLOC that contain I/O operations and the total number of lines. Structure Ratio: The ration between the number of structures declared and the total number of declarations Fall 2002 CS-545-Fall-2002

ASIC Oriented Metrics ASIC Oriented Metrics:
D. Scuito et. Al, Metrics for Design Space Exploration of Heterogeneous Multiprocessor Embedded Systems, ACM. ASIC Oriented Metrics: The goal is to identify the functions that significantly rely on operations that involve bit manipulations. Bit manipulation Rate: The ration between the number of SLOC that contain bit manipulation operations (AND, OR, XOR ..) and the total number of SLOC. Fall 2002 CS-545-Fall-2002

Putting It All Together
D. Scuito et. Al, Metrics for Design Space Exploration of Heterogeneous Multiprocessor Embedded Systems, ACM. Affinity: The affinity towards a GPP depends on: I/O Ratio, Conditional Ratio, Structure Ratio The affinity towards a DSP depends on: Degree of Circularity, Harvard, MAC, the Loop Ratio and the number of declared variables of DSP compatible built-in types. The affinity towards an ASIC depends on: The Loop ratios, the Bit Manipulation Ratio and the number of bit types. See the authors definition of measuring the affinity and the validation approach ! Fall 2002 CS-545-Fall-2002

Week 10 Formal Models & Specifications
CS-545 Week 10 Formal Models & Specifications

Formal Models & Specifications
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 The Value of Architecture Formalisms Specifying the Architecture of a system Describe the value of doing so? Specifying an Architectural Style Specifying a Theory of Software Architecture Provide a deductive basis for Specifying the Formal Semantics for Architecture Description Languages Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Formalizing the Architecture of a Specific System How should one best communicate the functional architecture ? Transformations and interconnections What about data processing sequences ? How should one best communicate the data architecture ? As an OO data model (?) … What about physical deployment issues and data distribution issues ? How should one best communicate the control architecture ? Internal vs. External Events ? How should one best communicate the fault-tolerant approach? Fall 2002 CS-545-Fall-2002

Formalizing the Architecture of a Specific System
The formal specification notation Z (pronounced "zed"), useful for describing computer-based systems, is based on Zermelo-Fraenkel set theory and first order predicate logic. It has been developed by the Programming Research Group (PRG) at the Oxford University Computing Laboratory (OUCL) and elsewhere since the late 1970s, inspired by Jean-Raymond Abrial's seminal work. See the section in your notes “Architecture Formal Methods\Z Notation” Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Formalizing an Architecture Style Problems with “Z” (1) The underlying architectural style is NOT expressed explicitly and must be inferred and therefore opens up questions in the realization of a design. (2) The high level abstraction avoids many design issues: What are the Functional, Data, and Control Architectures (topologies) !!! (3) Architectural Connection is Implicit: How are the components to be connected ? How do we reason about the above topologies (architectures) independent of the system specification ? Therefore, we need to EXPLICITLY formalize an Architecture Style. Fall 2002 CS-545-Fall-2002

Formalizing an Architecture Style
Notice the combination of “Z” and a MIL to define an Architecture Style in your text. Roz: The Production of formal Z specifications from annotated UML diagrams “RoZ automatically generates the Z schemas skeletons corresponding to a UML class diagram. To have a complete Z specification, you must add information like the definition of the type of the attributes and the constraints on the class diagram. In the Rational Rose tool, each concept is complemented by a specification form to express additional information. We use these forms to express constraints, pre and post-conditions of operations etc. Constraints are written in the Z latex syntax in (the) "Documentation" fields of forms.” Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Formalizing an Architecture Design Space Remember from the fist data in class we wanted to formalize the description of an architecture so that we could share results So what is the language of an architecture ? Expand on the notion of using “Z” and a MIL to also include a set of events and a set of methods. Benefits (see your text) Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 T.R. Dean and J.R. Cody, A Syntactic Theory of Software Architecture, IEEE Transactions on Software Engineering, Vol. 21, No. 4, April 1995. P Inverardi and Alexander L. Wolf, “Formal Specification and Analysis of Software Architecture Using the Chemical Abstract Machine Model, IEEE Transactions on Software Engineering, VOL 21, No. 4, April 1995. Toward a Theory of Software Architecture ? So….How should we define Components ? So….How should we define Connectors ? So….How should we define Control ? So….How should we define Events ? So….How should we define State ? So….How should we define Decomposition ? What mechanisms allow us to describe an Architecture and reason about an architecture ? Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 P Inverardi and Alexander L. Wolf, “Formal Specification and Analysis of Software Architecture Using the Chemical Abstract Machine Model, IEEE Transactions on Software Engineering, VOL 21, No. 4, April 1995. What’ next Note the path of history from “Z” to where we are today. Note the concerns with building a real-system. Performance, cost, accuracy, … etc and the Quality Attributes Will any of the mechanisms to date allow us to address these issues in the same way in which we are addressing functionality, events, etc? Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 P Inverardi and Alexander L. Wolf, “Formal Specification and Analysis of Software Architecture Using the Chemical Abstract Machine Model, IEEE Transactions on Software Engineering, VOL 21, No. 4, April 1995. It would therefore seem natural for us to want to extend the formal specification techniques and generalize them to allow: Development of abstract concepts in conjunction with the concrete functional architecture Why is this important ? Degrees of Precision in the Architecture Specification Formal analysis when practical. If it is exits, then it is Platonic and can be described. However, this is often harder than it sounds. Extension of the tried and true techniques to address new ideas and approaches to architectural specification. Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Z Notation Used in this Chapter. See for everything you ever think wanted to know about “Z”, (and then some) I have downloaded the Z Reference Manual and the PDF Power point slides for your use. Fall 2002 CS-545-Fall-2002

Formal Methods in Practice
CS-545 Formal Methods in Practice

P Inverardi and Alexander L. Wolf, “Formal Specification and Analysis of Software Architecture Using the Chemical Abstract Machine Model, IEEE Transactions on Software Engineering, VOL 21, No. 4, April 1995. A Specifier’s Introduction to Formal Methods, Computer Seven Myths of Formal Methods, IEEE Software State-Based Model Checking of Event-Driven System Requirements, IEEE Inconsistency Handling in Multi-perspective Specifications, IEEE Approach … Pros …. Cons … Issues …. Fall 2002 CS-545-Fall-2002

Abstract Model Examples Algebraic Specifications Axiomatic Specification States and Finite State Machines Concurrency Time and temporal relationships Fall 2002 CS-545-Fall-2002

Formal Specification and Analysis
G. Abowd, R. Allen, and D. Garlan, "Using Style to Understand Descriptions of Software Architecture", Proceedings of the ACM SIGSOFT'93 Symposium on Foundations on Software Engineering, Redondo Beach, CA, Software Engineering Notes, December 1993, pp. 9-20 G. Abowd, R. Allen, and D. Garlan, Formalizing Style to Understand Descriptions of Software Architecture, Technical Report, CMU-CS , Carnegie Mellon University, School of Computer Science, January 1995 Robert J. Allen, David Garlan, and James Ivers, Formal Modeling and Analysis of the HLA Component Integration Standard, Proceedings of the Sixth International Symposium on the Foundations of Software Engineering (FSE-6), November 1998 R. Allen and D. Garlan, "A Formal Basis for Architectural Connection", ACM Transactions on Software Engineering and Methodology, Vol. 6, No. 3, July 1997, pp ACM TOSEM Vol. 7, No. 3, July 1998, pp J. Magee, "Behavioral analysis of software architectures using LTSA", Proceedings of ICSE '99, Los Angeles, CA, May 16-22, 1999, pp R. T. Monroe, "Modeling and Analyzing Software Architectures", Proceedings of ICSE '99, Los Angeles, CA, May 16-22, 1999, pp Nenad Medvidovic, Formal definition of the Chiron-2 software architectural style, Technical Report UCI-ICS-95-24, Department of Information and Computer Science, University of California, Irvine, August 1995. N. Medvidovic, R.N. Taylor, and Jr. E. J. Whitehead, "Formal Modeling of Software Architectures at Multiple Levels of Abstraction", Proceedings of California Software Symposium, Los Angeles, April 1996, pp M. Shaw and D. Garlan, "Formulations and Formalisms in Software Architecture", LNCS, Vol. 1000, Springer-Verlag, 1995, pp Fall 2002 CS-545-Fall-2002

Domain Specific Architectures
Domain-Specific Software Architectures (DSSA) D. Batory, L. Coglianese, S. Shafer, and W. Tracz, "The ADAGE Avionics Reference Architecture", Proceedings of AIAA Computing in Aerospace 10, San Antonio, 1995 B. Hayes-Roth, K. Pfleger, P. Lalanda, P. Morignot, and M. Balabanovic, "A Domain-Specific Software Architecture for Adaptive Intelligent Systems", IEEE Transactions on Software Engineering, Vol. 21, No. 4, April 1995, pp W. Griswold and D. Notkin, "Architectural Tradeoffs for a Meaning-Preserving Program Restructuring Tool", IEEE Transactions on Software Engineering, Vol. 21, No. 4, April 1995, pp Pam Binns, Matt Englehart, Mike Jackson, and Steve Vestal. "Domain-Specific Software Architectures for Guidance, Navigation, and Control", Honeywell Technology Center, 1993 S. Vestal, MetaH Programmer's Manual, Version 1.09, Technical Report, Honeywell Technology Center, April 1996 Fall 2002 CS-545-Fall-2002

Formal Specification and Analysis
G. Abowd, R. Allen, and D. Garlan, "Using Style to Understand Descriptions of Software Architecture", Proceedings of the ACM SIGSOFT'93 Symposium on Foundations on Software Engineering, Redondo Beach, CA, Software Engineering Notes, December 1993, pp. 9-20 G. Abowd, R. Allen, and D. Garlan, Formalizing Style to Understand Descriptions of Software Architecture, Technical Report, CMU-CS , Carnegie Mellon University, School of Computer Science, January 1995 Robert J. Allen, David Garlan, and James Ivers, Formal Modeling and Analysis of the HLA Component Integration Standard, Proceedings of the Sixth International Symposium on the Foundations of Software Engineering (FSE-6), November 1998 R. Allen and D. Garlan, "A Formal Basis for Architectural Connection", ACM Transactions on Software Engineering and Methodology, Vol. 6, No. 3, July 1997, pp ACM TOSEM Vol. 7, No. 3, July 1998, pp ) J. Magee, "Behavioral analysis of software architectures using LTSA", Proceedings of ICSE '99, Los Angeles, CA, May 16-22, 1999, pp R. T. Monroe, "Modeling and Analyzing Software Architectures", Proceedings of ICSE '99, Los Angeles, CA, May 16-22, 1999, pp Nenad Medvidovic, Formal definition of the Chiron-2 software architectural style, Technical Report UCI-ICS-95-24, Department of Information and Computer Science, University of California, Irvine, August 1995. N. Medvidovic, R.N. Taylor, and Jr. E. J. Whitehead, "Formal Modeling of Software Architectures at Multiple Levels of Abstraction", Proceedings of California Software Symposium, Los Angeles, April 1996, pp P. Inverardi and A. L. Wolf, "Formal Specification and Analysis of Software Architecture Using the Chemical Abstract Machine Model, IEEE Transactions on Software Engineering, Vol. 21, No. 4, April 1995 M. Shaw and D. Garlan, "Formulations and Formalisms in Software Architecture", LNCS, Vol. 1000, Springer-Verlag, 1995, pp Fall 2002 CS-545-Fall-2002

Architecture Patterns & Styles
Implicit Invocation J. Dingel, D. Garlan, S. Jha, and D. Notkin, "Towards a Formal Treatment of Implicit Invocation" Proceedings of the 1997 Formal Methods Europe Conference, 1997 D. Garlan, G. E. Kaiser, and D. Notkin, "Using Tool Abstraction to Compose Systems", IEEE Computer, Vol. 25, No. 6, June 1992 D. Garlan and C. Scott, "Adding Implicit Invocation to Traditional Programming Languages", Proceedings of the 15th. Int'l Conference on Software Engineering, Baltimore, MD, May 1993, pp D. Garlan, S. Jha, D. Notkin, and J. Dingel, "Reasoning about Implicit Invocation", Proceedings of ACM SIGSOFT 6th. International Symposium on Foundations on Software Engineering, Florida, November 3-5, 1998, pp D. Notkin, D. Garlan, W. G. Griswold, and K. Sullivan, "Adding Implicit Invocation To Languages: Three Approaches" K. Sullivan and D. Notkin, "Reconciling Environment Integration and Software Evolution", ACM Transactions on Software Engineering and Methodology, Vol. 1, No. 3, July 1992, pp Communicating Processes G. R. Andrews, "Paradigms for Process Interaction in Distributed Systems", ACM Computing Surveys, Vol. 23, No. 1, March 1991, pp Fall 2002 CS-545-Fall-2002

Architecture Patterns & Styles
Real-Time Process Control B. Selic, "Recursive Control", Proceedings of PLoP '96 Writers Workshops, Pattern Languages of Program Design 3 (PLoPD3), Edited by R. Martin, D. Riehle and F. Buschmann. Addison-Wesley, Chapter 24, pp M. Shaw, "Beyond objects: A software design paradigm based on process control", ACM Software Engineering Notes, Vol. 20, No. 1, January 1995, pp Finite State Machines B. P. Douglass, "UML Statecharts", A White Paper, Embedded Systems Programming, January 1999 B. P. Douglass, "State Machines and Statecharts", A White Paper, Embedded Systems Conference West, 1999 Fall 2002 CS-545-Fall-2002

Week 11 Architecture Description Languages
CS-545 Week 11 Architecture Description Languages

Module Interconnect Languages
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Need an alternative to module interfaces to describe module interconnections See MIL75, Intercol Still deficient as they use name bindings and only low level primitives are supported. The System UI Functions.. DBMS WS (1) WS (…) WS (n) Fall 2002 CS-545-Fall-2002

Module Interconnect Languages
MILs do not attempt to do the following: Load compiled images. This function is left to a separate facility within the development environment. Define system function. A MIL defines only the structure, not the function, of a system. Provide type specifications. A MIL is concerned with showing or identifying the separate paths of communication between modules. Syntactic checks along these communications paths may be performed by a MIL, but because MILs are independent of the language chosen to implement the modules they reference, such type checking will be limited to simple syntactic- not semantic- compatibility. Define embedded link-edit instructions. Recently, MILs have been extended with notions of communication protocols and with constructs for defining semantic properties of system function. These extended MILs are referred to as Architecture Description Languages (ADLs). Fall 2002 CS-545-Fall-2002

Architecture Description Languages
1. We will go over some recent references to ADLs in general then the references for specific ADLs. 2. We review the key concepts from the book. 3. We review the key concepts from the SEI. 4. We review, compare, and contrast two ADL approaches: SADL (Stanford) SADL (UCI) Meta-H (SAE & Honeywell) 5. Finally we look at current work in ADLs. Fall 2002 CS-545-Fall-2002

ADL: Classification and Comparison
Paul Clements, A Survey of Architecture Description Languages Eighth Intl. Workshop in Software Specification and Design, Paderborn, Germany, March 1996 Neno Medvidovic, "A Classification and Comparison Framework for Software Architecture Description Languages", Technical Report UCI-ICS-97-02, Department of Information and Computer Science, University of California, Irvine, February 1997 Nenad Medvidovic and David S. Rosenblum, "Domains of Concern in Software Architectures and Architecture Description Languages.", In Proceedings of the USENIX Conference on Domain-Specific Languages, Santa Barbara, CA, October 15-17, 1997, pp Nenad Medvidovic and Richard N. Taylor, "A Classification and Comparison Framework for Software Architecture Description Languages", IEEE Transactions on Software Engineering, Vol. 26, No. 1, January 2000, pp Nenad Medvidovic and Richard N. Taylor, "A Framework for Classifying and Comparing Architecture Description Languages", In Proceedings of the Sixth European Software Engineering Conference together with Fifth ACM SIGSOFT Symposium on the Foundations of Software Engineering, pages 60-76, Zurich, Switzerland, September 22-25, 1997 Fall 2002 CS-545-Fall-2002

ADL: Classification and Comparison
Jason E. Robbins, Nenad Medvidovic, David F. Redmiles, and David S. Rosenblum, "Integrating Architecture Description Languages with a Standard Design Method", Presented at the Second EDCS Cross Cluster Meeting in Austin, Texas S. Vestal, A Cursory Overview and Comparison of Four Architecture Description Languages, Technical Report, Honeywell Technology Center, February 1993 T. R. Dean and J. R. Cordy, "A Syntactic Theory of Software Architecture", IEEE Transactions on Software Engineering, Vol. 21, No. 4, April 1995, pp D. Le Metayer, "Describing Software Architecture Styles Using Graph Grammar", IEEE Transactions on Software Engineering, Vol. 24, No. 7, July 1998, pp R. Kazman, P. Clements, L. Bass, G. Abowd, "Classifying Architectural Elements as a Foundation for Mechanism Matching," Proceedings of COMPSAC, Washington, D.C., August 1997, pp Fall 2002 CS-545-Fall-2002

ADLs & Environments ACME Aesop AML
D. Garlan, R. Monroe, and D. Wile, "Acme: An Architecture Description Interchange Language", Proceedings of CASCON'97, Nov. 1997, pp D.Garlan and Z. Wang, "A Case Study in Software Architecture Interchange", Submitted for publication, March 1998 Aesop R. Melton, The Aesop System: A Tutorial, The ABLE Project, School of Computer Science, Carnegie Mellon University D. Garlan, R. Allen, and J. Ockerbloom, "Exploiting Style in Architectural Design Environments", Proceedings of SIGSOFT '94 Symposium on the Foundations of Software Engineering, December 1994 R. T. Monroe and D. Garlan, "Style Based Reuse for Software Architecture", Proceedings of the 1996 International Conference on Software Reuse, April 1996 R. T. Monroe, "Capturing Design Expertise in Customized Software Architecture Design Environments", Proceedings of the Second International Software Architecture Workshop, October 1996 AML D. Wile, AML: An Architecture Meta-Language. Proceedings of 14th International Conference on Automated Software Engineering (ASE¡¯99), Cocoa Beach, FL, October 1999 Fall 2002 CS-545-Fall-2002

Architecture Definition Languages
See for a list of ADLs. An architecture is generally considered to consist of components and the connectors (interactions) between them however we are inconsistent and informal in their use and therefore Architectural designs are often poorly understood and not amenable to formal analysis or simulation. (Remember.. How can I evaluate on Architecture over another?) Architectural design decisions are based more on default than on solid engineering principles. Architectural constraints assumed in the initial design are not enforced as the system evolves. Unfortunately there are few tools to help the architectural designers with their tasks. To address these problems, formal languages for representing and reasoning about software architecture have been developed. These languages, called architecture description languages (ADLs), seek to increase the understandability and reusability of architectural designs, and enable greater degrees of analysis. In contrast to Module Interconnection Languages (MILS), which only describe the structure of an implemented system, ADLs are used to define and model (the) system architecture prior to system implementation. Fall 2002 CS-545-Fall-2002

ADL Requirements Our Original Dilemma
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Our Original Dilemma When to pick our architecture over another ? Characteristics of Architectural Descriptions Common Patterns of Software Organization What do all these boxes and interconnecting lines really mean? Data flow ? Data dependencies?, Control ? , Functional dependencies ? Functional Sequences ?. States & Modes ? therefore we really do need a more precise way in which to capture and describe an architecture Examples of Common Components and Interconnections: Examples of Interactions between these components Critical Elements of a Design Language The Language Problem for Software Architecture Fall 2002 CS-545-Fall-2002

ADL Requirements Examples of Common Components and Interconnections
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Examples of Common Components and Interconnections Computation, Memory, Server, Controller, Link (Interfaces), (list others) Examples of Interactions between these components Procedure Call, Data Flow, Message Passing, Shared Data, .. (list Others) Note that components and interactions are evident across all the architecture styles and their variants. The good thing .. A common set of primitives (Abstract concepts in an earlier lecture). Critical Elements of a Design Language The Language Problem for Software Architecture Fall 2002 CS-545-Fall-2002

ADL Requirements Critical Elements of a Design Language
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Critical Elements of a Design Language Components: Primitive elements and their values (give examples) Operators: Functions that combine Components Abstraction: Naming rules for components and operators Closure: Rules that determine which abstractions can be added to the classes of components and operators Specification: Association of semantics with syntactic forms. Fall 2002 CS-545-Fall-2002

ADL Requirements The Language Problem for Software Architecture
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 The Language Problem for Software Architecture Note: SWA deals with the overall allocation of functions to components, with data and interface connectivity and overall system balance (task allocation, file allocation, dead-lock recovery, fault-tolerance, etc….) Do conventional programming languages support this ? Does UML support this ? Does “Z” support this ? So where do we go from here ? So we need a way to allow us to combine the components, operations, interfaces etc into an ARCHITECTURE. So then why not just use Ada, and CORBA, … etc.? So where do programming languages fit in the scheme of things ? Fall 2002 CS-545-Fall-2002

ADL Requirements An ADL therefore must:
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 An ADL therefore must: Support the description of components and their interactions Why ? Handle large-scale, high-level designs Why? Support Translation of Design to a Realization Support user-defined or application Specific Abstractions Support the Disciplined selection of architectural styles. Fall 2002 CS-545-Fall-2002

ADL Requirements Composition:
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Composition: “It should be possible to describe a system as a composition of independent components and connections” This allows us to combine independent elements into larger systems (this is really critical in Network centric independent systems that demonstrate new emergent capabilities when combined together) An ADL therefore: Must allow the hierarchical decomposition of and assembly of a system. Final Decomposed elements must be independent (stand-alone) pieces in their own right. Must be able to separate architectural design approach from realization approach. Note: the ADL closure rule must allow us to view entities of an architectural description as primitive at one level and as composite structures at a lower level of decomposition. Why is this important ? Fall 2002 CS-545-Fall-2002

ADL Requirements Abstraction:
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Abstraction: “It should be possible to describe the components and their interactions within the software architecture in a way that clearly and explicitly describes their abstract roles in a system” This property will allow us to describe explicitly the kind of architectural elements used and the relationships between the elements Note the contrast with high level programming languages vs ADL. For example: It should be possible to describe an architecture without having to relay on implicit coding conventions or unstated assumptions about the intended realization. (Remember how benign ACME looks) Note: It should be able to indicate explicitly that components are related via a Client-Server relationship (regardless of how they might be implemented) NOT implicitly by looking at lower level IDL or procedure calls. For example I could implement a C-S relationship in “C”. But you would not know that we have C-S relationship unless you went digging through the low level code.) We want to get away from the code and IDL level. (those are implementation realization, not abstract roles. Ie. We want to be at the Client module and a Server Module level. Service based Architecture ? Fall 2002 CS-545-Fall-2002

ADL Requirements Reusability:
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Reusability: “It should be possible to reuse components, connectors, and architectural patterns in different architectural descriptions, even if they were developed outside the context of the system” This property will allow us to describe families of architectures as an open-ended collection of architectural elements, together with constraints on the structure and semantics. These Architectural patterns require further instantiation of substructure and indefinite replication of relations. See the GOF book. Note that programming languages permit reuse of individual components, FEW make it possible to describe generic patterns of components and connectors. Programming languages provide module constructs only (Ada) few allow us to talk about collections of modules or structural patterns. For example a pipeline architecture uses pipes & filters AND also constrains the topology to be a linear sequence (but we cannot describe the topology). Fall 2002 CS-545-Fall-2002

ADL Requirements Configuration:
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Configuration: “Architectural Descriptions should localize the description of system structure independently of the elements being structured. They should also support dynamic reconfiguration.” This property allows us to understand and change the architectural structure of a system without having to examine each of the systems individual components. Therefore an ADL should separate the description of composite structures from the elements in these compositions so that we can reason about the composition as a whole. See the comment on dynamic architectures in your text. Fall 2002 CS-545-Fall-2002

ADL Requirements Heterogeneity:
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Heterogeneity: “It should be possible to combine multiple, heterogeneous architectural descriptions” This property will allow us to: Combine single combined different architectural patterns into a single system. Combine components written in different languages (marshaling). Module connection systems that support interaction between distinct address spaces often provide this capability (see book examples) Fall 2002 CS-545-Fall-2002

ADL Requirements Analysis:
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Analysis: “It should be possible to perform rich and varied analyses of architectural descriptions” Note that current module connection languages (Ada) provide only weak support for analysis. (only type checking at component boundaries) Note how JINI has started to address the issue of event broadcast. Need to associate an specification with an architecture as they become relevant to a particular components, connections, and patterns. Fall 2002 CS-545-Fall-2002

Problems with Existing Languages
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Informal Diagrams Programming Language Modularization Facilities Module Interconnect Languages Support for Alternative Kinds of Interaction Specialized Notation for Certain Architectural Styles Fall 2002 CS-545-Fall-2002

Informal Diagrams Informal diagrams are used to express many ideas:
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Informal diagrams are used to express many ideas: the boxes can represent anything from components to functions, the interconnections are equally vague at identifying the interaction they were meant to convey. Data flow? , Control Flow? , Event Handling? Inheritance ? , etc. Note that although they intuitively convey the architecture, they are limited in the use for analysis The System UI Functions.. DBMS WS (1) WS (…) WS (n) Fall 2002 CS-545-Fall-2002

Issues with Programming Language Modularization Facilities
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 This approach uses a programming language (PL) modularization facilities to convey the description of the architecture. These languages are based on the notion that modules define an interface that declares: Exports: The services the module provides Imports: the Services on which it relies Issues: Composition: PL provide poor support for the independent composition of architectural elements Inter-module connection is determined by name matching. Good for PL but poor for AD. Naming Exports and Imports forces interconnection structure to be embedded in the module definitions. Consequently, modules can rarely be REUSED in another system for which they were not designed. Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Abstraction: PL represent module interfaces as a collection of independent procedures, data with types and possibly constraints. The result is that the High Level Architecture has to be described in these low level implementation primitives of the PL. Usually the interconnection is also limited to data sharing or procedure calls. So how do we capture the other types of interconnections such as pipes, message passing, etc. Simplicity of the ability to describe an interconnection therefore has both positive and negative effects. For programming, we know the types, However we do not have the freedom to describe the system interactions not can we describe the architectural components (services) Forces the designer to think in only the terms of the PL primitive constructs Limits reusability as one set of interconnections may not be valid for another architecture Limits the level of abstraction that can be used to describe interconnections. Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Consequence of Abstraction: A MAJOR part of the design, (the interconnection) between modules at the ARCHITECURE level is therefore buried in procedure calls and shared data access, is distributed across the modules, and difficult to change because of module inter-dependencies. Reuse: Modules explicitly declare their exports and imports, they do NOT declare the export and import REQUIREMENTS. Note that module definitions ONLY supports the reuse of the module. There is NO support for reuse of the patterns of composition. The System UI Functions.. DBMS WS (1) WS (…) WS (n) Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Configuration: The requirements of modules to define EXPORTS and IMPORTS leads to a condition where the connectivity of the architecture is distributed throughout the module definitions. Makefiles are the only single place where Connectivity dependencies are visible. Note that we only get a notion of the dependency NOT the nature of the dependency or design intention. Also the declarations of EXPORTS and IMPORTS is STATIC. There is no notion of dynamic reconfiguration. The System UI Functions.. DBMS WS (1) WS (…) WS (n) Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Heterogeneity: Modules written in different languages cannot (generally) be combined or require the use of special purpose middleware (Actually the approach DEC took to their language interface easily allowed Fortran to call PL/I to call C … etc. (on the same machine). Due to the limited number of abstract primitives we can only describe the interactions in the low level primitives available. So we do NOT have a way in which to express architectural paradigms, let alone combined them. The System UI Functions.. DBMS WS (1) WS (…) WS (n) Fall 2002 CS-545-Fall-2002

Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Analysis: Given a set of modules – What is the Architecture ? The current approach of name matching (modules and EXPORTS and IMPORTS) makes it difficult to check for consistency of interconnection. Name matching DOES NOT assure proper use !! The System UI Functions.. DBMS WS (1) WS (…) WS (n) Fall 2002 CS-545-Fall-2002

Problems With Current Approaches to AD
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996 Inability to Localize Information about Interactions Poor Abstraction Mechanisms Lack of Structure on Interface Definition Programming Language Specifications Support for Components with Incompatible Packaging Support for Multi-Language or Multi-Paradigm Systems Support for Legacy Systems Fall 2002 CS-545-Fall-2002

SEI: Architecture Definition Languages
ADLs address more than system structure (components and connectors): Component behavioral specification. Unlike MILs, ADLs are concerned with component functionality. ADLs provide support for specifying both functional and non-functional characteristics of components. (Non-functional requirements include those associated with safety, security, reliability, and performance.) Depending on the ADL, timing constraints, properties of component inputs and outputs, and data accuracy may all be specified. ADLs can be viewed as extended MILs in that ADLs augment the structural information of a MIL with information about communication protocols and system behavior. Fall 2002 CS-545-Fall-2002

Component protocol specification. Some ADLs, such as Wright and Rapide support the specification of relatively complex component communication protocols. Other ADLs, such as UniCon allow the type of a component to be specified (e.g., filter, process, etc.) which in turn restricts the type of connector that can be used with it. Connector specification. ADLs contain structures for specifying properties of connectors, where connectors are used to define interactions between components. In Rapide, connector specifications take the form of partially-ordered event sequences In Wright, connector specifications are expressed using Hoare's Communicating Sequential Processes (CSP) language Fall 2002 CS-545-Fall-2002

As an example, consider the component shown below. Component Simple is Type in_type is … Type out_type is … Op f : in_type -> out_type Op valid_input? : in_type -> Boolean : This component defines two data types, two operations (op), and an input and an output communication port. The component also includes specifications constraining the behavior of its two operations. A protocol specification for this component, written in CSP, defines how it interacts with its environment. Specifically, component Simple will accept a data value x of type in_type on its input port, and, if the data value is valid, will output f(x) on its output port. If the data value is not valid, Simple will output an error message on its output port. Note that component Simple is a specification, not an implementation. Implementations of ADL components and connectors are expressed in traditional programming languages such as Ada or C. Fall 2002 CS-545-Fall-2002

Usage Considerations ADLs were developed to address a need that arose from programming in the large; they are well-suited for representing the architecture of a system or family of systems. Because of this emphasis, several changes to current system development practices may occur: Training. ADLs are formal, compilable languages that support one or more architectural styles. Developers will need training to understand and use ADL technology and architectural concepts/styles effectively (e.g., the use of dataflow, layered, or blackboard architectural styles). Facilities for associating implementations with ADL entities vary between ADLs. Change/emphasis in life-cycle phases. The paradigm currently used for system development and maintenance may be affected. Specifically, architectural design and analysis will precede code development; results of analysis may be used to alter system architecture. As such, a growing role for ADLs is expected in evaluating competing proposed systems during acquisitions. An ADL specification should provide a good basis for programming activities. Fall 2002 CS-545-Fall-2002

Documentation. Because the structure of a software system can be explicitly represented in an ADL specification, separate documentation describing software structure is not necessary. This implies that if ADLs are used to define system structure, the architectural documentation of a given system will not become out of date. ADLs document system properties in a formal and rigorous way. These formal characterizations can be used to analyze system properties statically and dynamically. For example, dynamic simulation of Rapide specifications can be analyzed by automated tools to identify such things as communication bottlenecks and constraint violations. Further, these formal characterizations provide information that can be used to guide reuse. Expanding scope of architecture. ADLs are not limited to describing the software architecture; application to system architecture (to include hardware, software, and people) is also a significant opportunity. Fall 2002 CS-545-Fall-2002

Maturity Several ADLs have been defined and implemented that support a variety of architectural styles, including Aesop supports the specification and analysis of architectural styles (formal characterizations of common architectures such as pipe and filters, and client-server). Rapide uses event posets to specify component interfaces and component interaction. Wright supports the specification and analysis of communication protocols MetaH was developed for the real-time avionics domain LILEAnna, is designed for use with Ada and generalizes Ada's notion of generics. UniCon, addresses packaging and functional issues associated with components . Further information about these and other languages used to describe software architectures can be found in the Software Architecture Technology Guide and Architectural Description Languages. Note … there is little evidence in the published literature of successful commercial application. However, Rapide and UniCon have been used on various problems MetaH appears to be in use in a commercial setting. ADLs often have graphical tools that are similar to CASE tools. Fall 2002 CS-545-Fall-2002

Costs and Limitations The lack of a common semantic model coupled with differing design goals for various ADLs complicates the ability to share tool suites between them. Researchers are addressing this problem; an ADL called ACME is being developed with the goal that it will serve as an architecture interchange language. Some ADLs, such as MetaH, are domain-specific. In addition, support for asynchronous versus synchronous communication protocols varies between ADLs, as does the ability to express complex component interactions. Dependencies Simulation technology is required by those ADLs supporting event-based protocol specification. Fall 2002 CS-545-Fall-2002

Alternatives The alternatives to ADLs include: Module Interconnection Languages (which only represent the defacto structure of a system) Object-oriented CASE tools, and Various ad-hoc techniques for representing and reasoning about system architecture. Another alternative is the use of VHSIC Hardware Description Language (VHDL) tools. VHDL is often thought of exclusively as a hardware description language, its modularization and communication protocol modeling capabilities are very similar to the ones under development for use in ADLs. Fall 2002 CS-545-Fall-2002

SADL: Structural Architecture Description Language
TR-SRI-CSL-97-01 SADL (Stanford): A Language for Specifying Software Architecture Hierarchies Sadl is programming language independent, intended for both abstract and concrete modeling of system architectures. The Sadl language provides a precise textual notation for describing software architectures while retaining the intuitive boxandarrow model. (Sadl) makes a clean distinction between several kinds of architectural objects (e.g., components and connectors) and make explicit their intended uses. The Sadl language provides facilities for specifying architectures and for also specifying wellformed ness constraints on particular classes of architectures. For example, it is possible to specify not only the kinds of components and connections in, clientserver and blackboard systems, but also the intended configurations of the components and connections. Sadl can be used to describe the architecture of a specific system or a family of systems. Fall 2002 CS-545-Fall-2002

TR-SRI-CSL-97-01 A vertical hierarchy serves to bridge the gap between abstractions in architectures and the more primitive structural concepts in conventional programming languages. Each level in a vertical hierarchy typically is described using a different vocabulary, reflecting a change in representation. For example, a pipeandfilter architecture would be described using a different vocabulary than an eventbased architecture. A horizontal hierarchy is analogous to ``bubble decomposition'' in dataflow modeling, where the same vocabulary is used to describe every level in the decomposition. Fall 2002 CS-545-Fall-2002

TR-SRI-CSL-97-01 The Sadl language is intended to be used in describing both vertical and horizontal hierarchy and in relating different levels of representation by means of mappings. They also make it possible to reason about the relationship among architectures in a hierarchy and the relation between the hierarchy and its implementation. For example, we can determine whether the architectural objects in one architecture are present in the other even if there is a change in representation. We also can show that, if a particular communication path is not allowed in one architecture, it is not allowed in others in the hierarchy. An architecture hierarchy may describe a specific system or a family of systems. Fall 2002 CS-545-Fall-2002

TR-SRI-CSL-97-01 Sadl can be used to represent the following architectural elements. 1. Architecture. An architecture is a, possibly parameterized, collection of the following items. (a) Component. A component represents a locus of computation or a data store. The various types of components include a module, process, procedure, or variable. A component has a name, a type (a subtype of type COMPONENT), and an interface, the ports of the component. A port is a logical point of interaction between a component and its environment. A port has a name, a type, and is designated for input or output. Fall 2002 CS-545-Fall-2002

TR-SRI-CSL-97-01 (b) Connector. A connector is a typed object (a subtype of type CONNECTOR) relating ports. Every connector is required to accept values of a given type on one end and to produce output values of the same type on the other. (c) Configuration. A configuration constrains the wiring of components and connectors into an architecture. A configuration can contain two kinds of elements. Connections. A connection associates typecompatible connectors and ports. Constraints. Constraints are used to relate named objects or to place semantic restrictions on how they can be related in an architecture. Fall 2002 CS-545-Fall-2002

TR-SRI-CSL-97-01 Mapping. A mapping is a relation that defines a syntactical interpretation from the language of an abstract architecture to the language of a concrete architecture. Architectural style. A style consists of a vocabulary of design elements, well formed-ness constraints that determine how they can be used, any semantic constraints needed for refinement, and a logical definition of the semantics of the connectors associated with the style. A constraint is declarative and might say, for example, that clients initiate communication with servers, but not vice versa. A given architecture may be homogeneous, involving one style, or heterogeneous, involving multiple styles. Fall 2002 CS-545-Fall-2002

TR-SRI-CSL-97-01 Refinement pattern. A refinement pattern consists of two architecture schemas, an association of the objects in the two schemas, and possibly constraints on one or both schemas. An instance of a pattern is formed by matching schema variables against the appropriate portions of Sadl specifications. Components, interfaces, connectors, and constraints: Are treated as firstclass objects --- i.e., they are named and typed objects that can appear as parameters. They can be refined into (decomposed, aggregated, or eliminated) objects in more concrete architectures. Fall 2002 CS-545-Fall-2002

UCI SADL C2 SADL (pronounced "saddle") is the language for defining architectures built according to the C2 style. C2 SADL draws its influences from the strengths and shortcomings of existing ADLs. It is currently only a prototype language and its needed support tools are under construction. C2 SADL consists of three parts: IDN - interface definition notation, which supports specification of C2 component interfaces. ADN - architecture description notation, which allows declarative specification of C2 architectures. ACN - architecture construction notation, which contains features for expressing architecture changes imperatively. The ACN is mostly used for expressing dynamic architecture changes. Fall 2002 CS-545-Fall-2002

UCI SADL : IDN component StackADT is interface top_domain in null; out
component StackADT is interface top_domain in null; out bottom_domain PushElement (value : stack_type); PopElement (); GetTopElement (); ElementPushed (value : stack_type); ElementPopped (value : stack_type); TopStackElement (value : stack_type); StackEmpty (); parameters methods procedure Push (value : stack_type); function Pop () return stack_type; function Top () return stack_type; function IsEmpty () return boolean; behavior received_messages PushElement; invoke_methods Push; always_generate ElementPushed; received_messages PopElement; invoke_methods IsEmpty, Pop; always_generate StackEmpty xor ElementPopped; received_messages GetTopElement; invoke_methods IsEmpty, Top; always_generate StackEmpty xor TopStackElement; context top_most ADT end StackADT; Fall 2002 CS-545-Fall-2002

UCI SADL: ADN connector BottomConnector connections top_ports
architecture StackVisualizationArchitecture is components top_most StackADT; internal StackVisualization1; StackVisualization2; bottom_most GraphicsServer; connectors connector TopConnector is message_filter no_filtering end TopConnector; connector BottomConnector is end BottomConnector; architectural_topology connector TopConnector connections top_ports bottom_ports connector BottomConnector connections top_ports StackVisualization1; StackVisualization2; bottom_ports GraphicsServer; end StackVisualizationArchitecture; system StackVisualizationSystem is architecture StackVisualizationArchitecture with StackADT is_bound_to IntegerStack; StackVisualization1 is_bound_to StackArtist1; StackVisualization2 is_bound_to StackArtist2; GraphicsServer is_bound_to C2GraphicsBinding; end StackVisualizationSystem; Fall 2002 CS-545-Fall-2002

UCI SADL: ACN Modifying the Simple Stack Architecture
Modifying the Simple Stack Architecture Adding a New Stack Artist StackVisualizationArchitecture.add(NewStackVisualization); StackVisualizationArchitecture.weld(TopConnector, NewStackVisualization); StackVisualizationArchitecture.weld(NewStackVisualization, BottomConnector); StackVisualizationSystem.bind(NewStackVisualization, StackArtist3); Temporarily Removing an Existing Stack Artist TopConnector.SetTopPortFilter(StackVisualization1, message_sink); BottomConnector.SetBottomPortFilter(StackVisualization1, message_sink); Physically Removing an Existing Stack Artist StackVisualizationArchitecture.remove(StackVisualization1); StackVisualizationArchitecture.unweld(TopConnector, StackVisualization1); StackVisualizationArchitecture.unweld(StackVisualization1, BottomConnector); Fall 2002 CS-545-Fall-2002

The SAE, Meta-H and UML See UML Profile for AADL (Meta-H)
See UML Profile for AADL (Meta-H) See Rich Hilliard, Using the UML for Architectural Description (paper and slides) See html/Logical View/Meta Model/Main Fall 2002 CS-545-Fall-2002

CS-545 Week 13 Connectors

Middleware References
E. M. Dashofy et al. Using Off-the-Shelf Middleware to Implement Connectors in Distributed Software Architectures. 21st International Conference on Software Engineering, Los Angeles, CA, May 1999. R. Natarajan and D. S. Rosenblum. "Merging Component Models and Architectural Styles", Third International Software Architecture Workshop, Nov. 1998 Sun Microsystems, Inc. Java Beans 1.01 Specification Microsoft Corporation. The Component Object Model: Technical Overview. (on-line reference) Microsoft Corporation. DCOM Technical Overview. (on-line reference) Sun Microsystems, Inc. Java Beans Specification. (on-line reference) Sun Microsystems, Inc. Enterprise Java Beans Specification. (on-line reference) S. P. Reiss. Connecting Tools Using Message Passing in the Field Environment. IEEE Software, July 1990. Fall 2002 CS-545-Fall-2002

Mil References Prieto-Diaz, Ruben & Neighbors, James. "Module Interconnection Languages." Journal of Systems and Software 6, 4 (1986): Tichy, W. F. "Software Development Control Based on Module Interconnection," Proceedings of the 4th International Conference on Software Engineering. Munich, Germany, September 17-19, New York, NY: IEEE Computer Society Press, 1979. Cooprider, Lee W. The Representation of Families of Software Systems (CMU-CS ). Pittsburgh, PA: Computer Science Department, Carnegie Mellon University, 1979. Garlan, David & Allen, Robert. "Formalizing Architectural Connection," Proceedings of the 16th International Conference on Software Engineering. Sorrento, Italy, May 16-21, Los Alamitos, CA: IEEE Computer Society Press, 1994. Geschke, C.; Morris, J.; & Satterthwaite, E. "Early Experience with MESA." Communications of the ACM 20, 8 (August 1977): Mitchell, J.; Maybury, W.; & Sweet, R. MESA Language Manual (CSL-79-3). Palo Alto, CA: Xerox Palo Alto Research Center, April 1979. Tracz, W. "LILEANNA: a Parameterized Programming Language," Proceedings of the Second International Workshop on Software Reuse. Lucca, Italy, March 24-26, Los Alamitos, CA: IEEE Computer Society Press, 1993. Z and, M., et al. "An Interconnection Language for Reuse at the Template/Module Level." Journal of Systems and Software 23, 1 (October 1993): 9-26. Purtillo and Atlee,"Module Reuse by Interface Adaptation," Software-Practice and Experience, Vol.21 No. 6, June 1991, pages Fall 2002 CS-545-Fall-2002

Week 14 Dynamisms in Architectures
CS-545 Week 14 Dynamisms in Architectures

Dynamism in SA P. Oreizy et al. Architecture-Based Runtime Software Evolution. 20th International Conference on Software Engineering, Kyoto, Japan, April 1998. Fall 2002 CS-545-Fall-2002

Week 15 From Architecture to Design From Design to Implementation
CS-545 Week 15 From Architecture to Design From Design to Implementation

From Architecture to Design
D. Krieger and R.M. Adler. The Emergence of Distributed Component Platforms. IEEE Computer, March 1998. E. Di Nitto and D. S. Rosenblum. Exploiting ADLs to Specify Architectural Styles Induced by Middleware Infrastructures. 21st International Conference on Software Engineering, Los Angeles, CA, May 1999. Fall 2002 CS-545-Fall-2002

Project Notebook Outline Homework Reading Assignments
CS-545 Project Notebook Outline Homework Reading Assignments

Project Outline Cover Page Readings: Homework: Project: Midterm
Name (picture might help) Readings: Organized by week Homework: Quality Attribute Tree considerations for each architecture level. Project: 24 use cases Midterm Your comments: What did you like ? What did you dislike? How would you improve the course? Fall 2002 CS-545-Fall-2002

Deleted Homework Homework 1: Definitions of basic concepts
Gauges your understanding of the basic software engineering concepts and your perception of several software architecture terms and concepts. Homework 2: Case study system architecture Requires you to provide and analyze an architectural breakdown for the system described in the case study. Homework 3: Example system architecture and implementation Requires you to provide an architectural description of the software system from Homework 2. Homework 4: Example system implementation Requires you to provide a partial implementation of the architecture from Homework 3. Homework 5: Example of system implementation using a standard middleware solution Requires you to provide a partial implementation for the application from Homework 3 using a standard, third-party middleware solution. Fall 2002 CS-545-Fall-2002

Timely Copyrighted Papers
Weekly Readings Adapted from: and from And from other Timely Copyrighted Papers

Copyright 2001 Carnegie Mellon University
Week 1 Readings Adapted from: D. E. Perry and A. L. Wolf. Foundations for the Study of Software Architectures. ACM SIGSOFT Software Engineering Notes, October 1992. (in your packet) DeRemer and Kron (1976): Programming-in-the-Large Versus Programming-in-the-Small Prieto-Diaz and Neighbors (1986): “Module Interconnection Languages”. D. Perry and A. Wolf, “Foundations for the Study of Software Architectures”, ACM B. Boehm, and W. Scherlis, “ Mega programming”, What is the difference between routine and innovative design? Give an example of each within the arena of software development. How do engineering disciplines evolve? In discussing MIL75, both references mention that dealing with "external scope" is an important objective of the language. Explain external scope, identify the elements of the MIL universe" with which it is concerned, and provide a specific reason why it is useful. Fall 2002 CS-545-Fall-2002 Copyright 2001 Carnegie Mellon University

Week 2 Readings Adapted from: How Architecture Wins Technology Wars. Harvard Business Review, 71, 2, March-April 1993, pp Formulations and Formalisms in Software Architecture. Computer Science Today: Recent Trends and Developments ACME: An Architecture Description of Component-Based Systems, Foundations of Component-Based Systems How to Solve It: A New Aspect of Mathematical Methods. Princeton University Press 1973. What is the framework used by your text book to describe architectural styles? That is, what structure do they impose on answers to a question such as “what’s this architecture?” List the seven core types of entities in ACME, and say briefly what each represents. What does Morris and Ferguson mean by an “open proprietary architectural standard”? Isn’t this a contradiction in terms? List two examples of open proprietary products, and two examples of products that aren’t. What two kinds of problems does Polya identify? What are four methods are commonly used by architects to build systems? Fall 2002 CS-545-Fall-2002 Copyright 2001 Carnegie Mellon University

Week 3 Readings Adapted from: Architectural Blueprints, The 4+1 View Model of Software Architecture Ref The Art of Systems Architecting A Comedy of Errors: the London Ambulance Service case study" How do you reason about the functionality of pure pipe-and-filter systems? For example, if filter f with input stream x delivers the output stream f(x), what does the following compute? Why? When should you seriously consider using the process control paradigm to organize a software system (or part of one)? Give at least one specific example. How can the activity of a filter be triggered? After having reviewed the documentation of the NASA subsystem, list (a) three things about the documentation that are good, and (b) five things that could be improved. Bonus question: Produce a good C&C (component & connector) graphical view of the DMS (Data Management Subsystem) and also of its context diagram. Extra bonus: Produce an Acme version of these two views. Fall 2002 CS-545-Fall-2002 Copyright 2001 Carnegie Mellon University

Week 4 Readings Adapted from: Software Requirements & Specifications Software Architecture Documentation in Practice Build the Documentation Package Release 6A Segment/Design Specification for the ECS Project, Section 4.4. NASA Report 305-CD , pages March 2001. Case Study: An Early Exploitation of Product Lines P. Krutchen, “The Software Architect”, ICSE (in your packet) Why do the various authors of these papers suggest that you should use multiple views? Which of Kruchten's views comes closest to what we've been terming "architecture"—namely components and connectors? Does Kruchten's model accommodate styles? Explain why or why not. List 5 "principles of good architectural documentation" that you've been able to extract from the readings. Rank these in order of importance. Fall 2002 CS-545-Fall-2002 Copyright 2001 Carnegie Mellon University

Week 5 Readings Adapted from: Best Current Practices: Software Architecture Validation. AT&T Report ADS Architecture: Executive Summary Software Architecture in Industrial Applications Documenting Software Architectures: Recommendations for Industrial Practice. Carnegie Mellon University, School of Computer Science, CMU-CS On the Criteria To Be Used in Decomposing Systems Into Modules (in your packet) What information hiding principle, as realized by Parnas, Clements, and Weiss’ module decomposition, determines how much an interface should change? Looking at Parnas’ KWIC example from an architectural perspective, with what quality attribute(s) was Parnas most concerned? Can an object (in the architectural sense) have multiple interfaces? Is such a feature desirable? What kinds of changes are difficult for an object-oriented system to handle? How did the use of objects and software architectural renderings complement one another in the GHB paper. Fall 2002 CS-545-Fall-2002 Copyright 2001 Carnegie Mellon University

Week 6 Readings Adapted from: A New Approach to Functional and Software Structure for Engine Management Systems - BOSCH ME7 The Modular Structure of Complex Systems (in your packet) Component Software: Beyond Object-Oriented Programming A Model for Distributed System Services Using Style to Understand Descriptions of Software Architecture (In your packet) P. Inverardi, and A. Worf, “Formal Specification and Anslysis of Software Architectures Using the Chemical Abstract Machine Model”, IEEE Transactions Viewed as architectural styles, how do each of CORBA, DCOM, and JavaBeans elaborate (or constrain) the more general object-oriented style discussed in class lectures. Sketch at least three similarities and three differences between the three. (You may want to use a table to do this.) Suppose an architect is trying to decide which to use. Provide a list of questions that you could ask that would allow you to determine which choice is better for that person's design. When is middleware NOT appropriate? Fall 2002 CS-545-Fall-2002 Copyright 2001 Carnegie Mellon University

Week 7 Readings Adapted from: Software Architecture and Object Oriented Systems The Unified Modeling Language Reference Manual Reconciling the Needs of Architectural Description with Object-Modeling Notations Using Tool Abstraction to Compose Systems C. Gacek, et al. “Composing Components: How does One Detect Potential Architectural Mismatches” (in your packet) Parnas advocates the use of information hiding and ADTs. What are the essential differences between architectural styles based on abstract data types or objects and the one advocated by Garlan, Kaiser and Notkin? What are the tradeoffs in using one over the other? Suppose someone told you they were using implicit invocation, except that by convention there is always exactly one recipient of each event. And further, the announcer of the event expects a return event from the receiver carrying a result. Is this really implicit invocation? Why? Pick four dimensions along which Field and one of the language-based implementations (described in 7.3) differ, and briefly explain the differences? Fall 2002 CS-545-Fall-2002 Copyright 2001 Carnegie Mellon University

Week 8 Readings Adapted from: Connecting Tools Using Message Passing in the Field Environment. Formal Modeling and Analysis of the HLA Component Integration IEEE P1516/D1 Draft Standard [for] Modeling and Simulation (M&S), High Level Architecture (HLA) – Framework and Rules. RTI 2.0 Architecture What is the main function of the HLA? What are some of the services provided by the RTI? (Describe at the level of one or two sentences.) What is the FOM? What is its role in the HLA? Explain Rule 4 of the P1516 reading in structural (topological) terms: that is, what does its say about the connectivity of this architectural framework? Then explain why this rule is deemed important. What kinds of problems can a Wright specification of the HLA detect? Fall 2002 CS-545-Fall-2002 Copyright 2001 Carnegie Mellon University

Week 9 Readings Adapted from: Quality Attributes. Software Engineering Institute Technical Report, CMU/SEI-95-TR-021 The Architecture Tradeoff Analysis Method. Software Engineering Institute Technical Report, CMU/SEI-98-TR-008 M. Klein, R. Kazman, R. Nord, “A BASis (or ABASs) for Reasoning about Software Architectures”, (In packet) L. Davis, R.F. Gamble J. Payton, “The impact of component architectures on interoperability”, The Journalof Systems and Software, Vol 61, 2002, pgs 31-45 (in packet) J. Wang X. He, Y. Deng, “Introducing software architecture specification and analysis in SAM through an example”, Information and Software Technology, Vol 41, 1999, pgs The SEI Technical Report claims that systems often fail to meet user needs. In your own words discuss the author's reasons for making this claim. In your own words, discuss why is a structured tradeoff analysis method is useful? The ATAM process helps developers discover tradeoffs and sensitivity points. In the context of ATAM, what are tradeoffs and sensitivity points? 4. An author claims: For this reason, software architectures are often designed “in the dark”. Why does the author make this claim? Fall 2002 CS-545-Fall-2002 Copyright 2001 Carnegie Mellon University

Week 10 Readings Adapted from: Achieving Usability Through Software Architecture. Software Engineering Institute Technical Report. CMU/SEI-2001-TR-005. ATAM: Method for Architecture Evaluation. Software Engineering Institute Technical Report, CMU/SEI-2000-TR-004 The Architecture Tradeoff Analysis Method. Software Engineering Institute Technical Report, CMU/SEI-98-TR-008 Y. Morisawa, K. Inuone, . Torii, “Architectural styles for distributed processing systems and practical selection method” (in packet) The scenarios in these reports are all single user, desktop based scenario, except the for last paper. Discuss the most difficult aspects of your assigned quality attributes and how would you use the info in this last paper to refine your particular assigned attribute. Fall 2002 CS-545-Fall-2002 Copyright 2001 Carnegie Mellon University

Week 11 Readings Adapted from: Blackboard Systems. AI Magazine 7(3): and 7(4): Mediators in the Architecture of Future Information Systems. H. Penny Nii, “Black board systems at the Architecture Level”, Expert Systems with Applications (in your packet) In a few lines, describe the components of the blackboard model. In your own words, discuss the basic approach to problem solving in the blackboard framework. What distinction does Wiederhold make between data and knowledge? Briefly discuss the two major problems that Wiederhold predicted with computer information systems. Fall 2002 CS-545-Fall-2002 Copyright 2001 Carnegie Mellon University

Week 12 Readings J. Magee, J. Kramer, “Dynamic Structure in Software Architecture”:, ACM (in your packet) D. Luckman, J. Vera, “An Event Based Architecture Definition Language”, DARPA R. Fielding, R. Taylor, “Principled Design of the Modern Web Architecture” ACM R. Taylor and N Medvidovic, “A Component and Message Based Architectural Style for GUI Software”, D. Perry, “Generic Architecture Descriptions for Product Lines”, Bell Labs Based on these papers propose a starting viewpoint for any given architecture. Be sure to discuss components, connectors, events, data and control topologies and interactions, local and distributed system issues. Fall 2002 CS-545-Fall-2002

Week 13 Readings Adapted from: Schneider, P. Blueprint for Harmony. CIO.com, Sept Software Architecture: An Executive Overview, Software Engineering Institute Technical Report, CMU/SEI-96-TR-003, Feb 1996. Architecting Processes are Key to Software Quality UML Components: A Simple Process for Specifying Component-Based Software, Addison Wesley, 2001, Chapters 1and 2. Szyperski, C. Component Software: Beyond Object-Oriented Programming, Addison-Wesley, 1998, pp and Packaging and Deploying Predictable Assembly M. Moriconi, X. Qian, R. Riemenschneider, “Correct Architecture Refinement”, IEEE (in your packet) D. Batory and S. O’Malley, “ The Design and Implementation of Hierarchical Software Systems with Resubale Components”, ACM (in your packet) R. Fielding, “Software Architecture Styles for Network Based Applications”, UCI In each of the readings there is a description, characterization, or definition of what a software component is. In a few words, describe each and then briefly summarize the differences among them. Cheesman and Daniels talk different forms of components. Name these and list two reasons for making these distinctions. Name three types of dependencies that you think might emanate from a component specification and give a few words about why an architect might decide to set such a constraint. Cheesman and Daniels claim the development process must be subservient to the management process. Briefly describe each of these processes and say why Cheesman and Daniels believe this to be true. Fall 2002 CS-545-Fall-2002 Copyright 2001 Carnegie Mellon University

Week 14 Readings Adapted from: Three Tier Software Architectures. SEI, maint. Darleen Sadoski and Santiago Comella-Dorda, Feb 16, 2000. Microsoft Corporation. A Blueprint for Building Web Sites Using the Microsoft Windows Platform, Draft, Version .9. January 2000. Monica Pawlan. Introduction to the J2EE Platform, Mar 23, 2001. Component Object Model (COM), DCOM, and Related Capabilities. SEI, maint. Santiago Comella-Dorda, Mar 13, 2001. A Framework for Classifying and Comparing Architectural Description Languages. Software Architecture: A Roadmap. The Future of Software Engineering. Compare and contrast the Microsoft DNA approach to building large scale, complex web-deployed applications with the J2EE approach. Identify three key similarities between the two approaches and three key differences. According to Shaw and Garlan, what are the six classes of properties that characterize what an ideal ADL would provide? What are the four essential modeling features in the Medvidovic and Taylor ADL comparison framework? According to “A Rodmap…”, what new architectural challenges are presented by the changing face of technology Fall 2002 CS-545-Fall-2002 Copyright 2001 Carnegie Mellon University

CS-545 References

Categories of References
Class Packaged References Primary Public References Reviewed Other References Reviewed Fall 2002 CS-545-Fall-2002

Class Packaged Papers Intro: Background:
(In Packet) M. Shaw and P. Clements. A Field Boxology: Preliminary Classification of Architectural Styles for Software Systems. April (Open Lit.) (In Packet) David Parnas, Paul Clements and David Weiss, “The Modular Structure of Complex Systems”, IEEE Transactions on Software Engineering, SE-11 (3). March 1985. Background: (In Packet) Frank DeRemer and Hans H. Kron, Programming in the large vs Programming in the Small, IEEE Transactions on Software Engineering, June, 1976 (In Packet) B. W. Boehm and W. L. Scherlis. Megaprogramming. Software Technology Conference 1992, Los Angeles, April 1992. (In Packet) Perry, Dewayne E. and Alexander L. Wolf, "Foundations for the study of software architecture," Software Engineering Notes, Vol. 17, No. 4, October 1992, pages Architecture Definition Languages (Open Source) N. Medvidovic. A Classification and Comparison Framework for Software Architecture Description Languages. Technical Report, UCI-ICS-97-02, University of California, Irvine, January 1997. (In Packet) D. C. Luckham and J. Vera. An Event-Based Architecture Definition Language. IEEE Transactions on Software Engineering, pages , September 1995. (Open Source) N. Medvidovic et al. A Language and Environment for Architecture-Based Software Development and Evolution. 21st International Conference on Software Engineering, Los Angeles, CA, May 1999. (Open Source) E. Di Nitto and D. Rosenblum, "Exploiting ADLs to Specify Architectural Styles Induced by Middleware Infrastructures" Proceedings of 21st. Int'l Conference on Software Engineering (ICSE 99), Los Angeles, CA, May 1999, pp Fall 2002 CS-545-Fall-2002

Class Packaged Papers Cont.
Architecture Development: (In Packet) D. Parnas, "On the Criteria To Be Used in Decomposing Systems into Modules", Communications of the ACM, 15(12), 1972, (In Packet) Inverardi, Paola and Alexander L. Wolf, Formal Specification and Analysis of Software Architectures Using the Chemical Abstract Machine Model. IEEE Transactions on Software Engineering 21(4), April To appear. Architecture to Design: (Open Source) N. Medvidovic et al. Modeling Software Architectures in the Unified Modeling Language. ACM Transactions on Software Engineering and Methodology, 2002. (Open Source) D. Garlan and A. J. Kompanek – Carnegie Melon University. Reconciling the needs of Architectural Description with Object-Modeling Notations. 3rd International Conference on The Unified Modeling Language (UML 2000), (In Packet) G. Abowd, R. Allen, and D. Garlan, "Using Style to Understand Descriptions of Software Architecture", Proceedings of the ACM SIGSOFT'93 Symposium on Foundations on Software Engineering, Redondo Beach, CA, Software Engineering Notes, December 1993, pp. 9-20 (In Packet) L. Davis, R.F. Gamble, and J. Payton, “The impact of component architectures on interoperability”, The Journal of Systems and Software Vol 61, pages Connectors & Middleware: (Open Source) N. R. Mehta et al. Towards a Taxonomy of Software Connectors. 22nd International Conference on Software Engineering, Limerick, Ireland, June 2000. (Open Source) E. M. Dashofy et al. Using Off-the-Shelf Middleware to Implement Connectors in Distributed Software Architectures. 21st International Conference on Software Engineering, Los Angeles, CA, May 1999. (Open Source) M. J. Maybee et al. Multilanguage Interoperability in Distributed Systems: Experience Report. 18th International Conference on Software Engineering, Berlin, Germany, March 1996. (Open Source) S. Vinoski. CORBA: Integrating Diverse Applications Within Distributed Heterogeneous Environments. IEEE Communications Magazine, February (Open Source) R. Natarajan and D. S. Rosenblum. Supporting Architectural Concerns in Component Interoperability Standards. IEEE Proceedings – Software, December 2000. Fall 2002 CS-545-Fall-2002

Architecture Evolution: (In Packet) J. Magee and J. Kramer. Dynamic Structure in Software Architectures. In Proceedings of ACM SIGSOFT'96: Fourth Symposium on the Foundations of Software Engineering (FSE4), pages 3-14, San Francisco, CA, October 1996. (Open Source) P. Oreizy, N. Medvidovic, R. N. Taylor, "Architecture-based Runtime Software Evolution", Proceedings of the Int'l Conference on Software Engineering (ICSE '98), April 1998, pp (In Packet) M. Moriconi, X. Qian, and R. A. Riemenschneider. Correct Architecture Refinement. IEEE Transactions on Software Engineering, pages , April 1995. Architecture Testing & Analysis: (Open Source) D. Garlan et al. Architectural Mismatch; Why its hard to Build Systems out of Existing Parts (In Packet) C. Gacek and B. W. Boehm. Composing Components: How Does One Detect Potential Architectural Mismatches? Workshop on Compositional Software Architectures, Monterey, CA, January 1998. (In Packet) J. Wang, X He, Y. Deng, “ Introducing software architecture specification and analysis in SAM through an example”, Information and Software Technology, Vol 41, pgs , 1999. (In Packet) Y. Morisawa, K. Inoue, and K. Torii, “Architectural Styles for distributed processing systems and practical selection method”, Information and Software Technology, Vol 44, pgs , 2002. (In Packet) M. Klein, R. Kazman, R. Nord, “A Basis for Reasoning about Software Architectures”, People & Teams: (In Packet) P. Kruchten. The Software Architect – and the Software Architecture Team. 1st Working IFIP Conference on Software Architectures, San Antonio, TX, February 1999 Fall 2002 CS-545-Fall-2002

Product Lines: (In Packet) D. E. Perry. Generic Descriptions for Product Line Architectures. 2nd International Workshop on Development and Evolution of Software Architectures for Product Families (ARES II), Las Palmas de Gran Canaria, Spain, February 1998 DSSA: (Open Source) R. Kazman, A Challenge for Software Architecture: Distributed Flight Simulation, in Parallel and Distributed Computing Handbook, A. Zomaya (ed.), McGraw-Hill, 1995, to appear. (Open Source) Call Center Customer Care (C4) System (In Packet) Software Architecture Styles for Network-Based Applications, University of California Irvine, Draft 1.1 , July 15, 1999 (In Packet) D. Batory and S. O'Malley. The Design and Implementation of Hierarchical Software Systems with Reusable Components. ACM Transactions on Software Engineering and Methodology, October 1992. R. N. Taylor et al. A Component- and Message-Based Architectural Style for GUI Software. IEEE Transactions on Software Engineering, June 1996. (In Packet) R. T. Fielding and R. N. Taylor. Principled Design of the Modern Web Architecture. 22nd International Conference on Software Engineering (ICSE 2000), Limerick, Ireland, June 2000. (In Packet) H. Penny Nii, “Blackboard Systems at the Architecture Level”, Expert Systems with Applications, Vol 7. Pp 43-54, 1994. Fall 2002 CS-545-Fall-2002

Primary Public References Reviewed
A Case Study in Architectural Modelling AEGIS A Case Study in Structural Modeling A Classification and Comparison Framework for Software Architecture Description Languages A Component- and Message-Based Architectural Style for GUI Software A Discipline of Software Architecture, ACM Interactions, A, 1,1 January 1994 A Design Space and Design Rules for User Interface Software Architectures, A Framework for Classifying and Comparing A Framework for Classifying and Comparing Architecture Description Languages A Recovery Model for Extended Real-Time Transactions IEEE A Software Architecture for Dependable and Evolvable Industrial Computing Systems A Survey of Architecture Description Languages A Type Theory for Software Architectures Fall 2002 CS-545-Fall-2002

Abstractions and Implementations for Architectural Connections Acme An Architecture Description Interchange Language ADLs and Dynamic Architecture Changes AML An Architecture Meta-Language An Architectural Analysis Case Study Internet Information Systems An Evaluation Theory Perspective of the Architectural Tradeoff Analysis Method Analyzing Software Architectures for Modifiability Applicability of General Scenarios to the Architecture Tradeoff Analysis Method Architectural Unification Architecture Based Development Architecture Based Design Method Architecture-Based Runtime Software Evolution Architecture Trade-Off Analyses of C4ISR Products Assessing the Suitability of a Standard Design Method for Modeling Software Architectures Attribute-Based Architecture Styles Fall 2002 CS-545-Fall-2002

Connectors in Software Architecture Deriving Test Plans from Architectural Descriptions ACM Domains of Concern in Software Architectures Exploiting Style in Architectural Design Environments Extending Design Environments to Software Architecture Design Features of Architecture Description Languages Formal Definition of the Chiron-2 Software Architectural Style Formal Modeling and Analysis of the HLA Component Integration Standard Formal Modeling of Software Architectures at Multiple Levels of Abstraction Formulations and Formalisms in Software Architecture From Domain Models to Architectures Fall 2002 CS-545-Fall-2002

Object Based Concurrent Programming in Distributed Artificial Intelligence Patterns for Software Architectures Quality Attribute Workshops Refinement of Pipe and Filter Architectures Reusing Off-the-Shelf Components to Develop a Family of Applications in the C2 Architectural Style SAAM A Method For Analyzing the Properties of Software Architectures Scenario Based Analysis of Software Architecture Software Architecture Foundation of a Software Component Marketplace Software Architecture Validation Software Synthesis via Domain Specific Architectures Some Patterns for Software Architectures Structural Modeling An Application Framework and Development Process For Flight Simulators Studying Software Architectures Through Design Spaces and Rules Stylized Architecture, Design Patterns, and Objects Fall 2002 CS-545-Fall-2002

The Architecture Tradeoff Analysis Method The Software Architecture Renaissance Tool Support for Architectural Analysis and Design Toward Deriving Software Architectures from Quality Attributes: Understanding Architectural Influences and Decisions in Large System Projects Using Critics to Analyze Evolving Architectures Using Explicit State to Describe Architectures Using Object-Oriented Typing to Support Architectural Design in the C2 Style Using Patterns to Integrate UML Views Using Style to Understand Descriptions of Software Architectures Using the Architectural Tradeoff Method to Evaluate a Wargame Simulation Study Visual Language Features Supporting Human-Human and Human-Computer Communication What is Style? Fall 2002 CS-545-Fall-2002

Other References Reviewed
Moriconi, Mark and Xiaolei Qian, "Correctness and Composition of Software Architectures," In Proceedings of SIGSOFT '94 , December 1994. O'Malley, S. W. and Peterson, L. L., "A Dynamic Network Architecture", ACM Transactions on Computer Systems , Vol. 10, May 1992, pages Schmidt, Douglas C. and Tatsuya Suda, "Transport System Architecture Services for High-Performance Communications Systems", IEEE Journal on Selected Areas in Communications , Vol. 11, No. 4, May 1993, pages Fall 2002 CS-545-Fall-2002

D. Garlan, M. Shaw, "An Introduction to Software Architecture", Advances in Software Engineering and Knowledge Engineering", Volume I, World Scientific, D. Perry, A. Wolf, Foundations for the Study of Software Architecture", Proceedings of ACM SIGSOFT, October 1992, W. Waite, A. Sloane, Software Synthesis via Domain-Specific Software Architectures, University of Colorado Technical Report CU-CS , 1992. R. Kazman, L. Bass, G. Abowd, M. Webb, SAAM: A Method for Analyzing the Properties Software Architectures, Proceedings of ICSE 16, May 1994, R. Kazman, G. Abowd, L. Bass, P. Clements, Scenario-Based Analysis of Software Architecture, IEEE Software, to appear, (Also available as Department of Computer Science Technical Report CS ) AT&T, "Best Current Practices: Software Architecture Validation". T. R. Dean, J. R. Cordy, "A Syntactic Theory of Software Architecture", IEEE Transactions on Software Engineering, April 1995, M. Shaw, R. DeLine, D. Klein, T. Ross, D. Young, G. Zelesnik, "Abstractions for Software Architecture and Tools to Support Them", IEEE Transactions on Software Engineering, April, 1995, R. Kazman, L. Bass, Toward Deriving Software Architectures from Quality Attributes, Software Engineering Institute Technical Report CMU/SEI-94-TR-10. October 30 (student paper presentations): Chung-Horng Lung, Sonia Bot, Jay Godse presenting: On the Definition of Software System Architecture," by Cristina Gacek, Ahmed Abd-Allah, Bradford Clark and Barry Boehm - ICSE 17 Software Architecture Workshop, April, 1995 Michael Thompson, Bruce Barkhouse, Richard Muise presenting: Object Oriented Software Technologies Applied to Switching System Architectures and Software Development Processes. Arnold et.al. ISS'90 Fall 2002 CS-545-Fall-2002

Mahboob Ashraf, Larry Brunet, Georgi Kouzev presenting: Luckham, et al, "Specification and Analysis of System Architecture Using Rapide", IEEE Trans. Software Engineering, vol. 21, no. 4, pp , 1995. Francois Moore and Tony Wacheski presenting Distributed Software Engineering by Jeff Kramer. Proceedings of ICSE 16, May 1994, The Semantic Foundations of Software Architecture M. Jazayeri, Component Programming--a fresh look at software components, Technical University of Vienna Technical Report TUV Architecture Evaluations: Fall 2002 CS-545-Fall-2002

R. Allen and D. Garlan. Formal Connectors. Technical Report, CMU-CS , Carnegie Mellon University, March 1994. R. Allen and D. Garlan. Formalizing Architectural Connection. In Proceedings of the Sixteenth International Conference on Software Engineering, pages 71-80, Sorrento, Italy, May 1994. R. Allen. HLA: A Standards Effort as Architectural Style. In A. L. Wolf, ed., Proceedings of the Second International Software Architecture Workshop (ISAW-2), pages , San Francisco, CA, October 1996. G. Booch and J. Rumbaugh. Unified Method for Object-Oriented Development. Rational Software Corporation, 1995. F. DeRemer and H. H. Kron. Programming-in-the-large versus Programming-in-the-small. IEEE Transactions on Software Engineering, pages 80-86, June 1976. Failures Divergence Refinement: User Manual and Tutorial. Formal Systems (Europe) Ltd., Oxford, England, October 1992. D. Garlan, R. Allen, and J. Ockerbloom. Exploiting Style in Architectural Design Environments. In Proceedings of SIGSOFT'94: Foundations of Software Engineering, pages , New Orleans, Louisiana, USA, December 1994. D. Garlan, editor. Proceedings of the First International Workshop on Architectures for Software Systems, Seattle, WA, April 1995. D. Garlan. Style-Based Refinement for Software Architecture. In A. L. Wolf, ed., Proceedings of the Second International Software Architecture Workshop (ISAW-2), pages 72-75, San Francisco, CA, October 1996. D. Garlan, R. Monroe, and D. Wile. ACME: An Architectural Interconnection Language. Technical Report, CMU-CS , Carnegie Mellon University, November 1995. D. Garlan, R. Monroe, and D. Wile. ACME: An Architecture Interchange Language. Submitted for publication, January 1997. Fall 2002 CS-545-Fall-2002

D. Garlan, F. N. Paulisch, and W. F. Tichy, editors. Summary of the Dagstuhl Workshop on Software Architecture, February Reprinted in ACM Software Engineering Notes, pages 63-83, July 1995. D. Garlan and M. Shaw. An Introduction to Software Architecture: Advances in Software Engineering and Knowledge Engineering, volume I. World Scientific Publishing, 1993. J. A. Goguen and T. Winkler. Introducing OBJ3. Technical Report SRI-CSL SRI International, 1988. D. Harel. Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming, 1987. C. A. R. Hoare. Communicating Sequential Processes. Prentice Hall, 1985. P. Inverardi and A. L. Wolf. Formal Specification and Analysis of Software Architectures Using the Chemical Abstract Machine Model. IEEE Transactions on Software Engineering, pages , April 1995. M. Jackson. Software Requirements and Specifications: A Lexicon of Practice, Principles and Prejudices. Addison-Wesley, 1995. D. C. Luckham, J. J. Kenney, L. M. Augustin, J. Vera, D. Bryan, and W. Mann. Specification and Analysis of System Architecture Using Rapide. IEEE Transactions on Software Engineering, pages , April 1995. D. Luckham. ANNA, a language for annotating Ada programs: reference manual, volume 260 of Lecture Notes in Computer Science. Springer-Verlag, Berlin, 1987. D. C. Luckham, J. Vera, D. Bryan, L. Augustin, and F. Belz. Partial Orderings of Event Sets and Their Application to Prototyping Concurrent, Timed Systems. Journal of Systems and Software, pages , June 1993. D. C. Luckham, J. Vera, and S. Meldal. Three Concepts of System Architecture. Unpublished Manuscript, July 1995. Fall 2002 CS-545-Fall-2002

N. Medvidovic. ADLs and Dynamic Architecture Changes. In A. L. Wolf, ed., Proceedings of the Second International Software Architecture Workshop (ISAW-2), pages 24-27, San Francisco, CA, October 1996. J. Magee, N. Dulay, S. Eisenbach, and J. Kramer. Specifying Distributed Software Architectures. In Proceedings of the Fifth European Software Engineering Conference (ESEC'95), Barcelona, September 1995. N. Medvidovic, P. Oreizy, and R. N. Taylor. Reuse of Off-the-Shelf Components in C2-Style Architectures. In Proceedings of the 1997 Symposium on Software Reusability (SSR'97), pages , Boston, MA, May 17-19, Also in Proceedings of the 1997 International Conference on Software Engineering (ICSE'97), pages , Boston, MA, May 17-23, 1997. N. Medvidovic, P. Oreizy, J. E. Robbins, and R. N. Taylor. Using object-oriented typing to support architectural design in the C2 style. In Proceedings of ACM SIGSOFT'96: Fourth Symposium on the Foundations of Software Engineering (FSE4), pages 24-32, San Francisco, CA, October 1996. N. Medvidovic and R. N. Taylor. Reusing Off-the-Shelf Components to Develop a Family of Applications in the C2 Architectural Style. In Proceedings of the International Workshop on Development and Evolution of Software Architectures for Product Families, Las Navas del Marqués, Ávila, Spain, November 1996. N. Medvidovic and R. N. Taylor. A Framework for Classifying and Comparing Architecture Description Languages. To appear in Proceedings of the Sixth European Software Engineering Conference together with Fifth ACM SIGSOFT Symposium on the Foundations of Software Engineering, Zurich, Switzerland, September 22-25, 1997. Fall 2002 CS-545-Fall-2002

N. Medvidovic, R. N. Taylor, and E. J. Whitehead, Jr. Formal Modeling of Software Architectures at Multiple Levels of Abstraction. In Proceedings of the California Software Symposium 1996, pages 28-40, Los Angeles, CA, April 1996. K. Ng, J. Kramer, and J. Magee. A CASE Tool for Software Architecture Design. Journal of Automated Software Engineering (JASE), Special Issue on CASE-95, 1996. P. Oreizy. Issues in the Runtime Modification of Software Architectures. Technical Report, UCI-ICS-96-35, University of California, Irvine, August 1996. C. A. Petri. Kommunikationen Mit Automaten. PhD Thesis, University of Bonn, English translation: Technical Report RADC-TR , Vol.1, Suppl 1, Applied Data Research, Princeton, N.J. R. Prieto-Diaz and J. M. Neighbors. Module Interconnection Languages. Journal of Systems and Software, pages , October 1989. D. E. Perry and A. L. Wolf. Foundations for the Study of Software Architectures. ACM SIGSOFT Software Engineering Notes, pages 40-52, October 1992. J. E. Robbins, N. Medvidovic, D. F. Redmiles, and D. S. Rosenblum. Integrating Architecture Description Languages with a Standard Design Method. Technical Report, UCI-ICS-97-35, University of California, Irvine, August 1997. J. E. Robbins and D. Redmiles. Software architecture design from the perspective of human cognitive needs. In Proceedings of the California Software Symposium (CSS'96), Los Angeles, CA, USA, April 1996. M. Shaw, R. DeLine, D. V. Klein, T. L. Ross, D. M. Young, and G. Zelesnik. Abstractions for Software Architecture and Tools to Support Them. IEEE Transactions on Software Engineering, pages , April 1995. M. Shaw and D. Garlan. Characteristics of Higher-Level Languages for Software Architecture. Technical Report, CMU-CS , Carnegie Mellon University, December 1994. Fall 2002 CS-545-Fall-2002

D. Garlan, M. Shaw, "An Introduction to Software Architecture", Advances in Software Engineering and Knowledge Engineering", Volume I, World Scientific, D. Perry, A. Wolf, Foundations for the Study of Software Architecture", Proceedings of ACM SIGSOFT, October 1992, W. Waite, A. Sloane, Software Synthesis via Domain-Specific Software Architectures, University of Colorado Technical Report CU-CS , 1992. R. Kazman, A Challenge for Software Architecture: Distributed Flight Simulation, in Parallel and Distributed Computing Handbook, A. Zomaya (ed.), McGraw-Hill, 1995, to appear. R. Kazman, L. Bass, G. Abowd, M. Webb, SAAM: A Method for Analyzing the Properties Software Architectures, Proceedings of ICSE 16, May 1994, R. Kazman, G. Abowd, L. Bass, P. Clements, Scenario-Based Analysis of Software Architecture, IEEE Software, to appear, (Also available as Department of Computer Science Technical Report CS ) AT&T, "Best Current Practices: Software Architecture Validation". T. R. Dean, J. R. Cordy, "A Syntactic Theory of Software Architecture", IEEE Transactions on Software Engineering, April 1995, M. Shaw, R. DeLine, D. Klein, T. Ross, D. Young, G. Zelesnik, "Abstractions for Software Architecture and Tools to Support Them", IEEE Transactions on Software Engineering, April, 1995, R. Kazman, L. Bass, Toward Deriving Software Architectures from Quality Attributes, Software Engineering Institute Technical Report CMU/SEI-94-TR-10. October 30 (student paper presentations): Chung-Horng Lung, Sonia Bot, Jay Godse presenting: On the Definition of Software System Architecture," by Cristina Gacek, Ahmed Abd-Allah, Bradford Clark and Barry Boehm - ICSE 17 Software Architecture Workshop, April, 1995 Michael Thompson, Bruce Barkhouse, Richard Muise presenting: Object Oriented Software Technologies Applied to Switching System Architectures and Software Development Processes. Arnold et.al. ISS'90 Fall 2002 CS-545-Fall-2002

J. M. Spivey. The Z notation: a reference manual. Prentice Hall, New York, 1989. A. Terry, R. London, G. Papanagopoulos, and M. Devito. The ARDEC/Teknowledge Architecture Description Language (ArTek), Version 4.0. Technical Report, Teknowledge Federal Systems, Inc. and U.S. Army Armament Research, Development, and Engineering Center, July 1995. S. Vestal. A Cursory Overview and Comparison of Four Architecture Description Languages. Technical Report, Honeywell Technology Center, February 1993. S. Vestal. MetaH Programmer's Manual, Version Technical Report, Honeywell Technology Center, April 1996. A. L. Wolf, editor. Proceedings of the Second International Software Architecture Workshop (ISAW-2), San Francisco, CA, October 1996. Fall 2002 CS-545-Fall-2002

Reference: General Background
D. Garlan and M. Shaw, "An Introduction to Software Architecture", Advances in Software Engineering and Knowledge Engineering, Vol. 2, 1993, pp Also available as Carnegie Mellon University Technical Report CMU-CS , January 1994 D. E. Perry and A. L. Wolf, "Foundations for the study of software architecture", ACM SIGSOFT Software Engineering Notes, Vol. 17, No. 4, October 1992, pp D. Garlan, R. Allen, and J. Ockerbloom, "Architectural Mismatch, or why it's hard to build systems out of existing parts", Proceedings of the 17th. Int'l Conference on Software Engineering, Seattle, WA, April 1995, pp D. Garlan, "Research Directions in Software Architecture" ACM Computing Surveys, Vol. 27, No. 2, June 1995, pp D. Garlan and D. E. Perry, "Introduction to the Special Issue on Software Architecture", IEEE Transactions on Software Engineering, Vol. 21, No. 4, April 1995, pp Philippe Kruchten, "The 4+1 View Model of Software Architecture", IEEE Software, Vol. 12, No. 6, November 1995, pp M. Shaw, D. Garlan, R. Allen, et al., "Candidate Model Problems in Software Architecture", Discussion draft 1.3 in circulation for development of community consensus, Carnegie Mellon University, November See instead the online version Fall 2002 CS-545-Fall-2002

References Mainframe Architectures ADL
Paulisch, Frances. "Software Architecture and Reuse- An Inherent Conflict?" 214. Proceedings of the 3rd International Conference on Software Reuse. Rio de Janeiro, Brazil, November 1-4, Los Alamitos, CA: IEEE Computer Society Press, 1994 Siwolp, Sana. "Not Your Father's Mainframe." Information Week 546 (Sept 25, 1995): Edelstein, Herb. "Unraveling Client/Server Architecture." DBMS 7, 5 (May 1994): 34(7). ADL Garlan, David & Shaw, Mary. "An Introduction to Software Architecture," Advances in Software Engineering and Knowledge Engineering Volume 2. New York, NY: World Scientific Press, 1993. Garlan, D. & Allen, R. "Formalizing Architectural Connection," Proceedings of the 16th International Conference on Software Engineering. Sorrento, Italy, May 16-21, Los Alamitos, CA: IEEE Computer Society Press, 1994. Luckham, David C., et al. "Specification and Analysis of System Architecture Using Rapide." IEEE Transactions on Software Engineering 21, 6 (April 1995): Shaw, Mary, et al. "Abstractions for Software Architecture and Tools to Support Them." IEEE Transactions on Software Engineering 21, 6 (April 1995): Hoare, C.A.R. Communicating Sequential Processes. Englewood Cliffs, NJ: Prentice Hall International, 1985. Fall 2002 CS-545-Fall-2002

References ADL Garlan, David & Shaw, Mary. "An Introduction to Software Architecture," Advances in Software Engineering and Knowledge Engineering Volume 2. New York, NY: World Scientific Press, 1993. Garlan, D. & Allen, R. "Formalizing Architectural Connection," Proceedings of the 16th International Conference on Software Engineering. Sorrento, Italy, May 16-21, Los Alamitos, CA: IEEE Computer Society Press, 1994. Luckham, David C., et al. "Specification and Analysis of System Architecture Using Rapide." IEEE Transactions on Software Engineering 21, 6 (April 1995): Shaw, Mary, et al. "Abstractions for Software Architecture and Tools to Support Them." IEEE Transactions on Software Engineering 21, 6 (April 1995): Hoare, C.A.R. Communicating Sequential Processes. Englewood Cliffs, NJ: Prentice Hall International, 1985. Fall 2002 CS-545-Fall-2002

References SA: Inverardi, Paola and Alexander L. Wolf, Formal Specification and Analysis of Software Architectures Using the Chemical Abstract Machine Model. IEEE Transactions on Software Engineering 21(4), April To appear. Leffler, Samuel J. and McKusick, Marshall Kirk and Karels, Michael J. and Quaterman, John S., The Design and Implementation of the 4.3 BSD UNIX Operating System , Addison-Wesley, 1st edition, 1989. Moriconi, Mark and Xiaolei Qian, "Correctness and Composition of Software Architectures," In Proceedings of SIGSOFT '94 , December 1994. O'Malley, S. W. and Peterson, L. L., "A Dynamic Network Architecture", ACM Transactions on Computer Systems , Vol. 10, May 1992, pages Perry, Dewayne E. and Alexander L. Wolf, "Foundations for the study of software architecture," Software Engineering Notes, Vol. 17, No. 4, October 1992, pages Schmidt, Douglas C. and Tatsuya Suda, "Transport System Architecture Services for High-Performance Communications Systems", IEEE Journal on Selected Areas in Communications , Vol. 11, No. 4, May 1993, pages Fall 2002 CS-545-Fall-2002

Finite State Machines Robert Büssow, Matthias Weber, "A Steam Boiler Control Specification with Statecharts and Z", volume 1165 of Lecture Notes in Computer Science. Springer-Verlag, 1996 Matthias Weber, "Combining Statecharts and Z for the Design of Safety-Critical Control Systems", FME'96: Industrial Benefits and Advances in Formal Methods, Lecture Notes in Computer Science 1051, p , Springer Verlag Hartmut Ehrig, Robert Geisler, Marcus Klar, Julia Padberg, "Horizontal and Vertical Structuring Techniques for Statecharts", Proc. CONCUR'97, Springer LNCS Fall 2002 CS-545-Fall-2002

Tool Support for Architecture Analysis & Design
Frameworks for ADL Tool Support [MR97] Nenad Medvidovic and David S. Rosenblum, "Domains of Concern in Software Architectures and Architecture Description Languages.", In Proceedings of the USENIX Conference on Domain-Specific Languages, Santa Barbara, CA, October 15-17, 1997, pp [MRT99] Nenad Medvidovic, David S. Rosenblum, and Richard N. Taylor, "A Language for Architecture-Based Software Development and Evolution", Proceedings of the 21th Int'l Conference on Software Engineering (ICSE '99), May 16-22, 1999, Los Angeles, CA, USA, pp SSAMtool [KAB+96] R. Kazman, G. Abowd, L. Bass, and P. Clements, "Scenario-Based Analysis of Software Architecture", IEEE Software, Vol. 13, No. 6, November 1996, pp [Kazman96] R. Kazman, "Tool Support for Architecture Analysis and Design," Joint Proceedings of the SIGSOFT '96 Workshops (ISAW-2), San Francisco, CA, October 1996, pp CSP Model Checker (for Wright) [For92] Failures Divergence Refinement: User Manual and Tutorial, Formal Systems (Europe) Ltd., Oxford, England, October 1992 Software Architect's Assistant in Darwin [NKM96] K. Ng, J. Kramer, and J. Magee, "A CASE Tool for Software Architecture Design", Journal of Automated Software Engineering (JASE), Special Issue on CASE-95, 1996 C2's ArchShell [Oreizy96] P. Oreizy, Issues in the Runtime Modification of Software Architectures, Technical Report, UCI-ICS-96-35, University of California, Irvine, August 1996 Fall 2002 CS-545-Fall-2002

Domains of Concern in SA
Software architectures shift the focus of developers from lines-of-code to coarser-grained elements and their interconnection structure. Architecture description languages (ADLs) have been proposed as domain-specific languages for the domain of software architecture. There is still little consensus in the research community on what problems are most important to address in a study of software architecture, what aspects of an architecture should be modeled in an ADL, or even what an ADL is. To shed light on these issues, we provide a framework of architectural domains, or areas of concern in the study of software architectures. We evaluate existing ADLs with respect to the framework and study the relationship between architectural and application domains. One conclusion is that, while the architectural domains perspective enables one to approach architectures and ADLs in a new, more structured manner, further understanding of architectural domains, their tie to application domains, and their specific influence on ADLs is needed. Fall 2002 CS-545-Fall-2002

How to Pick a Model Problem

Selection of Model Problems
Model problems for software architecture should focus on specific architectural issues. Such issues include Describing system organizations, and describing specific kinds of system organization (architectural styles) Distinguish among templates, instances, and invocations Distinguish among different kinds of system organization – implications of structural differences Select among different architectural alternatives Using different models concurrently, or at different refinements of a design; establish consistency among such different views Define families of systems Define families, or styles, of architecture Describe dynamic behavior of systems with fixed structure and describing dynamic changes in system structure Measure, evaluate, and test properties of systems such as performance, reliability, security Measure, evaluate, and test properties of designs such as ease of extension or sub-setting. Fall 2002 CS-545-Fall-2002

Our Problem F1 F3 F4 Output Input F2
We will start with the simple system below and extend it in response to address and clarify the different architectural issues. F1 F3 F4 Output Input F2 Fall 2002 CS-545-Fall-2002

Configuration Updates

History of Updates Oct Architecture Styles Update Week 3, 4 and 5 Oct Reading Updates fro Week 12 and general cleanup. Oct Homework updated for ATAM Sep ATAM Update and general cleanup Sep : Cleanup of References Aug : Initial Release to Students Fall 2002 CS-545-Fall-2002

Software Architecture

Similar presentations

Presentation on theme: "Software Architecture"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Software Architecture

Similar presentations

Presentation on theme: "Software Architecture"— Presentation transcript:

Similar presentations

About project

Feedback