SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler

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)

Design Model

Logical Architecture – Simple Layers

Logical Architecture – Layers

Logical Architecture – Layers & Partitions

Domain Model and Domain Layer Low representational gap

SSDs, System Operations & Layers

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

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

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

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.

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.

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

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.

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

Jacobson’s Objectory Design Objects

Robustness model has Entity objects Boundary (interface objects) Control objects Essentially UML collaboration (communication) diagram

Jacobson’s Robustness Analysis Bridges Analysis-Design Gap

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)

Traceability

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

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.

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

Fig

Fig Controller choices

Fig Desirable coupling

Fig Controller delegating work

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

Attribute Visibility

Parameter Visibility

Local Visibility