object architecture design
DESCRIPTION
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. What Is Architectural Design?. - PowerPoint PPT PresentationTRANSCRIPT
15.1.2003 Software Engineering 2003Jyrki 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.
15.1.2003 Software Engineering 2003Jyrki 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.
15.1.2003 Software Engineering 2003Jyrki 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.
15.1.2003 Software Engineering 2003Jyrki 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
15.1.2003 Software Engineering 2003Jyrki 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.
15.1.2003 Software Engineering 2003Jyrki 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.
15.1.2003 Software Engineering 2003Jyrki 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
15.1.2003 Software Engineering 2003Jyrki 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.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
9
Subject {abstract}
Subject {abstract}
Object {abstract}
Object {abstract}
update() {abstract}update() {abstract}
ConcreteSubjectConcreteSubject
ConcereteObserverConcereteObserver
update()update()
observes
*
registersfor all g in observes { g.update()}
attach(x:Observer)detach(x: Observer)notify()
Class Diagram for Observer Design Pattern
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
10
:ConcreteSubject t1:ConcreteObserver
attach(t1)
update()
t2:ConcereteObserver
attach(t2)
notify()
update()
Changes State
A Sequence Diagram For Observer Design Pattern
15.1.2003 Software Engineering 2003Jyrki 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.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
12
Subject {abstract}
Subject {abstract}
Object {abstract}
Object {abstract}
update() {abstract}update() {abstract}
GameModelGameModel
GameGUIGameGUI
update()update()
observes
*
registersfor all g in observes { g.update()}
attach(x:Observer)detach(x: Observer)notify()
Applying The Observer Design Pattern
Controller?
15.1.2003 Software Engineering 2003Jyrki 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.
15.1.2003 Software Engineering 2003Jyrki 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
15.1.2003 Software Engineering 2003Jyrki 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.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
16
ComponentZ
ComponentY
InterfaceX
Component Diagram
implements
uses
Interface – this may also be represented with stereotype <<interface>> for a class.
component
15.1.2003 Software Engineering 2003Jyrki 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.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
18
Component Technologies
• Microsoft COM & DCOM (distributed COM)• CORBA standard
– several vendors – heavyweight system
• Java Beans
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
19
GameGUI
GameController
GameModel
GameModelInterface
GameControllerInterface
Component Diagram For The Game Application
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
20
User
Choose to take card
Show funds
Card Value
Sequence Diagram for ”Take Card” at Component Level
Pay (1)
Updated funds
Turn Card
Show card value
Add Funds (Value)
Show funds
GameView GameController GameModel
Take card
Show funds
Show card value
Updated fundsShow funds
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
21
: GameClient : GameServer
: GameModel
: GameController
: GUI
<<TCP/IP>>
Deployment Diagram
Processing resource (a device, not a device type)
Component instance Object – ok, this was a componentin an earlier slide, this is just for example