Object-Oriented Programming

Software Design

Michael L. Collard, Ph.D.

Department of Computer Science, The University of Akron

Scale of Software Systems

Layers of a System

  • System
  • Subsystem
  • Namespace/Directory
  • Class/File
  • Method/Function
  • Statement

Design Definition

Software design is the process of defining software methods, functions, objects, and the overall structure and interaction of your code so that the resulting functionality will satisfy user requirements¹

  • A process
  • Defining software methods, …
  • Defining overall structure
  • Defining interaction of code
  • Result will satisfy user requirements

Software Activities

OOP View of Software Development

Design Explanation

Software design is the process by which an agent creates a specification of a software artifact, intended to accomplish goals, using a set of primitive components and subject to constraints.²

  • An agent
  • Creates a specification
  • software artifact
  • Intent is to accomplish goals
  • Uses primitive components
  • Subject to constraints

Design Explanation

Software design may refer to either "all the activity involved in conceptualizing, framing, implementing, commissioning, and ultimately modifying complex systems" or "the activity following requirements specification and before programming, as … [in] a stylized software engineering process."³

  • Activities: conceptualizing, framing, implementing, commissioning, modifying
  • Activity after requirements specification
  • Activity before programming

Design Explanation

Software design usually involves problem-solving and planning a software solution. This includes both a low-level component and algorithm design and a high-level, architecture design.

  • Involves problem-solving
  • Planning a software solution
  • Includes low-level component design
  • Includes algorithm design
  • Includes high-level architecture design

Design Levels

  • High-Level Design (HLD)
    • Close to Analysis
    • Overall system design
    • Includes Software Architecture
    • Represents solutions to requirements
  • Low-Level Design (LLD)
    • Close to Code
    • Detailed description of every module
    • Expressed in the design of the classes and methods

Layers of Design

  • System
  • Subsystem
  • Namespace/Directory
  • Class/File
  • Method/Function
  • "Hunks" or individual statements

Types of Design

  • structured design
    • From structured programming
    • What are the functions?
  • object-oriented design
    • From object-oriented programming
    • What are the classes?

Class Design: Individual Class

  • What classes exist
  • Identifiers (names) of the classes
  • Methods of each class:
    • Name
    • Parameters
    • Return Type
    • (Method) Specifiers: const, static, virtual, final, override, and friend
    • Access: public, private, protected

Class Design: Class Relationships

Relationship UML Model
Bidirectional Association
Generalization (Inheritance)

Target Audience for Design Decisions

  • You, as a developer
  • Other developers
  • You in a few months
  • Other developers in a few months
  • Future developers

Informally, what indicates a good design?

  • Easy to add features
  • Easy to determine the source of bugs
  • Easy to fix bugs
  • Has the required efficiency
  • Has the required security
  • Handles errors safely

Why does bad design occur?

  • Design primarily involves making choices between tradeoffs
  • Design decisions are often made before the problem is fully understood
  • Incomplete knowledge by current and previous software engineers
  • Requirements changes since the design was made
  • Security requirement changes since the design was made

Features of Good Design

  • Consistent with a shared vocabulary
  • Simplicity
  • Clear roles
  • High cohesion
  • Low coupling

Design Example: MethodCount

Count the number of methods per class for a software system written in C++

  • Input the software system (files, directories, fragments)
  • Parse the source code into some form so we can process it
  • Count the methods in the parsed form

Design Choices

  • MethodCount-AllInOne
  • MethodCount-Internal
  • MethodCount-External
  • MethodCount-Parser

Design Choice: Internal Input & Parsing


  • Method count() must do all the input, parsing, and counting
  • Difficult to generalize as there is limited space for parameters
  • For Users, if flexibility is not needed, then this is the easiest-to-use

Design Choice: Internal Parsing


  • Separate input()
  • Method count() does all the parsing and counting
  • Users do not have to concern themselves with parsing

Design Choice: Separate Interfaces


  • Each part has its own method, input(), parse(), and output()
  • Lots of flexibility for users
  • But more complex to use

Design Choice: Separate Parser


  • Ultimate flexibility for users
  • But again, introduce complexity
  • But the complexity may be needed

Design Choices

  • MethodCount-AllInOne
  • MethodCount-Internal
  • MethodCount-External
  • MethodCount-Parser

Layers of Design

  • System
  • Subsystem
  • Namespace/Directory
  • Class/File
  • Method/Function
  • Statement

Software Design

  • Software design is a skill
  • Requires deciding between tradeoffs, e.g., complexity vs. efficiency, etc.
  • Requires knowing alternatives at a high level and language features to support the design at a low level
  • Needs to clearly and cleanly implement the design, so code consistency, standards, and documentation are essential
  • Is an iterative process that requires exploring alternatives as requirements and the environment changes