SYSTEM DEVELOPMENT

ANALYSIS & DESIGN

UNIT I: UML DIAGRAMS
Introduction to OOAD
Object-Oriented Analysis and Design (OOAD) is a method used in software engineering to design and
analyze systems. It combines object-oriented programming (OOP) principles and practices with
systematic analysis to create efficient, reusable, and modular systems.
Here’s a breakdown of the key components:
1. Object-Oriented Programming (OOP)(4 Marks)
OOP is a programming paradigm that uses the concept of "objects" to design and build applications.
Objects represent real-world entities or abstractions, each encapsulating data (attributes) and behavior
(methods).
Key concepts of OOP:
Class: A blueprint for creating objects. It defines attributes and behaviors.
Object: An instance of a class that holds data and can perform actions.
Encapsulation: Hiding the internal details and exposing only what’s necessary.
Abstraction: Representing only essential features while hiding the complex details.
Inheritance: Creating new classes from existing ones, inheriting their properties and behaviors.
Polymorphism: The ability to present the same interface for different underlying forms (data types).
2. Object-Oriented Analysis (OOA)
OOA focuses on understanding the problem domain by analyzing the
system's requirements and defining the objects that will form the system.
The goal is to identify:
Entities (Objects) that will be used in the system.
Relationships between these objects.
Behaviors and functionalities of each object
Steps in OOA:
Identify the actors: External entities that interact with the system (e.g.,
users, other systems).
Define the use cases: Describe how actors will interact with the system.
Build models: Create diagrams like class diagrams and object models to
represent objects and their relationships.
Object-Oriented Design (OOD)
OOD takes the analysis and transforms it into a design model, ensuring
that the system’s architecture aligns with the requirements. The focus
here is on how the system will be implemented.
Steps in OOD:
Design the class structure: Identify and define classes, their attributes,
methods, and relationships.
Determine interfaces: Define how different objects will communicate with
each other.
Apply design patterns: Use standard solutions (like Singleton, Observer,
etc.) to common design problems.
Create diagrams: Use UML (Unified Modeling Language) diagrams to
represent the system’s structure and behavior.
Benefits of OOAD:
Modularity: Breaking the system into manageable, modular components (objects).
Reusability: Objects can be reused across different projects.
Scalability and Maintainability: Easier to update and scale the system.
Clear Mapping to Real-World: Object-oriented systems mirror real-world entities,
making them intuitive to design and understand.
Common Diagrams in OOAD:
Class Diagrams: Show the static structure of the system (classes and relationships).
Use Case Diagrams: Show the interactions between users (actors) and the system.
Sequence Diagrams: Illustrate how objects interact in a sequence to accomplish
tasks.
Activity Diagrams: Represent workflows and business processes
Unified Process (UP)

• The Unified Process (UP) is a popular software development process

