MTAT.03.094 Software Engineering - ut...Philippe Kruchten’s 4+1 View Model Process View: • Focuses on behaviour. Addresses needs of system integrators, i.e., people designing the

LTAT.05.003 / Lecture 07 / © Dietmar Pfahl 2017

MTAT.03.094 Software Engineering

Lecture 07: Architecture and Design

Dietmar Pfahl email: [email protected]

Fall 2017


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: Continuous Development

and Integration

Week 09: Refactoring (and TDD)

Week 10: Verification and Validation

Week 11: Crowdsourced Testing

Week 12: Agile/Lean Methods

Week 13: Software Craftsmanship

Week 14: Course wrap-up, review and

exam preparation

Week 15: no lecture


Acknowledgements

Textbooks/Slides: •  Ian Sommerville: Software Engineering, 9th edition, 2010 (http://

www.softwareengineering-9.com/)

•  Stefan Zörner: Softwarearchitekturen dokumentieren und kommunizieren (in German), 2013

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


Structure of Lecture 07

•  Why Architecture? •  Terminology: Architect, Architecting, Architecture •  Viewpoints and View Models •  Notation •  Architecture & Design Patterns


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)

- ++

Which one is better?


Trade-Offs and Decision-Making

Telephone system for a Fire Brigade Station:


++ --


- ++

Which one is better?


Trade-Offs and Decision-Making – Template for capturing design rationales:

Telephone system for a Fire Brigade Station: •  Because <Quality Attribute 1> is more important than <Quality

Attribute 2> for this system, we choose <technical (design/architecture) option>, accepting <drawback>


++ --


- ++


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


++ --


- ++


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)


Rackspace: Quality Attribute Trade-offs


Trade-Offs and Decision-Making – Template

Architecture for the CSR system: •  Because <Scalability> is more important than <Data

freshness> for this system, we choose <V3>, accepting <lower ad hoc query ease>.

Quality Attribute V1 V2 V3 Data Freshness + - - Scalability -- - + Ad-hoc query ease + + -


What if you don’t think architecturally?

Remember: All programs have an architecture ... But not every architecture suits the problem to be solved by the program!





Terminology

•  Architect – Person

•  Architecting – Process

•  Architecture – Product


The Role of the Architect

client,users architect developers

appearance,behaviour

construction,co-operation

architecturaldesign

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


Now, what is ‘Architecting’?


Attribute-Driven Design (ADD)

An architect faces many design issues These are sub-problems of the overall design problem.

Each issue usually has several alternative solutions (or design options)

The designer makes a design decision to resolve each issue.

Process of ‘Architecting’ = choosing the best options from among the alternatives


Design Issues, Options and Decisions

Example: The type and level of Security in a system

•  Security can be decomposed into

•  authentication (user recognition),

•  authorization (user access to data),

•  privacy (encryption of data exchanged on a public network).

•  If the architecture is for

•  a medical system, then all security sub-issues must be addressed.

•  gaming applications, probably not all of them are important, and could be dropped in favor of, e.g., higher performance.


The Bigger Picture – ADD Iterations Example

Top-level: •  usability ⇒ separate UI ⇒ 3-tier

architecture

Lower-level, within user interface: •  security ⇒ authenticate users

Lower-level, within data layer: •  availability ⇒ active redundancy


Once again: Why is documenting design decisions important?

•  Explains why this is a good (better: suitable) architecture •  Emphasizes qualities and criticality with regards

to requirements/goals

•  Provides context and background

•  Prevents repeating (expensive) past steps

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 !!! NB: We can only understand qualities in context.


Software Architecture – Definition

  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

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

NB: ’Principles’ includes the explicit identification and mentioning of properties (-> behaviour)

Structure





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

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.

Standard: ISO/IEC/IEEE 42010: 2011


Most Common Architectural Views


Philippe Kruchten’s 4+1 View Model

(Scenarios)



Logical View:

•  Addresses the end user's concerns: captures 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).

•  In OO systems, this is often at the class level. In complex systems, you may need a package view and decompose the packages into multiple class diagrams. In other paradigms, you may be interested in representing modules and the functions they provide.

•  The end result should be a mapping of the required functionality to components that provide that functionality.

Suggested UML notations:

•  class diagrams, object diagrams, state charts, and composite structures

Logical View Implementation View

Process View Deployment View

Scenarios



Process View: •  Focuses on behaviour. Addresses needs of system integrators, i.e., people

designing the whole system and then integrating the subsystems or the system into a system of systems.

