Architectural Styles and Patterns

1
Architectural Styles andPatterns

• 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
  Object-Oriented Software, Addison-Wesley, 1995.

2
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

3
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

4
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

5
Example
Layered security architecture
Cryptography
File interface
Key management
User
6
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
7
Layered Architectures in Interactive Information
Systems
Browsers
Presentation
Web Server
Application Control and Coordination
App Server
Domain Services and Information
Db Server
Legacy Database Services
8
Characteristic Object Roles
Windows and Widgets
Presentation
Interfacers
Events
Results
Coordinators, and (application) controllers
Application Services
Results
Messages
Information holders, service providers, Structures
, coordinators, and domain controllers
Domain Services
Results
Messages
Technical Services
Interfacers
9
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

10
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

11
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

12
Ontology
13
Workflow Derived from Ontology
isInputTo
Raw Gravity Data
Excel Reduction
isConvertedTo
outputs
Anomaly Values
isInputTo
Mapping Method
outputs
Anomaly Map
14
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.

15
Why Design Patterns?

• To capture and document software design
  knowledge.
• gt 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.

16
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.

17
Separating M from VC
18
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.

19
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).

20
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.

21
Model-View Separation Pattern
Window
View
display( )
Goal Classes in Model should not have direct
visibility to classes in View.
Configuration
Model
addEntry( ) query( )
22
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.

23
Model-View Separation Pattern
Worse
Window
View
Model classes talk to View classes.
display( )
displayMessage ( )
Configuration
Model
addEntry( ) query( )
24
Model-View Separation Pattern
Window
View
display( )
query( )
Configuration
Model
addEntry( ) query( )
25
Model-View Separation Pattern
View
query( )
The View Layer can be modified without affecting
the Model layer.
Configuration
Model
addEntry( ) query( )
26
Model-View Separation Pattern
When the Window needs to display data it queries
the Model objects Polling Model
View
query( )
Configuration
Model
addEntry( ) query( )
27
Model-View Separation Pattern

• Problem Domain objects need to communicate with
  windows to cause a real-time ongoing display
  update as the state of information in the domain
  object changes.
• - Monitoring applications
• - Simulation applications.
• Solution Indirect Visibility

28
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).

29
Model-View Separation Pattern with Indirect
Visibility
tells Window to Update
View
Model View Controller
query( )
Configuration
post Update Message
Model
addEntry( ) query( )
30
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

31
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

32
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

33
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