Upload
phungtuyen
View
225
Download
3
Embed Size (px)
Citation preview
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
MTAT.03.094
Software Engineering
Lecture 07: Architecture
and Design
Dietmar Pfahl
email: [email protected] 2016
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Schedule of Lectures (Final)
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: Refactoring
Week 09: Verification and Validation I
Week 10: Guest Lecture I (Testing)
Week 11: Guest Lecture II (Software
Quality Management)
Week 12: Verification and Validation II
Week 13: Agile/Lean Methods
Week 14: Guest Lecture III (Software
Craftsmanship)
Week 15: Course wrap-up, review and
exam preparation
Week 16: no lecture
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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)
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Structure of Lecture 07
• Why Architecture?
• Terminology: Architect, Architecting, Architecture
• Viewpoints and View Models
• Notation
• Architecture & Design Patterns
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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?
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Trade-Offs and Decision-Making
Telephone system for a Fire Brigade Station:
Quality Attribute Landline Phone VoIP (Skype)
Power Outage
Tolerant
++ --
Reliable + -
Scalable - ++
Extendable (new
features)
- ++
Which one is better?
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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>
Quality Attribute Landline Phone VoIP (Skype)
Power Outage
Tolerant
++ --
Reliable + -
Scalable - ++
Extendable (new
features)
- ++
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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)
- ++
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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).
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Architecture Analysis – Purpose
• 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
Softwarearchitecture
Softwaresystem
Properties Qualities
implementation
properties?
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Architecture Analysis – Techniques
• Questioning techniques:
• how does the system react to various situations;
• often make use of scenarios
• Measuring techniques:
• rely on quantitative measures; architecture metrics, simulation, etc.
• e.g., cohesion & coupling
• Different types of scenarios, e.g. use-cases, likely changes, stress situations, risks, far-into-the-future scenarios
• Which stakeholders to ask for scenarios?
• When do you have enough scenarios?
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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 ...
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Let’s Design a Software System!
Source:
George Fairbanks: Just Enough Software Architecture, 2012
CSR: Customer Service Request
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Rackspace: Architecture 1
CSR: Customer Service Request
grep examples:http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_04_02.html
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Rackspace: Architecture 2
CSR: Customer Service Request
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Rackspace: Architecture 3
CSR: Customer Service Request
(https://www.usenix.org/legacy/publications/library/proceedings/osdi04/tech/full_papers/dean/dean_html/index.html)
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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!
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Structure of Lecture 07
• Why Architecture?
• Terminology: Architect, Architecting, Architecture
• Viewpoints and View Models
• Notation
• Architecture & Design Patterns
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Terminology
• Architect – Person
• Architecting – Process
• Architecture – Product
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
The Role of the Architect
client,
usersarchitect developers
appearance,
behaviour
construction,
co-operation
architectural
design
visualises prescribes
requirements solutions
createsassess assess
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Adding Architecture: The Easy Way
architecture
detailed design
implementation
functionality
agreement
quality
development
stakeholders(few)
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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:
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Structure of Lecture 07
• Why Architecture?
• Terminology: Architect, Architecting, Architecture
• Viewpoints and View Models
• Notation
• Architecture & Design Patterns
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Philippe Kruchten’s
4+1 View Model
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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Philippe Kruchten’s
4+1 View Model
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.
Suggested UML notations:
• sequence diagrams, communication diagrams, activity diagrams, timing diagrams, interaction overview diagrams
Logical View Implementation
View
Process View Deployment View
Scenarios
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Philippe Kruchten’s
4+1 View Model
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.
Suggested UML notations:
• component diagrams, package diagrams
Logical View Implementation
View
Process View Deployment View
Scenarios
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Philippe Kruchten’s
4+1 View Model
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.
Suggested UML notations:
• deployment diagrams
Logical View Implementation
View
Process View Deployment View
Scenarios
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Philippe Kruchten’s
4+1 View Model
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.
Suggested UML notations:
• Use case diagrams, activity diagrams
Logical View Implementation
View
Process View Deployment View
Scenarios
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Structure of Lecture 07
• Why Architecture?
• Terminology: Architect, Architecting, Architecture
• Viewpoints and View Models
• Notation
• Architecture & Design Patterns
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
More technical view Developers (same system as on previous slide)
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Logical & Implementation View
A University Course Catalogue System
(see full report on course wiki)
Process View
Deployment View
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Structure of Lecture 07
• Why Architecture?
• Terminology: Architect, Architecting, Architecture
• Viewpoints and View Models
• Notation
• Architecture & Design Patterns
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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 MetaHfor missile guidance, navigation, and control systems
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Reference Architecture – Example
• Structural viewof Lunar LanderDSSA
• Invariant withexplicit pointsof variation
• Satellite relay
• Sensors
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Reference Architecture
MURA: Microsoft Upstream Reference Architecture(Oil & Gas Industry)
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
DSSAs also include …MURA: Microsoft Upstream Reference Architecture(Oil & Gas Industry)
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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.
• Pipes and filters• Data abstraction and
object-oriented organization
• Layered systems• Repositories• Event-based, implicit
invocation• ... and many more
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
MVC Code Example:
CalculatorModel.java
01 // The Model performs all the calculations needed
02 // and that is it. It doesn't know the View exists
03
04 public class CalculatorModel {
05
06 // Holds the value of the sum of the numbers
07 // entered in the view
08
09 private int calculationValue;
11
12 public void addTwoNumbers(int firstNumber, int secondNumber){
13
14 calculationValue = firstNumber + secondNumber;
16 }
17
18 public int getCalculationValue(){
19
20 return calculationValue;
22 }
24 }
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
MVC Code Example:
CalculatorView.java (1) 01 // This is the View
02 // Its only job is to display what the user sees. It performs no calculations,
03 // but instead passes information entered by the user to whomever needs it.
06
07 import java.awt.event.ActionListener;
09 import javax.swing.*;
10
11 public class CalculatorView extends JFrame{
12
13 private JTextField firstNumber = new JTextField(10);
14 private JLabel additionLabel = new JLabel("+");
15 private JTextField secondNumber = new JTextField(10);
16 private JButton calcButton = new JButton("Calc");
17 private JTextField calcSolution = new JTextField(10);
18
19 CalculatorView(){
20
21 // Sets up the view and adds the components
22
23 JPanel calcPanel = new JPanel();
24
25 this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
26 this.setSize(600, 200);
27
28 calcPanel.add(firstNumber);
29 calcPanel.add(additionLabel);
30 calcPanel.add(secondNumber);
31 calcPanel.add(calcButton);
32 calcPanel.add(calcSolution);
33
34 this.add(calcPanel);
35
36 // End of setting up the components --------
38 }
Num1 Num2+
Calc Sum
The class extends the abstract class JFrame (defined in the swing GUI widget toolkit for Java – now succeeded by JavaFX)
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
MVC Code Example:
CalculatorView.java (2) 39
40 public int getFirstNumber(){
42 return Integer.parseInt(firstNumber.getText());
44 }
45
46 public int getSecondNumber(){
48 return Integer.parseInt(secondNumber.getText());
50 }
51
52 public int getCalcSolution(){
54 return Integer.parseInt(calcSolution.getText());
56 }
57
58 public void setCalcSolution(int solution){
60 calcSolution.setText(Integer.toString(solution));
62 }
63
64 // If the calcButton is clicked execute a method
65 // in the Controller named actionPerformed
66
67 void addCalculateListener(ActionListener listenForCalcButton){
69 calcButton.addActionListener(listenForCalcButton);
71 }
72
73 // Open a popup that contains the error message passed
74
75 void displayErrorMessage(String errorMessage){
77 JOptionPane.showMessageDialog(this, errorMessage);
79 }
81 }
Num1 Num2+
Calc Sum
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
MVC Code Example:
CalculatorController.java (1)
01 import java.awt.event.ActionEvent;
02 import java.awt.event.ActionListener;
03
04 // The Controller coordinates interactions
05 // between the View and Model
06
07 public class CalculatorController {
08
09 private CalculatorView theView;
10 private CalculatorModel theModel;
11
12 public CalculatorController(CalculatorView theView, CalculatorModel theModel) {
13 this.theView = theView;
14 this.theModel = theModel;
15
16 // Tell the View that whenever the calculate button
17 // is clicked to execute the actionPerformed method
18 // in the CalculateListener inner class
19
20 this.theView.addCalculateListener(new CalculateListener());
21 }
22
More on the value and advantage of using inner classes (like CalculateListener):http://www.javaworld.com/article/2077411/core-java/inner-classes.html
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
MVC Code Example:
CalculatorController.java (2)
23 class CalculateListener implements ActionListener{
24
25 public void actionPerformed(ActionEvent e) {
26
27 int firstNumber, secondNumber = 0;
28
29 // Surround interactions with the view with
30 // a try block in case numbers weren't
31 // properly entered
32
33 try{
34
35 firstNumber = theView.getFirstNumber();
36 secondNumber = theView.getSecondNumber();
37
38 theModel.addTwoNumbers(firstNumber, secondNumber);
39
40 theView.setCalcSolution(theModel.getCalculationValue());
42 }
43
44 catch(NumberFormatException ex){
45
46 System.out.println(ex);
48 theView.displayErrorMessage("You Need to Enter 2 Integers");
50 }
52 }
54 }
56 }
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
MVC Code Example:
MVCCalculator.java
01 public class MVCCalculator {
02
03 public static void main(String[] args) {
04
05 CalculatorView theView = new CalculatorView();
06
07 CalculatorModel theModel = new CalculatorModel();
08
09 CalculatorController theController = new CalculatorController(theView,theModel);
10
11 theView.setVisible(true);
12
13 }
14 }
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
Benefits and Liabilities of MVC
Benefits
Liabilities
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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/
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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)
Source:http://www.javabrahman.com/design-patterns/observer-design-pattern-in-java/
Concrete Observers in Java need to
implement the Observer interface,
whereas concrete Subject needs to
extend Observable to provide its own
notification logic.
Observersjava.util.Observable <<interface>>java.util.Observer
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
The Observer Pattern – Example
Implementation (Class Diagram)
Source:http://www.javabrahman.com/design-patterns/observer-design-pattern-in-java/
Observers
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
The Observer Pattern – Example
Implementation (Code)
Source:http://www.javabrahman.com/design-patterns/observer-design-pattern-in-java/
import java.util.Observable;import java.util.Observer;public class Subscriber1 implements Observer{String currentPublisherState;@Overridepublic void update(Observable o, Object arg) {System.out.println("New state received by Subscriber
1:"+arg.toString());this.currentPublisherState=(String)arg;
}}
import java.util.Observable;import java.util.Observer;public class Subscriber2 implements Observer{String currentPublisherState;@Overridepublic void update(Observable o, Object arg) {System.out.println("New state received by Subscriber
2:"+arg.toString());this.currentPublisherState=(String)arg;
}}
import java.util.Observable;public class Publisher extends Observable{public void changeStateTo(String newStateName){this.setChanged();this.notifyObservers(newStateName);
}}
public class Client {public static void main(String args[]){Publisher publisher=new Publisher();publisher.addObserver(new Subscriber1());publisher.addObserver(new Subscriber2());publisher.changeStateTo("assigned");
}}
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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.
Summary:
In the above tutorial we understood what is Observer design pattern and the main
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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 Banashttps://www.youtube.com/playlist?list=PLF206E906175C7E07
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2016
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.