Layered Style Examples

1. Layered Style Examples • Layered Communication Protocols: • Each layer provides a substrate for communication at some level of abstraction. • Lower levels define lower levels of interaction, the lowest level being hardware connections (physical layer). • Operating Systems • Unix (c) Ian Davis

2. Unix Layered Architecture (c) Ian Davis

3. Overlaid Layered Architecture • Dynamically load code as needed • Can instantiate many different capabilities at run time • Free memory for reuse when no longer needed • COBOL (Initial, mainline, final) • COM/OLE • Reference counting • Garbage collection (c) Ian Davis

4. Pattern: Microkernel • Context • Core functionality must deploy on different platforms • Problem • Connections to hardware / OS subject to change • Forces • Preserve abstraction rather than focus on detail • Encapsulate what may change so easier to change • Share abstraction across all applications • Memory protection within O/S as well as outside (c) Ian Davis

5. Characteristics • Minimal capabilities in a much reduced Kernel • Process creation / deletion / scheduling • Foundational Inter-Process Communication • Secure Memory Management • Much implemented as application software • File System / Network Software / Drivers • Offers choice / variety / extension / change • Adaptable (O/S not set in stone) (c) Ian Davis

6. (c) Ian Davis

7. https://en.wikipedia.org/wiki/Microkernel (c) Ian Davis

8. Layered Style Advantages • Design: based on increasing levels of abstraction. • Enhancement: since changes to the function of one layer affects at most two other layers. • Reuse: since different implementations (with identical interfaces) of the same layer can be used interchangeably. (c) Ian Davis

9. Layered Style Disadvantages • Not all systems are easily structured in a layered fashion. • Performance requirements may force the coupling of high-level functions to their lower-level implementations. • Adding layers increases the risk of error. • Eg. getchar() doesn’t work correctly on Linux if the code is interrupted, but read() does. (c) Ian Davis

10. Object-Oriented Style • Powerful metaphor • Dynamic creation and deletion of objects • Clearer encapsulation of functionality • More restrictions on legitimate usage • Inheritance • Polymorphism • Pure abstract interfaces (c) Ian Davis

11. Implicit Invocation Architecture (c) Ian Davis

12. Implicit Invocation • Model/View/Controller • Data forms the Model • Controller changes the model • Controller announces to requesting views change • Publish/Subscriber • Publishes to topics • Subscribers listen to topics • Observer design pattern • Underlying implementation (c) Ian Davis

13. Pattern: Model View Controller • Context • Systems retrieve and display data in many formats • User interface may need new or altered views • Problem • Don’t want core application to be concerned with supporting the User Interface behaviour • Forces at work • User interface expected to evolve • Parallel tasks can be handled in different ways • Partition how things appear from how they change (c) Ian Davis

14. Model View Controller (MVC) (c) Ian Davis

15. Model ↔ View ↔ Controller • Business logic does not sit between Display and State • Changes to model broadcast to listeners • View responsible for presentation of model • Different parts of dashboard all listen for change • Controller • Responsible for handling input • Maintains model consistency (c) Ian Davis

16. Model View Presenter • Problem • Hard to test/generate pseudo user interaction • Solution • Separate the logic for the visual display • View (software that writes to the screen) • Presenter (sees interactions that occur on screen) • Impose a strict interface between the two • Can now test presenter without having a screen • Simply invoke interface from test software (c) Ian Davis

17. MVC .v. MVP • MVP can be a refinement of MVC • Android MVP looks a lot more like 3 tier The presenter is the middle-man between model and view. All your business logic belongs to it. The presenter is responsible for querying the modelandupdating the view, reacting to user interactions updating the model. https://medium.com/@cervonefrancesco/model-view-presenter-android-guidelines-94970b430ddf (c) Ian Davis

18. Why to avoid 3-tier • In a dashboard can have many sub-views • New sub-views should be easy to develop • A sub-view may not be visible all the time • Putting all view management in the presenter makes the presenter ever fatter (and confused) • Risks breaking presenter if have to change it • Presenter doesn’t care about the views • subview listening software better encapsulated • subview can easily be deactivated/reactivated (c) Ian Davis

19. Implicit Invocation Style • Suitable for applications that involve loosely-coupled collection of components, each of which carries out some operation and may in the process enable other operations. • A generalization of event driven code in which relevant state is included with the event, and multiple processes can “see” events. (c) Ian Davis

20. Implicit Invocation Style (Cont’d) • Instead of invoking a procedure directly ... • A component can announce (or broadcast) one or more events. • Other components in the system can register an interest in an event by associating a procedure with the event. • When an event is announced, the broadcasting system (connector) itself invokes all of the procedures that have been registered for the event. (c) Ian Davis

21. Implicit Invocation Style (Cont’d) • An event announcement “implicitly” causes the invocation of procedures in other modules. (c) Ian Davis

22. Implicit Invocation Invariants • Announcers of events do not know which components will be affected by those events. • Components cannot make assumptions about what processing will occur as a result of their events (perhaps no component will respond). • Components cannot make assumptions about the order of processing. (c) Ian Davis

23. Implicit Invocation Specializations • Often connectors in an implicit invocation system also include the traditional procedure call in addition to the bindings between event announcements and procedure calls. (c) Ian Davis

24. Implicit Invocation Examples • Used in programming environments to integrate tools: • Debugger stops at a breakpoint and makes that announcement. • Editor responds to the announcement by scrolling to the appropriate source line of the program and highlighting that line. • LSEdit (c) Ian Davis

25. Implicit Invocation Examples (Cont’d) • Used to enforce integrity constraints in database management systems (called triggers). • Used in user interfaces to separate the presentation of data (views) from the applications that manage that data. • Used in user interfaces to allow correct mapping of function keys etc. to logic. • Used in forms to allow generic logic. (c) Ian Davis

26. Implicit Invocation Advantages • Provides strong support for reuse since any component can be introduced into a system simply by registering it for the events of that system. • Eases system evolution since components may be replaced by other components without affecting the interfaces of other components in the system. • Easy to add new views, etc. (c) Ian Davis

27. Implicit Invocation Advantages • Eases system development since one has to only map the events which occur to the software that manages them, and these events are often predefined. • Case tools hide the complexities of managing the flow of events. • Asynchronous interface improves performance, response times etc. • Parallelism? (c) Ian Davis

28. Implicit Invocation Disadvantages • When a component announces an event: • it has no idea what other components will respond to it, • it cannot rely on the order in which the responses are invoked, • it cannot know when responses are finished. • Feedback involves generating additional events that are routed to callback routines. (c) Ian Davis

29. Implicit Invocation Disadvantages • There is no single defined flow of logic within such systems. • It can be hard to consider all possible events that may occur, and their interactions. • Such systems can be very hard to both maintain and debug. • There is the risk that you end up communicating with “Trojan horses”. (c) Ian Davis