+ All Categories
Home > Documents > Introduction

Introduction

Date post: 30-Dec-2015
Category:
Upload: kevyn-boyer
View: 24 times
Download: 5 times
Share this document with a friend
Description:
Introduction. Software Architectures An emerging field of research in Software Engg. Has rapidly evolved over last 5-6 years. What is a “Software Architecture” informally -- a plan maybe for a building , or computer system - PowerPoint PPT Presentation
Popular Tags:
31
Introduction Software Architectures An emerging field of research in Software Engg. Has rapidly evolved over last 5-6 years. What is a “Software Architecture” informally -- a plan maybe for a building , or computer system Among others, two very interesting aspects of Software Architectures…..…
Transcript
Page 1: Introduction

Introduction

Software ArchitecturesAn emerging field of research in Software Engg.

Has rapidly evolved over last 5-6 years.

What is a “Software Architecture”informally -- a plan maybe for a building , or computer system

Among others, two very interesting aspects of Software Architectures…..…

Page 2: Introduction

Introduction (cont)

….Two aspects

1. A formal, unambiguous representation of a software system

2. Ability to evaluate “Quality Attributes” of a system based on the architectural representation

Quality Attributes of a system -performance, maintainability, RELIABILITY etc.

Page 3: Introduction

Estimating Software Reliability :

A Software Architecture-based approach.

November 13th, 2000

Vijayanand Bharadwaj

Page 4: Introduction

Theme

How can we use software architectures to evaluate a Quality Attribute such as Reliability ?

Above question forms the theme of this presentation.

We hope to begin answering with this presentation

i.e Can we do so and what is the correct way?

Page 5: Introduction

Rest of this Presentation….

Advantages of evaluating Reliability using Software Architectures

Software Architectures in general

Techniques to evaluate reliability

Conclusions and future work

Page 6: Introduction

Advantages of Evaluating Quality Attributes through Software Architecture Analysis [MED,2000][WWC,1999]

Means for making design decisions at an early stage and improves development process as it is a system blueprint

Serves as a common unambiguous view of requirements Serves as a contract between developers and users Flaws can be detected early and changes made before

implementing , so saves cost. Represents a high level view so low level details which

clutter are absent avoids losing sight of the “forest for the trees”.

Tells us if we are building the right system and if it fulfills our needs.

Page 7: Introduction

Software Architectures

Formal Definition

Characteristics

Architectural Styles

How are system properties exhibited by an architecture

Methods of describing Software Architectures using ADLs

Page 8: Introduction

Software Architectures (continued)

Definitions

Shaw and Garlan (CMU) [MED,2000]Software architecture [is a level of design that] involves

1. the description of elements from which systems are built,

2. interactions among those elements,

3. patterns that guide their composition,

4. and constraints on these patterns

Page 9: Introduction

Definitions (continued)

Krutchen [MED, 2000]Software architecture deals with the

1. design and implementation of the high-level structure of software.

2. abstraction, decomposition, composition, style, and aesthetics.

Software Architectures (continued)

Page 10: Introduction

CharacteristicsS/W Architecture is made up of

Connectors, Components,Configurations (3C) [MED,2000]

Components A component is a unit of computation or a data store

For example: clients, servers, databases, ADT’s, filters.

May be simple or composite ( describing an entire system)

Note: Techniques to evaluate software reliability of components and component based systems have been evolving. [YCA,1999],[EVE1999] [GLT,1998],[KM,1997]

Architecture is an aggregation of components.

Software Architectures (continued)

Page 11: Introduction

Connectors

A connector is an architectural element that models interactions among components and rules that govern those interactions.

Connectors may be simple, such as procedural calls ,shared variable access

or complex (semantically rich interactions) client -server protocols, database protocols, multicast etc.

ConfigurationsAn architectural configuration or topology is a connected graph of components and connectors that describes

architectural structure

proper connectivity

concurrent and distributed properties

conforms adherence to style rules

Software Architectures (continued)

Page 12: Introduction

Simple Web-based C/S system ( watered down example)

Web Browser Client

Web Server

Database

COMPONENTS

CONNECTORS

HTTPS

Database Access Protocols

C/S CONFIGURATION

Software Architectures (continued)

Page 13: Introduction

Architectural Styles: a brief overview [Mili et al, 2000] [MED, 2000](differences are beyond the scope )

Various styles such as

1. Call and Return { Main program and subroutine style

Remote Procedure Call

Object Oriented

Layered }

2. Data Flow {Pipe and Filter}

3. Virtual machine {Java, Rule-based}

4. Data Centered {Blackboard}

5. Independent Components {Publish -Subscribe}

6. Heterogeneous ( Mixture of above styles)

Software Architectures (continued)

Page 14: Introduction

1. Call and Return Style (Client -Server)

Web Browser Client

Web Server

Database

COMPONENTS

CONNECTORS

HTTPS

Database Access Protocols

C/S CONFIGURATION

Software Architectures (continued)

Page 15: Introduction

2. Call and Return Style (Layered)

