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 (id#’s 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 Naming Documentation
understanding a component independently
Naming
reflects real-world intuition
Documentation
Complexity
algorithms

19. Adaptability Sensitivity to change Loosely coupled components
are changes in design easy?
Loosely coupled components
Self-contained components

20. Object-Oriented Design 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
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. Example: Class Diagram
FFCounter
totalcash
totalorders
PriceChecker
getPrice() pc
counters 5
FastFood
Restaurant

28. Example: Use Case Diagram
LIBRARY SYSTEM
Facilitate Checkout
Search for Book
Borrower
Librarian
Facilitate Return

29. Example: Interaction Diagram
2: checkIfAvailable()
Checkout
Screen
:Book
1: checkIfDelinquent()
3: borrowBook()
4: setBorrower()
:Borrower

30. Example: State 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 Relationships
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 Counterpart: Object Interaction
new (delivery info)
Encoder
:Transaction
post (item count)
:Item Master

37. Building an OO 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. What’s 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