EYE OPTICAL MANAGEMENT SYSTEM

SOFTWARE ENGINEERING LAB

SLOT: L13+ L14
VL2023240505809

SUBMITTED BY:
ARUN.U
21BCE3187

1|Page
 Assessment – III

1. Analyse the Behavioral Modeling using State Transition Diagram.

Introduction:

A State Transition Diagram (STD) which shows the order of states

underwent by an object within the system.It captures the software
system's behaviour. It models the behaviour of a class, a subsystem, a
package, and a complete system.It tends out to be an efficient way of
modelling the interactions and collaborations in the external entities
and the system.It models event-based systems to handle the state of
an object. It also defines several distinct states of a component
within the system. Each object/component has a specific state.
It is a valuable tool for modelling the behaviour of an Eye Optical
Management System's order fulfillment process. It visually depicts
the various states an order can be in (pending, processing, shipped,
etc.) and the events that trigger transitions between these states.

Advantages:
 Clarity: STDs provide a clear and concise picture of the order
lifecycle, making it easier to understand how orders flow within
your system. This is beneficial for developers, system analysts,
and anyone needing to grasp the overall order handling
process.
 Communication: These diagrams act as a common language for
discussing your system's functionalities with stakeholders. They
can be used to identify potential bottlenecks, areas for

2|Page
 improvement, and ensure a smooth order fulfillment
experience.
 Error Identification: By visualizing the transitions between
states, STDs can help pinpoint potential issues in the order
handling process. For instance, an STD might reveal a missing
state for handling order cancellations or a lack of clarity on how
backordered items are managed.
 Documentation: STDs serve as documentation for the system's
behaviour, especially helpful when maintaining or modifying
the Eye Optical Management System in the future.

Disadvantages:
 Complexity: As your system grows and the order fullfillment
process becomes more intricate, STD can become cluttered and
difficult to understand. It's important to maintain focus on core
states and transitions to avoid overwhelming complexity.
 Limited Scope: STDs primarily focus on the order lifecycle. They
are less suited for modelling complex business rules or user
interactions within your system. Use case diagrams or other
behavioural modelling techniques might be more appropriate
for those aspects.
 Oversimplification: While beneficial, STDs may not capture
every intricate detail of the real-world order fulfillment process.
There might be exceptions or edge cases that the STD doesn't
explicitly represent.

3|Page
Components and Relationships:
States:
 Pending: Customer places an order, awaiting confirmation.
 Payment Processing: Order is confirmed, payment is being
processed.
 Invoice Generation: Payment successful, order is being
prepared.
 On Hold: Payment issue or awaiting customer information (e.g.,
prescription details).
 Order Shipped: Order is packaged and shipped to the customer.
 Delivered: Order is received by the customer.
 Cancelled: Order is cancelled by the customer or due to stock
issues.

Events (Causing Transitions):

 Order Placed: Triggers transition from "Pending" to "Payment
Processing."
 Payment Confirmed: Triggers transition from "Payment
Processing" to "Invoice Generation."
 Payment Failed: Triggers transition from "Payment Processing"
to "On Hold."
 Information Received: Triggers transition from "On Hold" to
"Invoice Generation" (if awaiting info) or "Cancelled" (if order
cannot be fulfilled).
 Order Prepared: Triggers transition from "Invoice Generation"
to "On Hold" (if stock issues arise) or "Order Shipped."
 Shipped: Triggers transition from "Order Shipped" to
"Delivered."
 Delivered: Final state, no further transitions.

4|Page
  Cancelled: Final state, no further transitions (can occur from
multiple states).

Construction of State Transition Diagram:

 Identify States: List the different order states based on the
project's workflow.
 Define Events: Determine the actions or occurrences that cause
transitions between states.
 Draw the Diagram: Use a diagramming tool or create a simple
sketch. (Star uml)
 Represent states as circles or rectangles.
 Use arrows to show transitions between states, labelled with
the events that trigger them.

5|Page
 State Transition Diagram (Star UML):

2. Describe the OO using Use case Model, Class Model.

Use case Model:

1. Introduction about the Diagram

A use case diagram is a visual representation of the interactions

