Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

Elective 1 > Modularity > Flashcards

Modularity Flashcards

3rd Exam

1
Q

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.

A

Modularity

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

is a term used in software architecture to describe a system that lacks a clear and organized structure, resulting in a tangled, messy codebase.

A

Big Ball of Mud

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

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.

A
  • Element
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

refer to the hierarchical organization of modules in a system, where each layer represents a distinct level of abstraction or functionality.

A

Layers

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

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.

A

Aspect Oriented Programming

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

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.

A

Domain Based Decomposition

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

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.

A

Time-to-start

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

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

A

Incremental Piecemeal

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

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

A

Inertia

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

You need an immediate fix for a small problem, a quick prototype or proof of concept When it is good enough, you ship it

A

Throwaway Code

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Growth in each deliver

A

Piecemeal growth

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Bad code reproduces in lots of places

A

Cut/Paste reuse

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Not following clean code/architecture, Bad smell

A
  • Anti-pattern and technical debts
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

refers to a self-contained, independent unit of code that performs a specific function or set of functions within a larger system.

A
  • Module
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

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.

A

Interface

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

refers to the implementation details or the internal workings of a module.

A

Body

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

is a software engineering approach that involves breaking down a complex system into smaller, manageable, and self-contained modules.

A

Modular decomposition

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Modular systems allow teams to work on different modules simultaneously, increasing productivity.

A

Communication

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

A module only exposes an interface- less complexity

A

Simplicity

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Modules can be reused in different programs or projects without modification

A

Reusability

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Modules can be developed by different teams

A

Independence

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

refers to a poor division of a system’s components, modules, or functionalities, leading to problems in design, maintainability, performance, or flexibility.

A

Bad Decomposition

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Managing dependencies between modules can become complex, particularly as the number of modules increases.

A

Dependency Management

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Modules decomposition affects team organization

A

