UML SIMPLE

Definition of UML
UML (Unified Modeling Language) is a visual language for modeling and
documenting the design of software systems.

Importance of UML in SOA

SOA (Service Oriented Architecture) involves building software as
interconnected services. UML is important in SOA because it:

1. Clarifies Design: Provides clear diagrams for understanding system

architecture.
2. Identifies Services: Helps find and define the services needed.
3. Defines Interfaces: Specifies how services communicate and what data they
exchange.

To integrate APIs in SOA:

1. Define Interfaces: Use UML to design the service interfaces (APIs).
2. Use an API Gateway: Manage and route API requests through a central point.
3. Service Registry: Register services so they can discover and communicate
with each other.
4. Choose API Type: Use REST for simple, stateless interactions or SOAP for
complex, secure communications.
 Q6.(a) Creating a Use Case Diagram in UML
Process:
1. Identify Actors: Determine who interacts with the system (e.g., users,
external systems).
2. Identify Use Cases: List the functions or services the system provides to
actors.
3. Define System Boundary: Draw a rectangle representing the system’s scope.
4. Place Use Cases: Inside the rectangle, place ovals for each use case.
5. Place Actors: Outside the rectangle, add stick figures or labels for each actor.
6. Connect Actors and Use Cases: Draw lines to show interactions between
actors and use cases.

Example:
For an online bookstore:
Actors: Customer, Admin
Use Cases: Browse Books, Purchase Book, Manage Inventory
System Boundary: Enclose the use cases in a rectangle labeled “Online
Bookstore”
Connections:
Customer → Browse Books, Purchase Book
Admin → Manage Inventory

Capture Functional Requirements:

Shows what the system should do (use cases).
Illustrates interactions between users and the system.
Helps identify system functionalities from the user’s perspective.
 Q6.(b) Roles in Use Case Diagrams
Actors:
Role: External entities interacting with the system.
Example: Customer, Admin

Use Cases:
Role: Functions or services the system provides.
Example: Browse Books, Purchase Book

System Boundary:
Role: Defines what is inside (use cases) and outside (actors) of the system.
Example: A rectangle labeled “Online Bookstore”

Relationships:
Include: One use case uses the functionality of another.
Example: Purchase Book «include» Process Payment
Extend: One use case adds extra behavior to another.
Example: Purchase Book «extend» Apply Discount
Generalization: One actor or use case inherits behavior from another.
Example: Premium Customer generalizes Customer

These components together create a clear and structured representation of

system requirements.
 Q5.(a) Using UML Class Diagrams to Model the Static Structure of a System

Modeling Static Structure:

UML class diagrams provide a blueprint of the system’s structure by
depicting the system’s classes, their attributes, methods, and the
relationships among objects.

Key Elements to Include:

1. Classes:
Role: Represent the main entities or concepts within the system.
Example: `Book`, `Library`, `Member`.

2. Attributes:
Role: Characteristics or properties of classes.
Example: `title` and `author` for the `Book` class.

3. Methods:
Role: Functions or behaviors of classes.
Example: `borrow()`, `return()` for the `Book` class.

4. Relationships:
Associations: Show connections between classes.
Example: A `Library` has many `Books`.
Generalizations: Indicate inheritance between classes.
Example: `Ebook` generalizes `Book`.
 Dependencies: Show that one class uses another.
Example: A `Member` class depends on the `Book` class for borrowing
books.

5. Multiplicity:
Role: Specifies the number of instances in a relationship.
Example: A `Library` (1) can have many `Books` (1..*).

Example:
A class diagram for a library system might include:
Classes: `Library`, `Book`, `Member`
Attributes: `Book` (title, author), `Member` (name, memberID)
Methods: `Book` (borrow(), return()), `Member` (register(), borrowBook())
Relationships: `Library` (1) — (1..*) `Book`, `Member` (1..*) — (0..*) `Book`

Q5.(b) Components of Class Diagrams

1. Classes:
Role: Represent objects or concepts in the system.
Example: `Book`

