MTAT.03.094 Software Engineering · 2015. 10. 30. · Week 01: Introduction to SE Week 02: Requirements Engineering I ... Analysis of Alarm Clock Architectures Consider standard alarm

MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015

MTAT.03.094

Software Engineering

Lecture 07: Architecture

and Design

Dietmar Pfahl

email: [email protected] Fall 2015


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 …

http://www.cs.ut.ee/en/ics-day





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


Acknowledgements

Textbooks/Slides:

• Ian Sommerville: Software Engineering, 9th edition, 2010 (http://www.softwareengineering-9.com/)

• 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: https://www.youtube.com/watch?v=x30DcBfCJRI)

• Tutorials by Derek Banas (on YouTube)

https://www.youtube.com/watch?v=x30DcBfCJRI

https://www.youtube.com/watch?v=x30DcBfCJRI


Structure of Lecture 07

• What is it? Why bother?

• Terminology: Architect, Architecting, Architecture

• Viewpoints and View Models

• Notation

• Patterns, Styles and DSSAs


Two Telephone Systems


Two Telephone Systems – Pro’s and Con’s

Quality Attribute Landline Phone VoIP (Skype)

Power Outage

Tolerant

++ --

Reliable + -

Scalable - ++

Extendable (new

features)

- ++


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)

- ++


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


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

Software system

Properties Qualities

implementation

properties ?


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


Let’s Design a Software System!

Source: George Fairbanks: Just Enough Software Architecture, 2012

CSR: Customer Service Request


Real Story – Rackspace

e.g., scalability


Rackspace: Architecture 1


grep examples: http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_04_02.html







(https://www.usenix.org/legacy/publications/library/proceedings/osdi04/tech/full_papers/dean/dean_html/index.html)

https://www.usenix.org/legacy/publications/library/proceedings/osdi04/tech/full_papers/dean/dean_html/index.html


Rackspace: Quality Attribute Trade-offs


Architecture Drivers Importance

Difficulty

Stimulus

Response


What if you don’t think architecturally?

Remember: All programs have an architecture ... But not every architecture suits the program (or: problem)!






• Notation



Terminology

• Architect – Person

• Architecting – Process

• Architecture – Product


The Role of the Architect

client,

usersarchitect developers

appearance,

behaviour

construction,

co-operation

architectural

design

visualises prescribes

requirements solutions

createsassess assess


Pre-Architecture Life-Cycle

functionality

agreement

quality

development

stakeholders (few)

Characteristics:

• Iteration mainly on functional requirements

• Few stakeholders involved

• No balancing of functional and quality requirements


Adding Architecture: The Easy Way

architecture

detailed design

implementation

functionality

agreement

quality

development

stakeholders (few)


Architecture in the Life-Cycle

functionality

architecture

quality

agreement

stakeholders (many)

development

Characteristics:

• Iteration on both functional and quality requirements

• Many stakeholders involved

• Balancing of functional and quality requirements


Rational Architecture Decisions

Gottfried Wilhelm Leibnitz


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)


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


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


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.


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


Once again: Why is documenting design

decisions important?

• 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

Design rationale example:


Now, what is ‘Architecture’?


Architecture in Construction of Buildings


Software Architecture

• Architecture is conceptual.

• Architecture is about fundamental things.

• Architecture exists in some context.

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


Software Architecture – Definition (1)

The architecture of a software system defines that system in terms of computational components and interactions among those components.

(from Shaw and Garlan, Software Architecture, Perspectives on an Emerging Discipline, Prentice-Hall, 1996)

statement

procedure

module

(design) pattern

architecture

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.

(from Bass, Clements, and Kazman, Software Architecture in Practice, SEI Series in Software Engineering. Addison-Wesley, 2003)

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

(from IEEE Standard on the Recommended Practice for Architectural Descriptions, 2000)

4


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


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






• Notation



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


IEEE Model for Architectural Descriptions

Mission

Sy stemEnv ironment Architecture

RationaleArchitecture Description

Concern

Library Viewpoint

Viewpoint

Stakeholder

Model

View

Mission

Sy stemEnv ironment Architecture

RationaleArchitecture Description

Concern

Library Viewpoint

Viewpoint

Stakeholder

Model

View

System stakeholder: an individual, team, or organization (or classes hereof) with interests in, or concerns relative to, a system.

View: a representation of a whole system from the perspective of a related set of concerns.

Viewpoint: A viewpoint establishes the purposes (concerns) and audience (stakeholders) for a view and the techniques or methods employed in constructing a view.


Kruchten’s 4+1 View Model

Logical Viewpoint

Implementation Viewpoint

Process Viewpoint

Deployment Viewpoint

Scenarios

End-user Functionality

Programmers Software management

Integrators Performance Scalability

System engineers Topology

Communications



Logical Viewpoint


Process Viewpoint


Scenarios





Communications

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



Logical Viewpoint


Process Viewpoint


Scenarios





Communications

Takes into account some nonfunctional requirements, such as performance and system availability. It addresses concurrency and distribution, system integrity, and fault-tolerance. 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.



Logical Viewpoint


Process Viewpoint


Scenarios





Communications

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.



Logical Viewpoint


Process Viewpoint


Scenarios





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 (fault-tolerance), performance (throughput), and scalability.


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.

Logical Viewpoint


Process Viewpoint


Scenarios





Communications






• Notation



Standard Notation: UML

Alternatives: ADLs = Architecture Description Languages https://en.wikipedia.org/wiki/Architecture_description_language


Architecture presentations in practice

• By and large two flavors:

• Powerpoint slides – for managers, users, consultants, etc

• UML diagrams, for technicians

• A small sample …


Conceptual View Customer, Users


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


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

Runtime View Deployment View


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.

High-level overview of the architecture (Logical view – Implementation view)

A University Course Catalogue System

(see doc on course wiki)


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.


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.


So, …

• Different representations

• For different people

• For different purposes

• These representations are both descriptive and prescriptive

• More formal: Architecture Description Languages (ADLs)






• Notation


To be continued in next lecture


Further Reading

• Len Bass et al, Sofware Architecture in Practice, 2008 (3rd edition).

• Jan Bosch, Design & Use of Software Architectures, 2000.

• Frank Buschmann et al., Pattern-Oriented Software Architecture: A System of Patterns, 1996. Part II: 2001.

• George Fairbanks: Just Enough Software Architecture, 2012.

• Erich Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, 1995.

• C. Hofmeister et al., Applied Software Architecture, 1999.

• Philippe B. Kruchten, The 4+1 view model of architecture, IEEE Software, 12(6):42-50, November 1995.

• Mary Shaw and David Garlan, Software Architecture; Perspectives of an Emerging Discipline, 1995.

• Richard Taylor et al.: Software Architecture, University of California at Irvine, Lecture 2011.

• Ian Sommerville: Software Engineering, 9th edition, 2010. (http://www.softwareengineering-9.com/)

• Hans van Vliet: Software Architecture, Free University of Amsterdam, Lecture 2008.


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

Documents

MTAT.03.094 Software Engineering · 2015. 10. 30. · Week 01: Introduction to SE Week 02: Requirements Engineering I ... Analysis of Alarm Clock Architectures Consider standard alarm