Unit 3 - Practice Quiz

The Inception phase is the initial phase of the Unified Process, where the primary goals are to establish the project's scope, feasibility, and business case.

The Construction phase is where the bulk of the software is designed, implemented, and tested. The focus is on building the system.

Iterative development is based on the principle of developing a system through repeated cycles, allowing for refinement and improvement with each iteration.

The incremental model focuses on delivering the software in parts (increments), where each increment adds new, usable functionality to the existing system.

An actor is an external entity that interacts with the system. It can be a person, another system, or a device.

Use Case diagrams provide a high-level view of a system's functionality by showing how external users (actors) interact with the system to achieve their goals.

A Class Diagram is a structural diagram that describes the static structure of a system by showing its classes, attributes, methods, and the relationships among them.

The standard UML notation for visibility is: + for public, - for private, # for protected, and ~ for package.

Sequence Diagrams are behavioral diagrams because they describe how objects interact with each other and the sequence of those interactions over time.

The lifeline represents the existence of an object over a period of time. Messages are shown as arrows between lifelines.

Activity diagrams are used to model the flow of control from one activity to another, making them conceptually very similar to flowcharts.

A diamond shape represents a decision node where the flow of control can branch into multiple paths based on a condition.

The object modeling process begins with analyzing the problem domain to identify the key concepts, which are then modeled as classes and objects.

Encapsulation is the object-oriented principle of bundling data and the methods that work on that data within one unit, and also hiding the internal state of an object from the outside.

Completeness checking is the process of verifying that the model has not omitted any requirements or necessary components defined in the specification.

Consistency checking ensures that different models or different parts of the same model do not contradict each other. An object of a non-existent class is a clear inconsistency.

A traceability matrix is a tool used to ensure that all requirements are being addressed by tracking them throughout the development lifecycle, from origin to implementation and testing.

By having links from a requirement to all related design, code, and test artifacts, traceability makes it easier to identify everything that might need to be modified when that requirement changes.

Coding standards create consistency across the codebase, making it easier for any developer on the team to read, understand, and modify the code, which is crucial for long-term maintenance.

A code review is a systematic examination of source code. Its primary purpose is to find mistakes, improve code quality, and help share knowledge among team members.

The Elaboration phase focuses on understanding the problem domain, establishing a solid architectural foundation, and mitigating key risks by implementing the most critical use cases. It is not about full implementation (which happens in Construction) or deployment (which happens in Transition). Initial requirements gathering happens in Inception.

The Construction phase is where the bulk of the coding and component development occurs. While other workflows like Analysis, Design, and Test are still active in each iteration, the primary focus and effort shift heavily towards implementing the system features based on the architecture established in the Elaboration phase.

The key advantage of iterative models is their ability to handle change. Each iteration provides an opportunity to review progress, gather feedback from stakeholders, and incorporate new or modified requirements. This is very difficult in a rigid, sequential model like Waterfall, which assumes requirements are fixed upfront.

Delivering a working, albeit partial, increment of the software allows stakeholders to interact with it and provide valuable feedback early in the lifecycle. This helps ensure the final product aligns with their needs and allows the team to make course corrections if necessary, reducing the risk of building the wrong product.

The <<include>> relationship is used when a base use case must incorporate the functionality of another use case to complete its task. Since logging in is a mandatory, non-optional step for registering, "Register for Course" includes "Login". An <<extend>> relationship represents optional functionality.

Actors in a Use Case diagram represent entities outside the system under development that interact with it (e.g., human users, external hardware, other software systems). A database is an internal component of the system itself, not an external actor that initiates actions.

A filled diamond represents Composition, which is a strong form of the "has-a" relationship. It implies whole-part ownership, where the part (Engine) cannot exist without the whole (Car). If the Car is destroyed, its Engine is also destroyed. Aggregation (unfilled diamond) implies a weaker relationship where the part can exist independently.

Multiplicity is read near the opposite class on the association line. The rule "each Account must belong to exactly one Customer" means you place a 1 at the Customer end of the link. The rule "A Customer can have one or more Accounts" means you place 1..* (one to many) at the Account end.

A solid line with a filled arrowhead represents a synchronous message (like a standard method call). The sender (Lifeline A) pauses its execution and waits until the receiver (Lifeline B) has finished processing the message and returns control. The activation bar on B shows its period of execution for that call. An asynchronous call uses an open arrowhead.

The alt (alternative) fragment is used to model choice or conditional logic, similar to an if-then-else structure. It contains multiple operands, each with a guard condition. Only the operand whose guard condition is true will be executed. This perfectly models the exclusive choice between Credit Card and PayPal payment methods.

A Fork node is used to split a single flow of control into multiple parallel or concurrent flows. A Join node is used to synchronize these parallel flows, waiting for all of them to complete before continuing with a single outbound flow. This correctly models the concurrent activities of packing and shipping.

