SOFTWARE ENGINEERING 2

Educator : Ms. Mansi Shah

Assistant Professor
Sutex Bank College of Computer Application and Science, Amroli

Educator : Ms. Mansi Shah

1.4 UML

Educator : Ms. Mansi Shah

Introduction to UML
 UML is short form of Unified Modeling Language

 UML is a standardized modeling language consisting of an

integrated set of diagrams, developed to help system and
software developers.

 UML helps in specifying, visualizing, constructing, and

documenting the artifacts of software systems.

Educator : Ms. Mansi Shah

The Origin of UML
 UML is a notation that resulted from the unification of OMT
from
 Object Modeling Technique OMT [James
Rumbaugh 1991] - was best for analysis and data-intensive
information systems.

Educator : Ms. Mansi Shah

Benefits of UML
 Provide users with a ready-to-use, expressive visual
modeling language so they can develop and exchange
meaningful models.
 Provide extensibility and specialization mechanisms to
extend the core concepts.
 Be independent of particular programming languages and
development processes.
 Provide a formal basis for understanding the
modeling language.
 Encourage the growth of the OO tools market.
 Support higher-level development concepts such as
collaborations, frameworks, patterns and
components.

Educator : Ms. Mansi Shah

Views of System Model for
Represented by UML Diagram
 Structure diagram
 Behavior diagram

Educator : Ms. Mansi Shah

Structure diagrams
 Structure diagrams show the static structure of the
system.

 The elements in a structure diagram represent the

meaningful concepts of a system, and may include
abstract, real world and implementation concepts.

Educator : Ms. Mansi Shah

 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

Educator : Ms. Mansi Shah

Behavior diagrams
 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.

Educator : Ms. Mansi Shah

 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
7. Timing Diagram

Educator : Ms. Mansi Shah

Diagram Hierarchy

Educator : Ms. Mansi Shah

What is a Class Diagram?
 Class Diagram gives the static view of an application.

 A class diagram describes the types of objects in the

system and the different types of relationships that exist
among them.

 This modeling method can run with almost all Object-

Oriented Methods.

 A class can refer to another class.

 A class can have its objects or may inherit from other

classes.

Educator : Ms. Mansi Shah

 UML Class Diagram gives an overview of a software
system by displaying classes, attributes, operations, and
their relationships.

 This Diagram includes the class name, attributes, and

operation in separate designated compartments.

 Class Diagram helps construct the code for the

software application development.

Educator : Ms. Mansi Shah

Benefits of Class Diagram
 Class Diagram Illustrates data models for even very
complex information systems
 It provides an overview of how the application is structured
before studying the actual code. This can easily reduce the
maintenance time
 It helps for better understanding of general schematics of
an application.
 Allows drawing detailed charts which highlights code
required to be programmed
 Helpful for developers and other stakeholders.

Educator : Ms. Mansi Shah

Essential elements of A UML
class diagram
 Class Name
 Attributes
 Operations

Educator : Ms. Mansi Shah

Class Name
 The name of the class is only needed in the graphical
representation of the class.

 It appears in the topmost compartment.

 A class is the blueprint of an object which can share the

same relationships, attributes, operations, & semantics.

 The class is rendered as a rectangle, including its name,

attributes, and operations in separate compartments.

Educator : Ms. Mansi Shah

Following rules must be taken care
of while representing a class:
 A class name should always start with a capital letter.

 A class name should always be in the center of the first

compartment.

 A class name should always be written in bold format.

 An abstract class name should be written in italics

format.

Educator : Ms. Mansi Shah

Attributes
 An attribute is named property of a
class which describes the object being
modeled.
 In the class diagram, this component
is placed just below the name-
compartment.

 A derived attribute is computed from

other attributes. For example, an age
of the student can be easily computed
from his/her birth date.

Educator : Ms. Mansi Shah

Attributes characteristics
 The attributes are generally written along with the visibility
factor.
 Public, private, protected and package are the four
visibilities which are denoted by +, -, #, or ~ signs
respectively.
 Visibility describes the accessibility of an attribute of a
class.
 Attributes must have a meaningful name that describes
the use of it in a class.

Educator : Ms. Mansi Shah

Relationships
 There are mainly three kinds of relationships in UML

1. Dependencies
2. Generalizations
3. Associations

Educator : Ms. Mansi Shah

Dependency

 A dependency means the relation between two or more

classes in which a change in one may force changes in
the other.

 However, it will always create a weaker relationship.

 Dependency indicates that one class depends on

