TK2023 Object-Oriented Software Engineering

CHAPTER 8

LOGICAL ARCHITECTURE

INTRODUCTION

We have transitioned from analysis-oriented work to software design.

Before going on to object design, we will first look at logical layered architecture and the related UML notation.

LOGICAL ARCHITECTURE AND LAYERS The logical architecture is the large-scale

organization of the software classes into packages, subsystems, and layers.

A layer is a very coarse-grained grouping of classes, packages, or subsystems that has cohesive responsibility for a major aspect of the system.

EXAMPLE

Domain

UI

Swing

not the Java Swing libraries, but our GUI classes based on Swing

Web

Sales Payments Taxes

Technical Services

Persistence Logging RulesEngine

HIGHER LAYERS

LOWER LAYERS

Layers are organized such that "higher" layers call upon services of "lower" layers, but not normally vice versa.

Typical layers in an OO system include: User Interface (UI Layer) Application Logic and Domain Objects

contains software objects representing domain concepts that fulfill application requirements e.g. calculating a sale total

Technical Services consists of general purpose objects and subsystems that

provide supporting technical services e.g. interfacing with databases.

A logical architecture doesn't have to be layered but it's very common.

PACKAGE DIAGRAMS

UML package diagrams are often used to illustrate the logical architecture of a system.

A layer can be modeled as a UML package. In UML, a package can group anything:

classes, other packages, use cases, etc.

Technical Services

Persistence LoggingSales

Dependency between packages can be shown using a dashed arrowed line.

Domain

UI

Swing Web

Sales Payments Taxes

Technical Services

Persistence Logging RulesEngine

GUIDELINE: DESIGN WITH LAYERS Organize the large-scale logical structure of a

system into discrete layers of distinct, related responsibilities, with a clean, cohesive separation of concerns. "Lower" layers should be low-level and general services whereas the "higher" layers are more application specific.

Collaboration and coupling is from higher to lower layers; lower-to-higher layer coupling should be avoided.

Using layers helps address several problems: Source code changes ripple throughout the

system Application logic is tied to the user interface,

making it difficult to be reused with a different interface.

Potentially general technical services or business logic is tied to application-specific logic, making it difficult to be reused or easily replaced with a different implementation.

There is high coupling across different areas of concern, making it difficult to divide the work along clear boundaries for different developers.

GUIDELINE: COHESIVE RESPONSIBILITIES The responsibilities of the objects in a layer

should be strongly related to each other and should not be mixed with responsibilities of other layers.

For example, UI objects should not do application logic. Application logic classes should not trap UI

events.

DOMAIN OBJECTS AND THE DOMAIN LAYER

How do we design application logic with objects? The recommended approach is to create software

objects with names and information similar to the real-world domain, and assign application logic responsibilities to them. Example: Assign the logic for adding new SaleLineItem objects to Sale.

Such software objects are referred to as domain objects.

The application logic layer is sometimes referred to as the domain layer of the architecture as it contains domain objects to handle application logic work.

DOMAIN LAYER AND DOMAIN MODEL It is important to understand that the domain

layer is part of the software whereas the domain model is part of analysis.

We refer to the domain model for inspiration for the names of classes in the domain layer. Doing this creates a lower representational gap between the real-world domain and our software design.

Payment

amount

Sale

datetime

Pays-for

Payment

amount: Money

getBalance(): Money

Sale

date: DatestartTime: Time

getTotal(): Money. . .

Pays-for

UP Domain ModelStakeholder's view of the noteworthy concepts in the domain.

Domain layer of the architecture in the UP Design ModelThe 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.

1 1

1 1

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.

inspires objects

and names in

GUIDELINE: THE MODEL-VIEW SEPARATION PRINCIPLE What kind of visibility should other packages have to

the UI layer? The Model-View Separation principle:

Do not connect or couple non-UI objects directly to UI objects.

Do not put application logic in the UI object methods. UI objects should only initialize UI elements, receive UI events, and delegate requests for application logic to non-UI objects.

Information and behaviour related to application logic should be encapsulated within the domain classes.

Motivation for Model-View Separation includes: To allow separate development of the model

(domain layer) and the user interface layer. To minimize the impact of requirements changes

in the interface upon the domain layer. To allow multiple simultaneous views on the same

model object. To allow execution of the model layer

independent of the user interface layer, such as in a batch-mode system.

SSDs, SYSTEM OPERATIONS AND LAYERS An SSD shows the events generated by the

actor/s on the system. It shows the system operations but it does not show the specific UI objects involved.

System operations involve application logic so they should not be operations of the UI layer. Thus, system operation requests should be forwarded by the UI layer to the domain layer for handling.

SystemSystem

Domain

UI

Swing

ProcessSaleFrame

...

... Register

makeNewSale()enterItem()...

: Cashier

makeNewSale()enterItem()endSale()

makeNewSale()enterItem()endSale()

enterItem(id, quantity)

:System: Cashier

endSale()

description, total

makeNewSale()

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

makeNewSale()enterItem(id, quantity)endSale()