0% found this document useful (0 votes)
3 views8 pages

Software Design Engineering Notes

The document provides comprehensive study notes on software engineering, focusing on the transition from analysis models to design models, fundamental design concepts, and various design approaches such as Object-Oriented Design (OOD), Function-Oriented Design (FOD), and Service-Oriented Design (SOD). It emphasizes key principles like modularity, information hiding, and functional independence, which contribute to maintainable and scalable software. Additionally, it outlines the detailed design phase, including key activities and deliverables necessary for precise implementation.

Uploaded by

raymondholt764
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3 views8 pages

Software Design Engineering Notes

The document provides comprehensive study notes on software engineering, focusing on the transition from analysis models to design models, fundamental design concepts, and various design approaches such as Object-Oriented Design (OOD), Function-Oriented Design (FOD), and Service-Oriented Design (SOD). It emphasizes key principles like modularity, information hiding, and functional independence, which contribute to maintainable and scalable software. Additionally, it outlines the detailed design phase, including key activities and deliverables necessary for precise implementation.

Uploaded by

raymondholt764
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Design Engineering

Comprehensive study notes — Software Engineering, Slide Set 8 | CSED, TIET Patiala

Contents
1. From Analysis Model to Design Model
2. Fundamental Design Concepts
3. Types of Abstraction
4. Modularity, Information Hiding & Functional Independence
5. Separation of Concerns (SoC)
6. Design Approaches: OOD, FOD, SOD
7. Detailed Design — Key Activities & Deliverables
1. From Analysis Model to Design Model

The analysis model captures what the system must do. The design model describes how it will be built.
Every element of the analysis model feeds information into one or more of the four design layers.

Key idea: Analysis → Design is a transformation, not a one-to-one copy. The four design models are built
from four types of analysis elements: scenario-based, flow-oriented, class-based, and behavioral.

Data / Class Design Architectural Design


Transforms analysis classes into design classes Defines the overall structure and the relationships
and defines the data structures required to between major structural elements. Uses
implement the software. architectural styles and design patterns to meet
[Class-based model] [Behavioral model] system requirements.
[Class-based model] [Flow-oriented model]

Interface Design Component-Level Design


Describes how the software communicates with Transforms structural architecture elements into a
external systems it interoperates with and with the procedural (step-by-step) description of individual
humans who use it. software components.
[Scenario-based] [Flow-oriented] [Behavioral] [Class-based] [Flow-oriented] [Behavioral]

Analysis model element types


Element type Includes

Scenario-based Use-cases (text), use-case diagrams, activity diagrams, swim lane diagrams

Flow-oriented Data flow diagrams, control-flow diagrams, processing narratives

Class-based Class diagrams, analysis packages, CRC models, collaboration diagrams

Behavioral State diagrams, sequence diagrams


2. Fundamental Design Concepts

Eight core principles form the foundation of good software design. Understanding and applying these
consistently leads to software that is maintainable, scalable, and intellectually manageable.

Abstraction Architecture
Focusing on essential characteristics while The overall structural framework — its
suppressing irrelevant detail. Comes in three components, connectors, and the relationships
forms: data abstraction, procedural abstraction, between them — that gives the system
and control abstraction. conceptual integrity.

Patterns Modularity
Proven, reusable design solutions for recurring Dividing software into separately named,
problems in a specific context. Provides a addressable components (modules). Applies the
template that can be applied or adapted across "divide and conquer" principle to make complexity
different projects. intellectually manageable.

Information Hiding Functional Independence


Designing modules so their internal algorithms Each module has one clearly defined job (high
and local data structures are inaccessible to other cohesion) and minimal connections to other
modules. Enforces access through controlled modules (low coupling). Reduces unintended
interfaces only. side-effects of changes.

Stepwise Refinement Refactoring


Progressively elaborating a program from Reorganizing/simplifying a component's internal
high-level abstractions down to fine design without changing its external behavior.
implementation detail. Complements abstraction Removes redundancy, dead code, and inefficient
— design top-down, refine bottom-up. structures.
3. Types of Abstraction

Abstraction is the ability to concentrate on essential features while ignoring lower-level detail. It is one of the
most powerful tools in software design.

Data Abstraction
A named collection of data that describes a data object. You define all relevant attributes of a real-world
concept and implement it as a data structure, hiding how those attributes are stored.
Example — a door: Instead of thinking about physical materials, data abstraction models it as:
manufacturer, model number, type, swing direction, inserts, lights (type, number), weight, opening
mechanism. The concept 'door' becomes a usable data structure.

