1. © Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software1 Layers Data from IBM-Rational and Craig Larman…

2. © Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software2 Typical Layering Approach General functionality Specific functionality The layering principles originally described for packages also apply to subsystems But this is a very broad generalization. in practice, things will be considerably different and application dependent in many cases. Note: this is a general view; may/may not include a GUI layer; may not have one; may include UI in with the application…..

3. © Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software3 LAYERS In reality, there may be several layers…and certain packages may use services of layers directly beneath them; some may not. Going ‘down’ one layer does not necessarily mean that this layer shields one layer from another. Some packages in layers may need some domain services – beneath them. Thus, for those packages, there is a domain services layer beneath them. Other packages in the same upper layer may need technical services layer beneath them. Thus, for these packages, dependencies are on layers beneath them but skipping an intervening layer – e.g. may NOT include the domain layer (above); rather go directly to a middleware component. Application specific has components unique to the application. Business specific (domain layer) may have reusable subsystems… Middleware layer may likely have the DBController, Transaction dispatcher, Broker (pattern), persistency mechanisms; security mechanisms, ….

4. © Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software4 On Layers Many (not all) layered approaches have a Presentation Layer on top of the Application Layer IF that is appropriate to the type of application!!!! As usual: this is DESIGN – which means these are design choices. These choices represent decisions as to how BEST to accommodate the requirements for the specific type of application, be it an information systems application or a scientific application, process-control application, manufacturing application…these applications and requirements may legislate for a different kind of layered approach. But, let’s consider these…

5. © Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software5 System Partitioning (layering) Note: different author’s terminology. While his terminology should be clear in its context, if confusing, PLEASE ASK. The logical view of the architecture emphasizes large-scale elements (LSEs): Layers, subsystems, modules, frameworks. Before considering detailed object design, which is often referred to as subsystem design, it is recommended to start with a draft design partitioning the system into LSEs. 1. The elements 2. Their interfaces 3. The inter-element collaborations Note: this author uses LSEs for layers, subsystems, … Important to get used to different terminology….

6. © Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software6 Large-Scale Element Collaboration It is Good Thing to achieve early clarification of the interfaces of LSEs, and their collaborations. Of course, mutable in the spirit of iterative development. This effort helps to partition parallel design and implementation by workers. —“Stubs” can be defined for incomplete LSEs. Define the operations and parameters in detail.* Be mindful of coupling and cohesion. Avoid coupling into the internals of an LSE, or across several LSEs. * No algorithms, data structures here, please. Merely ‘cite’ the operations, parameters in general, returned types…

7. © Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software7 Large-Scale Element Collaboration  It is a common experience to “reasonably” design the static partitioning into LSEs without “too much” trouble or error, during early design.  However, the early design of the LSE interfaces and collaborations (dynamics) is usually quite speculative, and unstable. These will change. They will become more detailed and correct during the detailed object design of individual LSEs; that is, our look at the details of each subsystem we identify.

8. © Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software8 Advice: Multi-Tier Layered Architectures Separate presentation and application logic, and other areas of concern. ANOTHER ARCHITECTURE… Different names (in some cases). Can see the main idea! Discuss! UI Layer (or Presentation Layer) “Domain” or “Application Logic” Layer Services Layer Persistence Subsystem Logging Subsystem Security Subsystem (May/may not be graphical…) (May/may not need both…)

9. © Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software9 A Simple Logical Architecture In the UML, the logical partitioning is illustrated with package diagrams. The layers ‘might’ look like these….a design choice! Here, the User Interface is first. Some authors call this a Presentation Layer (makes sense…) These might be the only layers needed.

10. © Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software10 Advice: An Application Coordination Layer – another twist? Consider an “application coordination layer” whose objects represent use cases. They may also hold session state. This is often (not always) a better design. These look like Control classes… 

11. © Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software11 Package Dependencies* (a very good slide w/dependencies) It is useful to show the coupling with UML dependency lines. Further, it is helpful to cite the purpose of each subsystem / package to show how these design elements cohere. Discuss the dependencies!!

12. © Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software12 Ordering Work What can we start with? What can we do in parallel? How? Discuss!

13. © Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software13 Let’s look at a little ‘variation’ in this thinking … but not too much. Let’s also go a little lower in our design and talk a little bit more on thin and fat clients. Next slide is VERY good!

14. © Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software14 Here is still another view of layers: Note the suggested contents of each layer

15. © Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software15 This slide shows three layers on different boxes…But normally we will have additional layers such as Business layers, Technical Services, etc. whose packages will be located within one or more of these nodes.

16. © Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software16 Another similar view of layers (including some of their contents) on nodes…

17. © Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software17 ► Remember, these are Design Choices: They will vary from design to design depending on corporation’s / developer’s experience and how the organization might normally ‘go’ with these… A final picture of two other layers. Note (here) that Domain seems to have the packages for a general application in the ‘domain’ of the specific application. (We have seen application layers, domain layers, business services layers….) Business Services layer or Domain layers usually contain packages across a more general Business domain – then followed by a ‘lower’ Technical Services’ Layer, that might contain Persistency, Security, etc.) PersistenceSecurity Web AppFramework Technical Services POSInventory Tax Domain Vertical Layers Horizontal Partitions