Software Engineering Roadmap: Chapter 6 Focus

1
Software Engineering Roadmap Chapter 6 Focus
Develop Architecture - see chapter 5
Identify corporate practices
Perform Detailed Design - apply design patterns
- accommodate use cases supply methods -
exploit libraries (STL, Java, ) - describe
methods where required - develop detailed
object models - develop other models
Plan project
Analyze requirements
Maintain
Integrate test system
Design
Test units
Implement
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
2
Typical Roadmap for Detailed Design

• 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
4. Specify class invariants -- section 3.1
For each class ...
5. Specify methods with pre- and post-conditions,
flowcharts pseudocode -- sections 3 and 4
For each method ...
6. Sketch unit test plans -- see chapter 8
For each unit ...
7. Inspect test plans design -- section 9
if applicable
8.Release for implementation
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
3
Organize the Team for Detailed Design 1/2
One way to ...

• 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
• Ensure team members aware of the notation
  expected
• typically UML plus a pseudocode standard and/or
  example
• 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.
4
Organize the Team for Detailed Design 2/2
One way to ...

• 2. Hold the kick-off meeting
• 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
• revise as a group if not
• Dont try to develop detailed designs as a group
• not necessary individuals have the
  responsibility
• groups are seldom good at designing details
  together
• Allocate modules to members
• Request time estimates to design lead by a fixed
  date
• Write out the conclusions and copy/e-mail every
  member
• Decide how and when the results are to be
  reviewed
• 3. Update the documentation set
• more detailed schedule with modules inspections
• 4. Inspect the detailed designs
• see figure TBD below
• 5. Rework as a result of inspections
• 6. Conduct post mortem and write out lessons
  learned

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
5
Unified Software Development Process Design
Inception
Elaboration
Construction
Transition
U. P. Term Requirements Analysis Design Imp
lemen- tation Test (Jacobson et al)
1
Jacobson et al
2
3
Prelim. iterations
Iter. 1
Iter. n
Iter. n1
Iter. m
Iter. m1
Iter. k
..
..
Key terminology used in this book
Detailed design
1
3
2
Requirements
Achitecture
6
Analysis
Design
1/2
After Jacobson et al USDP

• 1. Conceptual abstract
• 2. Applicable to several designs
• 3. control, entity boundary stereotypes
• 4. Less formal
• 5. Less expensive to develop

• 1. Concrete implementation blueprint
• 2. Specific for an implementation
• 3. No limit on class stereotypes
• 4. More formal
• 5. More expensive to develop (? 5)

7
Analysis
Design
2/2
After Jacobson et al USDP

• 6. Outlines the design
• 7. Emerges from conceptual thinking
• 8. Lower priority for in-process maintenance
• 9. Relatively unconstrained
• 10. Less focus on sequence diagrams
• 11. Few layers

• 6. Manifests the design (architecture one view)
• 7. May use tools (e.g. visual, round-trip
  engineering)
• 8. Higher priority for in-process maintenance
• 9. Constrained by the analysis architecture
• 10. More focus on sequence
• 11. Many layers

8
Designing Against Interfaces
Client code
Used code
Abstract layer
Customer bill() printAccounts()
BillingClient listCustomers() billCustomers()
-- written in terms of Customer (not specific
types of Customer)
Concrete (non-abstract) layer
RegularCustomer bill() printAccounts()
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
9
Refine Models for Detailed Design1/2 Sequence
Diagrams
One way to ...

• 1. Begin with the sequence diagrams constructed
  for detailed requirements and/or architecture (if
  any) corresponding to the use cases.
• 2. Introduce additional use cases, if necessary,
  to describe how parts of the design typically
  interact with the rest of the application.
• 3. Provide sequence diagrams with complete
  details
• be sure that the exact objects their classes
  are specified
• select specific function names in place of
  natural language
