UNIT-III

THE LOGICAL VIEW DESIGN STAGE

The Static Structure Diagrams: The Class Diagram Model-Attributes descriptions

Operations descriptions- Connections descriptions in the Static Model -Association,
Generalization, Aggregation, Dependency, Interfacing, Multiplicity.

Static Structure Diagrams

Static Structure Diagrams in UML represent the static view of a system, focusing on its
architecture rather than its dynamic behavior. They depict the building blocks of a system,
such as classes, objects, components, and their relationships, providing a foundation for
system design and implementation.

Types of Static Structure Diagrams

1. Class Diagram
o Represents the classes in a system along with their attributes, operations,
and relationships (e.g., association, generalization, aggregation).
o Key elements:
▪ Classes: Show the structure of entities.
▪ Attributes and Operations: Represent properties and methods.
▪ Relationships: Show connections, such as inheritance or associations.
o Use Case: Used for designing object-oriented systems.
2. Object Diagram
o A snapshot of objects and their relationships at a specific time.
o Focuses on instances of classes rather than the classes themselves.
o Use Case: Used for understanding system states at runtime.
3. Component Diagram
o Describes the physical structure of code components.
o Focuses on modules, libraries, and interfaces.
o Use Case: Useful for deployment and implementation planning.
4. Deployment Diagram
o Represents the physical architecture of a system.

1
 o Focuses on hardware nodes, software components, and their configurations.
o Use Case: Useful for designing distributed systems.
5. Package Diagram
o Shows how classes or components are grouped into packages.
o Highlights dependencies between packages.
o Use Case: Used to organize large systems into manageable units.

Elements of Static Structure Diagrams

1. Classes/Objects:
o Represent entities with attributes and methods.
2. Relationships:
o Association: A connection between two classes.
o Aggregation: A whole-part relationship.
o Composition: A stronger form of aggregation where parts cannot exist
independently.
o Generalization: Inheritance relationships between classes.
o Dependency: Indicates that one element uses another.
3. Multiplicity:
o Defines how many instances of a class can be associated with another.
4. Interfaces:
o Represent a contract that a class must adhere to.

Advantages of Static Structure Diagrams

● System Understanding: Helps in visualizing the architecture and structure of the

system.
● Documentation: Provides a clear picture of system components and their
relationships.
● System Design: Aids in object-oriented design and implementation.
● Maintainability: Simplifies updates and debugging.

2
Examples

1. Class Diagram Example:

Use Case: Online Shopping System

● Classes: Customer, Order, Product, Cart

● Relationships:
o Customer places an Order.
o Order contains multiple Products.

2. Object Diagram Example:

Use Case: Runtime Snapshot of an Order

● Objects:
o Customer: John Doe
o Order: #123
o Product: Laptop

3. Component Diagram Example:

Use Case: E-commerce System

● Components:
o UserInterface, Database, PaymentGateway
● Interfaces:
o PaymentAPI

Comparison with Dynamic Diagrams

3
 The Class Diagram Model

A Class Diagram is a static structure diagram in UML that describes the blueprint of a system
by modeling its classes, attributes, operations, and relationships. It provides a foundation for
object-oriented design and is widely used in software engineering to visualize and design the
structure of software systems.

Key Components of a Class Diagram

