Unit3 - Subjective Questions

The Unified Process consists of four sequential phases, each concluding with a major milestone:

1. Inception Phase: The primary goal is to establish the business case for the system. It involves defining the scope, identifying critical risks, and determining if the project is feasible.
2. Elaboration Phase: The focus shifts to analyzing the problem domain, establishing a sound architectural foundation, eliminating high-risk elements, and refining the project plan.
3. Construction Phase: This is the manufacturing phase where the system is built. It involves iterative implementation, coding, integration, and testing of the remaining components to produce a deployable product.
4. Transition Phase: The software is deployed to the end-users. Activities include beta testing, user training, data conversion, and correcting final defects before the official release.

While often used together, these strategies have distinct meanings:

• Iterative Development:

  • Concept: The system is developed through repeated cycles (iterations). In each iteration, the software is refined and improved.
  • Focus: It focuses on refining the design and fixing issues. You might revisit the same module multiple times to improve quality or logic.
  • Goal: To improve the system through feedback.

• Incremental Development:

  • Concept: The system is built and delivered in pieces (increments). Each increment adds new functionality to the previous one.
  • Focus: It focuses on expanding the system's capabilities. Once a module is finished, you move to the next one.
  • Goal: To deliver functional parts of the system early to the user.

The Unified Process defines several core workflows that occur across the four phases. Key workflows include:

• Requirements: Systematically identifying, documenting, and managing the requirements of the system using Use Cases.
• Analysis: Translating requirements into a conceptual model that describes what the system should do, independent of implementation details.
• Design: Transforming the analysis model into a design model that describes how the system will be implemented (architecture, data structures, interfaces).
• Implementation: Writing the actual code and building the system components.
• Test: Verifying that the implementation matches the requirements and design through unit, integration, and system testing.
• Deployment: Releasing the software to the end-users.
• Configuration and Change Management: Managing versions and changes to artifacts throughout the lifecycle.

Use Case Diagrams capture the functional requirements of a system by showing the interactions between external entities (Actors) and the system's functions (Use Cases).

Relationships:

• Relationship:

  • Represents a mandatory relationship. It implies that the behavior of the included use case is inserted into the behavior of the base use case.
  • Example: A "Withdraw Cash" use case includes "Verify PIN". The withdrawal cannot happen without verification.

• Relationship:

  • Represents an optional or conditional relationship. It implies that the extending use case may augment the behavior of the base use case under specific conditions.
  • Example: A "Book Flight" use case might be extended by "Add Travel Insurance". The insurance is optional.

Generalization is a relationship between a general classifier (parent/superclass) and a more specific classifier (child/subclass). It represents an "IS-A" relationship, analogous to inheritance in object-oriented programming.

• Notation: A solid line with a hollow triangle arrow pointing to the parent class.
• Mechanism: The specific class inherits attributes and operations from the general class and may add new ones or override existing ones.

Example:
Consider a class Vehicle.

• Car and Truck are specific classes that inherit from Vehicle.
• Vehicle might have attributes like speed and engineType.
• Car inherits these but adds numberOfDoors.
• Truck inherits these but adds cargoCapacity.
• Here, Car is a Vehicle.

Both are special forms of association representing a "whole-part" relationship, but they differ in the strength of ownership.

A Sequence Diagram illustrates how objects interact with each other in a specific time sequence. The main components are:

1. Lifeline: Represented by a dashed vertical line extending downward from an object/actor symbol. It indicates the existence of the object over time.
2. Activation Bar (Focus of Control): A thin rectangle on the lifeline that represents the period during which an object is performing an operation or is active.
3. Messages:
   • Synchronous Message: Sender waits for a response (solid line with filled arrowhead).
   • Asynchronous Message: Sender does not wait for a response (solid line with open arrowhead).
   • Return Message: Response back to the sender (dashed line with open arrowhead).
4. Interaction Fragments/Guards: Frames used to show logic like loops (loop), alternatives (alt), or options (opt) enclosing a section of interactions.

An Activity Diagram is a behavioral diagram in UML that depicts the flow of control or object flow with an emphasis on the sequence and conditions of the flow. It models the dynamic aspects of a system, often used for business processes or complex algorithms.

