SOEN 343Software Design

Section H Fall 2006

Dr Greg Butlerhttp://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

• GRASP Controller principle (Larman 17.13)

• Design for visibility (Larman ch 19)

Design Model

: Register

enterItem(itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID )

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

Vision Glossary

The logical architecture is influenced by the constraints and non-functional requirements captured in the Supp. Spec.

Domain Model

**

SupplementarySpecification

Use-Case Model

Register

...

makeNewSale()enterItem(...)...

ProductCatalog

...

getProductSpec(...)...

1 1class diagrams(a static view)

interaction diagrams(a dynamic view)

UIpackage diagramsof the logical architecture(a static view) Domain

Tech Services

Design Model

Logical Architecture – Simple Layers

Domain

UI

Swingnot the Java Swing libraries, but our GUI classes based on Swing

Web

Sales Payments Taxes

Technical Services

Persistence Logging RulesEngine

Logical Architecture – LayersUI

(AKA Presentation, View)

Application(AKA Workflow, Process,Mediation, App Controller)

Domain(AKA Business,

Application Logic, Model)

Technical Services(AKA Technical Infrastructure, High-level Technical Services)

Foundation(AKA Core Services, Base Services,

Low-level Technical Services/Infrastructure)

width implies range of applicability

GUI windowsreportsspeech interfaceHTML, XML, XSLT, JSP, Javascript, ...

handles presentation layer requestsworkflowsession statewindow/page transitionsconsolidation/transformation of disparate data for presentation

handles application layer requestsimplementation of domain rulesdomain services (POS, Inventory)- services may be used by just one application, but there is also the possibility of multi-application services

(relatively) high-level technical services and frameworks Persistence, Security

low-level technical services, utilities, and frameworksdata structures, threads, math, file, DB, and network I/O

moreapp

specific

de

pen

den

cy

Business Infrastructure(AKA Low-level Business Services)

very general low-level business services used in many business domainsCurrencyConverter

Logical Architecture – Layers & Partitions

Persistence Security Logging

Technical Services

POS Inventory Tax

Domain

Vertical Layers

Horizontal Partitions

Logical Architecture – Layers & Partitions

Domain(s)

Technical Services

Foundation

MySQL Inventory

PersistenceNaming and

Directory ServicesWeb

AppFramework

Technical Services

POS Inventory

Domain(s)

Foundation

Worsemixes logical and deployment views

Bettera logical view

a logical representation of the need for data or services related to these subdomains, abstracting implementation decisions such as a database.

«component»NovellLDAP

UML notation: A UML component, or replaceable, modular part of the physical system

UML notation: A physical database in the UML.

Domain Model and Domain LayerLow representational gap

Payment

amount

Sale

datetime

Pays-for

Payment

amount: Money

getBalance(): Money

Sale

date: DatestartTime: Time

getTotal(): Money. . .

Pays-for

UP Domain ModelStakeholder's view of the noteworthy concepts in the domain.

Domain layer of the architecture in the UP Design ModelThe object-oriented developer has taken inspiration from the real world domain in creating software classes.

Therefore, the representational gap between how stakeholders conceive the domain, and its representation in software, has been lowered.

1 1

1 1

A Payment in the Domain Model is a concept, but a Payment in the Design Model is a software class. They are not the same thing, but the former inspired the naming and definition of the latter.

This reduces the representational gap.

This is one of the big ideas in object technology.

inspires objects

and names in

SSDs, System Operations & Layers

Domain

UI

Swing

ProcessSaleFrame

...

... Register

makeNewSale()enterItem()...

: Cashier

makeNewSale()enterItem()endSale()

makeNewSale()enterItem()endSale()

enterItem(id, quantity)

:System: Cashier

endSale()

description, total

makeNewSale()

the system operations handled by the system in an SSD represent the operation calls on the Application or Domain layer from the UI layer

Model-View Separation Principle (MVC)

UI layer has viewsDomain layer has model

Domain

UI

Swingnot the Java Swing libraries, but our GUI classes based on Swing

Web

Sales Payments Taxes

Technical Services

Persistence Logging RulesEngine

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 ObjectsSpend plenty of time on dynamic models(see notation chapter 15)

Jacobson’s Objectory Design Objects

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?

???

Presentation

ApplicationLogic

Video Store

Record Rental

Video ID

...

...

...

... ...

Clerk

rent(videoID)

Now what happens?

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 represents1. 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. 17.21

Which class of object should be responsible for receiving this system event message?

It is sometimes called the controller or coordinator. It does not normally do the work, but delegates it to other objects.

The controller is a kind of "facade" onto the domain layer from the interface layer.

actionPerformed( actionEvent )

: ???

: Cashier

:SaleJFrame

presses button

enterItem(itemID, qty)

UI Layer

Domain Layer

system operation message

Fig. 17.22 Controller choices

:RegisterenterItem(id, quantity)

:ProcessSaleHandlerenterItem(id, quantity)

Fig. 17.24 Desirable coupling

actionPerformed( actionEvent )

:Register

: Cashier

:SaleJFrame

presses button

1: enterItem(itemID, qty)

:Sale1.1: makeLineItem(itemID, qty)

UI Layer

Domain Layer

system operation message

controller

Fig. 17.26 Controller delegating work

: Register : Sale

addPayment( p )

p : Paymentcreate()makePayment()

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

:Afoo()

: B

bar := getBar( )

{public void foo(){ .. bar = myB.getBar() ...}}

class A{ ... private B myB; ...}

Parameter Visibility

2: bar(spec)foo()

1: spec := getSpecification(id)

:A : B

: C

Local Visibility

: Afoo()

: B

spec := getSpecification( itemID )

{foo(){...// local visibility via assignment of returning objectProductSpecification spec = myB.getSpecification(id);...}}