Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa SOFTWARE ARCHITECTURES...
40
Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa SOFTWARE ARCHITECTURES An architecture contains the information on how the software devides into building blocks.
-
Upload
alexzander-pasley -
Category
Documents
-
view
221 -
download
1
Transcript of Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa SOFTWARE ARCHITECTURES...
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
SOFTWARE ARCHITECTURES
An architecture contains the information on how the software devides into building blocks.
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
“GUI-Hanger” syndrome
FuncX(…){ do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that;}
FuncX(…){ do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that;}
FuncX(…){ do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that;}
FuncX(…){ do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that;}
FuncX(…){ do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that;}
FuncX(…){ do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that;}
FuncX(…){ do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that;}
FuncX(…){ do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that;}
FuncX(…){ do this; do that; do this; do that; do this; do that;do that; do this; do that; do this; do that; do this; do that;}
FuncX(…){ do this; do that; do this; do that; do this; do that;do that; do this; do that; do this; do that; do this; do that;}
FuncX(…){ do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that;}
FuncX(…){ do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that; do this; do that;}
FuncX(…){ do this; do that; do this; do that; do this; do that;do that; do this; do that; do this; do that;}
FuncX(…){ do this; do that; do this; do that; do this; do that;do that; do this; do that; do this; do that;}
FuncX(…){ do this; do that; do this; do that; do this; do that;do this; do that; do this; do that; do this; do that;}
FuncX(…){ do this; do that; do this; do that; do this; do that;do this; do that; do this; do that; do this; do that;}
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
Why software architectures?
• 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 – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
Architectural Design Choices
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.
• Let’s have a look at some historical development.
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
Monolithic Architecture / 1
• Monolithic systems are not divided into independent parts. They typically run on a single processing unit (computer).
• There was a time when computers typically did not talk that much with each other.
• This made monolithic systems more or less the only choice.• Lack of complicated communication speeds up processing,
but it is hard to improve performance in any other way than increasing processing power for that one computer.
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
Monolithic Architecture / 2
• Typically and historically, the monolithic system talks with fairly dumb clients (like terminals).
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
Client/Server Architecture /1
• When terminals were replaced by microcomputers, they started to have processing power.
• To use this power just to run a terminal program was a waste of processing capabilities.
• Consequently, the microcomputers were used to run a client program, which talked with the mainframe server.
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
Client/Server Architecture /2
• Fat clients contained more functionalities and data.• Thin clients contained more or less terminal-type
functionalities.• Client/Server (C/S) computing was the first step towards
multi-tier (multi-layer) architectures on processing unit level.• It allowed a better division of work.• However, fat clients also needed maintenance and
installations to keep up with current versions.
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
Three-tier architecture / 1
• The server side was still monolithic in a basic C/S architecture, which created a performance bottleneck.
• As the applications usually had a database, multiplying the database is hard in many cases, which makes it hard to multiply the servers.
• However, by having a separate database server it was possible to have multiple application servers.
DATABASE SERVER
APPLICATIONSERVERS
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
Three-tier architecture / 2
• The database server only runs the database, as having several of them is difficult.
• If there are database server performance problems, get a more powerful server!
• You may use several servers for backup to always have a backup server on-line ready for action.
• The three-tier architecture is fairly common.• To make client installation easier, it is possible to have a
client server (or UI server), from which the client is software is loaded for execution (like an applet to be executed in the browser).
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
Using multiple database servers
• If data is replicated to several databases, updating them correctly is a problem – in particular if the replicas must be consistent.
• If data is distributed, then it should be easily found somehow. Like assume a library keeps books with title starting with ”A” on one data server, ”B” on a second server, and so on.
• Queries based on other selection criteria or data from several servers are problematic.
A B C
Z
. . .
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
Some application architectures
Min=0Max=400Value=50
Abstraction Control Presentation
PAC (J.Coutaz)
Controller View
Model
MVC Model (Reenskaug)
Application Userinterface
Simple Separation (N.N)
Frame
View
Document
Document
View
MDI (MFC)
Slide by Ari Jaaksi.
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
MVC
• Model– Often uses a database.
– Could include ”basic rules” about the domain.
• View– User interface
– Typical implementation is graphical (GUI, graphical user interface)
• Controller– Understands user interface requests.
– Uses the model to fulfill them.
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
MVC - web development examples
• Model– Typically uses an SQL database
– Objects to manage the database according to the rules of the model
• View– HTML forms
– Applets
– JSP (Java Server Pages, an XML-like description from which HTML is generated)
• Controller (”application programs using M and V”)– Java servlets, perl programs, etc...
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
MVC++ triad
Controller-knows how this particular application works-controls the view and the model
Model-"real world"-works when the controller asks it to work
View-user interface-knows how to communicatewith the end user
MVC++ is an MVC variant developed at Nokia. Slide by Ari Jaaksi.
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
MVC++ application in action
Actions ofthe End User
=Manipulation
Observations ofthe End User=Feedback
End User View Controller Model
Decisions
Interpretedactions
Results
Actions
Action requests
Action requests
UserInterface
From a slide by Ari Jaaksi.
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
Working together
Balance:7800:-
ModelControllerView
controller::BalanceWanted(){ b = model->GetBalance(); view->ShowBalanceFM(b);};
7800.00
Balance
Get
view::GetPressedMM(){ controller->BalanceWanted();};
view::ShowBalanceFM(int b){ TextField.WriteInt(b);};
int model::GetBalance(){
return(balance);};
Slide by Ari Jaaksi.
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
Peer-To-Peer Computing
• The above processing architectures have assumed that we have separate servers and clients and the configuration of the system is controlled in a centralised fashion.
• In Peer-To-Peer computing, each computer (node) is equal, and the nodes may ask each other for processing services.
• The nodes may contact each other flexibly and forward processing requests, which removes a fixed configuration for processing.
• Grid computing (”a software infrastructure enabling flexible, secure and coordinated resource sharing”)
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
Processing Unit vs. Software Architecture
• If an architecture divides processing into different types of processing units (clients and various servers), then of course this division implies also a division of the software functionalities.
• However, there is also architectural structural decisions, which do not need to be based on the processing unit architecture.
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
Dividing the tiers
• As an example, we may divide the application server functionalities into domain tier and control (application) tier. Typically it is the domain tier, which talks to the database.
• It makes a big difference, how the layers talk with each other.
• It is typically seen as a good thing, if the layers call each other in top-down fashion and the calls do not pass-by layers (e.g. application layer does not call database layer).- Makes maintenance easier.- Performance may suffer.
Client tier
Application tier
Domain tier
Database tier
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
Issues with multi-layer architectures
• Number of layers• Error/exception management (what to pass on, what to
process)• Callback from lower layers.• Interfaces between layers / encapsulation of layers.• Maintenance knock-on effects (do changes of one layer imply
changes in other layers?)
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
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 – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
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 – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa ComponentZ
ComponentY
InterfaceX
Component Diagramimplements
uses
Interface – this may also be represented with stereotype <<interface>> for a class.
component
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
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 – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
Component Technologies
• Microsoft COM & DCOM (distributed COM)• CORBA standard
– several vendors – heavyweight system
• Java Beans
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
GameGUI
GameController
GameModel
GameModelInterface
GameControllerInterface
Component Diagram For The Game Application
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
User
Choose to take card
Show funds
Card Value
Seq. Diagram for ”Take Card”, 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
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
: GameClient : GameServer
: GameModel
: GameController
: GUI
<<TCP/IP>>
Deployment DiagramProcessing resource (a device, not a device type)
Component instance
Object – ok, this was a componentin an earlier slide, this is just for example
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
FRAMEWORKS
• An application framework contains core parts for an application.
• The framework serves as a starting-point for application development.
• We add new things to the core. • In case of OO software development, a framework may
contain a set of core classes.• Naturally, the new system inherits the basic architecture from
the framework.
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
Black-box vs. white-box frameworks
• In black-box frameworks, we just build things on top of the framework without a need to see the implementation details in the framework. - Easy to use
• In white-box frameworks, we typically implement new subclasses based on the classes in the framework.- More flexible
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
Frameworks vs. components
• When you use components, you typically write the “main programs” yourself and call the services from the components.
• When you use frameworks, the framework includes the “main programs” and you implement the application-specific special services, which the framework calls.- The so-called Hollywood principle: “Don’t call us, we call you”.
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
Frameworks – conclusions
• It is harder to write a good application framework than it is to write a good application.
• However, if it succeeds, a lot of effort can be saved in producing future applications based on the framework.
• In particular, it is possible to get the products out earlier (a time-to-market improvement).
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
Design Patterns
• The idea 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.
• Design patterns can be used at architectural design as well as in more detailed design.
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
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 – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
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 – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
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
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
:ConcreteSubjectt1:ConcreteObserver
attach(t1)
update()
t2:ConcereteObserver
attach(t2)
notify()
update()
Changes State
A Sequence Diagram For Observer Design Pattern
Software Engineering – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
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 – http://www.cs.uta.fi/se
Un
iversity of T
amp
ere, CS
D
epartm
ent
Jyrki Nu
mm
enm
aa
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?
