UML CLASS DIAGRAM
AND PACKAGES
By Dileep
Collaberos: “We Create Professionals”
AGENDA
 What is a Class Diagram?
 Essential Elements of a UML Class Diagram
 Packages and Class Diagrams
 Analysis Cla...
WHAT IS A CLASS DIAGRAM?
 The class diagram is the main building block in
object oriented modeling.
 They are being used...
CLASSES
 In the class diagram these classes are represented with boxes which
contain three parts.
 The upper part holds ...
Collaberos:WeCreateProfessionals
In the system design of a system, a number of classes are identified and grouped
together...
ESSENTIAL ELEMENTS OF A UML
CLASS DIAGRAM
 Class Diagram
 Class
 Attributes
 Operations
 Relationships
 Associations...
ASSOCIATIONS
 A semantic relationship between two or more
classes that specifies connections among their
instances.
 A s...
ASSOCIATIONS (CONT.)
 An association between two classes indicates that
objects at one end of an association “recognize”
...
ASSOCIATIONS (CONT.)
Collaberos:WeCreateProfessionals
StaffMember Student
1..* *instructs
instructor
Association
name
Role...
ASSOCIATIONS (CONT.)
 Multiplicity
 The number of instances of the class, next to which
the multiplicity expression appe...
ASSOCIATIONS (CONT.)
 Multiplicity Indicators