framework that is driven by use-case modeling and focuses on iterative and
incremental development. The most well-known adaptation of UP is the
Rational Unified Process (RUP), developed by Rational Software (now part of
IBM). It provides a disciplined approach to assigning tasks and responsibilities
in a development organization and aims to ensure the production of high-
quality software that meets user needs.
• The Unified Process (UP) in Object-Oriented Analysis and Design (OOAD) is
a flexible and iterative approach to developing software. It focuses on creating
working software increments, collaborating with team members, and
adapting to changes.
What is Unified Process?(2 Mark)
The Unified Process (UP) in Object-Oriented Analysis and Design (OOAD) is a
software development methodology that emphasizes iterative development,
collaboration, and flexibility. It is based on the Unified Modeling Language (UML)
and is characterized by its use of use cases to drive development, its focus on
architecture-centric development, and its emphasis on risk management and
incremental delivery. UP is a flexible and adaptable process that can be tailored to
meet the specific needs of a project or organization, making it a popular choice for
many software development teams.
Importance of Unified Process
Comple-x software projects are made- more manageable by Unified Process. It
breaks them into smaller, iterative- chunks.
Clear guidelines and workflows from Unified Process boost communication. It
e-nsures stakeholder collaboration is seamless.
Continuous feedback is e-mphasized by UP's approach. High-quality software
mee-ting requirements are the- result.
Key Principles of Unified Process
Below are the key principles of the Unified Process:
Iterative and Incremental: Unified Process divides the development process
into multiple iterations, with each iteration adding new functionality
incrementally.
Use Case Driven: The Unified Process focuses on identifying and prioritizing
use cases that represent the system's functionality from the user's perspective.
Architecture-Centric: The Unified Process emphasizes defining and refining
the system architecture throughout the development process.
Risk Management: Unified Process identifies and manages project risks
proactively to minimize their impact on the project's success.
Continuous Validation: Unified Process ensures continuous validation of the
system's requirements, design, and implementation through reviews, testing,
and feedback.
Phases of Unified Process
Unified Process (UP) is characterized by its iterative and incremental approach to
software development. The phases in Unified Process provide a structured framework
for managing the various activities and tasks involved in building a software system.
Here's an in-depth look at each phase:
1. Inception
This is the initial phase where the project's scope, objectives, and feasibility are
determined. Key activities in this phase include identifying stakeholders, defining the
initial requirements, outlining the project plan, and assessing risks. The goal of this
phase is to establish a solid foundation for the project and ensure that it is worth
pursuing.
2. Elaboration
In this phase, the project requirements are analyzed in more detail, and the architecture
of the system is defined. Key activities include developing use cases, creating the
architectural baseline, identifying key components, and refining the project plan. The
goal of this phase is to mitigate major risks and establish a solid architectural
foundation for the project.
3. Construction
This is the phase where the actual implementation of the system takes place.
Key activities include developing, testing, and integrating the system
components, as well as continuously verifying that the system meets the
requirements. The goal of this phase is to build a complete, high-quality
software product that is ready for deployment.
4. Transition
In this final phase, the software is deployed to end users. Key activities include
user training, final system testing, and transitioning the system to the
operations and maintenance team. The goal of this phase is to ensure a smooth
transition from development to production and to address any issues that arise
during deployment.
These phases are iterative, meaning that they may be revisited multiple times
throughout the project to incorporate feedback, make improvements, and
address changes in requirements. This iterative approach allows for flexibility
and adaptability, making the Unified Process well-suited for complex and
evolving software projects.
Workflows in Unified Process
Below are the different workflows in the Unified Process:
Requirements Workflow: Identifies, analyzes, and prioritizes system requirements, ensuring
alignment with stakeholder needs.
Analysis and Design Workflow: Translates requirements into system designs, defining the
architecture and high-level structure of the system.
Implementation Workflow: Implements system functionality based on design specifications,
coding and integrating components as needed.
Test Workflow: Designs and executes test cases to verify system functionality, ensuring the
software meets quality standards.
Deployment Workflow: Prepares and transitions the system for deployment, ensuring a smooth
transition from development to production.
Configuration and Change Management: Manages configuration items and tracks changes,
ensuring version control and integrity throughout development.
Project Management Workflow: Oversees project progress, resources, and schedule, ensuring
timely delivery and adherence to quality standards.
Environment Workflow: Sets up and maintains development, testing, and production
Roles and Responsibilities of Unified Process
In the Unified Process (UP), there are several roles with specific responsibilities that contribute to the
successful development of a software system. These roles and their responsibilities include:
Responsible for overall project planning, scheduling, resource allocation, and
coordination of activities. The project manager ensures that the project is completed on time, within
budget, and meets the specified requirements.
Responsible for defining the overall architecture of the system, including its structure,
components, and interactions. The architect ensures that the system is scalable, maintainable, and meets
the desired quality attributes.
Responsible for gathering and analyzing requirements from stakeholders and translating them
into detailed specifications. The analyst also helps to identify risks and propose mitigation strategies.
Responsible for creating detailed designs for the system, including class diagrams, sequence
diagrams, and other UML diagrams. The designer works closely with the architect to ensure that the
design aligns with the overall architecture.
Responsible for implementing the system according to the design specifications. The
developer writes code, tests it, and integrates it with other components of the system.
Responsible for testing the system to ensure that it meets the specified requirements and is free
of defects. The tester develops test cases, executes them, and reports any issues found.
Iterative and Incremental Development in Unified Process(4 Marks)
Software de-velopment is often split into smalle-r parts. This is called Iterative and
Incre-mental Developme-nt. It's an important idea in Unified Process (UP) and othe-r
agile methods. The proce-ss is divided into iterations or increme-nts. Each one adds
new feature-s or improves existing ones.
Principle-s of Interative and Incremental Development:
Iterative Approach: Development occurs in cycles or iterations, with each iteration
delivering incremental improvements.
Incremental Delivery: Software is built incrementally, with each iteration providing
a subset of the system's functionality.
Feedback-driven: Regular feedback from stakeholders drives the development
process, ensuring alignment with user needs.
Adaptability: The development process is flexible and can accommodate changes in
requirements, priorities, and constraints.
Benefits of Iterative and Incremental Development:
Early and Continuous Delivery: Stakeholders receive working software early and
frequently, enabling rapid validation and feedback.
: Early identification and mitigation of risks through regular iterations
and testing.
Transparency into the project's progress facilitates
informed decision-making and management of expectations.
Ability to incorporate changes and evolving requirements
throughout the development process.
Continuous testing and validation lead to higher quality
software with reduced defects.
Active involvement of stakeholders ensures better
understanding of requirements and increased satisfaction with the final product.
How to Adapt and Scale Unified Process to Different Project Needs
How to Adapt Unified Process?
Customize phases, workflows, and artifacts to fit the project's size and complexity.
Adjust iteration lengths and team roles based on project timelines and requirements.
Tailor documentation and deliverables to meet specific project needs and stakeholder
expectations.
How to Scale Unified Process?
Integrate UP practices with other methodologies like Agile or Scrum for larger projects.
Establish governance structures and standardized processes for consistency across
teams.
Invest in training and skill development to ensure teams can effectively apply UP
principles.
Continuously evaluate and refine the adapted UP process based on feedback and
performance metrics.
Benefits of Unified Process
Unified Process (UP) offers several benefits and challenges. Benefits include iterative
development, risk management, quality assurance, stakeholder collaboration, and flexibility.
Challenges of Unified Process
Challenges include complexity, overhead, learning curve, scope
management, and adoption resistance.
Unified Modeling Language (UML)(12 Marks)
• A Use Case Diagram in Unified Modeling Language (UML) is a visual
representation that illustrates the interactions between users (actors) and a
system.
• It captures the functional requirements of a system, showing how
different users engage with various use cases, or specific functionalities,
within the system.
• Use case diagrams provide a high-level overview of a system’s behavior,
making them useful for stakeholders, developers, and analysts to
understand how a system is intended to operate from the user ’s
perspective, and how different processes relate to one another.
• They are crucial for defining system scope and requirements.
What is a Use Case Diagram in UML?
A Use Case Diagram is a type of Unified Modeling Language (UML)
diagram that represents the interaction between actors (users or external
systems) and a system under consideration to accomplish specific goals. It
provides a high-level view of the system’s functionality by illustrating the
various ways users can interact with it.
When to apply Use Case Diagram?
Use case diagrams are useful in several situations. Here’s when you
should consider using them:
üWhen you need to gather and clarify user requirements, use case
diagrams help visualize how different users interact with the system.
üIf you’re working with diverse groups, including non-technical
stakeholders, these diagrams provide a clear and simple way to convey
system functionality.
üDuring the system design phase, use case diagrams help outline user
interactions and plan features, ensuring that the design aligns with user
needs.
üWhen defining what is included in the system versus what is external, use
case diagrams help clarify these boundaries.
Use Case Diagram Notations
UML notations provide a visual language that enables software developers, designers,
and other stakeholders to communicate and document system designs, architectures, and
behaviors in a consistent and understandable manner.
1. Actors
Actors are external entities that interact with the system. These can include users, other
systems, or hardware devices. In the context of a Use Case Diagram, actors initiate use
cases and receive the outcomes. Proper identification and understanding of actors are
crucial for accurately modeling system behavior.
2. Use Cases
Use cases are like scenes in the play. They represent specific things your
system can do. In the online shopping system, examples of use cases could
be “Place Order,” “Track Delivery,” or “Update Product Information”. Use
cases are represented by ovals.
3. System Boundary
The system boundary is a visual representation of the scope or limits of the system you
are modeling. It defines what is inside the system and what is outside. The boundary
helps to establish a clear distinction between the elements that are part of the system and
those that are external to it. The system boundary is typically represented by a
rectangular box that surrounds all the use cases of the system.
Use Case Diagram Relationships
In a Use Case Diagram, relationships play a crucial role in depicting the interactions
between actors and use cases. These relationships provide a comprehensive view of
the system’s functionality and its various scenarios. Let’s delve into the key types of
relationships and explore examples to illustrate their usage.
1. Association Relationship
The Association Relationship represents a communication or interaction between an
actor and a use case. It is depicted by a line connecting the actor to the use case. This
relationship signifies that the actor is involved in the functionality described by the
use case.
Example: Online Banking System
Actor: Customer
Use Case: Transfer Funds
Association: A line connecting the “Customer” actor to the “Transfer Funds” use
case, indicating the customer’s involvement in the funds transfer process.
 Include Relationship
