Your SlideShare is downloading. ×
Software Architecture: Introduction
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Software Architecture: Introduction

1,302
views

Published on

This is an introductory lecture to Software Architecture, part of the Advanced Software Engineering course, at the University of L'Aquila, Italy (www.di.univaq.it/muccini/SE+/2012)

This is an introductory lecture to Software Architecture, part of the Advanced Software Engineering course, at the University of L'Aquila, Italy (www.di.univaq.it/muccini/SE+/2012)


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,302
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
34
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. L01: Intro to Software Architecture Vittorio Cortellessa & Henry Muccini DISIM Department, University of L’Aquila vittorio.cortellessa@univaq.it;henry.muccini@univaq.it
  • 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. 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. SEA Group
  • 5. SEA Group
  • 6. SEA Group
  • 7. SEA Group
  • 8. SEA Group
  • 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. 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. 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. 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. ExampleSEA Group
  • 14. Process Requirements A modeling language Drives modeled in (e.g. UML) Software Architecture modeled in Analysis Implementation TraceabilitySEA Group
  • 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. 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. 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. 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. General workflowSEA Group
  • 20. Static Description →Components →Connectors →InterfacesSEA Group
  • 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. 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. 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. 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. 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. 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. Architecting: exampleSEA Group
  • 28. Dynamic Description Behavioral modelsSEA Group
  • 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. 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. 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. AN EXAMPLE : E-COMMERCE SYSTEM SA Dynamic Description : Place Order Sequence Diagram (success)SEA Group
  • 33. AN EXAMPLE : E-COMMERCE SYSTEM SA Dynamic Description : Place Order Sequence Diagram (empty cart)SEA Group
  • 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. 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. 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. … 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. 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

×