EYE OPTICAL MANAGEMENT SYSTEM

SOFTWARE ENGINEERING LAB

SLOT: L13+ L14
VL2023240505809

SUBMITTED BY:
ARUN.U
21BCE3187

Assessment-IV
1|Page
1. Describe the OO design using Interaction Models.

Introduction:
Purpose: This sequence diagram models the real-time interactions
between objects in the Eye Optical Management System. It visualizes the
core process a customer follows when browsing products, selecting
items, and completing a successful order placement.

Scope: Emphasize that while it provides a detailed view of the "Place

Order" functionality, it serves as a model for interactions, and the actual
implementation might involve additional considerations related to
internal object logic or error handling.

Components and relationships:

Objects:

 Customer: The primary user, engaging with the system, browsing

products, and ultimately confirming orders.
 Product: A key entity representing individual product offerings. It
reacts to browsing requests and communicates essential
information and stock availability.
 ShoppingCart: A crucial intermediary, temporarily storing item
selections and facilitating smooth transition to the order creation
process.
 Order: The core entity responsible for orchestrating order
creation, verifying product availability, interacting with the
payment gateway, and initiating delivery.
 Payment: Securely handles the financial transaction of an order
and updates the order object with the processing status.

2|Page
  Delivery: Efficiently schedules delivery upon order completion and
sends confirmation signals.

Relationships (Messages):
Clearly define each message exchanged between objects, emphasizing
their role in the process flow:

 browseProduct() & displayDetails(): Establish initial customer-

product interaction for exploring product listings.
 addItem() & confirmItemAdded(): Facilitate product selection and
ensure smooth integration with the shopping cart.
 initiateOrder(), retrieveItems(), & returnItems(): Trigger the order
creation process and manage communication between the
shopping cart and order objects.
 verifyStock() & returnAvailability(): These interactions safeguard
successful order fulfillment by ensuring product availability before
proceeding.
 processPayment() & returnPaymentStatus(): Handle the critical
financial transaction, communicating the outcome to the order
object.
 scheduleDelivery() & confirmDeliveryScheduled(): The final stage,
where delivery is scheduled and the system updates the customer.

Advantages and disadvantages:

Advantages

Process Understanding: Unravels the order process step-by-step,

contributing to a shared understanding among developers, testers, and
other stakeholders.

3|Page
Dynamic Illustration: Highlights the interplay between objects, which is
difficult to convey through static documentation.
Design & Testing Aid: Serves as a blueprint for code implementation,
outlining how object methods should interact for successful order
placement. Additionally, it guides the creation of test cases targeted at
object interactions.

Disadvantages
Potential Complexity: As system complexity grows, sequence diagrams
can become intricate. Focus on specific processes and abstract away
unnecessary details where possible.
Focus on Interactions: Prioritizes message flow over the detailed internal
logic of individual classes. Complementary documentation or class
diagrams might be needed.
Maintenance: As your system evolves, sequence diagrams require
updates to ensure continued accuracy.

4|Page
 Construction of a diagram:

2. Describe the OO design Package, Component and deployment Models.

Package model:

Introduction:

5|Page
Purpose: This package diagram provides a modular view of the Eye Optical
Management System. It visually organizes the system's components into
cohesive functional areas, illustrating the relationships and dependencies
between them.

Scope: Emphasize that it offers a higher-level perspective of the system's

design, promoting clear organization and maintainability.

Components and Relationships:

Packages:
 Customer Management: Handles customer accounts, profiles, order
history, and eye prescriptions (if applicable).
 Product Management: Manages product listings, including categories,
descriptions, brands, and inventory.
 Order Processing: The cornerstone, orchestrating order creation,
processing, payment interactions, and coordination with delivery.
 Administration: Provides management capabilities for admins or
employees responsible for system oversight or specific functionalities.
 Reporting: Facilitates report generation for business insights, analyzing
sales, inventory trends, and customer data (if this feature exists).

Dependencies:
 Customer Management <-> Order Processing: A reciprocal dependency,
where customers interact with the order process and the order process
utilizes customer information.
 Order Processing -> Product Management: Order processing relies on
product availability and information.
 Order Processing -> Payment: Secure handling of order-related financial
transactions.
 Order Processing -> Delivery: Initiates and communicates with the
delivery system for product shipment.

6|Page
  Administration -> Reporting: Admins potentially utilize the reporting
system for decision-making.
 Reporting -> (Most Packages): Reporting likely draws data from multiple
packages for comprehensive analysis.

Advantages and Disadvantages:

Advantages
 Modularization: Promotes the creation of well-defined system
components with clear interfaces, enhancing flexibility and
maintainability.
 High-Level Understanding: Makes the core functional areas and
interactions readily apparent, aiding collaboration between developers
and stakeholders.
 Scalability: Facilitates additions or modifications of modules (packages)
with minimized impact on the entire system.
 Reduced Complexity: Organizes the system to decrease cognitive
overload for developers.

Disadvantages
 Abstraction: Hides internal class details; might require supplementary
class diagrams for in-depth understanding.
 Over-simplification: In large systems, there's a risk of over-simplifying
dependencies, leading to overlooked complexities.
 Subjectivity: Package divisions can be somewhat flexible, different
designers might group functionalities slightly differently.

7|Page
Diagram:

Component Model:
Introduction about Diagram

Purpose: This component diagram provides a modular view of the Eye Optical
Management System's software architecture. It illustrates the high-level
software components and the dependencies between them.
Scope: Emphasize that this diagram aids in understanding the system's
structure from a software perspective, promoting maintainability and guiding
development efforts.

