1 / 44

Software Architecture: An Overview

Software Architecture: An Overview. Vanilson Burégio vaab@cin.ufpe.br. Agenda. History Software Architecture Definition Motivation Roles Architectural Styles Architectural Views Architectural Description Language (ADL) Architecture and Reuse DSSA based reuse PLA.

Leo
Télécharger la présentation

Software Architecture: An Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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

More Related