Swimlanes are the primary mechanism in Activity Diagrams for organizing activities based on the responsible party (e.g., a specific object, a component, an actor, or a business department). This adds a crucial layer of organizational or structural context that is absent in simple flowcharts, making it clear who does what.

After identifying the candidate classes (the nouns of the system), the object modeling process typically proceeds to define how these classes relate to each other (their associations) and what data they hold (their attributes). This static structure is usually captured in a Class Diagram before moving on to dynamic behavior or implementation.

In this context, "color" is a simple property of a car. It doesn't have its own distinct behavior or complex attributes that would justify making it a separate class. Modeling it as a simple attribute (like a string or an enum) within the Car class is the most efficient and common approach, avoiding unnecessary complexity.

This is a classic example of an inconsistency between a static model (the Class Diagram, which defines structure and capabilities) and a dynamic model (the Sequence Diagrams, which show behavior over time). The behavioral models fail to utilize a capability defined in the structural model, suggesting either the method is unnecessary or the behavioral model is incomplete.

A completeness check ensures that the models fully address all specified requirements. The most direct way to do this is to trace each functional requirement from the SRS to a corresponding element in the design models, such as a use case, to ensure nothing has been missed. Other options relate to standards, aesthetics, or process metrics, not completeness.

Traceability provides a clear, bi-directional path from requirements through design, implementation, and testing. Its key benefit is ensuring that all requirements are accounted for (completeness) and providing a mechanism to analyze the impact of a change (e.g., "If this requirement changes, which use cases, classes, and tests are affected?").

Traceability provides justification for the work being done. By showing a direct link from the implemented feature back to a documented and approved requirement (e.g., SR-10.3: "System must log all user access"), the team can demonstrate that they are building what was requested and not engaging in "gold plating" or unnecessary work.

Formal Inspection is the most rigorous and structured code review technique. It involves defined roles (moderator, author, reviewer, scribe), preparation by reviewers using checklists, a formal meeting to log defects (not fix them), and a follow-up process to ensure defects are resolved. This rigor makes it ideal for safety-critical systems where defect detection is paramount.

The number 2 is a "magic number" – a hardcoded literal value whose meaning is not immediately clear from the code itself. A good coding standard would require replacing it with a named constant, such as if (user.status == UserStatus.INACTIVE), to improve code readability and maintainability.

The Construction phase is where the bulk of the coding occurs, making the Implementation workflow dominant. While other workflows are active (e.g., design is refined, tests are executed), the primary goal and resource consumer is building the software. Each iteration must produce an executable, tested, and integrated increment of the final system, not just models or plans.

While the other options are potential risks, the most severe and direct consequence of neglecting the architectural vision is architectural drift or erosion. Each increment may be optimized locally, but the overall system structure degrades over time, making future changes expensive and complex, and potentially compromising non-functional requirements like performance and security.

This question tests the precise semantics of use case relationships. 'Authenticate User' is mandatory shared behavior, perfect for <<include>>. 'Dispense Cash' is an integral, inseparable part of the main success scenario, so it should be a step within the base use case's description, not a separate included or extending use case. 'Print Receipt' is truly optional behavior that adds to the base case under certain conditions, which is the exact purpose of the <<extend>> relationship.

The key phrase is "The lifecycle of the Engine is entirely dependent on the Car." This describes a whole-part relationship where the part cannot exist without the whole. This is the definition of Composition, represented by a filled diamond on the whole's (Car's) side. Aggregation (hollow diamond) implies a weaker relationship where the part can exist independently. A simple association doesn't convey the lifecycle dependency.

This requires combining three distinct fragments. alt (alternative) is perfect for mutually exclusive outcomes like valid/invalid credentials. opt (optional) is correct for the 'Refresh Token' step which may or may not happen. The requirement that the login interaction must complete before other processes can access session data indicates a critical section, correctly modeled by the critical fragment. Nesting the alt inside the critical fragment correctly models the entire atomic, conditional operation.

This is a very specific form of inconsistency. It's not just that the names are different (terminological inconsistency), but the entire signature (name, number, and type of parameters) of the operation/message is mismatched between the static model (Class Diagram) and the behavioral model (Sequence Diagram). The class expects an Address object, but the sequence diagram shows it receiving primitive strings. This is a direct conflict in the expected interface.

Forward-to traceability traces from a requirement to the downstream artifacts that implement and verify it (design elements, code, test cases). The auditor's action is a classic example of this. Backward-from traceability is the opposite: starting from code or a test case and tracing back to the requirement that justifies its existence. Horizontal traceability links artifacts at the same level (e.g., requirement to requirement).

