IT 118 - SIA - Module 4

Bicol University College of Science
CS/IT Department IT 118 - System Integration and Architecture

Legazpi City Module 4: Modeling Requirements
Module 4
Modeling Requirements
Modeling requirements (or requirements modeling) is the process used in software development
projects where requirements and solutions constantly evolve through collaborative efforts and
teamwork. In any IT project, there is always a possibility that developers could misinterpret software
requirements. Most commonly, this will be due to a lack of effective communication and briefing. This
can result in discrepancies in the software that is being built.
To mitigate any potential risks, employees and teams should create more detailed visualization
processes. This will help ensure that the project’s exact requirements are documented clearly. By doing
so, you can create a strong foundation for the project’s overall needs and specifications. Thus, affording
you a higher-level of understanding. By using this method of cross-functional and self-organizing teams,
you can ensure that your team meets the exact needs of the stakeholders.
The main aim of requirements modeling is to support the end goals of system or software development.
It also aims to achieve these objectives:
• Identify and establish the best practices required to create an effective model
• Outline the ways you intend to put said practices into action
• Always have alternatives to improve the overall modeling approach
5 Key Benefits of Requirements Modeling
By using this process, you will enhance the overall clarity of your requirements. This can drastically
improve the outcomes of your software projects. Below are the main benefits of using modern
requirements modeling and management systems:
1. Easy to create simulations

2. Able to automatically generate documents
3. Can automatically conduct tests
4. Allows for easy integration into development and test tools
5. Can easily manage evolving requests and requirements
Unified Modeling Language (UML)

UML, short for Unified Modeling Language, is a standardized modeling language consisting of an
integrated set of diagrams, developed to help system and software developers for specifying,
visualizing, constructing, and documenting the artifacts of software systems, as well as for business
modeling and other non-software systems. The UML represents a collection of best engineering
practices that have proven successful in the modeling of large and complex systems. The UML is a
very important part of developing object oriented software and the software development process. The
Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024
Page 1 of 24
UML uses mostly graphical notations to express the design of software projects. Using the UML helps
project teams communicate, explore potential designs, and validate the architectural design of the
software. In this article, we will give you detailed ideas about what is UML, the history of UML and a
description of each UML diagram type, along with UML examples.
As the strategic value of software increases for many companies, the industry looks for techniques to
automate the production of software and to improve quality and reduce cost and time-to-market. These
techniques include component technology, visual programming, patterns and frameworks. Businesses
also seek techniques to manage the complexity of systems as they increase in scope and scale. In
particular, they recognize the need to solve recurring architectural problems, such as physical
distribution, concurrency, replication, security, load balancing and fault tolerance. Additionally, the
development for the World Wide Web, while making some things simpler, has exacerbated these
architectural problems. The Unified Modeling Language (UML) was designed to respond to these
needs. The primary goals in the design of the UML summarize by Page-Jones in Fundamental Object-
Oriented Design in UML as follows:
1. Provide users with a ready-to-use, expressive visual modeling language so they can develop
and exchange meaningful models.
2. Provide extensibility and specialization mechanisms to extend the core concepts.
3. Be independent of particular programming languages and development processes.
4. Provide a formal basis for understanding the modeling language.
5. Encourage the growth of the OO tools market.
6. Support higher-level development concepts such as collaborations, frameworks, patterns and
components.
7. Integrate best practices.
The first thing to notice about the UML is that there are a lot of different diagrams (models) to get used
to. The reason for this is that it is possible to look at a system from many different viewpoints. A software
development will have many stakeholders playing a part.
For Example:
• Analysts
• Designers
• Coders
• Testers
• QA
• The Customer
• Technical Authors
All of these people are interested in different aspects of the system, and each of them require a different
level of detail. For example, a coder needs to understand the design of the system and be able to
convert the design to a low level code. By contrast, a technical writer is interested in the behavior of

Page 2 of 24
the system as a whole, and needs to understand how the product functions. The UML attempts to
provide a language so expressive that all stakeholders can benefit from at least one UML diagram.
Here's a visual representation of the UML 2 Diagram Structure below:
Structure diagrams show the static structure of the system and its parts on different abstraction and
implementation levels and how they are related to each other. The elements in a structure diagram
represent the meaningful concepts of a system, and may include abstract, real world and
implementation concepts, there are seven types of structure diagram as follows:
1. Class Diagram
2. Component Diagram
3. Deployment Diagram
4. Object Diagram
5. Package Diagram
6. Composite Structure Diagram
7. Profile Diagram
Behavior diagrams show the dynamic behavior of the objects in a system, which can be described as
a series of changes to the system over time, there are seven types of behavior diagrams as follows:
1. Use Case Diagram

