1. TK2023 Object-Oriented Software Engineering CHAPTER 8 LOGICAL ARCHITECTURE

2. 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.

3. 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.

4. EXAMPLE Domain UI Swing not the Java Swing libraries,but our GUI classes based on Swing Web SalesPaymentsTaxes Technical Services PersistenceLoggingRulesEngine HIGHER LAYERS LOWER LAYERS

5. 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.

6. 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 PersistenceLogging Sales

7. Dependency between packages can be shown using a dashed arrowed line. Domain UI SwingWeb SalesPaymentsTaxes Technical Services PersistenceLoggingRulesEngine

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

13. 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.

15. 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.

16. 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.

17. 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.

18. System makeNewSale() enterItem(id, quantity) endSale()