While all options are useful, a Fagan inspection is the most rigorous and formal technique specifically designed for high-fidelity defect detection. Its structured process, defined roles (especially having a 'reader' paraphrase the logic), and preparation phase where inspectors review the code against specifications before the meeting are tailored to find deep logical errors, which is the primary concern. A walkthrough is less formal, pair programming is a development practice (not a review of already-written code), and static analysis tools are excellent but may miss complex algorithmic or concurrency flaws that require human reasoning.

The primary goal of the Elaboration phase is to establish a stable architectural baseline and retire major risks. A failure to meet key non-functional requirements (like performance) in the executable architecture is a major risk that has not been retired. If this failure makes the project non-viable (exceeds budget), it's a clear indication that the Lifecycle Architecture Milestone has not been met. Deferring low-risk use cases, having a reasonable confidence interval in the plan, and managing minor risks are all acceptable and expected outcomes of a successful Elaboration phase.

This model conveys multiple layers of information. The partitions (swimlanes) explicitly model the locus of control or responsibility for actions. The arrow crossing the partition boundary signifies a handoff of this responsibility. The object flow notation (an arrow with an object name) explicitly shows that a data object of type SQLQuery is being passed as part of this handoff. The other options are incorrect interpretations of these standard UML notations.

The Information Expert principle (part of GRASP heuristics) is the primary tool for assigning responsibilities. In this complex case, applying it reveals that neither class has all the required information. The Product knows its own physical properties, but the ShoppingCart knows the destination and the full list of items. This realization that the information is distributed is a key outcome of the modeling process, and it correctly points towards the need for a new collaborator (ShippingCalculator) that can aggregate this information, thus promoting low coupling and high cohesion.

This scenario—a many-to-many relationship that has its own attributes—is the canonical use case for an Association Class. It precisely models that role and billableHours are properties of the link between an Employee and a Project, not of the employee or project themselves. While creating a separate class and linking it (Option B) is a common implementation pattern (a 'reified' association), the Association Class is the more abstract and semantically expressive modeling construct in UML.

In UML, a message where the sender does not wait for the receiver to finish is an asynchronous message, denoted by a solid line with a stick arrowhead (an open, V-shaped head). A synchronous call, where the sender blocks, uses a filled triangle. Since both the initial request (processData) and the subsequent callback (dataReady) are 'fire-and-forget' from the sender's perspective, both are correctly modeled as asynchronous messages.

A sharp velocity drop when integrating a complex new component often signals that the existing architecture is not robust or clean enough to support the extension. The integration work forces the team to refactor, debug, and fix underlying issues (technical debt) that were not apparent during simpler, earlier iterations. While inaccurate estimation (Option B) contributes, it doesn't explain the full 40% drop as well as the cascading effect of significant, unplanned refactoring work caused by accumulated technical debt.

The primary value of a traceability matrix during a change is to facilitate impact analysis. By tracing forward from the changed requirement (FR-25), the team can immediately identify the entire chain of dependent artifacts (design, code, tests) that are affected. This prevents defects caused by incomplete changes and provides a clear scope of work for implementing the change request. The other options are valid uses of traceability but are not the most critical and immediate action in response to a requirement change.

This approach is the most effective. It enforces the standard, which exists for long-term health of the codebase (maintainability, testability). However, it does so constructively by (1) acknowledging the developer's achievement (correctness), (2) clearly stating the reason for rejection (maintainability via complexity), (3) providing a specific, actionable path forward (refactor into smaller methods), and (4) offering collaboration. This turns a simple rule violation into a coaching and quality improvement opportunity. Approving it creates technical debt; a blunt rejection is demotivating.

This requires several concepts. Fork starts the parallel execution. The critical requirement is immediate termination, which is modeled by a Flow Final node (circle with an X) that terminates a single control flow without ending the entire activity. An Activity Final node (filled circle in a ring) would be incorrect as it terminates everything. The successful paths must be synchronized using a Join node before a Decision can be made based on their combined outcomes. This combination correctly models the required parallel logic with an early-exit condition.

Vertical consistency checking validates models at different levels of abstraction against each other. Here, a behavioral model (State Machine) defines a required behavior (confirmReceipt event) that the structural model (Class Diagram) does not support with a corresponding operation. This indicates that the class's interface is incomplete. The dynamic model dictates the necessary operations that the static model must provide.

The core distinction between subclassing (is-a) and states (is-in) is identity and permanence. Subclassing implies a relatively static classification. An object of type Inpatient is created and will always be an Inpatient. If the real-world entity (Patient) can dynamically change its classification throughout its lifetime while retaining its identity, modeling this as a change of state within a single Patient object is a much more robust and accurate design. Re-instantiating the object as a different subclass is clumsy and can break references.

The Transition phase is about moving the completed system from the development environment to the user community. The focus shifts from feature creation to stabilization and user acceptance. Work is dominated by fixing bugs discovered in the production environment, optimizing the system based on real-world usage patterns (performance tuning), making small changes to improve user experience (usability refinements), and handling the operational aspects of deployment like migrating data from a legacy system.