3.7.

1 ER Diagram:

An entity relationship diagram (ERD) shows the relationships of entity sets stored
in a database. An entity in this context is an object, a component of data. An entity
set is a collection of similar entities. These entities can have attributes that define
its properties.

By defining the entities, their attributes, and showing the relationships between
them, an ER diagram illustrates the logical structure of databases.ER diagrams are
used to sketch out the design of a database.
3.7.2 Class Diagram:

Class diagram is a static diagram. It represents the static view of an application.

Class diagram is not only used for visualizing, describing, and documenting
different aspects of a system but also for constructing executable code of the
software application.
Class diagram describes the attributes and operations of a class and also the
constraints imposed on the system. The class diagrams are widely used in the
modeling of object oriented systems because they are the only UML diagrams,
which can be mapped directly with object-oriented languages.

Class diagram shows a collection of classes, interfaces, associations, collaborations,

and constraints. It is also known as a structural diagram.

 UML Class Diagram Shapes

 Classes and interfaces in UML show architecture and features of the

designed system.

 Aggregation is a special type of association in which objects are

assembled or configured together to create a more complex object. An
aggregation describes a group of objects and how you interact with
 them.

 Dependency relationship is a relationship in which one element, the

client, uses or depends on another element, the supplier.

 Composition represents whole-part relationships and is a form of

aggregation.

 Generalization is a relationship in which one model element (the child)

is based on another model element (the parent).
  Association is a relationship between two classifiers, such as classes or
use cases that describes the reasons for the relationship and the rules
that govern the relationship.

3.7.3 Use Case Diagram:

A use case diagram at its simplest is a representation of a user's interaction with

the system that shows the relationship between the user and the different use
cases in which the user is involved. A use case diagram can identify the different
types of users of a system and the different use cases and will often be
accompanied by other types of diagrams as well. The use cases are represented by
either circles or ellipses.

 Use Case

• A use case represents a user goal that can be achieved by accessing the
system or software application. In Visual Paradigm, you can make use of the sub-
diagram feature to describe the interaction between user and system within a use case by creating
a sub-sequence diagram under a use case. You can also describe the use case scenario using the
 Flow of Events editor.

 Actor

• Actors are the entities that interact with a system. Although in most cases,
actors are used to represent the users of system, actors can actually be
anything that needs to exchange information with the system. So, an actor may
be people, computer hardware, other systems, etc.

 System

• The scope of a system can be represented by a system (shape), or sometimes

known as a system boundary. The use cases of the system are placed inside
 the system shape, while the actor who interact with the system are put outside the system.
The use cases in the system make up the total requirements of the system.

 Include

• An include relationship specifies how the behavior for the inclusion use case
is inserted into the behavior defined for the base use case.

 Extend

• An extend relationship specifies how the behavior of the extension use case
can be inserted into the behavior defined for the base use case.

 Dependency
• A dependency relationship represents that a model element relies on another
model element for specification and/or implementation.

 Generalization

• A generalization relationship is used to represent inheritance relationship

between model elements of same type. The more specific model element
share the same specification with. The more general the model element but
carries more details in extra.

 Realization

• A realization is a relationship between a specification and its

implementation.
  Collaboration

• A collaboration describes a structure of collaborating elements (roles), each

performing a specialized function, which collectively accomplish some
desired functionality.
3.7.4 Sequence Diagram:

A sequence diagram simply depicts interaction between objects in a sequential

order i.e. the order in which these interactions take place. We can also use the
terms event diagrams or event scenarios to refer to a sequence diagram. Sequence
diagrams describe how and in what order the objects in a system function. These
diagrams are widely used by businessmen and software developers to document
and understand requirements for new and existing systems.

Sequence Diagram Notations:

 Lifeline Notation
• A sequence diagram is made up of several of these lifeline notations
that should be arranged horizontally across the top of the diagram. No
two lifeline notations should overlap each other. They represent the
different objects or parts that interact with each other in the system
during the sequence.
• A lifeline notation with an actor element symbol is used when the particular
sequence diagram is owned by a use case.

• A lifeline with an entity element represents system data. For example, in a

customer service application, the Customer entity would manage all data
related to a customer.
• A lifeline with a boundary element indicates a system boundary/ software
element in a system; for example, user interface screens, database gateways
or menus that users interact with, are boundaries.

• And a lifeline with a control element indicates a controlling entity or

manager. It organizes and schedules the interactions between the boundaries
and entities and serves as the mediator between them.
• A synchronous message is used when the sender waits for the receiver to
process the message and return before carrying on with another
message. The arrowhead used to indicate this type of message is a solid one,
like the one below.
• An asynchronous message is used when the message caller does not wait for
the receiver to process the message and return before sending other
messages to other objects within the system. The arrowhead used to show
this type of message is a line arrow.