Object Oriented Analysis and Design Logical Architecture

Matthew Dailey
Computer Science and Information Management Asian Institute of Technology

Matthew Dailey (CSIM-AIT)

Architecture

1 / 24

Readings

Readings for these lecture notes: - Larman (2005), Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3rd edition, Chapter 13. Some material c Larman (2005).

Matthew Dailey (CSIM-AIT)

Architecture

2 / 24

Outline

Introduction

Layering Pattern

Wrap-Up

Matthew Dailey (CSIM-AIT)

Architecture

3 / 24

Introduction
Start with the big picture

Design is another major discipline of the UP elaboration phase. To get started on design, we need the big picture or high-level organization for the software. Here we consider the logical architecture that describes the high-level organization of the system. Later we drill down to design the application logic (aka domain logic) layer.

Matthew Dailey (CSIM-AIT)

Architecture

4 / 24

Introduction
Getting started

The logical architecture organizes the major subsystems without committing to a particular deployment. The Software Architecture document is created during elaboration and will be baselined by the end of elaboration. Logical architecture design begins with a consideration of an constraints and non-functional requirements in the supplementary specication.

Matthew Dailey (CSIM-AIT)

Architecture

5 / 24

Introduction
Logical architecture relationships
Sample UP Artifact Relationships Domain Model

Business Modeling

Requirements

Use-Case Model

Vision

Supplementary Specification

Glossary

The logical architecture is influenced by the constraints and non-functional requirements captured in the Supp. Spec. Design Model package diagrams of the logical architecture (a static view) UI Domain Tech Services

: Register Design interaction diagrams (a dynamic view) enterItem (itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID )

Register class diagrams (a static view) ... makeNewSale() enterItem(...) ... 1 1 ...

ProductCatalog

getProductSpec(...) ...

Larman (2005), Fig. 13.1

Matthew Dailey (CSIM-AIT) Architecture 6 / 24

Outline

Introduction

Layering Pattern

Wrap-Up

Matthew Dailey (CSIM-AIT)

Architecture

7 / 24

Layering Pattern
Characteristics

Most applications (especially enterprise applications) use the layering pattern: Subsystems are organized into coarse-grained groups Responsibilities within each layer are strongly related to each other Each layer may depends on the layers (relaxed layering) or layer (strict layering) below it. There are no upward dependencies.

Matthew Dailey (CSIM-AIT)

Architecture

8 / 24

Layering Pattern
Example
UI not the Java Swing libraries, but our GUI classes based on Swing

Swing

Web

Domain

Sales

Payments

Taxes

Technical Services

Persistence

Logging

RulesEngine

Larman (2005), Fig. 13.2

Matthew Dailey (CSIM-AIT) Architecture 9 / 24

Layering Pattern
Typical layers

Typical layers: UI (thick client, Web, remote) Application logic and domain objects Technical services (persistence, logging, etc.)

Matthew Dailey (CSIM-AIT)

Architecture

10 / 24

Layering Pattern
UML packages for layers

In UML, layers are represented by packages. Unlike Java packages or C++ namespaces, UML packages can contain anything.
UI Domain

Swing

Web

Sales

UI UI::Swing UI::Web

Swing Domain::Sales

Web Domain Sales

Larman (2005), Fig. 13.3

Matthew Dailey (CSIM-AIT)

Architecture

11 / 24

Layering Pattern
Why layers?

Why layers? Coupling is reduced Application logic is well separated from user interface. General purpose business logic can be separated from application specic logic. Development activities can proceed with clear responsibilities

Matthew Dailey (CSIM-AIT)

Architecture

12 / 24

Layering Pattern
Typical informations system layers

Typical layers in an information system:

GUI windows reports speech interface HTML, XML, XSLT, JSP, Javascript, ... UI (AKA Presentation, View)
more app specific

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

Domain (AKA Business, Application Logic, Model)

very general low-level business services used in many business domains CurrencyConverter

Business Infrastructure (AKA Low-level Business Services)

(relatively) high-level technical services and frameworks Persistence, Security

Technical Services (AKA Technical Infrastructure, High-level Technical Services)

low-level technical services, utilities, and frameworks data structures, threads, math, file, DB, and network I/O

Foundation (AKA Core Services, Base Services, Low-level Technical Services/Infrastructure)

width implies range of applicability

Larman (2005), Fig. 13.4

Matthew Dailey (CSIM-AIT) Architecture 13 / 24

dependency

handles presentation layer requests workflow session state window/page transitions consolidation/transformation of disparate data for presentation

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

Layering Pattern
Layers and package naming conventions

