Documente Academic
Documente Profesional
Documente Cultură
Design
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Specify algorithms
use flowcharts
use pseudocode
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Cars should be able to travel from the top of Smith Hill at 65 mph, travel in a straight line, and arrive at Jones Hollow within 3 minutes.
3. Architecure
(not specifically required)
Cable
Auto
4. Detailed Design
Smith Hill
Road
Pylon
Jones Hollow
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
1. Begin with architectural models -- see chapter 5 class model: domain & architectural classes overall state model* overall data flow model* use case model
2. Introduce classes & design patterns* which connect the architecture classes with the domain classes -- sections 1 and 5 concentrate on riskiest parts first; try alternatives
3. Refine models, make consistent, ensure complete
For each class ... 4. Specify class invariants* -- section 3.1 For each method ... 5. Specify methods with pre- and post-conditions,
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Organize the Team for Detailed Design 1/2 1. Prepare for a detailed design kick-off meeting.
Ensure team members aware of the models (views) they are expected to produce
typically object model, sequence diagrams, state, & data flow
Design leader prepares list of modules Design leader creates a meeting agenda Project leader allocates time to agenda items
(people can speak about detailed designs indefinitely if allowed to!) allocate the time among the agenda items
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Organize the Team for Detailed Design 2/2 2. Hold the kick-off meeting
revise as a group if not
Designate someone to monitor the agenda item time Confirm that the architecture is ready for detailed design
Make sure that module interfaces the are clear Dont try to develop detailed designs as a group
not necessary: individuals have the responsibility groups are seldom good at designing details together
Write out the conclusions and copy/e-mail every member Decide how and when the results are to be reviewed
more detailed schedule with modules & inspections see figure TBD below
Inception Elaboration
Construction
Transition
*Key: terminology
used in this book
1 = Requirements
2 = Achitecture
3=
Detailed design
Analysis
1. Conceptual & abstract
Design
1. Concrete: implementation blueprint 2. Specific for an implementation
1/2
After Jacobson et al: USDP
Analysis
1. Conceptual & abstract
Design
1/2
After Jacobson et al: USDP
2. Applicable to several designs 3. control, entity & boundary stereotypes 4. Less formal 5. Less expensive to develop
Analysis
6. Outlines the design
Design
2/2
7. May use tools (e.g. visual, round-trip engineering) 8. Higher priority for inprocess maintenance
Analysis
6. Outlines the design
Design
2/2
Abstract layer
RegularCustomer
bill() printAccounts()
1.2 display() 1.3 new Engagement() 2. execute() 2.1 setPlayerQuality() 2.2 setQuality() 2.3 setForeignQuality() 2.4 setQuality()
3.2 displayResult()
EncounterGame
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Account. getDeposit()
Customer
User
Customer. getDetails()
.....
Account. getDeposit()
Customer
Account. verifyPassword()
Password
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Specify A Class
1. Gather the attributes listed in the SRS.
if the SRS is organized by class
2. Add additional attributes required for the design. 3. Name a method corresponding to each of the requirements for this class.
easy if the SRS is organized by class
Specify a Function
1. Note the section(s) of the SRS or SDD which this function (method) satisfies. 2. State what expressions the function must leave invariant. 3. State the methods pre-conditions (what it assumes).
4. State the methods post-conditions (its effects).
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Operations
Invariant of withdraw():
availableFundsI = max( 0, balanceI ) .....
xI denotes an attribute; xP denotes a function parameter; x' is the value of x after execution; X denotes a class constant
Precondition*:
withdrawalAmountP >= 0 AND
balanceI - withdrawalAmountP
>= OVERDRAFT_MAX Postcondition*:
4. Specifying algorithms
Flowchart Example
Y
Nominal path
protected final void setName( String aName ) { // Check legitimacy of parameter and settings if( ( aName == null ) || ( maxNumCharsInName() <= 0 ) || ( maxNumCharsInName() > alltimeLimitOfNameLength() ) ) { _name = new String( "defaultName" ); System.out.println ( "defaultName selected by GameCharacter.setName()"); } Set _name Truncate else to parameter name // Truncate if aName too long if( aName.length() > maxNumCharsInName() ) _name = new String ( aName.getBytes(), 0, maxNumCharsInName() ); else // assign the parameter name _name = new String( aName ); } Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Fact
content addFact() proveBack()
consequent
Rule
addRule() proveAntecedents() forwardChain()
1..n antecedents
Set Fact.factList to the known facts and a Rule.ruleBase to the known rules.
soughtFact in factList?
Nominal path
Apply R.proveAntecedents()
Succeede d?
Report TRUE
Report FALSE
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Pseuodocode Example
FOR number of microseconds supplied by operator IF number of microseconds exceeds critical value Try to get supervisor's approval
IF no supervisor's approval
See section tbd for inspection results of this pseudocode
abort with "no supervisor approval for unusual duration" message ENDIF ENDIF
....
IF no supervisor's approval
See section tbd for inspection results of this pseudocode
Pseuodocode Example
abort with "no supervisor approval for unusual duration" message ENDIF ENDIF
IF power level exceeds critical value abort with "power level exceeded" message ENDIF
//p FOR number of microseconds supplied by operator for( int i = 0; i < numMicrosecs; ++I ) { //p IF number of microseconds exceeds critical value if( numMicrosecs > XRayPolicies.CRITICAL_NUM_MICROSECS ) //p Try to get supervisor's approval
int supervisorMicrosecsApproval =
getApprovalOfSuperForLongExposure(); //p IF no supervisor approval
Pseudocode Extraction
be performed
Help to trap defects before they become code Increases product reliability
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
to maintain
Introduces error possibilities in translating
to code
May require tool to extract pseudocode and facilitate drawing flowcharts
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Consider each part of the detailed design in turn: 2. Determine whether the problem has to do with (C) creating something complex, (S) representing a complex structure, or (B) capturing behavior 3. Determine whether there is a design patterns that addresses the problem
try looking in the category identified (C, S, or B)
use this book and/or Gamma et al [Ga]
Factory: Example
Factory design pattern
Client
BiologicalCell getNewCellObject()
Prototype: Example
Client
_documentPrototype
MyOfficeApplication myMethod()
.....
Document clone()
PurchaseOrderDocument clone()
InvoiceDocument clone()
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Prototype: Example
Client
MyOfficeApplication myMethod()
documentPrototypeS
Document clone()
CashCustomer clone()
PurchaseOrderDocument clone()
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
public class MyOfficeApplication { private static Document documentPrototypeS; private static Customer customerPrototypeS; ....
This class is unaware of which type (subclass) of Document or Customer it is being executed with
documentPrototypeS = dProtopypeP;
customerPrototypeS = cPrototypeP; }
public myMethod { . . . . // Need a new Document object: Document d = documentPrototypeS.clone(); . . . . // Need a new Customer object: Customer c = customerPrototypeS.clone(); . . .
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
....
{ protected Document clone(); } public class InvoiceDocument { .... protected Document clone() {. . . . return new InvoiceDocument(); }
public class PurchaseOrderDocument { .... protected Document clone() {. . . . return new PurchaseOrderDocument(); }
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Client 1..n
EncounterEnvironment Area EnvironmentFactory getArea() buildConnection()
Level3Area
Client
Area getArea() { return envFactory.getArea(); } EncounterEnvironment getArea() getConnection() incrementLevel() 1..n EnvironmentFactory getArea() getConnection()
envFactory
EncounterAreaConnection
1..n
Area
Level2Area
create
Level2AreaConnection
create
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Client 1..n
EncounterEnvironment Area EnvironmentFactory getArea() getConnection()
Level1AreaConnection
create
Level2AreaConnection
Level3AreaConnection
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
The Basis for Composite & Decorator Structures non-leaf node leaf node
Component
every object involved is a Component object non-leaf nodes have one or more components
NonLeafNode
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Decorator: 1
Leaf doIt()
NonLeafNode doIt()
component
TypeANonLeafNode doIt()
TypeBNonLeafNode doIt()
etc.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
EncounterGame
EncounterGame
EncounterCharacters
EncounterCast
EncounterEnvironment
EncounterEnvironment
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Financial
amount()
Principal
computeValue()
Client
Financial
amount()
Principal
computeValue()
Client
FinancialAdapter
amount()
legacyAdaptee
{ legacyAdaptee.computeValue(); }
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
iterator: Iterator
Aggregate of Element objects Before next() executes, iterator references this object.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Mediator
Colleague
ConcreteColleague1 ConcreteColleague2
ConcreteMediator
Gamma et al
Colleague
ConcreteColleague1 ConcreteColleague2
Current life points: 56
EncounterDisplay
Strength Endurance Endurance Intelligence Patience Value
EngagementDisplayItem
Applied to Encounter
16.18
QualListDisp QualValueDisp
SetQualitiesDisplay
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
1. Introduction 1.1. Purpose Architecture 1.2. Scope 1.3. Definitions, acronyms & abbreviations 2. References 3. Decomposition description 3.1. Module decomposition 3.1.1 Module 1 description 3.1.1 Module 2 description 3.2 Concurrent process decomposition 3.2.1 Process 1 description 3.2.2 Process 2 description 3.3 Data decomposition 3.3.1 Data entry 1 description 3.3.2 Data entry 2 description
4. Dependency description 4.1 Intermodule dependencies 4.2 Interprocess dependencies 4.3 Data dependencies 5. Interface description 5.1 Module interface 5.1.1 Module 1 description 5.1.2 Module 2 description 5.2 Process interface 5.2.1 Process 1 description 5.2.2 Process 2 description
6. Detailed design
6.1 Module detailed design 6.1.1 Module 1 detail 6.2.2 Module 2 detail 6.2 Data detailed design 6.2.1 Data entity 1 detail 6.2.2 Data entity 2 detail
Java Source with Javadoc 1/2 .. /** Character of role-playing games. @author Eric Braude @version 0.1, 7/14/98 */ public abstract class GameCharacter { /** Name of the game character; initially null */ private String _name;
/** No character name will ever exceed this length */ public final int alltimeLimitOfNameLength () .. /** For logging*/ protected void display() .. /** Accessor of _name. "defaultName" assigned if this is first-time access. */ public String getName() ..
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
/** Sets _name to aName if length is within aMaxNumChars in length; otherwise truncates. Inheritors should use this for setName( String ), but not override @param aName: proposed name for _name @param aMaxNumChars -- at which to truncate aName */ protected final void setName( String aName ) ..
..
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
1. Make sure the SDD reflects latest version of detailed design, as settled on after inspections. 2. Give complete detail to the schedule (SPMP). 3. Allocate precise tasks to team members (SPMP). 4. Improve project cost & time estimates (see below). 5. Update the SCMP to reflect the new parts. 6. Review process by which the detailed design was created, & determine improvements. Include ...
time taken; broken down to include
preparation of the designs inspection change
defect summary
number remaining open, found at detailed design, closed at detailed design where injected; include previous phases & detailed design stages
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Estimate Size & Time from Detailed Designs 1. Start with the list of methods
ensure completeness, otherwise underestimate will result
5. Ensure that your estimates of method sizes and time will be compared and saved at project end.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
CATEGORY
Very small
Small
Medium
Large
Very large
Calculation
2.34
5.13
11.25
24.66
54.04
Data
2.60
4.79
8.84
16.31
30.09
METHOD TYPE
I/O
9.01
12.06
16.15
21.62
28.93
Logic
7.55
10.98
15.98
23.25
33.83
Set-up
3.88
5.04
6.56
8.53
11.09
Text
3.75
8.00
17.07
36.41
77.67
7%
generality
enables design of similar applications?
expandability
enables enhancements?
efficiency
speed, storage
portability
Severity
Description
Urgent
High
Medium
Low None
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Severity
Major Medium
Description
Requirement(s) not satisfied Neither major nor trivial
Trivial
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Types of Defects (1) (IEEE) [PS] Logic problem (forgotten cases or steps; duplicate logic; extreme conditions neglected; unnecessary functions; misinterpretation; missing condition test; checking wrong variable; iterating loop incorrectly etc.) [PS] Computational problem (Equation insufficient or incorrect; precision loss; sign convention fault)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
1 IF aQuality is not recognized Log error to log file 2 Inform user qualities unchanged 3 4 ELSE setQuality() IF aQualityValue out of bounds should be 5 mentioned Log error to log file 6 Inform user qualities unchanged 7 ELSE 8 Set the stated quality to aQualityValue 9 Reduce the remaining qualities, 10 ... retaining their mutual proportion, Make these ... making the sum of qualities unchanged preconditions; dont check. ENDIF Lacks detail on how to allocate ENDIF the remaining quality values
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
10. Summary
Case Study
RPGame
handleEvent()
state
GameState
handleEvent()
{ state.handleEvent(); }
....
rPGameS
RPGMouseEventListener
mouseEnter()
RPGame
handleEvent()
stateS
GameState
handleEvent()
{ stateS.handleEvent(); }
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
User
eventTarget
:RPGame
:GameState
:RPGMouseEventListener
1. mouse action 2. mouseClicked()
RolePlayingGame
framework package
Characters
framework package
EncounterGame
application package
uses
EncounterCharacters uses
application package EncounterCharacter PlayerCharacter ForeignCharacter PlayerQualityWindow
EncounterGame
Engagement
EngagementDisplay
GameEnvironment
framework package
EncounterEnvironment
application package Area
uses
GameArtifacts
framework package
EncounterAreaConnection ConnectionHyperlink
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
MouseListener
EncounterGameDisplays
EncounterDisplayItem EncounterDisplay
EncounterCast
Detailed Design of EncounterGameDisplays Sub-package
QualListDispl
SetQualValueDispl
QualValueDispl Reporting
handleEvent()
EngagementDisplay
SetQualityDisplay
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Preparing
handleEvent()
User
:EngagementDisplay
:RPGMouse EventListener
2. mouseClicked()
5. setVisible( false )
6. setState (new Waiting())
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
:RPGMouse EventListener
2. mouseClicked()
:EncounterGame
3. handleEvent()
4. handleEvent()
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
User :AreaConnectionHyperlink
1. hit area connection hyperlink
:EncounterCast
:Waiting
:RPGMouse EventListener
2. mouseClicked()
:EncounterEnvironment :EncounterGame
3. handleEvent() 4. handleEvent() 6. displayArea() 7. displayPlayerCharacter()
5. setVisible( false )
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
GameCharacter
EncounterCharacters
application package
EncounterCharacter
facade
PlayerCharacter
EncounterCast ForeignCharacter
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
EncounterEnvironment Package
GameEnvironment GameArea GameAreaConnection
GameCharacter
....
EncounterEnvironment Package
GameEnvironment GameArea GameAreaConnection GameCharacter
Area EncounterEnvironment
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.