Unit 2 - Practice Quiz

Modularity is the design principle of breaking down a large software system into smaller, self-contained, and interchangeable components or modules. This makes the system easier to develop, understand, and maintain.

Cohesion is a measure of how strongly related and focused the responsibilities of a single software module are. High cohesion, where all elements work towards a common goal, is desirable.

Coupling measures the degree to which different modules rely on each other. A good design aims for low coupling, meaning modules are as independent as possible.

Functional cohesion is the ideal type, where all elements of a module contribute to performing a single, well-defined function. This leads to modules that are highly focused and reusable.

Content coupling is the worst form because one module directly modifies or relies on the internal workings of another module. This violates information hiding and makes the system very difficult to maintain.

Good module independence is achieved by maximizing the relationships within a module (high cohesion) and minimizing the relationships between modules (low coupling).

A circle (Gane & Sarson notation) or a rounded rectangle (Yourdon & DeMarco notation) represents a process that transforms incoming data flows into outgoing data flows.

An arrow in a DFD represents the movement of data between processes, data stores, and external entities. It is always labeled with the name of the data being transferred.

The Level 0 DFD, also called the Context Diagram, provides the highest-level view of the system, showing the entire system as a single process with its inputs from and outputs to external entities.

A Structure Chart is a design tool that graphically represents the hierarchical organization of modules in a system, showing how they are structured and the passing of control and data between them.

Information Hiding is a core design principle where the internal details of a module's implementation are hidden from other modules, which only interact with it through a well-defined public interface.

A Data Store (like a file or database table) is represented by two parallel lines or an open-ended rectangle. It is a passive repository of data where data can be stored and retrieved.

Decomposition (also known as leveling or refinement) is the process of exploding a single process in a DFD into a more detailed DFD to show its internal sub-processes and data flows.

A classic design trade-off is between performance and maintainability. Highly optimized code for performance can sometimes be more complex and harder to understand, modify, and maintain.

A small arrow with an empty circle is a 'data couple', representing the passing of a simple data parameter from a calling module to a called module.

The Software Design Document (SDD) is a comprehensive description of the software's design. It acts as a blueprint for the development team to follow during the implementation phase.

A design walkthrough is a review process where the designer presents the design document to a group of peers, managers, and stakeholders to find errors and get feedback before implementation begins.

Data cannot flow directly from one external entity to another without passing through a process within the system. The DFD models how the system being analyzed processes data, not how external entities interact with each other.

Transform Analysis is a key technique in function-oriented design for deriving a structure chart from a data flow diagram. It identifies the central data processing and maps the DFD into a hierarchical module structure.

A diamond symbol indicates that the call to the subordinate module is conditional. It is executed only if a certain condition is met, representing an 'if' or 'case' statement in the code.

Sequential cohesion occurs when the output of one element in a module serves as the input for another element. In this scenario, the retrieved records (step 1) are the input for the GPA calculation (step 2), and the calculated GPAs (step 2) are the input for report generation (step 3). This chained relationship is the definition of sequential cohesion.

Common coupling occurs when two or more modules share access to the same global data. This is a highly undesirable form of coupling because a change in the global data structure can require changes in all modules that use it. It also makes it difficult to understand which module is responsible for modifying the data, leading to maintenance and debugging challenges.

A core rule of DFDs is that all data must pass through a process. An external entity cannot directly write to or read from a data store. There must be an intermediary process (e.g., Process Payment) that takes the data from the entity and performs the action of storing it.

The diamond symbol in a Structure Chart represents a decision. It indicates that the superordinate module contains logic (like an if-then-else statement) that determines whether the subordinate module will be invoked.

Microservices architecture provides high modularity (independent services) and scalability. However, managing a distributed system is inherently more complex than managing a monolith. The team is accepting this increased operational and deployment complexity to gain the benefits of a more scalable and maintainable modular architecture.

The principle of DFD balancing dictates that the inputs and outputs of a parent process in a higher-level diagram must be conserved in the corresponding lower-level diagram. The Level-1 DFD is an explosion of the single process in the Level-0 DFD, so its overall inputs and outputs must match those of the parent process exactly.

Transaction analysis is ideal for designing systems where a single input triggers one of many possible action paths. The DFD described has a characteristic 'transaction center' (Dispatch_Command) that routes control to different processing 'spokes'. This structure is the hallmark of a system suitable for transaction analysis.

A well-designed module should have a single, well-defined purpose (high cohesion) and minimal dependencies on other modules (low coupling). This combination makes modules easier to understand, test, reuse, and maintain independently of the rest of the system.