2. Attributes:
Role: Define properties or characteristics of a class.
Example: `title`, `author` for the `Book` class.
3. Methods:
Role: Define behaviors or functions of a class.
Example: `borrow()`, `return()` for the `Book` class.

4. Relationships:
Associations: Show how classes are connected.
Example: `Library` has `Books`.
Generalizations: Represent inheritance.
Example: `Ebook` generalizes `Book`.
Dependencies: Show that one class uses another.
Example: `Member` depends on `Book` to borrow books.

5. Multiplicity:
Role: Indicates the number of instances in a relationship.
Example: A `Library` (1) can have many `Books` (1..*).

These elements are crucial for accurately representing and understanding the
structure and relationships within a system using UML class diagrams.
Sequence diagram
A Sequence Diagram shows how objects interact in a scenario by representing
the order of messages exchanged between them.

Key Elements
1. Objects (Lifelines):
Role: Represent participants.
Example: `User`, `LoginPage`, `AuthService`.
Diagram: Vertical dashed lines with object names.

2. Messages:
Role: Show communication.
Types:
Synchronous: Sender waits for response.
Asynchronous: Sender doesn’t wait.
Return: Receiver responds.
Example: `User` → `AuthService`: loginRequest()

3. Activation Bars:
Role: Show object’s activity.
Diagram: Thin rectangles on lifelines during processing.
4. Combined Fragments:
Role: Show control structures.
Types:
alt: Conditional branches.
loop: Repeated actions.
opt: Optional actions.

Simple Example: User Login

Scenario: User logs in.

# Objects:
`User`
`LoginPage`
`AuthService`

# Messages:
1. User → `enterCredentials()` → LoginPage
2. LoginPage → `authenticate()` → AuthService
3. AuthService → `authenticationResult()` → LoginPage
4. LoginPage → `displayResult()` → User
# Diagram:
1. User → `enterCredentials()` → LoginPage
2. LoginPage → `authenticate()` → AuthService
3. AuthService → `authenticationResult()` → LoginPage
4. LoginPage → `displayResult()` → User

This diagram simplifies the interaction flow for a user login, showing the order of
messages exchanged between objects.

Activity Diagram
An Activity Diagram in UML shows the flow of activities or tasks within a
system.
Key Elements
1. Activity (Action):
Represents a task or action.
Example: `Login`, `Browse Products`, `Checkout`.

2. Decision (Decision Node):

Indicates a point where the flow diverges based on conditions.
Example: Decide to login or register.

3. Merge (Merge Node):

Merges multiple flows back into one.
Example: After login or registration, continue shopping.
4. Fork (Fork Node):
Splits the flow into parallel paths.
Example: Process multiple orders simultaneously.

5. Join (Join Node):

Synchronizes parallel flows back into one.
Example: After parallel processing, continue with a common task.

6. Initial Node:
Indicates the starting point.
Example: Start of the order process.

7. Final Node:
Indicates the ending point.
Example: End of the order process.

Simple Example: Order Processing

Scenario: Processing an order in an online store.

1. Activities: Login → Browse Products → Add to Cart → Checkout → Payment

→ Process Order
2. Decision: Payment Verification
3. Final: Order Confirmation
This diagram simplifies the flow of activities involved in processing an order, from
login to order confirmation.

Component diagram
A Component Diagram in UML shows the components and their relationships in
a system.

Key Elements

1. Component:
Represents a part of the system with defined functionality.
Example: `User Interface`, `Database`, `Payment System`.

2. Interface:
Describes how components interact with each other.
Example: `Database Interface`, `Payment Interface`.
3. Dependency:
Shows that one component relies on another.
Example: `User Interface` depends on `Database`.

Simple Example: E commerce System

1. Components:
`User Interface`
`Database`
`Payment System`

2. Interfaces:
`User Interface`: Communicates with users.
`Database`: Accesses data.
`Payment System`: Handles payments.

3. Dependencies:
`User Interface` depends on `Database`.
`Payment System` relies on `Database`.

This diagram simplifies the structure of an e commerce system, showing how

components interact and depend on each other.