2. Activity Diagram
3. State Machine Diagram
4. Sequence Diagram
5. Communication Diagram
6. Interaction Overview Diagram

Page 3 of 24
7. Timing Diagram
Let have a brief discussion with UML Diagrams starting with Structure diagrams.
1. Class Diagram
The class diagram is a central modeling technique that runs through nearly all object-oriented methods.
This diagram describes the types of objects in the system and various kinds of static relationships which
exist between them.
Relationships
There are three principal kinds of relationships which are important:
• Association - represent relationships between instances of types (a person works for a company,
a company has a number of offices.
• Inheritance - the most obvious addition to ER diagrams for use in OO. It has an immediate
correspondence to inheritance in OO design.
• Aggregation - Aggregation, a form of object composition in object-oriented design.
Class Diagram Example
2. Component Diagram
In the Unified Modeling Language, a component diagram depicts how components are wired together
to form larger components or software systems. It illustrates the architectures of the software
components and the dependencies between them. Those software components including run-time
components, executable components also the source code components.

Page 4 of 24
Component Diagram Example
3. Deployment Diagram
The Deployment Diagram helps to model the physical aspect of an Object-Oriented software system.
It is a structure diagram which shows architecture of the system as deployment (distribution) of software
artifacts to deployment targets. Artifacts represent concrete elements in the physical world that are the
result of a development process. It models the run-time configuration in a static view and visualizes the
distribution of artifacts in an application. In most cases, it involves modeling the hardware configurations
together with the software components that lived on.
Deployment Diagram Example

Page 5 of 24
4. Object Diagram
An object diagram is a graph of instances, including objects and data values. A static object diagram
is an instance of a class diagram; it shows a snapshot of the detailed state of a system at a point in
time. The difference is that a class diagram represents an abstract model consisting of classes and
their relationships. However, an object diagram represents an instance at a particular moment, which
is concrete in nature. The use of object diagrams is fairly limited, namely to show examples of data
structure.
Class Diagram vs Object Diagram - An Example
Some people may find it difficult to understand the difference between a UML Class Diagram and a
UML Object Diagram as they both comprise of named "rectangle blocks", with attributes in them, and
with linkages in between, which make the two UML diagrams look similar. Some people may even
think they are the same because in the UML tool they use both the notations for Class Diagram and
Object Diagram are put inside the same diagram editor - Class Diagram. But in fact, Class Diagram
and Object Diagram represent two different aspects of a code base.
Relationship between Class Diagram and Object Diagram
You create "classes" when you are programming. For example, in an online banking system you may
create classes like 'User', 'Account', 'Transaction', etc. In a classroom management system you may
create classes like 'Teacher', 'Student', 'Assignment', etc. In each class, there are attributes and
operations that represent the characteristic and behavior of the class. Class Diagram is a UML
diagram where you can visualize those classes, along with their attributes, operations and the inter-
relationship.
UML Object Diagram shows how object instances in your system are interacting with each other at a
particular state. It also represents the data values of those objects at that state. In other words, a
UML Object Diagram can be seen as a representation of how classes (drawn in UML Class Diagram)
are utilized at a particular state.
If you are not a fan of those definition stuff, take a look at the following UML diagram examples. I
believe that you will understand their differences in seconds.
Class Diagram Example
The following Class Diagram example represents two classes - User and Attachment. A user can
upload multiple attachment so the two classes are connected with an association, with 0..* as
multiplicity on the Attachment side.

Page 6 of 24
Object Diagram Example
The following Object Diagram example shows you how the object instances of User and Attachment
class "look like" at the moment Peter (i.e. the user) is trying to upload two attachments. So there are
two Instance Specification for the two attachment objects to be uploaded.
5. Package Diagram
Package diagram is UML structure diagram which shows packages and dependencies between the
packages. Model diagrams allow to show different views of a system, for example, as multi-layered
(aka multi-tiered) application - multi-layered application model.
Package Diagram Example

Page 7 of 24
6. Composite Structure Diagram
Composite Structure Diagram is one of the new artifacts added to UML 2.0. A composite structure
diagram is similar to a class diagram and is a kind of component diagram mainly used in modeling a
system at micro point-of-view, but it depicts individual parts instead of whole classes. It is a type of
static structure diagram that shows the internal structure of a class and the collaborations that this
structure makes possible.
This diagram can include internal parts, ports through which the parts interact with each other or
through which instances of the class interact with the parts and with the outside world, and
connectors between parts or ports. A composite structure is a set of interconnected elements that
collaborate at runtime to achieve some purpose. Each element has some defined role in the
collaboration.
Composite Structure Diagram Example
7. Profile Diagram
A profile diagram enables you to create domain and platform specific stereotypes and define the
relationships between them. You can create stereotypes by drawing stereotype shapes and relate
them with composition or generalization through the resource-centric interface. You can also define
and visualize tagged values of stereotypes.
Profile Diagram Example

Page 8 of 24
Now, let us have a brief discussion about UML Behavior Diagrams.
1. Use Case Diagram
A use-case model describes a system's functional requirements in terms of use cases. It is a model of
the system's intended functionality (use cases) and its environment (actors). Use cases enable you to
relate what you need from a system to how the system delivers on those needs.
Think of a use-case model as a menu, much like the menu you'd find in a restaurant. By looking at the
menu, you know what's available to you, the individual dishes as well as their prices. You also know
what kind of cuisine the restaurant serves: Italian, Mexican, Chinese, and so on. By looking at the
menu, you get an overall impression of the dining experience that awaits you in that restaurant. The
menu, in effect, "models" the restaurant's behavior.
Because it is a very powerful planning instrument, the use-case model is generally used in all phases
of the development cycle by all team members.
Use Case Diagram Example
2. Activity Diagram
Activity diagrams are graphical representations of workflows of stepwise activities and actions with
support for choice, iteration and concurrency. It describes the flow of control of the target system,
such as the exploring complex business rules and operations, describing the use case also the
business process. In the Unified Modeling Language, activity diagrams are intended to model both
computational and organizational processes (i.e. workflows).

Page 9 of 24
Activity Diagram Example
3. State Machine Diagram
A state diagram is a type of diagram used in UML to describe the behavior of systems which is based
on the concept of state diagrams by David Harel. State diagrams depict the permitted states and
transitions as well as the events that effect these transitions. It helps to visualize the entire lifecycle of
objects and thus help to provide a better understanding of state-based systems.
State Machine Diagram Example

Page 10 of 24
4. Sequence Diagram
The Sequence Diagram models the collaboration of objects based on a time sequence. It shows how
the objects interact with others in a particular scenario of a use case. With the advanced visual
modeling capability, you can create complex sequence diagram in few clicks. Besides, some
modeling tool such as Visual Paradigm can generate sequence diagram from the flow of events
which you have defined in the use case description.
Sequence Diagram Example
5. Communication Diagram
Similar to Sequence Diagram, the Communication Diagram is also used to model the dynamic
behavior of the use case. When compare to Sequence Diagram, the Communication Diagram is more
focused on showing the collaboration of objects rather than the time sequence. They are actually

Page 11 of 24
semantically equivalent, so some of the modeling tool such as, Visual Paradigm allows you to
generate it from one to the other.
Communication Diagram Example
6. Interaction Overview Diagram
The Interaction Overview Diagram focuses on the overview of the flow of control of the interactions. It
is a variant of the Activity Diagram where the nodes are the interactions or interaction occurrences. The
Interaction Overview Diagram describes the interactions where messages and lifelines are hidden. You
can link up the "real" diagrams and achieve high degree navigability between diagrams inside the
Interaction Overview Diagram.

Page 12 of 24
Interaction Overview Diagram
7. Timing Diagram
Timing Diagram shows the behavior of the object(s) in a given period of time. Timing diagram is a
special form of a sequence diagram. The differences between timing diagram and sequence diagram
are the axes are reversed so that the time are increase from left to right and the lifelines are shown in
separate compartments arranged vertically.
Timing Diagram Example

Page 13 of 24
You now have an idea of what are the different types of UML diagrams. Let us now take a deeper look
on one of the most useful types of diagrams in UML which is the Class Diagram. Class Diagrams clearly
map out the structure of a particular system by modeling its classes, attributes, operations, and
relationships between objects.
What is Class Diagram?

In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of static
structure diagram that describes the structure of a system by showing the system's classes, their
attributes, operations (or methods), and the relationships among objects.
Purpose of Class Diagrams
1. Shows static structure of classifiers in a system

2. Diagram provides a basic notation for other structure diagrams prescribed by UML
3. Helpful for developers and other team members too
4. Business Analysts can use class diagrams to model systems from a business perspective
A UML class diagram is made up of:
• A set of classes and

• A set of relationships between classes
What is a Class?
A description of a group of objects all with similar roles in the system, which consists of:
• Structural features (attributes) define what objects of the class "know"

o Represent the state of an object of the class
o Are descriptions of the structural or static features of a class
• Behavioral features (operations) define what objects of the class "can do"
o Define the way in which objects may interact
o Operations are descriptions of behavioral or dynamic features of a class
Class Notation
A class notation consists of three parts:
1. Class Name
• The name of the class appears in the first partition.
2. Class Attributes
• Attributes are shown in the second partition.
• The attribute type is shown after the colon.
• Attributes map onto member variables (data members) in code.
3. Class Operations (Methods)

Page 14 of 24
• Operations are shown in the third partition. They are services the class provides.
• The return type of a method is shown after the colon at the end of the method signature.
• The return type of method parameters is shown after the colon following the parameter name.
• Operations map onto class methods in code
The graphical representation of the class - MyClass as shown above:
• MyClass has 3 attributes and 3 operations

• Parameter p3 of op2 is of type int
• op2 returns a float
• op3 returns a pointer (denoted by a *) to Class6
Class Relationships
A class may be involved in one or more relationships with other classes. A relationship can be one of
the following types:
1. Inheritance (or Generalization)
• Represents an "is-a" relationship.

• An abstract class name is shown in italics.
• SubClass1 and SubClass2 are specializations of Super Class.
• A solid line with a hollow arrowhead that point from the child to the parent class

Page 15 of 24
2. Simple Association
• A structural link between two peer classes.

• There is an association between Class1 and Class2
• A solid line connecting two classes
3. Aggregation
A special type of association. It represents a "part of" relationship.
• Class2 is part of Class1.

• Many instances (denoted by the *) of Class2 can be associated with Class1.
• Objects of Class1 and Class2 have separate lifetimes.
• A solid line with an unfilled diamond at the association end connected to the class of
composite
4. Composition
A special type of aggregation where parts are destroyed when the whole is destroyed.
• Objects of Class2 live and die with Class1.

• Class2 cannot stand by itself.
• A solid line with a filled diamond at the association connected to the class of composite
5. Dependency
• Exists between two classes if the changes to the definition of one may cause changes to the
other (but not the other way around).

Page 16 of 24
• Class1 depends on Class2

• A dashed line with an open arrow
Relationship Names
• Names of relationships are written in the middle of the association line.

• Good relation names make sense when you read them out loud:
• "Every spreadsheet contains some number of cells",
• "an expression evaluates to a value"
• They often have a small arrowhead to show the direction in which direction to read the
relationship, e.g., expressions evaluate to values, but values do not evaluate to expressions.
Relationship - Roles
• A role is a directional purpose of an association.

• Roles are written at the ends of an association line and describe the purpose played by that
class in the relationship.
• E.g., A cell is related to an expression. The nature of the relationship is that the expression is
the formula of the cell.
Navigability
The arrows indicate whether, given one instance participating in a relationship, it is possible to
determine the instances of the other class that are related to it.
The diagram above suggests that,
• Given a spreadsheet, we can locate all of the cells that it contains, but that
o we cannot determine from a cell in what spreadsheet it is contained.
• Given a cell, we can obtain the related expression and value, but
o given a value (or expression) we cannot find the cell of which those are attributes.
Visibility of Class attributes and Operations
In object-oriented design, there is a notation of visibility for attributes and operations. UML identifies
four types of visibility: public, protected, private, and package.

Page 17 of 24
The +, -, # and ~ symbols before an attribute and operation name in a class denote the visibility of the
attribute and operation.
• + denotes public attributes or operations

• - denotes private attributes or operations
• # denotes protected attributes or operations
• ~ denotes package attributes or operations
Class Visibility Example
In the example above:
• attribute1 and op1 of MyClassName are public

• attribute3 and op3 are protected.
• attribute2 and op2 are private.
Multiplicity
How many objects of each class take part in the relationships and multiplicity can be expressed as:
• Exactly one - 1
• Zero or one - 0..1
• Many - 0..* or *
• One or more - 1..*
• Exact Number - e.g. 3..4 or 6
• Or a complex relationship - e.g. 0..1, 3..4, 6.* would mean any number of objects other than 2
or 5
Multiplicity Example
• Requirement: A Student can take many Courses and many Students can be enrolled in one
Course.
• In the example below, the class diagram (on the left), describes the statement of the
requirement above for the static model while the object diagram (on the right) shows the
snapshot (an instance of the class diagram) of the course enrollment for the courses Software
Engineering and Database Management respectively)