Stamp coupling occurs when a module is passed a data structure (like an object or record) but only uses a portion of it. This is less desirable than data coupling (passing only the necessary simple data items) because it creates a dependency on the entire data structure, even the unused parts. A change to an unused field in the Employee object could still necessitate recompilation or retesting of Module B.

A walkthrough is a peer-group review where the author presents the work product (in this case, a design). It is typically less formal than an inspection and its primary goals are to find defects, consider alternatives, and educate the participants. The scenario described perfectly matches the nature of a walkthrough.

Modularity enables the breakdown of a large problem into smaller, manageable, and independent sub-problems (modules). Once the interfaces between these modules are defined, development teams can work on them in parallel, significantly reducing the overall development time for the project.

Temporal cohesion is when elements of a module are grouped together because they are processed at a particular time in the execution of the system. In this case, all the functions are related by the fact that they are performed during the shutdown sequence.

The afferent stream (or input stream) is the part of the data flow that leads into the central processing region. Its corresponding modules in the structure chart are responsible for reading, validating, and preparing input data. The central transform is the core processing, and the efferent stream handles the output.

A 'miracle' is a process that produces output data without any input. This is a logical error because a process must transform data from some input source to create an output. The opposite error, a process with inputs but no outputs, is called a 'black hole'.

The designer is making a trade-off. By adding functionality to support multiple formats, the module becomes highly reusable across different projects or parts of the same project. The cost of this reusability is increased internal complexity, which can make the module harder to understand, debug, and maintain.

Separation of Concerns is a design principle for separating a computer program into distinct sections such that each section addresses a separate concern. Separating the user interface (presentation concern) from the business logic (domain concern) is a prime example of SoC, and it is the foundational idea behind architectures like Model-View-Controller (MVC).

Module Y returns a data value to X. Module X uses this data to make its own decision. X is not passing a flag to Y, Z, or W to tell them how to behave. Therefore, the coupling between X and Y is data coupling. The relationship between X and Z/W is normal invocation; X is in control. Control coupling would exist if X passed a flag to another module telling it what to do internally.

Architectural design focuses on the high-level structure, components, and their interactions. Detailed design delves into the internal logic of individual modules. Therefore, specifying the exact data structures and algorithms for a module is a core activity of detailed design, not architectural design.

The accepted order of cohesion from best (strongest) to worst (weakest) is: Functional (performs one single task), Sequential (output of one part is input to another), Communicational (parts operate on the same data), Procedural (parts related by order of execution, not in the list), Temporal (parts related by time), Logical (parts logically related), and Coincidental (parts are unrelated).

In structure chart notation, an arrow represents a call or invocation. Small arrows alongside the main arrow represent the flow of parameters. An arrow with an open circle (a 'data couple') indicates the flow of data. When it points from the subordinate (B) to the superordinate (A), it means B is returning data to A.

This is a classic design trade-off. The initial goal was high cohesion for the ReportGenerator module. However, by including generic data-handling functions (fetchData, formatData), the module's cohesion is likely Communicational or Sequential, not purely Functional. When the DataAnalytics module calls these specific functions, it creates a dependency. The best solution would be to extract fetchData and formatData into a third, independent DataUtility module, which both ReportGenerator and DataAnalytics can use. This creates a more flexible design with lower coupling between the primary modules. The original design forced an unnecessary dependency (high coupling) between two otherwise unrelated high-level modules in a misguided attempt to maximize cohesion in one of them.

Instability () means a module has high fan-out and low fan-in, implying it depends on many other modules but few depend on it. This is expected for UI layer modules, as they depend on business logic and services but are rarely depended upon. Instability close to 0 () means low fan-out and high fan-in, indicating a stable, responsible module. This is ideal for a database utility, which many modules depend on but should depend on very little itself. A core domain logic module should be highly stable () because it contains fundamental business rules and should not be dependent on higher-level or volatile components. A core module with signifies it is highly dependent on other modules, making it fragile and hard to change, which is a major architectural flaw (violates the Dependency Inversion Principle).

Let's analyze the issues. Passing the entire CustomerOrder object when only parts are needed is Stamp Coupling. The operations being performed in sequence on the same data (CustomerOrder) suggests Communicational Cohesion. The access to global variables SystemConfig and FinancialLedger is Common Coupling. Of these, Common Coupling is considered one of the worst forms of coupling because it creates hidden, system-wide dependencies that are difficult to track and maintain. While Stamp Coupling is not ideal, it is less severe than Common Coupling. The cohesion is Communicational because the operations are grouped as they operate on the same data (CustomerOrder), not just because they occur in a sequence (which would be Sequential). The combination of tight, non-obvious Common Coupling with a moderately acceptable cohesion level makes this the most significant problem set.

