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 Spring 2017

Unix Layered Architecture (c) Ian Davis Spring 2017

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 Spring 2017 (c) Ian Davis

Pattern: Microkernel Context Problem Forces 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 Spring 2017 (c) Ian Davis

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) Spring 2017 (c) Ian Davis

Spring 2017 (c) Ian Davis

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

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 Spring 2017

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 Spring 2017

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 Spring 2017 (c) Ian Davis

Implicit Invocation Architecture Spring 2017 (c) Ian Davis

Implicit Invocation Model/View/Controller Publish/Subscriber 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 Spring 2017 (c) Ian Davis

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 Spring 2017 (c) Ian Davis

Model View Controller (MVC) Spring 2017 (c) Ian Davis

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 Spring 2017 (c) Ian Davis

Model View Presenter Problem Solution 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 Spring 2017 (c) Ian Davis

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 model and updating the view, reacting to user interactions updating the model. https://medium.com/@cervonefrancesco/model-view-presenter-android-guidelines-94970b430ddf Spring 2017 (c) Ian Davis

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 Spring 2017 (c) Ian Davis

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 Spring 2017

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 Spring 2017

Implicit Invocation Style (Cont’d) 11/30/2018 Implicit Invocation Style (Cont’d) An event announcement “implicitly” causes the invocation of procedures in other modules. (c) Ian Davis Spring 2017

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 Spring 2017

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 Spring 2017

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 Spring 2017

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 Spring 2017

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 Spring 2017

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 Spring 2017

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 Spring 2017

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 Spring 2017