The Include Relationship indicates that a use case includes the functionality
of another use case. It is denoted by a dashed arrow pointing from the
including use case to the included use case. This relationship promotes
modular and reusable design.
Example: Social Media Posting
Use Cases: Compose Post, Add Image
Include Relationship: The “Compose Post” use case includes the
functionality of “Add Image.” Therefore, composing a post includes the
action of adding an image.
3. Extend Relationship
The Extend Relationship illustrates that a use case can be extended by
another use case under specific conditions. It is represented by a dashed
arrow with the keyword “extend.” This relationship is useful for handling
optional or exceptional behavior.
Example: Flight Booking System
Use Cases: Book Flight, Select Seat
Extend Relationship: The “Select Seat” use case may extend the “Book
Flight” use case when the user wants to choose a specific seat, but it is an
optional step.
Generalization Relationship
The Generalization Relationship establishes an “is-a” connection between
two use cases, indicating that one use case is a specialized version of
another. It is represented by an arrow pointing from the specialized use
case to the general use case.
Example: Vehicle Rental System
Use Cases: Rent Car, Rent Bike
Generalization Relationship: Both “Rent Car” and “Rent Bike” are
specialized versions of the general use case “Rent Vehicle.”
How to draw a Use Case diagram in UML?(4 Marks)
Below are the main steps to draw use case diagram in UML:
Step 1: Identify Actors: Determine who or what interacts with the system. These are your actors.
They can be users, other systems, or external entities.
Step 2: Identify Use Cases: Identify the main functionalities or actions the system must perform.
These are your use cases. Each use case should represent a specific piece of functionality.
Step 3: Connect Actors and Use Cases: Draw lines (associations) between actors and the use
cases they are involved in. This represents the interactions between actors and the system.
Step 4: Add System Boundary: Draw a box around the actors and use cases to represent the
system boundary. This defines the scope of your system.
Step 5: Define Relationships: If certain use cases are related or if one use case is an extension
of another, you can indicate these relationships with appropriate notations.
Step 6: Review and Refine: Step back and review your diagram. Ensure that it accurately
represents the interactions and relationships in your system. Refine as needed.
Step 7: Validate: Share your use case diagram with stakeholders and gather feedback. Ensure
that it aligns with their understanding of the system’s functionality
Use Case Diagram example(Online Shopping System)
Let’s understand how to draw a Use Case diagram with the help of an Online
Shopping System:
Actors:
• Customer
• Admin
Use Cases:
• Browse Products
• Add to Cart
• Checkout
• Manage Inventory (Admin)
Relations:
• The Customer can browse products, add to the cart, and complete the checkout.
• The Admin can manage the inventory.
Below is the use case diagram of an Online Shopping System:
Class Diagram
A Class Diagram is a type of static structure diagram in the Unified Modeling Language
(UML) that describes the structure of a system by showing its classes, attributes, operations,
and the relationships among objects. It's a key tool in object-oriented design that helps
visualize and define the architecture of a software system.

