Software Architecture
CS-545
Syllabus - Fall 2002
Rev 0.21
Haig F. Krikorian
General Issues
•Me:
–Mr. Haig Krikorian, 25+ yrs. developing SW intensive systems
•Office Hours:
–30 min. before and after class, Rm. 419.
•e-mail:
– [email protected][email protected]
• Web Site:
– http://haig.ecs.fullerton.edu
• Class Notes at: http://haig.ecs.fullerton.edu/files/
– ftp:[email protected]
• Class Notes at : ftp:[email protected]/homepage/files/
•Phone: 714-278-3700 (dept.)
•Course Time & Place: Monday (7-10) here
•Prerequisites: as specified
•How many are currently working in a SW position ?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
2
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 020170482X.
– Design & Use of Software Architectures: Adopting and Evolving a Product Line Approach: ISBN:
0201674947
– SEI Selected Papers: http://www.sei.cmu.edu/architecture/
– USC Selected Papers: http://sunset.usc.edu
– UCI Selected Papers: http://www.ics.uci.edu
• Other References & Standards discussed in this class
–IEEE 1471, ISO RM-ODP
• http://www.dstc.edu.au/Research/Projects/ODP/ref_model.html
–IEEE 1220, EIA-632, EIA-731, DO-178B, J-STD-016-1995
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
3
Other Referenced Sites
•
Primary References:
–
http://portal.acm.org/dl.cfm?coll=portal&dl=ACM&CFID=3943453&CFTOKEN=26992569
•
–
http://ieeexplore.ieee.org/Xplore/DynWel.jsp
•
–
(Elsevier Copyrighted material)
http://citeseer.nj.nec.com/cs
(Lots of open source materials)
http://www.sei.cmu.edu/str/
(Lots of open source materials)
http://www-2.cs.cmu.edu/~able/publications/
(Lots of open source materials)
http://www.sei.cmu.edu/staff/rkazman/SE-papers.html
(Lots of open source materials)
http://www.cs.ukc.ac.uk/people/staff/cr3/bib/bookshelf/Modules.html
•
–
–
–
–
(IEEE Copyrighted papers)
http://www.sciencedirect.com/
•
–
–
–
–
–
(ACM Copyrighted Papers)
(A ton of open source materials)
http://www2.umassd.edu/SECenter/SAResources.html
http://www.cgl.uwaterloo.ca/~rnkazman/SA-sites.html
http://www-ksl-svc.stanford.edu:5915/
http://www.sei.cmu.edu/architecture/adl.html
Fall 2002
(Links to other sites)
(Links to other sites)
(Ontologies)
(Architecture Definition Languages)
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
4
Other Referenced Sites
•Secondary References Used:
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/
(Garlan’s Class on SA)
– http://www.softwaresystems.org/architecture.html
– http://www-old.ics.uci.edu/pub/arch/
– http://cora.whizbang.com/
– http://selab.korea.ac.kr/selab/resources/se/architecture.htm#Web
– http://www.cebase.org/
– http://www.afm.sbu.ac.uk/
– http://www.wwisa.org
– http://www.dacs.dtic.mil/databases/url/key.hts?keycode=71:2024&islowerlevel=1
– http://www.cs.colorado.edu/serl/arch/Papers.html
– http://www.cetus-links.org/
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
5
Other Referenced Sites
•Tools:
– http://www.isr.uci.edu/projects/xarchuci/
– http://www.isr.uci.edu/projects/xarchuci/tools-overview.html
– http://www.isr.uci.edu/projects/archstudio/setup-rundevelop.html
– http://www.isr.uci.edu/projects/archstudio/
– http://www.kc.com/products/iuml/lite.html
– http://www-2.cs.cmu.edu/~able/software.html
– http://www-2.cs.cmu.edu/~Compose/html/tools.html
– http://pavg.stanford.edu/rapide/
– http://www.afm.sbu.ac.uk/z/
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
(xADL 2.0 )
(xADL)
(xUml)
(ACME SW)
(RAPIDE)
(Z)
6
Academic Dishonesty
•Cheating
–Homework is individual
•Inventing false information
–Your work is individual
•Wrong citations
–(NA this class)
•Plagiarism
–Homework is individual
–Keep it that way…
•Collaboration this class
–Your projects are individual.
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
7
Ethics in Software Architecture Development
• Space Mission disasters
•Aircraft disasters
–Airbus disasters
•Launch Disasters
–International launch disasters
–Domestic launch 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
8
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
9
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
10
The Proposed Architectures
•TheWKB.com
– depicts what they call an architecture by
showing the allocation of functional pieces to
hardware.
WS (1)
WS (…)
UI
UI
UI
Functions..
Functions..
DBMS
WS (n)
•TheMob.com
–depicts what they call an architecture by
showing a functional block diagram.
The System
UI
•TheWBTE.com
– depict what they call an architecture by
showing a logical view of the functional
elements and their interconnection
dependencies.
These depictions and others have been used to describe architectures –
So who is correct ? What’s missing ?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
Functions..
DBMS
UI
Functions..
DBMS
11
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:
–
–
–
–
–
WS (1)
UI
Functional relationships ?
Data Flow ?
Functions..
Control Flow ?
Event Handling ?
•Do the boxes and lines have the same
meaning both internal to an architecture and
Fault-Tolerance ?
across competing architectures ?
WS (…)
WS (n)
UI
UI
Functions..
DBMS
The System
• Operational capabilities:
– How do measure which one is better at
UI
Functions..
DBMS
addressing the issues wrt.:
–Homogenous vs. Heterogeneous systems?
UI
– Expandability ?
Functions..
– Interoperability ?
– Maintainability ?
– Upgradeability ?
DBMS
– Responsiveness ?
•Who do you give the contract to?
–… etc..
•It should be obvious then that there needs to be a better
(more formal) way of describing and evaluating an architecture !
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
12
Industry Concerns
•
•
•
•
http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/roadmap2000/roadmap2000.pdf
http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/mse-ieee97/mse-ieee97.pdf
http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/able/ftp/fmmse-zum94/fmmse-zum94.pdf
http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/sacourse-csee92/sacourse-csee92.pdf
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
13
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
14
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%
– Assesses your ability to express fundamental software architecture themes and concepts
– 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
15
Proposed Course Outline & Schedule (*)
http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/sacourse-csee92/sacourse-csee92.pdf
Week 1:
Course Introduction
Background & Origins
Introduction to Mega-programming
Architecture Terms
Architecture Styles:
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 2 Background
Objects
Decomposition Issues
Building Blocks
Formal Models (Z)
Week 3: DSSA:
AESOP, UniCON, Cyberspace Info Architectures
Week 9: Architecture Evolution & Issues
Week 10: Formal Models of Processes
Week 4 Data Flow Systems
Batch Sequential & Pipeline
Case Study
Pipes & Filters (Unix Pipes)
Formal Models for Data Flow
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 5: Call & Return Systems
Main Program & Subroutine
Object Oriented Systems
Hierarchical
Layers
Fall
2002
Week 15: Architecture-based development and evolution
(*) We are in no hurry… I want to ensure you understand the
material. The proposed as topics will spill over from week-to-week.
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
16
Organization of the Materials
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
17
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
18
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 ?
WS (1)
WS (…)
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 ?
WS (n)
The System
• Operational capabilities:
– How do measure which one is better at
UI
Functions..
DBMS
addressing the issues wrt.:
–Homogenous vs. Heterogeneous systems?
UI
– Expandability ?
Functions..
– Interoperability ?
– Maintainability ?
– Upgradeability ?
DBMS
– Responsiveness ?
•Who do you give the contract to?
–… etc..
•It should be obvious then that there needs to be a better
(more formal) way of describing and evaluating an architecture !
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
21
Industry Concerns
•
•
•
•
http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/roadmap2000/roadmap2000.pdf
http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/mse-ieee97/mse-ieee97.pdf
http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/able/ftp/fmmse-zum94/fmmse-zum94.pdf
http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/sacourse-csee92/sacourse-csee92.pdf
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
22
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
23
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
24
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, 1994. 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
25
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
26
Issues in Software Architecture
•http://www.sei.cmu.edu/publications/documents/01.reports/01tr035.html
•http://www.sei.cmu.edu/pub/documents/96.reports/pdf/tr008.96.pdf
•http://www.sei.cmu.edu/str/
•http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/aesop-fse2/aesop-fse2.pdf
• 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?: http://www.sei.cmu.edu/ata/arch_rep.html
• ? 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.: http://www.sei.cmu.edu/ata/ata_extraction.html
• Architecture: Static vs Dynamic View: (See References)
– http://www-old.ics.uci.edu/pub/arch/dynamic-arch.html
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
27
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 1996. (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):
• Then consider a pipeline architecture.
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
28
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 1996. (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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
29
Architecture Representation Concepts
• (Computer 2) Core Architecture Refinement: IEEE Transactions on Software Engineering, Vol 21, No .4 April 1995, pgs 356-372
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
30
Architecture Evaluation and Analysis:
SEI: Architecture Quality Attributes Used for Evaluation & Analysis
• http://www.sei.cmu.edu/publications/documents/00.reports/00tn017.html
• http://www.sei.cmu.edu/str/taxonomies/view_qm.html
• Performance Measures
– Dependability
– Availability
– Reliability
– Accuracy
– Safety
– Trustworthiness
– Vulnerability
– Integrity
– Confidentiality
– Denial of Service
– Survivability
– Accountability
– Auditable
– Security
• Need Satisfaction Measures
–Effectiveness
• Necessity of Characteristics
• Sufficiency of Characteristics
–Responsiveness
–Correctness
• Completeness / Incompleteness
• Consistency
• Traceability
• Provably Correct
–Verifiability
• Testability
What are the different considerations for a
local vs
distributed homogeneous vs
distributed heterogeneous system ?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
– Efficiency / Utilization
– Capacity
– Real-Time Responsiveness
– Throughput
– Usability / Human Engineering
– Error Proneness
– Operability
– Fidelity
31
Architecture Evaluation and Analysis:
SEI: Architecture Quality Attributes Used for Evaluation & Analysis
• http://www.sei.cmu.edu/publications/documents/00.reports/00tn017.html
• http://www.sei.cmu.edu/str/taxonomies/view_qm.html
• Maintenance Measures
• Organizational Measures
–Cost of Ownership
• Cost of Operation
• Operations Personnel
• Training
• Operations System
• Cost of Maintenance
• Maintenance Personnel
• Training
• Maintenance Control
• HW Maintenance
• SW Maintenance
• Requirements Growth
• Life-Time Operational Capability
• Acquisition Cycle Time
• Software Change Cycle Time
–Maintainability
–Understandability
• Complexity
• Simplicity
• Structuredness
• Readability
• Adaptive Measures
–Interoperability
• Compatibility
• Openness
–Portability
–Scalability
–Reusability
• Functional Scope
• Retrievability
–Productivity
What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
32
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
– What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?
•Usability
– Understandability, Learn ability, Operability
– What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?
•Efficiency
– Time behavior, Resource Behavior
– What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?
•Maintainability
– Analyzability, changeability, Stability, Testability
– What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?
•Portability
– Adaptability, Install ability, Conformance, Replace ability
– What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
•ISO vs. SEI Differences?
33
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. 43-50
– 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. 415-434
– 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. 186-195
– 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. 179-185
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
34
Architecture Representations:
Static View vs. Dynamic View
• http://www-old.ics.uci.edu/pub/arch/dynamic-arch.html
•“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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
35
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
36
Background Cont:
• http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/roadmap2000/roadmap2000.pdf
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
37
Roles of an ADL
• http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/roadmap2000/roadmap2000.pdf
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
38
Background Cont:
• http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/roadmap2000/roadmap2000.pdf
• http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/aesop-fse2/aesop-fse2.pdf
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
39
Background Cont:
• http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/roadmap2000/roadmap2000.pdf
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
40
Background Cont:
• http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/roadmap2000/roadmap2000.pdf
• Design & Use of Software Architectures: Adopting and Evolving a Product Line Approach: ISBN: 0201674947
• http://www.dstc.edu.au/Research/Projects/ODP/ref_model.html
•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 !!)
– What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
41
Background Cont:
• http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/roadmap2000/roadmap2000.pdf
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
42
Background Cont:
• http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/roadmap2000/roadmap2000.pdf
• Design & Use of Software Architectures: Adopting and Evolving a Product Line Approach: ISBN: 0201674947
• http://www.dstc.edu.au/Research/Projects/ODP/ref_model.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
43
Background Cont:
• http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/roadmap2000/roadmap2000.pdf
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
44
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
46
Architecture Terms that get thrown about
• Asynchronous:
WS (1)
WS (…)
UI
UI
UI
Functions..
Functions..
DBMS
– 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 ?
WS (n)
• Atomic:
– After a transaction executes, either all or none of its operations
take effect
–What are the different considerations for a local vs
distributed homogeneous vs distributed
heterogeneous system ?
• 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.
–What are the different considerations for a local vs
distributed homogeneous vs distributed
heterogeneous system ?
The System
UI
Functions..
DBMS
UI
Functions..
DBMS
•How are these issues addressed in each architecture?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
47
Architecture Terms that get thrown about
• Behavior:
–(dependencies between events)
–What are the different considerations for a local
vs distributed homogeneous vs distributed
heterogeneous system ?
• Causality:
WS (1)
WS (…)
UI
UI
UI
Functions..
Functions..
DBMS
WS (n)
– Being able to depict the causal history between events
time, and response process execution time
– What are the different considerations for a local vs
distributed homogeneous vs distributed heterogeneous
system ?
• Centralized:
The System
– (Have class explain)
– What are the different considerations for a local vs
distributed homogeneous vs distributed heterogeneous
system ?
UI
Functions..
DBMS
• 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.
– What are the different considerations for a local vs
distributed homogeneous vs distributed heterogeneous
system ?
UI
Functions..
•How are these issues addressed in each architecture?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
DBMS
48
Architecture Terms that get thrown about
• Consistency: (Of States): (Have class explain)
– What are the different considerations for a local vs
distributed homogeneous vs distributed heterogeneous
system ?
WS (1)
WS (…)
UI
UI
UI
Functions..
Functions..
DBMS
WS (n)
• Correctness:(Have class explain)
– What are the different considerations for a local vs
distributed homogeneous vs distributed heterogeneous
system ?
• 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.
– What are the different considerations for a local vs
distributed homogeneous vs distributed heterogeneous
system ?
The System
UI
Functions..
• Disconnected operation :
DBMS
UI
– 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.
– What are the different considerations for a local vs
distributed homogeneous vs distributed heterogeneous
system ?
Functions..
DBMS
•How are these issues addressed in each architecture?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
49
Architecture Terms that get thrown about
• 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 ?
WS (1)
WS (…)
UI
UI
UI
Functions..
Functions..
DBMS
WS (n)
The System
• Decentralized:
–(Have class explain)
UI
Functions..
–What are the different considerations for a local
vs distributed homogeneous vs distributed
heterogeneous system ?
• Durability:
DBMS
UI
Functions..
– Under failures, how does the system behave.
–What are the different considerations for a local
vs distributed homogeneous vs distributed
heterogeneous system ?
DBMS
•How are these issues addressed in each architecture?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
50
Architecture Terms that get thrown about
• Efficient:
–(Have class explain)
–What are the different considerations for a local
vs distributed homogeneous vs distributed
heterogeneous system ?
WS (1)
WS (…)
UI
UI
UI
Functions..
Functions..
DBMS
WS (n)
• Events: (Patterns of Events)
–(Have class explain)
–What are the different considerations for a local
vs distributed homogeneous vs distributed
heterogeneous system ?
• Fault-tolerance:
The System
UI
Functions..
DBMS
–(Have class explain)
–What are the different considerations for a local
vs distributed homogeneous vs distributed
heterogeneous system ?
UI
Functions..
DBMS
•How are these issues addressed in each architecture?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
51
Architecture Terms that get thrown about
•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 ?
WS (1)
WS (…)
UI
UI
UI
Functions..
Functions..
DBMS
WS (n)
The System
UI
Functions..
DBMS
UI
Functions..
DBMS
•How are these issues addressed in each architecture?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
52
Architecture Terms that get thrown about
•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 ?
WS (1)
WS (…)
UI
UI
UI
Functions..
Functions..
DBMS
WS (n)
The System
UI
Functions..
DBMS
•Interfaces: (& types)
UI
–(Have class explain)
–What are the different considerations for a local
vs distributed homogeneous vs distributed
heterogeneous system ?
Functions..
DBMS
•How are these issues addressed in each architecture?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
53
Architecture Terms that get thrown about
•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 ?
WS (1)
WS (…)
UI
UI
UI
Functions..
Functions..
DBMS
•Isolation: (Of transactions)
WS (n)
The System
–(Have class explain)
–What are the different considerations for a local
vs distributed homogeneous vs distributed
heterogeneous system ?
UI
Functions..
•Mainframe
DBMS
UI
Functions..
–(Have class explain)
–What are the different considerations for a local
vs distributed homogeneous vs distributed
heterogeneous system ?
DBMS
•How are these issues addressed in each architecture?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
54
Architecture Terms that get thrown about
•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-thefly” 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 ?
WS (1)
WS (…)
UI
UI
UI
Functions..
Functions..
DBMS
WS (n)
The System
UI
Functions..
DBMS
•Maintainable:
– (Have class explain)
UI
– What are the different considerations for a local vs
distributed homogeneous vs distributed heterogeneous
system ?
Functions..
DBMS
•How are these issues addressed in each architecture?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
55
Architecture Terms that get thrown about
•Portable:
WS (1)
WS (…)
UI
UI
UI
Functions..
Functions..
DBMS
WS (n)
–(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.
–What are the different considerations for a local
vs distributed homogeneous vs distributed
heterogeneous system ?
•Reusable:
The System
UI
Functions..
DBMS
UI
Functions..
–(Have class explain)
–What are the different considerations for a local
vs distributed homogeneous vs distributed
heterogeneous system ?
DBMS
•How are these issues addressed in each architecture?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
56
Architecture Terms that get thrown about
• 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 ?
WS (1)
WS (…)
UI
UI
UI
Functions..
Functions..
DBMS
WS (n)
The System
UI
Functions..
DBMS
UI
Functions..
DBMS
•How are these issues addressed in each architecture?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
57
Architecture Terms that get thrown about
• 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.
WS (1)
WS (…)
UI
UI
UI
Functions..
Functions..
DBMS
–What are the different considerations for a local
vs distributed homogeneous vs distributed
heterogeneous system ?
WS (n)
The System
– (have class explain)
• Structured-ness:
– (have class explain)
UI
Functions..
–What are the different considerations for a local
vs distributed homogeneous vs distributed
heterogeneous system ?
DBMS
UI
Functions..
• Time sharing computing:
– (have class explain)
–What are the different considerations for a local
vs distributed homogeneous vs distributed
heterogeneous system ?
DBMS
•How are these issues addressed in each architecture?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
58
Architecture Terms that get thrown about
• Testable:
WS (1)
WS (…)
UI
UI
UI
Functions..
Functions..
DBMS
WS (n)
– (have class explain)
–What are the different considerations for a local vs
distributed homogeneous vs distributed
heterogeneous system ?
• Triggers:
– (have class explain)
–What are the different considerations for a local vs
distributed homogeneous vs distributed
heterogeneous system ?
The System
• Understandable:
– (have class explain)
–What are the different considerations for a local vs
distributed homogeneous vs distributed
heterogeneous system ?
UI
Functions..
DBMS
UI
• Usable:
Functions..
– (have class explain)
–What are the different considerations for a local vs
distributed homogeneous vs distributed
heterogeneous system ?
DBMS
•How are these issues addressed in each architecture?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
59
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
60
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
61
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 ofhttp://www.sei.cmu.edu/about/disclaimer.html
since then)
Fall 2002
CS-545-Fall-2002
62
MIL Continued
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
63
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
64
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
65
Towards Defining an Architecture
•
•
•
•
http://sunset.usc.edu
http://www.cs.ucsd.edu/users/goguen/pps/orlando96.ps
http://www.cs.ukc.ac.uk/people/staff/cr3/bib/bookshelf/Modules.html
http://ftp.ics.uci.edu/pub/c2/papers/C2-ICSE17-SAWS.pdf
• System Decomposition
– Parnas 72
• http://www.acm.org/classics/may96/
• Modular Structure and Composition of Complex Systems
–Parnas 85
• Software Module Interface Specification
– Parnas 72
• Module Interconnection
– Prieto-Diaz 86
• Mega Programming
– From Modules to Systems
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
66
System & Component Decomposition Issues
• http://sunset.usc.edu
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
67
Components & Connector Interactions
• http://sunset.usc.edu
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
68
System Decomposition Cont.
• http://www.cs.ucsd.edu/users/goguen/pps/orlando96.ps
• http://www.cs.ukc.ac.uk/people/staff/cr3/bib/bookshelf/Modules.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
69
Decomposition & Information Hiding
• http://www.cs.ucsd.edu/users/goguen/pps/orlando96.ps
• http://www.cs.ukc.ac.uk/people/staff/cr3/bib/bookshelf/Modules.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
70
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?
–(hint..See Use case Analysis)
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
71
Module Guide Example
•Goals:
– 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
– Internal Operations
– Design Decisions
– Capabilities provided by each module
– Interdependencies
(See Supporting Activity Diagrams)
(See Use case internal sequence desc.)
(See Use case descriptions)
(See Use case descriptions)
(See Use case sequence diagrams)
We can fulfill the intent of Parnas through our Use Case Analysis Method
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
72
Parnas: A7-E Module Guide Example
• http://www.infosys.tuwien.ac.at/Teaching/Courses/ 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
Note the additions by D.L.
Parnas to his original
discussion in 1972. We can
fulfill the intent of Parnas
through our Use Case
Analysis Method
• Software Decision Module (SDM)
– Hides SW design Decision
– Application Data Type Module
– Physical Model Module
– Data Module
– (Not in Requirements Documents)
Fall 2002
•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.
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
73
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
74
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
75
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
76
Module Interconnect Languages (MILs)
• http://www.sei.cmu.edu/str/descriptions/mil_body.html
• Prieto-Diaz, Ruben & Neighbors, James. "Module Interconnection Languages." Journal of Systems and Software 6, 4 (1986): 307-334.
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
77
Module Interconnect Languages (MILs)
• http://www.sei.cmu.edu/str/descriptions/mil_body.html
• Prieto-Diaz, Ruben & Neighbors, James. "Module Interconnection Languages." Journal of Systems and Software 6, 4 (1986): 307-334.
• Tichy, W. F. "Software Development Control Based on Module Interconnection," 29-41. Proceedings of the 4th International Conference on Software
Engineering. Munich, Germany, September 17-19, 1979. New York, NY: IEEE Computer Society Press, 1979.
• Cooprider, Lee W. The Representation of Families of Software Systems (CMU-CS-79-116). 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
78
MILs Continues
• http://www.sei.cmu.edu/str/descriptions/mil_body.html
• Garlan, David & Allen, Robert. "Formalizing Architectural Connection," 71-80. Proceedings of the 16th International Conference on Software
Engineering. Sorrento, Italy, May 16-21, 1994. Los Alamitos, CA: IEEE Computer Society Press, 1994.
•MIL Example:
– See http://www.sei.cmu.edu/str/descriptions/mil_body.html
–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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
79
Mega Programming
•
•
•
•
http://citeseer.nj.nec.com/cache/papers/cs/357/http:zSzzSzwww-db.stanford.eduzSzpubzSzgiozSz1992zSzcacm-final.pdf/wiederhold92towards.pdf
http://citeseer.nj.nec.com/cache/papers/cs/8483/http:zSzzSzwww-db.stanford.eduzSzpubzSzgiozSz1995zSznpgs.pdf/wiederhold96towards.pdf
http://www.cs.brown.edu/publications/techreports/reports/CS-90-20.html
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
80
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
81
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.
WS (1)
WS (…)
UI
UI
UI
Functions..
Functions..
DBMS
WS (n)
•TheMob.com
–depicts what they call an architecture by
showing a functional block diagram.
The System
UI
•TheWBTE.com
– depict what they call an architecture by
showing a logical view of the functional
elements and their interconnection
dependencies.
These depictions and others have been used to describe architectures –
So who is correct ? What’s missing ? What analysis can I perform ?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
Functions..
DBMS
UI
Functions..
DBMS
83
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:
–
–
–
–
–
WS (1)
UI
Functional relationships and Distribution?
Data Topology (Distribution) & Flow ?
Functions..
Control Topology Flow ?
Event Handling ?
•Do the boxes and lines have the same
meaning both internal to an architecture and
Fault-Tolerance ?
across competing architectures ?
WS (…)
WS (n)
UI
UI
Functions..
DBMS
The System
• Operational capabilities:
– How do measure which one is better at
UI
Functions..
DBMS
addressing the issues wrt.:
–Homogenous vs. Heterogeneous systems?
UI
– Expandability ?
Functions..
– Interoperability ?
– Maintainability ?
– Upgradeability ?
DBMS
– Responsiveness ?
•Who do you give the contract to?
–… etc..
•It should be obvious then that there needs to be a better
(more formal) way of describing and evaluating an architecture !
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
84
Industry Concerns
•
•
•
•
http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/roadmap2000/roadmap2000.pdf
http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/mse-ieee97/mse-ieee97.pdf
http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/able/ftp/fmmse-zum94/fmmse-zum94.pdf
http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/sacourse-csee92/sacourse-csee92.pdf
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
85
Research in Architectures
•
•
•
•
•
•
http://www4.in.tum.de/~philipps/pub/fm99.pdf
http://www.cs.toronto.edu/~sme/CSC444F/slides/L19-SoftwareArchitectures.pdf
http://www.di.fc.ul.pt/~mal/papers/fase99.pdf
ftp:se.uwaterloo.ca/~jmatlee/papers/fse00.ps
http://citeseer.nj.nec.com/cache/papers/cs/13115/http:zSzzSzwww4.in.tum.dezSz~philippszSzpubzSz.zSzfm99.pdf/philipps99refinement.pdf
http://seg.iit.nrc.ca/~erdogmus/papers/FormalMethods/AlgThCnf.pdf
•
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:
• http://citeseer.nj.nec.com/cache/papers/cs/13115/http:zSzzSzwww4.in.tum.dezSz~philippszSzpubzSz.zSzfm99.pdf/philipps99refinem
ent.pdf
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
86
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, 1994. 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
87
Issues in Software Architecture
•http://www.sei.cmu.edu/publications/documents/01.reports/01tr035.html
•http://www.sei.cmu.edu/pub/documents/96.reports/pdf/tr008.96.pdf
•http://www.sei.cmu.edu/str/
•http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/aesop-fse2/aesop-fse2.pdf
• Architecture representation: (this session)
– How does one communicate an architecture?
• How does one represent an architectures?: http://www.sei.cmu.edu/ata/arch_rep.html
• 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.: http://www.sei.cmu.edu/ata/ata_extraction.html
• Architecture: Static vs Dynamic View: (covered in another session)
– http://www-old.ics.uci.edu/pub/arch/dynamic-arch.html
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
88
Architecture Representation Concepts
• (Computer 2) Core Architecture Refinement: IEEE Transactions on Software Engineering, Vol 21, No .4 April 1995, pgs 356-372
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
89
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
– What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?
•Usability
– Understandability, Learn ability, Operability
– What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?
•Efficiency
– Time behavior, Resource Behavior
– What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?
•Maintainability
– Analyzability, changeability, Stability, Testability
– What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?
•Portability
– Adaptability, Install ability, Conformance, Replace ability
– What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
90
Architectural Style
• http://www.sei.cmu.edu/publications/documents/99.reports/99tr022/99tr022abstract.html
• http://www.sei.cmu.edu/ata/abas99symp/index.htm
• http://www.sei.cmu.edu/pub/documents/99.reports/pdf/99tr022.pdf
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
91
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. 453-462
• M. Shaw and P. Clements. A Field Boxology: Preliminary Classification of Architectural Styles for Software Systems. April 1996.
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
92
Capturing an Architectural Style
• M. Shaw and P. Clements. A Field Boxology: Preliminary Classification of Architectural Styles for Software Systems. April 1996. (Open Lit.)
• Y. Morisawa et. al Architectural Styles for distributed processing systems and practical selection method Information and Software Technology 44 (2002) 459-472
Style
Constituent Parts
Components
Connectors
Control Issues
Topology
Synchronicity
Data Issues
Binding
Time
Topology
Continuity
Control/Data
Interaction
Mode
Binding
Time
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
93
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, AddisonWesley, 1995, Chapter 24, pp. 453-462
• M. Shaw and P. Clements. A Field Boxology: Preliminary Classification of Architectural
Styles for Software Systems. April 1996.
• Data Flow
– (1) Batch Sequential (traditional systems) & Pipeline Systems
– (2) Pipes & Filters (Linked Stream transformers)
• (13) Distributed Processing Styles
• (14) Process Control Style
• (15) :
• (16) :
• 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
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
94
Batch Sequential
• http://www-2.cs.cmu.edu/afs/cs/project/tinker-arch/www/html/1998/Lectures/06.dataflow/quick_index.html
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
95
Suggested Batch Sequential Style
Scheduler
Program 1
Data
Store
(1)
Program 2
Data
Store
(2)
Program (n)
Components are the Programs and Data stores.
Connectors are one way pipes that transfer bulk data sets.
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
96
Pipe & Filter (Pipeline)Architecture Styles
• http://www-2.cs.cmu.edu/afs/cs/project/tinker-arch/www/html/1998/Lectures/06.dataflow/base.012.html
• http://hebb.cis.uoguelph.ca/~dave/27320/new/architec.html
• http://hebb.cis.uoguelph.ca/~dave/27320/new/architec.html
• 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
Fall 2002
Program 2
Program (n)
http://www.sei.cmu.edu/about/disclaimer.html
• Can I embed commands and data CS-545-Fall-2002
together and have the stream self executing?
97
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
98
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
http://www.sei.cmu.edu/about/disclaimer.html
Main Frame
CS-545-Fall-2002
99
Call & Return Style: File Sharing
• http://www.dafscollaborative.org/press/whitepaper.pdf
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
100
Suggested File Sharing Architecture
Application
Application (n)
:
Buffer
Data
Buffer
Control
Buffer
:
Buffer
:
File
Fall 2002
Main frame
File (n)
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
101
Data Abstraction & OO Architecture
• http://hebb.cis.uoguelph.ca/~dave/27320/new/architec.html
• Barber, K.S.; Graser, T.J. Tool support for systematic class identification in object-oriented software architectures, Technology of Object-Oriented Languages and Systems,
2000. TOOLS-Pacific 2000. Proceedings. 37th International Conference on , 2000, Page(s): 82 –93
• Taylor, P. Designing persistent object-oriented software architectures, Technology of Object-Oriented Languages, 1998. TOOLS 28. Proceedings , 1998, Page(s): 14 –26
• Bosch, J. Specifying frameworks and design patterns as architectural fragments, Technology of Object-Oriented Languages, 1998. TOOLS 27. Proceedings, 1998, Page(s):
268 -277
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
102
Hierarchical Layered Architecture Styles
• Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996.
http://hebb.cis.uoguelph.ca/~dave/27320/new/architec.html
•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.
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
GUI
Application Layer
DBMS
OS Layer
103
Hierarchical Layered Architecture Styles
• http://www.crystalclearsoftware.com/cgi-bin/arch_patterns/wiki.pl?Pattern_Analysis/Layers
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
104
Hierarchical Layered Architecture Styles
• http://www.crystalclearsoftware.com/cgi-bin/arch_patterns/wiki.pl?Pattern_Analysis/Layers
• http://martinfowler.com/isa/layers.html
•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
• (http://c2.com/ppr/envy/#well_encapsulated_code)
–Layered architecture
–Layers (from POSA1)
–Patterns for generating a layered architecture
–Relational database access layer
GUI
Application Layer
DBMS
OS Layer
• (http://www.objectarchitects.de/ObjectArchitects/orpatterns/index.htm?Performance/performa
nce.htm)
•Secure access layer (analysis)
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
105
Hierarchical Layered Architecture Styles
• Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996.
http://hebb.cis.uoguelph.ca/~dave/27320/new/architec.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
106
Communicating Processes
• http://www.crystalclearsoftware.com/cgi-bin/arch_patterns/wiki.pl?Architecture_Patterns_Home
• http://www.crystalclearsoftware.com/cgi-bin/arch_patterns/wiki.pl?Pattern_Analysis/Communicating_Processes
• http://www.industriallogic.com/patterns/P02.pdf
•Each component has it's own thread of execution.
•The Provider/Observer Role Pattern
•The components are the objects
•Push and Pull Interaction Patterns
and connectors operate through
message passing.
•Opaque Interaction Patterns
–Synchronous Opaque Interaction Patterns
–Asynchronous Opaque Interaction Patterns
•Components are often in separate
process spaces
•Monitorable Interaction Patterns
–Pull-Monitorable Interaction Patterns
–Push-Monitorable Interaction Patterns
Object 1
Object 2
•Abortable Interaction Patterns
–Abortable Async Opaque Interaction Patterns
–Abortable Pull-Monitorable Interaction Patterns
–Abortable Push-Monitorable Interactions Patterns
•Handshaking Patterns
•Combining Patterns
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
107
Independent Components:Event Based Architecture Styles
• Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996.
• http://hebb.cis.uoguelph.ca/~dave/27320/new/architec.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
108
Event Based Architecture Styles
• Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996.
• http://hebb.cis.uoguelph.ca/~dave/27320/new/architec.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
109
Event Based Architecture Styles
• Using Events to build Distributed Systems (Open Lit)
– http://citeseer.nj.nec.com/cache/papers/cs/618/ftp:zSzzSzftp.cl.cam.ac.ukzSzoperazSzevent.pdf/bacon96u
sing.pdf
– http://citeseer.nj.nec.com/cache/papers/cs/16314/http:zSzzSzwww.cs.tamu.eduzSzcourseinfozSzcpsc609zSzspring98zSzlivelyzSzp76-waldo.pdf/waldo99jini.pdf
• 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)
Event
Registration
Lookup
Service
(1)
Lookup
Service
(n)
Service
Registration
Event
Notification
Service
Provider
Client
(n)
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
Communication with Service
110
Interpreter Architecture Styles
• Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996.
• http://hebb.cis.uoguelph.ca/~dave/27320/new/architec.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
111
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.
GUI
(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)
Text Processor
(defclass aTractor :bindsTo (Tractor tractor Tractor ctr))
(defclass aCustomer :bindsTo (Customer customer))
on-line
(defclass simpleOption
interpreter,
:bindsTo (aDriver driver aDriver hoursToDate
Compiler
aDriver hrsThisMonth aTractor tractor aTractor ctr
aCustomer customer) :Float pw)
(defclass PlanNode
:Driver driver :Tractor tractor :Customer customer :PlanNode parent :Float pw :Float fw)
•
•
•
•
•
•
•
Data Store
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.
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
112
Rule Based Style
• 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
Inputs
Knowledge base
Working
Memory
Data &
Updates
Rule
base
Fact
memory
Active Rules
& Facts
New Facts
New Active Rules
Trigger Data
Outputs
Rule
Interpreter
Selected Rule
Selected Data
Rule &
Data Element
Selection
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
113
Rule-Based Style
•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
Inputs
Knowledge base
Working
Memory
Data &
Updates
Rule
base
Inactive Inactive
Rules
Facts
Fact
memory
Active
Rules
Active Rules
& Facts
New Facts
New Active Rules
Trigger Data
Outputs
Rule
Interpreter
Selected Rule
Selected Data
Rule &
Data Element
Selection
Next Action
Incomplete
Procedures
Control
Procedures
Fall 2002
Active
Facts
Activation/
Deactivation
Active Rules & Facts
Unfinished Action
Execution
Stack
Why the Distinction
Between
Inactive & Active?
What Architectural
Style would we
have if this data was
maintained remotely?
Trigger
Data
Interpreter Outputs
Selected
Actions
Delete
Completed
Activations
Matching
Rule/Data
Pairs
Data Flow Network
for Partially
Evaluated Rule Sets
Prioritized
Scheduler Activations Agenda
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
Rule &
Fact
Compiler
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
Candidate
Rule/Data
Activations
Meta Control Rules
114
Data Repository Architecture Styles
• Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996.
• http://hebb.cis.uoguelph.ca/~dave/27320/new/architec.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
115
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
116
Repository: Client-Server Cont.
• http://www.sei.cmu.edu/str/descriptions/clientserver.html#777375
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
117
Client Server Architecture Types
• http://www.sei.cmu.edu/str/descriptions/clientserver.html#777375
• http://www.sei.cmu.edu/str/descriptions/clientserver_body.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
118
Two Tiered Client-Server Architectures
• http://www.sei.cmu.edu/str/descriptions/twotier.html#512860
•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
Fall 2002
Data
http://www.sei.cmu.edu/about/disclaimer.html
Store
CS-545-Fall-2002
119
Two Tiered Client-Server Architectures
• http://www.sei.cmu.edu/str/descriptions/twotier.html#512860
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
120
Two Tiered VS Three Tiered C/S
Thin
Clients
Middle
Tier
Fat
Clients
DBMS
Engine
DBMS
Engine
Data
Store
Fall 2002
Data
Store
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
121
Three Tiered Client-Server Architectures
• http://www.sei.cmu.edu/str/descriptions/threetier.html#34492
• http://www.sei.cmu.edu/str/descriptions/distcoll.html#785809
• http://ei.cs.vt.edu/~cs6704/3Tier.ppt.
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
122
Three tier with transaction processing monitor technology
• http://www.sei.cmu.edu/str/descriptions/threetier.html#34492
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
123
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
124
Three tier with message server
• http://www.sei.cmu.edu/str/descriptions/threetier.html#34492 (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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
125
Three tier with an application server (TTAS).
• http://www.sei.cmu.edu/str/descriptions/threetier.html#34492
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
126
Three tier with an ORB architecture
• http://www.sei.cmu.edu/str/descriptions/threetier.html#34492
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
127
Distributed/collaborative enterprise architecture
• http://www.sei.cmu.edu/str/descriptions/clientserver.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
128
Distributed/collaborative enterprise architecture
• http://www.sei.cmu.edu/str/descriptions/distcoll.html#785809
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
129
Distributed/collaborative enterprise architecture (DCAE)
• http://www.sei.cmu.edu/str/descriptions/distcoll.html#785809
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
130
Distributed/collaborative enterprise architecture
• http://www.sei.cmu.edu/str/descriptions/distcoll.html#785809
• http://www.ca.sandia.gov/8900/research/scieng_prbslv_ext.html
• http://www.bib.ecs.soton.ac.uk/data/1367/html/html/
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
131
Hypertext Style
• Reflections on "Seven Issues": Hypertext in the Era of the Web Frank G. Halasz [email protected]
• 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, 1991. 'Decision Aiding for
Complex Systems,Conference Proceedings., 1991 IEEE International Conference on , 1991, Page(s): 2049 -2054 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
127-145
• http://www.elsinnet.org.uk/abstracts/aom/gra-aom.htm
• http://wwwis.win.tue.nl/2L670/static/architecture.html
• http://wwwis.win.tue.nl/2L670/static/bib.html#DBHK92
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
132
HAM Reference Model : Hypertext Style
• http://wwwis.win.tue.nl/2L670/static/ham.html
• 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
http://www.sei.cmu.edu/about/disclaimer.html
133
Trellis Reference Model : Hypertext Style
• http://wwwis.win.tue.nl/2L670/static/trellis.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
134
Dexter Reference Model : Hypertext Style
• http://wwwis.win.tue.nl/2L670/static/dexter.html
• 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 datacontaining "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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
135
A Formal Model of Hypertext
• http://wwwis.win.tue.nl/2L670/static/lange.html
• http://wwwis.win.tue.nl/2L670/static/lange-oomodel.html
• 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 hyperdocuments. 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 hyperdocument 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
136
Tower Reference Model: Hypertext Style
• http://wwwis.win.tue.nl/2L670/static/tower.html
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
137
Blackboard Style
• http://www.cs.virginia.edu/~acc2a/techie/notes/blkbrds.htm
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
138
BB Architecture Overview
•Penny Nii, Blackboard Systems at the Architecture Level, Expert Systems with Applications, Vol 7, pp43-54, 1994
Blackboard
Layers
KS
KS
KS
KS
KS
Control
Data
Fall 2002
Controller
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
139
Repository Architecture Styles: Blackboard
• Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996.
• http://techreports.larc.nasa.gov/ltrs/PDF/conf-10-dasc.pdf
• P. Nii, "Blackboard Systems: The Blackboard Model of Problem Solving and the Evolution of Blackboard Architectures",
AI Magazine, Summer 1986, pp. 38
• http://www-2.cs.cmu.edu/afs/cs/project/tinker-arch/www/html/1998/Lectures/20.Blackboard/base.000.html
• http://www.cs.virginia.edu/~acc2a/techie/notes/blkbrds.htm
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
140
Repository Architecture Styles: Blackboard
• http://www.cs.virginia.edu/~acc2a/techie/notes/blkbrds.htm
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
141
Repository Architecture Styles: Blackboard
• http://www.cs.virginia.edu/~acc2a/techie/notes/blkbrds.htm
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
142
Repository Architecture Styles: Blackboard
• http://www.cs.virginia.edu/~acc2a/techie/notes/blkbrds.htm
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
143
Repository Architecture Styles: Blackboard
• http://www.cs.virginia.edu/~acc2a/techie/notes/blkbrds.htm
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
144
Uses of the Blackboard Style
• http://www.cs.virginia.edu/~acc2a/techie/notes/blkbrds.htm
•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..
Fall 2002
•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.
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
145
Repository Architecture Styles: Blackboard
•
•
•
•
•
http://www.cs.virginia.edu/~acc2a/techie/notes/blkbrds.htm
A task Allocation Model For Distributed Computing Systems, IEEE Transactions on Computers, Vol. C-31, No. 1 41-47, January 1982
Optimal File Allocation in a Multiple Computer System, IEEE Transactions on Computers, Vol. C-18, No. 10, 885-889, Oct 1969
Load Balancing in Distributed Systems, IEEE Transactions on Software Engineering, Vol. SE-8, No. 401-412, 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
146
Repository Architecture Styles: Blackboard
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
147
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
148
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
Fall 2002
Note the Independence of
each KS
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
149
Simple BB Example C++ Code Snippet Cont.
•void execTaskList(taskInstance tl[])
•taskInstance initTaskList[]=
{
{tskWindows,0},
{tskInitialize,0},
{tskDisplay,0},
{tskDisplayDebug,0},
{tskNoTask,0}
};
•taskInstance suTaskList[]=
{
{tskWindows,0},
{tskInputs,0},
{tskErrorHandle,0},
{tskPowerOn,0},
:
{tskOutputs,0},
{tskNoTask,0}
};
: // Situation Specific Task Lists
{ // 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
•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
}; http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
150
Simple BB Example C++ Code Snippet
class TCB; // Task Control Block
typedef int (*pfunc)(TCB *);
•TCB allTasks[]={
class TCB // task control block {
•{TASK,"No Task",NULL,NULL,TASK_TIMER,0,
NULL ,0,NULL,NULL,NULL},
public:
int type;
char *name;
•{TASK,"Windows Handler"
,&rqst[tskWindows],
&sema[tskWindows],TASK_TIMER,0,
windowsControlStates,0,NULL ,NULL,NULL},
// TASK control block
// name
int *rqst;
// Have I been Requested ?
int *sema;
// Am I Busy ?
int priority;
// my Priority, 0 = HIGHEST
int currentFrameTime;
•{TASK,"Initialize",
&rqst[tskInitialize],
&sema[tskInitialize],TASK_TIMER,0,
initVarStates,0,NULL ,NULL,NULL},
// 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
•{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},
void execTask();
void execReset();
void init();
int timeout();
};
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
•{TASK,"PowerOnTest" ,
&rqst[tskPowerOn]
,
&sema[tskPowerOn],TASK_TIMER,0,
powerOnStates ,0,NULL ,NULL,NULL},
•: }
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
151
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) 459-472
• ISO/IEC 10026-1 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
Fall 2002 with a client request http://www.sei.cmu.edu/about/disclaimer.html
152
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) 459-472
• ISO/IEC 10026-1 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
Fallapplications
2002
or systems. http://www.sei.cmu.edu/about/disclaimer.html
153
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
– Channel has fixed capacity
– 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
154
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
155
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) 459-472
• ISO/IEC 10026-1 Information Technology – Open Systems Interconnection, Distributed Transaction Processing Part 1, OSI TP Model, 1992
• http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation_2up.pdf
• 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
Distributed
• Location of Data
•Processing Types
between C/S
• Processing Type
Between Servers
Centralized
Synchronous
Asynchronous
Distributed
Transactions
Asynchronous
Transactions
• Msg. Type
Synchronous Processing
Transaction Type
(ACID)
Query Type
Asynchronous Processing
Fall 2002
Notification Type
Centralized Transactions
Centralized
Query
Distributed Query
Asynchronous Query
Centralized Notification
Distributed
Notification
Asynchronous Notification
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
156
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
157
Distributed Processes Architecture Styles
• Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996.
• http://hebb.cis.uoguelph.ca/~dave/27320/new/architec.html
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
158
Process Control Architecture Styles
• Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996.
• http://hebb.cis.uoguelph.ca/~dave/27320/new/architec.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
159
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.
http://hebb.cis.uoguelph.ca/~dave/27320/new/architec.html
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
160
CS-545
Week 6
Case Studies
(Domain Specific Architectures)
Case Studies
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
162
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
Input
Medium
Characters
Index
Alphabetized Index
Output
Medium
• Disadvantages:
• Advantages:
–Change in data storage format
affects all modules
– Ease of Upgrade to different
algorithms?
– Reusable in different
What are the different considerations for a local vs
distributed homogeneous vs distributed heterogeneous
domains?
–Efficient Control Flow Mechanism
–Efficient Data Representation
–Efficient Data Flow between
modules
system ?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
163
Abstract Data Types
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996
Subroutine Calls
Master Control
Output
Input
Ith
Circular Shift
Alpha
Word
Char
Set Char
Characters
Setup
Word
Char
Set Char
Input
Medium
Output
Medium
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.
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
What are the different
considerations for a local vs
distributed homogeneous vs
distributed heterogeneous
system ?
164
Implicit Invocation
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996
Master Control
Input
I th
Delete
Lines
Alphabetizer
Insert
I th
Delete
Insert
Input
Medium
Circular Shift
Subroutine Calls
Output
Output
Medium
Lines
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
165
Pipes & Filters
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996
Input
Circular Shift
Alphabetizer
Output
Output
Medium
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
166
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
0
+2
0
0
:
•Quality attribute concerns at each level of the architecture will swing the vote further
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
167
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.
• How does the user interact with it ?
What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
168
Case Studies
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
Couple
Acquire
To:X-Y
Filter (n)
Clip
Control Variables
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
169
What are the different considerations for a local vs distributed homogeneous vs distributed heterogeneous system ?
Ch. 3 Case Studies
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
170
Case Studies
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
171
Case Studies
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
172
Case Studies
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
173
Case Studies
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
174
Case Studies
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
175
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
176
Case Studies
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
177
Case Studies
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
178
Case Studies
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
179
Case Studies
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
180
Case Studies
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
181
Case Studies
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
182
Case Studies
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
183
Case Studies
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
184
Case Studies
• 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 does your answer
change for a local vs
distributed homogeneous
vs distributed
heterogeneous system ?
• 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 ?
 How Updated ?
