1 / 35

SOEN 343 Software Design

SOEN 343 Software Design. Section H Fall 2006 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/soen343h-f06.html. Outline. Importance of domain model, use cases, operation contracts for design Layers MVC Use case realization, Jacobson robustness analysis, traceability

delano
Download Presentation

SOEN 343 Software Design

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. SOEN 343Software Design Section H Fall 2006 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/soen343h-f06.html

  2. Outline • Importance of domain model, use cases, operation contracts for design • Layers • MVC • Use case realization, Jacobson robustness analysis, traceability • GRASP Controller principle (Larman 17.13) • Design for visibility (Larman ch 19)

  3. Design Model

  4. Logical Architecture – Simple Layers

  5. Logical Architecture – Layers

  6. Logical Architecture – Layers & Partitions

  7. Logical Architecture – Layers & Partitions

  8. Domain Model and Domain Layer Low representational gap

  9. SSDs, System Operations & Layers

  10. Model-View Separation Principle (MVC) UI layer has views Domain layer has model

  11. Model-View-Control Architecture (MVC) • MVC is an acronym for Model View Controller • It represents a software design pattern developed at Xerox PARC in 1978 (!) • It explains a method of separating the visual, interaction and data components. • Very popular, used extensively in Java and other languages

  12. Model-View-Control Architecture (MVC) Model • maintains the state and data of the application - the XML document View • A rendering of the XML document Controller • The user interface presented to the user to manipulate the application

  13. Why use MVC • Makes it very easy to have multiple different displays of the same information. • For example: a graph and a table could both display and edit the same data. • Essentially provides greater control over the UI and it’s behaviour.

  14. MVC Model • The “Model” contains the data • Has methods to access and possibly update it’s contents. • Often, it implements an interface which defines the allowed model interactions. • Implementing an interface enables models to be pulled out and replaced without programming changes.

  15. MVC Controller • Users interact with the controller. • It interprets mouse movement, clicks, keystrokes, etc • Communicates those activities to the model – eg: delete row, insert row, etc • It’s interaction with the model indirectly causes the View(s) to update

  16. MVC View • The View provides a visual representation of the model. • There can be multiple views displaying the model at any one time. • For example, a companies finances over time could be represented as a table and a graph. • These are just two different views of the same data. • When the model is updated, all Views are informed and given a chance to update themselves.

  17. 14.4 Design Objects Spend plenty of time on dynamic models (see notation chapter 15)

  18. Jacobson’s Objectory Design Objects

  19. Jacobson’s Objectory Design Objects Robustness model has • Entity objects • Boundary (interface objects) • Control objects Essentially UML collaboration (communication) diagram

  20. Jacobson’s Robustness Analysis Bridges Analysis-Design Gap

  21. What are the users doing? (Jacobson) • What are the objects in the real world? (Rumbaugh) • What objects are needed for each use case? (Jacobson) • How do the objects collaborate with each other? (Jacobson and Booch) • How will we implement real-time control? (state models) • How are we really going to build this system? (Booch)

  22. Traceability

  23. PATTERN: Controller • What object in the domain (or application coordination layer) receives requests for work from the UI layer?

  24. PATTERN: Controller (Larman 17.13) Problem: What object in the domain (or application coordination layer) receives requests for work from the UI layer? System operations (see SSD): major input events to the system The controller is the first object beyond the UI layer that is responsible for receiving or handling a system operations message. Note that UI objects delegate system operation request to a controller.

  25. PATTERN: Controller (Larman 17.13) Solution: Assign the responsibility to a class representing one of the following choices: • A façade controller, which represents • the overall system • A root object • A device that the software is running within, or • A major subsystem • A use case or session controller which represents a use case scenario in which the system operation occurs

  26. Fig. 17.21

  27. Fig. 17.22 Controller choices

  28. Fig. 17.24 Desirable coupling

  29. Fig. 17.26 Controller delegating work

  30. Designing for Visibility • Fact: To send a message to B, A must have visibility to B. It doesn’t happen by “magic.” • Kinds of visibility: • Attribute • Parameter • Local • Global Larman ch 19

  31. Attribute Visibility

  32. Parameter Visibility

  33. Local Visibility

More Related