Software Design?

 Iterative translation of requirements into a high-level blueprint, progressively refined

into detailed plans.
 Starts with holistic abstraction, directly traceable to requirements; evolves into low-
level designs (e.g., data structures, detailed component behavior).

Core Goals of High-Quality Design

According to McGlaughlin, a robust design must:

1. Fully implement explicit requirements and capture implicit stakeholder needs.

2. Be readable and understandable for developers, testers, and maintainers.
3. Provide a complete picture—covering data, functional, and behavioral perspectives
through an implementation view.

Achieving these requires design principles, a systematic methodology, and rigorous reviews.

Key Design Quality Guidelines

To assess and drive quality, adhere to these guidelines:

1. Meaningful Architecture
o Built using known styles/patterns
o Consists of well-designed components
o Evolvable—supports iterative implementation and testing
2. Modularity
o Clearly partition the system into cohesive, logical subsystems
3. Multiple Representations
o Capture separate views of data, architecture, interfaces, and components
4. Appropriate Data Structures
o Choose structures aligned with target classes and derived from recognized
patterns
5. Functional Cohesiveness
o Components should encapsulate independent, well-defined functionalities
6. Interface Simplicity
o Interfaces should minimize complexity in inter-component and external
interactions
7. Traceable, Repeatable Methods
o Derive designs via repeatable methods rooted in requirement analysis
8. Effective Notation
o Use clear, expressive modeling notations (e.g., UML, structured diagrams)

Technical Reviews – Ensuring Design Quality

Because software isn’t executable at design time, use Technical Reviews (TRs) to catch issues
early:

 Participants (2–4):
o Review leader: sets agenda, directs discussion
o Recorder: documents findings
o Producer(s): creators of the design under review
o Other reviewers: peers who pre-read design artifacts
 Process:
o Pre-meeting: reviewers individually analyze the design artifact
o Meeting (60–90 mins): discuss errors, omissions, ambiguities
o Post-meeting: decide on required revisions before approval

These reviews are crucial risk-reducing checkpoints.

The Evolution of Design Methods

Design practices have evolved considerably:

Era Focus Key Methods

1970s Structured, top-down modular design DeRemer (1973), Wirth (1971), Dahl (1972)
Object-oriented design & architectural Jacobson (1992), Gamma et al. (1995),
1990s
patterns Kruchten (2006)
Aspect-oriented, Model-driven, Test-
2000s+ Clarke (2005), Schätz (2006), Astels (2004)
driven
Search-based software engineering
2010s+ Harman (2012)
(SBSE)
2010s+ Variability-intensive systems Gall et al. (2016)

Despite method differences, all incorporate:

1. Mapping requirements to design

2. Notations for components and interfaces
3. Heuristics for refinement
4. Quality assessment processes

Takeaways: Your Action Plan

1. Begin with high-level abstraction, map designs to requirements.
2. Apply design principles (e.g., modularity, clear interfaces).
3. Use familiar design patterns/styles and notational clarity.
4. Iterate and modularize, enabling phased implementation and testing.
5. Continuously review & refine via TRs before moving to coding.
6. Stay adaptive—embrace modern paradigms (OO, MDD, TDD, SBSE) as appropriate.
 Design Concepts

1. Abstraction 🧠
Definition: Simplifying complexity by focusing on essential features and hiding implementation
details Course Hero+1SDE Coursepack+1.

 Procedural Abstraction: Treat functions/methods as black boxes defined by their names

(e.g., useCamera() hides elaborate internal steps).
 Data Abstraction: Define abstract entities (e.g., Camera with id, zoom, location) while
hiding internal representation.
Benefits: Keeps code portable, reusable, and easier to reason about
Reddit+3BrightHub+3Sentenz+3.

2. Refinement (Stepwise Refinement)

Definition: Breaking a high-level function or specification progressively into more detailed,
implementable steps .

 Complements Abstraction: One hides detail, the other reveals it in stages.

Example:

scss
CopyEdit
checkout():
validateCart()
calculateTotal()
authorizePayment()
saveOrder()
sendConfirmation()

Each step can be further refined into sub-methods.

3. Modularity & Separation of Concerns

Definition: Dividing a system into independently developed, testable units, each handling
distinct concerns Reddit+2SDE Coursepack+2CSL SRI+2.

 Achieved through clear interfaces and data encapsulation.

Key Properties Reddit+7Reddit+7Develop N Solve+7:

1. Decomposability – break down problems.

2. Composability – assemble modules back.
3. Understandability – each module is clear and focused.
4. Continuity – changes in one module won’t shatter others.
5. Protection – isolate failures to their modules.
4. Information Hiding & Encapsulation
Definition: Restricting visibility of a module’s internal details to prevent external code from
depending on them GeeksforGeeks+1BrightHub+1.

 Encapsulation binds data + methods, enforcing controlled access.

Benefits: Minimizes unintended dependencies, enhances maintainability and robustness
Sentenz+1Reddit+1.

5. Functional Independence
Definition: Each module should perform a coherent function with minimal dependencies on
others .

 Measured by:
o Cohesion: internal relatedness.
o Coupling: inter-module dependency.
Goal: High cohesion + low coupling for modules that are both useful and stable
Course HeroReddit+15BrightHub+15Medium+15.

6. Architecture
Definition: The overall structure including modules, their interactions, and extra-functional
requirements like performance, scalability, and security .
Models:

 Structural — static organization of components.

 Framework — use of architectural patterns.
 Dynamic — evolving behavior over time.
 Process — business/workflows.
 Functional — feature decompositions
GeeksforGeeks+15Wikipedia+15Wikipedia+15Wikipedia.

7. Design Patterns
Definition: Named, reusable solutions to common design problems within a context,
encapsulating best practices .
Benefits:

1. Identify relevant patterns.

2. Save design effort through reuse.
3. Identify proven strategies for new designs.

8. Refactoring
Definition: Restructuring code/design internally without changing external behavior to improve
clarity and maintainability Summary PlanetWikipedia+9Reddit+9Summary
Planet+9GeeksforGeeks+6Wikipedia+6Wikipedia+6.
Example: Splitting a monolithic class into more cohesive units to enhance readability and
testability.

9. Design Classes
Definition: Refining high-level analysis classes into concrete, implementable classes.
Well-formed design classes should be :

1. Complete & Sufficient – include needed attributes and methods.

2. Primitive – each method does one thing.
3. High Cohesion – concentrated responsibilities.
4. Low Coupling – follows the Law of Demeter (only interact with neighbors).

--

The Design Model Overview

 Analogy: Like house plans, the software design model begins with a holistic view and
refines to detailed specifics (e.g., architectural layout → component plumbing)
 Two dimensions (see figure 9.4):
1. Process dimension – stages of design activities
2. Abstraction dimension – evolving from analysis to implementation details
 Shift from analysis to design may blur, but models are refined in parallel: architecture →
interfaces & components → deployment

📐 Design Modeling Principles

1. Traceability
o Every design element links back to requirements—supporting rationale and
verification
2. Architectural-first
o Start with system structure before diving into component specifics
3. Equal data & processing design
o Thoughtful data modeling simplifies system logic and architecture
4. Well-designed interfaces
o Clean contracts for internal and external communication enhance reliability
5. User-focused UI
o A well-designed user interface shapes perception—even flawless internals fail
without it
6. Functional independence
 o Components serve a single purpose to uphold cohesion
7. Loose coupling
o Minimize interdependencies to reduce risk and improve maintenance
8. Clarity in all models
o Diagrams should clearly communicate to coders, testers, and maintainers
9. Iterative design
o Refine complexity, simplify, and correct flaws over multiple iterations
10. Support agile workflows

 Maintain lightweight, living documentation synced with code, including rationale and
alternatives

🗂️Design Model Elements

1. Data Design

 From high-level user data models to database schemas and data structures
 Guides component and algorithm design; essential for performance and maintainability

2. Architectural Design

 Defines the system’s structure and conceptual integrity, much like a house’s floor plan
 Informed by domain models, architectural styles, and analysis packages
TutorialsPoint+6Scribd+6studylib.net+6Visual Paradigm
Guides+6GeeksforGeeks+6UML Diagrams+6GeeksforGeeksVisual Paradigm
Guides+5Software Ideas+5GeeksforGeeks+5

3. Interface Design
a. User Interface

 Should be intuitive, accessible, aesthetically pleasing—aligned with UX principles

b. External Interfaces

 Must clearly specify data format, protocols, error-handling, and security mechanisms

c. Internal Interfaces

 Define APIs and message exchanges between components; often specified via UML
interfaces or collaboration diagrams Scribd
4. Component-Level Design

 Like room-specific blueprints: each component details data structures, algorithms, and its
interface
 Represented in UML component diagrams, with optional pseudocode or activity
diagrams Wikipedia+12Scribd+12GeeksforGeeks+12

5. Deployment-Level Design

 Maps software components/artifacts onto hardware nodes and environments

o Nodes: physical devices (servers, smartphones) or virtual environments (JVM,
containers)
o Artifacts: deployable binaries, scripts, databases UML
Diagrams+9GeeksforGeeks+9Visual Paradigm Guides+9
 Includes both specification-level (generic) and instance-level (specific environment)
diagrams UML Diagrams

🧩 Diagram Types & Usage

Diagram Type Purpose & Focus

Illustrates modular structure, provided/required interfaces, and dependencies

Component Diagram
TutorialsPoint+7Wikipedia+7GeeksforGeeks+7

Visualizes software on hardware; shows nodes, communication links, and

Deployment Diagram
artifacts

Composite Structure Zooms into parts, ports, and connectors within a classifier

C4 Model
Offers multi-level architecture views from system to component
(Context/Container)

✅ Summary
 The design model is the structured blueprint of your software—from macro architecture
to micro logic
 It ensures traceability, modularity, clarity, and testability, supporting both traditional
and agile processes
 Uses a family of UML diagrams and design principles to document structure, interfaces,
components, and deployments effectively