Differences from Flowchart:

1. Concurrency: Activity diagrams explicitly support parallel processing (concurrency) using Fork and Join nodes, whereas standard flowcharts are typically sequential.
2. Object Flow: Activity diagrams can show how objects are created, modified, or moved between activities, not just the flow of control.
3. Swimlanes: While flowcharts can use swimlanes, they are a core feature of Activity Diagrams (Partitions) to group actions by the responsible actor or system subsystem.
4. Standardization: Activity diagrams follow strict UML semantics, whereas flowcharts are often informal.

Swimlanes (or Partitions) in Activity Diagrams are vertical or horizontal lines that divide the diagram into distinct sections.

Significance:

• Responsibility Assignment: They are used to group activities based on who (or what subsystem) is responsible for performing them. For example, one lane might be "User", another "System Interface", and a third "Database".
• Clarity: They enhance readability by clearly showing the hand-offs between different actors or departments.
• Process Analysis: They help in identifying bottlenecks or excessive dependencies between specific roles or system components.
• Structure: They provide a structural view to the dynamic behavior modeled in the diagram.

The Object Modeling Process typically involves the following steps to translate real-world concepts into a software model:

1. Identify Objects/Classes: Analyze requirements (nouns in the problem statement) to find potential objects.
2. Identify Attributes: Determine the data or state (adjectives) associated with each object.
3. Identify Operations (Methods): Determine the behaviors or responsibilities (verbs) of each object.
4. Identify Relationships: Establish how objects interact:
   • Associations (structural connections)
   • Aggregations/Compositions (whole-part)
   • Generalizations (inheritance)
5. Refine the Model: Eliminate redundant classes, define visibility (public/private), and ensure the model meets the requirements.
6. Create Scenarios: Use sequence or communication diagrams to validate that the objects can collaborate to fulfill specific use cases.

Model validation ensures the design is correct, robust, and meets requirements before coding begins.

• Consistency Checking:

  • Ensures that there are no contradictions within the model or between different models.
  • Horizontal Consistency: Checking different diagrams at the same level (e.g., ensuring a message in a Sequence Diagram corresponds to an operation in the Class Diagram).
  • Vertical Consistency: Checking consistency between levels (e.g., Use Case requirements matches the detailed Class Design).

• Completeness Checking:

  • Ensures that all requirements have been addressed.
  • Verifies that every Use Case is realized by a set of classes.
  • Checks that all necessary attributes and methods are defined for a class to function.
  • Ensures no "dangling" relationships or undefined types exist.

Traceability is the ability to link software artifacts (requirements, design, code, tests) to one another.

Types:

• Forward Traceability: From Requirements Design Code Test Cases.
• Backward Traceability: From Code/Tests back to the specific Requirement it satisfies.

Importance:

1. Change Impact Analysis: If a requirement changes, traceability helps identify which code modules and test cases need to be updated.
2. Verification: Ensures that every requirement has been implemented (completeness) and tested.
3. Compliance: often required for safety-critical systems or industry standards.
4. Maintenance: Helps future developers understand why a piece of code exists by linking it back to the business need.

Coding standards are a set of guidelines and best practices for writing code.

Importance:

1. Readability: Uniform code style (naming conventions, indentation) makes it easier for any team member to read and understand code written by others.
2. Maintainability: Consistent structure reduces the effort required to modify or debug the system later.
3. Error Reduction: Standards often forbid dangerous practices (e.g., strict rules on memory management or global variables), leading to fewer bugs.
4. Integration: When multiple developers work on different modules, standards ensure the pieces fit together seamlessly without naming conflicts or style clashes.
5. Code Review Efficiency: Reviewers can focus on logic and architecture rather than arguing about formatting.

Code reviews are systematic examinations of source code.

1. Code Walkthrough:

• Nature: Informal.
• Process: The author of the code leads a team through the code, explaining logic and thought processes.
• Goal: Knowledge transfer, basic sanity check, and gathering feedback.
• Preparation: Minimal preparation required by participants.

2. Code Inspection (Fagan Inspection):

