Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
10/23/2015
1
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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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 2015
Structure of Lecture 07
• What is it? Why bother?
• Terminology: Architect, Architecting, Architecture
• Viewpoints and View Models
• Notation
• Patterns, Styles and DSSAs
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Two Telephone Systems
10/23/2015
2
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Two Telephone Systems – Pro’s and Con’s
Quality Attribute Landline Phone VoIP (Skype)
Power Outage
Tolerant
++ --
Reliable + -
Scalable - ++
Extendable (new
features)
- ++
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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 2015
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 2015
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 ?
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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 2015
Let’s Design a Software System!
Source: George Fairbanks: Just Enough Software Architecture, 2012
CSR: Customer Service Request
10/23/2015
3
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Real Story – Rackspace
e.g., scalability
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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 2015
Rackspace: Architecture 2
CSR: Customer Service Request
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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 2015
Rackspace: Quality Attribute Trade-offs
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Architecture Drivers Importance
Difficulty
Stimulus
Response
10/23/2015
4
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
What if you don’t think architecturally?
Remember: All programs have an architecture ... But not every architecture suits the program (or: problem)!
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Structure of Lecture 07
• What is it? Why bother?
• Terminology: Architect, Architecting, Architecture
• Viewpoints and View Models
• Notation
• Patterns, Styles and DSSAs
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Terminology
• Architect – Person
• Architecting – Process
• Architecture – Product
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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 2015
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 2015
Adding Architecture: The Easy Way
architecture
detailed design
implementation
functionality
agreement
quality
development
stakeholders (few)
10/23/2015
5
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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 2015
Rational Architecture Decisions
Gottfried Wilhelm Leibnitz
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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)
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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; ...
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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.
10/23/2015
6
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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:
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Now, what is ‘Architecture’?
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Architecture in Construction of Buildings
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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 !!!
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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
10/23/2015
7
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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.
(from Bass, Clements, and Kazman, Software Architecture in Practice, SEI Series in Software Engineering. Addison-Wesley, 2003)
3
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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
(from IEEE Standard on the Recommended Practice for Architectural Descriptions, 2000)
4
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Structure of Lecture 07
• What is it? Why bother?
• Terminology: Architect, Architecting, Architecture
• Viewpoints and View Models
• Notation
• Patterns, Styles and DSSAs
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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
10/23/2015
8
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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
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).
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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
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.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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
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.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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
=> 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.
10/23/2015
9
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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
Implementation Viewpoint
Process Viewpoint
Deployment Viewpoint
Scenarios
End-user Functionality
Programmers Software management
Integrators Performance Scalability
System engineers Topology
Communications
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Structure of Lecture 07
• What is it? Why bother?
• Terminology: Architect, Architecting, Architecture
• Viewpoints and View Models
• Notation
• Patterns, Styles and DSSAs
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Standard Notation: UML
Alternatives: ADLs = Architecture Description Languages https://en.wikipedia.org/wiki/Architecture_description_language
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Architecture presentations in practice
• By and large two flavors:
• Powerpoint slides – for managers, users, consultants, etc
• UML diagrams, for technicians
• A small sample …
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Conceptual View Customer, Users
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
More technical view Developers (same system as on previous slide)
10/23/2015
10
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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)
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
So, …
• Different representations
• For different people
• For different purposes
• These representations are both descriptive and prescriptive
• More formal: Architecture Description Languages (ADLs)
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Structure of Lecture 07
• What is it? Why bother?
• Terminology: Architect, Architecting, Architecture
• Viewpoints and View Models
• Notation
• Patterns, Styles and DSSAs
10/23/2015
11
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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 2015
How to solve a problem?
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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 2015
Domain-Specific Software Architectures
• A DSSA is an assemblage of software components
• specialized for a particular type of task (domain),
• generalized for effective use across that domain, and
• composed in a standardized structure (topology) effective for building successful applications.
• DSSAs are the pre-eminent means for maximal reuse of knowledge and prior development.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Reference Architecture – Example
• Structural view of Lunar Lander DSSA
• Invariant with explicit points of variation
• Satellite relay
• Sensors
10/23/2015
12
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Reference Architecture
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Reference Architecture
MURA: Microsoft Upstream Reference Architecture
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
DSSAs also include …
MURA: Microsoft Upstream Reference Architecture
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Extreme Case of DSSA ...
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Product Line Architecture
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Product Line Architecture – Why?
10/23/2015
13
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
How do Product Lines come to be?
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Example: Lunar Lander Game
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Example: Lunar Lander Game
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Product Lines in the Lunar Lander Game
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Product Lines: Components, Features, Products
???
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Better Representation: Variability Model
10/23/2015
14
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
DSSAs vs. Product Lines
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Architectural Patterns
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
State-Logic-Display (a.k.a. Three-Tier Pattern)
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
State-Logic-Display (a.k.a. Three-Tier Pattern)
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
State-Logic-Display in Web Development
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Tiers and Layers
Note: The middle tier might be multi-tiered (resulting in an n-tier architecture)
10/23/2015
15
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Model-View-Controller (MVC)
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Model-View-Controller (MVC)
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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 2015
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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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 2015
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 when ever 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
10/23/2015
16
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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 2015
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 2015
Do you recall ...?
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Do you recall ...?
Boundary = View Entity = Model Control = Controller
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Two Flavors of MVC: Passive Model
• The passive model is employed when one controller manipulates the model exclusively.
• The controller modifies the model and then informs the view that the model has changed and should be refreshed.
• The model is completely independent of the view and the controller, i.e. there is no means for the model to report changes in its state.
• The HTTP protocol is an example of this. There is no simple way in the browser to get asynchronous updates from the server. The browser displays the view and responds to user input, but it does not detect changes in the data on the server.
• Only when the user explicitly requests a refresh is the server interrogated for changes.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Two Flavors of MVC: Active Model
Solution: Observer Design Pattern!
10/23/2015
17
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Two Flavors of MVC: Active Model
Figure shows the structure of the active MVC using Observer and how the observer isolates the model from referencing views directly.
Java code example: http://en.wikipedia.org/wiki/Observer_pattern
Observer Pattern:
The observer pattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.
ConcreteObserver = ’listener’ in Java swing framework!
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
Benefits and Liabilities of MVC
Benefits
Liabilities
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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 2015
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 2015
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 2015
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
10/23/2015
18
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2015
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