1 / 16

m : Model

An abstract object model. v1 : ViewA. v2 : ViewB. access. access. propagate. propagate. m : Model. access. access. access. access. c1 : ControllerA. c2 : ControllerB. Model : provides central functionality of the application, is aware of its dependent view and controller components

shawn
Download Presentation

m : Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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(Observer) 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. 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

  12. 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!

  13. Interface layer 4. WebBrowser 3. Server Side Form 2. DB Connection 1. SQL Query

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

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

More Related