Transcript Responsibilities

Architectural Styles and
Patterns
Wirfs Brock et al, Designing Object-Oriented
Software, Prentice Hall, 1990.
E. Gamma, R. Helm, R. Johnson, and J. Vlissides.
Design Patterns, Elements of Reusable ObjectOriented Software, Addison-Wesley, 1995.
Architectural Styles
• Definition: a classification that captures how
software objects are organized with respect to
component interaction and control
• Examples:
– Layered
– Pipes and filters
– Client-Server
Architectural Styles
Remarks:
• Each style has its own advantages and drawbacks
• An application may require several architectural
views
• Choosing the right views is a key factor in
having a good design
Layered Architecture
• Layers are hierarchical
• Each layer provides services to the outer layer
which is a client to the inner layer
• Layers can have access to adjacent layers (direct
access only)
• The design includes how each pair of layers
interact (protocols)
• Layered architectures are often used for interactive
information services
Example
Layered security architecture
Cryptography
File interface
Key management
User
Advantages and Drawbacks
+ Each layer can be seen as a higher level of
abstraction
+ A change on one layer affects only layers
interacting with the changed layer
+ Clearly favors reuse
- Layers are not always obvious when looking at the
requirements
- Performance may suffer from the extra
coordination among the layers
Layered Architectures in Interactive Information Systems
Browsers
Presentation
Web Server
App Server
Db Server
Application
Control and
Coordination
Domain
Services and
Information
Legacy
Database
Services
Windows and
Widgets
Characteristic Object Roles
Presentation
Interfacers
Coordinators,
and
(application)
controllers
Information
holders,
service
providers,
Structures,
coordinators,
and domain
controllers
Events
Messages
Application
Services
Results
Domain
Services
Messages
Interfacers
Results
Results
Technical
Services
Locating Objects in Layers
• Once we have agreed on a layered architecture, we
need to identify objects (classes) in layers
• One approach is to use CRC
-objects collaborates mostly within their layers
-client objects will tend to be in an outer layer
(requests go inside)
-information goes outside
Pipe and Filter-1
• Defining characteristics
– Each component has a set of inputs and outputs
– Component reads streams of data on its inputs and produces
streams of data on its outputs
– Local transformations on input streams and incremental
computation
– Output begins before input is consumed
• Terms
– Components are called filters
– Connectors are called pipes
Pipe and Filter-2
• Invariants
– Filters must be independent entities; do not share state
with other filters
– Filters do not know identity of the upstream and
downstream filters
• Common variations
– Pipelines that restrict topologies to linear sequences of
filter
– Bounded pipes that restrict the amount data that reside
in pipe
– Batch sequential that do not require stream of data
Ontology
Workflow Derived from Ontology
Raw Gravity Data
isConvertedTo
Anomaly Values
isInputTo
Anomaly Map
isInputTo
Excel Reduction
outputs
Mapping Method
outputs
What Are Design Patterns?
• Schematic descriptions of solutions to
recurring problems in software design
• Design patterns describe
– Problems that occur repeatedly, and
– Core solutions to those problems.
• And such solutions are
– Reusable, but do not have to be implemented in the
same way.
Why Design Patterns?
• To capture and document software design
knowledge.
=> helps designers acquire design expertise.
• To support reuse in design and boost confidence in
software systems.
• To provide a common vocabulary for software
designers to communicate their designs.
Model-View-Controller (MVC)
• A way of cleanly breaking an application into
three parts:
– Models for maintaining data,
– Views for displaying all or a portion of the data,
and
– Controllers for handling events that affect the
model or views.
16
CS 4311
Separating M from VC
get data
from model
changes
model or view
View
Controller
Model
update view
when data changes
17
CS 4311
Due to Separation …
• Multiple views and controllers for the same
model.
• New views and controllers for the model.
• Localized changes in views, i.e., minimal or no
impact on the model.
18
CS 4311
Model-View Separation Pattern
• Model: The domain layer of objects.
(objects that contain data and operations).
• View: The presentation layer of objects
(windows, applets, reports).
Model-View Separation Pattern
• Context/Problem
It is desirable to de-couple domain (model) objects from
windows (views), to support increased reuse of domain
objects, and minimize the impact of changes in the
interface upon domain objects.
• Solution
Define the domain (model) classes so that they do not have
direct coupling or visibility to the window (view) classes,
and so that application data and functionality is maintained
in domain classes, not window classes.
Model-View Separation Pattern
View
Window
display( )
Configuration
Model
addEntry( )
query( )
Goal: Classes
in Model should
not have direct
visibility to
classes in View.
Model-View Separation Pattern
Motivation
• Focus more on the domain processes rather than
on computer interfaces.
• Allow separate development of the model and user
interface layers.
• Minimize the impact of changes in the interface
upon the domain layer.
• Allow new views to be easily connected to an
existing domain layer.
Model-View Separation Pattern
View
Window
display( )
Worse
Model classes
talk to View
classes.
displayMessage ( )
Configuration
Model
addEntry( )
query( )
Model-View Separation Pattern
View
Window
display( )
query( )
Configuration
Model
addEntry( )
query( )
Better
View classes
talk to Model
classes.
Model-View Separation Pattern
View
New Window
Old Window
display( )
display( )
query( )
Configuration
Model
addEntry( )
query( )
The View Layer
can be modified
without affecting
the Model layer.
Model-View Separation Pattern
View
New Window
display( )
query( )
Configuration
Model
addEntry( )
query( )
When the Window
needs to display
data it queries the
Model objects
“Polling Model”
Model-View Separation Pattern
• Problem: Domain objects need to
communicate with windows to cause a realtime ongoing display update as the state of
information in the domain object changes.
- Monitoring applications
- Simulation applications.
• Solution: Indirect Visibility
Model-View Separation Pattern
with Indirect Visibility
• Named Publish-Subscribe Pattern
• Context/Problem:
A change in state (an event) occurs within a Publisher
of the event and other objects are dependant on or
interested in this event (Subscribers to the event).
However the Publisher should not have direct knowledge
of its subscribers.
• Solution:
Define an event notification system so that the Publisher an
indirectly notify Subscribers. Event Manager or Model
View Controller (MVC).
Model-View Separation Pattern
with Indirect Visibility
View
Window
display( )
query( )
tells Window to Update
Model View
Controller
Configuration
Model
post Update Message
addEntry( )
query( )
CRC: MVC
• Model
– Provides functional core of application
– Registers dependent views and controllers
– Notifies dependent components about data changes
• View
–
–
–
–
Creates and initializes associated controller
Displays information to user
Implements update procedure
Retrieves data from model
CRC: MVC
• Controller
– Accepts user input as events
– Translates events to service request for model
or display requests for view
– Implements update procedure if required
Some Considerations: Data
Management
• Data Management (DM); Problem Domain (PD)
• DM objects
– Each DM object knows all objects in corresponding PD class
– Knows indices, dictionaries, information for converting an
object from and to other formats (row, record)
– Knows how to search (single object; collection of objects;
multiple types of criteria)
– Knows how to load, save, delete (persistent store; flat file;
memory)
– Knows how to cache
DM Object
• Isolates data management complexities from application
• Encapsulates how to store and retrieve objects from whatever storage
mechanism used
• Encapsulates where data comes from (location and sources involved)
• Add corresponding DM object when have PD objects that needs
someone to search across persistent objects
• DM Object Server maintains collection of DM objects, provides a
single point of access to get a DM object, and provides commitment
control for all objects transactions