– Identify the QA impacts to the architecture at each level.
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
185
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
186
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
187
Case Studies
– 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
188
Case Studies
• 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
Inputs
Knowledge base
Working
Memory
Data &
Updates
Rule
base
Fact
memory
Active Rules
& Facts
New Facts
New Active Rules
Trigger Data
Outputs
Rule
Interpreter
Selected Rule
Selected Data
Select and and Execute
Rules based on the
Current State
and Derived Facts
Rule &
Data Element
Selection
•What are the different
considerations for a local vs
distributed homogeneous vs
•The Example in the book shows how the Architecture Elements
distributed heterogeneous
system ?
For a Rule-based Systems are realized using a number of
Architecture Types.
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
189
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
190
Case Studies
•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
Inputs
Data &
Updates
Rule
base
Inactive Inactive
Rules
Facts
Fact
memory
Active
Rules
Active Rules
& Facts
New Facts
New Active Rules
Trigger Data
Outputs
Rule
Interpreter
Selected Rule
Selected Data
Rule &
Data Element
Selection
Next Action
Incomplete
Procedures
Control
Procedures
Fall 2002
Active
Facts
Activation/
Deactivation
Active Rules & Facts
Unfinished Action
Execution
Stack
So why the
Distinction Between
Inactive & Active?
What Architectural
Style would we
have if this data was
maintained remotely?
Knowledge base
Working
Memory
Trigger
Data
Interpreter Outputs
Selected
Actions
Delete
Completed
Activations
Matching
Rule/Data
Pairs
Data Flow Network
for Partially
Evaluated Rule Sets
Prioritized
Scheduler Activations Agenda
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
Rule &
Fact
Compiler
Rule &
Fact
Compiler
Candidate
Rule/Data
Activations
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
Meta Control Rules
191
Case Studies
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
192
CS-545
Week 7
Case Studies
(Domain Specific Languages)
Domain Specific Languages: PLP
• http://compose.labri.u-bordeaux.fr/overview/overview.en.php3#dsl
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
194
Domain Specific Languages: SLP
• http://compose.labri.u-bordeaux.fr/overview/overview.en.php3#dsl
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
195
Domain Specific Languages: SLP
• http://compose.labri.u-bordeaux.fr/overview/overview.en.php3#dsl
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
196
Why Use a DSL
• http://compose.labri.u-bordeaux.fr/overview/overview.en.php3#dsl
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
197
Domain Specific Languages: SAP
• http://compose.labri.u-bordeaux.fr/overview/overview.en.php3#dsl
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
198
Domain Specific Languages: SAP
• http://compose.labri.u-bordeaux.fr/overview/overview.en.php3#dsl
•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 highlyparameterized 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
199
Domain Specific Languages: SAP
• http://compose.labri.u-bordeaux.fr/overview/overview.en.php3#dsl
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
200
When to Develop a DSL
• http://compose.labri.u-bordeaux.fr/overview/overview.en.php3#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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
201
How does one Develop a DSL ?
• http://compose.labri.u-bordeaux.fr/overview/overview.en.php3#dsl
• D.L. Parnas. On the design and development of program families. IEEE Transactions on Software Engineering, 2:1-9, March 1976.
• http://citeseer.nj.nec.com/cache/papers/cs/22112/http:zSzzSzdivcom.otago.ac.nzzSzinfoscizSzpublctnszSzcompletezSzpaperszSzdp
2001-08.pdf/cranefield01generating.pdf
• http://citeseer.nj.nec.com/cache/papers/cs/8161/http:zSzzSzwww.aifb.uni-karlsruhe.dezSzWBSzSzdfezSziii99zSzcrainfield-ijcai99iii.pdf/cranefield99uml.pdf
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
202
How does one Develop a DSL ?
• http://compose.labri.u-bordeaux.fr/overview/overview.en.php3#dsl
• D.L. Parnas. On the design and development of program families. IEEE Transactions on Software Engineering, 2:1-9, March 1976.
• http://citeseer.nj.nec.com/cache/papers/cs/22112/http:zSzzSzdivcom.otago.ac.nzzSzinfoscizSzpublctnszSzcompletezSzpaperszSzdp200108.pdf/cranefield01generating.pdf
• http://citeseer.nj.nec.com/cache/papers/cs/8161/http:zSzzSzwww.aifb.uni-karlsruhe.dezSzWBSzSzdfezSziii99zSzcrainfield-ijcai99iii.pdf/cranefield99uml.pdf
–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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
203
How does one Develop a DSL ?
• http://citeseer.nj.nec.com/cache/papers/cs/22112/http:zSzzSzdivcom.otago.ac.nzzSzinfoscizSzpublctnszSzcompletezSzpaperszSzdp200108.pdf/cranefield01generating.pdf
• http://citeseer.nj.nec.com/cache/papers/cs/8161/http:zSzzSzwww.aifb.uni-karlsruhe.dezSzWBSzSzdfezSziii99zSzcrainfield-ijcai99iii.pdf/cranefield99uml.pdf
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
204
How does one Develop a DSL ?
• http://citeseer.nj.nec.com/cache/papers/cs/22112/http:zSzzSzdivcom.otago.ac.nzzSzinfoscizSzpublctnszSzcompletezSzpaperszSzdp
2001-08.pdf/cranefield01generating.pdf
• http://citeseer.nj.nec.com/cache/papers/cs/8161/http:zSzzSzwww.aifb.uni-karlsruhe.dezSzWBSzSzdfezSziii99zSzcrainfield-ijcai99iii.pdf/cranefield99uml.pdf
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
205
How does one Develop a DSL ?
• http://www.cwi.nl/~arie/papers/dslbib/index.html
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
206
How does one Develop a DSL ?
• http://www.cwi.nl/~arie/papers/dslbib/index.html
• 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 domainspecific 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
207
How does one Develop a DSL ?
• http://www.cwi.nl/~arie/papers/dslbib/index.html
• Coplien, D. Hoffman, and D. Weiss. Commonality and variability in software engineering. IEEE Software, pages 37-45, November/December 1998.
• http://www.hep.net/chep95/html/slides/it14/it14.pdf
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
208
DSL Pros & Cons
• http://www.cwi.nl/~arie/papers/dslbib/index.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
209
DSL Pros & Cons
• http://www.cwi.nl/~arie/papers/dslbib/index.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
210
Using UML & OCL to Capture a DSL
• http://citeseer.nj.nec.com/cache/papers/cs/22112/http:zSzzSzdivcom.otago.ac.nzzSzinfoscizSzpublctnszSzcompletezSzpaperszSzdp200108.pdf/cranefield01generating.pdf
• http://citeseer.nj.nec.com/cache/papers/cs/8161/http:zSzzSzwww.aifb.uni-karlsruhe.dezSzWBSzSzdfezSziii99zSzcrainfield-ijcai99iii.pdf/cranefield99uml.pdf
•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 interchange
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
211
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
212
CS-545
Week 8
Developing an Architecture
Given Set of Requirements, how do we
choose the best Architecture?
Architecture Design Alternatives
• http://www.sei.cmu.edu/publications/documents/01.reports/01tr035.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
214
Which Architectural Style or Styles should I use?
• http://www.sei.cmu.edu/publications/documents/01.reports/01tr035.html
• Jan Bosch, Design & Use of Software Architectures: Adopting and Evolving a Product Line Approach: ISBN: 0201674947
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
215
From Requirements to Design
•
•
Jan Bosch, Design & Use of Software Architectures: Adopting and Evolving a Product Line Approach: ISBN: 0201674947
http://www.sei.cmu.edu/publications/documents/01.reports/01tr035.html
•
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
216
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
217
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.
– QFD for Support and Correlation strengths and weaknesses
•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
– QFD for Support and Correlation strengths and weaknesses
•Select and Perform the transformation
– Select the design pattern
– Reorganize the functionality to suite the selected pattern.
•Update Design Space analysis
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
218
Architecture Analysis and
the Quality Attributes
Architectural Analysis
•ATAM:
Architecture trade-Off Analysis
– http://citeseer.nj.nec.com/cache/papers/cs/5585/http:zSzzSzwww.sei.cmu.eduzSzpubzSzdocumentszSz94.reportszSzpszSztr10.94.pdf/kazman94toward.pdf
– http://citeseer.nj.nec.com/cache/papers/cs/1457/ftp:zSzzSzftp.cc.gatech.eduzSzpubzSzcoczSztech_reportszSz1995zSzGIT-CC-95-41.pdf/kazman96scenariobased.pdf
•SAAM:
Software Architecture trade Off Analysis
– http://citeseer.nj.nec.com/cache/papers/cs/611/http:zSzzSzwww.cc.gatech.eduzSzclasseszSzcs8112mzSzwi95zSz..zSzpaperszSzICSE-16.pdf/kazman94saam.pdf
•ABAS:
Attribute Based Architectural Styles
– http://citeseer.nj.nec.com/cache/papers/cs/8382/http:zSzzSzwww.sei.cmu.eduzSzpubzSzdocumentszSz99.reportszSzpdfzSz99tr022.pdf/klein99attributebased.pdf
– http://citeseer.nj.nec.com/cache/papers/cs/11557/http:zSzzSzwww.bell-labs.comzSzuserzSzdepzSzprofzSzwicsa1zSzfinalzSzkazman.pdf/klein99attributebased.pdf
•ARID:
Active reviews for Intermediate Designs
– http://www.sei.cmu.edu/publications/documents/00.reports/00tn009.html
•SNA: Survivable Network Analysis Method
– http://www.cert.org/sna/
– http://www.sei.cmu.edu/publications/documents/00.reports/00tr013.html
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
220
Architecture Trade-Off Analysis Method
• http://www.cse.dcu.ie/essiscope/sm2/9126ref.html
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
221
Architecture Trade-Off Analysis Method
• http://www.cse.dcu.ie/essiscope/sm2/9126ref.html
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
222
ATAM Continued
• http://www.cse.dcu.ie/essiscope/sm2/9126ref.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
223
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
224
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
225
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
226
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
227
ATAM Products
• Paul Clements, et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
228
ATAM QA mapped to ISO QA
• Paul Clements, et al, Evaluating Software Architectures, Methods
& Case Studies, Addison-Wesley, ISBN 0-201-70482-X
•ISO/IEC 9126: Information Technology – Software Product Evaluation –
Quality characteristics and guidelines for their use, 1991.
•Functionality:
•Functionality
–Security:
•Reliability:
–Availability:
•Suitability, Accuracy, Interoperability, Compliance,
Security
•Reliability
•Maturity, Fault-Tolerance, Recoverability
•Usability
•(Efficiency)
–Performance:
•(Maintainability)
–Modifiability:
–Subsetability:
–Conceptual Integrity:
–Variability:
•Portability:
Fall 2002
•Understandability, Learn ability,
Operability
•Efficiency
•Time behavior, Resource Behavior
•Maintainability
•Analyzability, changeability, Stability, Testability
•Portability
http://www.sei.cmu.edu/about/disclaimer.html
• Adaptability, Install
CS-545-Fall-2002
ability
ability, Conformance, Replace
229
Issues with Quality Attributes
• Paul Clements, et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-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)
– A system is secure (or not)
– A system is reliable (or not)
– A system performs (or not)
– A system is suitable (or not)
–:
wrt a specific kind of change
wrt a specific kind of threat
wrt a specific kind of fault.
wrt a specific perf. criteria
wrt an envisioned product line
– See the other ISO Quality Attributes:
• http://www.cse.dcu.ie/essiscope/sm2/9126ref.html
– 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
230
ATAM in Practice: 9 Step Program
• Paul Clements, et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-X
• Toward Deriving Software Architectures From Quality Attributes
– http://citeseer.nj.nec.com/cache/papers/cs/5585/http:zSzzSzwww.sei.cmu.eduzSzpubzSzdocumentszSz94.reportszSzpszSztr10.94.pdf/kazman94toward.pdf
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
231
ATAM in Practice: Present the ATAM
• Paul Clements, et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-X
• Scenario based Analysis of Software Architecture
– http://citeseer.nj.nec.com/cache/papers/cs/1457/ftp:zSzzSzftp.cc.gatech.eduzSzpubzSzcoczSztech_reportszSz1995zSzGIT-CC-95-41.pdf/kazman96scenariobased.pdf
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
232
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
233
ATAM in Practice: Present the Business Drivers
• Adapted from: Paul Clements, et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
234
ATAM in Practice: Present the Business Drivers
• Adapted from: Paul Clements, et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
235
ATAM in Practice: Present the Business Drivers
• Adapted from: Paul Clements, et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
236
ATAM in Practice: Present the Business Drivers
• Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
237
ATAM in Practice: Present the Architecture
• Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-X
•Define the architectural constraints
– Requirement constraints
– Development constraints
– Test Constraints
– Manufacturing Constraints
– Installation Constraints
– Operational Constraints
– Training Constraints
– Deployment Constraints
– Transportation Constraints
Fall 2002
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
238
ATAM in Practice: Present the Architecture
• Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
239
ATAM in Practice: Identify Architecture Approaches
• Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
240
ATAM in Practice: Generate the Quality Attribute Utility Tree
• Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-X
• Adapted from : ISO/IEC 9126: Information Technology – Software Product Evaluation – Quality characteristics and guidelines for their use,
1991.
Functionality
Reliability
Usability
Utility
•Each ISO QA is decomposed
into a set of design specific
analyses, verifications, and
scenarios for YOUR domain.
Efficiency
• These attributes are the KEY
to the success of your system.
Maintainability
• Get the stakeholders concerns
Portability
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
241
Functionality Quality Attribute Utility Tree Decomposition
Example
• Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-X
• Adapted from: ISO/IEC 9126: Information Technology – Software Product Evaluation – Quality characteristics and guidelines for their use,
1991.
Operators
Suitability
Functionality
Trainers
Installers
Accuracy
:
Algorithm Precision
:
Data Precision
Reliability
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
:
Security
Data Access
Portability
Fall 2002
ISO
•Domain
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
External Program Access
Specific concerns examples
242
Reliability Quality Attribute Utility Tree Decomposition
• Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-X
• Adapted from: ISO/IEC 9126: Information Technology – Software Product Evaluation – Quality characteristics and guidelines for their
use, 1991.
Functionality
Reliability
Utility
Background BIT
Maturity
Fault-Tolerance
Usabilit
y
Detection
Isolation
Commanded BIT
Handling
Reporting
Efficienc
y
Resumption of Service
:
Maintainability
Recoverability
Portability
Fall 2002
ISO
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
DB Recovery
•Domain Specific concerns examples
243
Usability Quality Attribute Utility Tree Decomposition
• Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-X
• Adapted from: ISO/IEC 9126: Information Technology – Software Product Evaluation – Quality characteristics and guidelines for their use,
1991.
Functionalit
y
Installers
Understandability
Maintainers
:
Reliability
Operators
Utility
Trainers
Usability
Learn ability
Dedicated Training Time
:
Efficiency
OJT Training Time
Personnel Requirements
Maintainability
:
Operability
Workstation Requirements
Portability
Fall 2002
ISO
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
•Domain Specific concerns examples
244
Efficiency Quality Attribute Utility Tree Decomposition
• Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-X
• Adapted from: ISO/IEC 9126: Information Technology – Software Product Evaluation – Quality characteristics and guidelines for their use,
1991.
Concurrency
Functionality
:
Reliability
Time Behavior
Synchronization
Start Constraints
Utility
:
Usabilit
y
Completion Constraints
Resource Behavior
Processor Loading & Performance
Memory Loading & Performance
Efficiency
Interface Loading & Performance
:
Data Storage Loading &
Performance
Maintainability
Portability
ISO
•Domain Specific concerns examples
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
245
Maintainability Quality Attribute Utility Tree Decomposition
• Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-X
• Adapted from: ISO/IEC 9126: Information Technology – Software Product Evaluation – Quality characteristics and guidelines for their use,
1991.
Functionality
Analyzability
Health & Status
Logging
Global Logging
Event Logging
Reliability
Trending
MTBF
Usability
Utility
Local Logging
Stability
Number of Failures
HW Update Design
Efficiency
MTTR
Changeability
SW Update Design
Testing Sequence
Maintainability
Subsetability Sequence
Portability
Testability
Testing Equipment
ISO
•Domain Specific concerns examples
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
246
Portability Quality Attribute Utility Tree Decomposition
• Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-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
Different HW Platform
Reliability
Installability
Utility
Remote
Distributed
Usability
Efficiency
Local
Existing HW
Conformance
Planned HW
Maintainability
Replaceability
On-Line
Portability
ISO
•Domain Specific concerns examples
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
247
Maintainability Domain Specific Quality Attribute
Utility Tree Expansion Example
• Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-X
• Adapted from: ISO/IEC 9126: Information Technology – Software Product Evaluation – Quality characteristics and guidelines for their
use, 1991.
HW Update
Functionality
Analyzability
Add CORBA MW
in 6 months
(X,Y)
Reliability
SW Update
Stability
Change Web UI
in 2 months
Usability
Utility
(X,Y)
MTTR
Efficiency
Changeability
Maintainability
Portability
Testability
•(X,Y) Prioritization
•(X) = Importance
•(Y) = Difficulty
•Now define a Use Case
that encompasses
these actions !! (QA Scenarios)
ISO
•Domain Specific Expansion
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
248
ATAM in Practice: Analyze the Architectural Approaches
• Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
249
Architectural Analysis Template Example
• Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-X
Scenario (XXX) Analysis
Scenario #
Scenario Name
Add CORBA MW in 6 months
Quality Attribute
Attributed Related Stimuli:
Attributed Related Response:
Notes:
Issues:
Assumptions:
Fall 2002
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
Decision Reason
NR-4
AS-103
Watchdog timer removal
Decision Reason
AS-104
Heartbeat removal
Decision Reason
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
T-1
R-6
NR-5
250
Performance Quality Attribute Characterization Example
• Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-X
Architectural Stimuli
Performance
Architectural Decisions
Architectural Responses
Fall 2002
•Events that cause the
architecture to change that
affect this quality attribute
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
251
Performance Stimuli Characterization Example
• Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-X
Architectural Stimuli
Internal Event
Source
Clock Event
External Event
:
Performance
Architectural
Decisions
Arrival
Pattern
Periodic
:
A periodic
:
:
Architectural Responses
Fall 2002
Distribution
You must define these and the
specific stimuli for your
architecture and domain
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
sporadic
252
Performance Decision Characterization Example
• Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-X
Resource Type
Architectural Stimuli
Memory
Resource Scheduling
Resource Allocation
Performance
Processors
Networks
:
Architectural Decisions
Resource Consumption
:
Architectural Responses
Fall 2002
You must define the specific
decisions for your architecture
http://www.sei.cmu.edu/about/disclaimer.html
and domain
253
CS-545-Fall-2002
Performance Response Characterization Example
• Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
254
ATAM in Practice: Brainstorm
& Prioritize Scenarios
• Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-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 ….
– Develop additional scenarios as appropriate
• Review Exploratory Scenarios
– Improve reliability….
– Develop additional scenarios as appropriate
• Analyze the Architectural Approaches against these new scenarios
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
255
ATAM in Practice: Present
the Results
• Adapted from: Paul Clements et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-X
• Documented Architecture Approaches
• Prioritized Scenarios
• Attribute based Questions
• The Utility Tree
• Risks and Non-Risks Identified
• The trade studies identified
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
256
SAAM in Practice: 6 Step Program
• Paul Clements, et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-X
• Toward Deriving Software Architectures From Quality Attributes
– http://citeseer.nj.nec.com/cache/papers/cs/5585/http:zSzzSzwww.sei.cmu.eduzSzpubzSzdocumentszSz94.reportszSzpszSztr10.94.pdf/kazman94toward.pdf
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
257
SAAM Results
•Architecture (1)
Scenario
Number ID
Priority
Description
Direct –
Indirect
Items
Requiring
change
Number of
changes or
added
components
Complexity
Cost
Schedule
:
-
-
-
-
-
-
-
-
:
-
-
-
-
-
-
-
-
•Architecture (n)
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
258
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
259
Attribute Based Architectural Style (ABAS)
• http://www.sei.cmu.edu/pub/documents/99.reports/pdf/99tr022.pdf
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
260
Attribute-Based Architectural Style
• http://www.sei.cmu.edu/publications/documents/99.reports/99tr022/99tr022abstract.html
• http://www.sei.cmu.edu/pub/documents/99.reports/pdf/99tr022.pdf
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
261
ABAS in Practice
• http://www.sei.cmu.edu/pub/documents/99.reports/pdf/99tr022.pdf
•
Be Prepared to discuss Section 3. Of the reference
– Approach …
– Pros ….
– Cons …
– Issues ….
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
262
ARID: Active Reviews for Intermediate Designs
• Paul Clements, et al, Evaluating Software Architectures, Methods & Case Studies, Addison-Wesley, ISBN 0-201-70482-X
• Toward Deriving Software Architectures From Quality Attributes
– http://citeseer.nj.nec.com/cache/papers/cs/5585/http:zSzzSzwww.sei.cmu.eduzSzpubzSzdocumentszSz94.reportszSzpszSztr10.94.pdf/kazman94toward.pdf
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
263
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
264
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), 459-472,
• 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
Fall 2002
• 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 ?
Actual
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
266
Design Space Analysis
• 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), 459-472,
• 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 ?
Attribute (1)
Attribute (n)
Required
Actual
• 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).
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
267
Architectural Design Guidance
• 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).
Fall 2002
•Discuss the different levels of architecture complexity
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
268
Architectural Design Guidance
• 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?
Fall 2002
• 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!
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
269
Architectural Design Guidance
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
270
Architectural Design Guidance
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
271
Architectural Design Guidance
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
272
Architectural Design Guidance
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
273
Architectural Design Guidance
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
274
Architectural Design Guidance
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
275
Architectural Design Guidance
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
276
Architectural Design Guidance
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
277
Architectural Design Guidance
• Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996
• http://kmi.open.ac.uk/people/sbs/docs/SBS-DSA-1993.pdf
–Design Rules for UI Architectures
•See Book
–Applying the Design Space
•See Book
–A Validation Experiment
• See Book
–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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
278
Architectural Design Guidance
• 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
• http://kmi.open.ac.uk/people/sbs/docs/SBS-DSA-1993.pdf
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
279
Architectural Design Guidance
•
•
•
•
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
http://216.239.35.100/search?q=cache:WYksiz629xgC:sunset.usc.edu/~neno/teaching/s99/January28.ps.gz+Design+Spaces+and+Rules&hl=en&ie=UTF-8
http://kmi.open.ac.uk/people/sbs/docs/SBS-DSA-1993.pdf
–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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
280
Architectural Design Guidance
• 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
• http://kmi.open.ac.uk/people/sbs/docs/SBS-DSA-1993.pdf
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
281
Architectural Design Guidance
•
•
•
•
•
•
•
•
•
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
http://www.engin.umd.umich.edu/CIS/tinytools/cis375/f00/qds/Text.html
http://translate.google.com/translate?hl=en&sl=de&u=http://wwwagss.informatik.unikl.de/Projekte/GeneSys/Texts/german/DesignSpaces.html&prev=/sear
ch%3Fq%3DQuantified%2BDesign%2BSpace%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26sa%3DG
Metrics for design Space Exploration of Heterogeneous Multiprocessor Embedded Systems:
http://www.xrce.xerox.com/publis/cam-trs/pdf/1991/epc-1991-128.pdf
http://kmi.open.ac.uk/people/sbs/docs/SBS-DSA-1993.pdf
http://ei.cs.vt.edu/~cs5714/QOC.pdf
http://kmi.open.ac.uk/people/sbs/docs/SBS-DSA-1993.pdf
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
282
Architectural Design Guidance
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
283
Architectural Design Guidance
• 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.
–Design Space rules can be captured in these values
• Matrix Analyzed and the “best” realizations are selected for the next level of
decomposition
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
284
QFD Example: House of Quality
•Correlations
H
•Realization Mechanisms
Customer
Requirements
Import
ance
Implementation Difficulty (not
considered in calc)
Arch Style
Variant (1)
Arch
Style
Variant
(n)
10
2
Req A
5
H (6) (30)
M (4) (20)
Req B
6
L (3) (18)
H (6) (36)
Absolute Technical Importance
48
56
Relative Technical Importance
2
1
:
Objective Target Values
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
285
Architectural Design Guidance
• Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996
• http://kmi.open.ac.uk/people/sbs/docs/SBS-DSA-1993.pdf
–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)
Realization
Alt #1
Req. #1
Realization
Alt # (:)
Realization
Alt #(n)
10
1
9
2
:
:
:
:
3
3
1
4
Total Weight
19
93
20
Req #1
10
90
20
Req. #(:)
:
:
:
Req #(n)
9
3
12
Realization Design Decision
-
1
-
Req. #(n)
Fall 2002
Functional Dimension # (n)
Realization
Alt #1
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
Realization
Alt # (:)
Realization
Alt #(n)
286
Architectural Design Guidance
• Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996
• http://kmi.open.ac.uk/people/sbs/docs/SBS-DSA-1993.pdf
•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)
Dimensions
Weight
Alt #1
Alt # (:)
Alt #(n)
Functional
Dimension #1
Alt (1)
0
1
1
1
:
Alt (n)
100
:
:
:
Functional
Dimension (n)
Alt (1)
50
3
1
4
Calculated Weights
19
93
20
Req #1
10
90
20
Req. #(:)
:
:
:
Req #(n)
9
3
12
Realization Design Decision
-
1
-
Fall 2002
Structural Dimension # (n) (Patterns)
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
Alt #1
:
Alt # (:)
:
Alt #(n)
:
287
Architectural Design Guidance
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
288
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. 31-35
– J. O. Coplien, "Idioms and Patterns as Architectural Literature", IEEE Software, January 1997, pp. 36-42
– R. T. Monroe, A. K. Kompanek, R. Melton, and D. Garlan, "Architectural Styles, Design Patterns, and Objects",
IEEE Software, January 1997, pp. 43-52
– N. L. Kerth and W. Cunningham, "Using Patterns to Improve Our Architectural Vision", IEEE Software, January
1997, pp. 53-59
– S. Shlaer and S. J. Mellor, "Recursive Design of an Application-Independent Architecture", IEEE Software,
January 1997, pp. 61-72
– 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
289
CS-545
Week 9-10
Design Analysis Space in Practice
Design Space Analysis in Practice
• http://kmi.open.ac.uk/people/sbs/docs/SBS-DSA-1993.pdf
•An Example of the components of a design space using the QOC notation
Option (1)
Criteria (1)
Option (2)
Criteria (n)
Question
•“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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
291
Design Space Analysis in Practice
• http://kmi.open.ac.uk/people/sbs/docs/SBS-DSA-1993.pdf
•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
Iterative
– (*) 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.
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
292
Design Space Analysis in Practice
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
293
Design Space Analysis
• 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
Do you know why is this important to this particular domain ?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
294
Design Space Analysis
• 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
• What does this metric give us insight into ?
–Super Harvard Architecture:
• Identify subsets of the architecture to exploit concurrent memory accesses to instructions
and data
• What does this metric give us insight into ?
• Notice that the approach considers both CONFIRMING and DISCONFIRMING measurements !!!
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
295
DSP Oriented 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
296
GPP Oriented Metrics
• 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.
• What does this metric give us insight into ?
• Structure Ratio:
–The ration between the number of structures declared and the total number of declarations
• What does this metric give us insight into ?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
297
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
298
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
299
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
•Describe the value of doing so?
– Specifying a Theory of Software Architecture
•Describe the value of doing so?
•Provide a deductive basis for
– Specifying the Formal Semantics for Architecture Description
Languages
•Describe the value of doing so?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
301
Formal Models & Specifications
•
•
•
•
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996
http://www.afm.sbu.ac.uk/z/
http://web.comlab.ox.ac.uk/oucl/work/andrew.martin/CZT/
http://web.comlab.ox.ac.uk/oucl/research/groups/zstandards/
•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 ?
•What about data processing sequences ?
–How should one best communicate the fault-tolerant approach?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
302
Formalizing the Architecture of a Specific System
•
•
•
•
http://www.afm.sbu.ac.uk/z/#archive
http://spivey.oriel.ox.ac.uk/~mike/zrm/zrm.pdf
http://softeng.comlab.ox.ac.uk/usingz/slides/zips/index.html#pdf
http://softeng.comlab.ox.ac.uk/usingz/exercises/zips/index.html#pdf
•The formal specification notation Z (pronounced "zed"), useful
for describing computer-based systems, is based on ZermeloFraenkel 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
303
Formal Models & Specifications
• Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996
• http://www-lsr.imag.fr/Les.Groupes/PFL/RoZ/geneZ.htm
• http://www-lsr.imag.fr/Les.Groupes/PFL/RoZ/index.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
304
Formalizing an Architecture Style
• http://www-lsr.imag.fr/Les.Groupes/PFL/RoZ/geneZ.htm
• http://www-lsr.imag.fr/Les.Groupes/PFL/RoZ/index.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
305
Formal Models & Specifications
• Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996
• http://www-lsr.imag.fr/Les.Groupes/PFL/RoZ/geneZ.htm
• http://www-lsr.imag.fr/Les.Groupes/PFL/RoZ/index.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
306
Formal Models & Specifications
•
•
•
•
Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996
http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/able/ftp/fmmse-zum94/fmmse-zum94.pdf
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
307
Formal Models & Specifications
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
308
Formal Models & Specifications
• 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
– Why is this important ?
 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.
