Blog’s Class diagram
What is a Class Diagram?
• A Class
Diagram is a diagram describing the structure of a system
• shows the system's
• classes
• Attributes
• operations
(or methods),
• Relationships
among the classes.
The class diagram is the main building
block of modelling. It is used both
for general conceptual modelling of the systematics of
the application, and for detailed modelling translating the models into programming code. Class diagrams can also be used for data modelling. The
classes in a class diagram represent both the main objects, interactions in the
application and the classes to be programmed.
In the diagram, classes are represented with boxes which contain three parts:
· The top part contains the name of the class
· The middle part contains the attributes of the class
· The bottom part gives the methods or operations the class can take or undertake
In the design of a system, a number of classes are identified and grouped together in a class diagram which helps to determine the static relations between those objects. With detailed modelling, the classes of the conceptual design are often split into a number of subclasses.
Class
· The top part contains the name of the class
· The middle part contains the attributes of the class
· The bottom part gives the methods or operations the class can take or undertake
In the design of a system, a number of classes are identified and grouped together in a class diagram which helps to determine the static relations between those objects. With detailed modelling, the classes of the conceptual design are often split into a number of subclasses.
Class
•
Describes a set of objects having
similar:
–
Attributes (status)
–
Operations (behavior)
–
Relationships with other classes
•
Attributes and operations may
–
have their visibility marked:
–
"+" for public
–
"#" for protected
–
"−" for private
–
"~" for package
Instance
Level Relationship
Links
The basic relationship
Association
• An
association between two classes indicates that objects at one end of an
association “recognize” objects at the other end and may send messages to them.
For Example : Relation between An employee and company .
Aggregation
•
A
special form of association that models a whole-part relationship between an
aggregate (the whole) and its parts.
Models a “is a part-part of”
relationship
For Exampel : Car – Door – House
Generalization
•
Indicates
that objects of the specialized class (subclass) are substitutable for objects
of the generalized class (super-class).
–
“is
kind of” relationship.
Realization
•
A
realization relationship indicates that one class implements a behavior
specified by another class (an interface or protocol).
•
An
interface can be realized by many classes.
Realizations can only be shown on class or component diagrams.
General
Relationship
Dependency
•
Dependency is a weaker form
of relationship which indicates that one class depends on another because it
uses it at some point in time.
•
One
class depends on another if the independent class is a parameter variable or
local variable of a method of the dependent class.
•
This is different from an association, where
an attribute of the dependent class is an instance of the independent class.
Multiplicity
A Multiplicity gives an instant to be accommodated in
the classroom. For example, in theemployee class, we might have
had some instant, one for Ani, one for the Ina, one for Nanaand
so on. So the Multiplicity of the class of employees is
set to n. classroom control, TheMultiplicity is set to 1, because
at the time the application is running only one class.
Analysis
Styerotypes
In the early stages of a project's technical analysis, class
diagrams can be used to produce early conceptual models of the system. Classes
at this stage often take the form of boundaries, controls and entities and
rarely survive into the design without heavy changes.
Analysis
Classes
•
A technique for finding analysis classes which
uses three different perspectives of the system:
•
The boundary between the system and its actors
(Boundary)
a) •
A technique for finding analysis classes which
uses three different perspectives of the system:
•
The boundary between the system and its actors
(Boundary)
a)
Boundary classes handle the communication between
actors and the system's internal components. They might be user interfaces,
system interfaces or device interfaces (for example). They are identified by
each actor–use-case pair on the system's use-case diagram, with one and only
one boundary class existing for each pair.
b) They are drawn as circles with a short line to the left attached
to a vertical line the same height as the circle (as though it is attached to
the side of the use-case system boundary). Alternatively, they can be drawn as
normal classes with the «boundary» stereotype notation above the class name.
•
The information the system uses (Entity)
a)
Entity classes model the information handled by the
system, and sometimes the behavior associated with the information. They should
not be identified as database tables or other data-stores.
b)
They are drawn as circles with a short line attached
to the bottom of the circle. Alternatively, they can be drawn as normal classes
with the «entity» stereotype notation above the class name.
•
The control logic of the system (Control)
Control classes handle the flow of
control for a use-case and can therefore be seen as co-ordinating
representation classes. These do not do everything in the use case, but
co-ordinate with other classes that can do the work for them.
Boundary
Classes
•
Models the interaction between the system’s
surroundings and its inner workings
Entity
Classes
•
Models the key concepts of the system
•
Usually models information that is persistent
•
Contains the logic that solves the system
problem
•
Is environment independent
•
Can be used in multiple use cases
For Example : Report
Control Classes
•
Controls and coordinates the behavior of a use
case
•
Delegates the work of the use case to classes
–
A control class should tell other classes to
do something and should never do anything except for directing
•
Control classes decouple boundary and entity
classes
•
Often, there is one control class per use case