•  This view shows tasks and processes that the system has, interfaces to the outside world and/or between components within the system, the messages sent and received, and how performance, availability, fault-tolerance, and integrity are being addressed. The process view also specifies which thread of control executes each operation of each class identified in the logical view.


•  sequence diagrams, communication diagrams, activity diagrams, timing diagrams, interaction overview diagrams



Scenarios



Implementation View: •  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.


•  component diagrams, package diagrams



Scenarios



Deployment 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. (=> Physical View)

•  Takes into account the system's non-functional requirements such as system availability, reliability (fault-tolerance), performance (throughput), and scalability.

•  This view is primarily for system designers and administrators who need to understand the physical locations of the software, physical connections between nodes, deployment and installation, and scalability.


•  deployment diagrams



Scenarios



Scenarios: •  The scenarios help to capture the requirements so that all the stakeholders

understand how the system is intended to be used.

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


•  Use case diagrams, activity diagrams



Scenarios





Three Flavours of Architectural Notations

•  Informal •  Hand-drawn figures on the whiteboard •  Plain text

•  Semi-Formal: UML

•  Formal •  Architecture Description Languages (ADLs)

https://en.wikipedia.org/wiki/Architecture_description_language


Conceptual View à Customer, Users


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


Logical & Implementation View A University Course Catalogue System (see full report on course wiki)

Process View

Deployment View


Formal Architecture Description Languages (ADLs)


Comparison of Notations





Learning from Others: Patterns, Styles, and DSSAs

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.


How to solve a problem?


Examples of Domains

•  Compilers for programming languages

•  Consumer electronics

•  Electronic commerce system/Web stores

•  Video game

•  Business applications

•  Basic/Standard/“Pro” We can subdivide, too:

•  Avionics systems -> Boeing Jets -> Boeing 747-400


Domain-Specific Software Architectures

A DSSA comprises:

•  A reference architecture, which describes a general computational framework for a significant domain of applications

•  A component library, which contains reusable chunks of domain expertise, and

•  An application configuration method for selecting and configuring components within the architecture to meet particular application requirements

Examples:

•  ADAGE for avionics, AIS for adaptive intelligent systems, and MetaH for missile guidance, navigation, and control systems


Reference Architecture – Example

•  Structural view of Lunar Lander DSSA

•  Invariant with explicit points of variation •  Satellite relay •  Sensors


Reference Architecture MURA: Microsoft Upstream Reference Architecture (Oil & Gas Industry)


DSSAs also include …

MURA: Microsoft Upstream Reference Architecture (Oil & Gas Industry)


Patterns, Styles, and DSSAs


•  Pipes and filters •  Data abstraction and

object-oriented organization

•  Layered systems •  Repositories •  Event-based, implicit

invocation •  ... and many more


Patterns, Styles, and DSSAs



Architectural Patterns


State-Logic-Display (a.k.a. Three-Tier Pattern)


State-Logic-Display (a.k.a. Three-Tier Pattern)


State-Logic-Display in Web Development


Model-View-Controller (MVC)


Model-View-Controller (MVC)


MVC Code Example

The simplest Model View Controller (MVC) Java example by Joseph Mack jmack (at) austintek (dot) com Copyright © 2011 Joseph Mack 15 Aug 2011, released under GPL-v3 http://www.austintek.com/mvc/

This example uses AWT (Abstract Window Toolkit) The predecessor of swing and javafx


MVC Code Example



MVC Code Example



MVC Code Example: RunMVC.java & Main.java public class RunMVC {

private int start_value = 1; //initialise model, which in turn initialises view

public RunMVC() {

//create Model and View Model myModel = new Model(); View myView = new View();

//tell Model about View. myModel.addObserver(myView);

//create Controller; tell it about Model and View, initialise model Controller myController = new Controller(); myController.addModel(myModel); myController.addView(myView); myController.initModel(start_value);

//tell View about Controller myView.addController(myController);

} //RunMVC()

} //RunMVC

