Software Architecture: Introduction


Published on

This is an introductory lecture to Software Architecture, part of the Advanced Software Engineering course, at the University of L'Aquila, Italy (

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software Architecture: Introduction

  1. 1. L01: Intro to Software Architecture Vittorio Cortellessa & Henry Muccini DISIM Department, University of L’Aquila;
  2. 2. The material in these slides may be freely reproduced and distributed, partially or totally, as far as an explicit reference or acknowledge to the material author is preserved.SEA Group
  3. 3. Intro to SA Intro to Software Testing Lab Structural Testing SA style Model-based Testing ADLs Architecture-based Testing Design Decisions Lab Views/Viewpoints UML Non Functional S.E. UML Profiling Performance modeling Lab Performance analysisSEA Group
  4. 4. SEA Group
  5. 5. SEA Group
  6. 6. SEA Group
  7. 7. SEA Group
  8. 8. SEA Group
  9. 9. Software Architecture The Software Architecture is the earliest model of the whole software system created along the software lifecycle “Traditional” definition: →A set of components and connectors communicating through interfaces “Recent/Future” understanding: →A set of architecture design decisions taken to generate the architecture artifact →Focus on set of Views and Viewpoints, looking at stakeholders and their concernSEA Group
  10. 10. Software Architecture definitions Perry and Wolf, ’92 (aspects): →“Architecture is concerned with the selection of architectural elements, their interactions, and the constraints on those elements and their interactions necessary to provide a framework in which to satisfy the requirements and serve as a basis for the design.” →Elements are divided into processing elements, data elements and connection elements Garlan and Shaw, ’93 (elements): → Architecture for a specific system may be captured as “a collection of computational components - or simply components - together with a description of the interactions between these components - the connectors -” Sommerville, 7th edition, ’04 (process): → The design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural design. The output of this design process is a description of the SA.SEA Group
  11. 11. Application Example “We want to build a software system that allows people to vote electronically. → The citizen goes to the electoral place, and she votes using a hw/sw device. → The vote is stored locally and automatically sent to other computers. → The citizen identity must be validated by the system → …”SEA Group
  12. 12. Basic Requirement Example The voting system must satisfy the following requirements: → One voter – one vote (no more than one vote for voter) → The voter can vote in only one previous designated voting place → The voter must be identified by the election officials at the voting place ─ The citizen identity must be validated by the system → It is not possible to trace the votes back to the voters → The election officials can’t read the results, guarantying that the results are unknown until the end of the voting processSEA Group
  13. 13. ExampleSEA Group
  14. 14. Process Requirements A modeling language Drives modeled in (e.g. UML) Software Architecture modeled in Analysis Implementation TraceabilitySEA Group
  15. 15. Advantages of explicit architecture System analysis →Analysisof whether the system can meet its functional and non-functional requirements is possible. Large-scale reuse →The architecture (or part of it) may be reusable across a range of systems. Stakeholder communication →Architecture may be used as a focus of discussion by system stakeholders.SEA Group
  16. 16. SA History 1992 and 1993: SA is recognized as an independent area of research; → What is SA 1993-1995: SA described through box and line (i.e. informal) diagrams; 1995-1997: Architectural Description Languages (ADLs) are introduced to formally describe SA; → SA and Specification (with ADLs) 1997-2003: → more interest on dynamic aspects of SA; → SA recognized as a valid tool to deal with various aspects of complex, concurrent, real systems; → SA and UML → SA and Analysis 2003-today: → SA vs CBSE, AOP, SOA, etc… → Design Decisions, ViewpointsSEA Group
  17. 17. Civil Architecture vs Software Architecture Civil : » Software : Bricks - Three types of Roof components Chimney top - Multiple instances of the type “brick” » Civil : » Software : - Concrete - Connectors - Construction Rules - Assembly constraintsSEA Group
  18. 18. In general terms… SA describes (in a more or less “formal” notation) how a system is structured into components and connectors… →Components →Connectors SA Structure (topology) →Channels and Ports … and how these components interact →Scenarios →State Diagrams SA Dynamics (behavior) →…SEA Group
  19. 19. General workflowSEA Group
  20. 20. Static Description →Components →Connectors →InterfacesSEA Group
  21. 21. Components A component is a building block that is … →A unit of computation or a data store, with an interface specifying the services it provides and requires →A unit of deployment →A unit of reuse ─ e.g., client, server, database, filters, ... required S’x S1 provided services S’Y C1 S2 S3 servicesSEA Group
  22. 22. Components vs Objects The level of abstraction is usually different Size →Objects tend to be small →Components can be small (one object) or large (a library of objects or a complete application) An architectural component may be implemented by several objects Lifecycle →Objects are created and destroyed constantly →Components are created and destroyed infrequentlySEA Group
  23. 23. Connectors A connector is a building block that enables interaction among components →Events →Client/server middleware →Messages and message buses →Shared variables →Procedure calls (local or remote) →Pipes Connectors may be implicit or explicit →Connectors sometimes are just channels →Connectors sometimes have their own logic and complexity Connectors may be endogenous or exogenousSEA Group
  24. 24. Components and Connectors A component is (or should be) independent of the context in which it is used to provide services A connector is (or should be) dependent on the context in which it is used to connect components Connectors sometimes are modeled as special kinds of componentsSEA Group
  25. 25. Interfaces An interface is the external connection of a component (or connector) that describes how to interact with it Provided and required interfaces are important Spectrum of interface specification → Loosely specified (events go in, events go out) → API style (list of functions) → Very highly specified (event protocols across the interface in CSP)SEA Group
  26. 26. Architecting: example GUI Admin NewsFeeder Action Action Transfer Object DATABASE FeedService Common FeedService Trasformation Action Validation ValidatorService Browser Validation (html Service javascript) NewsFeederDelegate FeedDelegate NewsFeeder FeedDelegate DelegatePOJOs POJOs NewsFeederDAO NewsFeeder Web DAO Services BusinessFactory Factory FeedDAO FeedDAOSEA Group
  27. 27. Architecting: exampleSEA Group
  28. 28. Dynamic Description Behavioral modelsSEA Group
  29. 29. SA dynamics The SA dynamics is expressed in terms of component interactions via connectors •Labeled Transition Systems •Automata •UML StateCharts, Sequence Diagrams, Activity Diagrams •State Diagrams •Message Sequence Charts •…SEA Group
  30. 30. AN EXAMPLE : E-COMMERCE SYSTEM Customer Interface Web Server Cart Server Customer Process Delivery Order Catalog Server Process Customer Server Order Server SA Static DescriptionSEA Group
  31. 31. AN EXAMPLE : E-COMMERCE SYSTEM CustomerInterface CustomerProcess CatalogServer Registered Customer BrowseCatalog BrowseCatalog ReadStatus Catalog DB Catalog Info Involved Catalog Page Output Page SA Dynamic Description : Browse Catalogue Sequence DiagramSEA Group
  32. 32. AN EXAMPLE : E-COMMERCE SYSTEM SA Dynamic Description : Place Order Sequence Diagram (success)SEA Group
  33. 33. AN EXAMPLE : E-COMMERCE SYSTEM SA Dynamic Description : Place Order Sequence Diagram (empty cart)SEA Group
  34. 34. Architectural Elements vs Design Elements “Architecture is concerned with the selection of architectural elements, their interactions, and the constraints on those elements and their interactions necessary to provide a framework in which to satisfy the requirements and serve as a basis for the design.” “Design is concerned with the modularization and detailed interfaces of the design elements, their algorithms and procedures, and the data types needed to support the architecture and to satisfy the requirements.” (Perry & Wolf 92)SEA Group
  35. 35. Architectural Elements vs Design Elements “The architecture of a software system defines that system in terms of computational components and interactions among those components. … In addition to specifying the structure and topology of the system, the architecture shows the correspondence between the requirements and elements of the constructed system, thereby providing some rationale for the design decisions.” (Shaw & Garlan 96)SEA Group
  36. 36. Architecture and NF characteristics… Performance →Localise critical operations and minimise communications. Security →Use a layered architecture with critical assets in the inner layers. Safety →Localise safety-critical features in a small number of sub-systems. Availability →Include redundant components and mechanisms for fault tolerance. Maintainability →Use fine-grain, replaceable components.SEA Group
  37. 37. … may originate architectural conflicts Using large-grain components improves performance but reduces maintainability. Introducing redundant data improves availability but makes security more difficult. Localising safety-related features usually means more communication so degraded performance.SEA Group
  38. 38. Architectural styles The architectural model of a system may conform to a generic architectural model or style. The awareness of these styles can simplify the problem of defining system architectures. There is a strict relation between the ADLs and the style adopted. However, most large systems are heterogeneous and do not follow a single architectural style.SEA Group