Software Design

Document Sample
Software Design Powered By Docstoc
					Software Design

    AITI GP

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

To achieve sufficient agreement on
 interface definition and internal structure
 that implementation may proceed in
 parallel teams.
Stages in SW Design

Architectural Design
Abstract Specification
Interface Design
Component Design
Detailed Design

*Reference: Sommerville, Chapter 12
Architectural Design

Identify Subsystems and Modules
Example: Program Submission System
  Server
  Teacher Interface
  Student Interface
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
“Obvious” areas of concern
for architectural design

Structure       Error Handling
Communication   Recovery
Distribution    Use or Reuse of
Persistence      existing hardware and
Security         software
                  configurations
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
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)
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
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
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
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
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
Design Quality

Cohesion
Coupling
Understandability
Adaptability

*Reference: Section 12.3 of Sommerville
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)
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
Understandability

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

Sensitivity to change
  are changes in design easy?
Loosely coupled components
Self-contained components
Object-Oriented
Design Notation

CS 123/CS 231
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
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
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
Building Blocks of the UML


Things
  the abstractions
Relationships
  tie the “things” together
Diagrams
  group interesting collections of things
UML Diagrams

What is depicted?
  Class details and static relationships
  System functionality
  Object interaction
  State transition within an object
Some UML Modeling
Techniques

Class Diagrams
Use Cases/Use Case Diagrams
Interaction Diagrams
  Sequence Diagrams
  Collaboration Diagrams
State Diagrams
Activity Diagram
Example:
Class Diagram
      FFCounter
       totalcash    pc   PriceChecker
      totalorders
                          getPrice()

   counters   5




       FastFood
       Restaurant
Example:
Use Case Diagram
                LIBRARY SYSTEM



               Facilitate Checkout


   Librarian                                 Borrower
                           Search for Book



                 Facilitate Return
Example:
Interaction Diagram
                    2: checkIfAvailable()
     Checkout
                                             :Book
      Screen

           1: checkIfDelinquent()
           3: borrowBook()

                               4: setBorrower()

     :Borrower
Example:
State Diagram (Book)

   start
                          Reserved



             New                            Borrowed


    Librarian activates               Borrower returns book
    book as available     Available
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
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
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)
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
DFD Example
(Inventory Management)



   Delivery info
                   Accept and Post
                      Delivery
                                              Transaction




                                     Item Master
OO Counterpart:
Object Interaction
                new (delivery info)
     Encoder                            :Transaction




                                      post (item count)



               :Item Master
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
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

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:3/28/2013
language:English
pages:38