OBJECT ARCHITECTURE

What Is Architectural Design?

DESIGN

• These slides continue with our example Choices Made In Architectural Design:
application, based on the simplified OMT-based • Components
technique. • High-Level Design Patterns
• I am not trying to cover all or not even most • Architectural Styles
aspects here.
• A Possible Framework Architecture
• We will have other examples to show how things
can be done differently. • 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 1 4.10.2004 Software Engineering 2004 2

Jyrki Nummenmaa Jyrki Nummenmaa

Input Information For

Why Architectural Design?
Architecture Design

• Managing complexity • Analysis model of the application showing what the

– It is easier to manage complexity, if we divide the system is about and what it should do.
application into reasonable parts. • Hardware environment
• Maintainability • Software environment
– Usually a reasonable architecture makes it much easier to - possible database management system
maintain the software.
- communication technologies
– This may actually be the biggest reason for architectural
design. - programming language – if known
- target operating system(s) – if known
• 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 3 4.10.2004 Software Engineering 2004 4

Jyrki Nummenmaa Jyrki Nummenmaa

Architectural Design For

Design Patterns
Example Game Application

• Clearly, it seems reasonable to separate the game • Our design could follow the principles of MVC (or
logic from the user interface. MVC++) directly.
• If done suitably, this will also enable multiple • Another possibility is to copy an existing design
client applications with a view to the same game. idea and modify it to our needs.
• This kind of an approach is actually quite usual. • The idea of copying designs like this is the basic
• In fact, so usual, that there is a well-known idea behind design patterns.
architectural solution for this kind of setting, called • It has been difficult to reuse code. The idea of
Model-View-Controller architecture (MVC design patterns is to reuse ideas.
architecture). • In a way, applying the MVC model is reusing the
• We will study a variant of MVC from a separate set idea. However, there have been efforts to give a
of slides by Ari Jaaksi, Nokia. fixed format for presenting design patterns.

4.10.2004 Software Engineering 2004 5 4.10.2004 Software Engineering 2004 6

Jyrki Nummenmaa Jyrki Nummenmaa

1
 Design Pattern Description Design Pattern ”Observer”

• Name • Problem: We want to keep a number of objects

• Problem (observers) aware of the state of an object
• Solution (subject)
– Static: E.g. Class Diagram • This is done by making the observers subscribe to
– Dynamic: E.g. Sequence Diagram the subject.
• Strategy • Whenever the subjects state changes, it will
– How to implement the pattern publish information about that to all subscribed
• Consequences observers.
– Results and trade-offs

4.10.2004 Software Engineering 2004 7 4.10.2004 Software Engineering 2004 8

Jyrki Nummenmaa Jyrki Nummenmaa

Class Diagram for Observer A Sequence Diagram For

Design Pattern Observer Design Pattern

:ConcreteSubject t1:ConcreteObserver t2:ConcereteObserver

observes Object
Subject {abstract}
attach(t1)
{abstract} * attach(t2)

update() {abstract}
attach(x:Observer) Changes State
detach(x: Observer)
notify()
notify()
for all g in observes {
registers update()
g.update()
update()
} ConcereteObserver
ConcreteSubject
update()

4.10.2004 Software Engineering 2004 9 4.10.2004 Software Engineering 2004 10

Jyrki Nummenmaa Jyrki Nummenmaa

Applying The Observer Design

Some observations
Pattern

• A subject and the respective observers need

minimal information on each other.
observes Object
• In fact, they need to implement the required Subject
* {abstract}
{abstract}
operations (attach, detach, notify, update), but
update() {abstract}
that’s about that. attach(x:Observer)
detach(x: Observer)
• This way, we get a high level of independence in notify()
their implementations. for all g in observes {
registers
g.update()
} GameGUI
GameModel
update()

Controller?

4.10.2004 Software Engineering 2004 11 4.10.2004 Software Engineering 2004 12

Jyrki Nummenmaa Jyrki Nummenmaa

2
 Applying The Observer Pattern Components - What?

• Apparently, we can use the Observer pattern for • Component technologies can be seen as packaging
the user interface to observe the state of the technologies
game. • Independent
• Q: How is this different from using the MVC • Can be used as a building block to build larger
model? systems – dynamic, ”plug & play” linking
A: This model does not include the control part, ie. • Have a well-defined interface, which hides the
it is more appropriate for situations, where implementation completely
observing is enough. This way, MVC seems more
appropriate for our game example. • Can be treated as a product of its own
• -> Back to the drawing board. The MVC looked • Can be installed separately
better. However, we will look at yet another • Can be implemented with any language, as long as
possibility: components. it implements the necessary interfaces
4.10.2004 Software Engineering 2004 13 4.10.2004 Software Engineering 2004 14
Jyrki Nummenmaa Jyrki Nummenmaa

Components - Why? Component Diagram

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

requires same source code language. uses
• Object-oriented source-level re-use may require
understanding of the implementation.
• Building the system from source-level pieces Interface – this may also be
ComponentZ represented with stereotype
requires that these pieces compile happily with
<<interface>> for a class.
each other.
InterfaceX
• We want to avoid the above problems and build
binary components with well-defined interfaces. ComponentY

component

4.10.2004 Software Engineering 2004 15 4.10.2004 Software Engineering 2004 16

Jyrki Nummenmaa Jyrki Nummenmaa

Component - Interfaces Component Technologies

• An interfaces defines a set of services, which • Microsoft COM & DCOM (distributed COM)
semantically belong together. • CORBA standard
• An interface is a contract between the user and – several vendors
the implementor. – heavyweight system
• A componenent may implement many interfaces • Java Beans
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 17 4.10.2004 Software Engineering 2004 18

Jyrki Nummenmaa Jyrki Nummenmaa

3
 Component Diagram For The Sequence Diagram for ”Take
Game Application Card” at Component Level

GameView GameController GameModel

GameGUI User
Choose to take card
Take card Pay (1)

Show funds Show funds Updated funds

Game
Controller Turn Card
GameControllerInterface
Show card value Card Value
Show card value
Add Funds (Value)
GameModel
Show funds Updated funds
Show funds
GameModelInterface

4.10.2004 Software Engineering 2004 19 4.10.2004 Software Engineering 2004 20

Jyrki Nummenmaa Jyrki Nummenmaa

Deployment Diagram

Processing resource (a device, not a

device type)

: GameClient : GameServer

: GUI : GameModel

<<TCP/IP>>

: GameController

Component instance Object – ok, this was a component

in an earlier slide, this is just for example
4.10.2004 Software Engineering 2004 21
Jyrki Nummenmaa