4-Layered-architectures

8/7/2019 4-Layered-architectures

http://slidepdf.com/reader/full/4-layered-architectures 1/51

OOSD 2004

Mira Balaban

Layered architecture

Layered Architecture

The main

architectural

pattern for largesystems is

Layers!

Common layers:



OOSD 2004

Mira Balaban



Layers in

the POS

problem:



OOSD 2004

Mira Balaban



Motivation – Logical layers separate the major

concerns concerns of the application:

1. Modularity, low-coupling – easier maintenance.

2. Business-logic is separated from presentation – reuse.

3. General technical services, e.g., database, areseparated from the business-logic – reused, replaced.

4. Low coupling, separation of concerns – evolvingfunctionality, system scaling-up, adapt to new

technologies.



OOSD 2004

Mira Balaban



• Layers are implemented as packages.

• Layer packages have a downwarddirected dependency!

• The dependency is not strictly restricted

to“n

n-1”

layers.





OOSD 2004

Mira Balaban



Layer

dependencies:



OOSD 2004

Mira Balaban


The model-view separation principle

Model (domain) elements should not have direct

knowledge of view (presentation) objects.

Motivation:

1. Support cohesive model definitions.

2. Focus on domain process and not on user interfaces.

3. Allow separate development of the model and user interface.

4. Minimize impact of interface change on the domain layer.

5. Allow connection of new views to existing domain layer.

6. Allow multiple views to a single domain layer.7. Allow execution of model layer – independently of the view.

8. Allow easy porting of a domain layer to another user interface.



OOSD 2004

Mira Balaban



Model (domain) elements should not have direct

knowledge of view (presentation) objects.

Presentation objects might have visibility of domain

objects, but not vice-versa.



OOSD 2004

Mira Balaban



Presentation objects can send system event messages to

domain objects to which they have permanent visibility.



OOSD 2004

Mira Balaban



The Model View Controller (MVC) pattern --

Split user interface interaction into three distinct roles:

View Controller

Model

The controller manipulates model based on user’s input, andcauses view to update.

The presentation is a combination of View and Controller.



OOSD 2004

Mira Balaban



The Model View Controller (MVC) pattern emphasizes

2 separations:

1. Model-view separation – most important!

• Separation of concerns.

• Multiple views.

• Easier development and testing of domain logic.

2. View-controller separation – less important.

• Multiple controllers (behaviors) for a single view.

• Controller might play the Driver role.



OOSD 2004

Mira Balaban



Controller as Driver:

1. Initialize View Domain visibility.

– Creates the Initial Domain Object (IDO) (applicationstart-up operation). Returns the Domain layer facade(representative) object d .

– Creates the Initial-Presentation-Object (IPO) with

argument d : create-IPO(d ):IPO has permanent visibility to the Domain layerfacade object!

2. Run -- IPO.run().

The IPO object might create other IPO objects.



OOSD 2004

Mira Balaban



Controller as Driver:

In Java, the Driver (Controller) class is the class with

the main method:public class Driver{

public static void main( String[] args ) {

Store store = new Store();Register register = store.getRegister();

ProcessSaleJFrame frame = new ProcessSaleJFrame(register);

frame.run()}

}

Controller IDO

Controller facade

IPO IDO



OOSD 2004

Mira Balaban



The IPO object

might get

temporaryvisibility to

more domain

objects:



OOSD 2004

Mira Balaban


Layers in the POS application

IPO

Sale

Register

ProductSpecification

Item



OOSD 2004

Mira Balaban


Presentation-Domain interaction:



OOSD 2004

Mira Balaban


Model-view separation and “upward”

communication

There is a need for presentation objects to receive

triggers from domain objects about state changes that

should be displayed: – Partial and total sale calculation in POS.

– Network management.

– Simulation applications.

BUT: The MVC patterns suggests only triggers to

domain objects.



OOSD 2004Mira Balaban


Model-view separation and “upward”

communication

Updating the user interface when the sale total changes:

When the Sale total changes the display should be refreshed.

Sale total: $5

OK

SaleTotal

…

setTotal(newTotal)







Observer (publish-subscribe)

Problem: Different kinds of subscribers (listeners, observers)objects are interested in the state change of a publisher object.The subscribers have their own ways to react to the publisher

