m%20:%20Model

1
An abstract object model
v1 ViewA
v2 ViewB
access
access
propagate
propagate
m Model
access
access
access
access
c1 ControllerA
c2 ControllerB
2

• Model provides central functionality of the
  application, is aware of its dependent view and
  controller components
• View each view corresponds to a particular style
  and format of presentation of information. View
  retrieves data from model and updates itself when
  data has been changed in another view. View
  creates its own controller.
• Controller accepts user input events that
  trigger operations/changes within the model.
  These may trigger updates in other views ensuring
  they are up to date.
• See also Observer design pattern.

3
MyView
viewData initialize() displayData() update()
depends on
Model

1
coreData setOfObservers attach(Observer) detach(Ob
server) notify() getData() modifyData()
1
1
updates
MyController
updates
viewData initialize() changeData() update()

1
4
c1 Controller
m Model
v1 View
changeData()
modifyData()
notify()
update()
displayData()
getData()
update()
getData()
5

• 4.3 Independent components
• executing in parallel, with communication,
• aka object-oriented architectures.
• e.g. simple OOP, peer to peer (2-way client-
  server)

6

• 4.4 Virtual machines
• an interpreter (high-level machine) a
• program in a special purpose
• (application-oriented) language

I/O
VM
e.g. Java VM, application-oriented PLs
7

• 4.5 Data Centered
• Built around a large data collection, aka
  repository

App3
App1
App2
8
Example Client-Server

Server service1() service2() serviceN()
Client
requester
provider
Request for service using RPC or CORBA, Java RMI,
HTTP.
9

• 4.6 Layered
• subsystems hierarchically organised, each
• layer (1) depending only on layer below, (2)
• supplying services to layers above

10
Example 1 ISO/OSI 7 layer communication
hierarchy
7. Application (mail, telnet, ftp )
6. Presentation (XDR)
5. Session (RPC)
4. Transport (TCP, UDP)
3. Network (IP)
2. Data Link (Ethernet)
Hardware
1. Physical (thinnet, thicknet, UTP)
11
(No Transcript)
12
Example 2 Three-Tier Database Architecture

3. Interface layer
2. Application logic layer
1. Storage layer
Interface layer objects dealing with user,
windows, forms, Web pages, etc Application logic
layer control and entity objects for
processing, Rule checking and notification Storage
layer implements storage, retrieval and query
of persistent objects
13
Example 3 Four-Tier Database Architecture

Interface layer
4. Presentation Client
3. Presentation Server
2. Application logic layer
1. Storage layer
Presentation Client sits on user
machine. Presentation Server sits on server
machine Different kinds of clients and servers
possible Compare with MVC!
14
Interface layer
4. WebBrowser
3. Server Side Form
2. DB Connection
1. SQL Query
15
Architecture Tradeoff Analysis Method ATAM

• CMU Software Engineering Institute (SEI)
• Collect scenarios (use cases)
• Elicit requirements, constraints and environment
• Describe architectural styles/patterns
• Evaluate quality attributes, e.g. reliability,
  performance, security, flexibility, portability,
  testability
• Identify sensitivity points attributes sensitive
  to a small change in architecture
• Critique candidate architectures

16

• Once the sensitivity points have been
  determined, finding trade-off points is simply
  the identification of architectural elements to
  which multiple attributes are sensitive.
• E.g. The performance of a client-server
  architecture might be highly sensitive to the
  number of servers. The availability might also be
  sensitive to that number. However, the security
  might vary inversely with that number (more
  points of attack).
• So the number of servers is a trade-off point.