1

Layers

Data from IBM-Rational and Craig Larman’s text integrated into these slides.

These are great references…

Slides from these sources have been modified for pedagogical reasons.

© Lethbridge/Laganière 2001

2

Objectives of Architectural Design

• In Architectural Design, we define the pieces/parts (generalizing: “components”) of the system and their relationships.

• Relationships implies dependencies, services needed, relationships among components, and more.•in our case, these pieces will be organized into well-

defined layers •Layers will

— provide services, and — exhibit explicit dependencies— Subscribe to accepted principles of ‘layering.’

© Lethbridge/Laganière 2001

3

Objectives of Architectural Design

• Architectural Design - starting point for design.

• Remember, design bridges a major gap: •Problem Space

(requirements, use cases, prototype…•to the Solution Space.

(design, implementations, testing…)

• Equivalently, we are mapping ‘what’ to ‘how.’

•We will talk in terms of design (solution) elements

© Lethbridge/Laganière 2001

4

Architect

Designer

ArchitecturalAnalysis

ArchitectureReviewer

Review theDesign

Review theArchitecture

Use-CaseAnalysis

ArchitecturalDesign

DescribeConcurrency

DescribeDistribution

ClassDesign

Subsystem Design

Use-Case Design

DesignReviewer

Architectural Design in Context – ‘about choices!’

Detailed Unified Process workflow – a tailored version of the Analysis and Design core workflow of the RUP.

In Use Case Analysis: looked at requirements; allocated responsibilities to analysis classes.

Now undertake Architectural Design. (note roles: See where it fits.)and Use-Case Design – see above

Note the distribution of responsibities!!

© Lethbridge/Laganière 2001

Explain the parallelism…

5

More…We have defined and decided upon a

• a layered architecture, and we should • recorded design decisions as to the contents of each layer.

In continuing our Architectural Design we will refine our analysis classes (boundary, control, entity) into design elements (design classes, subsystems, components) Map where appropriate

Architectural layers constitute the implementation environment.

We will allocate design elements to layers; then,

within layers, to packages and subsystems in the architecture.

© Lethbridge/Laganière 2001

6

1. Typical Layering Approach

General functionality

Specific functionality

This is a very broad generalization. in practice, things will be considerably different and application dependent in many cases.

Note: this is also a very general view; may/may not include a GUI layer.

© Lethbridge/Laganière 2001

7

LAYERS – in general, there are several scenarios…Certain packages in a layer may/may not use services of layers directly beneath them.

Layers don’t necessarily shield one layer from other. • a package in application layer may need some domain services – in a

domain layer beneath them. Thus, for those packages, there is a domain services layer beneath them.

• A package in the same upper layer may need technical services. For these packages, dependencies are on layers beneath them but skipping an intervening layer and go directly to middleware component.

•Application layer has components unique to the application.•Business specific (domain layer) may have reusable subsystems •Middleware layer may likely have the DB Controller, transaction dispatcher, Broker (pattern), persistency mechanisms, security mechanisms and other classes and associated relationships.

© Lethbridge/Laganière 2001

8

2. Multi-Tier Layered Architecture - Example

Separate presentation and application logic, and other areas of concern.

Consider: Different names (in some cases). Can see the main idea!

UI Layer (or Presentation Layer)

“Domain” or “Application Logic” Layer

Services Layer

PersistenceSubsystem

LoggingSubsystem

SecuritySubsystem

(Interface may/may not be graphical…)

(May/may not need both…)

© Lethbridge/Laganière 2001

9

In more detail: A Simple Logical Architecture

Using UML, logical partitioning is illustrated with package /subsystem diagrams. The layers ‘might’ look like these….a design choice! Maybe not too…

Here, the User Interface is first.

Some authors call this a Presentation Layer (makes sense if UI is graphical…)

These might be the only layers needed.

© Lethbridge/Laganière 2001

10

Adding An Application Coordination Layer – another twist?

Consider an “application coordination layer” whose objects represent use cases. They may also hold session state.

This is often (not always) a better design.

Added this layer!(look like controlclass names…)

© Lethbridge/Laganière 2001

11

Continuing: Showing Package Dependencies (good slide w/dependencies)

It is useful to show the coupling with UML dependency lines.

Further, it is helpful to cite the purpose of each subsystem / package to show how these design elements cohere.

Document these.

Discuss the dependencies!!

© Lethbridge/Laganière 2001

12

Ordering WorkWhat do we now start?

What do/can we now do in parallel?

•How?

•The REAL

advantages of a

carefully designed

architecture!!

In the meantime…

lower –level design

and implementation

and testing can be occurring

© Lethbridge/Laganière 2001

13

A Little Variation with this Thinking

Next slide is VERY good!

This architectural approach adds layers but ratchets down a bit.

Note the cohesion in each layer (what it does; area of concern)

Note also the dependencies.

© Lethbridge/Laganière 2001

14

3. Here is still another view of layers: Note the suggested layer contents

Presentation(AKA Interface, UI, View)

Application(AKA Workflow, Process,Mediation, App Controller)

Domain(s)(AKA Business,

Business Services, Model)

Technical Services(AKA Technical

Infrastructure,High-level Technical Services)

Foundation(AKA Core Services, Base Services,

Low-level Technical Services/Infrastructure)

width implies range of applicability

GUI windowsReportsSpeech interfaceHTML, XML, XSLT, JSP, Javascript, ...

Handles presentation layer requestsWorkflowSession stateWindow/page transitionsConsolidation/transformation of disparate data for presentation

Handles application layer requestsImplementation of domain rulesDomain services (POS , Inventory) - Services may be used by just one

application, but there is also the possibility of multi-application services

(Relatively) high-level technical servicesand frameworksPersistence, Security

Low-level technical services, utilities,and frameworks Data structures, threads, math,

file, DB, and network I/O

de

pe

nd

en

cy

Business Infrastructure(AKA Low-level Business Services)

Very general low-level business services Used in many business domains CurrencyConverter

more application specific

© Lethbridge/Laganière 2001