Unit 2 1 1
Unit 2 1 1
Mallikarjuna Nandi
Assistant Professor
Computer Science & Engineering
RGUKT- Ongole-AP
Structural modeling in UML (Unified Modeling Language) is a type of modeling that focuses on the static
structure of a system or software application. It is used to describe the components of a system and their
relationships, as well as the constraints and interfaces that govern how they interact with each other.
Diagrams are:
Class diagram
Object diagram
Package diagram
Component diagram
Structural modeling is useful for understanding the architecture and design of a software system, as well as
for communicating that information to stakeholders and team members. It is designed in a way that meets
the requirements and is scalable, maintainable, and extensible.
Class diagrams: These diagrams are used to represent the classes in a system and the relationships
between them. A class is a template or blueprint for creating objects, and it defines the properties and
methods that objects of that class will have. A class diagram consists of:
Class: A class represents a template for creating objects that share the same attributes,
operations, relationships, and behavior. It is represented as a rectangle with the class name
written inside it.
Attributes: Attributes are the data members of a class. They describe the characteristics of
the objects created from the class. They are represented as name: type pairs in the class
rectangle.
Methods: Methods are the operations that can be performed on the objects created from the
class. They are represented as name(parameter list):return type in the class rectangle.
The vocabulary of a class can be modeled using the attributes and operations of the class. The attributes
represent the properties or characteristics of the objects that belong to the class, while the operations
represent the actions or behaviors that the objects can perform. Here are some guidelines for modeling the
vocabulary of a class in UML:
Identify the key properties of the class: The key properties of a class are the attributes that define its
identity or differentiate it from other classes. For example, if you are modeling a class for a person, the key
properties could include the person's name, age, gender, and occupation.
Identify the operations that the objects can perform: The operations of a class are the functions or
methods that the objects can perform. For example, if you are modeling a class for a person, the operations
could include walking, talking, eating, sleeping, and working.
Use relationships to model associations between classes: Classes can have associations with other classes,
such as composition, aggregation, or inheritance. You can use UML relationships (represented by lines and
symbols) to model these associations.
In this example, the class is called Person and has four attributes: name (a
string), age (an integer), gender (a string), and occupation (a string). The
attributes are marked as private (-) to indicate that they can only be accessed by
methods within the class.
The class has four methods: walk (which takes an integer parameter and returns
void), talk (which takes a string parameter and returns void), eat (which takes a
string parameter and returns void), and sleep (which takes an integer parameter
and returns void). The methods are marked as public (+) to indicate that they can
be accessed by other classes.
Relationships: Relationships represent the associations between the classes, such as inheritance,
composition, aggregation, and association. They are represented as lines between the classes with an
arrowhead indicating the direction of the relationship.
Class diagrams are useful for modeling the relationships between different objects and classes in a
system, and they can help in identifying potential issues in the design of a system.
The association between the Account and Customer classes can be labeled as "has" or
"belongs to", indicating that an account "belongs to" a customer. The association can also be given a
multiplicity, which specifies the number of instances that can participate in the association.
For example, the multiplicity on the Customer side of the association may be "1..*", indicating that
each customer can have zero or more accounts, while the multiplicity on the Account side may be "1",
indicating that each account must be associated with exactly one customer.
08/03/2024 RGUKT Ongole Campus 8
UNIT-2
Multiplicity is a concept used to specify how many objects can participate in a relationship between two
classes. Multiplicity is represented using numbers or special symbols near the association line between two
classes.
One-to-one relationship: In a one-to-one relationship, each instance of one class is associated with one
and only one instance of another class. This is represented by the number "1" on each end of the association
line.
One-to-many relationship: In a one-to-many relationship, each instance of one class is associated with
one or more instances of another class. This is represented by the number "1" on one end of the association
line, and the asterisk symbol (*) on the other end.
Many-to-many relationship: In a many-to-many relationship, each instance of one class is associated with
one or more instances of another class, and vice versa. This is represented by the asterisk symbol (*) on both
ends of the association line.
08/03/2024 RGUKT Ongole Campus 9
UNIT-2
Aggregation is a relationship between two classes where one class (the containing class) contains instances
of another class (the contained class). Aggregation is typically shown with a diamond symbol at the end of
the association line pointing towards the class that contains the instances.
Aggregation implies a relationship where the child can exist independently of the
parent. Example: Class (parent) and Student (child). Delete the Class and the
Students still exist. Composition implies a relationship where the child cannot exist
independent of the parent.
Example: we are designing a library management system, and we have two classes:
Library and Book. The Library class contains a collection of books, so we can represent this
relationship using aggregation. The Library class is the containing class, and the Book class
is the contained class.
In the example, the Library class contains an array of Book objects, which are instances
of the Book class. The aggregation relationship is shown with a diamond symbol on the
association line connecting the two classes, with the symbol pointing towards the Library
class, indicating that it is the containing class.
Aggregation is a specialised form of association. It defines a one-way relationship that specifies a 'has-a'
relationship between two classes. For example, you can say that a wallet has money. However, the money
does not need a wallet in order to exist, so the relationship is one-way.
Composition relationship is a type of association where one class (the "whole" or composite object)
contains another class (the "part" or component object) as a part.
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.
In UML, it can exist between It is a part of the association relationship. It is a part of the aggregation relationship.
two or more classes.
It can associate one more In an aggregation relationship, the In a composition relationship, the associated
objects together. associated objects exist independently objects cannot exist independently within the
within the scope of the system. scope of the system.
It may or may not affect the Deleting one element in the aggregation It affects the other element if one of its
other associated element if relationship does not affect other associated element is deleted.
one element is deleted. associated elements.
Example: A tutor can associate Example: A car needs a wheel for its Example: If a file is placed in a folder and
with multiple students, or one proper functioning, but it may not require that is folder is deleted. The file residing
student can associate with the same wheel. It may function with inside that folder will also get deleted at the
multiple teachers. another wheel as well. time of folder deletion.
Dependency is an important aspect in UML elements. It describes the dependent elements and the
direction of dependency. Dependency is represented by a dotted arrow . The arrow head represents the
independent element and the other end represents the dependent element.
Generalization describes the inheritance relationship of the object-oriented world. It is a parent and child
relationship. Generalization is represented by an arrow with a hollow arrow head . One end represents the
parent element and the other end represents the child element. Generalization is used to describe parent-
child relationship of two elements of a system.
Classifier: A classifier is a mechanism that describes structural and behavioral features. Classifiers include
classes, associations, interfaces, data types, signals, components, nodes, use cases, and subsystems.
The most important kind of classifier in the UML is the class. A class is a description of a set of objects that
share the same attributes, operations, relationships, and semantics. Classes are not the only kind of
classifier, however. The UML provides a number of other kinds of classifiers to help you model.
1. Interface A collection of operations that are used to specify a service of a class or a component.
2. Datatype A type whose values are immutable, including primitive built-in types (such as numbers and
strings) as well as enumeration types (such as Boolean)
3. Collaboration (Signal): defines an interaction between elements.
4. Use case represents a set of actions performed by a system for a specific goal.
5. Node: A node can be defined as a physical element that exists at run time.
Advanced classes in structural modeling refer to the use of advanced modeling techniques and notations to
represent classes and their relationships in a more detailed and accurate way. Some of the advanced classes
mechanisms are:
Abstract class is a class that cannot be created and serves as a base or parent class for other classes. It provides a way to
define common properties and behavior that can be shared among multiple classes. Abstract classes typically contain
one or more abstract methods, which are methods without an implementation that must be implemented by subclasses.
In this example, the class "Dog" inherits from the "Animal" class and implements the
"makeSound()" method. It also has a property "breed" of type String, which is specific
to dogs.
By using an abstract class in this way, we can create a common structure for all
animals, while still allowing for the unique characteristics of each specific animal
subclass.
Interface: is a type of element that defines a set of operations that can be implemented by any class or
component that adopts the interface.
Example: we are designing a system for managing different types of vehicles, including cars, buses, and
trucks. We want to define a set of operations that each vehicle type must support, such as "start", "stop",
"accelerate", and "decelerate". we can define an interface called "IVehicle" that specifies these operations.
Enumeration is a type of element that represents a fixed set of values. An enumeration defines a set of
named values, which are typically used to represent a specific type of data that can only take on a limited set
of values.
Suppose we are designing a system that needs to represent different types of colors. We want to limit the
available colors to a fixed set of options, such as red, green, blue, and yellow. To achieve this, we can define
an enumeration called "Color" that defines these values.
Example, if we have a class called "Shape" that has a color attribute, we could use the "Color" enumeration
to specify the allowed values for this attribute.
In this example, the "Shape" class has a color attribute that is typed as the "Color" enumeration. This ensures
that the color attribute can only take on one of the allowed values specified by the enumeration.
Class Diagrams: Role: Class diagrams are used to represent the static structure of a system. They describe
the classes, attributes, methods, and relationships between classes, such as inheritance, association,
aggregation, and composition.
Object Diagrams: Role: Object diagrams represent instances of classes in a system at a specific point in
time. They show objects and their relationships, which can be created from class diagrams. Object diagrams
are useful for testing and debugging.
Component Diagrams: Role: Component diagrams show the components that make up a system and the
relationships between them. Components can be physical or logical, and can include executables, libraries,
databases, and so on. Component diagrams are useful for understanding how a system is composed and how
components work together.
Package Diagrams: Role: Package diagrams show the organization of classes, components, and other
elements into packages. They show how packages depend on each other and how they relate to each other.
Package diagrams are useful for understanding the overall structure of a system and how different parts of
the system are related.
Deployment Diagrams: Role: Deployment diagrams show how components are deployed to physical
hardware or software environments. They show the nodes (physical or virtual hardware), and the
components that are deployed on them. Deployment diagrams are useful for understanding how a system is
deployed and how it interacts with its environment.
Packages are used to organize elements into groups, making it easier to manage and understand complex
systems. Advanced structural modeling with packages allows software engineers to model the organization
and structure of a system, including its components, classes, interfaces, and other elements.
Here are some examples of how packages can be used in advanced structural modeling:
Organizing Classes and Interfaces: Packages can be used to organize classes and interfaces into logical
groups. For example, all the classes and interfaces related to user management can be grouped into a
package called "User Management." This makes it easier to understand the overall structure of the system
and find the relevant classes and interfaces.
Representing Layers: Packages can be used to represent layers in a system. For example, the presentation
layer, business logic layer, and data access layer can each be represented as a separate package. This makes
it easier to manage the layers independently and to understand the dependencies between them.
Separating Concerns: Packages can be used to separate concerns within a system. For example, all the
classes related to logging can be grouped into a package called "Logging." This separates the logging
functionality from other parts of the system and makes it easier to modify or replace the logging component.
Representing Subsystems: Packages can be used to represent subsystems within a larger system. For
example, a system that includes multiple modules or components can be represented using packages to group
related elements together. This makes it easier to manage and understand the system as a
ATM Transaction