Figures – Chapter 7.

Slides:



Advertisements
Similar presentations
Chapter 7 – Design and Implementation
Advertisements

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design 1.
Chapter 7 – Design and Implementation
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
Winter 2007ACS-3913 Ron McFadyen1 Also known as publish/subscribe The essence of this pattern is that one or more objects (called observers or listeners)
 Recent researches show that predicative programming can be used to specify OO concepts including classes, objects, interfaces, methods, single and multiple.
Observer Method 1. References Gamma Erich, Helm Richard, “Design Patterns: Elements of Reusable Object- Oriented Software” 2.
Design Patterns Pepper. Find Patterns Gang of Four created 23 Siemens published another good set x
Lecture 10: Chapter 12 Pattern-Based Design
Chapter 7 – Design and Implementation Lecture 1 1Chapter 7 Design and implementation.
Chapter 7 – Object-Oriented Design
Chapter 7 – Design and Implementation Lecture 1 1Chapter 7 Design and implementation.
SWE Introduction to Software Engineering
Fall 2009ACS-3913 Ron McFadyen1 Observer Problem: There are many objects (subscribers) needing to know of the state changes, or events, of another object.
Spring 2010ACS-3913 Ron McFadyen1 Weather Station Page 39+ In this application, weather station devices supply data to a weather data object. As the data.
7M701 1 Software Engineering Object-oriented Design Sommerville, Ian (2001) Software Engineering, 6 th edition: Chapter 12 )
Observer Pattern Fall 2005 OOPD John Anthony. What is a Pattern? “Each pattern describes a problem which occurs over and over again in our environment,
Observer Pattern Tu Nguyen. General Purpose When one object changes state, all the dependent objects are notified and updated. Allows for consistency.
Chapter 14: Object-Oriented Design
© 2005 Prentice Hall8-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
1 Objectives To introduces the concept of software Design. To introduce the concept of Object- Oriented Design (OOD). To Define various aspects about object.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented design 2.
Satzinger, Jackson, and Burd Object-Orieneted Analysis & Design
©Ian Sommerville 2006Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
Oct Ron McFadyen1 Collaborations Collaboration : an arrangement of classes, links, roles in a context to implement some behaviour. Useful for.
Winter 2007ACS-3913 Ron McFadyen1 Observer Pattern Problem: There are many objects (observers / subscribers) needing to know of the state changes, or events,
March Ron McFadyen1 Observer Problem: There are many objects (subscribers) needing to know of the state changes, or events, of another object.
Chapter 7 – Design and Implementation
Design Patterns. What is wrong with this picture? Ball double gravity 32.1 Private: Enemy double gravity 32.1 Private: Don’t repeat yourself!
Design Patterns.
Software Engineering Lecture 8 – Design and Implementation
Object-Oriented Design Yonsei University 2 nd Semester, 2014 Woo-Cheol Kim.
02 - Behavioral Design Patterns – 2 Moshe Fresko Bar-Ilan University תשס"ח 2008.
Chapter 7 – Design and Implementation Lecture 2 1Chapter 7 Design and implementation.
CS 210 Introduction to Design Patterns September 7 th, 2006.
Observer Behavioral Pattern. Intent Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified.
Programming in C# Observer Design Pattern
Behavioral Pattern: Observer C h a p t e r 5 – P a g e 186 A large monolithic design does not scale well as additional graphical and monitoring requirements.
Chapter 12: Design Phase n 12.1 Design and Abstraction n 12.2 Action-Oriented Design n 12.3 Data Flow Analysis n Data Flow Analysis Example n
Oct R McFadyen1 Facade P Problem: There are a set of classes, a subsystem, that you need to interact with for some purpose, but you don’t.
Lecture 1: Introduction to Software Engineering WXGE6103 Software Engineering Process and Practice Object-oriented Design.
Proxy, Observer, Symbolic Links Rebecca Chernoff.
OBJECT ORIENTED AND FUNCTION ORIENTED DESIGN 1 Chapter 6.
CSE 332: Design Patterns Review: Design Pattern Structure A design pattern has a name –So when someone says “Adapter” you know what they mean –So you can.
Slide 1 Chapter 10 Object-oriented Design. Slide 2 Characteristics of OOD l Objects are abstractions of real-world or system entities and manage themselves.
Chapter 7 – Design and Implementation 1Chapter 7 Design and implementation.
Observer Pattern Keeping An Eye on Things Need to introduce observer pattern formally first, include book definition & design principle Keeping An Eye.
OBSERVER PATTERN OBSERVER PATTERN Presented By Presented By Ajeet Tripathi ISE
The Observer Design Pattern Author :Erich Gamma, et al. Source :Elements of Reusable Object-Oriented Software Speaker : Chiao-Ping Chang Advisor : Ku-Yaw.
Chapter 7 Lecture 1 Design and Implementation. Design and implementation Software design and implementation is the stage in the software engineering process.
Chapter 7 – Design and Implementation Lecture 1 1Chapter 7 Design and implementation.
February 23, 2009Observer Pattern, OOA&D, Rubal Gupta, CSPP, Winter ‘09 Observer Pattern Defines a “one-to-many” dependency between objects so that when.
Design Review.
Chapter 6 – Architectural Design
EKT 421 SOFTWARE ENGINEERING
Case Study -- Weather system
Chapter 5 – Design and Implementation
Chapter 7 – Object-Oriented Design
Chapter 7 – Design and Implementation
Observer Design Pattern
Observer Design Pattern
Design and Implementation
Chapter 7 – Design and Implementation
Chapter 7 – Design and Implementation
OO Design - Observer Pattern
Observer Pattern 1.
Chapter 7 – Design and Implementation
Design and Implementation
CS310 Software Engineering Dr.doaa Sami Khafaga
Presentation transcript:

Figures – Chapter 7

Figure 7.1 System context for the weather station

Figure 7.2 Weather station use cases

Figure 7.3 Use case description—Report weather System Weather station Use case Report weather Actors Weather information system, Weather station Description The weather station sends a summary of the weather data that has been collected from the instruments in the collection period to the weather information system. The data sent are the maximum, minimum, and average ground and air temperatures; the maximum, minimum, and average air pressures; the maximum, minimum, and average wind speeds; the total rainfall; and the wind direction as sampled at five-minute intervals. Stimulus The weather information system establishes a satellite communication link with the weather station and requests transmission of the data. Response The summarized data is sent to the weather information system. Comments Weather stations are usually asked to report once per hour but this frequency may differ from one station to another and may be modified in the future.

Figure 7.4 High-level architecture of the weather station

Figure 7.5 Architecture of data collection system

Figure 7.6 Weather station objects

Figure 7.7 Sequence diagram describing data collection

Figure 7.8 Weather station state diagram

Figure 7.9 Weather station interfaces

Figure 7.10 The Observer pattern Pattern name Observer Description Separates the display of the state of an object from the object itself and allows alternative displays to be provided. When the object state changes, all displays are automatically notified and updated to reflect the change. Problem description In many situations, you have to provide multiple displays of state information, such as a graphical display and a tabular display. Not all of these may be known when the information is specified. All alternative presentations should support interaction and, when the state is changed, all displays must be updated. This pattern may be used in all situations where more than one display format for state information is required and where it is not necessary for the object that maintains the state information to know about the specific display formats used. Solution description This involves two abstract objects, Subject and Observer, and two concrete objects, ConcreteSubject and ConcreteObject, which inherit the attributes of the related abstract objects. The abstract objects include general operations that are applicable in all situations. The state to be displayed is maintained in ConcreteSubject, which inherits operations from Subject allowing it to add and remove Observers (each observer corresponds to a display) and to issue a notification when the state has changed. The ConcreteObserver maintains a copy of the state of ConcreteSubject and implements the Update() interface of Observer that allows these copies to be kept in step. The ConcreteObserver automatically displays the state and reflects changes whenever the state is updated. The UML model of the pattern is shown in Figure 7.12. Consequences The subject only knows the abstract Observer and does not know details of the concrete class. Therefore there is minimal coupling between these objects. Because of this lack of knowledge, optimizations that enhance display performance are impractical. Changes to the subject may cause a set of linked updates to observers to be generated, some of which may not be necessary.

Figure 7.11 Multiple displays

Figure 7.12 A UML model of the Observer pattern