Prominent in Software Reuse --Reuse Business Methodology

[Jacobson et al,1997 ]

Component systems (Business logic)

Middleware Components(CORBA, EJB)

Application Systems

System Software Components(Device drivers)

Components Connectors

Layered Configuration

Software Architectures (continued)

Page 16: Introduction

3.Data Flow (Pipe and Filter)

Filter1

Filter3

Filter4Filter2

COMPONENTS CONNECTORS

PIPE & FILTER CONFIGURATION

PIPE

PIPE

Software Architectures (continued)

Page 17: Introduction

How are system properties exhibited by an architecture

MODIFIABILITY

Depends on Modularity and encapsulation strategies used

REUSABILITY

Depends on degree of coupling between modules

PERFORMANCE

Volume and Complexity of inter-component communication and coordination.Are components distributed?

3CCOMPONENTS—specify modularity, interfaces, dependencies.

CONNECTORS—Acceptable interaction, protocols, behavior

CONFIGURATION—nature, distributed, synchronous execution

Page 18: Introduction

Describing Software Architectures Architectural Description Languages (ADL)1. Formal Languages for representing and reasoning about software

architectures [CMU1,2000] 2. An ADL must explicitly model components, connectors and configurations

[ MT1997] 3. Must provide tool support for architecture based development and

evolution.

Examples around 10-15.[CMU2,2000] Rapide (Stanford Univ.)

Wright, AESOP (CMU)

C2 (UCI)

UML (?) [EM, 1999] ( research interest)

Page 19: Introduction

Describing Software Architectures (continued)

A Rapide Component (closer to Formal Languages )

type Application is interfacein action Request(p : params);out action Results(p : params);

behavior(?M in String) Receive(?M) => Results(?M);;

end Application;

Unified Modeling Language (UML) is graphical , all artifacts are diagrams

easy to use , industry accepted

Page 20: Introduction

Techniques to evaluate reliability using software architectures [WWC1999],[SG1998],[CBKA1995],[ABDA1997] [CMU3,2000]

Fairly new area of software architecture research must be investigated to see if

1. techniques are correct

2. suitable enough to give accurate estimates of reliability

One such technique [WWC,1999]

Based on Component based reliability model by Cheung [CHE1980]Consists of creating a state transition diagram from an architectural view.

Fill a state transition Matrix from the state diagram and apply formulae.

Page 21: Introduction

Techniques to evaluate reliability using software architectures (continued)

Note:

1. One component (calling) may request services of another (called) before transferring complete control to others.

2.Called components may execute multiple times with one execution of calling component

C1R1

C3R3

C2R2

P12

P21

Ci is a COMPONENT (i from 1 to 3)

Pij is Transition Probability from Ci to Cj

Ri is Reliability of the Component Ci

Call and Return Architecture (architectural view)

P12

Page 22: Introduction

Techniques to evaluate reliability using software architectures (continued)

State viewS1

S3

S2

Si is Execution State of component

State diagram is also represented by and equivalent state transition matrix M.

where M[i,j]=Ri*Pij if Si can reach Sj

= Pij if Si can reach Sj but Sj is called component

=0 if Si cannot reach Sj

Formulae are applied to M to calculate overall Reliability [WWC1999]

S1 S2 S3

S1 0 P12 R1P13

S2 R2P21 0 0

S3 0 0 0

Page 23: Introduction

Techniques to evaluate reliability using software architectures (continued)

Objective -- To illustrate that one can use an architecture and devise a method to estimate reliability.

More importantly fact that a characteristic such as “call and return” which is special to software can be included in estimation ( as it does affect the reliability)

Other properties such as concurrency, dynamism (spawining or forking, threads), distribution etc . Can be modeled and used in estimations.

Correctness and Accuracy of our estimation technique = F(Properties of a system and how they are exhibited by an architecture)

In fact very interesting that different styles of architecture exhibit different properties which may orthogonal .

Hence one reliability technique may not work for different styles, efforts are underway to investigate this. [ABDA1997]

Page 24: Introduction

Techniques to evaluate reliability using software architectures (continued)

Other techniques such as Software Architecture Analysis Method (SAAM),uses scenarios (operational profile) [CBKA1995]

Architectural tradeoff Analysis Method (ATAM)[CMU3,2000] are industry strength, formal.

(compares various architectural styles based on attributes)

Page 25: Introduction

Conclusions and Future Work

We have looked at Software Architectures,(nature,use,representation) Their use in evaluation of quality attributes Sample technique to estimate reliability

Above is still WIPS (Stanford, UCI, CMU, Industry)

* especially evaluation of architectures

Page 26: Introduction

Future work will involve following…… A focus on WebApps. (web applications) since they bring host of

challenges such as

1. Constraints on the conventional software development process (time-to-market, continuous evolution) (WebEngineering)[PRE,2000]

2. Metrics for WebApps may be different.(Web Metrics)[WE, 2000]

