Layers

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.

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 • exhibitexplicitdependencies • subscribe to accepted principles of ‘layering.’

3. Objectives of Architectural Design • Architectural Design - starting point for design. • Remember, design bridges a major gap: • ProblemSpace (requirements, use cases, analysis modeling, prototyping…to the • SolutionSpace. • Equivalently, we are mapping ‘what’ to ‘how.’ • We will talk in terms of design (solution) elements

4. Architectural Design in Context – ‘about choices!’ Architectural Analysis Review the Architecture Describe Architectural Describe Architecture Reviewer Architect Concurrency Design Distribution Subsystem Design Use-Case Analysis Use-Case Design Designer 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 analysisclasses. Now undertake Architectural Design.

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) • Architecturallayers constitute the implementation environment. • We will allocate these design elements to layers; • within layers, to packages and subsystems in the architecture.

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.

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. • Businessspecific (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.

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

9. In more detail: A Simple Logical Architecture • Using UML, logicalpartitioning 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.

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…) 

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!!

12. Ordering Work • What do we now start? • What do/can we now do in parallel? • How? Discuss!

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.

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 technicalservices Technical Services and frameworks (AKA Technical Infrastructure, Persistence , Security High-level Technical Services) Foundation Low-level technicalservices, utilities, (AKA Core Services, Base Services, and frameworks width implies range of applicability Data structures, threads, math, file, DB, and network I/O Low-level Technical Services/Infrastructure)