Collaberos:WeCreateProfessionals
Exactly one 1
Zero or more (unlimited) * (...
AGGREGATION
 A special form of association that models a whole-
part relationship between an aggregate (the whole)
and it...
COMPOSITION
 A strong form of aggregation
 The whole is the sole owner of its part.
 The part object may belong to only...
GENERALIZATION
 Indicates that objects of the specialized class
(subclass) are substitutable for objects of the
generaliz...
DEPENDENCY
 Dependency is a weaker form of relationship which indicates
that
 one class depends on another because it us...
REALIZATION
 A realization relationship indicates that one class
implements a behavior specified by another class
(an int...
CONSTRAINT RULES AND NOTES
 Constraints and notes annotate among
other things associations, attributes,
operations and cl...
TVRS EXAMPLE
Collaberos:WeCreateProfessionals
id : long
name : String
rank : int
Policeman
<<abstract>>
TrafficPoliceman i...
UML PACKAGES
 A package is a general purpose grouping
mechanism.
Can be used to group any UML element (e.g. use
case, ac...
LOGICAL DISTRIBUTION OF
CLASSES
 Emphasize the logical structure of the system
(High level view)
 Higher level of abstra...
PACKAGES AND CLASS DIAGRAMS
(CONT.)
 Add package information to class diagrams
Collaberos:WeCreateProfessionals
A
DE
F
G
...
PACKAGES AND CLASS DIAGRAMS
(CONT.)
 Add package information to class diagrams
Collaberos:WeCreateProfessionals
a.A
b.b.D...
ANALYSIS CLASSES
 A technique for finding analysis classes which
uses three different perspectives of the system:
 The b...
BOUNDARY CLASSES Models the interaction between the system’s
surroundings and its inner workings
 User interface classes...
ENTITY CLASSES
 Models the key concepts of the system
 Usually models information that is persistent
 Contains the logi...
CONTROL CLASSES Controls and coordinates the behavior of the
system
 Delegates the work to other classes
 A control cla...
TVRS EXAMPLE
Collaberos:WeCreateProfessionals
Violation
EditReportController
<<control>>
TrafficReport
Offender TrafficPol...
THANK YOU
Upcoming SlideShare
Loading in …5
×

Uml class diagram and packages ppt for dot net

4,268 views

Published on

What is a Class Diagram?
Essential Elements of a UML Class Diagram
Packages and Class Diagrams
Analysis Classes Approach

Published in: Education
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,268
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
272
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Uml class diagram and packages ppt for dot net

  1. 1. UML CLASS DIAGRAM AND PACKAGES By Dileep Collaberos: “We Create Professionals”
  2. 2. AGENDA  What is a Class Diagram?  Essential Elements of a UML Class Diagram  Packages and Class Diagrams  Analysis Classes Approach Collaberos:WeCreateProfessionals
  3. 3. WHAT IS A CLASS DIAGRAM?  The class diagram is the main building block in object oriented modeling.  They are being used both for  general conceptual modeling of the systematics of the application, and for detailed modeling translating the models into programming code.  The classes in a class diagram represent both  the main objects and or  interactions in the application and the objects to be programmed. Collaberos:WeCreateProfessionals
  4. 4. CLASSES  In the class diagram these classes are represented with boxes which contain three parts.  The upper part holds 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 Collaberos:WeCreateProfessionals Window size: Size visibility: boolean display() hide() Class Name Attributes Operations
  5. 5. Collaberos:WeCreateProfessionals In the system design of a system, a number of classes are identified and grouped together in a class diagram which helps to determine the statical relations between those objects. With detailed modeling, the classes of the conceptual design are often split in a number of subclasses.
  6. 6. ESSENTIAL ELEMENTS OF A UML CLASS DIAGRAM  Class Diagram  Class  Attributes  Operations  Relationships  Associations  Generalization  Dependency  Realization  Constraint Rules and Notes Collaberos:WeCreateProfessionals
  7. 7. ASSOCIATIONS  A semantic relationship between two or more classes that specifies connections among their instances.  A structural relationship, specifying that objects of one class are connected to objects of a second (possibly the same) class.  Example: “An Employee works for a Company” Collaberos:WeCreateProfessionals CompanyDepartmentEmployee
  8. 8. ASSOCIATIONS (CONT.)  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.  This property will help us discover less trivial associations using interaction diagrams. Collaberos:WeCreateProfessionals
  9. 9. ASSOCIATIONS (CONT.) Collaberos:WeCreateProfessionals StaffMember Student 1..* *instructs instructor Association name Role name Multiplicity Navigable (uni-directional) association Courses pre - requisites 0..3 Reflexive association Role *
  10. 10. ASSOCIATIONS (CONT.)  Multiplicity  The number of instances of the class, next to which the multiplicity expression appears, that are referenced by a single instance of the class that is at the other end of the association path.  Indicates whether or not an association is mandatory.  Provides a lower and upper bound on the number of instances. Collaberos:WeCreateProfessionals
  11. 11. ASSOCIATIONS (CONT.)  Multiplicity Indicators Collaberos:WeCreateProfessionals Exactly one 1 Zero or more (unlimited) * (0..*) One or more 1..* Zero or one (optional association) 0..1 Specified range 2..4 Multiple, disjoint ranges 2, 4..6, 8
  12. 12. 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. Collaberos:WeCreateProfessionals Whole Part Car Door House 1..*2..*
  13. 13. COMPOSITION  A strong form of aggregation  The whole is the sole owner of its part.  The part object may belong to only one whole  Multiplicity on the whole side must be zero or one.  The life time of the part is dependent upon the whole.  The composite must manage the creation and destruction of its parts. Collaberos:WeCreateProfessionals Circle Point 3..* 1 Polygon Point Circle
  14. 14. GENERALIZATION  Indicates that objects of the specialized class (subclass) are substitutable for objects of the generalized class (super-class).  “is kind of” relationship. Collaberos:WeCreateProfessionals Shape {abstract} Circle Super Class Sub Class An abstract class Generalization relationship {abstract} is a tagged value that indicates that the class is abstract. The name of an abstract class should be italicized
  15. 15. DEPENDENCY  Dependency is a weaker form of relationship which indicates that  one class depends on another because it uses it at some point of time.  Dependency exists if a class is a parameter variable or local variable of  a method of another class. Collaberos: We Create Professionals
  16. 16. 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.  A class may realize many interfaces. Collaberos:WeCreateProfessionals LinkedList <<interface>> List LinkedList List
  17. 17. CONSTRAINT RULES AND NOTES  Constraints and notes annotate among other things associations, attributes, operations and classes.  Constraints are semantic restrictions noted as Boolean expressions. UML offers many pre-defined constraints. Collaberos:WeCreateProfessionals id: long { value > 0 } Customer Order *1 { total < $50 } may be canceled Constraint Note
  18. 18. TVRS EXAMPLE Collaberos:WeCreateProfessionals id : long name : String rank : int Policeman <<abstract>> TrafficPoliceman id : long description : String TrafficReport id : long description : String Violation name : String id : long Offender 1..* 1 reports of 1..* issues1 * occuredAt : Date
  19. 19. UML PACKAGES  A package is a general purpose grouping mechanism. Can be used to group any UML element (e.g. use case, actors, classes, components and other packages.  Commonly used for specifying the logical distribution of classes.  A package does not necessarily translate into a physical sub-system. Collaberos:WeCreateProfessionals Name
  20. 20. LOGICAL DISTRIBUTION OF CLASSES  Emphasize the logical structure of the system (High level view)  Higher level of abstraction over classes.  Aids in administration and coordination of the development process.  Contributes to the scalability of the system.  Logical distribution of classes is inferred from the logical architecture of the system. Collaberos:WeCreateProfessionals
  21. 21. PACKAGES AND CLASS DIAGRAMS (CONT.)  Add package information to class diagrams Collaberos:WeCreateProfessionals A DE F G C B
  22. 22. PACKAGES AND CLASS DIAGRAMS (CONT.)  Add package information to class diagrams Collaberos:WeCreateProfessionals a.A b.b.Db.b.E b.a.F b.a.G a.C a.B b.a b.b ab
  23. 23. ANALYSIS CLASSES  A technique for finding analysis classes which uses three different perspectives of the system:  The boundary between the system and its actors  The information the system uses  The control logic of the system Collaberos:WeCreateProfessionals
  24. 24. BOUNDARY CLASSES Models the interaction between the system’s surroundings and its inner workings  User interface classes  Concentrate on what information is presented to the user  Don’t concentrate on user interface details  Example:  ReportDetailsForm  ConfirmationDialog  System / Device interface classes  Concentrate on what protocols must be defined. Don’t concentrate on how the protocols are implemented Collaberos:WeCreateProfessionals
  25. 25. ENTITY CLASSES  Models the key concepts of the system  Usually models information that is persistent  Contains the logic that solves the system problem  Can be used in multiple behaviors  Example: Violation, Report, Offender. Collaberos:WeCreateProfessionals
  26. 26. CONTROL CLASSES Controls and coordinates the behavior of the system  Delegates the work to other 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  Example:  EditReportController  AddViolationController Collaberos:WeCreateProfessionals
  27. 27. TVRS EXAMPLE Collaberos:WeCreateProfessionals Violation EditReportController <<control>> TrafficReport Offender TrafficPoliceman Clerk ReportDetailsForm <<boundary>> ConfirmationDialog <<boundary>> PolicemanDBProxy <<boundary>> Of fendersDBProxy <<boundary>> OffendersDB PolicemenDB 1 1 1 1 1
  28. 28. THANK YOU

×