Software Architecture: An Overview Vanilson Burégio [email protected].

Software Architecture: An Overview

Vanilson Buré[email protected]

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


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, …


History {1960s}

Problems of developing large-scale software Systems Software structure Specifications Language issues

Abstract Data Types


History {1970s}

Software Design Design is an activity separate from

implementation

Research results Notation Techniques CASE tools


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


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]


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


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



[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"



[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


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]


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!


Software Architecture {Context}

Requirements

Architecture

Design

Implementation

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


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



Pipes and Filters



Data Abstraction and Object-Oriented Organization



Event-based, Implicit Invocation



Layered Systems



Repositories



Table Driven Interpreters



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”



Formal approach [Abowd, 1993]

Abstract Sintaxe

Semantic Domain

mapping

Z especification

Architectural views


Architectural views

[Gacek, 1994] “To accommodate the different expectations of the various stakeholders,

a software architecture must incorporate different, multiple views“


Architectural views

Views of a Software Architecture [Gacek, 1994] Static Topological Behavioral / Operational Dataflow Computing Environment Process Environment


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


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


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


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]


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


ADL – {Design Model}

Integrating ADL with a Standard Design Method [Robbins, 1998]

Wright`s CSP constructorC2 architecture expressed in UML


Architecture and Reuse

DSSA – Based ReuseProduct-line architecture (PLA)


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]


DSSA Based Reuse

Lifecycle [Balzer et al. 1993]


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


PLA {Cases}

[Bosch, 1999] Axis Communications AB

Securitas Larm AB


PLA {Problems}

Background knowledge Information Distribution Multiple versions of assets Dependencies between assets Assets in new contexts Documentation Tool support Effort estimation


PLA {recently}

PLA Development toolkit [Lesaint & Papamargaritis, 2004]

Support two operations: Application configuration Application generation

Process Specifying the architecture Configuring the application Generating applications


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.


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.


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.

Date post:	19-Dec-2015
Category:	Documents
View:	218 times
Download:	2 times

Software Architecture: An Overview Vanilson Burégio [email protected].

Documents