March 2003 91.3913 R McFadyen 1

Architecture

Architecture involves the set of significant decisions about the organization of a software system,

decisions concerning:

•its structural elements and their interfaces

•its behaviour as specified in the collaborations

•its composition into progressively larger subsystems

March 2003 91.3913 R McFadyen 2

Layers Pattern

The Layers Pattern organizes the large-scale logical/conceptual structure of a system into discrete layers with distinct, but related responsibilities.

Each layer exhibits high cohesion.

Lower layers are low-level providing general services; higher levels are more application specific.

Collaboration and coupling is from higher to lower layers

Layers defines an N-tier model

Page 450-1

March 2003 91.3913 R McFadyen 3

Layers Pattern

Benefits/goals:

•strong cohesion within layers

•clean/clear definition of interface between layers

•promotes re-usability, replaceability

March 2003 91.3913 R McFadyen 4

Typical Layers in an Information System - Fig 30.1, P. 451

Layers is a pattern where the structure of a system is organized into discrete layers where each layer is highly cohesive, and where higher layers are more application specific, lower layers are more low-level and service oriented.

March 2003 91.3913 R McFadyen 5

Figure 30.2 Layers in NextGen

•They only have three layers in this architecture

•Each layer is shown as a UML Package

•No separate Application Layer is shown - Register manages the UI

•not all Classes are shown - the big picture is illustrated

March 2003 91.3913 R McFadyen 6

Figure 30.3 Architecture drawing showing noteworthy coupling

•Dependency lines depict coupling

•Figure 30.4 reinforces the idea that you show the level of detail appropriate for the audience

March 2003 91.3913 R McFadyen 7

Figure 30.5 An architecturally significant interaction diagram

•Illustrates inter-package and inter-layer connections

•shows a subsystem as an object

March 2003 91.3913 R McFadyen 8

•The Domain layer is only exposing one object (Register) to the UI - the above represents an application of Controller or Façade

•As the system grows to handle many Use Cases, an Application Layer is likely

Use of Façade in POS - Fig 30.7, p 459

March 2003 91.3913 R McFadyen 9

Figure 30.8 The system evolves ... Application Layer

•Collaboration via Façade is usually from a higher level to a lower level - downward collaboration

March 2003 91.3913 R McFadyen 10

Figure 30.11 Upward communication in case of Observer pattern

•When the application layer needs to communicate with the presentation layer it is usually via the Observer Pattern

•the lower layer objects send messages to the higher layer objects, but the coupling is not to direct classes, but rather to any class implementing an interface such as PropertyListener

March 2003 91.3913 R McFadyen 11

Classic View of 3-Tier Architecture - Fig 30.14, P 470-1

3-tier architectures appeared in the 90s

its prominence was partly due to its promotion by the Gartner Group

March 2003 91.3913 R McFadyen 12

Different Deployments of 3-Tier - Fig 30.15, p 471

Thick Client Thin Client

There are many ways of slicing the 3-tier architecture across one or more hardware components

March 2003 91.3913 R McFadyen 13

Model-View Separation Principle - P 471-3

Concept originated with SmallTalk development (MVC)

The general concern is: what kind of visibility should other packages have to the Presentation Layer?

Model is synonymous with Domain Layer

View is synonymous with Presentation Layer

The Model-View Separation principle states that model objects should not have direct knowledge of View objects

•Window classes are relatively thin; they are responsible for input/output, catching GUI events, but do not maintain data or provide application functionality

•e.g. Register or Sale objects should not send messages directly to a GUI window object (Note Observer does not involve

direct coupling)

March 2003 91.3913 R McFadyen 14

Model-View Separation Principle - P 471-3

How do windows obtain information to display?

Two approaches:

•Polling/Pull-from-above

•Push-from-below

•needed when polling is too inefficient

•two solutions:

•Observer

•Presentation Façade object

One is deciding how two layers

are going to interact - this is a big

decision, an architectural decision

March 2003 91.3913 R McFadyen 15

Figure 30.16 Presentation Facade