public class Main{

public static void main(String[] args){

RunMVC mainRunMVC = new RunMVC();

} //main() } //Main }


MVC Code Example: Model.java (1)

//Model holds an int counter (that's all it is). //Model is an Observable //Model doesn't know about View or Controller public class Model extends java.util.Observable {

private int counter; //primitive, automatically initialised to 0

public Model(){

System.out.println("Model()");

} //Model()

…

The Model has - a counter - a method to increment the counter (the Model's main functionality) - a method to intitialise the counter - a null constructor (well, the constructor prints a notice to the console)



… //notifyObservers() //model sends notification to view because of RunMVC: myModel.addObserver(myView) //myView then runs update() // //model Push - send counter as part of the message public void setValue(int value) {

this.counter = value; System.out.println("Model init: counter = " + counter); setChanged(); //model Push - send counter as part of the message notifyObservers(counter);

} //setValue()

… In this code Model:notifyObservers(counter) pushes the model's status to the View.



… public void incrementValue() {

++counter; System.out.println("Model: counter = " + counter); setChanged(); //model Push - send counter as part of the message notifyObservers(counter);

} //incrementValue()

} //Model The model has state (a counter). The model accepts a command to change state (increment the counter). The model emits notices of change of state, and the new state. The model has no code specifying where the notices are sent or from where it will accept the command. This makes the model reusable. A non-reusable piece of code RunMVC tells model to send notices to view and to accept commands from controller.


MVC Code Example: View.java (1) //View is an Observer import java.awt.Button; … import java.lang.Integer; //int from Model is passed as an Integer import java.util.Observable; //for update(); import java.awt.event.ActionListener; //for addController() class View implements java.util.Observer {

private TextField myTextField; private Button button; View() { System.out.println("View()"); //frame and panel arein constructor and not an attribute as doesn't need to be visible to whole class Frame frame = new Frame("simple MVC"); frame.add("North", new Label("counter"));

myTextField = new TextField(); frame.add("Center", myTextField);

Panel panel = new Panel(); button = new Button("PressMe"); panel.add(button); frame.add("South", panel);

frame.addWindowListener(new CloseListener()); frame.setSize(200,100); frame.setLocation(100,100); frame.setVisible(true);

} //View()

…

1

PressMe

Counter =

The view is an Observer. The view is a GUI which has -  a TextField to display the status of the model

(the value of the counter). -  a Button to communicate with the controller

(the controller is a button Listener).


MVC Code Example: View.java (2) …

// Called from the Model public void update(Observable obs, Object obj) { //who called us and what did they send? System.out.println ("View: Observable is " + obs.getClass() + ", object passed is " + obj.getClass()); //model Push //parse obj myTextField.setText("" + ((Integer)obj).intValue()); //obj is an Object, need to cast to an Integer } //update()

public void addController(ActionListener controller){ System.out.println("View: adding controller"); button.addActionListener(controller); //need instance of controller before can add it as a listener } //addController()

//to initialise TextField public void setValue(int v){

myTextField.setText("" + v); } //setValue() public static class CloseListener extends WindowAdapter { public void windowClosing(WindowEvent e) { e.getWindow().setVisible(false); System.exit(0); } //windowClosing() } //CloseListener

} //View

The interesting functionality of View communicates with the controller and the model. -  a method addController(ActionListener

controller), which attaches the controller as a listener to the button (called by the glue class RunMVC).

-  the magic part, update(), which receives the status message from model.


MVC Code Example: Controller.java (1)

//Controller is a Listener class Controller implements java.awt.event.ActionListener {

//Controller has Model and View hard-wired in; should normally use model or view API Model model; View view;

Controller() { System.out.println ("Controller()"); } //Controller()

//invoked when a button is pressed public void actionPerformed(java.awt.event.ActionEvent e){ //uncomment to see what action happened at view // /* System.out.println ("Controller: The " + e.getActionCommand() + " button is clicked at " + new java.util.Date(e.getWhen()) + " with e.paramString " + e.paramString() ); // */ System.out.println("Controller: acting on Model"); model.incrementValue(); } //actionPerformed()

…

Controller is a Listener. It has a method actionPerformed(), which listens to View's button. When the method receives a button press, it changes the state of Model by running myModel.incrementValue().


MVC Code Example: Controller.java (2)

…

//I should be able to add any model/view with the correct API //but here I can only add Model/View public void addModel(Model m){ System.out.println("Controller: adding model"); this.model = m; } //addModel()

public void addView(View v){ System.out.println("Controller: adding view"); this.view = v; } //addView()

public void initModel(int x){ model.setValue(x); } //initModel()

} //Controller Controller has the following routine functionality

- a constructor which sends a notice to the console. (->previous slide) - a method to initialise the Model. - methods to get references to myModel and myView (these methods are run by the glue class RunMVC).


Benefits and Liabilities of MVC

Benefits

Liabilities


Design Patterns

•  A design pattern is a way of reusing abstract knowledge about a problem and its solution.

•  A pattern is a description of the problem and the essence of its solution.

•  It should be sufficiently abstract to be reused in different settings.

•  Pattern descriptions usually make use of object-oriented characteristics such as inheritance and polymorphism.

ELEMENTS:

Name

A meaningful pattern identifier.

