Dec 19, 2015
Reuse in Software Engineering Group
Agenda
History Software Architecture
Definition Motivation Roles
Architectural Styles Architectural Views Architectural Description Language (ADL) Architecture and Reuse
DSSA based reuse PLA
Reuse in Software Engineering Group
History {1950s}
Machine language programmers placed instructions and data explicitly in
the computer`s memory
Symbolic Assemblers Symbolic names Memory layout and update references could be
automated
High-level Programming Languages Procedures invocations, loops, modules, …
Reuse in Software Engineering Group
History {1960s}
Problems of developing large-scale software Systems Software structure Specifications Language issues
Abstract Data Types
Reuse in Software Engineering Group
History {1970s}
Software Design Design is an activity separate from
implementation
Research results Notation Techniques CASE tools
Reuse in Software Engineering Group
History {1980s}
The focus of software engineering research: Integrating designs and the design process
Result: many of the notations and techniques
developed for software design have been absorbed by implementation languages
Reuse in Software Engineering Group
History {1990s}
Software Architecture Design Vs Architecture
"use the term architecture, in contrast to design, to evoke notions of codification, of abstraction, of standards, of formal training (of software architects), and of style " [Perry and Wolf,92]
Reuse in Software Engineering Group
History {Summary}
1950s - High-level Programming Languages 1960s - large-scale software Systems 1970s - Software Design 1980s - Integrating designs and the design
process 1990s - Software Architecture
Abstraction level
Reuse in Software Engineering Group
Software Architecture {Definition}
There are several different definitions of software architecture in the literature, all of them agree that it:
The most commonly used definitions: [Perry & Wolf, 1992] [Garlan & Shaw, 1994]
Describes the organization of the overall systemDescribes the organization of the overall system
concentrate on the topological view
Reuse in Software Engineering Group
Software Architecture {Definition}
[Perry & Wolf, 1992] Set of architectural elements that have a particular form, and an underlying
rationale
Elements - processing, data and connecting elements Form - consists of weighted properties of architectural elements Rationale - captures the motivation for the choice of architectural style,
the choice of elements, and the form
It is the connecting elements ("glue") that especially distinguish one architecture from another
"Data element": ball"Processing elements“: Swimmers
"Connecting element" ("glue"): water
It has a similar "architecture" but differ in the "glue"
Reuse in Software Engineering Group
Software Architecture {Definition}
[Garlan & Shaw, 1994] Define software architectures as including components, connectors
and configurations. Where:
components - define the locus of computation, connectors - define the interactions between components configurations define the topology of the components and connectors
“The structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time.”
Software architecture discussion group at the SEI, 1994
“The structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time.”
Software architecture discussion group at the SEI, 1994
Reuse in Software Engineering Group
Software Architecture {Motivation}
High cost of softwareEvolutioncustomization
“Software architecture simplifies our ability to comprehend large systems by presenting them at a level of abstraction at which high-level design can be understood “
[Garlan and Shaw 1993; Perry and Wolf 1992]
“Software architecture simplifies our ability to comprehend large systems by presenting them at a level of abstraction at which high-level design can be understood “
[Garlan and Shaw 1993; Perry and Wolf 1992]
Reuse in Software Engineering Group
Software Architecture {Roles}
[Eden & Kazman, 2003] Communication among stakeholders Early design decisions Transferable abstraction of a system
Main considerations [Szyperski, 2002] Functionality Performance Reliability Security
Commonly, these aspects are ignored, emphasizing functionality. The consequences can be fatal!
Reuse in Software Engineering Group
Software Architecture {Context}
Requirements
Architecture
Design
Implementation
Reuse in Software Engineering Group
Architectural styles
Observation Many systems have a similar solution structure
Defines a family of architectures constrained by [Garlan & Shaw, 1994]: Component/connector vocabulary Topology Semantic constraints
Benefits of styles Reuse of experience Reuse of code Insight in/analysis of solution characteristics
Reuse in Software Engineering Group
Most Common Architectural Styles [Garlan & Shaw]
Pipes and Filters Data Abstraction and Object-Oriented
Organization Event-based, Implicit Invocation Layered Systems Repositories Table Driven Interpreters Heterogeneous Architectures
Reuse in Software Engineering Group
Most Common Architectural Styles [Garlan & Shaw]
Pipes and Filters
Reuse in Software Engineering Group
Most Common Architectural Styles [Garlan & Shaw]
Data Abstraction and Object-Oriented Organization
Reuse in Software Engineering Group
Most Common Architectural Styles [Garlan & Shaw]
Event-based, Implicit Invocation
Reuse in Software Engineering Group
Most Common Architectural Styles [Garlan & Shaw]
Layered Systems
Reuse in Software Engineering Group
Most Common Architectural Styles [Garlan & Shaw]
Table Driven Interpreters
Reuse in Software Engineering Group
Most Common Architectural Styles [Garlan & Shaw]
Heterogeneous Architectures
There are different ways in which architectural styles can be combined
Hierarchyo pipe connector may be implemented internally as a FIFO
A single component using a mixture of architectural connectorso an “active database”
Reuse in Software Engineering Group
Architectural styles
Formal approach [Abowd, 1993]
Abstract Sintaxe
Semantic Domain
mapping
Z especification
Reuse in Software Engineering Group
Architectural views
[Gacek, 1994] “To accommodate the different expectations of the various stakeholders,
a software architecture must incorporate different, multiple views“
Reuse in Software Engineering Group
Architectural views
Views of a Software Architecture [Gacek, 1994] Static Topological Behavioral / Operational Dataflow Computing Environment Process Environment
Reuse in Software Engineering Group
Architectural views
[Kruchten, 1995] The 4+1 View Model
Logical view Process view Physical view Development view Scenarios
Scenario-driven approach capture the system`s critical functionality
Style Vs View…
System engineers
End users, customers, data specialists
Project managers, software-configuration staff members
Reuse in Software Engineering Group
ADL - Architecture Description Language
ADL’s differ in their scope of use [Abd-Allah, 1994]
Architecture Description Languages (ADL’s) lay the formal basis for architectingArchitecture Description Languages (ADL’s) lay the formal basis for architecting
Reuse in Software Engineering Group
ADL - Architecture Description Language Goals
Rapid Prototyping Reengineering Better understanding of overall system
Main problem A lot of ADLs are loosely coupled to implementation languages,
causing problems in: Analysis Implementation Understanding evolution
Reuse in Software Engineering Group
ADL - Architecture Description Language
Early ADLs were restricted to static connectivity Rapide Darwin Wright DICAM …
Later ADLs added support for dynamic connectivity and dynamic reconfiguration ArchJava [Aldrich, 2002]
Reuse in Software Engineering Group
ADL – {ArchJava}
Key concept: Communication Integrity [Luckham &Vera, 1995]
A system has Communication Integrity if implementation components only communicate directly with the components they are connected to in the architecture
Example
Reuse in Software Engineering Group
ADL – {Design Model}
Integrating ADL with a Standard Design Method [Robbins, 1998]
Wright`s CSP constructorC2 architecture expressed in UML
Reuse in Software Engineering Group
Architecture and Reuse
DSSA – Based ReuseProduct-line architecture (PLA)
Reuse in Software Engineering Group
Domain Specific Software Architecture Based Reuse
Artifact involved: Reference architecture, design, requirements and code
General characteristics: Requires thorough domain understanding Domain specific repository Domain model, reference architecture and repository evolution
Example
SGS Reference Architecture [Gacek, 1995]
Reuse in Software Engineering Group
Product-line architecture {Context} Product-line architecture (PLA) have received
special attention in software industry Increase reuse minimize product-specific development Competitive advantage
Recent Area
Reuse in Software Engineering Group
PLA {Cases}
[Bosch, 1999] Axis Communications AB
Securitas Larm AB
Reuse in Software Engineering Group
PLA {Problems}
Background knowledge Information Distribution Multiple versions of assets Dependencies between assets Assets in new contexts Documentation Tool support Effort estimation
Reuse in Software Engineering Group
PLA {recently}
PLA Development toolkit [Lesaint & Papamargaritis, 2004]
Support two operations: Application configuration Application generation
Process Specifying the architecture Configuring the application Generating applications
Reuse in Software Engineering Group
References
[Abd-Allah, 1994] Ahmed A. Abd-Allah. Architecture Description Languages. 1994.
[Abowd, 1993] Gregory Abowd, Robert Allen, David Garlan. Using Style to Understand Descriptions of Software Architecture. 1993.
[Aldrich, 2002] Jonathan Aldrich, Craig Chambers, David Notkin. ArchJava: Connecting Software Architecture to Implementation. 2002.
[Balzer et. al. 1993] R. Balzer, C. Braun, F. Belz, L. Coglianese, L. Erman, K. Harbison, R. Might, R. Platek, and S. Vestal. DSSA Process Summary. Copies available from Chris Braun ([email protected]), 1993.
[Bosch, 1999] Jan Bosch Product-Line Architectures in Industry: A Case Study. 1999.
[Clements, 1996] Paul C. Clements. A Survey of Architecture Description Languages. 1996.
[Eden & Kazman, 2003] Amnon H. Eden, Rick Kazman. Architecture, Design, Implementation. 2003.
[Gacek et. al. 1995] Cristina Gacek, Ahmed Abd-Allah, Bradford Clark, Barry Boehm. On the Definition of Software System Architecture. 1995.
[Gacek, 1994] Cristina Gacek. Domain Specific Software Architecture Based Reuse. 1994.
Reuse in Software Engineering Group
References
[Gacek, 1995] Cristina Gacek. Exploiting Domain Architectures in Software Reuse. 1995.
[Garlan & Shaw, 1994] David Garlan, Mary Shaw. An Introduction to Software Architecture. 1994.
[Garlan et. al.. 1995] David Garlan, Robert Allen, Jihn Ackerbloom. Architectural Mismatch: Why Reuse is So Hard. 1995.
[Garlan, 1995] David Garlan. Research Directions in Software Architecture. 1995.
[Kruchten, 1995] P. Kruchten. The 4+1 View Model of Architecture. IEEE Software, Nov 1995.
[Lesaint & Papamargaritis, 2004] David Lesaint, George Papamargaritis. Aspects and Constraints for Implementing Configurable Product-Line Architectures. 2004.
[Luckham & Vera, 1995] David C. Luckham, James Vera. An Event Based Architecture Definition Language. IEEE Trans. Software Enginering 21(9), Sep 1995.
[Lutz & Gannod, 2003] Robyn R. Lutz, Gerald C. Gannod. Analysis of a software product line architecture: an experience report. 2003.
[Meekel, 2001] Jacques Meekel, Thomas B. Hortont, Robert B. Francet, CharlieMellone L Sajid Dalvi. From Domain Models to Architecture Frameworks. 1997.
Reuse in Software Engineering Group
References
[Perry & Wolf, 1992] Dewayne E. Perry, Alexander L. Wolf. Foundations for the Study of Software Architecture. 1992.
[Robbins, 1998] Jason E. Robbins, Nenad Medvidovic, David F. Redmiles, David S. Rosenblumart.Integrating Architecture Description Languages with a Standard Design Method. 1998.
[Shaw, 1995] Mary Shaw. Comparing Architectural Design Styles. 1995.
[Szyperski, 2002] C. Szyperski, D. Gruntz, S. Murer, Component Software: Beyond Object-Oriented Programming, Addison-Wesley, 2002, pp. 588
[Wallnau, 2001] Kurt Wallnau, Judith Stafford, Scott Hissam, Mark Klein. On the Relationship of Software Architecture to Software Component Technology. 2001.