Chapter 13: Logical Architecture and UML Package Diagrams

1
Chapter 13 Logical Architecture and UML Package
Diagrams

• 13.1 Introduction
• The software architecture is a fairly large
  topic we will only introduce one possible
  solution (the most common) here.
• As we have finished the requirement analysis part
  of the first iteration and are ready to move on
  to design we can look at a larger scale.
• The design of a typical OO system is based on
  several architectural layers, such as a UI layer,
  an application logic (or "domain") layer, and so
  forth.
• Figure 13.1 illustrates the use of packages in
  UML to organise the architecture of the software
  prior to moving on to design.

2
Figure 13.1 A look at design
3

• 13.2 Example
• Figure 13.2, below, shows a logical architecture
  using a UML package diagram.

4

• 13.3 What is the Logical Architecture and Layers?
• The logical architecture is the large-scale
  organization of the software classes into
  packages, subsystems, and layers.
• It is called the logical architecture because
  there is no decision about how these elements are
  deployed across different operating system
  processes or across physical computers in a
  network (these latter decisions are part of the
  deployment architecture).
• A layer is a very coarse-grained grouping of
  classes, packages, or subsystems that has
  cohesive responsibility for a major aspect of the
  system.
• Layers are organized such that "higher" layers
  (such as the UI layer) call upon services of
  "lower" layers, but not normally vice versa.
  Typically layers in an OO system include
• User Interface.
• Application Logic and Domain Objects software
  objects representing domain concepts (for
  example, a software class Sale) that fulfill
  application requirements, such as calculating a
  sale total.

5

• Technical Services general purpose objects and
  subsystems that provide supporting technical
  services, such as interfacing with a database or
  error logging. These services are usually
  application-independent and reusable across
  several systems.
• In a strict layered architecture, a layer only
  calls upon the services of the layer directly
  below it.
• This can be relaxed so that a higher layer calls
  upon several lower layers. For example, the UI
  layer may call upon its directly subordinate
  application logic layer, and also upon elements
  of a lower technical service layer, for logging
  and so forth.
• A logical architecture does not have to be
  organized in layers. But it is very common.

6

• 13.4 UML Package Diagrams
• A UML package diagram provides a way to group
  elements. A UML package can group anything
  classes, other packages, use cases, and so on.
  Nesting packages is very common.
• It is common to want to show dependency (a
  coupling) between packages so that developers can
  see the large-scale coupling in the system.
• A UML package represents a namespace so that, for
  example, a Date class may be defined in two
  packages. If you need to provide fully-qualified
  names, the UML notation is, for example,
  javautilDate in the case that there was an
  outer package named "java" with a nested package
  named "util" with a Date class.
• Nesting can be represented in various manners
  with the UML see Figure 13.3.

7

• Figure 13.3 different ways to represent UML
  packages nesting and dependencies.

8

• 13.5 Designing with Layers
• To achieve a layered architecture
• Organize the large-scale logical structure of a
  system into discrete layers of distinct, related
  responsibilities, with a clean, cohesive
  separation of concerns such that the "lower"
  layers are low-level and general services, and
  the higher layers are more application specific.
• Collaboration and coupling is from higher to
  lower layers lower-to-higher layer coupling must
  be avoided.
• Using layers helps address several problems
• Source code changes are rippling throughout the
  system many parts of the systems are highly
  coupled.
• Application logic is intertwined with the user
  interface, so it cannot be reused with a
  different interface.
• Potentially general technical services or
  business logic is intertwined with more
  application-specific logic, so it cannot be
  reused.
• There is high coupling across different areas of
  concern. It is thus difficult to divide the work
  for different developers.

9
Figure 13.4 Typical Layers
10

• Figure 13.4 represents a typical layered
  architecture.
• The number of layers varies across applications
  and application domains.
• Benefits of a layered architecture
• In general, there is a separation of concerns, a
  separation of high from low-level services, and
  of application-specific from general services.
  This reduces coupling and dependencies, improves
  cohesion, increases reuse potential, and
  increases clarity.
• Related complexity is encapsulated and
  decomposable.
• Some layers can be replaced with new
  implementations. This is generally not possible
  for lower-level Technical Service or Foundation
  layers (e.g., java.util), but may be possible for
  UI, Application, and Domain layers.
• Lower layers contain reusable functions.
• Some layers (primarily the Domain and Technical
  Services) can be distributed.
• Development by teams is aided because of the
  logical segmentation.

11

• Guidelines
• 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, objects in the UI
  layer should focus on UI work, such as creating
  windows and widgets, capturing mouse and keyboard
  events, and so forth. Objects in the application
  logic or "domain" layer should focus on
  application logic, such as calculating a sales
  total or taxes, or moving a piece on a game
  board.
• UI objects should not do application logic. For
  example, a Java Swing JFrame (window) object
  should not contain logic to calculate taxes or
  move a game piece. And on the other hand,
  application logic classes should not trap UI
  mouse or keyboard events. That would violate a
  clear separation of concerns and maintaining high
  cohesion basic architectural principles.

12

• 13.6 The Model-View Separation Principle
• The Model-View Separation principle states that
  model (domain) objects should not have direct
  knowledge of view (UI) objects. So, for example,
  a Register or Sale object should not directly
  send a message to a GUI window object
  ProcessSaleFrame, asking it to display something,
  change color, close, and so forth.
• A legitimate relaxation (especially for
  asynchronous events) of this principle is the
  Observer pattern, where the domain objects send
  messages to UI objects viewed only in terms of an
  interface such as PropertyListener (a common Java
  interface for this situation). Then, the domain
  object does not know that the UI object is a UI
  object it does not know its concrete window
  class. It only knows the object as something that
  implements the PropertyListener interface.

13

• 13.7 SSDs, System Operations and Layers
• During analysis we created System Sequence
  Diagram(s) to formalise the use cases they
  represent messages that will be received by the
  system
• In a well-designed layered architecture that
  supports high cohesion and a separation of
  concerns, the UI layer objects will then forward
  the request from the UI layer onto the domain
  layer for handling.
• See Figure 13.5, below, for illustration

14

• 13.8 Conclusions
• As soon as the project is larger than very small,
  all the artefacts (including the code of course)
  need to logically organised in a well-defined
  architecture
• The most common architecture is the layered
  architecture
• Others do exist for games no architecture has
  the upper hand but the idea of a logical
  architecture, regrouping common concerns, into
  well defined sub-systems with clear interfaces,
  has been accepted
• Another potential architecture for games is a
  data-driven architecture