1 / 11

Figure 30.2 Layers in NextGen

Figure 30.2 Layers in NextGen. They only have three layers in this architecture Each layer is shown as a UML Package No separate Application Layer is shown - Register manages the UI not all Classes are shown - the big picture is illustrated.

brandi
Download Presentation

Figure 30.2 Layers in NextGen

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Figure 30.2 Layers in NextGen • They only have three layers in this architecture • Each layer is shown as a UML Package • No separate Application Layer is shown - Register manages the UI • not all Classes are shown - the big picture is illustrated 91.3913 R McFadyen

  2. Figure 30.3 Architecture drawing showing noteworthy coupling • Dependency lines depict coupling • Figure 30.4 reinforces the idea that you show the level of detail appropriate for the audience 91.3913 R McFadyen

  3. Figure 30.5 An architecturally significant interaction diagram • Illustrates inter-package and inter-layer connections • shows a subsystem as an object 91.3913 R McFadyen

  4. Use of Façade in POS - Fig 30.7, p 459 • The Domain layer is only exposing one object (Register) to the UI - the above represents an application of Controller or Façade • As the system grows to handle many Use Cases, an Application Layer is likely 91.3913 R McFadyen

  5. Figure 30.8 The system evolves ... Application Layer • Collaboration via Façade is usually from a higher level to a lower level - downward collaboration 91.3913 R McFadyen

  6. Figure 30.11 Upward communication in case of Observer pattern • When the application layer needs to communicate with the presentation layer it is usually via the Observer Pattern • the lower layer objects send messages to the higher layer objects, but the coupling is not to direct classes, but rather to any class implementing an interface such as PropertyListener 91.3913 R McFadyen

  7. Classic View of 3-Tier Architecture - Fig 30.14, P 470-1 3-tier architectures appeared in the 90s its prominence was partly due to its promotion by the Gartner Group 91.3913 R McFadyen

  8. Different Deployments of 3-Tier - Fig 30.15, p 471 Thick Client Thin Client There are many ways of slicing the 3-tier architecture across one or more hardware components 91.3913 R McFadyen

  9. Model-View Separation Principle - P 471-3 • Concept originated with SmallTalk development (MVC) • The general concern is: what kind of visibility should other packages have to the Presentation Layer? • Model is synonymous with Domain Layer • View is synonymous with Presentation Layer • The Model-View Separation principle states that model objects should not have direct knowledge of View objects • Window classes are relatively thin; they are responsible for input/output, catching GUI events, but do not maintain data or provide application functionality • e.g. Register or Sale objects should not send messages directly to a GUI window object (Note Observer does not involve direct coupling) 91.3913 R McFadyen

  10. Model-View Separation Principle - P 471-3 • How do windows obtain information to display? • Two approaches: • Polling/Pull-from-above • Push-from-below • needed when polling is too inefficient • two solutions: • Observer • Presentation Façade object One is deciding how two layers are going to interact - this is a big decision, an architectural decision 91.3913 R McFadyen

  11. Figure 30.16 Presentation Facade 91.3913 R McFadyen

More Related