• Classes: Represented as boxes divided into three sections:

• Class Name: The name of the class appears at the top of the box.
• Attributes: The properties or fields of the class.
• Methods/Operations: Functions that the class can perform.
• Attributes: Describe the properties of the class. They have:
• Name
• Type (e.g., integer, string)
• Visibility (+ for public, - for private, # for protected)
Operations/Methods: Define the behavior of the class. Methods can also have
visibility modifiers and parameters.

• Association: A relationship between two classes, often shown with a line connecting
the two classes.
• Multiplicity: Specifies how many instances of a class can be associated with one
instance of another class. (e.g., 1..*, 0..1)
• Aggregation: A special type of association that represents a "whole-part" relationship.
Shown with a hollow diamond at the "whole" end.
• Composition: A stronger form of aggregation, where the part cannot exist without the
whole. Shown with a filled diamond.
• Inheritance/Generalization: A relationship where one class (child) inherits from
another (parent). Represented by a line with a hollow triangle pointing to the parent
class.
• Dependency: A weaker relationship indicating that one class uses another. Shown as a
dashed arrow.
Example:
Imagine a simple system with the following classes: Person, Student, and Teacher.
+---------------------+
| Person |
+---------------------+
| -name: String |
| -age: int |
+---------------------+
| +getDetails(): void |
Inheritance: Student and Teacher inherit from
+---------------------+ Person.
▲ Attributes: Each class has its attributes (name,
| age, studentID, teacherID).
|
Methods: Operations like getDetails(), enroll(),
+-------------------+ +--------------------+
and teach() define behavior
| Student | | Teacher |
+-------------------+ +--------------------+
| -studentID: int | | -teacherID: int |
+-------------------+ +--------------------+
| +enroll(): void | | +teach(): void |
+-------------------+ +--------------------+
Interaction Diagrams (12 Marks)
Interaction Diagrams in UML (Unified Modeling Language) are used to
visualize the flow of control and data among different components or
objects in a system. They are crucial in modeling how objects collaborate to
achieve a particular behavior or functionality. The two primary types of
interaction diagrams are Sequence Diagrams and Communication Diagrams.
Both depict interactions but in slightly different ways.
1. Sequence Diagrams
A Sequence Diagram shows the interaction between objects arranged in a time
sequence. It represents how objects or components in the system exchange
messages or signals over time.
Key Components of Sequence Diagrams:
1. Lifeline: A vertical dashed line representing the existence of an object over
time.A lifeline represents an individual participant in a sequence diagram. A
lifeline will usually have a rectangle containing its object name. If its name is
"self", that indicates that the lifeline represents the classifier which owns the
sequence diagram.
Sometimes a sequence diagram will have a lifeline with an actor element
symbol at its head. This will usually be the case if the sequence diagram is
owned by a use case. Boundary, control and entity elements from
robustness diagrams can also own lifelines.
Messages
Messages are displayed as arrows. Messages can be complete, lost or found;
synchronous or asynchronous; call or signal. In the following diagram, the
first message is a synchronous message (denoted by the solid arrowhead)
complete with an implicit return message; the second message is
asynchronous (denoted by line arrowhead), and the third is the
asynchronous return message (denoted by the dashed line).
Execution Occurrence
A thin rectangle running down the lifeline denotes the execution occurrence, or activation
of a focus of control. In the previous diagram, there are three execution occurrences. The
first is the source object sending two messages and receiving two replies; the second is
the target object receiving a synchronous message and returning a reply; and the third is
the target object receiving an asynchronous message and returning a reply.
Self Message

A self message can represent a recursive call of an

operation, or one method calling another method
belonging to the same object. It is shown as
creating a nested focus of control in the lifeline’s
execution occurrence.
Lost and Found Messages
Lost messages are those that are either sent but do not arrive at the intended
recipient, or which go to a recipient not shown on the current diagram.
Found messages are those that arrive from an unknown sender, or from a
sender not shown on the current diagram. They are denoted going to or
coming from an endpoint element.
Lifeline Start and End
A lifeline may be created or destroyed during the timescale represented by a
sequence diagram. In the latter case, the lifeline is terminated by a stop
symbol, represented as a cross. In the former case, the symbol at the head of
the lifeline is shown at a lower level down the page than the symbol of the
object that caused the creation. The following diagram shows an object
being created and destroyed.
Activation Bar: A thin rectangle on the lifeline that shows when an object is
active (i.e., performing an operation).
Return Messages: Dashed arrows representing the return of control to the
calling object.
Loops and Conditionals: Diagrams may include loop blocks (alt, opt, etc.)
to indicate repetitive or conditional flows.
2. Communication Diagrams (Collaboration Diagrams)
A Communication Diagram focuses on showing how objects interact with
one another through message passing, but it doesn’t emphasize the time
sequence as strongly as the sequence diagram. Instead, it shows a network
of objects and how they are linked to each other with messages.
Importance of Collaboration Diagrams
Collaboration diagrams is important for understanding communication, design, analysis, and
documentation of the system's architecture and behavior.
Visualizing Interactions:
These diagrams offer a clear visual representation of how objects or components interact within a
system.
This visualization helps stakeholders in understanding the flow of data and control for easier
understanding.
Understanding System Behavior:
By showing interactions, collaboration diagrams provide insights into the system's dynamic
behavior during operation.
Understanding this behavior is important for identifying potential issues, optimizing performance,
and ensuring the system functions smoothly.
Facilitating Communication:
Collaboration diagrams provide an effective communication tools among team members.
They facilitate discussions, enabling refinement of the system's design, architecture, and
Components and their Notations in Collaboration Diagrams
There are several components in Collaboration Diagram. Let's see those components
and their notations:
1. Objects/Participants
Objects are represented by rectangles with the object's name at the top. Each object
participating in the interaction is shown as a separate rectangle in the diagram. Objects
are connected by lines to indicate messages being passed between them.
2. Multiple Objects
Multiple objects are represented by rectangles,each with the object's name
inside, and interactions between them are shown using arrows to indicate
message flows.
3. Actors
They are usually shown at the top or side of the diagram. Actors indicate
their involvement in the interactions with the system's objects or
components. They are connected to objects through messages, showing the
communication with the system
Thank You