Download
software architecture an overview n.
Skip this Video
Loading SlideShow in 5 Seconds..
Software Architecture: An Overview PowerPoint Presentation
Download Presentation
Software Architecture: An Overview

Software Architecture: An Overview

357 Vues Download Presentation
Télécharger la présentation

Software Architecture: An Overview

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Software Architecture: An Overview Vanilson Burégio vaab@cin.ufpe.br

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

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

  4. History{1960s} • Problems of developing large-scale software Systems • Software structure • Specifications • Language issues • Abstract Data Types Reuse in Software Engineering Group

  5. History{1970s} • Software Design • Design is an activity separate from implementation • Research results • Notation • Techniques • CASE tools Reuse in Software Engineering Group

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

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

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

  9. 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 system concentrate on thetopological view Reuse in Software Engineering Group

  10. "Processing elements“: Swimmers "Data element": ball It has a similar "architecture" but differ in the "glue" "Connecting element" ("glue"): water 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 Reuse in Software Engineering Group

  11. Software Architecture{Definition} • [Garlan & Shaw, 1994] • Define software architectures as including components, connectorsand 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 Reuse in Software Engineering Group

  12. Software Architecture{Motivation} • High cost of software • Evolution • customization “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

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

  14. Software Architecture{Context} Requirements Architecture Design Implementation Reuse in Software Engineering Group

  15. Architectural styles

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

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

  18. Most Common Architectural Styles [Garlan & Shaw] • Pipes and Filters Reuse in Software Engineering Group

  19. Most Common Architectural Styles [Garlan & Shaw] • Data Abstraction and Object-Oriented Organization Reuse in Software Engineering Group

  20. Most Common Architectural Styles [Garlan & Shaw] • Event-based, Implicit Invocation Reuse in Software Engineering Group

  21. Most Common Architectural Styles [Garlan & Shaw] • Layered Systems Reuse in Software Engineering Group

  22. Most Common Architectural Styles [Garlan & Shaw] • Repositories Reuse in Software Engineering Group

  23. Most Common Architectural Styles [Garlan & Shaw] • Table Driven Interpreters Reuse in Software Engineering Group

  24. Most Common Architectural Styles [Garlan & Shaw] • Heterogeneous Architectures • There are different ways in which architectural styles can be combined • Hierarchy • pipe connector may be implemented internally as a FIFO • A single component using a mixture of architectural connectors • an “active database” Reuse in Software Engineering Group

  25. Architectural styles • Formal approach [Abowd, 1993] mapping Abstract Sintaxe Semantic Domain Z especification Reuse in Software Engineering Group

  26. Architectural views

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

  28. Architectural views • Views of a Software Architecture [Gacek, 1994] • Static Topological • Behavioral / Operational • Dataflow • Computing Environment • Process Environment Reuse in Software Engineering Group

  29. 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… End users, customers, data specialists System engineers Project managers, software-configuration staff members Reuse in Software Engineering Group

  30. 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 architecting Reuse in Software Engineering Group

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

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

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

  34. ADL – {Design Model} • Integrating ADL with a Standard Design Method [Robbins, 1998] C2 architecture expressed in UML Wright`s CSP constructor Reuse in Software Engineering Group

  35. Architecture and Reuse • DSSA – Based Reuse • Product-line architecture (PLA) Reuse in Software Engineering Group

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

  37. DSSA Based Reuse • Lifecycle [Balzer et al. 1993] Reuse in Software Engineering Group

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

  39. PLA {Cases} • [Bosch, 1999] • Axis Communications AB • Securitas Larm AB Reuse in Software Engineering Group

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

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

  42. 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 (braun@europa.eng.gtefsd.com), 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

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

  44. 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. Reuse in Software Engineering Group