1 Design Pattern Description Design Pattern Observer Name - - PDF document

1

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 1

OBJECT ARCHITECTURE DESIGN

• These slides continue with our example

application, based on the simplified OMT-based technique.

• I am not trying to cover all or not even most

aspects here.

• We will have other examples to show how things

can be done differently.

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 2

What Is Architectural Design?

Choices Made In Architectural Design:

• Components
• High-Level Design Patterns
• Architectural Styles
• A Possible Framework Architecture
• Processes and Hardware
• Processes and Communication
• Other Architecture-Related Decisions ☺
• -> Some of these issues depend on each other

strongly.

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 3

Why Architectural Design?

• Managing complexity

– It is easier to manage complexity, if we divide the application into reasonable parts.

• Maintainability

– Usually a reasonable architecture makes it much easier to maintain the software. – This may actually be the biggest reason for architectural design.

• Efficiency

– A good architecture enables us to isolate the potential causes for inefficiency and makes it possible to scale up performance when load increases.

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 4

Input Information For Architecture Design

• Analysis model of the application showing what the

system is about and what it should do.

• Hardware environment
• Software environment
• possible database management system
• communication technologies
• programming language – if known
• target operating system(s) – if known

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 5

Architectural Design For Example Game Application

• Clearly, it seems reasonable to separate the game

logic from the user interface.

• If done suitably, this will also enable multiple

client applications with a view to the same game.

• This kind of an approach is actually quite usual.
• In fact, so usual, that there is a well-known

architectural solution for this kind of setting, called Model-View-Controller architecture (MVC architecture).

• We will study a variant of MVC from a separate set
• f slides by Ari Jaaksi, Nokia.

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 6

Design Patterns

• Our design could follow the principles of MVC (or

MVC++) directly.

• Another possibility is to copy an existing design

idea and modify it to our needs.

• The idea of copying designs like this is the basic

idea behind design patterns.

• It has been difficult to reuse code. The idea of

design patterns is to reuse ideas.

• In a way, applying the MVC model is reusing the
• idea. However, there have been efforts to give a

fixed format for presenting design patterns.

2

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 7

Design Pattern Description

• Name
• Problem
• Solution

– Static: E.g. Class Diagram – Dynamic: E.g. Sequence Diagram

• Strategy

– How to implement the pattern

• Consequences

– Results and trade-offs

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 8

Design Pattern ”Observer”

• Problem: We want to keep a number of objects

(observers) aware of the state of an object (subject)

• This is done by making the observers subscribe to

the subject.

• Whenever the subjects state changes, it will

publish information about that to all subscribed

• bservers.

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 9

Subject {abstract} Object {abstract} update() {abstract} ConcreteSubject ConcereteObserver update()

• bserves

* registers for all g in observes { g.update() } attach(x:Observer) detach(x: Observer) notify()

Class Diagram for Observer Design Pattern

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 10 :ConcreteSubject t1:ConcreteObserver attach(t1) update() t2:ConcereteObserver attach(t2) notify() update() Changes State

A Sequence Diagram For Observer Design Pattern

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 11

Some observations

• A subject and the respective observers need

minimal information on each other.

• In fact, they need to implement the required
• perations (attach, detach, notify, update), but

that’s about that.

• This way, we get a high level of independence in

their implementations.

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 12

Subject {abstract} Object {abstract} update() {abstract} GameModel GameGUI update()

• bserves

* registers for all g in observes { g.update() } attach(x:Observer) detach(x: Observer) notify()

Applying The Observer Design Pattern

Controller?

3

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 13

Applying The Observer Pattern

• Apparently, we can use the Observer pattern for

the user interface to observe the state of the game.

• Q: How is this different from using the MVC

model? A: This model does not include the control part, ie. it is more appropriate for situations, where

• bserving is enough. This way, MVC seems more

appropriate for our game example.

• -> Back to the drawing board. The MVC looked
• better. However, we will look at yet another

possibility: components.

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 14

Components - What?

• Component technologies can be seen as packaging

technologies

• Independent
• Can be used as a building block to build larger

systems – dynamic, ”plug & play” linking

• Have a well-defined interface, which hides the

implementation completely

• Can be treated as a product of its own
• Can be installed separately
• Can be implemented with any language, as long as

it implements the necessary interfaces

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 15

Components - Why?

• Object-oriented source-level re-use of code

requires same source code language.

• Object-oriented source-level re-use may require

understanding of the implementation.

• Building the system from source-level pieces

requires that these pieces compile happily with each other.

• We want to avoid the above problems and build

binary components with well-defined interfaces.

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 16

ComponentZ ComponentY InterfaceX

Component Diagram

implements uses Interface – this may also be represented with stereotype <<interface>> for a class. component

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 17

Component - Interfaces

• An interfaces defines a set of services, which

semantically belong together.

• An interface is a contract between the user and

the implementor.

• A componenent may implement many interfaces

and an interface may be implemented by many components.

• Once an interface is released, it does not change.
• If changes are necessary, a new interface is

released.

• As a matter of fact, you should know all this.

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 18

Component Technologies

• Microsoft COM & DCOM (distributed COM)
• CORBA standard

– several vendors – heavyweight system

• Java Beans

4

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 19

GameGUI Game Controller GameModel GameModelInterface GameControllerInterface

Component Diagram For The Game Application

4.10.2004 Software Engineering 2004 Jyrki Nummenmaa 20 User Choose to take card Show funds Card Value

Sequence Diagram for ”Take Card” at Component Level

: GameClient : GameServer : GameModel : GameController : GUI

<<TCP/IP>>

Deployment Diagram

Processing resource (a device, not a device type) Component instance Object – ok, this was a component in an earlier slide, this is just for example