MTAT Software Engineering

Transcription

1 MTAT Software Engineering Lecture 07: Architecture and Design Dietmar Pfahl Fall

2 ATI Päev 2015 ICS Day 2015 When? Friday, 16-Oct-2015, 14:00-17:00 What and Who? Welcome and Information Overview Session (in 2-111) Several research groups present their work in alternating and parallel sessions (smaller groups) Why? To inform about the cool research BSc topics

3 Schedule of Lectures Week 01: Introduction to SE Week 02: Requirements Engineering I Week 03: Requirements Engineering II Week 04: Analysis Week 05: Development Infrastructure I Week 06: Development Infrastructure II Week 07: Architecture and Design Week 08: No lecture Week 09: Refactoring Week 10: Verification and Validation I Week 11: Industry Lecture (Testing) Week 12: Verification and Validation II Week 13: Agile/Lean Methods Week 14: Industry Lecture (Agile) Week 15: Measurement / Course wrap-up, review and exam preparation Week 16: no lecture

4 Acknowledgements Textbooks/Slides: Ian Sommerville: Software Engineering, 9th edition, 2010 ( Hans van Vliet: Software Architecture, Free University of Amsterdam, Lecture 2008 Richard Taylor et al.: Software Architecture, University of California at Irvine, Lecture 2011 Alexander Serebrenik: Software architecture: Domain-Specific Software Architecture and Architectural Patterns, TU Eindhoven, Lecture 2013 George Fairbanks: Just Enough Software Architecture, 2012 (Video: Tutorials by Derek Banas (on YouTube)

5 Structure of Lecture 07 What is it? Why bother? Terminology: Architect, Architecting, Architecture Viewpoints and View Models Notation Patterns, Styles and DSSAs

6 Two Telephone Systems

7 Two Telephone Systems Pro s and Con s Quality Attribute Landline Phone VoIP (Skype) Power Outage Tolerant Reliable + - Scalable - ++ Extendable (new features) - ++

8 Trade-Offs and Decision-Making Template Telephone system for a Fire Brigade Station: Because <Power Outage Tolerance> is more important than <Scalability> for this system, we choose a <Landline Phone>, accepting <a higher cost for adding new subscribers>. Quality Attribute Landline Phone VoIP (Skype) Power Outage Tolerant Reliable + - Scalable - ++ Extendable (new features) - ++

9 Exercise: Analysis of Alarm Clock Architectures Consider standard alarm clocks that you have seen. For this exercise, consider each of the following to be representative of an architectural style of alarm clocks: An LED alarm clock for a bedroom, A LCD travel alarm, An analog alarm clock (there are several varieties; choose one).

10 Architecture Evaluation/Analysis Assess whether architecture allows system to meet certain quality goals e.g. regarding maintainability, modifiability, reliability, performance,... Note: the architecture is assessed, while we hope the results will hold for a system yet to be built Software architecture Properties implementation properties? Software system Qualities

11 List of Analysis Methods SAAM (Scenario-based Architecture Analysis Method) SAAMER (Software Architecture Analysis Method for Evolution and Reusability) ATAM (The Architecture Trade-Off Analysis Method) SBAR (Scenario-Based Architecture Reengineering)... and many more...

12 Let s Design a Software System! CSR: Customer Service Request Source: George Fairbanks: Just Enough Software Architecture, 2012

13 Real Story Rackspace e.g., scalability

14 Rackspace: Architecture 1 CSR: Customer Service Request grep examples:

15 Rackspace: Architecture 2 CSR: Customer Service Request

16 Rackspace: Architecture 3 CSR: Customer Service Request (

17 Rackspace: Quality Attribute Trade-offs

18 Architecture Drivers Importance Difficulty Stimulus Response

19 What if you don t think architecturally? Remember: All programs have an architecture... But not every architecture suits the program (or: problem)!

20 Structure of Lecture 07 What is it? Why bother? Terminology: Architect, Architecting, Architecture Viewpoints and View Models Notation Patterns, Styles and DSSAs

21 Terminology Architect Person Architecting Process Architecture Product

22 The Role of the Architect client, users requirements architect solutions developers assess creates assess visualises prescribes appearance, behaviour architectural design construction, co-operation

23 Pre-Architecture Life-Cycle stakeholders (few) functionality quality Characteristics: Iteration mainly on functional requirements Few stakeholders involved No balancing of functional and quality requirements agreement development

24 Adding Architecture: The Easy Way stakeholders (few) functionality quality agreement architecture detailed design development implementation

25 Architecture in the Life-Cycle stakeholders (many) functionality quality architecture Characteristics: Iteration on both functional and quality requirements Many stakeholders involved agreement development Balancing of functional and quality requirements

26 Rational Architecture Decisions Gottfried Wilhelm Leibnitz

27 Design Issues, Options and Decisions A designer is faced with a series of design issues These are sub-problems of the overall design problem. For example, a design issue can be the type and level of security. Security can be decomposed into authentication, authorization, and privacy. Each issue usually has several alternative solutions (or design options) The designer makes a design decision to resolve each issue. This process involves choosing the best option from among the alternatives. Attribute-Driven Design (ADD)

28 ADD Example Iterations Top-level: usability separate UI 3-tier architecture Lower-level, within user interface: security authenticate users Lower-level, within data layer: availability active redundancy

29 Decision Space The space of possible designs that can be achieved by choosing different sets of alternatives. Issues that can be relevant in the decision process could be: - level of flexibility; - outsourcing/external acquisition of client technology (that mans need for separate presentation also relevant for the budget); - if using the Web/Internet; - performance;...

30 Tree or Graph? Issues and options are not independent... A number of options become invalid due to a desired NFR (quality). For example, flexibility could be achieved through certain architectural patterns, like MVC which facilitates separation of concerns and layered architecture restricting client-server interactions. If we choose any of the two, we exclude the 'monolithic' sub-tree and we need a separate GUI layer.

31 More than just IT Technical and non-technical issues and options are intertwined Architects deciding on the type of database versus Management deciding on new strategic partnership or Management deciding on budget

32 Once again: Why is documenting design decisions important? Design rationale example: Prevents repeating (expensive) past steps Explains why this is a good (better: suitable) architecture Emphasizes qualities and criticality for requirements/goals Provides context and background

33 Now, what is Architecture?

34 Architecture in Construction of Buildings

35 Software Architecture Architecture is conceptual. Architectural descriptions are concrete, but the architecture itself is inherently conceptual, and cannot be captured in any (set of) views nor in the code. Architecture is about fundamental things. Abstraction!!! Architecture exists in some context. We can only understand qualities in context. -> Views!!!

36 Software Architecture Definition (1) The architecture of a software system defines that system in terms of computational components and interactions among those components. 2 (from Shaw and Garlan, Software Architecture, Perspectives on an Emerging Discipline, Prentice-Hall, 1996) statement procedure module (design) pattern architecture

37 Software Architecture Definition (2) The software architecture of a system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. 3 (from Bass, Clements, and Kazman, Software Architecture in Practice, SEI Series in Software Engineering. Addison-Wesley, 2003)

38 Software Architecture Definition (3) Architecture is the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution 4 (from IEEE Standard on the Recommended Practice for Architectural Descriptions, 2000)

39 Architecture Sloppy Definitions Architecture is high-level design Architecture is overall structure of the system Architecture is components and connectors Architecture is the structure, the behavior (properties), and the principles and guidelines governing its design and evolution over time

40 Why is Architecture Important? Architecture is the vehicle for stakeholder communication Architecture manifests the earliest set of design decisions Constraints on implementation Dictates organizational structure Inhibits or enables quality attributes Architecture is a transferable abstraction of a system Product lines share a common architecture Allows for template-based development Basis for training

41 Structure of Lecture 07 What is it? Why bother? Terminology: Architect, Architecting, Architecture Viewpoints and View Models Notation Patterns, Styles and DSSAs

42 Analogy with Building Architecture Overall picture of building (client) Front view (client, municipal beauty committee) Separate picture for water supply (plumber) Separate picture for electrical wiring (electrician) etc

43 IEEE Model for Architectural Descriptions Env ironment Mission Sy stem Architecture System stakeholder: an individual, team, or organization (or classes hereof) with interests in, or concerns relative to, a system. Stakeholder Architecture Description Rationale View: a representation of a whole system from the perspective of a related set of concerns. Concern Viewpoint Library Viewpoint View Model Viewpoint: A viewpoint establishes the purposes (concerns) and audience (stakeholders) for a view and the techniques or methods employed in constructing a view.

44 Kruchten s 4+1 View Model End-user Functionality Programmers Software management Logical Viewpoint Implementation Viewpoint Scenarios Process Viewpoint Deployment Viewpoint Integrators Performance Scalability System engineers Topology Communications

45 Kruchten s 4+1 View Model Supports the functional requirements, i.e., the services the system should provide to its end users. Typically, it shows the key abstractions (e.g., classes and associations amongst them). End-user Functionality Logical Viewpoint Process Viewpoint Scenarios Programmers Software management Implementation Viewpoint Deployment Viewpoint Integrators Performance Scalability System engineers Topology Communications

46 Kruchten s 4+1 View Model Takes into account some nonfunctional requirements, such as performance and system availability. It addresses concurrency and distribution, system integrity, and faulttolerance. The process view also specifies which thread of control executes each operation of each class identified in the logical view. So the process view describes the mapping of functions to runtime elements. It concerns the dynamics of the system. A process is a group of tasks which form a logical unit. A process can be started, stopped, resumed, etc., and there is communication between processes. End-user Functionality Logical Viewpoint Process Viewpoint Integrators Performance Scalability Scenarios Programmers Software management Implementation Viewpoint Deployment Viewpoint System engineers Topology Communications

47 Kruchten s 4+1 View Model End-user Functionality Logical Viewpoint Process Viewpoint Scenarios Programmers Software management Implementation Viewpoint Deployment Viewpoint Focuses on the organization of the actual software modules in the software-development environment. The software is packaged in small chunks (program libraries or subsystems) that can be developed by one or more developers. Integrators Performance Scalability System engineers Topology Communications

48 Kruchten s 4+1 View Model End-user Functionality Logical Viewpoint Process Viewpoint Integrators Performance Scalability Scenarios Programmers Software management Implementation Viewpoint Deployment Viewpoint System engineers Topology Communications => Physical view: Defines how the various elements identified in the logical, process, and implementation views (networks, processes, tasks, and objects) must be mapped onto the various nodes. Takes into account the system's non-functional requirements such as system availability, reliability (faulttolerance), performance (throughput), and scalability.

49 4 + 1: Scenario Viewpoint Consists of a small subset of important scenarios (e.g., use cases) to show that the elements of the four views work together seamlessly. This view is redundant with the other ones (hence the "+1"), but it plays two critical roles: Acts as a driver to help designers discover architectural elements during the architecture design; Validates and illustrates the architecture design, both on paper and as the starting point for the tests of an architectural prototype. End-user Functionality Logical Viewpoint Process Viewpoint Integrators Performance Scalability Scenarios Programmers Software management Implementation Viewpoint Deployment Viewpoint System engineers Topology Communications

50 Structure of Lecture 07 What is it? Why bother? Terminology: Architect, Architecting, Architecture Viewpoints and View Models Notation Patterns, Styles and DSSAs

51 Standard Notation: UML Alternatives: ADLs = Architecture Description Languages

52 Architecture presentations in practice By and large two flavors: Powerpoint slides for managers, users, consultants, etc UML diagrams, for technicians A small sample

53 Conceptual View Customer, Users

54 More technical view Developers (same system as on previous slide)

55 Runtime View Deployment View Runtime Component Deployment View Component clientars User machine Search App. Server 1, App Server 2 (WebLogic 7.0) ReserveAndBuy App. Server 1, App Server 2 (WebLogic 7.0) Authenticate App. Server 1, App Server 2 (WebLogic 7.0) ArsStartup App. Server 1, App Server 2 (WebLogic 7.0) LocalRestart App. Server 1, App Server 2 (WebLogic 7.0) ARS Database DB Server (MS SQL Server) CreditCard Database DB Server (MS SQL Server) CreditCard Naming server & Replication mgr God Naming server & Replication mgr

56 High-level overview of the architecture (Logical view Implementation view) A University Course Catalogue System Application layer This Application layer has all the boundary classes that represent the application screens that the user sees. Business Services layer The Business Services process layer has all the controller classes that represent the use case managers that drive the application behavior. This layer represents the client-to-mid-tier border. Middleware layer The Middleware layer supports access to Relational DBMS and OODBMS. Base Reuse package The Base Reuse package includes classes to support list functions and patterns. (see doc on course wiki)

57 Process view of the architecture. Shows the tasks (processes and threads) involved in the system's execution, their interactions and configurations. Processes exist to support student registration, professor functions, registration closing, and access to the external Billing System and Course Catalog System.

58 Deployment view of the architecture. Shows the various physical nodes for the most typical platform configurations. Also shows the allocation of tasks (from the Process View) to the physical nodes.

59 So, Different representations For different people For different purposes These representations are both descriptive and prescriptive More formal: Architecture Description Languages (ADLs)

60 Structure of Lecture 07 What is it? Why bother? Terminology: Architect, Architecting, Architecture Viewpoints and View Models Notation Patterns, Styles and DSSAs To be continued in next lecture

61 Further Reading Len Bass et al, Sofware Architecture in Practice, 2008 (3 rd edition). Jan Bosch, Design & Use of Software Architectures, Frank Buschmann et al., Pattern-Oriented Software Architecture: A System of Patterns, Part II: George Fairbanks: Just Enough Software Architecture, Erich Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, C. Hofmeister et al., Applied Software Architecture, Philippe B. Kruchten, The 4+1 view model of architecture, IEEE Software, 12(6):42-50, November Mary Shaw and David Garlan, Software Architecture; Perspectives of an Emerging Discipline, Richard Taylor et al.: Software Architecture, University of California at Irvine, Lecture Ian Sommerville: Software Engineering, 9th edition, ( Hans van Vliet: Software Architecture, Free University of Amsterdam, Lecture 2008.

62 Next Lecture in 2 weeks from today! Date/Time: Friday, 30-Oct, 10:15-12:00 Topic: Refactoring (and TDD) For you to do: Finish and submit Lab Task 3