Packages should be named consistently with nesting by layer to allow reverse engineering of the layer structure, e.g.:
// --- UI Layer com.mycompany.nextgen.ui.swing com.mycompany.nextgen.ui.web // --- DOMAIN layer com.mycompany.nextgen.domain.sales com.mycompany.nextgen.domain.payments // --- TECHNICAL SERVICES Layer // home-grown services com.mycompany.services.persistence // third-party services org.apache.log4j org.apache.soap.rpc // --- FOUNDATION Layer // foundation packages that our team creates com.mycompany.util
Matthew Dailey (CSIM-AIT) Architecture 14 / 24

Layering Pattern
The domain layer

Our focus for this course is the application logic layer aka the domain layer.

The key to object-oriented design

We begin design using the domain objects in the analysis model. This leads to a lower representational gap between the real world and the software design.

Matthew Dailey (CSIM-AIT)

Architecture

15 / 24

Layering Pattern
Domain model and domain layer

The domain model and the domain layer are related. Example:
UP Domain Model Stakeholder's view of the noteworthy concepts in the domain. A Payment in the Domain Model is a concept, but a Payment in the Design Model is a software class. They are not the same thing, but the former inspired the naming and definition of the latter. This reduces the representational gap. This is one of the big ideas in object technology. Payment amount: Money getBalance(): Money 1 Pays-for 1 date: Date startTime: Time getTotal(): Money ... Payment amount inspires objects and names in Sale Sale 1 Pays-for 1 date time

Domain layer of the architecture in the UP Design Model The object-oriented developer has taken inspiration from the real world domain in creating software classes. Therefore, the representational gap between how stakeholders conceive the domain, and its representation in software, has been lowered.

Larman (2005), Fig. 13.5

Matthew Dailey (CSIM-AIT) Architecture 16 / 24

Layering Pattern
Layers and partitions

Within each layer we have horizontal partitions.

Domain

POS Vertical Layers Technical Services Persistence

Inventory

Tax

Security Horizontal Partitions

Logging

Larman (2005), Fig. 13.6

Avoid the word tier in a logical architecture as it usually refers to deployment.

Matthew Dailey (CSIM-AIT)

Architecture

17 / 24

Layering Pattern
Use the right view

Avoid allowing deployment views to creep into your logical architecture views:
Worse mixes logical and deployment views Better a logical view Domain(s) Domain(s) POS Inventory a logical representation of the need for data or services related to these subdomains, abstracting implementation decisions such as a database.

Technical Services

Technical Services Naming and Directory Services Web AppFramework

Foundation

Persistence

MySQL Inventory

component Novell LDAP

Foundation

UML notation: A UML component, or replaceable, modular part of the physical system UML notation: A physical database in the UML.

Larman (2005), Fig. 13.7

Matthew Dailey (CSIM-AIT) Architecture 18 / 24

Layering Pattern
MVC and layers

The Model-View Controller pattern separates model objects in the domain layer from view objects in the UI layer. View objects use the Observer pattern to register for notication of model object events (e.g. state changes). The Observer pattern allows the model to inform the view of changes and other events without coupling. (See next slide for the pattern...)

Matthew Dailey (CSIM-AIT)

Architecture

19 / 24

Layering Pattern
Observer pattern

Larman (2005), Fig. 26.22

Matthew Dailey (CSIM-AIT)

Architecture

20 / 24

Layering Pattern
UI layer Domain layer interface

UI layer Domain layer interface

The messages sent from the UI to the domain layer should be exactly the system-level events discovered during SSD analysis.

Matthew Dailey (CSIM-AIT)

Architecture

21 / 24

Layering Pattern
UI-Domain layer interface design from SSD analysis

Example interface derived from SSD analysis:

UI :System : Cashier makeNewSale() : Cashier enterItem(id, quantity) description, total Domain endSale() ... makeNewSale() enterItem() endSale() Swing ... ProcessSale Frame makeNewSale() enterItem() endSale()

Register makeNewSale() enterItem() ...

the system operations handled by the system in an SSD represent the operation calls on the Application or Domain layer from the UI layer

Larman (2005), Fig. 13.8

Matthew Dailey (CSIM-AIT) Architecture 22 / 24

Outline

Introduction

Layering Pattern

Wrap-Up

Matthew Dailey (CSIM-AIT)

Architecture

23 / 24

Wrap-Up
Package diagrams

BOUML makes it easy to create package diagrams. Create the package hierarchy in the explorer view, then drag the packages you want to display to the diagram panel. For the pineapple farm information system project, we might begin with a standard layering and plan to rene later.

Matthew Dailey (CSIM-AIT)

Architecture

24 / 24