Object-Oriented Analysis and Design report

Asian School of Management and Technology
Lab Report of Object-oriented analysis and Design
Submitted By: Submitted To:
Ritika Poudel Lecturer: Manish Sapkota
BIM (7th
Semester)
Symbol no: 11205/20

OBJECTIVES:
● To capture the requirements specification for an intended software system,
● To draw the UML diagrams for the given specification,
● To map the design properly to code
● To test the software system thoroughly for all scenarios,
● To improve the design by applying appropriate design patterns.

INTRODUCTION TO UML
The software system and its components can be specified, built, visualized, and documented using
the UML language. A graphical language with rules and semantics is UML. OCL (Object
Constraint Language) is a variant of English that expresses a model's semantics and rules. OCL
specifies a system's attributes using basic logic. It is not the goal of the UML to serve as a visual
programming language.
To have the best of both worlds, it has a much closer mapping to object-oriented programming
languages. The UML is far less complicated than earlier approaches. UML is suitable for modeling
a wide range of systems, including distributed web-based applications, enterprise information
systems, and real-time embedded systems.
Three major language elements:
● UML basic building blocks
● Rules that dictate how this building blocks put together
● Some common mechanism that apply throughout the language
The primary goals in the design of UML are:
1. Provides users with ready to use, expressive visual modeling language as well so they
can develop and exchange meaningful models.
2. Provide extensibility and specialization mechanisms to extend the core concepts.
3. Be independent of programming languages and development processes.
4. Provide a formal basis for understanding the modeling language.
5. Encourage the growth of the OO tools market.
6. Support higher-level development concepts.
7. Integrate best practices and methodologies.

The ideal way to approach any complicated system is with a limited number of almost independent
model viewpoints. There are various fidelity levels at which each model can be expressed. The
most accurate models are grounded. The nine graphical diagrams defined by the UML are:
1. Class diagram
2. Use-case diagram
3. Behavior diagram
3.1. Interaction diagram
3.1.1. sequence diagram
3.1.2. collaboration diagram
3.2. State chart diagram
3.3. activity diagram
4. Implementation diagram
4.1component diagram
4.2deployment diagram
1. UML class diagram:
Another name for the UML class diagram is object modeling. This figure is for static analysis.
The model's static structure is depicted in these diagrams. A class diagram is a network that
connects static model pieces, like classes and their relationships, to both their contents and
each other.
2. Use-case diagram:
Many use-cases, each representing a distinct sequence of events in a system, can be used to
characterize the functionality of a system. It consists of an actor graph, a collection of use cases
surrounded by boundaries, communication, connections between the players and the use cases,
and use case generalization.

3. Behavior diagram:
Unlike every other model previously stated, this one is dynamic. Static diagrams do not make
the objects in an object-oriented system easy to understand because they are dynamic. This
diagram depicts the actions of an object, or the instance of the class. There is a behavior
diagram for each use-case in the system that shows how the object behaves. We may include
a script or interaction diagram to display a timeline of events in addition to the use-case
diagram. Sequence and cooperation diagrams make up this document.
4. Interaction diagram:
It is a collaboration diagram combined with a sequence diagram. It is employed to show how
events in the system have progressed over time. The system's behavior during dynamic
execution is depicted in the interaction diagram, a dynamic model.
5. State chart diagram:
It is made up of events, actions, and states. A well-known method for describing a system's
behavior is a state diagram. They provide a description of every potential state that a specific
thing may enter and how actions that come into contact with the object alter its state. To depict
an object's lifecycle behavior, state diagrams for a single class are typically created in object-
oriented programming (OO) techniques.
6. Activity diagram:
It displays the grouping of the components and their interdependence. These flowcharts are
very helpful when explaining behavior that involves numerous concurrent processing
processes and workflows. An activity is a state of doing something, such as carrying out a
software program or a real-world procedure.
7. Implementation diagram:
It displays the source code structure and the run-time implementation structure, among other
aspects of the system’s development process. Compared to the other high-level diagrams that

have been seen thus far, these are quite straightforward. The component diagram and the
deployment diagram are their two sub-diagrams.
8. Component diagram:
These are the UML model's organizational components. These are boxes that allow a model to
be disassembled. They display the code's internal organization. They simulate the tangible
elements of a design, like the user interface and source code. It's comparable to the idea of
packaging.
9. Deployment diagram:
The runtime system's structure is displayed in the deployment diagram. It displays how the
software components that reside in runtime processing elements are configured. They are
typically used to illustrate the physical distribution of code modules on the system in
conjunction with deployment diagrams.
NOTATION ELEMENTS:
These are the UML model's explanatory components. These are boxes that can be used to
comment on and explain any part of the model. They give the facts needed to comprehend the
diagrams' essential details.
Relations in the UML:
These are four kinds of relationships used in an UML diagram, they are:
● Dependency
● Association
● Generalization
● Realization
Dependency:
It is a semantic relationship in which modifications to one item have an impact on the semantics
of other items. A dependency is graphically represented as a non-continuous line.

