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.
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.
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.
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
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 of slides by Ari Jaaksi, Nokia.
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.
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
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 observers.
Software Engineering 2004
Jyrki Nummenmaa

9. Class Diagram for Observer Design Pattern
observes
Object
{abstract}
update() {abstract}
Subject
{abstract} *
attach(x:Observer)
detach(x: Observer)
notify()
for all g in observes {
g.update() }
registers
ConcereteObserver
update()
ConcreteSubject
Software Engineering 2004
Jyrki Nummenmaa

10. A Sequence Diagram For Observer Design Pattern
:ConcreteSubject
t1:ConcreteObserver
t2:ConcereteObserver
attach(t1)
attach(t2)
Changes State
notify()
update()
update()
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 operations (attach, detach, notify, update), but that’s about that.
This way, we get a high level of independence in their implementations.
Software Engineering 2004
Jyrki Nummenmaa

12. Applying The Observer Design Pattern
observes
Object
{abstract}
update() {abstract}
Subject
{abstract} *
attach(x:Observer)
detach(x: Observer)
notify()
for all g in observes {
g.update() }
registers
GameGUI
update()
GameModel
Controller?
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 observing 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.
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
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.
Software Engineering 2004
Jyrki Nummenmaa

16. Component Diagram implements uses
Interface – this may also be represented with stereotype <<interface>> for a class.
ComponentZ
InterfaceX
ComponentY
component
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.
Software Engineering 2004
Jyrki Nummenmaa

18. Component Technologies
Microsoft COM & DCOM (distributed COM)
CORBA standard
several vendors
heavyweight system
Java Beans
Software Engineering 2004
Jyrki Nummenmaa

19. Component Diagram For The Game Application
GameGUI
Game Controller
GameControllerInterface
GameModel
GameModelInterface
Software Engineering 2004
Jyrki Nummenmaa

20. Sequence Diagram for ”Take Card” at Component Level
GameView
GameController
GameModel
User
Choose to take card
Take card
Pay (1)
Show funds
Show funds
Updated funds
Turn Card
Show card value
Card Value
Show card value
Add Funds (Value)
Show funds
Updated funds
Show funds
Software Engineering 2004
Jyrki Nummenmaa

21. 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
Software Engineering 2004
Jyrki Nummenmaa