Procedural Abstraction
A named sequence of instructions that performs a specific, limited function. The caller uses it by name
without needing to know the internal steps.
Example — 'open': The word implies a whole sequence (grasp handle, turn, push/pull). As a procedural
abstraction it hides those steps — the caller just invokes open(door) and the details are handled internally.

Control Abstraction
Hides the flow-control mechanism of a program. For example, using a loop construct like 'for each item
in list' without worrying about the underlying iteration counter logic.

Key relationship: Abstraction and stepwise refinement work together. Abstraction lets you define procedure
and data at a high level while suppressing detail. Refinement then progressively adds that detail, layer by
layer.
4. Modularity, Information Hiding & Functional Independence

Modularity
Breaking software into separately named, addressable components. Each module should be small enough
to be mentally manageable but large enough to justify its existence.
The trade-off: There is an optimal number of modules for any given system. Too few modules → each is
large and complex, development cost rises. Too many modules → integration cost explodes (too many
interfaces to manage and test). The optimum is where total cost (development + integration) is minimized.

Information Hiding
Module internals (algorithms, local data structures) are hidden behind a clean interface. Other modules
interact only through that interface — they cannot directly access or modify internal data.
Why it matters: Changes inside a module do not break other modules, as long as the interface stays the
same. Forces developers to consciously decide what a module exposes vs what it keeps private. In OOP,
implemented via access modifiers like private and protected.

Functional Independence
Each module does exactly one well-defined job and avoids excessive interaction with other modules.
Measured by two complementary properties:

Property Meaning Goal

High Cohesion All code in a module works together to perform a single task. Nothing
MAXIMIZE
unrelated is mixed in.

Low Coupling Modules share as little information as possible. Changes in one rarely
MINIMIZE
force changes in another.

5. Separation of Concerns (SoC)

A foundational principle: each part of the system should address one specific aspect of functionality, with
minimal overlap between parts.

Modularization Encapsulation
The system is divided into modules, each with a Each module encapsulates its data and logic,
well-defined purpose. These modules have hiding the internal workings from other parts of
minimal overlap in their responsibilities. the system. Changes within a module do not
affect others.
6. Design Approaches: OOD, FOD, SOD

Object-Oriented Design (OOD)


Organizes code around objects that bundle data (attributes) and behavior (methods) together.
• Objects model real-world entities — e.g. a car has color, make, model (data) and can accelerate, brake,
turn (methods).
• Classes group related objects; inheritance lets child classes reuse parent properties and behavior.
• Promotes code reuse and reduces redundancy.
Common languages: Java, C++, Python, C#

Function-Oriented Design (FOD)


Structures code around functions — independent, self-contained blocks that perform specific tasks.
• Programs are decomposed into smaller, manageable functions.
• Each function has a clearly defined input and output, making it easier to understand, test, and reuse.
Common languages: C, Pascal, Fortran

Service-Oriented Design (SOD)


Organizes functionality as independent services that communicate over a network using standardized
protocols.
• Services are self-contained mini-applications with well-defined interfaces — think of them as mini-apps
accessible by other apps.
• Loose coupling: services are independent; one can change without breaking others.
• Highly scalable and flexible — ideal for large distributed systems.
Examples: REST APIs, Microservices architecture
7. Detailed Design — Key Activities & Deliverables

The detailed design phase takes high-level architectural decisions and refines them into precise,
implementable specifications that developers can directly code from.

Key Activities

Module Decomposition Functional Allocation


High-level components from earlier design Each module is assigned specific functionalities
phases are broken down into smaller, more and responsibilities. Ensures no function is
manageable modules with clear boundaries and duplicated and every function has a clear owner.
interfaces.

Data Design Algorithm Selection


Data structures, types, and storage mechanisms Specific algorithms are chosen for each function,
for each module are defined. Includes how data is balancing efficiency, correctness, and suitability
passed between modules. for the task at hand.

User Interface (UI) Design


For systems with user interfaces: UI elements are
defined, interaction flows are laid out, and data
flow between UI and back-end modules is
specified.

Deliverables
Deliverable Description

Module Specifications Detailed documents covering each module's functionalities, interfaces, data
structures, and algorithms. The primary technical reference for developers.

Data Flow Diagrams (DFDs) Visual representations showing how data moves through the system — interactions
between modules and external entities.

Sequence Diagrams Illustrate the ordered sequence of interactions between objects or modules during a
specific operation or use case.

Class Diagrams (OOD) In object-oriented design: depict the classes, their attributes and methods, and the
relationships (associations, inheritance) between them.

Pseudocode An informal, code-like language that outlines the logic and algorithms used in specific
sections. Readable by both developers and non-developers.
Remember: The goal of detailed design is to produce documentation precise enough that any competent
developer could implement the system correctly — without needing to make fundamental design decisions
themselves.

You might also like