between users (actors) and a system. It depicts the functionalities
(use cases) that the system provides from the user's perspective.

6|Page
This Use Case Diagram (UCD) visually depicts the essential functions
(use cases) of the Eye Optical Management System and the
interactions between users (actors) and these functions.
This UCD helps stakeholders (developers, managers, etc.) grasp the
system's capabilities and intended user flows.

2. Components and Relationships

Actors

 Customer: The primary user, interacting with the system for

browsing, ordering, and managing orders, and providing
feedback.
 Admin: Manages the core elements of the system, including
product listings and inventory.
 Employee: Handles order fulfillment, payment processing, and
responding to customer inquiries.

Use Cases

 Browse Products: Allows customers to search and explore

product offerings.
 Add to Cart: Enables customers to select products for purchase.
 Place Order: The core function where customers finalize their
purchases.
 View Order Status: Gives customers visibility into the order
(placed, shipped, delivered, etc.).
 Update/Cancel Order: Provides flexibility for customers to
modify or cancel orders, potentially before fulfillment.
7|Page
  Inquiries and Feedback: Facilitates customer-initiated
communication for questions, concerns, or suggestions.
 Manage Products: Admin function for adding, editing, and
deleting product information.
 Process Order: Employee function for handling the various
stages of order fulfillment.
 Process Payment: Secure handling of customer payment
transactions.
 Update Stock: Ensures inventory levels are accurately reflected,
managed by both admins and employees.
 Promotions and Sale Update: (Potentially) Admin function for
managing promotional offers or sale events.

Relationships

 Associations: Lines connecting actors to use cases they perform.

 Include: a dotted line labeled <<include>> beginning at base
use case and ending with an arrows pointing to the include use
case. The include relationship occurs when a chunk of behavior
is similar across more than one use case.Indicates mandatory
actions within another use case ( e.g., payment is always part of
placing an order).
 Extend: a dotted line labeled <<extend>> with an arrow toward
the base case. The extending use case may add behavior to the
base use case. The base class declares “extension points”.

 Associations
Customer -> Browse Products
Customer -> Add to Cart
Customer -> Place Order

8|Page
Customer -> View Order Status
Customer -> Update/Cancel Order
Customer -> Inquiries and Feedback
Admin -> Manage Products
Admin -> Update Stock
Employee -> Process Payment
Employee -> Inquiries and Feedback
Employee -> Process Order
Employee -> Update Stock
 Include
Place Order <<include>> Process Payment
Update Stock <<include>> Promotions and Sales Update
 Extend
Update/Cancel Order <<extend>> Request Return/Exchange

3. Advantages and Disadvantages

Advantages

 User-focused: Illustrates the system from a user perspective,

ensuring it satisfies user needs.
 Clear Scope: Outlines the system's essential functionalities.
 Communication Tool: Facilitates discussions about the system
between technical and non-technical stakeholders.

9|Page
  Foundation for Development: Provides a blueprint to guide
system design and implementation.

Disadvantages

 Simplification: UCDs may oversimplify certain processes; might

necessitate additional diagrams to capture greater detail.
 Lack of Process Flow: Focus is on interactions, not the step-by-
step process flow within a use case.
 Potential for Ambiguity: Without clear descriptions, UCDs might
be subject to misinterpretation.
4. Construction of the Diagram

 Identify Actors: Define the different roles interacting with the

system (Customer, Admin, Employee, potentially others if the
system expands).
 Define Use Cases: List the discrete actions each actor needs to
perform (place orders, manage inventory, etc.). Consider
breaking down complex actions into smaller use cases.
 Establish Relationships: Draw associations between actors and
use cases. Utilize include for essential sub-processes within a
use case
 Refine and Review: Get feedback and revise your UCD to gain
clarity and ensure it accurately represents your system's design.

10 | P a g e
Use Case Diagram:

11 | P a g e
Class model:

1.Introduction
In object-oriented programming (OOP), a class is a blueprint or
template for creating objects. Objects are instances of classes, and
each class defines a set of attributes (data members) and methods
(functions or procedures) that the objects created from that class will
possess. The attributes represent the characteristics or properties of
the object, while the methods define the behaviours or actions that
the object can perform.
This class diagram serves as a blueprint for the object-oriented code
of our Eye Optical Management System. It illustrates how objects like
Customer, Order, and Product interact with each other, providing a
framework for our system's implementation