Page 18 of 24
Dealing with Complex System - Multiple or Single Class Diagram?
Inevitably, if you are modeling a large system or a large business area, there will be numerous
entities you must consider. Should we use multiple or a single class diagram for modeling the
problem? The answer is:
• Instead of modeling every entity and its relationships on a single class diagram, it is better to
use multiple class diagrams.
• Dividing a system into multiple class diagrams makes the system easier to understand,
especially if each diagram is a graphical representation of a specific part of the system.
Perspectives of Class Diagram in Software Development Lifecycle
We can use class diagrams in different development phases of a software development lifecycle and
typically by modeling class diagrams in three different perspectives (levels of detail) progressively as
we move forward:
• Conceptual perspective: The diagrams are interpreted as describing things in the real world.
Thus, if you take the conceptual perspective you draw a diagram that represents the concepts
in the domain under study. These concepts will naturally relate to the classes that implement
them. The conceptual perspective is considered language-independent.
• Specification perspective: The diagrams are interpreted as describing software abstractions or
components with specifications and interfaces but with no commitment to a particular
implementation. Thus, if you take the specification perspective we are looking at the interfaces
of the software, not the implementation.
• Implementation perspective: The diagrams are interpreted as describing software
implementations in a particular technology and language. Thus, if you take the implementation
perspective we are looking at the software implementation.
Now, let us discuss on of one of the common UML diagrams used in software or system
development, the Use Case Diagram. Use Case diagram captures the functional requirements of the
system. Each use case in a use case diagram represents a high level business goal that yields a
measurable result of business values. (UML) Actors are connected with use cases to represent the
roles that interact with the functions.
What is Use Case Diagram?

