Logical Architecture

[jimin-kiim]

• Logical Architecture
• Strict v.s. Relaxed Layered Architecture
• UML Package Diagrams
• Common Layers in an Information Systems Logical Architecture
• Benefits of Using Layers
• Domain Layers and Domain Objects, Domain Model
• Tiers, Layer and Partitions
• The Model-View Separation Principle

[jimin-kiim]

Logical Architecture

• UP artifacts influence the logical architecture (LA)
• UML package diagram:
  • illustrates the LA as part of the Design Model
  • can be summarized as a view in a Software Architecture Document
• logical architecture:
  • the large-scale organization of the software classes into packages, subsystems, and layers.
  • layer: a coarse-grained grouping of classes, packages, or subsystems that has cohesive responsibility
  • higher layers call upon services of lower layers
  • UI layer, Application Logic and Domain Objects layer, Technical Services layer
  • Domain layer: software objects representing domain concepts that fulfill application requirements.
  • Technical Services layer: 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.
  • 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 is avoided.

[jimin-kiim]

Strict v.s. Relaxed Layered Architecture

• strict architecture:
  • a layer only calls upon the services of the layer directly below.
  • common in network protocol stacks, but not in information systems.
• relaxed architecture:
  • a higher layer calls upon several lower layers.
  • ex. 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.
  • Common in information systems.

[jimin-kiim]

Software Architecture

• the fundamental structures of a software system
• the discipline of creating such structures and systems
• Each structure comprises software elements, relations among them, and properties of both elements and relations.

[jimin-kiim]

UML Package Diagrams

• often used to illustrate the logical architecture
• layers, subsystems, packages ...
• UML package diagram provides a way to group elements.
• A UML package can group anything: classes, other packages, use cases, etc.
• Nesting packages is very common.
• A UML package is a more general concept than simple a Java package or .NET namespace, though a UML package can represent those.
• Package Dependency: The UML dependency line is used - a dashed arrowed line with the arrow pointing towards the depended - on package.

[jimin-kiim]

Common Layers in an Information Systems Logical Architecture

• UI (Presentation, View)
  • GUI windows
  • reports
  • speech interface
  • HTML, XML, XSLT, JSP, Javascript...
• Application (Workflow, Process, Mediation, App Controller)
  • handles presentation layer requests
  • workflow, session state
  • window/page transition
  • consolidating transformation of disparate data for presentation
• Domain (Business, Application Logic, Model)
  • handles application layer requests
  • implementation of domain rules
  • domain services
• Business Infrastructure (Low-level Business Services)
  • very general low level business services like CurrencyConverter
• Technical Services(Technical infrastructure, High-Level Technical Services)
  • high-level technical services and frameworks
  • ex. Persistence, Security
• Foundation(Core Services, Base Services, Low-level Technical Services/Infrastructure)
  • low-level technical services, utilities, and frameworks
  • data structures, threads, math, file, DB, network IO

[jimin-kiim]

Benefits of Using Layers

• separation of concerns
  • a separation of high from low- level services, and of application-specific from general services.
  • reduces coupling and dependencies
  • improves cohesion
  • increases reuse potential
  • increases clarity
• Related complexity is encapsulated and decomposable
• Some layers can be replaced with new implementations
  • 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.

[jimin-kiim]

Domain Layers and Domain Objects, Domain Model

• 1. create software objects with names and information similar to the real-world domain
• 2. and then assign application logic responsibilities to them.
• e.g. real-world POS: sales and payments. In software, Sale and Payment class, and give them application logic responsibilities.
• this kind of software objects : "domain object"
  • represents a thing in the problem domain space, and has related application or business logic
  • e.g. Sale object is able to calculate its total.
• Domain Layer: contains domain objects to handle application logic
• UP Domain Model: stakeholder's view of the noteworthy concepts in the domain. OOA
• Domain layer of the architecture: OOD. UP Design Model.

[jimin-kiim]

Tiers, Layer and Partitions

• Tier
  • widely used to mean a physical processing node (or cluster of nodes), such as the "client tier" (the client computer).
• Layers
  • represent the vertical slices of the system.
• Partitions
  • represent a horizontal division of relatively parallel subsystems of a layer.
  • e.g. the Technical Services layer may be divided into partitions such as Security and Reporting

[jimin-kiim]

The Model-View Separation Principle

1. Do not connect or couple non-UI objects directly to UI objects.
2. Do not put application logic (such as a tax calculation) in the UI object methods.
   • UI objects should only initialize UI elements, receive UI events (such as a mouse click on a button), and delegate requests for application logic on to non-UI objects (such as domain objects).
   • View: UI layer
   • Model: Domain Layer
   • to support cohesive model definitions that focus on the domain processes, rather than on user interfaces.
   • to allow separate development of the model and user interface layers.
   • to minimize the impact of requirements changes in the interface upon the domain layer.
   • to allow new views to be easily connected to an existing domain layer, without affecting the domain layer.
   • to allow multiple simultaneous views on the same model object, such as both a tabular and business chart view of sales information.
   • to allow execution of the model layer independent of the user interface layer, such as in a message-processing or batch-mode system.
   • to allow easy porting of the model layer to another user interface framework.
   • The UI layer objects will forward or delegate the requests from the UI layer (system operations) onto the domain layer for handling.
   • The messages sent from the UI layer to the domain layer will be the messages illustrated on the SSDs