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
1
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 welldefined layers
• Layers will
— provide services, and
— exhibit explicit dependencies
— Subscribe to accepted principles of ‘layering.’
© Lethbridge/Laganière 2001
2
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
3
Architectural Design in Context – ‘about choices!’
Architectural
Analysis
Describe
Architectural
Concurrency
Design
Architect
Describe
Distribution
Review the Architecture
Architecture Reviewer
Explain the parallelism…
Subsystem Design
Use-Case
Analysis
Designer
Use-Case
Design
Review the
Design
Design
Reviewer
Class
Design
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
4
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
5
1. Typical Layering Approach
Specific
functionality
General
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
6
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
7
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)
(Interface may/may not be graphical…)
“Domain” or “Application Logic” Layer
(May/may not need both…)
Services Layer
Persistence
Subsystem
© Lethbridge/Laganière 2001
Logging
Subsystem
Security
Subsystem
8
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
9
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 control
class names…)
© Lethbridge/Laganière 2001
10
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.
© Lethbridge/Laganière 2001
Discuss the
dependencies!!
11
Ordering Work
What 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
12
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
13
3. Here is still another view of layers: Note the suggested layer contents
Handles presentation layer requests
Workflow
Session state
Window/page transitions
Consolidation/transformation of disparate
data for presentation
Presentation
(AKA Interface, UI, View)
more
application
specific
Application
(AKA Workflow, Process,
Mediation, App Controller)
Handles application layer requests
Implementation of domain rules
Domain services (POS , Inventory)
- Services may be used by just one
application, but there is also the possibility
of multi-application services
Very general low-level business services
Used in many business domains
CurrencyConverter
(Relatively) high-level technical services
and frameworks
Persistence, Security
Low-level technical services, utilities,
and frameworks
Data structures, threads, math,
file, DB, and network I/O
Domain(s)
(AKA Business,
Business Services, Model)
dependency
GUI windows
Reports
Speech interface
HTML, XML, XSLT, JSP, Javascript, ...
Business Infrastructure
(AKA Low-level Business Services)
Technical Services
(AKA Technical Infrastructure,
High-level Technical Services)
Foundation
(AKA Core Services, Base Services,
width implies range of applicability
Low-level Technical Services/Infrastructure)
© Lethbridge/Laganière 2001
14