A UML use case diagram is the primary form of system/software requirements for a new software
program underdeveloped. Use cases specify the expected behavior (what), and not the exact method
of making it happen (how). Use cases once specified can be denoted both textual and visual
representation (i.e. use case diagram). A key concept of use case modeling is that it helps us design a

Page 19 of 24
system from the end user's perspective. It is an effective technique for communicating system behavior
in the user's terms by specifying all externally visible system behavior.
A use case diagram is usually simple. It does not show the detail of the use cases:
• It only summarizes some of the relationships between use cases, actors, and systems.
• It does not show the order in which steps are performed to achieve the goals of each use case.
As said, a use case diagram should be simple and contains only a few shapes. If yours contain more
than 20 use cases, you are probably misusing use case diagram. Use case diagrams belong to the
family of behavioral diagrams.
Origin of Use Case
These days use case modeling is often associated with UML, although it has been introduced before
UML existed. Its brief history is as follow:
• In 1986, Ivar Jacobson first formulated textual and visual modeling techniques for specifying use
cases.
• In 1992 his co-authored book Object-Oriented Software Engineering - A Use Case Driven
Approach helped to popularize the technique for capturing functional requirements, especially in
software development.
Purpose of Use Case Diagram
Use case diagrams are typically developed in the early stage of development and people often apply
use case modeling for the following purposes:
• Specify the context of a system

