OOAD Unit-2 2.1 Inception

Inception

• Inception is the first phase of Object-Oriented Analysis and Design (OOAD) methodology, which involves gathering information and understanding the requirements for a new software project.
• The main objective of the inception phase is to establish the scope of the project, identify the stakeholders, and define the initial set of requirements.
• Activities involved in the inception phase include:
  • Identifying the problem: analyzing the problem that the software is intended to solve.
  • Defining the scope: defining the features, functionality, and limitations of the software.
  • Identifying stakeholders: identifying the users, customers, and developers involved in the project.
  • Establishing project goals and objectives: establishing the goals and objectives of the project, including timelines, budget, and resource requirements.
  • Creating the initial requirements: developing the initial set of requirements for the software.

Artifacts in Inception

• Vision and Business Case: describes the high-level goals and constraints, the business case, and provides an executive summary.
• Use-Case Model: describes the functional requirements, including the names of most use cases and their detailed analysis.
• Supplementary Specification: describes other requirements, mostly non-functional, including key non-functional requirements that have a major impact on the architecture.
• Glossary: includes key domain terminology and data dictionary.
• Risk List and Risk Management Plan: describes the risks (business, technical, resource, and schedule) and ideas for their mitigation or response.
• Prototypes and proof-of-concepts: clarifies the vision and validates technical ideas.
• Iteration Plan: describes what to do in the first elaboration iteration.
• Phase Plan and Software Development Plan: provides a low-precision guess for elaboration phase duration and effort.
• Development Case: describes the customized UP steps and artifacts for the project.

Requirements

• Requirements are capabilities and conditions needed by a user to solve a problem or achieve an objective.
• Types of requirements:
  • Functional Requirements: describe the specific functions and features that the software system should perform.
  • Non-functional Requirements: specify the characteristics of the software system that are not related to its functionality but are essential for its effective operation.
• Categories of requirements:
  • User Requirements: describe the needs and expectations of the end-users of the software system.
  • System Requirements: describe the hardware and software infrastructure that the software system needs to operate correctly.
  • Design Requirements: describe the technical design of the software system.
  • Domain Requirements: are the requirements that are characteristic of a particular category or domain of projects.

Use Cases

• A use case represents a sequence of actions that the system performs in response to an external event to achieve a specific goal or objective.
• Elements of a use case:
  • Actors: persons, organizations, or systems that interact with the software system being developed.
  • Use Case Name: a concise name that describes the specific functionality of the use case.
  • Description: a detailed narrative of the steps involved in the use case.
  • Preconditions and Postconditions: describe the conditions that must be true before the use case can be executed and the state of the system after the use case is completed.
• Use Case Model: defines the user's objective, the interactions between the system and the user, and the system's behavior required to meet these objectives.
• Components of the Basic Model:
  • Actor: a person, organization, or system that interacts with the software system.
  • Use Case: defines how actors use a system to accomplish a specific objective.
  • Associations: define the associations among actors and use cases.

Use Case Diagram

• Use Case Diagrams are used to model the behavior of a system, subsystem, or class.
• Components of a Use Case Diagram:
  • Actors: the users that interact with a system.
  • System: a specific sequence of actions and interactions between actors and the system.
  • Goals: the end result of most use cases.
• Use Case Diagram symbols and notation:
  • Use cases: horizontally shaped ovals that represent the different uses that a user might have.
  • Actors: stick figures that represent the people actually employing the use cases.
  • Associations: a line between actors and use cases.
  • System boundary boxes: a box that sets a system scope to use cases.
  • Packages: a UML shape that allows you to put different elements into groups.

Use Case Diagram Library System Project

• The library system project involves two users: Librarian and Student.
• Both Librarian and Student can perform activities after logging in to the library management system.
• Librarian activities: add publication, add books, add branch, add student, issue book, return book, apply penalty, change password, view reports.
• Student activities: search book, issue/return book report, penalty report, change password.

Activity Diagram

• An activity diagram visually presents a series of actions or flow of control in a system, similar to a flowchart or data flow diagram.
• Activity diagrams are often used in business process modeling.
• Symbols used in activity diagrams:
  • Activity nodes: represent the different actions or steps in the process.
  • Control (Activity) flow arrows: connect the activity nodes and represent the sequence of actions in the process.
  • Decision nodes: indicate a branching point in the process, where the flow can follow different paths based on a condition.
  • Merge nodes: indicate a point in the process where multiple flows come together into a single flow.
  • Swimlanes: used to organize activities and show the different actors or organizations involved in the process.
  • Synchronization: used to split a single incoming flow into multiple concurrent flows and join multiple concurrent flows back into a single outgoing flow.
  • Flow final nodes: indicate the end of a flow.
  • Object nodes: represent objects or entities involved in the process.