1. Software Architecture

2. What is a SW architecture? • A SW architecture consists of a set of layers • Each layer is related to a central area of functionality in an application. Such an area of functionality could be e.g presentation or persistence. • A layer can be divided into a set of sub-layers, if the corre-sponding area of functionality can be naturally divided into sub-functions • A layer (or sub-layer) consists of a set of packages, each relating to a specific purpose in the layer • Each package contains a set of classes

3. Strukturelle principper Architecture • Levels of abstraction for a SW architecture • Architecture (level 0) • Layer (level 1) • Sub-layer (level 2) • Package (level 3) • Class (level 4) Layer Sub-layer Package Class

4. Standard SW architecture GUI Layer Control Layer Model Layer

5. Standard SW architecture • Purpose and responsibility for each layer: • GUI Layer. Contains functionality related to the graphical presentation of data, and the user/application interaction • Control Layer. Contains functionality related to the application business logic, independent of presentation and persistence • Model Layer. Contains functionality related to management of the domain data, both in-memory and in persistent form

6. GUI Layer GUI Layer CreateCustomer GUI CreateOrder GUI …GUI GUIUtility

7. GUI Layer • Properties for the GUI Layer • This layer is not divided further into sub-layers • Typically, one package will be created for each Use Case in the applica-tion, containing the GUI classes needed for that particular Use Case • Such a package is usually named after the Use Case, suffixed by ”GUI”, e.g. CreateCustomerGUI • Specific classes in such a package will be situation-dependent • GUI classes are usually not allowed to create new objects of a domain model class, but are allowed to receive (read-only) collections of domain data objects as e.g. a return value • Further decoupling can be achieved by defining view-specific versions of domain data classes

8. Control Layer Control Layer Controller Layer Business Logic Layer

9. Control Layer • Properties for Controller Layer • This layer is divided into two sub-layers; Controller Layer and Business Logic Layer • Controller Layer: This layer typically contains a class for each User Case in the system; each such class coordinates the actions needed to complete the corresponding Use Case. The classes in this layer will form the entire interface of the Control Layer towards the GUI layer, i.e. the GUI layer only knows Controller Classes • Business Logic Layer: This layer contains various classes needed to implement the actual business logic of the application. Executing business logic may alter the state of the data domain model. The actual classes – and organisation into packages – are situation-dependent.

10. Model Layer Model Layer Persistence Layer Data Model Layer Model Utility Layer

11. Model Layer • Properties for Model Layer • This layer is divided into three sub-layers; Data Model Layer, Persistence Layer and Model Utility Layer • Data Model Layer: This layer contains the classes which model the domain data model. This includes collection classes to hold sets of domain data objects • Persistence Layer: Classes needed for loading/saving domain data to a persistent media (file, database,…) are placed in this layer • Model Utility Layer: Sometimes it will be beneficial to extract certain general features into more general utility classes, which do not naturally fit into the above sub-layers (like a class handling general details about connection). They can be placed in the Utility Layer

12. Realising an architecture • The exact realisation of an application architecture will (of course) depend on the complexity of the application • The architecture presented here is a framework, which is capable of handling fairly complex applications • In less complex scenarios (e.g. a 1. or 2.semester project), some elements of the architecture will not be present, while others may ”collapse” into a single or very few classes • Always remember to apply your common sense…

13. Realising an architecture Architecture (1.semester) GUI Layer Control Layer Model Layer CreateCustomerGUI CustomerCatalog CreateCustomer Controller Customer CreateOrderGUI OrderCatalog CreateOrder Controller Order

14. Realising an architecture • Properties of a 1.semester architecture: • No sub-layers • One class per Use Case in GUI layer • One class per Use Case in Control layer • No explicit business logic classes • No persistence classes

15. Realising an architecture • What will a 2.semester architecture look like…? • Probably – but not certainly – still one class per Use Case in GUI layer • Explicit classes for business logic • Complex interactions between business logic and Model layer • Addition of Persistence layer • Use of interfaces where appropriate (e.g. define an interface for persistence, and implement DB-specific implementation of interface)