• Capture the requirements of a system
• Validate a systems architecture
• Drive implementation and generate test cases
• Developed by analysts together with domain experts
Use Case Diagram at a Glance
A standard form of use case diagram is defined in the Unified Modeling Language as shown in the Use
Case Diagram example below:

Page 20 of 24
Use Case Notations
1. Actor
• Someone interacts with use case (system function).

• Named by noun.
• Actor plays a role in the business
• Similar to the concept of user, but a user can play different roles
• For example:
• A prof. can be instructor and also researcher
• plays 2 roles with two systems
• Actor triggers use case(s).
• Actor has a responsibility toward the system (inputs), and Actor has expectations from the
system (outputs).
2. Use Case
• System function (process - automated or manual)

• Named by verb + Noun (or Noun Phrase).
• i.e. Do something
• Each Actor must be linked to a use case, while some use cases may not be linked to actors.

Page 21 of 24
3. Communication Link
• The participation of an actor in a use case is shown by connecting an actor to a use case by a
solid link.
• Actors may be connected to use cases by associations, indicating that the actor and the use
case communicate with one another using messages.
4. Boundary of system
• The system boundary is potentially the entire system

as defined in the requirements document.
• For large and complex systems, each module may be the system boundary.
• For example, for an ERP system for an organization, each of the modules such as personnel,
payroll, accounting, etc.
• Can form a system boundary for use cases specific to each of these business functions.
• The entire system can span all of these modules depicting the overall system boundary
Use Case Relationship
Use cases share different kinds of relationships. Defining the relationship between two use cases is
the decision of the software analysts of the use case diagram. A relationship between two use cases
is basically modeling the dependency between the two use cases. The reuse of an existing use case
by using different types of relationships reduces the overall effort required in developing a system.
Use case relationships are listed as the following:
1. Extends
• Indicates that an "Invalid Password" use case may include (subject to specified in the
extension) the behavior specified by base use case "Login Account".
• Depict with a directed arrow having a dotted line. The tip of arrowhead points to the base use
case and the child use case is connected at the base of the arrow.
• The stereotype "<<extends>>" identifies as an extend relationship
2. Include
• When a use case is depicted as using the functionality of another use case, the relationship
between the use cases is named as include or uses relationship.

