Software Design

1
Software Design

• CS 123/CS 231

2
What is Design?

• Design is the activity of specifying a solution
  to a problem
• Contrast this against other software engineering
  phases
• Analysis understanding and specifying the
  problem (requirements)
• Implementation system construction

3
Stages in SW Design

• Architectural Design
• Abstract Specification
• Interface Design
• Component Design
• Detailed Design
• Reference Sommerville, Chapter 12

4
Architectural Design

• Identify Subsystems and Modules
• Example Program Submission System
• Server
• Teacher Interface
• Student Interface

5
Architectural Design, continued

• Design information provided is minimal
• System is simply decomposed into interacting
  subsystems or modules
• Depicted using a block diagram
• subsystems rectangles
• arrows represent interaction / flow of data and
  control / dependency between the subsystems

6
Abstract Specification

• Identify services and constraints per subsystem
• Example Server
• set up a class
• set up a project
• submit a program
• Note descriptions of services are informal

7
Interface Design

• Per subsystem, specify its interface
• collection of available functions/methods for use
  by other subsystems
• Consistent with Encapsulation
• Example Server
• function set_up_class
• parameters catnum, section, list of students
  (ids and names)

8
Interface Specification

• Services per subsystem are formally specified
• Goal provide unambiguous information regarding
  extent of external interaction
• parameters/inputs, return values/outputs
• Design and implementation details of the
  subsystem are still hidden

9
Component Design

• Within a subsystem
• determine components
• per component, identify services/interfaces
• Understand interaction between components at the
  level of the subsystem
• OO Design components are classes
• Design models (using the UML, for example) are
  most useful at this level

10
Detailed Design

• Specify data structures and algorithms (for
  methods) of the individual components (classes)
• Generally still implementation-independent
• Although though in practice, specific language
  features are used
• Techniques Pseudocode, flowcharts, others

11
Design Quality

• Cohesion
• Coupling
• Understandability
• Adaptability
• Reference Section 12.3 of Sommerville

12
Cohesion

• Extent of relationship between parts of a
  component
• High cohesion is desirable
• Single logical t (or theme)
• all parts should contribute to the function
• Levels of cohesion (p. 218)
• coincidental cohesion (weakest)
• functional cohesion (strongest)

13
Coupling

• Dependence between units of a subsystems or
  components
• High coupling generally undesirable
• units fully depend on each other
• sensitive to change
• convenient/necessary only for small components

14
Understandability

• Cohesion and Coupling
• understanding a component independently
• Naming
• reflects real-world intuition
• Documentation
• Complexity
• algorithms

15
Adaptability

• Sensitivity to change
• are changes in design easy?
• Loosely coupled components
• Self-contained components

16
Object-OrientedDesign Notation

• CS 123/CS 231

17
References

• Main Reference UML Distilled, by Martin Fowler
• Chapters 3, 4, 6, and 8
• Supplementary References
• Chapter 14 of Sommerville
• Chapter 22 of Pressman

18
Component Design and Detailed Design

• Component Design
• For each subsystem determine components, and
  services/interface per component
• OO Design components are classes
• Detailed Design
• Determine attributes of classes and relationships
  between the classes
• Determine functionality of each class and
  interactions between classes

19
Object-Oriented Modeling

• UML Unified Modeling Language
• Emerging OO Modeling Standard
• Booch, Jacobson, Rumbaugh
• What is depicted?
• Class details and static relationships
• System functionality
• Object interaction
• State transition within an object

20
Some UML Modeling Techniques

• Class Diagrams
• Use Cases/Use Case Diagrams
• Interaction Diagrams
• State Diagrams

21
ExampleClass Diagram
FFCounter totalcash totalorders
PriceChecker getPrice()
pc
counters
5
FastFood Restaurant
22
ExampleUse Case Diagram
LIBRARY SYSTEM
Facilitate Checkout
Search for Book
Borrower
Librarian
Facilitate Return
23
ExampleInteraction Diagram
2 checkIfAvailable()
Checkout Screen
Book
1 checkIfDelinquent() 3 borrowBook()
4 setBorrower()
Borrower
24
ExampleState Diagram (Book)
start
Reserved
Borrowed
New
Librarian activates book as available
Borrower returns book
Available
25
Object-Oriented Design Models

• Static Model
• Class Diagrams
• Dynamic Model
• Use Cases, Interaction Diagrams, State Diagrams,
  others

26
OO Static Model

• Classes and Class Diagrams
• Relationships
• Association
• Aggregation/Composition
• Inheritance
• Dependencies
• Attribute and Method names

27
OO Dynamic Model

• Goal Represent
• Object behavior
• Object interaction
• Traditional/Procedural Dynamic Modeling
• Data Flow Diagrams (DFDs)
• Problem Processes separate from data
• Need modeling notation that highlight tight
  relationship between data processes

28
DFD Example(Inventory Management)
Accept and Post Delivery
Delivery info
Transaction
Item Master
29
OO CounterpartObject Interaction
new (delivery info)
Encoder
Transaction
post (item count)
Item Master
30
Building anOO Dynamic Model

• Identify use cases
• Describe each use case through an interaction
  diagram
• For more complex objects, provide a state diagram
  per class
• Derive implied methods (and attributes)

31
Whats Next?

• Need to understand the notation
• Make sure it helps the software development
  process
• When to use the UML techniques
• Primarily when specifying OO design
• Formal means of communication across the
  different software development stages