1. Classes:
o Represent entities in a system.
o Typically depicted as rectangles divided into three compartments:
▪ Top: Class name (e.g., Customer).
▪ Middle: Attributes (e.g., name, email).
▪ Bottom: Operations (e.g., addToCart(), placeOrder()).
2. Attributes:
o Represent the properties of a class.
o Syntax: <visibility> <attributeName>: <type>
o Example: +name: String
3. Operations:
o Represent the methods or behaviors of a class.
o Syntax: <visibility> <methodName>(parameters): <returnType>
o Example: +calculateTotal(): float
4. Visibility Modifiers:
o Public (+): Accessible to all classes.
o Private (-): Accessible only within the class.
o Protected (#): Accessible within the class and its subclasses.
5. Relationships:
o Association: A connection between two classes.
▪ Example: A Customer is associated with an Order.
o Multiplicity: Specifies the number of instances in a relationship.
▪ Example: 1..* indicates "one to many."
o Aggregation: A "whole-part" relationship where parts can exist
independently.
▪ Example: A Library contains Books.

4
 o Composition: A stronger aggregation where parts cannot exist independently.
▪ Example: A House has Rooms.
o Generalization: Inheritance between a superclass and subclasses.
▪ Example: Person is a general class; Customer and Employee are
specific classes.
o Dependency: One class uses or depends on another.
▪ Example: Invoice depends on Payment.
6. Interfaces:
o Represent a contract that a class must adhere to.
o Example: PaymentProcessor interface with processPayment() method.

How to Model a Class Diagram

1. Identify Classes:
o Extract nouns from the system requirements or use cases.
o Example: Customer, Order, Product.
2. Define Attributes:
o Assign properties relevant to each class.
o Example: Order has attributes orderID and date.
3. Define Operations:
o Specify behaviors or methods for each class.
o Example: Customer has login() and register().
o

4. Establish Relationships:
o Identify and model associations, dependencies, or hierarchies between classes.
o Example: Customer places an Order.
5. Use Multiplicity:
o Define the number of instances involved in associations.
o Example: A Cart can contain multiple Products (1..*).

An example of UML class diagram which shows a domain model for online shopping. The
purpose of the diagram is to introduce some common terms, "dictionary" for online shopping
- Customer, Web User, Account, Shopping Cart, Product, Order, Payment, etc. and

5
relationships between. It could be used as a common ground between business analysts and
software developers.
Each customer has unique id and is linked to exactly one account. Account owns shopping
cart and orders. Customer could register as a web user to be able to buy items online.
Customer is not required to be a web user because purchases could also be made by phone or
by ordering from catalogues. Web user has login name which also serves as unique id. Web
user could be in several states - new, active, temporary blocked, or banned, and be linked to
a shopping cart. Shopping cart belongs to account.

Online shopping domain UML class diagram example

Account owns customer orders. Customer may have no orders. Customer orders are sorted
and unique. Each order could refer to several payments, possibly none. Every payment has
unique id and is related to exactly one account.
Each order has current order status. Both order and shopping cart have line items linked to a
specific product. Each line item is related to exactly one product. A product could be
associated to many line items or no item at all.

Example: Class Diagram for an Online Shopping System

6
Relationships:

● Customer places Order (1..* multiplicity).

● Order contains Product (1..* multiplicity).
● Product is dependent on Inventory for stock updates.

Advantages of Class Diagrams

1. System Understanding: Provides a clear overview of system components and their

relationships.
2. Object-Oriented Design: Supports the development of object-oriented systems.
3. Code Generation: Many tools can generate skeleton code from class diagrams.
4. Documentation: Serves as a standard reference for developers.

UML Notation for Class Diagram

A UML Class Diagram is a structural diagram that represents the static structure of a system
by modeling its classes, attributes, operations, and the relationships between them. Here is a
detailed explanation of the notations used in a class diagram.

Key Elements of Class Diagram Notation

1. Class Representation:
○ A class is represented as a rectangle divided into three compartments:
1. Top: The name of the class.
2. Middle: Attributes of the class.
3. Bottom: Operations (methods) provided by the class.

Syntax:

ClassName
attributes
operations

7
Example

Attributes:

● Represent the data or properties of a class.

● Syntax: [visibility] name: type
○ + (Public): Visible to all.
○ # (Protected): Visible to the class and its subclasses.
○ - (Private): Visible only to the class.

Example:

- width: Float
- height: Float

Operations:

● Represent the behavior or functionality of the class.

● Syntax: [visibility] name(parameters): returnType

Example:
+ calculateArea() : Float
+ setDimensions(w: Float, h: Float) : void

Attributes in Class Diagrams

Attributes in a class diagram represent the properties or data fields of a class. They define
the characteristics or state that objects of the class can hold. Each attribute is typically
associated with a name, a type, and sometimes a default value or additional constraints.

8
Components of an Attribute

1. Visibility:

o Indicates the access level of the attribute.

▪ + (Public): Accessible by any class.
▪ - (Private): Accessible only within the class.
▪ # (Protected): Accessible within the class and its subclasses.
▪ ~ (Package): Accessible within the same package (in Java or similar
languages).

2. Name:

Describes what the attribute represents.

o
Example: customerName, orderID.
o
3. Data Type:

Specifies the type of value the attribute holds.

o
Examples:
o
▪ Primitive types: int, float, char.
▪ Object types: String, Date, List.
4. Multiplicity (Optional):

oIndicates how many instances of the attribute can exist.

oExample: A class may have a single age attribute or multiple hobbies.
5. Default Value (Optional):

Specifies the initial value of the attribute if not explicitly set.

o
Example: +isAvailable: boolean = true.
o
6. Constraints (Optional):

o Defines restrictions or conditions for the attribute.

o Example: +age: int {> 0}.

Syntax of Attributes in UML

<visibility> <attributeName>: <dataType> [multiplicity] = <defaultValue> {constraint}

Examples:

1. +name: String[
o Public name attribute of type String.
2. -salary: double = 50000.0
o Private salary attribute of type double with a default value of 50000.0.
3. #marks: List<int> [0..*]
o Protected marks attribute, a list of integers, with zero or more instances.
4. ~level: int {1..5}
o Package-level level attribute with values constrained between 1 and 5.

9
Describing Attributes with Examples

Example 1: Class Customer

Attribute Description

-customerID:
Unique identifier for the customer.
int

+name: String The name of the customer.

The email address of the customer, accessible by the class and its
#email: String
subclasses.

+age: int {>

Age of the customer must be a positive integer.
0}

Example 2: Class Order

Attribute Description

-orderID: int Unique identifier for each order.

+date: Date Date when the order was placed.

Current status of the order (e.g., "Pending",

+status: String
"Shipped").

-totalAmount:
Total cost of the order.
float

Guidelines for Defining Attributes

1. Clarity:

o Use descriptive names for attributes to convey their purpose.

o Example: Use birthDate instead of date.
2. Consistency:

o Follow a naming convention (e.g., camelCase in Java).

3. Encapsulation:

o Use private visibility (-) for most attributes to enforce data encapsulation.
4. Data Types:

o Choose appropriate data types based on the system requirements.

o Use enum types for predefined sets of values (e.g., status as an enum).
5. Constraints and Validations:

o Define constraints to ensure data integrity (e.g., age must be positive).

10
Visualization in UML

For the class Customer:

Customer
-customerID: int
+name: String
#email: String
+age: int {> 0}
+register(): void
+login(): boolean

Class diagram for Inventory Management system

Operations descriptions

11
In UML (Unified Modeling Language), operations are behaviors or functions associated with
a class or an interface. They represent actions or services that a class can perform and are
defined within the context of a class diagram.

Key Concepts of Operations in UML

1. Definition:
○ Operations specify what a class can do or what behavior it provides. They are
analogous to methods in programming languages.
○ Each operation has a signature that includes its name, parameters, and return
type.
2. Notation:
○ Represented in the third compartment of a class box in a class diagram,
below attributes.
○ Syntax:

visibility name (parameterList) : returnType

Example:

+ calculateArea(width: Float, height: Float) : Float

Visibility:

● Defines the access level of the operation:

○ Public (+): Accessible by any class.
○ Protected (#): Accessible by the class itself and its subclasses.
○ Private (-): Accessible only within the class.
○ Package (~): Accessible by classes in the same package or namespace.

Parameters:

● Parameters provide additional information required for the operation to execute.

● Consist of a parameter name and its type.
● Example: (name: String, age: Integer)

Return Type:

● Specifies the type of data returned by the operation. If no value is returned, the return
type is often omitted or noted as void.

Operation Modifiers:

● Additional properties of operations can be specified, such as:

○ Static: The operation belongs to the class rather than any specific instance.
○ Abstract: The operation is declared but not implemented (must be
implemented by subclasses).
○ Final: The operation cannot be overridden in a subclass.
12
Behavior Specification:

● An operation can be further defined using behavior diagrams like:

○ Sequence Diagrams: Show the interaction between objects during the
operation.
○ Activity Diagrams: Illustrate the flow of control within the operation.
○ State Diagrams: Represent changes in state triggered by the operation

Example in a Class Diagram:

Rectangle
- width: Float
- height: Float
+ setDimensions(width:
Float, height: Float) : void
+ calculateArea() : Float
+ calculatePerimeter() : Float

Role of Operations in UML

● Encapsulation: Operations enforce data hiding by providing controlled access to

attributes.
● Behavior Modeling: Define the dynamic aspects of a system.
● Communication: Used in collaboration and sequence diagrams to model object
interactions.

Connections descriptions in the Static Model

In the Static Model of UML, connections represent the relationships and links between the
structural elements of a system, such as classes, objects, and components. These connections
are foundational for defining the architecture and data flow within the system. The key types
of connections in the static model include associations, dependencies, generalizations,
realizations, and more.

13
Types of Connections in UML Static Models

Association:

Association relationship is a structural relationship in which different objects are linked within
the system. It exhibits a binary relationship between the objects representing an activity. It depicts
the relationship between objects, such as a teacher, can be associated with multiple teachers.

It is represented by a line between the classes followed by an arrow that navigates the direction,
and when the arrow is on both sides, it is then called a bidirectional association. We can specify
the multiplicity of an association by adding the adornments on the line that will denote the
association.

1) A single teacher has multiple students.

2) A single student can associate with many teachers.

The composition and aggregation are two subsets of association. In both of the cases, the
object of one class is owned by the object of another class; the only difference is that in
composition, the child does not exist independently of its parent, whereas in aggregation, the
child is not dependent on its parent i.e., standalone. An aggregation is a special form of
association, and composition is the special form of aggregation.

14
 ● Definition: Represents a structural relationship between two or more classes that
shows how objects of these classes are related to each other.
● Notation: Solid line connecting classes.
● Details:
○ Multiplicity: Specifies the number of instances that can participate in the
relationship.
■ Example: 1, 0..1, *, 1..*.
○ Role Names: Labels at the ends of the line to describe the role of each class in
the association.
○ Direction: Can have arrows to show navigability.

Example:

Person --------> Car

Aggregation:

Aggregation is a subset of association, is a collection of different things. It represents has a

relationship. It is more specific than an association. It describes a part-whole or part-of
relationship. It is a binary association, i.e., it only involves two classes. It is a kind of relationship
in which the child is independent of its parent.

● Definition: A special form of association representing a "whole-part" relationship

where the part can exist independently of the whole.
● Notation: Hollow diamond at the "whole" end.

Department <>---- Employee

15
For example:

Here we are considering a car and a wheel example. A car cannot move without a wheel. But the
wheel can be independently used with the bike, scooter, cycle, or any other vehicle. The wheel
object can exist without the car object, which proves to be an aggregation relationship.

Guidelines:

● Independence: Ensure that the part objects can exist independently of the whole
object.
○ Example: A Department has Employee objects, but employees can exist
without a department.
● Multiplicity: Clearly define the multiplicity at both ends to indicate how many parts
are involved in the relationship.
○ Example: 1 Department aggregates 1..* Employees.
● Role Clarity: Use meaningful role names for better understanding.
○ Example: A Car aggregates Tires with the role wheels.
● Avoid Overuse: Only use aggregation when there is a meaningful "whole-part"
relationship. Overuse can clutter the diagram.

Composition:

Definition: A stronger form of aggregation where the part cannot exist independently of the
whole.

● Notation: Filled diamond at the "whole" end.

Example:

House ◆---- Room

The composition is a part of aggregation, and it portrays the whole-part relationship. It

depicts dependency between a composite (parent) and its parts (children), which means that if
the composite is discarded, so will its parts get deleted. It exists between similar objects.

In the example given below, the composition association relationship connects the Person
class with Brain class, Heart class, and Legs class. If the person is destroyed, the brain, heart,
and legs will also get discarded.

16
Guidelines:

● Lifecycle Dependency: Ensure the part cannot logically exist without the whole.
○ Example: A House and its Rooms—if the house is destroyed, so are its
rooms.
● Encapsulation: Use composition for a stronger level of encapsulation between the
whole and the parts.
● Multiplicity: Clearly specify multiplicities to show how many parts are required.
○ Example: 1 House contains 1..* Rooms.
● Logical Relationship: Use composition only if the parts have no independent
significance without the whole.
● Consistency: Ensure the diagram reflects the logical dependency in the real-world
model.
● Role Naming: Add roles to clarify the relationship and improve understanding.
○ Example: House contains Rooms with the role livingArea.

Generalization:

In UML modeling, a generalization relationship is a relationship that implements the concept

of object orientation called inheritance. The generalization relationship occurs between two
entities or objects, such that one entity is the parent, and the other one is the child. The child
inherits the functionality of its parent and can access as well as update it.

Generalization relationships are utilized in class, component, deployment, and use case
diagrams to specify that the child inherits actions, characteristics, and relationships from its
parent.

To meet UML's standard, it necessitates usage of the same types of model elements in the
generalization relationship, i.e., generalization relation can either be used between actors or
between use cases, but not between an actor and a use case.

The generalization relationship is incorporated to record attributes, operations, and

relationships in a parent model element so that it can be inherited in one or more child model
elements.

17
The parent model element can have as many children, and also, the child can have one or more
parents. But most commonly, it can be seen that there is one parent model element and multiple
child model elements. The generalization relationship does not consist of names. The
generalization relationship is represented by a solid line with a hollow arrowhead pointing
towards the parent model element from the child model element.

Stereotypes and their constraints

<<implementation>> - It is used to show that the child is implemented by its parent, such that
the child object inherits the structure and behavior of its parent object without disobeying the
rules. The implementation of stereotype is mostly used in single inheritance.

In the generalization stereotype, there are two types of constraints that are complete and
incomplete to check if all the child objects are involved or not in the relationship.

Example:

As we know, the bank account can be of two types; Savings Account and Credit Card
Account. Both the savings and the credit card account inherits the generalized properties from
the Bank Account, which is Account Number, Account Balance, etc.

● Definition: Represents an inheritance relationship where a subclass inherits the

properties and behaviors of a superclass.
● Notation: Solid line with a hollow triangle pointing toward the superclass.
18
 ● Example

Animal ▲---- Dog

Dependency:

Dependency in UML is a relationship that represents how one element depends on another
for its specification or implementation. It typically signifies a "uses," "needs," or "relies
upon" relationship between two elements in a system.

Characteristics of Dependency

● Definition:
○ A unidirectional relationship where a change in the independent (supplier)
element may require a change in the dependent (client) element.
○ Indicates that one element relies on the functionality or existence of another
element.

● Notation:
○ Represented as a dashed arrow pointing from the dependent element (client)
to the independent element (supplier).
○ Optional stereotype (e.g., <<uses>>, <<calls>>,
<<instantiates>>, etc.) may be added for clarity.

Example:

Order -----> PaymentMethod <<uses>>

● Definition: A relationship where one class depends on another for its specification or
implementation. It signifies a "uses" or "needs" relationship.
● Notation: Dotted arrow pointing from the dependent class to the class it depends on.

Order -----> PaymentMethod <<uses>>

Directionality:

● Always points from the dependent element (client) to the independent element
(supplier).

Types of Dependencies

1. Usage Dependency:
○ Represents that one class uses another class, usually in the form of invoking
its methods or accessing its data.
○ Example: A Report class depends on a Database class for data fetching.
2. Instantiation Dependency:

19
 ○ Indicates that one class creates an instance of another.
○ Example: A Controller class depends on a View class to create a user
interface.
3. Abstraction Dependency:
○ Links an abstraction to its realization.
○ Example: An interface (IShape) has a dependency on its implementation
class (Circle).
4. Permission Dependency:
○ Indicates permission granted for one package or component to use elements of
another.
○ Example: A Client package depends on a Server package for accessing its
services.

Benefits of Modeling Dependency

1. Traceability:
○ Makes it easier to understand and trace dependencies between elements in
complex systems.

2. Change Impact Analysis:

○ Helps identify how changes in one element may affect other dependent
elements.
3. Encapsulation:
○ Encourages the separation of concerns by defining clear boundaries of usage
between components or classes.
4. Clarity in Communication:
○ Provides a clear and standardized way to depict how elements rely on each
other.

Stereotypes:

● Stereotypes clarify the nature of the dependency. Common stereotypes include:

○ <<use>>: The client uses services provided by the supplier.
○ <<call>>: The client calls operations in the supplier.
○ <<create>>: The client creates instances of the supplier.
○ <<trace>>: Tracks a relationship between model elements.
○ <<derive>>: Specifies that one element is derived from another.

Interface Connection:

An interface in UML is denoted similarly to a class; it is represented as a rectangle divided

into compartments for the name, attributes (optional), and operations. The key distinction in
UML is that an interface is annotated with the «interface» stereotype.

● Definition: Shows how a class or component connects to an interface.

● Notation: Circle (interface) with a line connecting it to a class or component.
20
 ● Example:

Printer ----> IPrintable

Key Concepts and Usage

● Multiple Implementations: A single class can implement multiple interfaces,

showcasing its capability to participate in several contracts, providing flexibility and
promoting reusability. This also allows for a form of multiple inheritances in
programming languages that do not support this feature directly, like C# or Java.
● Polymorphism: Interfaces facilitate polymorphism. Different classes can be treated
the same way if they implement the same interface, even if they have different
internal implementations.

Multiplicity:

● Specifies how many instances of one class can be associated with a single instance of
another class in an association.
● Examples:
○ 1: Exactly one.
○ 0..1: Zero or one.
○ *: Zero or more.
○ 1..*: One or more.

Importance of Connections in UML Static Models

● Structure Representation: They capture the foundational relationships that define the
structure of the system.
● Behavior Prediction: Help infer how elements interact and how the system behaves.
● Communication: Provide a clear and standardized way to describe relationships,
making it easier for teams to understand system architecture.

21