Page 22 of 24
• A use case includes the functionality described in another use case as a part of its business
process flow.
• A uses relationship from base use case to child use case indicates that an instance of the base
use case will include the behavior as specified in the child use case.
• An include relationship is depicted with a directed arrow having a dotted line. The tip of
arrowhead points to the child use case and the parent use case connected at the base of the
arrow.
• The stereotype "<<include>>" identifies the relationship as an include relationship.
3. Generalization
• A generalization relationship is a parent-child relationship between use cases.

• The child use case is an enhancement of the parent use case.
• Generalization is shown as a directed arrow with a triangle arrowhead.
• The child use case is connected at the base of the arrow. The tip of the arrow is connected to
the parent use case.
How to Identify Actor
Often, people find it easiest to start the requirements elicitation process by identifying the actors. The
following questions can help you identify the actors of your system (Schneider and Winters - 1998):
• Who uses the system?

• Who installs the system?
• Who starts up the system?
• Who maintains the system?
• Who shuts down the system?
• What other systems use this system?
• Who gets information from this system?
• Who provides information to the system?
• Does anything happen automatically at a present time?
How to Identify Use Cases?
Identifying the Use Cases, and then the scenario-based elicitation process carries on by asking what
externally visible, observable value that each actor desires. The following questions can be asked to
identify use cases, once your actors have been identified (Schneider and Winters - 1998):
• What functions will the actor want from the system?

Page 23 of 24
• Does the system store information? What actors will create, read, update or delete this
information?
• Does the system need to notify an actor about changes in the internal state?
• Are there any external events the system must know about? What actor informs the system of
those events?
References
https://reqtest.com/requirements-blog/requirements-modelling/
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-uml/
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-use-case-diagram/

Page 24 of 24

IT 118 - SIA - Module 4

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IT 118 - SIA - Module 4

Uploaded by

Copyright:

Available Formats

Bicol University College of Science

CS/IT Department IT 118 - System Integration and Architecture

5 Key Benefits of Requirements Modeling

1. Easy to create simulations

Unified Modeling Language (UML)

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

Here's a visual representation of the UML 2 Diagram Structure below:

1. Use Case Diagram

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

There are three principal kinds of relationships which are important:

Class Diagram Example

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

Component Diagram Example

Deployment Diagram Example

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

Class Diagram vs Object Diagram - An Example

Relationship between Class Diagram and Object Diagram

Class Diagram Example

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

Object Diagram Example

Package Diagram Example

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

6. Composite Structure Diagram

Composite Structure Diagram Example

Profile Diagram Example

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

Now, let us have a brief discussion about UML Behavior Diagrams.

1. Use Case Diagram

Use Case Diagram Example

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

Activity Diagram Example

3. State Machine Diagram

State Machine Diagram Example

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

Sequence Diagram Example

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

Communication Diagram Example

6. Interaction Overview Diagram

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

Interaction Overview Diagram

Timing Diagram Example

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

What is Class Diagram?

Purpose of Class Diagrams

1. Shows static structure of classifiers in a system

A UML class diagram is made up of:

• A set of classes and

• Structural features (attributes) define what objects of the class "know"

A class notation consists of three parts:

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

The graphical representation of the class - MyClass as shown above:

• MyClass has 3 attributes and 3 operations

1. Inheritance (or Generalization)

• Represents an "is-a" relationship.

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

• A structural link between two peer classes.

A special type of association. It represents a "part of" relationship.

• Class2 is part of Class1.

• Objects of Class2 live and die with Class1.

Instructor: Amie Dainne S. Esteves • A.Y. 2023-2024

• Class1 depends on Class2

• Names of relationships are written in the middle of the association line.

• A role is a directional purpose of an association.

The diagram above suggests that,