feb. 23, 2004cs 509 - wpi1 cs 509 design of software systems lecture #5 monday, feb. 23, 2004
Post on 21-Dec-2015
213 views
TRANSCRIPT
Feb. 23, 2004 CS 509 - WPI 2
Term Project AdministrationChanges to Course MaterialQuestionsQuiz #3Review of Chapters 8 & 9:In-class Exercise:
Requirements for new design project
Class Format for Today
Feb. 23, 2004 CS 509 - WPI 3
Term Project Administration
Return Phase 2 – Functional Specifications And Journals
Return Quiz #2About Phase 3:
How is the project progressing? Can we continue as planned?
• System & Object Design for CTS due next week
Have you started object design, or do you prefer to just focus on system design?
Feb. 23, 2004 CS 509 - WPI 4
Changes to Course Material
Next week start on a new project to design Home Inventory System (thanks to Michael) Discuss requirements later tonight
Presentations or 2 phases for last month?Readings & lecture topics:
Read Chapter 10 for next week New assignments will be posted to web site
Discuss possible topics for CS562
Feb. 23, 2004 CS 509 - WPI 5
Questions?
About what was covered last timeFrom the readingAbout the Term ProjectAnything else?
Feb. 23, 2004 CS 509 - WPI 8
Overview of Activities
Reuse (Chapter 8) Pick off-the-shelf components & design
patternsService specification (Chapter 9)
Precisely describe each class interfaceObject model restructuring (Chapter
10) Improve understandability & extensibility Optimizations to address performance
criteria (time, memory, etc.)
Feb. 23, 2004 CS 509 - WPI 9
Purpose of Object Design
Close the gap between application objects and selected hardware/software platforms
Identify missing functionality not covered by system design
Construct precise specifications of classes, attributes and operations
Produce a model from which a set of classes can be implemented by individual developers
Feb. 23, 2004 CS 509 - WPI 10
Reuse
Off-the-shelf components identified during system design need to be integrated Class libraries & 3rd party components
selected for basic data structures & services Wrapping components with custom objects Refining them using inheritance
Design patterns selected for solving common problems & isolating the effects of change
Feb. 23, 2004 CS 509 - WPI 11
Interface Specifications
Subsystem services identified during system design specified in terms of class interfaces Operations & Arguments Type signatures Constraints & Exceptions
Identify operations & objects needed to transfer data among subsystems
Feb. 23, 2004 CS 509 - WPI 12
Restructuring
Transforming & optimizing the object model should occur after classes & objects have been designed & interfaces fully specified Often design activities can get side-tracked
by optimization concerns Focusing on interfaces, components &
design patterns results in a more flexible design model
Focusing on optimizations first tends to produce design model that is rigid & difficult to modify
Feb. 23, 2004 CS 509 - WPI 13
Reuse Concepts
Application Objects vs. Solution Objects
Inheritance vs. DelegationThe Liskov Substitution PrincipleDesign PatternsApplication Frameworks
Feb. 23, 2004 CS 509 - WPI 14
Application & Solution Objects
Application domain objects come from the requirements & analysis Boundary, Control, Entity Represent concepts in the problem
domainSolution objects developed during
design Represent concepts with no
counterparts in the problem domain
Feb. 23, 2004 CS 509 - WPI 15
Inheritance vs. Delegation
Review Set/Hashtable example on pgs 310-311
Discuss distinction between inheritance and delegation
Which one is better? Why?Is it a general rule, or better only in this
case?Are there cases where the other is better?How does inheritance relate to taxonomy?
Feb. 23, 2004 CS 509 - WPI 16
Liskov Substitution Principle
“If an object of type S can be substituted in all the places where an object of type T is expected, then S is a subtype of T.
Who can interpret what this means?
Examples?
Feb. 23, 2004 CS 509 - WPI 17
Intro to Design Patterns
Purpose: Template solutions to recurring problems
History: Patterns evolve over time Refined for maximizing reuse & flexibility
Capture Knowledge: Document context & trade-offs Provide guidance about when to use
inheritance vs. delegation
Feb. 23, 2004 CS 509 - WPI 18
Design Pattern Participants
Client Class Accesses the pattern
Pattern Interface Part of pattern that is visible to the
clientImplementor Class(es)
Provides low-level behavior (may be > 1)Extender Class
Provides a specialized implementation or extended behavior
Feb. 23, 2004 CS 509 - WPI 20
Application Frameworks
Terminology: Hook Method Infrastructure Framework Middleware Framework Enterprise Application Framework White Box Framework Black Box Framework
Feb. 23, 2004 CS 509 - WPI 22
Activities Overview
Identify missing attributes & operations
Specify type signatures & visibilitySpecify contracts on classes &
methods
Feb. 23, 2004 CS 509 - WPI 23
Interface Spec. Concepts
Participants: Class implementor Class extender Class user (client)
Types, signatures & visibilityContracts on classes and methods:
Invariants, pre- and post-conditions
Feb. 23, 2004 CS 509 - WPI 24
Participants
Class Implementor Realizes the class
Class User (Client) Invokes operations provided by the
classClass Extender
Develops specializations of the class
Feb. 23, 2004 CS 509 - WPI 25
Types, Signatures & Visibility
Type specifies range of valid values: For attribute, parameters & method
return Examples?
Signature specifies method: Name, param types, return type
Visibility specifies who can see what Private, protected, public What does each mean?
Feb. 23, 2004 CS 509 - WPI 26
Contracts on Classes, Methods
Invariants Predicate true for all instances of a class
Pre-conditions Predicate true before an operation is
invokedPost-conditions
Predicate true after an operation has completed
Purpose? Examples?
Feb. 23, 2004 CS 509 - WPI 27
Object Constraint Language
Formal language for specifying contracts
Constraints should be specified in design document, but may be done more informally
Contracts should also be documented in code, using comments.
See example code on page 358