Modularity Flashcards
3rd Exam
is a software design principle that involves breaking a program into smaller, self-contained units or modules. Each module is designed to perform a specific function and can be developed, tested, and maintained independently from other modules.
Modularity
is a term used in software architecture to describe a system that lacks a clear and organized structure, resulting in a tangled, messy codebase.
Big Ball of Mud
often refers to an individual item or member of a collection or structure, such as an array, list, or set. It represents a discrete, identifiable unit within a collection.
- Element
refer to the hierarchical organization of modules in a system, where each layer represents a distinct level of abstraction or functionality.
Layers
is a software design approach that focuses on separating cross-cutting concerns from the main business logic of a program. Cross-cutting concerns are functionalities that affect multiple parts of a system but don’t fit neatly into the primary modules or classes.
Aspect Oriented Programming
is a software design approach that focuses on dividing a system into modules or components based on the real-world domains or business areas the system represents.
Domain Based Decomposition
is a key consideration in the context of software quality attributes, especially when balancing speed of delivery with other qualities like performance, maintainability, and reliability.
Time-to-start
refers to an approach in software development where a system or product is built and delivered in small, manageable parts (or increments) over time, rather than as a single, large, complete package. Each increment is a small piece of the overall system, typically fully functional or delivering a subset of features, and can be tested, evaluated, and improved upon as the project progresses
Incremental Piecemeal
When the system becomes a Big Ball of Mud it is very difficult to convert it to another thing
A few prestigious developers know where to touch Clean developers run away from these systems
Inertia
You need an immediate fix for a small problem, a quick prototype or proof of concept When it is good enough, you ship it
Throwaway Code
Growth in each deliver
Piecemeal growth
Bad code reproduces in lots of places
Cut/Paste reuse
Not following clean code/architecture, Bad smell
- Anti-pattern and technical debts
refers to a self-contained, independent unit of code that performs a specific function or set of functions within a larger system.
- Module
in software development is a contract or a blueprint that defines a set of methods that a class must implement, without providing the actual implementation of those methods.
Interface
refers to the implementation details or the internal workings of a module.
Body
is a software engineering approach that involves breaking down a complex system into smaller, manageable, and self-contained modules.
Modular decomposition
Modular systems allow teams to work on different modules simultaneously, increasing productivity.
Communication
A module only exposes an interface- less complexity
Simplicity
Modules can be reused in different programs or projects without modification
Reusability
Modules can be developed by different teams
Independence
refers to a poor division of a system’s components, modules, or functionalities, leading to problems in design, maintainability, performance, or flexibility.
Bad Decomposition
Managing dependencies between modules can become complex, particularly as the number of modules increases.
Dependency Management
Modules decomposition affects team organization
Team Organization
refer to pre-built, ready-made software components, applications, or products that are developed by third-party vendors and available for purchase or licensing.
COTS
are pre-built software components or entire applications that are freely available for anyone to use, modify, and distribute.
FOSS
COTS/FOSS modules
Decision: Develop vs Buy
refers to how closely related and focused the responsibilities of a module or class are. In software design, cohesion measures the degree to which the elements inside a module or class belong together, working toward a single, well-defined purpose. High cohesion within a class or module means that its components are strongly related, making the software easier to understand, maintain, and modify.
Cohesion
refers to the degree of direct dependency or interaction between different modules, classes, or components in a software system.
Coupling
in software engineering refers to the ability of a system, application, or component to handle unexpected conditions, inputs, or situations gracefully without crashing or producing incorrect results.
Robustness
is a design guideline for computer software, particularly in networking and communication protocols.
Postel’s Law
is a design guideline for developing software systems with low coupling. It promotes the idea that a given object should have limited knowledge about the internal details of other objects and should only communicate with its immediate “friends” or closely related components.
Demeter’s Law
refer to a design approach in software development where the interactions with a system or API are designed to be intuitive, flexible, and adaptable.
Fluid Interfaces
means that each module should have one reason to change. For instance, a module responsible for user authentication should not also manage user preferences, as this would add unnecessary complexity.
SRP (Single Responsibility Principle)
You should be able to extend the functionality of a class or module without changing its existing code. This can be achieved by using inheritance, interfaces, or abstract classes.
OCP (Open-Closed Principle)
Objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program.
LSP (Liskov Substitution Principle)
A client should not be forced to implement an interface it doesn’t use. Instead of one large interface, break it down into smaller, more specific interfaces.
ISP (Interface Segregation Principle)
High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g., interfaces). Also, abstractions should not depend on details; details should depend on abstractions.
DIP (Dependency Injection Principle)
is a concept in software design and cohesion principles that emphasizes the relationship between the reuse of software components and their release as independent modules or units. it can be reused in different applications:
REP (Reuse/Release Equivalence Principle)
It emphasizes the importance of grouping related classes or components that are likely to change together into a single module.
CCP (Common Closure Principle)
It focuses on how classes or components should be grouped in a way that maximizes their potential for reuse while minimizing unnecessary dependencies.
CRP (Common Reuse Principle)
represents the balance and trade-offs involved in maintaining cohesion between software components or modules while ensuring the system remains flexible and easy to maintain.
Tension Diagram Between Component Cohesion
refers to the degree of direct dependency or interaction between different modules, classes, or components in a software system. In other words, it describes how closely one module is connected or dependent on another.
Coupling
It is primarily concerned with ensuring that dependencies do not form cycles, which can lead to various problems such as increased complexity, difficulty in maintenance, and challenges in testing.
ADP(Acyclic Dependencies Principle)
is a principle in software design that focuses on managing dependencies between modules in a way that promotes stability and reduces the risk of ripple effects when changes are made.
SDP (Stable Dependencies Principle)
It emphasizes the relationship between abstractions (such as interfaces or abstract classes) and their stability within a system. By adhering to the Stable Abstraction Principle, developers can create more robust and maintainable systems.
SAP (Stable Abstraction Principle)
is a fundamental concept in software development that involves hiding the complex details of a system and exposing only the necessary parts.
Abstraction
measures the relationships between software components and helps determine how likely it is that a change in one part will necessitate changes in another part.
Connascene
refers to relationships or dependencies that can be determined and evaluated during coding
Static Connascene
refers to relationships or dependencies that can be determined and evaluated at compile time or during runtime execution
Dynamic Connascene
refers to the number of components that are involved in the connascence relationship. It measures how widespread the dependency is within the system.
Degree
refers to the distance between the components that are connascene. It measures how close or far apart the dependent components are in the system.
Locality
refers to how strongly components are tied together by the dependency. It measures the impact that changing one component will have on the others.
Strength
is a design pattern that enables code to be written in a more readable, expressive, and chainable manner. It allows developers to call methods in a way that forms a “flow” or chain of operations, often resembling natural language.
Fluent API’s
- Grasp principle
General Responsibility Assignments Software Patterns
Intent is declared in one place
DRY Principle
you ain’t gonna need it
YAGNI
KISS Principle
Keep it Simple Stupid
emphasizes the importance of robustness
Postel’s Law
system can tolerate a wide range of issues—such as errors, faults, or misuse—without failing, ensuring that it behaves reliably under various circumstances.
Robustness Principle
A network protocol should ensure that the data it sends conforms strictly to the defined protocol standard. This reduces the chance of errors or miscommunication between systems.
Application of Networking
better user experience, by tolerant with errors, user-friendly (search)
Software Development Impact
initiative on the developers towards the client
Challenges to implementation
It deals with runtime interactions and execution order
Dynamic Connascene
Multiple Components must reference the same identity
Connascene of Identity
It suggest that developers should not add functionality until its necessary
YAGNI
The Principle encourages developers to avoid unnecessary complexity and to strive for simple, straightforward solutions.
KISS Principle
Represents real world concepts and business logic
Domain Model
External Operations
Services
It promotes efficiency and prevents feature bloats in software Projects
YAGNI
In a system that interacts with databases, many methods might need to start or commit transactions
Transaction Management
A programming technique that is based on concept of an aspect that encapsulates cross-cutting concern
AOP (Aspect Oriented Programming)
Contain attributes but no identity
Value Objects
The distance between the elements
Locality
It focuses on understanding and modelling the core business logic of a system
DDD
Only few components depend on each other
Low Degree
The knowledge or logic in a system should have a single, unambiguous, and authoritative representation
DRY Principle
Describe key objects, relationship and behavior
Domain models
Organize system modules by technical capabilities
Technical Partitioning
More components depend on each other
High Degree / Tight Coupling
It emphasizes the simplicity should be a key goal in design
KISS Principle
The number of elements affected by connascene
Degree
Known as the Ports and Adaptors Architecture creating adaptable system by separating core business logic like database, user interface
Hexagonal Style
The interface for registering
Ports Driving
Interface for processing payments
Driven Ports
Archi-pattern exposing domain objects to user
Naked Objects
Separate between components domain and business node/rules
Clean Code
Provides a framework that priorities data as the core of the system
Data Centered
repetitive code like logging or security that tends to duplication. Functionality or feature of code that needed through multiple parts.
Cross-Cutting Concerns
Can be detected with analysis or during coding
Static Connascene
issues in term of deployment
Monolithic Application
Request flow through layers without processing
Skinkhole anti-pattern
Objects with identity
Entities
Collection of objects bound together by some root entities
Aggregates
Creates Objects
Factories
Storage Service
Repositories
Specifies Boundaries of domain
Bounded Context
Proposed by Eric Evans, focuses on understanding & modeling the lose business logic
Domain Driven Design
Module separated from other module
Domain models
Describes key objects, relationship and behaviour
Domain Models
Organize how data is stored structured and organize in database
Data Models
Organize modules by domain, categorize
Domain Partitioning
Encapsulate cross-cutting concern to be reuse, reduce code duplication
Reusable Code
developer can focus writing core business without worrying cross-cutting/ less error prone
Quick Development Progress
Born and Grow Together
Connascene
Combines coupling and cohesion
Connascene
looks at how components are coupled, source code interaction
Static Connascene
5 types of Static Connascene
Name, Type, Meaning, Identity, Algorithm
4 Types of Dynamic Connascene
Execution, Timing, Values, Identity
Improve readability & reusability
Fluent API’s
Principle of less knowledge
Demeter’s Law
Units should have limited knowledge, Each units should only talk to its friends, and Symptoms of bad design
Demeter’s Law
Don’t talk to Strangers
Demeter’s Law
Module can function independently, minimal dependencies
Loose Coupling
Modules are highly dependent on each other; changes in one module after others
Tight Coupling
Degree of interdependence between software modules; how closely connected different parts of a system
Coupling Principle
Set of functionalities exposed through an interface at a Level N
Layers
Divide software module in layers, ordered
Layers
Consumers services
Client
Provide services to the consumers
Server
2 variants of layers
Strict and Lax
tolerable and resilient systems, maintains functionality even faced with errors
Application of networking
more user friendly & reliable, satisfaction and reducing support cose
Software development Impact
Developers must strike right balance of accepting input while maintaining security
Challenges to Implementation
Piece of software that offers a set of resposibilities
Module
Describe what is a module
Interface
How it is implemented
Body
A module only exposes interfaces / less compexity
Simplicity
facilitates changes and extensions
Maintainability
communicate the general aspect of the system
Communication
decomposing the project in modules at development time
Modularity
module can be develop independently
Modularity
Quality Attributes of Modularity
- Time-to-market
- Cost
possible to start w/out defining an architecture
Quick Start
Cheap solution for short term projects
Cost
you need a immediate fix on a small problem
Throw-away code
when the systems becomes a big ball of mud, very difficult to convert in to another thing.
Inertia