• (calls of one object to another to perform an
  operation)

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
10
Classes of the EncounterForeignCharacter Use Case
EngagementDisplay displayResult()
Engagement execute()
EncounterGame
PlayerCharacter setQuality()
EncounterCast displayForeignChar() setPlayerQualit
y() setForeignQuality()
ForeignCharacter setQuality()
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
11
Sequence Diagram for Encounter Foreign Character
Use Case
engagement Engagement
Encounter game
freddie Foreign Character
Encounter Cast
1.1 displayForeignChar()
Engagement Display
1.2 display()
1.3 new Engagement()
2. execute()
Players main character
2.1 setPlayerQuality()
2.2 setQuality()
2.3 setForeignQuality()
3.1 new EngagementDisplay()
2.4 setQuality()
3.2 displayResult()
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
12
Classes at Detailed Design
Canister
Class name
numCanisters int - numWafers int - size
float
Attribute type
visible from without
display() - getNumSlotsOpen() setStatus()
Operations
Responsibilities -- describes each canister
undergoing fabrication
Place for comments
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
13
Specifying Functions withdraw() in Account
Invariant of withdraw() availableFundsI max(
0, balanceI ) Precondition withdrawalAmountP gt
0 AND
balanceI - withdrawalAmountP gt
OVERDRAFT_MAX Postcondition balanceI'
balanceI - withdrawalAmountP
xI denotes an attribute xP denotes a function
parameter x' is the value of x after
execution X denotes a class constant
The function invariant is an additional pre- and
post-condition
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
14
Apply Design Patterns in Detailed Design
One way to ...

• 1. Become familiar with the design problems
  solved by design patterns
• at a minimum, understand the distinction among
  (C) creational vs. (S) structural vs. (B)
  behavioral patterns
• 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
• 4. Decide if benefits outweigh drawbacks
• benefits usually include increased flexibility
• drawbacks increased class complexity(?), less
  efficient(?)

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
15
Factory Example
Factory design pattern
BiologicalCell getNewCellObject()
Client
AnimalCell getNewCellObject()
PlantCell getNewCellObject()
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
16
Prototype Example
Client
Document clone()
documentPrototypeS
MyOfficeApplication myMethod()
Customer clone()
customerPrototypeS
CashCustomer clone()
CreditCustomer clone()
PurchaseOrderDocument clone()
InvoiceDocument clone()
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
17
Prototype Design Pattern Typical Code 1/2
public class MyOfficeApplication private static
Document documentPrototypeS private static
Customer customerPrototypeS public
MyOfficeApplication ( Document dProtopypeP,
Customer cPrototypeP ) documentPrototypeS
dProtopypeP customerPrototypeS
cPrototypeP public myMethod . . . . //
Need a new Document object Document d
documentPrototypeS.clone() . . . . // Need a
new Customer object Customer c
customerPrototypeS.clone() . . .
This class is unaware of which type (subclass)
of Document or Customer it is being executed
with
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
18
Prototype Design Pattern Typical Code 2/2
abstract class Document protected Document
clone()
public class InvoiceDocument . . . .
protected Document clone() . . . . return new
InvoiceDocument()
Customer has an equivalent hierarchy of
classes implementing clone()
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.
19
The Basis for Composite Decorator Structures
leaf node
non-leaf node


Component
non-leaf nodes have one or more components
every object involved is a Component object
NonLeafNode
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
20
Composite Decorator Structures
Component doIt()
Composite 1..n
Client
Decorator 1
for all elements e in component e.doIt()
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.
21
Adapter Design Pattern
Legacy system
Adaptation
Application
Financial amount()
Principal computeValue()
FinancialAdapter amount()
legacyAdaptee
Client
legacyAdaptee.computeValue()
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
22
The Iterator Design Pattern
Key Intended sequence of Element objects
element Element
Aggregate of Element objects
After first() executes, iterator references this
object.
iterator Iterator
Before next() executes, iterator references this
object.
After next() executes, iterator references this
object.
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
23
The Mediator Design Pattern
Encapsulates behavior among objects of a class so
that they neednt refer to each other.
Colleague
Mediator
ConcreteColleague1
ConcreteColleague2
ConcreteMediator
Gamma et al
24
The Mediator Design Pattern
Colleague
Mediator
ConcreteMediator
ConcreteColleague1
ConcreteColleague2
EncounterDisplay
EngagementDisplayItem
Applied to Encounter
QualListDisp
QualValueDisp
SetQualitiesDisplay
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.