soen 343 software design
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
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);...}}