Components and Relationships

Identify Components Consider the following:

8|Page
Core Functionalities: Map the packages from your package diagram to
components
Deployment Units: Think about how you might break down the system during
actual deployment – this can guide component creation.
External Systems: Include components representing any significant external
systems your Eye Optical Management System interacts with (e.g., a 3rd-party
payment gateway).
Example Components (Preliminary)

CustomerManagementComponent
ProductManagementComponent
OrderProcessingComponent
PaymentGatewayComponent (external)
DeliveryManagementComponent
AdminComponent
ReportingComponent
Define Interfaces
Provided Interfaces: Each component declares the functionalities it offers to
other components. These could be method names, API endpoints, or event
triggers, depending on the technologies you use.
Required Interfaces: Specify the services a component needs from others to
function. This is key to showing dependencies.

Provided Interfaces:
placeOrder(customerID, orderData)
calculateTotal(orderID)
initiatePayment(paymentDetails)
scheduleDelivery(orderDetails)

9|Page
Required Interfaces:
getProductDetails(productID) (from ProductManagementComponent)
validateCustomer(customerID) (from CustomerManagementComponent)
processPayment(paymentDetails) (from PaymentGatewayComponent)
createShipment (shipmentDetails) (from DeliveryManagementComponent)
Establish Relationships
Dependency Arrows: Draw arrows from components with "required interfaces"
to the components providing those interfaces. This visualizes the flow of
dependencies.
Detailing Components (Optional)
Internal Structure: If beneficial, you can show important classes within each
component.
Ports: Use ports to pinpoint specific interaction points on components.

However Some of the above functionalities are not implied in my Diagram.

Simple depiction is made for this.

3. Advantages and Disadvantages

Advantages

Modularization: Promotes the creation of well-defined, independent

components, enhancing maintainability, and reusability.
System Complexity Reduction: Helps manage complexity by breaking down the
system into manageable units.
High-level Understanding: Provides developers and stakeholders with a clear
overview of component interactions.
Focus on Interfaces: Emphasizes the contracts between components, aiding in
defining clear communication channels within the system.

10 | P a g e
Disadvantages

Abstraction: Hides the internal implementation details of classes within each

component. Class diagrams might be needed for in-depth understanding.
Potential for Oversimplification: In large systems, oversimplifying dependencies
can lead to misrepresentation of certain complexities.
Design Subjectivity: Component definitions might vary slightly between
designers based on their interpretation of system boundaries.

Diagram:

Deployment Model:

1. Introduction about Diagram

11 | P a g e
Purpose: This deployment diagram visually depicts the physical configuration of
the Eye Optical Management System. It showcases the hardware components
(nodes) and the distribution of software components across those nodes.
Scope: Emphasize that this diagram provides a blueprint for the physical
deployment of the system, aiding in aspects such as capacity planning, network
configuration, and security considerations.
2. Components and Relationships

Nodes: Represent physical hardware like servers, desktops, or mobile devices.

Components: The software components from your component diagram are
now mapped onto these nodes.
Artifacts: Represent deployable units like executables, configuration files, or
database schemas.
Relationships: Typically show dependencies between software components or
connections between nodes.
Designing your Deployment Model

1. Identify Nodes

Web Server(s): Likely host the core functionality of your system. You might have
multiple servers for load balancing or separate
development/staging/production environments.
Database Server: Houses your system's data securely.
Client Devices: Consider the range of devices customers will use (desktops,
laptops, mobile phones).
Payment Gateway: If using an external provider, this might be an additional
node.
Other Hardware: Any specialized hardware if relevant (e.g., in-store inventory
management terminals).
2. Map Components to Nodes

12 | P a g e
Consider the following:
Performance: Critical components might need dedicated servers.
Security: Sensitive components (e.g., PaymentGatewayComponent) might have
strict isolation requirements.
Scalability: Plan for load distribution across servers if needed.
Example (Simplified)

Web Server :
CustomerManagementComponent
ProductManagementComponent
OrderProcessingComponent
AdminComponent
UserInterfaceComponent
Database Server:
Database Schema (as an artifact representing your data store)
Client Devices:
Web Browser (to access the UserInterfaceComponent)
3. Artifacts

Within each node, indicate the deployable files:

Web Server: .jar files (if using Java), Website code (HTML, JavaScript, CSS)
Database Server: SQL scripts, data backups
4. Connections

Show communication paths:

Client Devices <-> Web Servers (HTTP/HTTPS)
13 | P a g e
Web Servers <-> Database Server (database connection protocol)
Web Servers <-> Payment Gateway (if applicable)
3. Advantages and Disadvantages

Advantages

Hardware Planning: Facilitates informed decision-making about hardware

needs, sizing, and resource allocation.
Deployment Clarity: Gives development and operations teams a shared
understanding of the system's physical layout.
Network Visualization: Aids in visualizing the network infrastructure and
pinpointing potential bottlenecks or security considerations.
Configuration Management: Assists in the setup and maintenance of the
production environment.
Disadvantages

Complexity: For large systems, deployment diagrams can become intricate.

Maintaining focus on the most essential elements is crucial.
Maintenance: As the system evolves, keeping the deployment diagram aligned
with physical changes is essential.
Focus on Physical Aspects: Deployment diagrams do not convey internal
software architecture as effectively as Component Diagrams.

Diagram:

14 | P a g e
15 | P a g e