another.

Educator : Ms. Mansi Shah

 In the following example, Student has a dependency on
College

College

Dependency

Student

Educator : Ms. Mansi Shah

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.

Educator : Ms. Mansi Shah

 In this example, the class Student is generalized from Person
Class.

Person

Generalized

Student

Educator : Ms. Mansi Shah

Association
 This kind of relationship represents static relationships
between classes A and B.
 For example; an employee works for an organization.

Works for
Employee Organization

Educator : Ms. Mansi Shah

Rules for Association

 Association is mostly verb or a verb phrase or noun or noun

phrase.
 It should be named to indicate the role played by the class
attached at the end of the association path.
 Mandatory for reflexive associations
 In this example, the relationship between student and
college is shown which is studies.

Educator : Ms. Mansi Shah

 Association

Multiplicity Aggregation Composition

Educator : Ms. Mansi Shah

Multiplicity
 A multiplicity is a factor associated with an attribute.
 It specifies how many instances of attributes are created
when a class is initialized.
 If a multiplicity is not specified, by default one is considered
as a default multiplicity.
 Let's say that that there are 100 students in one college. The
college can have multiple students.

Educator : Ms. Mansi Shah

Aggregation
 Aggregation is a special type of association that models a
whole- part relationship between aggregate and its parts.

 For example, the class college is made up of one or more

student.
 In aggregation, the contained classes are never
totally dependent on the lifecycle of the container.
 Here, the college class will remain even if the student
is not available.

Educator : Ms. Mansi Shah

Composition

 The composition is a special type of aggregation which

denotes strong ownership between two classes when one
class is a part of another class.

 For example, if college is composed of classes student.

 The college could contain many students, while each student
belongs to only one college.
 So, if college is not functioning all the students also
removed.

Educator : Ms. Mansi Shah

Aggregation vs. Composition
Aggregation
Aggregation indicates a
relationship where the child
can exist separately from their
parent class.
Example: Automobile (Parent)
and Car (Child). So, If you
delete the Automobile, the
child Car still exist
Composition
Composition display
relationship where the child
will never exist independent of
the parent.
Example: House (parent) and
Room (child). Rooms will never
separate into a House.
Educator : Ms. Mansi Shah
Educator : Ms. Mansi Shah
Educator : Ms. Mansi Shah
What is a Use Case Diagram?
 A use case diagram is a dynamic or behavior diagram in UML.
 Use case diagrams model the functionality of a system using
actors and use cases.
 Use cases are a set of actions, services, and functions that
the system needs to perform.
 In this context, a "system" is something being developed or
operated, such as a web site.
 The "actors" are people or entities operating under defined
roles within the system.

Educator : Ms. Mansi Shah

Basic Use Case Diagram Symbols
and Notations
 System
Draw your system's
boundaries using a
rectangle that contains
use cases. Place actors
outside the system's
boundaries.
 Use Case
Draw use cases using
ovals. Label the ovals
with verbs that
represent the system's
functions.

Educator : Ms. Mansi Shah

 Actors
Actors are the users of a
system. When one system is
the actor of another system,
label the actor system with the
actor stereotype.
 Stereotype

The standard notation is to enclose the word in << >> .

Stereotypes provide a means to extend the UML without
modifying it.
A stereotype functions as a qualifier on a model element,
providing more information about the role of the element
without dictating its implementation.

Educator : Ms. Mansi Shah

Relationships
 Relationship are illustrated between an actor and a use case
using a simple line.
 For relationships among use cases, use arrows labeled either
“include" or "extends."

Educator : Ms. Mansi Shah

 A “include" relationship indicates that one use case is needed
by another in order to perform a task.
 Use case include is a directed relationship between
two use cases which is used to show that behaviour of
the included use case (the addition) is inserted into the
behaviour of the including (the base) use case

 Few things to consider when using the <<include>>

relationship.
◦ The base use case is incomplete without the included use
case.
◦ The included use case is mandatory and not optional.

Educator : Ms. Mansi Shah

 An "extends" relationship indicates alternative options under
a certain use case.

 Extends is used when you understand that your use case is

too much complex. So you extract the complex steps into
their own "extension" use cases.

 Includes is used when you see common behaviour in

two use cases.

Educator : Ms. Mansi Shah

Example

Educator : Ms. Mansi Shah

Top level Use case
Educator : Ms. Mansi Shah
view items use case.

Educator : Ms. Mansi Shah

checkout, authentication and payment use cases.

Educator : Ms. Mansi Shah