Association:
The asset of linkages is described by this structural relationship. An object is being linked to
another item. A solid line that may or may not have a label graphically represents association.
Generalization:
It's a specialized connection where the objects of the generalized element can be replaced by the
specialized elements. Visually, it is an arrowhead parent that is hollow and a solid line.
Realization:
The relationship between the classifiers is semantic. It is shown graphically as a cross between a
dependency connection and generalization.
Where UML can be used:
UML is not just for use with modeling programs. In fact, it is expressive to model non-software
such as to show in structure and behavior of health care system and to design the hardware of the
system.
Use Case Diagram
A use case diagram is a visual representation of the interactions between actors and a system, illustrating
the relationships and dependencies between different use cases (functionalities) within the system. It is
commonly used in the Unified Modeling Language (UML) to specify the functional requirements of a
system.
Notations
● Actors:
Actors represent external entities that interact with the system. These entities can be human users,
external systems, hardware, or other elements that interface with the system being modeled.

● Use Case:
Describes a discrete unit of behavior that has a clearly defined scope. Illustrate what should be
done to achieve the goal of the use case. Shown as an oval shape with the description of the
behavior.
● System Boundaries:
Indicates separation between actors and use cases (internal to the system). Marked by a
bounded box around the use cases.
● Communication Line:
Connects an actor and a use case Indicates participation of an actor. Appears a line between
an actor and the use case.
Relationship in Use Case Diagram
A Use relationship indicates that one element requires another to perform some interaction. An
Association implies that two model elements have a relationship, usually implemented as an
instance variable in one or both Classes. A Generalization is used to indicate inheritance.
● <<include>> Relationship
A use case may reuse all the steps from another use case. It “includes” the steps from another
use case. This can be depicted through <<include>> relationship. (We write include keyword
between angle brackets.) Dashed Arrow end points towards the use case that is reused.

● Generalization
Used to show that one use case is a type of another, but with some changes.
This is shown through the generalization arrow.
▪ Arrowhead points to generalized use case
▪ Tail points to specialized use case.
● <<extend>> Relationship
This is used to specify an optional behavior. This behavior appears as an extended use case.
Shown as dashed arrow with <<extend>> label.

Use case Diagram for Online Food Ordering System

Activity Diagram
An activity diagram portrays the control flow from a start point to a finish point showing the
various decision paths that exist while the activity is being executed. They are used in business
and process modeling where their primary use is to depict the dynamic aspects of a system.
Notations:
● Initial State:
The starting state before an activity takes place is depicted using the initial state. We use a
black filled circle to depict the initial state of a system.
● Activity
An activity represents execution of an action on objects or by objects. We represent an
activity using a rectangle with rounded corners.
● Action Flow or Control flows
Action flows or Control flows are also referred to as paths and edges. They are used to show
the transition from one activity state to another activity state. We use a line with an arrowhead
to depict a Control Flow.

● Decision node and Branching
When we need to decide before deciding the flow of control, we use the decision node. The
outgoing arrows from the decision node can be labelled with conditions or guard expressions.
It always includes two or more output arrows.
● Guard
A Guard refers to a statement written next to a decision node on an arrow sometimes within
square brackets.
● Fork
A fork node is used to split a single incoming flow into multiple concurrent flows. It is
represented as a straight, slightly thicker line in an activity diagram.
● Join
Join nodes are used to support concurrent activities converging into one. For join notations
we have two or more incoming edges and one outgoing edge.

● Time Event
This refers to an event that stops the flow for a time; an hourglass depicts it. We can have a
scenario where an event takes some time to completed.
● Final State or End State
The state which the system reaches when a particular process or activity ends is known as a
Final State or End State. We use a filled circle within a circle notation to represent the final
state in a state machine diagram.

Activity Diagram for Online Food Ordering System

Sequence Diagram
A sequence diagram shows how items interact with one another in a sequential fashion,
demonstrating the order and way processes work together. It describes the order of interactions
inside a system by concentrating on the messages that are transferred between objects throughout
time. Sequence diagrams, which clearly depict the order of events, and the roles engaged in each
phase of the process, are frequently used to describe the flow of control in a system and are helpful
for visualizing complicated interactions in a use case.
Notations:
● Actors
An actor represents a type of role played by an entity external to the subject. Actors interact
with the subject by exchanging signals and data. They can be human users, external hardware,
or other subjects.
● Lifeline
A lifeline represents an individual participant in interaction. It essentially portrays the existence
of an entity over time during the interaction.

● Activation
A thin rectangle on a lifeline represents the period during which an element is performing an
operation. The top and bottom of the rectangle align with the initiation and completion time,
respectively.
Activation
● Call Message
A call message is a type of message that represents the invocation of an operation on the target
lifeline.
● Return Message
A return message represents the passing of information back to the caller of a corresponding
former message.