• Nature: Formal and rigorous.
• Process: Roles are assigned (Moderator, Reader, Recorder, Author). The team reviews the code line-by-line using a checklist before the meeting. The meeting focuses on logging defects, not fixing them.
• Goal: Detecting defects (bugs, security issues, standard violations).
• Preparation: High; participants must study the code beforehand.

Comparison: Inspections are data-driven and focus on defect removal, while walkthroughs are author-driven and focus on understanding/consensus.

Scenario: An Online Shopping System allows users to browse items, add them to a cart, proceed to checkout, and pay via credit card.

Modeling Approach:

1. Use Case Diagram: To identify the Actors (Customer, Admin) and high-level goals (Login, Search Items, Checkout, Process Payment).
2. Class Diagram: To model the static structure. Classes would include Customer, Product, ShoppingCart, Order, and Payment. Relationships would show that a Customer has an Order, and an Order contains Products.
3. Sequence Diagram: To model the 'Checkout' process. It would show the timeline of messages: Customer clicks 'Checkout' System validates Cart System requests Payment Bank confirms Payment System creates Order.
4. Activity Diagram: To model the complex logic of the payment flow, including decision nodes (e.g., "Is payment valid?" If Yes, ship; If No, show error) and parallel processing (sending email receipt while updating inventory).

1. Early Risk Mitigation: UP tackles high-risk elements in the early Iterations (Elaboration phase), whereas Waterfall often discovers integration risks at the very end.
2. Accommodates Change: Requirements in UP can be refined with every iteration. Waterfall assumes requirements are frozen early on.
3. Early Feedback: Stakeholders see a working subset of the system early (Executables), allowing for feedback and course correction.
4. Better Progress Monitoring: Progress is measured by working code (increments) rather than just documentation completion.
5. Component Reuse: UP promotes component-based development, making it easier to reuse code modules.

Realization is a relationship between two model elements where one element (the client) realizes (implements) the behavior that the other element (the supplier) specifies.

• Notation: A dashed line with a hollow triangle arrow pointing to the supplier.
• Common Usage:
  1. Interfaces: Between a Class and an Interface. The Interface defines a contract (abstract methods), and the Class implements those methods.
  2. Use Cases: Between a Use Case and a Collaboration (or Class). The Class realizes (carries out) the functionality described in the Use Case text.
• Example: An interface Sortable defines a method sort(). A class Array implements Sortable. We say Array realizes Sortable.

Both model dynamic behavior, but they focus on different aspects:

• State Chart Diagram (State Machine):

  • Focus: Focuses on a single object.
  • Content: Shows the different states an object goes through during its lifecycle in response to events (e.g., an Order object goes from 'New' 'Paid' 'Shipped' 'Delivered').
  • Trigger: driven by external events.

• Activity Diagram:

  • Focus: Focuses on a process or workflow involving multiple objects.
  • Content: Shows the flow of activities (actions) and control logic.
  • Trigger: driven by the completion of the previous activity (internal processing).

Although MVC is an architectural pattern, it is fundamental to OO modeling and development.

• Model: Represents the data and business logic (e.g., Entity classes in a Class Diagram). It manages the state of the application.
• View: The user interface (UI) that displays data to the user. It observes the Model.
• Controller: Handles user input and interactions. It interprets inputs from the View and updates the Model accordingly.

Role in OO Development:

• Separation of Concerns: Decouples the UI from the business logic, making the system easier to maintain and test.
• Reusability: One Model can support multiple Views (e.g., a web view and a mobile view using the same data logic).
• Parallel Development: UI developers can work on Views while backend developers work on Models.

A Requirement Traceability Matrix (RTM) is a document that maps and traces user requirements with test cases.

Benefits:

1. Ensures Coverage: It guarantees that 100% of the requirements have associated test cases, preventing "missed features."
2. Prevents Scope Creep: By linking code to requirements, it helps prevent developers from adding unauthorized features that were not requested.
3. Streamlines Testing: If a specific requirement fails, the RTM allows QA to identify exactly which test cases failed and which code modules are likely responsible.
4. Documentation for Audits: It serves as proof of validation for clients and compliance auditors.
5. Simplifies Regression Testing: When a requirement changes, the RTM identifies specifically which tests need to be re-run.