events.The publisher is interested in low coupling with thesubscribers.

Solution: Define a “subscriber” or “listener” interface.

Subscribers implement this interface.

The publisher dynamically register subscribers that are

interested in its event.The publisher notifies its subscribers when an event occurs.











• Sale: The publisher.

• The interface: PropertyListener , with operation

onPropertyEvent (source,name,value).

• SaleFrame1 implements

onPropertyEvent :

• SaleFrame1: construction

has Sale as an argument.

Subscribes to the sale’slisteners:






• Sale: Does not know about SaleFrame1 objects.

But it knows about its subscribers: Its propertyListenerscollection.

• Sale knows to: – Register a new subscriber:

– Publish an event:

– Trigger the event publishing,

following a state change:

















The Application Layer

Includes Use-Case Controller (Handler) classes – describe use-case scenarios.

The controller

choices:






Use-case

controllers:






The behavior of use-case controller objects is captured

by use-case statechart diagrams:






A more detailed statechart diagram for the Process Sale

use-case:






A more detailed statechart diagram with nested OR-states for the Process Sale use-case:





Inter-Layer and inter-Package

interaction and OrganizationLayers and packages are organized and inter-related by

consulting patterns–

advice that suggest solutions forspecific problems.

1. Architectural patterns – What are the big parts.

– Layers ( ). – Package organization.

2. Micro-architectural design patterns – connections

between layers and packages. – Facade, Adapter, Factory, Strategy.

– Model-View-Controller, Observer-listener ( ).







Simple Packages vs. Subsystems

Simple packages with interfaces, subsystems (singletons) – All arepackages:





Simple Packages vs. Subsystems

Subsystems usually have a facade public representative:





Package Organization Guidelines

1. Functional cohesive grouping.

2. Encourage strong internal coupling and weaker external

coupling.

Relational Cohesion (RC) =

High RC values suggest more cohesion.

3. Place related interfaces together.4. Cluster unstable classes: Reduce dependency on unstable

packages.

Suggestion: Split packages into stable and unstable sub-

packages.

5. Make most dependened-on packages most stable.

Types

nsassociatio

#

#






6. Factor out independent types:

The factored classes can be used independently of the Persistence

subsystem.






7. Reduce dependency on concrete packages.

Solution: Use domain object factories with interfaces for

the creation of all domain objects.Direct coupling to a concrete package due to creation:






Reduce coupling to concrete packages by using a factory object:

P k O i ti G id li






8. Break package dependency cycles. – Factor out cycles into new smaller packages.

– Break a cycle with an interface:





Micro-architectural design patterns

Add levels of

indirection

using interfaces.1. Architectural patterns:

– Layers ( ).

– Package organization ( ).

2. Micro-architectural design patterns:

– Facade, Adapter, Factory, Strategy. – Model-View-Controller, Observer-listener ( ).





Facade design pattern

Problem: A set of classes/interfaces requires a unifiedinterface.

Direct coupling to elements of a subsystem isundesirable.

Solution: Define a single point of contact to the subsystem – a facade object.

A facade is a “front-end” (interface) object. The

facade object is responsible for collaborating withinternal components of the subsystem.

Facades are often Singletons.






Example: POSRuleEngine -- a subsystem with varied

implementations.

Responsibility: Evaluate rules against operations.

The Sale class consults POSRuleEngine for determining the

Legitimacy of operations.

Solution: Add a POSRuleEngineFacade – a singleton.

Clients (like Sale) access only the facade object.






Characterization of facade objects:

• Performs a small number of high level operations.

• Mediator to internal subsystem components – that thework.

Session facades: When there is a large number of systemoperations, introduce an Application Layer with use-case

Controller classes that function as Session Facades.

i






Layer facades:

F d d i






Session

facades:

Ad t d i tt





Adapter design pattern

Adds a level of indirection.

Ad t d i tt





Adapter design pattern

Adapters in the

POS problem:

F t d i tt





Factory design pattern

Hides the creation logic from client objects.

Factory objects are singletons.

Factory design pattern -- adapter services::





Factory design pattern -- adapter services::

Read class name.

Create instance.

A design using Adapter Factory





A design using Adapter, Factory

and Singleton:

Documents

4-Layered-architectures