Team Organization

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
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
26
are pre-built software components or entire applications that are freely available for anyone to use, modify, and distribute.
FOSS
27
COTS/FOSS modules
Decision: Develop vs Buy
28
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
29
refers to the degree of direct dependency or interaction between different modules, classes, or components in a software system.
Coupling
30
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
31
is a design guideline for computer software, particularly in networking and communication protocols.
Postel's Law
32
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
33
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
34
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)
35
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)
36
Objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program.
LSP (Liskov Substitution Principle)
37
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)
38
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)
39
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)
40
It emphasizes the importance of grouping related classes or components that are likely to change together into a single module.
CCP (Common Closure Principle)
41
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)
42
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
43
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
44
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)
45
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)
46
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)
47
is a fundamental concept in software development that involves hiding the complex details of a system and exposing only the necessary parts.
Abstraction
48
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
49
refers to relationships or dependencies that can be determined and evaluated during coding
Static Connascene
50
refers to relationships or dependencies that can be determined and evaluated at compile time or during runtime execution
Dynamic Connascene
51
refers to the number of components that are involved in the connascence relationship. It measures how widespread the dependency is within the system.
Degree
52
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
53
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
54
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
55
* Grasp principle
General Responsibility Assignments Software Patterns
56
Intent is declared in one place
DRY Principle
56
you ain’t gonna need it
YAGNI
57
KISS Principle
Keep it Simple Stupid
58
emphasizes the importance of robustness
Postel's Law
59
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
60
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
61
better user experience, by tolerant with errors, user-friendly (search)
Software Development Impact
62
initiative on the developers towards the client
Challenges to implementation
63
It deals with runtime interactions and execution order
Dynamic Connascene
64
Multiple Components must reference the same identity
Connascene of Identity
65
It suggest that developers should not add functionality until its necessary
YAGNI
66
The Principle encourages developers to avoid unnecessary complexity and to strive for simple, straightforward solutions.
KISS Principle
67
Represents real world concepts and business logic
Domain Model
68
External Operations
Services
69
It promotes efficiency and prevents feature bloats in software Projects
YAGNI
70
In a system that interacts with databases, many methods might need to start or commit transactions
Transaction Management
71
A programming technique that is based on concept of an aspect that encapsulates cross-cutting concern
AOP (Aspect Oriented Programming)
72
Contain attributes but no identity
Value Objects
73
The distance between the elements
Locality
74
It focuses on understanding and modelling the core business logic of a system
DDD
75
Only few components depend on each other
Low Degree
76
The knowledge or logic in a system should have a single, unambiguous, and authoritative representation
DRY Principle
77
Describe key objects, relationship and behavior
Domain models
78
Organize system modules by technical capabilities
Technical Partitioning
79
More components depend on each other
High Degree / Tight Coupling
80
It emphasizes the simplicity should be a key goal in design
KISS Principle
81
The number of elements affected by connascene
Degree
82
Known as the Ports and Adaptors Architecture creating adaptable system by separating core business logic like database, user interface
Hexagonal Style
83
The interface for registering
Ports Driving
84
Interface for processing payments
Driven Ports
85
Archi-pattern exposing domain objects to user
Naked Objects
86
Separate between components domain and business node/rules
Clean Code
87
Provides a framework that priorities data as the core of the system
Data Centered
88
repetitive code like logging or security that tends to duplication. Functionality or feature of code that needed through multiple parts.
Cross-Cutting Concerns
89
Can be detected with analysis or during coding
Static Connascene
90
issues in term of deployment
Monolithic Application
91
Request flow through layers without processing
Skinkhole anti-pattern
92
Objects with identity
Entities
93
Collection of objects bound together by some root entities
Aggregates
94
Creates Objects
Factories
95
Storage Service
Repositories
96
Specifies Boundaries of domain
Bounded Context
97
Proposed by Eric Evans, focuses on understanding & modeling the lose business logic
Domain Driven Design
98
Module separated from other module
Domain models
99
Describes key objects, relationship and behaviour
Domain Models
100
Organize how data is stored structured and organize in database
Data Models
101
Organize modules by domain, categorize
Domain Partitioning
102
Encapsulate cross-cutting concern to be reuse, reduce code duplication
Reusable Code
103
developer can focus writing core business without worrying cross-cutting/ less error prone
Quick Development Progress
104
Born and Grow Together
Connascene
105
Combines coupling and cohesion
Connascene
106
looks at how components are coupled, source code interaction
Static Connascene
107
5 types of Static Connascene
Name, Type, Meaning, Identity, Algorithm
108
4 Types of Dynamic Connascene
Execution, Timing, Values, Identity
109
Improve readability & reusability
Fluent API's
110
Principle of less knowledge
Demeter's Law
111
Units should have limited knowledge, Each units should only talk to its friends, and Symptoms of bad design
Demeter's Law
112
Don't talk to Strangers
Demeter's Law
113
Module can function independently, minimal dependencies
Loose Coupling
114
Modules are highly dependent on each other; changes in one module after others
Tight Coupling
115
Degree of interdependence between software modules; how closely connected different parts of a system
Coupling Principle
116
Set of functionalities exposed through an interface at a Level N
Layers
117
Divide software module in layers, ordered
Layers
118
Consumers services
Client
119
Provide services to the consumers
Server
120
2 variants of layers
Strict and Lax
121
tolerable and resilient systems, maintains functionality even faced with errors
Application of networking
122
more user friendly & reliable, satisfaction and reducing support cose
Software development Impact
123
Developers must strike right balance of accepting input while maintaining security
Challenges to Implementation
124
Piece of software that offers a set of resposibilities
Module
125
Describe what is a module
Interface
126
How it is implemented
Body
127
A module only exposes interfaces / less compexity
Simplicity
128
facilitates changes and extensions
Maintainability
129
communicate the general aspect of the system
Communication
130
decomposing the project in modules at development time
Modularity
131
module can be develop independently
Modularity
132
Quality Attributes of Modularity
1. Time-to-market 2. Cost
133
possible to start w/out defining an architecture
Quick Start
134
Cheap solution for short term projects
Cost
135
you need a immediate fix on a small problem
Throw-away code
136
when the systems becomes a big ball of mud, very difficult to convert in to another thing.
Inertia

Elective 1 (2 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2025 Bold Learning Solutions. Terms and Conditions