What kind of visibility should other packages have to the UI layer? How should non - window classes communicate with windows?
In this context, modelis a synonym for the domain layer of objects (it's an old 00 term from the late 1970s). Viewis a synonym for UI objects, such as windows, Web pages, applets, and reports.
The Model - View Separationprinciple2 states that model (domain) objects should not have direct knowledge of view (UI) objects, at least as view objects. So, for example, a Register or Saleobject should not directly send a message to a GUI window object ProcessSaleFrame, asking it to display something, change color, close, and so forth.
A legitimate relaxation of this principle is the Observer pattern, where the domain objects send messages to UI objects viewed only in terms of an interface such as PropertyListener (a common Java interface for this situation). Then, the domain object doesn't know that the UI object is a UI object - it doesn't know its concrete window clasj. It only knows the object as something that implements the PropertyListener interface.
A further part of this principle is that the domain classes encapsulate the information and behavior related to application logic. The window classes are relatively thin; they are responsible for input and output, and catching GUI events, but do not maintain application data or directly provide application logic. For example, a Java JFrame window should not have a method that does a tax calculation. A Web JSP page should not contain logic to calculate the tax. These UI elements should delegate to non - UI elements for such responsibilities.
The motivation for Model - View Separation includes:
What's the Connection Between SSDs, System Operations, and Layers?
During analysis work, we sketched some SSDs for use case scenarios. We identified input events from external actors into the system, calling upon system operations such as makeNewSale and enterltem.
The SSDs illustrate these system operations, but hide the specific UI objects. Nevertheless, normally it will be objects in the UI layer of the system that capture these system operation requests, usually with a rich client GUI or Web page.
In a well - designed layered architecture that supports high cohesion and a separation of concerns, the UI layer objects will then forward - or delegate - the request from the UI layer onto the domain layer for handling.
Now, here's the key point:
The messages sent from the UI layer to the domain layer will be the messages illustrated on the SSDs, such as enterltem.
For example, in Java Swing, perhaps a GUI window class called ProcessSale - Frame in the UI layer will pick up the mouse and keyboard events requesting to enter an item, and then the ProcessSaleFrame object will send an enterltem message on to a software object in the domain layer, such as Register, to perform the application logic.
System operations in the SSDs and in terms of layers
Example: Monopoly Logical Architecture?
The Monopoly architecture is a simple layered design - UI, domain, and services. There is nothing novel to illustrate, so the NextGen case study is used for the architectural examples.
UML Related Interview Questions
|Adv Java Interview Questions||Java collections framework Interview Questions|
|Design Patterns Interview Questions||Rational robot Interview Questions|
|Web semantic Interview Questions||Spring MVC Framework Interview Questions|
|Advanced C++ Interview Questions||Advanced jQuery Interview Questions|
|XML DOM Interview Questions||Object Oriented Analysis and Design Interview Questions|
Object-oriented Analysis And Design
Iterative, Evolutionary, And Agile
Inception Is Not The Requirements Phase
Iteration 1 Basics
System 'sequence Diagrams
Requirements To Design-iteratively
Logical Architecture And Uml Package Diagrams
On To Object Design
Uml Interaction Diagrams
Uml Class Diagrams
Grasp: Designing Objects With Responsibilities
Object Design Examples With Grasp
Designing For Visibility
Mapping Designs To Code
Test - Driven Development And Refactoring
Uml Tools And Uml As Blueprint
Iteration 2 - More Patterns
Quick Analysis Update
Grasp: More Objects With Responsibilities
Applying Gof Design Patterns
Iteration 3 Intermediate Topics
Uml Activity Diagrams And Modeling
Uml State Machine Diagrams And Modeling
Relating Use Cases
Domain Model Refinement
More Ssds And Contracts
Logical Architecture Refinement
More Object Design With Gof Patterns
Designing A Persistence Framework With Patterns
Uml Deployment And Component Diagrams
Documenting Architecture: Uml & The N+1 View Model
More On Iterative Development And Agile Project Management
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.