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, 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, analysis modeling, prototyping…to the
Solution Space.
Equivalently, we are mapping ‘what’ to ‘how.’
We will talk in terms of design (solution) elements
© Lethbridge/Laganière 2001

4. Architectural Design in Context – ‘about choices!’
Architectural Design is where the “filtering and factoring” is done before setting the designers loose on Use-Case Design.
Keep in mind that the focus of all architectural activities is on the “big picture”.
Architectural Design is all about decisions.
In Architectural Design, the Logical View chapter of the “Design Handbook” is developed.
Architectural Design in this course encompasses the following RUP Analysis and Design workflow activities: - Identify Design Mechanisms - Identify Design Elements - Incorporate Existing Design Elements. They are covered in a single module here as they are conceptually a single activity (all dealing with the Logical View of the architecture), and they are not covered in the same level of detail as they are in RUP.
Architectural
Analysis
Architectural
Describe
Review the
Describe
Architecture
Architecture
Architect
Design
Concurrency
Distribution
Reviewer
Subsystem Design
Use-Case
Analysis
Use-Case
Designer
Design
Review the
Design
Design
Reviewer
Class
Design
Our 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.
© Lethbridge/Laganière 2001

5. More… We have defined and decided upon a
a layered architecture, and we should
recorded 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)
Architectural layers constitute the implementation environment.
We will allocate these design elements to layers;
within layers, to packages and subsystems in the architecture.
© Lethbridge/Laganière 2001

6. 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

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!
Discuss!
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
Logging
Subsystem
Security
Subsystem
© Lethbridge/Laganière 2001

9. In more detail: A Simple Logical Architecture
Using UML, logical partitioning illustrated with package /subsystem diagrams. The layers ‘might’ look like these….a design choice!
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. This is often (not always) a better design.
Added this layer!
(look like control
class 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 Work What do we now start? What do/can we now do in parallel?
How?
Discuss!
© 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
GUI windows
Reports
Presentation
Speech interface
(AKA Interface, UI, View)
HTML, XML, XSLT, JSP, Javascript, ...
more
application
specific
Handles presentation layer requests
Workflow
Application
Session state
(AKA Workflow, Process,
Window/page transitions
Mediation, App Controller)
Consolidation/transformation of disparate
data for presentation
dependency
Handles application layer requests
Domain(s)
Implementation of domain rules
(AKA Business,
Domain services (
POS ,
Inventory )
Business Services, Model)
- Services may be used by just one
application, but there is also the possibility
of multi-application services
Very general low-level business services
Business Infrastructure
Used in many business domains
(AKA Low-level Business Services)
(Relatively) high-level technical services
Technical Services
and frameworks
(AKA Technical Infrastructure,
Persistence ,
Security
High-level Technical Services)
Foundation
Low-level technical services, utilities,
(AKA Core Services, Base Services,
and frameworks
Data structures, threads, math,
width implies range of applicability
file, DB, and network I/O
Low-level Technical Services/Infrastructure)
© Lethbridge/Laganière 2001