Problem description.

Solution description (might have an example)

Not a concrete design but a template for a design solution that can be instantiated in different ways.

Benefits and Consequences

The results and trade-offs of applying the pattern.


The Observer Pattern Name: Observer

Problem description

•  Situations where multiple displays of state are needed.

Solution description

•  Separates the display of object state from the object itself.

•  See UML description. Consequences

•  Optimisations to enhance display performance are difficult.


The Observer Pattern – Class Diagram Explanation of Observer Design Pattern’s Class Diagram:

•  Subject is the one being observed. It has attach() & detach() methods to add or remove observers respectively. It uses notify() method to publish its changes to observers/subscribers.

•  Observers register/attach themselves to the Subject they want to listen to for updates.

•  ConcreteObservers are actual Observer objects which treat the notifications they receive from the Subject in their own individual ways.

•  ConcreteSubject is the actual Subject object whose state change is notified to multiple Observers.

Source: http://www.javabrahman.com/design-patterns/observer-design-pattern-in-java/


The Observer Pattern – Inbuilt in JDK

Inbuilt Observer Pattern in Java: Java has an inbuilt Observer pattern implementation using:

•  Class java.util.Observable (represents Subject)

•  Interface java.util.Observer (represents an Observer)


Concrete Observers in Java need to implement the Observer interface, whereas concrete Subject needs to extend Observable to provide its own notification logic.

Observers java.util.Observable <<interface>> java.util.Observer


The Observer Pattern – Example Implementation (Class Diagram)


Observers


The Observer Pattern – Example Implementation (Code)


importjava.util.Observable;importjava.util.Observer;publicclassSubscriber1implementsObserver{StringcurrentPublisherState;@Overridepublicvoidupdate(Observableo,Objectarg){System.out.println("NewstatereceivedbySubscriber1:"+arg.toString());this.currentPublisherState=(String)arg;}}

importjava.util.Observable;importjava.util.Observer;publicclassSubscriber2implementsObserver{StringcurrentPublisherState;@Overridepublicvoidupdate(Observableo,Objectarg){System.out.println("NewstatereceivedbySubscriber2:"+arg.toString());this.currentPublisherState=(String)arg;}}

importjava.util.Observable;publicclassPublisherextendsObservable{publicvoidchangeStateTo(StringnewStateName){this.setChanged();this.notifyObservers(newStateName);}}

publicclassClient{publicstaticvoidmain(Stringargs[]){Publisherpublisher=newPublisher();publisher.addObserver(newSubscriber1());publisher.addObserver(newSubscriber2());publisher.changeStateTo("assigned");}}


The Observer Pattern – Example Implementation (Code) Lets quickly go through what’s there in Java’s example’s class diagram & corresponding code –

•  Publisher is the Subject. It extends java.util.Observable.

•  Subscriber1 & Subscriber2 are the Observers. They implement java.util.Observer.

•  Client first initiates Publisher. It then adds one instance each of Subscriber1 & Subscriber2 to Publisher’s list of Observers.

•  Client then invokes method changeStateTo() with new state value as “assigned”. Internally, Publisher then initiates notifyObservers() with this new state value. Before notifying, Publisher calls setStateChanged() which is a requirement of the java’s observer pattern implementation.

•  update() methods of Subscriber1 and Subscriber 2 are called internally by the notifyObservers() method and the new state value received by both in the parameter arg is printed.


Three Types of Patterns

Creational patterns:

•  Deal with initializing and configuring classes and objects

Structural patterns: •  Deal with decoupling interface and implementation of classes and

objects •  Composition of classes or objects

Behavioral patterns: •  Deal with dynamic interactions among societies of classes and objects •  How they distribute responsibility

Observer


Benefits of Design Patterns

•  Design patterns enable large-scale reuse of software architectures and also help document systems

•  Patterns explicitly capture expert knowledge and design tradeoffs and make it more widely available

•  Patterns help improve developer communication •  Pattern names form a common vocabulary

More on Design Patterns: Mini-Tutorials by Derek Banas https://www.youtube.com/playlist?list=PLF206E906175C7E07


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

•  Date/Time: •  Friday, 27-Oct, 10:15-12:00

•  Topic: •  Continuous Development and Integration •  Lecturer: Svetlana Omelkova, Nevercode.io

•  For you to do: •  Go to Labs next week! •  Submit Homework 3 •  Start working on Homework 4

Documents

MTAT.03.094 Software Engineering - ut...Philippe Kruchten’s 4+1 View Model Process View: • Focuses on behaviour. Addresses needs of system integrators, i.e., people designing the