High-Level Design Engineering Notes
What is Design?
Software design bridges the gap between requirements and code.
Design is a problem-solving process (verb) and a plan (noun).
Design Process
Problem understanding: Discover design requirements from different angles.
Identify solutions: Evaluate and choose the most appropriate solutions.
Describe solution abstractions: Use notations to describe the design components.
Repeat the process until the design is expressed in primitive terms.
Levels of Design
Software Architecture: Decompose the system into subsystems and define interactions.
Component Design: Transform architectural elements into procedural descriptions.
Data Design: Deals with system data structures and their representation.
Interface Design: Describes communication between software elements, other systems, and users.
Design Principles
SOLID principles
DRY (Do Not Repeat Yourself)
YAGNI (You Aren’t Gonna Need It)
SOLID Principles
SRP (Single Responsibility Principle): A class should have only one job.
OCP (Open/Closed Principle): Modules should be open for extension but closed for modifications.
LSP (Liskov’s Substitution Principle): Derived types must be substitutable for base types.
ISP (Interface Segregation Principle): Clients should not be forced upon unused interfaces.
DIP (Dependency Inversion Principle): High-level modules should not depend on low-level modules; both should depend on abstractions.
Fundamental Concepts
Abstraction: Focus on solving problems at a conceptual level.
Architecture: Overall software structure.
Patterns: Proven design solutions.
Modularity: Compartmentalization of data and function.
Information Hiding: Controlled interfaces.
Functional Independence: Single-minded function and low coupling.
Refactoring: Reorganization to simplify design.
Refinement: Elaboration of detail for all abstractions.
Abstraction Types
Procedural Abstraction: Hides algorithm details.
Data Abstraction: Provides essential data information to the outside world.
Architecture & Patterns
Patterns: Common solutions to common problems.
Architectural Styles: High-level patterns for organizing software.
Design Patterns: Low-level patterns for describing details.
Modularity
Breaking software into separate, integrable modules.
Desirable properties
Well-defined system that can be used with other applications
Single specified obejctives
Can be seperately compiled and saved in the library
Easier to use than to build
Simpler from outside than inside
Functional Independence
A function is atomic, performing a single task with minimal interaction.
Measured by cohesion and coupling.
Cohesion (Intra-module)
Functional strength of a module; higher cohesion is better.
Levels of cohesion (highest to lowest):
Functional
Sequential
Communicational
Procedural
Temporal
Logical
Co-incidental
Coupling (Inter-module)
Interdependence between modules; lower coupling is better.
Levels of coupling (lowest to highest):
Data
Stamp
Control
External
Common
Content
Advantages of Modularization
Easier maintenance, functional division, abstraction, re-use, concurrent execution, and security.
Information Hiding
Modules communicate with necessary information only.
Enforces access constraints.
Reduces side effects and global impact of design decisions.
Refactoring
Improving internal structure without altering external behavior.
Refinement
Breaking problems into smaller, easier-to-solve sub-problems.
Top-Down Design
Start with the problem as a whole and work downwards.
Bottom-Up Design
Specify lowest level components and join them to form larger components.
Top-Down Design, Bottom-Up Implementation
Practical approach: design top-down and implement bottom-up.
Architectural Design
Identifies subsystems and their communication framework.
Uses block diagrams of entities and relationships.
Architectural Views (4+1 Model)
Logical View: Functional requirements for end-users.
Process View: Dynamic aspects, processes, information flow.
Development View: Programmer's perspective, software management.
Physical View: System execution environment.
Scenarios: Use cases describing architecture.
Software Architecture
Represents overall structure, components, and organization.
Includes rationale, concepts, and constraints.
Architectural Patterns
Describe common architecture structures and their elements.
Architecture: Pipe and Filter
Filter: process the a stream of input data to some out put data
Pipe: a channel that allows the flow of data
Architecture: Model-View-Controller (MVC)
Manages interaction in web-based systems.
Model: Manages data, independent of the user interface.
View: Output representation of information.
Controller: Accepts input and updates the model or view.
Layered Architecture
System consists of layers providing services.
Supports incremental development.
Variations: 2-tier, 3-tier, N-tier.
Repository Architecture
Data exchange via a shared central database.
Peer-to-Peer Architecture
Each node has equal capabilities and responsibilities.
Microservices
Independent services providing specific functions.
Self-contained, focusing on single or related functions.
Microservices Architecture
Each part of the application is built as a microservice, can improve the modularity, testability and maintainability of the application
Requires more planning and resources since there are many parts to the application
Microservices Advantages
Automated deployment and continuous delivery (DevOps).
More reliable, independently developed, tested, and deployed.
Can utilize latest technology stack.
Microservices Disadvantages
Maintenance and management overhead.
Potential performance impact due to network overhead.
Problems associated with distributed computing (security, transactions, concurrency).
Design Patterns
Reusable solutions to common problems.
Template or guide for solving problems.
Categories of GoF Design Patterns
Creational, Structural, Behavioral.