Sequence Diagram for Online Food Ordering System

Class Diagram
A representation of a system's classes characteristics, methods, and relationships in UML (Unified
Modeling Language) is called a class diagram. The name, characteristics, and methods of each
class are displayed in three separate sections within a box. It is simple to comprehend and design
how various components of the system interact when lines and symbols are used to connect the
classes and represent connections like inheritance, association, and dependencies.
Notations:
● Class Notation: Represented by a rectangular box divided into three sections: the top
section displays the class name, the middle section lists attributes (variables), and the
bottom section lists methods (functions).
● Attributes and Methods: Attributes and methods are usually prefixed with visibility
symbols:
● Relationships:
Association: A solid line between classes, indicating a connection. Multiplicities (e.g., 1,
0.., or 1..) may be added to show the number of instances involved.
Aggregation: Represented by a line with an empty diamond at the end, showing a "whole-
part" relationship where one class is part of another but can exist independently.

Composition: A stronger form of aggregation shown by a filled diamond, where the part
class’s lifecycle depends on the whole (e.g., if the whole is destroyed, the part is too).
Inheritance/Generalization: A solid line with a hollow arrow pointing to the superclass,
showing that one class inherits from another.
Dependency: A dashed line with an open arrow, indicating that one class depends on or
uses another.
● Multiplicity: Numbers near associations (e.g., 1, 0..1, 1..*, or *) define how many
instances of each class can relate to the other.
● Interfaces: An interface is a specification of behavior that implementers agree to meet; it
is a contract. By realizing an interface, classes are guaranteed to support a required
behavior, which allows the system to treat non-related elements in the same way – that is,
through the common interface.

Class Diagram for Online Food Ordering System

Package Diagram
A package diagram in UML organizes system elements into "packages" to simplify complex
architectures, showing dependencies and interactions between different modules. Represented by
labeled rectangles, packages, group related classes, interfaces, or other packages, enabling clearer,
more modular design by visually managing system structure and dependencies.
Notations:
● Package: Represented by a rectangle with a small tab at the top left, labeled with the
package name. This box may contain classes, interfaces, or other packages.
● Subsystem: A subsystem is a self-contained module labeled <<subsystem>>, representing
a cohesive unit of related classes and functions, which simplifies the organization of
complex systems by showing high-level structure and dependencies.
● Dependency: In UML, a dependency is a directional relationship represented by a dashed
arrow, indicating that one element relies on another for its functionality, with potential
impacts from changes in the required element on the dependent element.
● Import: In UML, an import is a relationship that allows a package to access the public
elements of another package, facilitating the use of its classes, interfaces, or components
without requiring full qualification of their names.

● Merge: In UML, merge is a relationship that combines two or more elements, typically
packages or classes, into a single element, often used to simplify the model and eliminate
redundancy while maintaining the connections and dependencies between the merged
elements.

Package Diagram for Online Food Ordering System

Component Diagram
A component diagram in UML visually represents the organization and dependencies among
system components, highlighting their interfaces and interactions. It focuses on the modular
structure of the system, helping to clarify design and facilitate integration during development.
Notations:
● Component Notation: Represented by a rectangular box with a small "gear" icon or the
label <<component>> at the top left, indicating a modular part of the system.
● Interfaces: Specify a set of operations that a component offers or requires, serving as a
contract between the component and its environment.
● Relationships: Depict the connections and dependencies between components and
interfaces.
● Ports: Represent specific interaction points on the boundary of a component where
interfaces are provided or required.

● Artifacts: Represent physical files or data that are deployed on nodes.
● Node: Represent physical or virtual execution environments where components are
deployed.

Component Diagram for Online Food Ordering System

Deployment Diagram
A deployment diagram in UML represents the physical architecture of a system, illustrating the
hardware nodes, software components, and their relationships. It shows how software is deployed
on hardware, including servers, devices, and communication paths, providing insight into system
configuration, performance considerations, and resource allocation for effective implementation.
Notations:
● Component: A component represents a modular and reusable part of a system, typically
implemented as a software module, class, or package. It encapsulates its behavior and data
and can be deployed independently.
● Artifact: An artifact represents a physical piece of information or data that is used or
produced in the software development process. It can include source code files,
executables, documents, libraries, configuration files, or any other item.
● Interface: An interface defines a contract specifying the methods or operations that a
component must implement. It represents a point of interaction between different
components or subsystems.

● Node: A node represents a physical or computational resource, such as a hardware device,
server, workstation, or computing resource, on which software components can be
deployed or executed.
● Communication Path: A straight line that represents communication between two device
nodes. Dashed lines in deployment diagrams represents relationships or dependencies
between elements, indicating that one element is related to or dependent on another.

Deployment Diagram for Online Food Ordering System

Object-Oriented Analysis and Design report

More Related Content

Similar to Object-Oriented Analysis and Design report (20)

Recently uploaded (20)

Object-Oriented Analysis and Design report