2.Components and relationships:

Classes,attributes and operations
 Customer
customerID: int
name: String
address: String
contactInfo: String

operations:
Registers()
Login()
Update power specifications()(lens)
Browse Products()
12 | P a g e
Place order()
Update profile()
Inquiries and feedback()

 Order
orderID: int
customerID: int
orderDate: Date
orderStatus: String
deliveryID: int
OrderItem (Connecting Order and Product)

operations:
Add n remove item()
Update quantity()
Confirm order()
Cancel order()

 Product
productID: int
name: String
type: String
brand: String
price: double
stock: int

operations:
Update()

 Payment
paymentID: int
13 | P a g e
orderID: int
amount: double
paymentMethod: String
paymentDate: Date

operations:
Process Payment()
Generate receipt()

 Delivery
deliveryID: int
orderID: int
shippingAddress: String
deliveryStatus: String
deliveryDate: Date

operations:
Update Status()

 Employee
employeeID: int
name: String
Address: String
Contact: String
Department: String

operations:
Inquiries and feedback()
14 | P a g e
Process Payment()
Process order()
Update stock()

 Admin
adminID: int
Name
Contact

operations:
Manage Product()
Update stock()

Relationships

 Customer places Order (1:M Association)

 Order make Payment (1:1 Association)
 Payment proceeds Delivery (1:1 Association)
 Employee processes Order (Association)
 Employee updates Product (1:M Association)
 Admin manages Product (1:M Association)

3. Advantages and Disadvantages

Advantages:
 Clarity and Comprehensiveness
It depicts the core classes (Customer, Order, Product, etc.)
relevant to the system.
It includes attributes that represent essential data for
each class.
 Improved Communication
15 | P a g e
 This visual representation can be easily understood by
both technical and non-technical stakeholders.
It facilitates discussions about the system's design and
functionality.
Structured Design:
By defining clear relationships between classes, it
promotes a well-organized object-oriented approach.
It helps identify potential issues like missing functionalities
or redundancies.

 Maintainability
As the system evolves, the class diagram can be updated
to reflect the changes, aiding in ongoing system
maintenance.

Disadvantages :
 Potential Complexity
While this initial version focuses on core classes, adding
more features or intricate functionalities might increase
complexity.
Consider separate diagrams for specific functionalities if
needed.
 Limited Scope
Class diagrams primarily focus on object interactions.
They don't directly represent database interactions or
User Interface details.
It might need additional diagrams (e.g., Sequence
Diagrams) to depict these aspects comprehensively.
 Level of Detail
This is a well-structured starting point. Depending on the
project's needs, it might need to add more details like:
Data types for attributes (e.g., int for stockLevel)

16 | P a g e
 Specific operations for some classes (e.g., Employee:
updateInventory())

 Evolution and Refinement

Class diagrams aren't static. As the system evolves and
you gain a deeper understanding, the diagram should be
revisited and refined to reflect those changes.

4.Construction:
Begin by meticulously identifying the core entities within
the system. These entities, such as Customer, Order,
Product, and so forth, translate to classes in the diagram.
Each class represents a distinct concept with its own well-
defined attributes and operations.

Following the identification of classes, assign relevant

attributes to each. These attributes capture the essential
data specific to that class. For example, a Customer class
would possess attributes like name, address, and contact
information, while a Product class might have attributes
like name, type, brand, price, and stock level.

The crux of the class diagram lies in establishing the

relationships between these classes. These relationships
are denoted using standardized lines and notations:

 Associations: Solid lines connect classes when they

interact with each other. For instance, a Customer places
an Order (1:M association).

17 | P a g e
  Aggregation(not yet included) : A diamond-shaped head
on the association line signifies a stronger relationship,
where one class exists as part of the whole (e.g.,
OrderItem referencing a Product).
 Inheritance (not yet included): An open triangle
arrowhead points from the subclass to the superclass,
indicating the subclass inherits attributes and behaviors
(e.g., Admin inheriting from Employee)

Class Diagram:

18 | P a g e