This scenario deliberately mixes transaction and transform flow characteristics. The Parse Command process is a classic transaction center, identifying the type of incoming data and dispatching it along one of several paths. This suggests a transaction-driven design for the top level of the structure chart. However, the Query Database process is a clear example of a transform flow with a central transform (transforming SQL query to raw results). Therefore, the most effective design is a hybrid approach. The main module would manage the transaction center, and one of its subordinate modules (the one handling the query) would act as the controller for a smaller, self-contained transform-centered structure. This correctly models the problem's architecture.

The principle of DFD balancing (or consistency) is critical. It states that all data flows going into or out of a parent process must be represented as flows going into or out of the boundary of its child diagram. In this scenario, the 'Low Stock Alert' flow emerges from within the decomposition of Process 1.0 (specifically, from 1.1) and goes to an external entity that was present at the parent level. However, this output flow did not exist for Process 1.0 at Level 1. This is a direct violation of balancing. For the DFD to be correct, the Level 1 diagram must also show a 'Low Stock Alert' data flow originating from Process 1.0 and terminating at the 'User' entity.

For a safety-critical system, rigor and process are paramount. A formal inspection is the most systematic and rigorous technique. It mandates individual preparation (where experts can study the dense document beforehand), a structured meeting focused solely on defect logging (not problem-solving), and a formal follow-up process to ensure defects are fixed. This structured approach is superior to the informal nature of walkthroughs or ad-hoc reviews, which might miss critical, subtle errors. While pair designing is effective, it's a design creation/refinement technique, not a formal review method suitable for a large, completed document with a distributed team of experts.

Passing a flag that dictates the logic to be executed within another module is the definition of Control Coupling. This is undesirable because the calling module (A) is implicitly tied to the internal implementation details of the called module (B). Furthermore, module B is not functionally cohesive. It performs two different algorithms, and they are grouped together simply because they fall under the logical category of 'computation'. This is the definition of Logical Cohesion, which is a weak form of cohesion. The combination of high Control Coupling and low Logical Cohesion makes the module B difficult to understand, maintain, and reuse independently.

This is a subtle but important distinction. The elements of the module are executed in a specific order, and the output of one element serves as the input for the next. This is the definition of Sequential Cohesion. It is not Communicational Cohesion because, while the functions do operate on the same data structure (the student record), the defining characteristic is their assembly-line, sequential dependency. It's not Procedural Cohesion because the order is dictated by data flow, not just by a required order of execution of otherwise unrelated tasks. It is not Functional Cohesion because the module performs multiple distinct functions (validate, calculate, generate) rather than a single, indivisible one.

The use of a shared resource (the database) that both modules can read and write to is the definition of Common Coupling. This is the primary mechanism of their interaction. However, the data being passed is not just raw data; the 'status' field acts as a flag that explicitly controls the behavior of Module B. Module A is effectively telling Module B 'what to do' by setting the flag. This is the essence of Control Coupling. Therefore, the most precise and critical description is that this design exhibits both Common and Control coupling, which are both considered undesirable forms of coupling.

This question tests a nuanced rule of DFD leveling. The context diagram (Level 0) is meant to show the system as a black box, detailing only its interactions (data flows) with external entities. Internal data stores are implementation details of the system itself. Therefore, they are deliberately hidden at Level 0. It is perfectly valid and standard practice to introduce internal data stores at Level 1 or lower levels of decomposition. The principle of balancing applies to data flows that cross the system boundary (i.e., flows to/from external entities), not to purely internal flows and data stores. Therefore, the described Level 1 DFD is correct.

The Law of Demeter states that a module should not have knowledge of the internal workings of the objects it manipulates. A method should only call methods of: itself, its parameters, any objects it creates/instantiates, or its direct component objects. The code customer.getAccount().getProfile().setPrimaryEmail() violates this by 'reaching through' customer to account, and through account to profile. This creates a strong structural dependency (high coupling) from UIController not just to the Customer class, but also to the Account and Profile classes. If the internal structure of Account or Profile changes (e.g., getProfile() is renamed), the UIController code will break, demonstrating the ripple effect caused by this tight coupling.