3. WebApps have become ubiquitous and are being used in critical applications apart from E-Commerce. Banking, healthcare (security and reliability are utmost important).

Conclusions and Future Work (continued)

Page 27: Introduction

So issues of interest are 1.What characteristics of WebApps affect reliability estimation ? And How?

2.How we can estimate reliability of software using architectures for Web Apps? (Web Architectures are Software architectures too)

3. Can we use techniques for Software Component based estimation for reliability and Architectures to come up with technique (model) for Web Apps?

Also amongst prior techniques,

4. Some reliability estimation techniques assume a constant failure rate . Not recommended as does change in reality. How can we account for this ?

5. Operational profile ( usage scenarios[YCA,1999]) plays a very important role in reliability. How can we account for this ( prior methods ignore this) ? [MUS,1993]

6. How do these factors make a difference in terms of WebApps?

Conclusions and Future Work (continued)

Page 28: Introduction

References

[MED,2000] CS612 Software Architectures. Dr.N Medvidovich http://sunset.usc.edu/~neno/teaching/s99/cs612.html

[WWC,1999] Wang Wen-Li, Ye Wu, Mei-Hwa Chen. “An Architecture-Based Software Reliability Model”, Proceedings of the 1999 Pacific Rim International Symposium on Dependable Computing (IEEE).

[YCA,1999] Yacoub, S., B. Cukic and H. Ammar .“Scenario-Based Reliability Analysis of Component-Based Software”, Proceedings of the 10th International Symposium on Software Reliability Engineering, ISSRE 1999, 1 - 4 November, 1999,Boca Raton, Florida.

[EVE, 1999] Everett, W., “Software Component Reliability Analysis” 1999 IEEE Symposium on Application-Specific Systems and Software Engineering & Technology,ASSET 1999, 24 - 27 March, 1999Richardson, Texas.

[GLT,1998] Gokhale S.,M. Lyu, K. Trivedi.“Reliability Simulation of Component-Based Software Systems”, The Ninth International Symposium on Software Reliability Engineering,ISSRE 1997,4 - 7 November, 1998,Paderborn, Germany

Page 29: Introduction

References (continued)

[KM,1997] Krishnamurthy S, A. Mathur. “On the Estimation of Reliability of a Software System Using Reliabilities of its Components”, Eighth International Symposium on Software Reliability Engineering ISSRE 1997, November 2-5, 1997, Albuquerque, NM

[Mili et al,2000] ,Mili, H., A. Mili, S. Yacoub, E. Addy. “Foundations for an Engineering Discipline in Software Reuse”. May 23, 2000. CSEE, WVU

[Jacobson et al, 1997],Jacobson, I., M. Griss, P. Jonsson. “Software Reuse: Architecture, Process and Organization for Business Success”, ACM press 1997, ISBN 0-201-92476-5.

[CMU1,2000] Architecture Description Languages http://www.sei.cmu.edu/activities/str/descriptions/adl_body.html

[ MT1997] Medvidovic, N., and R. N. Taylor. “A Framework for Classifying and Comparing Architecture Description Languages. “, 6th European Software Engineering Conference with the 5th ACM SIGSOFT Symposium on the Foundations of Software Engineering, Zurich, Switzerland, September 1997.

Page 30: Introduction

References (continued)

[CMU2,2000] Architecture Description Languages (list of ADLs), http://www.sei.cmu.edu/architecture/adl.html

[EM, 1999],Egyed, A., and N. Medvidovic. Extending Architectural Representation in UML with View Integration. In Proceedings of The Second International Conference on The Unified Modeling Language (UML99), pp. 2-16, Fort Collins, CO, October 28-30, 1999.

[SG,1998], Spitznagel, B. and D. Garlan.”Architecture-Based Performance Analysis”, In proceedings of the 1998 Conference on Software Engineering and Knowledge Engineering, 1998.

[CBKA1995], Clements, P.,L. Bass, R. Kazman and G. Abowd.”Predicting Software Quality by Architecture-Level Estimation”,Proceedings, Fifth International Conference on Software Quality. Austin Tx, October 1995.

[ABDA1997], Abd-Allah, Ahmed. “Extending Reliability Block Diagrams to Software Architectures”, Technical Report USC-CSE-97-501, University of Southern California, March 1997.

Page 31: Introduction

References (continued)

[CMU3, 2000],The Architecture Tradeoff Analysis (ATA) Method, http://www.sei.cmu.edu/ata/ata_method.html

[CHE1980],Cheung, R., “A User-Oriented Software Reliability Model”, IEEE transactions Software Engineering, 6(2):118, March 1980.

[PRE,2000], Pressman, R., “Software Engineering , A Practitioner's Approach”,McGraw-Hill series in computer Science, ISBN 0-07-3655783-3, 2000

[WE, 2000], Webengineering Community Home page http://www.webengineering.org/

[MUS,1993] Musa, J., “Operational Profiles in Software Reliability Engineering”. IEEE Software, March1993.

Questions,comments,criticisms……… please email [email protected] OR

[email protected] thank you !


Recommended