Software Design

1
Software Design

• AITI GP
• John Paul Vergara

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
Goal of Software Design

• To achieve sufficient agreement on interface
  definition and internal structure that
  implementation may proceed in parallel teams.

4
Stages in SW Design

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

5
Architectural Design

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

6
Architectural Design, continued

• Design information provided is minimal
• System is simply decomposed into interacting
  subsystems or modules
• Making global and local decisions about planned
  implementation based on constraints,
  non-functional requirements and available
  alternatives
• Has general applicability

7
Obvious areas of concern for architectural
design

• Structure
• Communication
• Distribution
• Persistence
• Security

• Error Handling
• Recovery
• Use or Reuse of existing hardware and software
  configurations

8
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

9
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)

10
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

11
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

12
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

13
Design Work Products

• System Architecture
• Application Programming Interfaces
• Target Environment (addressing non-functional
  requirements)
• Subsystem Model
• Design Object Model - static model representing
  structure of classes and relationships with each
  other

14
Design Work Products continued...

• Design Object Interaction Diagrams - graphically
  depict collaborations between objects
• Design State Models - represent dynamic behavior
  of design classes and are done for all classes
  that have strong state dependent object behavior

15
Design Quality

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

16
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)

17
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

18
Understandability

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

19
Adaptability

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

20
Object-OrientedDesign Notation

• CS 123/CS 231

21
References

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

22
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

23
Object-Oriented Modeling

• UML Unified Modeling Language
• OO Modeling Standard
• Booch, Jacobson, Rumbaugh
• UML is used to visualize, specify, construct and
  document the artifacts of a software intensive
  system

24
Building Blocks of the UML

• Things
• the abstractions
• Relationships
• tie the things together
• Diagrams
• group interesting collections of things

25
UML Diagrams

• What is depicted?
• Class details and static relationships
• System functionality
• Object interaction
• State transition within an object

26
Some UML Modeling Techniques

• Class Diagrams
• Use Cases/Use Case Diagrams
• Interaction Diagrams
• Sequence Diagrams
• Collaboration Diagrams
• State Diagrams
• Activity Diagram

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

• Static Model interested in the structure
• Class Diagrams
• Dynamic Model interested in the behavior
• Use Cases, Interaction Diagrams, State Diagrams,
  others

32
OO Static Model

• Classes and Class Diagrams
• Names (attributes and methods)
• Visibility(private,public,protected)
• Scope (abstract, concrete)
• Relationships
• Dependency change to one affects the other
• Association (includes aggregation and
  composition) structural relationship describing
  connection between the objects

33
Relationships continued...

• Generalization inheritance
• Realization a classifier specifies a contract
  that another classifier guarantees to carry out
  (e.g., interfaces and classes that realize them)

34
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

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

• Identify use cases
• Describe each use case through an interaction
  diagram
• For state dependent objects, can provide state
  diagrams
• Derive implied methods (and attributes)
• Define flow of control, sequence of messages

38
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