First-level factoring is a specific step in converting a DFD to a structure chart using transform analysis. It involves: 1) Identifying the main afferent (input) and efferent (output) streams in the DFD. 2) Locating the central transform, which is the set of processes that converts the most abstract input into the most abstract output. 3) Creating a top-level coordinating module (the 'main' module). 4) Creating subordinate 'controller' modules for the afferent, efferent, and central transform regions. 5) Populating the modules below these controllers by mapping each DFD process to a module in the structure chart. The key is creating the high-level structure based on the input-process-output flow around the central transform.

A 'responsible' or stable module is one that many other parts of the system depend on (high fan-in) and that has few dependencies itself (low fan-out). The instability metric captures this perfectly. A low value of (close to 0) indicates high stability.

• For Module A: Fan-in = 25, Fan-out = 1. . This is very stable.
• For Module B: Fan-in = 1, Fan-out = 8. . This is very unstable.
  Therefore, Module A (XMLParser) is the far more stable and responsible component. This aligns with architectural principles: utility modules should be stable, while application-specific modules can be more volatile.

While changing from Stamp to Data coupling (Option B) is a definite improvement, it's not the most significant one possible. The problem describes a behavior (calculating tenure) that is intrinsically related to the data it operates on (Employee data). This is a strong indicator that the logic belongs with the data. By moving the calculation into the Employee class, we are following object-oriented principles (Information Hiding, Encapsulation) and significantly improving cohesion within the Employee class. More importantly, it completely eliminates the dependency of M1 on M2 for this function, thus providing the greatest possible improvement in independence. This is a more profound architectural improvement than simply changing the type of coupling.

The diamond symbol on a structure chart represents a decision. It indicates that the call to the subordinate module(s) below it is conditional. The logic within the superior module evaluates some condition, and based on the outcome, it may or may not invoke the subordinate module. This is the standard notation for representing an if-then or case structure in the control flow between modules. A loop is typically represented by a curved arrow around the call line. The return of a condition is just a data couple (upward arrow) and does not require a special symbol at the call site.

The lead architect is advocating for the Open-Closed Principle (OCP), which states that software entities should be open for extension but closed for modification. The plugin architecture perfectly embodies this: you can extend the system with new formats (plugins) without changing the existing, compiled framework. The junior developer is invoking the principle of YAGNI (You Ain't Gonna Need It), an agile principle that advises against adding functionality or complexity until it is actually required. The core of their disagreement is whether the upfront cost and complexity of building an extensible system (following OCP) is justified when the immediate requirement is simple (as argued by YAGNI).

The Moderator's primary role is to ensure the inspection process is followed correctly and efficiently. The goal of an inspection meeting is defect detection, not defect resolution or debate. The Author's role is to clarify, not to defend. The Scribe's role is to record all potential defects identified by the team. When this process breaks down, the integrity of the review is compromised. The Moderator must intervene. Halting the meeting to reset expectations and reinforce the rules is the most appropriate action. Taking over a role or unilaterally deciding on defects undermines the team process. The goal is to fix the process, not to force a result.

This scenario tests the balancing rule as it applies to data stores. While data stores themselves can appear at multiple levels, the flows to and from them must be balanced if they cross the process boundary. At Level 1, P1 is shown only reading from D1. At Level 2, the internals of P1 are shown writing to D1. This is a consistency error. If a child diagram shows a flow to/from a data store, the parent diagram must show a corresponding flow from/to that data store. To fix this, a data flow from P1 to D1 must be added on the Level 1 DFD to balance the internal write operation.

Temporal Cohesion occurs when elements are grouped together because they are all processed at a similar point in time or during a specific phase of execution. This module's functions—startup, runtime, and shutdown—are related only by the timing of their execution within the system's lifecycle. They do not operate on the same data (not Communicational), nor do they form a required sequence of operations where one's output is another's input (not Sequential). They are not just logically related alternative actions (not Logical). The grouping is based purely on 'when' they happen, which is the definition of Temporal Cohesion, a relatively weak form of cohesion.

Content coupling is almost always considered the worst form of coupling and is to be avoided. However, in extreme performance-critical systems (like high-frequency trading, embedded systems, or game engines), designers sometimes have to make difficult trade-offs. The justification is not that it's a 'good' design in terms of software engineering principles, but that it's a necessary evil to meet an overriding non-functional requirement (in this case, microsecond-level performance). The designer is consciously sacrificing maintainability, reusability, and modularity—all of which are severely compromised by content coupling—in order to gain the performance benefits of avoiding function call overhead and data copying. It is a deliberate, albeit risky, trade-off.