Introduction

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

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

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. Web Server Database Access Protocols HTTPS Web Browser Client Database COMPONENTS C/S CONFIGURATION CONNECTORS 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. Web Server Database Access Protocols HTTPS Web Browser Client Database COMPONENTS C/S CONFIGURATION CONNECTORS Software Architectures (continued) • 1. Call and Return Style (Client -Server)

15. Layered Configuration Application Systems Component systems (Business logic) Middleware Components (CORBA, EJB) System Software Components (Device drivers) Components Connectors Software Architectures (continued) • 2. Call and Return Style (Layered) Prominent in Software Reuse --Reuse Business Methodology [Jacobson et al,1997 ]

16. PIPE & FILTER CONFIGURATION Filter1 Filter2 Filter4 PIPE PIPE Filter3 COMPONENTS CONNECTORS Software Architectures (continued) • 3.Data Flow (Pipe and Filter)

17. 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? 3C COMPONENTS—specify modularity, interfaces, dependencies. CONNECTORS—Acceptable interaction, protocols, behavior CONFIGURATION—nature, distributed, synchronous execution 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) => 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],[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.

21. Call and Return Architecture (architectural view) P12 C1 R1 C2 R2 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 C3 R3 P12 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. S1 S2 Si is Execution State of component S3 S1 S2 S3 S1 0 P12 R1P13 S2 R2P21 0 0 S3 0 0 0 Techniques to evaluate reliability using software architectures (continued) State view 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]

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

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 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?

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

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

31. 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 vijay@csee.wvu.edu OR vanandb@hotmail.com thank you !