Software Architectures

1
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..

2
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.

3
Estimating Software Reliability A Software
Architecture-based approach.
November 13th, 2000 Vijayanand Bharadwaj
4
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?

5
Rest of this Presentation.

• Advantages of evaluating Reliability using
  Software Architectures
• Software Architectures in general
• Techniques to evaluate reliability
• Conclusions and future work

6
Advantages of Evaluating Quality Attributes
through Software Architecture Analysis
MED,2000WWC,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.

7
Software Architectures

• Formal Definition
• Characteristics
• Architectural Styles
• How are system properties exhibited by an
  architecture
• Methods of describing Software Architectures
  using ADLs

8
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

9
Software Architectures (continued)

• 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.

10
Software Architectures (continued)

• Characteristics
• S/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,
  ADTs, 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.

11
Software Architectures (continued)

• 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.
• Configurations
• An 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

12
Software Architectures (continued)

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

13
Software Architectures (continued)

• 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)

14
Software Architectures (continued)

• 1. Call and Return Style (Client -Server)

15
Software Architectures (continued)

• 2. Call and Return Style (Layered)
• Prominent in Software Reuse --Reuse Business
  Methodology
• Jacobson et al,1997

16
Software Architectures (continued)

• 3.Data Flow (Pipe and Filter)

17
How are system properties exhibited by an
architecture
18
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)

19
Describing Software Architectures (continued)

• A Rapide Component (closer to Formal Languages )
• type Application is interface
• in action Request(p params)
• out action Results(p params)
• behavior
• (?M in String) Receive(?M) gt Results(?M)
• end Application
• Unified Modeling Language (UML)
• is graphical , all artifacts are diagrams
• easy to use , industry accepted

20
Techniques to evaluate reliability using
software architectures WWC1999,SG1998,CBKA199
5,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.

21
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
22
Techniques to evaluate reliability using
software architectures (continued)
State view
State diagram is also represented by and
equivalent state transition matrix M. where
Mi,jRiPij 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
23
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. Correctn
ess 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
24
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)

25
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

26
Conclusions and Future Work (continued)

• 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).

27
Conclusions and Future Work (continued)

• 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 scenariosYCA,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?

28
References

• MED,2000 CS612 Software Architectures. Dr.N
  Medvidovich http//sunset.usc.edu/neno/teaching/s
  99/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

29
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.

30
References (continued)

• CMU2,2000 Architecture Description Languages
  (list of ADLs), http//www.sei.cmu.edu/architectur
  e/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.

31
References (continued)

• CMU3, 2000,The Architecture Tradeoff Analysis
  (ATA) Method, http//www.sei.cmu.edu/ata/ata_metho
  d.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
• vijay_at_csee.wvu.edu OR
• vanandb_at_hotmail.com thank you !