– Why is this important ?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
309
Formal Models & Specifications
• Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;, Prentice Hall, 1996
• http://www.afm.sbu.ac.uk/z/
•Z Notation Used in this Chapter.
–See http://www.afm.sbu.ac.uk/z/ 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
310
CS-545
Formal Methods in Practice
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
312
Formal Methods in Practice
•Abstract Model Examples
• Algebraic Specifications
• Axiomatic Specification
• States and Finite State Machines
• Concurrency
• Time and temporal relationships
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
313
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-95-111, 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. 213-249 ACM TOSEM Vol. 7, No. 3, July 1998, pp.
333-334
• J. Magee, "Behavioral analysis of software architectures using LTSA", Proceedings of ICSE '99, Los Angeles,
CA, May 16-22, 1999, pp. 634-637
• R. T. Monroe, "Modeling and Analyzing Software Architectures", Proceedings of ICSE '99, Los Angeles, CA,
May 16-22, 1999, pp. 690-691
• Nenad Medvidovic, Formal definition of the Chiron-2 software architectural style, Technical Report UCI-ICS-9524, 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. 29-40
• M. Shaw and D. Garlan, "Formulations and Formalisms in Software Architecture", LNCS, Vol. 1000, SpringerVerlag, 1995, pp. 307-323
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
314
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. 288-301
–W. Griswold and D. Notkin, "Architectural Tradeoffs for a MeaningPreserving Program Restructuring Tool", IEEE Transactions on Software
Engineering, Vol. 21, No. 4, April 1995, pp. 275-287
–Pam Binns, Matt Englehart, Mike Jackson, and Steve Vestal. "DomainSpecific 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
315
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-95-111, 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. 213-249 ACM TOSEM Vol. 7, No. 3, July 1998,
pp. 333-334)
• J. Magee, "Behavioral analysis of software architectures using LTSA", Proceedings of ICSE '99, Los
Angeles, CA, May 16-22, 1999, pp. 634-637
• R. T. Monroe, "Modeling and Analyzing Software Architectures", Proceedings of ICSE '99, Los Angeles, CA,
May 16-22, 1999, pp. 690-691
• Nenad Medvidovic, Formal definition of the Chiron-2 software architectural style, Technical Report UCI-ICS95-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.
29-40
• 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. 307-323
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
316
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 447-455
–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. 209-221
–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. 229268
• Communicating Processes
–G. R. Andrews, "Paradigms for Process Interaction in Distributed Systems", ACM Computing
Surveys, Vol. 23, No. 1, March 1991, pp. 49-90
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
317
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. AddisonWesley, 1998. Chapter 24, pp. 431-445
–M. Shaw, "Beyond objects: A software design paradigm based on process control", ACM
Software Engineering Notes, Vol. 20, No. 1, January 1995, pp. 27-38
–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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
318
CS-545
Week 11
Architecture Description Languages
Module Interconnect Languages
• Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging
Discipline;, Prentice Hall, 1996
• http://www.sei.cmu.edu/str/descriptions/mil_body.html
• Need an alternative to module interfaces to
describe module interconnections
WS (1)
WS (…)
UI
UI
UI
Functions..
Functions..
DBMS
WS (n)
– See MIL75, Intercol
– Still deficient as they use name bindings and only
low level primitives are supported.
The System
UI
Functions..
DBMS
UI
Functions..
DBMS
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
320
Module Interconnect Languages
• http://www.sei.cmu.edu/str/descriptions/mil_body.html
•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 semanticcompatibility.
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
321
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
322
ADL: Classification and Comparison
• ADL:
–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. 199-212
–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. 70-93
–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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
323
ADL: Classification and Comparison
• ADL:
–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. 302-313
–D. Le Metayer, "Describing Software Architecture Styles Using Graph Grammar", IEEE
Transactions on Software Engineering, Vol. 24, No. 7, July 1998, pp. 521-533
–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. 14-17
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
324
ADLs & Environments
• ACME
–D. Garlan, R. Monroe, and D. Wile, "Acme: An Architecture Description Interchange
Language", Proceedings of CASCON'97, Nov. 1997, pp. 169-183
–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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
325
Architecture Definition Languages
• http://www.sei.cmu.edu/str/descriptions/adl_body.html
• See http://www.sei.cmu.edu/architecture/adl.html 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
326
ADL Requirements
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
327
ADL Requirements
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
328
ADL Requirements
• 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
• (give examples)
– Abstraction: Naming rules for components and operators
• (give examples)
– Closure: Rules that determine which abstractions can be added to
the classes of components and operators
• (give examples)
– Specification: Association of semantics with syntactic forms.
• (give examples)
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
329
ADL Requirements
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
330
ADL Requirements
• 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
•Why ?
– Support user-defined or application Specific Abstractions
• Why?
– Support the Disciplined selection of architectural styles.
• Why ?
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
331
ADL Requirements
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
332
ADL Requirements
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
333
ADL Requirements
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
334
ADL Requirements
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
335
ADL Requirements
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
336
ADL Requirements
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
337
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
338
Informal Diagrams
• Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging Discipline;,
Prentice Hall, 1996
WS (1)
WS (…)
UI
UI
UI
Functions..
Functions..
DBMS
•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
WS (n)
The System
UI
Functions..
DBMS
UI
Functions..
DBMS
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
339
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
340
Issues with Programming Language
Modularization Facilities
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
341
Issues with Programming Language
Modularization Facilities
• Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging
Discipline;, Prentice Hall, 1996
WS (1)
WS (…)
UI
UI
UI
Functions..
Functions..
DBMS
•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:
–Note that module definitions ONLY
supports the reuse of the module. There
is NO support for reuse of the patterns of
composition.
Fall 2002
The System
UI
–Modules explicitly declare their exports
and imports, they do NOT declare the
export and import REQUIREMENTS.
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
WS (n)
Functions..
DBMS
UI
Functions..
DBMS
342
Issues with Programming Language
Modularization Facilities
• 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.
WS (…)
UI
UI
UI
Functions..
Functions..
DBMS
WS (n)
The System
– Makefiles are the only single place
where Connectivity dependencies are
visible.
UI
– Note that we only get a notion of the
dependency NOT the nature of the
dependency or design intention.
Functions..
DBMS
UI
Functions..
–Also the declarations of EXPORTS and
IMPORTS is STATIC. There is no
notion of dynamic reconfiguration.
Fall 2002
WS (1)
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
DBMS
343
Issues with Programming Language
Modularization Facilities
• 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
WS (1)
WS (…)
UI
UI
UI
Functions..
Functions..
DBMS
• (Actually the approach DEC took to their
language interface easily allowed Fortran
to call PL/I to call C … etc. (on the same
machine).
The System
UI
– 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.
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
WS (n)
Functions..
DBMS
UI
Functions..
DBMS
344
Issues with Programming Language
Modularization Facilities
• Mary Shaw & David Garlan, Software Architecture: Perspectives on an
Emerging Discipline;, Prentice Hall, 1996
WS (1)
WS (…)
UI
UI
UI
Functions..
Functions..
DBMS
•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.
WS (n)
The System
UI
Functions..
DBMS
UI
– Name matching DOES NOT
assure proper use !!
Functions..
DBMS
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
345
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
346
SEI: Architecture Definition Languages
• http://www.sei.cmu.edu/str/descriptions/adl_body.html
• http://citeseer.nj.nec.com/cache/papers/cs/350/ftp:zSzzSzftp.informatik.uni-stuttgart.dezSzpubzSzpszSzrapide.infozSzRapide1.0.paperszSzurapide-tse.pdf/luckham95eventbased.pdf
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
347
SEI: Architecture Definition Languages
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
348
SEI: Architecture Definition Languages
• http://www.sei.cmu.edu/str/descriptions/adl_body.html
• http://www.sei.cmu.edu/architecture/adl.html
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
349
SEI: Architecture Definition Languages
• http://www.sei.cmu.edu/architecture/adl.html
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
350
SEI: Architecture Definition Languages
• http://www.sei.cmu.edu/architecture/adl.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
351
SEI: Architecture Definition Languages
• http://www.sei.cmu.edu/architecture/adl.html
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
352
SEI: Architecture Definition Languages
• http://www.sei.cmu.edu/architecture/adl.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
353
SEI: Architecture Definition Languages
• http://www.sei.cmu.edu/architecture/adl.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
354
SADL: Structural Architecture Description Language
• http://www.sdl.sri.com/programs/dsa/sadl-main.html
• http://www.sdl.sri.com/programs/dsa/README.html
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
355
SADL: Structural Architecture Description Language
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
356
SADL: Structural Architecture Description Language
• 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
Fallsystems.
2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
357
SADL: Structural Architecture Description Language
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
358
SADL: Structural Architecture Description Language
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
359
SADL: Structural Architecture Description Language
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
360
SADL: Structural Architecture Description Language
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
361
UCI SADL
• http://ftp.ics.uci.edu/pub/arch/ADL/SADL.html
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
362
UCI SADL : IDN
• http://ftp.ics.uci.edu/pub/arch/ADL/SADL.html
• http://ftp.ics.uci.edu/pub/arch/ADL/IDNexample.html
component StackADT is
interface
top_domain
in
null;
out
null;
bottom_domain
in
PushElement (value : stack_type);
PopElement ();
GetTopElement ();
out
ElementPushed (value : stack_type);
ElementPopped (value : stack_type);
TopStackElement (value : stack_type);
StackEmpty ();
parameters
null;
Fall 2002
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;
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
363
UCI SADL: ADN
http://ftp.ics.uci.edu/pub/arch/ADL/SADL.html
http://ftp.ics.uci.edu/pub/arch/ADL/ADNexample.html
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
message_filter no_filtering
end BottomConnector;
architectural_topology
connector TopConnector connections
top_ports
StackADT;
bottom_ports
StackVisualization1;
StackVisualization2;
Fall 2002
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;
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
364
UCI SADL: ACN
• http://ftp.ics.uci.edu/pub/arch/ADL/SADL.html
• http://ftp.ics.uci.edu/pub/arch/ADL/ACNexample.html
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
365
The SAE, Meta-H and UML
•
•
•
•
http://ptolemy.eecs.berkeley.edu/~eal/towers/vestall/v14_mhtool.pdf
http://www.schafercorp-ballston.com/dasada/2001WinterPI/AMCOM_Tech.ppt
http://www.htc.honeywell.com/metah/uguide.pdf
http://sunset.usc.edu/events/2002/arr/presentations/AADL-UML%20-%20USC%202002%20Full.ppt
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
366
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
368
Mil References
• Prieto-Diaz, Ruben & Neighbors, James. "Module Interconnection Languages." Journal of Systems and
Software 6, 4 (1986): 307-334.
• Tichy, W. F. "Software Development Control Based on Module Interconnection," 29-41. Proceedings of the 4th
International Conference on Software Engineering. Munich, Germany, September 17-19, 1979. New York, NY:
IEEE Computer Society Press, 1979.
• Cooprider, Lee W. The Representation of Families of Software Systems (CMU-CS-79-116). Pittsburgh, PA:
Computer Science Department, Carnegie Mellon University, 1979.
• Garlan, David & Allen, Robert. "Formalizing Architectural Connection," 71-80. Proceedings of the 16th
International Conference on Software Engineering. Sorrento, Italy, May 16-21, 1994. 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): 540-553.
• 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," 66-78. Proceedings of the Second
International Workshop on Software Reuse. Lucca, Italy, March 24-26, 1993. 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 539-556.
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
369
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
371
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. 21 st International Conference on
Software Engineering, Los Angeles, CA, May 1999.
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
373
CS-545
Project Notebook Outline
Homework
Reading Assignments
Project Outline
• Cover Page
– 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
375
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
376
Weekly Readings
Adapted from:
http://www-2.cs.cmu.edu/afs/cs.cmu.edu/academic/class/17655-s02/www/
and from
http://sunset.usc.edu/research/software_architecture/index.html
And from other
Timely Copyrighted Papers
Week 1 Readings
• Adapted from: http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/questions/ReadingQuestions01.pdf
• D. E. Perry and A. L. Wolf. Foundations for the Study of Software Architectures. ACM SIGSOFT Software Engineering Notes, October 1992.
– http://citeseer.nj.nec.com/cache/papers/cs/4418/http:zSzzSzwww.bell-labs.comzSz~depzSzworkzSzpaperszSzswa-sen.pdf/perry92foundation.pdf
– (in your packet)
• DeRemer and Kron (1976): Programming-in-the-Large Versus Programming-in-the-Small
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/dk76.pdf
• Prieto-Diaz and Neighbors (1986): “Module Interconnection Languages”.
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/pn86.pdf
• D. Perry and A. Wolf, “Foundations for the Study of Software Architectures”, ACM
– (in your packet)
• B. Boehm, and W. Scherlis, “ Mega programming”,
– (in your packet)
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
Copyright 2001 Carnegie Mellon University
378
Week 2 Readings
• Adapted from: http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/questions/ReadingQuestions02.pdf
• How Architecture Wins Technology Wars. Harvard Business Review, 71, 2, March-April 1993, pp. 86-96.
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/mor93.pdf
• Formulations and Formalisms in Software Architecture. Computer Science Today: Recent Trends and Developments
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/sg95.pdf
• ACME: An Architecture Description of Component-Based Systems, Foundations of Component-Based Systems
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/GMW00.pdf
• How to Solve It: A New Aspect of Mathematical Methods. Princeton University Press 1973.
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/pol73.pdf
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
Copyright 2001 Carnegie Mellon University
379
Week 3 Readings
• Adapted from: http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/questions/ReadingQuestions03.pdf
• Architectural Blueprints, The 4+1 View Model of Software Architecture
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/kru96.pdf
• Ref The Art of Systems Architecting
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/rec92.pdf
• A Comedy of Errors: the London Ambulance Service case study"
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/fin93.pdf
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
Copyright 2001 Carnegie Mellon University
380
Week 4 Readings
• Adapted from: http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/questions/ReadingQuestions04.pdf
• Software Requirements & Specifications
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/jac95.pdf
• Software Architecture Documentation in Practice
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/C+02prologue.pdf
• Build the Documentation Package
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/C+02ch10.pdf
• Release 6A Segment/Design Specification for the ECS Project, Section 4.4. NASA Report 305-CD-600-001, pages 4-160-185. March 2001.
– http://edhs1.gsfc.nasa.gov/waisdata/toc/cd30560001toc.html
• Case Study: An Early Exploitation of Product Lines
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/lat01.pdf
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
Copyright 2001 Carnegie Mellon University
381
Week 5 Readings
• Adapted from: http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/questions/ReadingQuestions05.pdf
• Best Current Practices: Software Architecture Validation. AT&T Report
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/mar91.pdf
• ADS Architecture: Executive Summary
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/ads91.pdf
• Software Architecture in Industrial Applications
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/snh95.pdf
• Documenting Software Architectures: Recommendations for Industrial Practice. Carnegie Mellon University, School of Computer Science, CMU-CS-00-169
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/CMU-CS-00-169.pdf
• On the Criteria To Be Used in Decomposing Systems Into Modules
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/par72.pdf
– (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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
Copyright 2001 Carnegie Mellon University
382
Week 6 Readings
• Adapted from: http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/questions/ReadingQuestions06.pdf
• A New Approach to Functional and Software Structure for Engine Management Systems - BOSCH ME7
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/ghb98.pdf
• The Modular Structure of Complex Systems
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/pcw85.pdf
– (in your packet)
• Component Software: Beyond Object-Oriented Programming
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/szy98a.pdf
• A Model for Distributed System Services
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/ber96.pdf
• 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
– (in your packet)
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
Copyright 2001 Carnegie Mellon University
383
Week 7 Readings
• Adapted from: http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/questions/ReadingQuestions07.pdf
• Software Architecture and Object Oriented Systems
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/gar00.pdf
• The Unified Modeling Language Reference Manual
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/rjb99.pdf
• Reconciling the Needs of Architectural Description with Object-Modeling Notations
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/gck02.pdf
• Using Tool Abstraction to Compose Systems
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/gkn92.pdf
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
Copyright 2001 Carnegie Mellon University
384
Week 8 Readings
• Adapted from: http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/questions/ReadingQuestions08.pdf
• Connecting Tools Using Message Passing in the Field Environment.
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/rei90.pdf
• Formal Modeling and Analysis of the HLA Component Integration
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/agi98.pdf
• IEEE P1516/D1 Draft Standard [for] Modeling and Simulation (M&S), High Level Architecture (HLA) – Framework and Rules.
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/hla-p1516-rules.pdf
• RTI 2.0 Architecture
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/hla-rti.pdf
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
Copyright 2001 Carnegie Mellon University
385
Week 9 Readings
• Adapted from: http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/questions/ReadingQuestions09.pdf
• Quality Attributes. Software Engineering Institute Technical Report, CMU/SEI-95-TR-021
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/B+95.pdf
– http://www.sei.cmu.edu/pub/documents/95.reports/pdf/tr021.95.pdf
• The Architecture Tradeoff Analysis Method. Software Engineering Institute Technical Report, CMU/SEI-98-TR-008
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/k+098.pdf
– http://www.sei.cmu.edu/pub/documents/98.reports/pdf/98tr008.pdf
• 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 451-467
– (in packet)
•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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
Copyright 2001 Carnegie Mellon University
386
Week 10 Readings
• Adapted from: http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/questions/ReadingQuestions10.pdf
• Achieving Usability Through Software Architecture. Software Engineering Institute Technical Report. CMU/SEI-2001-TR-005.
– http://www.sei.cmu.edu/pub/documents/01.reports/pdf/01tr005.pdf
• ATAM: Method for Architecture Evaluation. Software Engineering Institute Technical Report, CMU/SEI-2000-TR-004
– http://www.sei.cmu.edu/pub/documents/00.reports/pdf/00tr004.pdf
• The Architecture Tradeoff Analysis Method. Software Engineering Institute Technical Report, CMU/SEI-98-TR-008
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/k+098.pdf
– http://www.sei.cmu.edu/pub/documents/98.reports/pdf/98tr008.pdf
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
Copyright 2001 Carnegie Mellon University
387
Week 11 Readings
• Adapted from: http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/questions/ReadingQuestions11.pdf
• Blackboard Systems. AI Magazine 7(3): 38-53 and 7(4): 82-107
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/nii86.pdf
• Mediators in the Architecture of Future Information Systems.
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/wie92.pdf
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
Copyright 2001 Carnegie Mellon University
388
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
– (in your packet)
• R. Fielding, R. Taylor, “Principled Design of the Modern Web Architecture” ACM
– (in your packet)
• R. Taylor and N Medvidovic, “A Component and Message Based Architectural Style for GUI Software”,
– (in your packet)
• D. Perry, “Generic Architecture Descriptions for Product Lines”, Bell Labs
– (in your packet)
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
389
Week 13 Readings
• Adapted from: http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/questions/ReadingQuestions13.pdf
• Schneider, P. Blueprint for Harmony. CIO.com, Sept 1 1999.
– http://www.cio.com/archive/090199_acrimony.html
• Software Architecture: An Executive Overview, Software Engineering Institute Technical Report, CMU/SEI-96-TR-003, Feb 1996.
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/cn96.pdf
• Architecting Processes are Key to Software Quality
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/ost98.pdf
• UML Components: A Simple Process for Specifying Component-Based Software, Addison Wesley, 2001, Chapters 1and 2.
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/cd01.pdf
• Szyperski, C. Component Software: Beyond Object-Oriented Programming, Addison-Wesley, 1998, pp. 3-39 and 331-344.
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/szy98a.pdf
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/szy98c.pdf
• Packaging and Deploying Predictable Assembly
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/hmsw02.pdf
• 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 your packet)
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
Copyright 2001 Carnegie Mellon University
390
Week 14 Readings
• Adapted from: http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/questions/ReadingQuestions14.pdf
• Three Tier Software Architectures. SEI, maint. Darleen Sadoski and Santiago Comella-Dorda, Feb 16, 2000.
– http://www.sei.cmu.edu/str/descriptions/threetier.html
• Microsoft Corporation. A Blueprint for Building Web Sites Using the Microsoft Windows Platform, Draft, Version .9. January 2000.
– http://msdn.microsoft.com/library/en-us/dndna/html/dnablueprint.asp?frame=true
• Monica Pawlan. Introduction to the J2EE Platform, Mar 23, 2001.
– http://developer.java.sun.com/developer/technicalArticles/J2EE/Intro/index.html
• Component Object Model (COM), DCOM, and Related Capabilities. SEI, maint. Santiago Comella-Dorda, Mar 13, 2001.
– http://www.sei.cmu.edu/str/descriptions/com.html
• A Framework for Classifying and Comparing Architectural Description Languages.
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/mt97.pdf
• Software Architecture: A Roadmap. The Future of Software Engineering.
– http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/references/gar00b.pdf
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
Copyright 2001 Carnegie Mellon University
391
CS-545 References
Categories of References
•Class Packaged References
•Primary Public References Reviewed
•Other References Reviewed
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
393
Class Packaged Papers
• Intro:
– (In Packet) M. Shaw and P. Clements. A Field Boxology: Preliminary Classification of Architectural Styles for
Software Systems. April 1996. (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 40-52.
• 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 717-734, 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. 1322
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
394
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, 1053-1058.
– (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 1995. 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 31-45. 2002
• 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 1997.
– (Open Source) R. Natarajan and D. S. Rosenblum. Supporting Architectural Concerns in Component Interoperability Standards.
IEEE Proceedings – Software, December 2000.
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
395
Class Packaged Papers Cont.
• 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. 177-186
• (In Packet) M. Moriconi, X. Qian, and R. A. Riemenschneider. Correct Architecture Refinement. IEEE Transactions
on Software Engineering, pages 356-372, 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 451-467, 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 459-472, 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
396
Class Packaged Papers Cont.
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
397
Primary Public References Reviewed
• A Case Study in Architectural Modelling AEGIS
– http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/aegis-iwssd8/aegis-iwssd8.pdf
• A Case Study in Structural Modeling
– http://www.sei.cmu.edu/publications/documents/96.reports/96.tr.035.html
• A Classification and Comparison Framework for Software Architecture Description Languages
– http://ftp.ics.uci.edu/pub/c2/papers/TR-UCI-ICS-97-02.pdf
• A Component- and Message-Based Architectural Style for GUI Software
– http://www.cs.ucsc.edu/~ejw/papers/c2-icse17.pdf
• A Discipline of Software Architecture, ACM Interactions, A, 1,1 January 1994
– http://cne.gmu.edu/pjd/PUBS/sa.pdf
• A Design Space and Design Rules for User Interface Software Architectures,
– http://www.sei.cmu.edu/publications/documents/90.reports/90.tr.022.html
• A Framework for Classifying and Comparing A Framework for Classifying and
Comparing Architecture Description Languages
– http://ftp.ics.uci.edu/pub/c2/papers/ADL-FSE97.pdf
• A Recovery Model for Extended Real-Time Transactions
– IEEE
• A Software Architecture for Dependable and Evolvable Industrial Computing Systems
– http://www.sei.cmu.edu/pub/documents/95.reports/pdf/tr005.95.pdf
• A Survey of Architecture Description Languages
– http://www.sei.cmu.edu/publications/articles/survey-adl.html
• A Type Theory for Software Architectures
– http://ftp.ics.uci.edu/pub/c2/papers/ics9814.pdf
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
398
Primary Public References Reviewed
• Abstractions and Implementations for Architectural Connections
– http://www-2.cs.cmu.edu/afs/cs/project/vit/www/paper_abstracts/ArchCxn.html
• Acme An Architecture Description Interchange Language
– http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/acme-cascon97/acme-cascon97.pdf
• ADLs and Dynamic Architecture Changes
– http://ftp.ics.uci.edu/pub/c2/papers/ADL-ISAW96.pdf
• AML An Architecture Meta-Language
– http://ase.informatik.uni-essen.de/olbib/99Wile.pdf
• An Architectural Analysis Case Study Internet Information Systems
– http://www.sei.cmu.edu/publications/articles/arch-anal-cs.html
• An Evaluation Theory Perspective of the Architectural Tradeoff Analysis Method
– http://www.sei.cmu.edu/publications/documents/00.reports/00tr012.html
• Analyzing Software Architectures for Modifiability
– http://www.cs.rug.nl/~bosch/papers/SAAModifiability.pdf
• Applicability of General Scenarios to the Architecture Tradeoff Analysis Method
– http://www.sei.cmu.edu/pub/documents/01.reports/pdf/01tr014.pdf
• Architectural Unification
– http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/Unification/Unification.pdf
• Architecture Based Development
– http://www.sei.cmu.edu/pub/documents/99.reports/pdf/99tr007.pdf
• Architecture Based Design Method
– http://www.sei.cmu.edu/pub/documents/00.reports/pdf/00tr001.pdf
• Architecture-Based Runtime Software Evolution
– http://www.ics.uci.edu/~peymano/papers/ICSE98.pdf
• Architecture Trade-Off Analyses of C4ISR Products
– http://www.sei.cmu.edu/pub/documents/99.reports/pdf/99tr014.pdf
• Assessing the Suitability of a Standard Design Method for Modeling Software Architectures
– http://ftp.ics.uci.edu/pub/c2/papers/wicsa1.pdf
• Attribute-Based Architecture Styles
– http://www.sei.cmu.edu/pub/documents/99.reports/pdf/99tr022.pdf
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
399
Primary Public References Reviewed
• Connectors in Software Architecture
– http://citeseer.nj.nec.com/cache/papers/cs/25896/http:zSzzSznenya.ms.mff.cuni.czzSzpublicationszSzbalek_phd.pdf/balek02connectors.pdf
• Deriving Test Plans from Architectural Descriptions
– ACM
• Domains of Concern in Software Architectures
– http://www.ics.uci.edu/~neno/dsl/dsl97.html
• Exploiting Style in Architectural Design Environments
– http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/aesop-fse2/aesop-fse2.pdf
• Extending Design Environments to Software Architecture Design
– http://www.ics.uci.edu/~jrobbins/papers/kbse_pres.pdf
– http://ftp.ics.uci.edu/pub/eden/papers/conferences/1996/kbse/KBSE96.pdf
• Features of Architecture Description Languages
• Formal Definition of the Chiron-2 Software Architectural Style
• Formal Modeling and Analysis of the HLA Component Integration Standard
– http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/hla-fse98/hla-fse98.pdf
• Formal Modeling of Software Architectures at Multiple Levels of Abstraction
– http://www.cs.ucsc.edu/~ejw/papers/medvidovic_css96.pdf
• Formulations and Formalisms in Software Architecture
– http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/vit/ftp/pdf/ProgCodif.pdf
• From Domain Models to Architectures
– http://www.sei.cmu.edu/publications/articles/from-domain-mods-archs.html
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
400
Primary Public References Reviewed
• Object Based Concurrent Programming in Distributed Artificial Intelligence
– http://citeseer.nj.nec.com/cache/papers/cs/4140/http:zSzzSzwww-poleia.lip6.frzSz~briotzSzpaperszSzobcp2dai-dai-kluwer92.pdf/gasser92objectbased.pdf
• Patterns for Software Architectures
– http://www-2.cs.cmu.edu/afs/cs/project/vit/ftp/pdf/PLoP94.pdf
• Quality Attribute Workshops
– http://www.sei.cmu.edu/publications/documents/01.reports/01tr010.html
• Refinement of Pipe and Filter Architectures
– http://www4.in.tum.de/~philipps/pub/fm99.pdf
• Reusing Off-the-Shelf Components to Develop a Family of Applications in the C2 Architectural Style
– http://ftp.ics.uci.edu/pub/c2/papers/C2-ARES96.pdf
• SAAM A Method For Analyzing the Properties of Software Architectures
– http://www.sei.cmu.edu/publications/articles/saam-metho-propert-sas.html
• Scenario Based Analysis of Software Architecture
– http://www.sei.cmu.edu/architecture/scenario_paper/
• Software Architecture Foundation of a Software Component Marketplace
– http://ftp.ics.uci.edu/pub/c2/papers/C2-ICSE17-SAWS.pdf
• Software Architecture Validation
• Software Synthesis via Domain Specific Architectures
– http://citeseer.nj.nec.com/cache/papers/cs/827/http:zSzzSzwww.cgl.uwaterloo.cazSz~rnkazmanzSzwaite.pdf/software-synthesis-via-domain.pdf
• Some Patterns for Software Architectures
– http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/vit/ftp/pdf/PLoP95.pdf
• Structural Modeling An Application Framework and Development Process For Flight Simulators
– http://www.sei.cmu.edu/publications/documents/93.reports/93.tr.014.html
• Studying Software Architectures Through Design Spaces and Rules
– http://citeseer.nj.nec.com/cache/papers/cs/222/http:zSzzSzwww.sei.cmu.eduzSzpubzSzdocumentszSz90.reportszSzpszSztr18.90.pdf/lane90studying.pdf
• Stylized Architecture, Design Patterns, and Objects
– http://www-2.cs.cmu.edu/afs/cs/project/compose/ftp/pdf/ObjPatternsArch-ieee97.pdf
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
401
Primary Public References Reviewed
• The Architecture Tradeoff Analysis Method
– http://www.sei.cmu.edu/pub/documents/98.reports/pdf/98tr008.pdf
• The Software Architecture Renaissance
– http://www.sei.cmu.edu/publications/articles/sw-arch-renaiss.html
• Tool Support for Architectural Analysis and Design
– http://www.sei.cmu.edu/publications/articles/tool-support-arch-anal-design.html
• Toward Deriving Software Architectures from Quality Attributes:
– http://www.sei.cmu.edu/pub/documents/94.reports/pdf/tr10.94.pdf
• Understanding Architectural Influences and Decisions in Large System Projects
– http://www.sei.cmu.edu/publications/articles/understanding-arch-influences.html
• Using Critics to Analyze Evolving Architectures
– http://ftp.ics.uci.edu/pub/eden/papers/conferences/1996/isaw/ISAW96.pdf
• Using Explicit State to Describe Architectures
– www.di.fc.ul.pt/~mal/papers/fase99.pdf
• Using Object-Oriented Typing to Support Architectural Design in the C2 Style
– http://ftp.ics.uci.edu/pub/c2/papers/ADL-FSE96.pdf
• Using Patterns to Integrate UML Views
– http://sunset.usc.edu/~aegyed/publications/Using_Patterns_to_Integrate_UML_Views.pdf
• Using Style to Understand Descriptions of Software Architectures
– http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/styleformalism-fse1/styleformalism-fse1.pdf
• Using the Architectural Tradeoff Method to Evaluate a Wargame Simulation Study
– http://www.sei.cmu.edu/pub/documents/01.reports/pdf/01tn022.pdf
• Visual Language Features Supporting Human-Human and Human-Computer Communication
– http://ftp.ics.uci.edu/pub/eden/papers/conferences/1996/vl/VL96.pdf
• What is Style?
– http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/style-iwass95/style-iwass95.pdf
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
402
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 110-143.
• 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 489-506.
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
403
Other References Reviewed
• D. Garlan, M. Shaw, "An Introduction to Software Architecture", Advances in Software Engineering and
Knowledge Engineering", Volume I, World Scientific, 1993. D. Perry, A. Wolf, Foundations for the Study of
Software Architecture", Proceedings of ACM SIGSOFT, October 1992, 40-52.
• W. Waite, A. Sloane, Software Synthesis via Domain-Specific Software Architectures, University of Colorado
Technical Report CU-CS-611-92, 1992.
• R. Kazman, L. Bass, G. Abowd, M. Webb, SAAM: A Method for Analyzing the Properties Software
Architectures, Proceedings of ICSE 16, May 1994, 81-90.
• R. Kazman, G. Abowd, L. Bass, P. Clements, Scenario-Based Analysis of Software Architecture, IEEE Software,
to appear, 1996. (Also available as Department of Computer Science Technical Report CS-95-45.)
• 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, 302-313.
• 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, 314-335.
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
404
Other References Reviewed
• 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. 336-355, 1995.
• Francois Moore and Tony Wacheski presenting Distributed Software Engineering by Jeff Kramer. Proceedings of ICSE 16, May
1994, 253-263.
• The Semantic Foundations of Software Architecture
• M. Jazayeri, Component Programming--a fresh look at software components, Technical University of Vienna Technical Report
TUV-1841-95-01.
• Architecture Evaluations: http://www.sei.cmu.edu/ata/pub_by_topic.html#evaluation
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
405
Other References Reviewed
• R. Allen and D. Garlan. Formal Connectors. Technical Report, CMU-CS-94-115, 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 130-133, 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 175-188, 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-95-219, Carnegie
Mellon University, November 1995.
• D. Garlan, R. Monroe, and D. Wile. ACME: An Architecture Interchange Language. Submitted for publication, January 1997.
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
406
Other References Reviewed
• D. Garlan, F. N. Paulisch, and W. F. Tichy, editors. Summary of the Dagstuhl Workshop on Software Architecture, February 1995.
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-88-99. 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 373-386, 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 336-355, 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 253-265, June 1993.
• D. C. Luckham, J. Vera, and S. Meldal. Three Concepts of System Architecture. Unpublished Manuscript, July 1995.
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
407
Other References Reviewed
• 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 190-198, Boston, MA, May 17-19,
1997. Also in Proceedings of the 1997 International Conference on Software Engineering (ICSE'97), pages 692700, 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
408
Other References Reviewed
• 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, 1962. English translation: Technical Report RADC-TR-65377, 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 307-334, October 1989.
• D. E. Perry and A. L. Wolf. Foundations for the Study of Software Architectures. ACM SIGSOFT Software Engineering Notes, pages 4052, 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 314-335, April 1995.
• M. Shaw and D. Garlan. Characteristics of Higher-Level Languages for Software Architecture. Technical Report, CMU-CS-94-210,
Carnegie Mellon University, December 1994.
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
409
Other References Reviewed
• D. Garlan, M. Shaw, "An Introduction to Software Architecture", Advances in Software Engineering and Knowledge
Engineering", Volume I, World Scientific, 1993. D. Perry, A. Wolf, Foundations for the Study of Software Architecture",
Proceedings of ACM SIGSOFT, October 1992, 40-52.
• W. Waite, A. Sloane, Software Synthesis via Domain-Specific Software Architectures, University of Colorado Technical Report
CU-CS-611-92, 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, 81-90.
• R. Kazman, G. Abowd, L. Bass, P. Clements, Scenario-Based Analysis of Software Architecture, IEEE Software, to appear, 1996.
(Also available as Department of Computer Science Technical Report CS-95-45.)
• 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,
302-313.
• 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, 314-335.
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
410
Other References Reviewed
• 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 1.09. 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
411
Reference: General Background
• D. Garlan and M. Shaw, "An Introduction to Software Architecture", Advances in
Software Engineering and Knowledge Engineering, Vol. 2, 1993, pp. 1-39. Also available
as Carnegie Mellon University Technical Report CMU-CS-94-166, 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. 40-52
• 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. 179-185
• D. Garlan, "Research Directions in Software Architecture" ACM Computing Surveys,
Vol. 27, No. 2, June 1995, pp. 257-261
• 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. 269-274
• Philippe Kruchten, "The 4+1 View Model of Software Architecture", IEEE Software,
Vol. 12, No. 6, November 1995, pp. 717-734
• 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 1994. See instead the online version
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
412
References
• Mainframe Architectures
– 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, 1994. Los Alamitos, CA:
IEEE Computer Society Press, 1994
– Siwolp, Sana. "Not Your Father's Mainframe." Information Week 546 (Sept 25, 1995): 53-58.
– Edelstein, Herb. "Unraveling Client/Server Architecture." DBMS 7, 5 (May 1994): 34(7).
• ADL
– Garlan, David & Shaw, Mary. "An Introduction to Software Architecture," 1-39. Advances in Software
Engineering and Knowledge Engineering Volume 2. New York, NY: World Scientific Press, 1993.
– Garlan, D. & Allen, R. "Formalizing Architectural Connection," 71-80. Proceedings of the 16th International
Conference on Software Engineering. Sorrento, Italy, May 16-21, 1994. 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): 336-355.
– Shaw, Mary, et al. "Abstractions for Software Architecture and Tools to Support Them." IEEE Transactions
on Software Engineering 21, 6 (April 1995): 314-335.
– Hoare, C.A.R. Communicating Sequential Processes. Englewood Cliffs, NJ: Prentice Hall International, 1985.
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
413
References
• ADL
–Garlan, David & Shaw, Mary. "An Introduction to Software Architecture," 1-39. Advances in
Software Engineering and Knowledge Engineering Volume 2. New York, NY: World Scientific
Press, 1993.
–Garlan, D. & Allen, R. "Formalizing Architectural Connection," 71-80. Proceedings of the 16th
International Conference on Software Engineering. Sorrento, Italy, May 16-21, 1994. 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): 336-355.
–Shaw, Mary, et al. "Abstractions for Software Architecture and Tools to Support Them." IEEE
Transactions on Software Engineering 21, 6 (April 1995): 314-335.
–Hoare, C.A.R. Communicating Sequential Processes. Englewood Cliffs, NJ: Prentice Hall
International, 1985.
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
414
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 1995. 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 110-143.
• Perry, Dewayne E. and Alexander L. Wolf, "Foundations for the study of software architecture," Software Engineering Notes, Vol.
17, No. 4, October 1992, pages 40-52.
• 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 489-506.
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
415
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.307-326, Springer Verlag
• Hartmut Ehrig, Robert Geisler, Marcus Klar, Julia Padberg,
"Horizontal and Vertical Structuring Techniques for
Statecharts", Proc. CONCUR'97, Springer LNCS
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
416
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. 199-212
• [MRT99] Nenad Medvidovic, David S. Rosenblum, and Richard N. Taylor, "A Language for ArchitectureBased 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. 44-53
• 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. 47-55
• [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. 94-97
• 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-ICS96-35, University of California, Irvine, August 1996
Fall 2002
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
417
Domains of Concern in SA
•http://www.ics.uci.edu/~neno/dsl/dsl97.html
• 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 domainspecific 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
418
How to Pick a Model Problem
http://www-2.cs.cmu.edu/afs/cs/project/compose/www/html/ModProb/index.html
http://www-2.cs.cmu.edu/afs/cs/project/compose/www/html/ModProb/benefits.html
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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
420
Our Problem
• 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
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
421
Configuration Updates
History of Updates
•Oct-20-2002
•Oct-13-2002
•Oct-11-2002
•Sep-22-2002
•Sep-09-2002:
•Aug-25-2002:
Fall 2002
0.21 Architecture Styles Update Week 3, 4 and 5
0.20 Reading Updates fro Week 12 and general cleanup.
0.19 Homework updated for ATAM
0.18 ATAM Update and general cleanup
0.17 Cleanup of References
0.16 Initial Release to Students
http://www.sei.cmu.edu/about/disclaimer.html
CS-545-Fall-2002
423
Descargar

Software Architecture - Donald Bren School of …