1.
Identifying classes, Packages and drawing class Diagrams , Object Diagrams and composite structure diagrams
Week 06

2.
Class
A Class is a description of a group of objects with common properties (attributes), common behavior (operations), common relationships to other objects, and common semantics.

3.
Class diagram
UML class diagrams show the classes of the system, their inter-relationships, and the operations and attributes of the classes
Explore domain concepts in the form of a domain model
Analyze requirements in the form of a conceptual/analysis model
Depict the detailed design of object-oriented or object-based software

4.
Class diagram

5.
Class diagram

6. Classes and Objects Objects are instances of a Class
Classes and Objects
Objects are instances of a Class
A Class is a definition / template / (cookie cutter) for all objects belonging to that Class
However:
A CLASS IS NOT A COLLECTION OF OBJECTS

8. How to Identify Classes?
Noun Analysis (Booch) of the TEXT within the Use Cases reveals first cut of a list of classes
Other Documents, Problem Statements etc. can be inspected for Nouns
These Nouns Represent Entities in Problem space, which are potential Classes
During Analysis, these Classes are of Stereotype <<entity>> as they are all derived from Problem Space
Attributes and Responsibilities are Added to these Classes; but only at analysis level.

9.
Class Diagrams
A class diagram describes the types of objects in the system and the various kinds of static relationships that exist among them.
It also shows the attributes and services of a class and the constraints that apply to the way objects are connected.

10. -Name : CHAR -DateOfBirth: DATE +getName () A Class Notation Patient
Stereotype:
Type of the Class;
entity for Analysis.
<<entity>>
Name of the Class
Patient
-Name : CHAR
Attributes of the
Class
-DateOfBirth: DATE
Operations of the
Class
+getName ()

11. Major components of a Class Diagram
Major components of a Class Diagram
<<entity>>
<<entity>>
Patient
Class:
With 3
Compartments
Inheritance
Association
Doctor
Class
Description
Contains
Attributes
&
Operations
Multiplicity
At each end
Of Association
Notes - -
DoctorID : :
Qual [ [ .. .. N N ] ] + +
getDoctorDtls ( ( ) ) 1 .. N N

12. Visibility – UML notations
Visibility – UML notations
• + Public • ‐ Private • # Protected • ~ Package ‐ Any element that is in the same package as the class, or in the nested subpackage , can access any of its features with package visibility.

13. Stereotypes and Classes
Stereotypes and Classes
A Stereotype is a mechanism you can use to categorize your classes. •Say you want to quickly find all of the forms in the model, •You could create a stereotype called form, and assign all of your windows this stereotype. •To find your forms later, you would just need to look for the classes with that stereotype.

14. • There are three primary class stereotypes in UML.
• There are three primary class stereotypes in UML.

15. Finding Boundary Classes
Finding  Boundary   Classes
These are classes that mediate between the subject (System boundary) and its environment. – User Interface class – classes that interface between the system and humans; – System Interface class – classes that interface with other systems; – Device Interface class – classes that interface with external devices such as sensors;

16.
Boundary Class:
They provide the interface to a user or another system. (ie. Interface to an actor).
Handles communication between system
surroundings and the inside of the system.

17.
Entity Class
• They are needed to perform task internal to the system. Reflect a real world entity. Identifying Entity Classes • Identify the nouns and noun phrases used to describe the responsibilities.

18.
Control Class:
• Sequencing behavior specific to one or more use cases. • There is typically one control class per use case. • Co‐ordinates the events needed to realise the behaviour specified in the use case. Eg. Running or executing the use case.

19. There are four types of relationships you can set up between classes.
There are four types of relationships you can set up between classes.
Association
Aggregation/Composition
Generalization
Dependency.

21. Association relationship on class diagram
Doctor
Department
ASSOCIATION
“USES”
Doctor uses Department; Department also uses Doctor; The Relationship is loose.

22. Relationships on a class diagrams
ASSOCIATION
“USES”
Hospital
Department
Doctor
1..*
1..4 1 1
1..*
INHERITANCE
“IS_A; IS_A_KIND_OF”
Operating Theatre
Dentistry
Surgical
Consultation
0..1
1..2

25. Association or Aggregation?
Association or Aggregation?
• Whether a relationship is an association or
an aggregation is often domain dependent.
• What type of relationship should be used to
model a car with its tires?
If the application is a service center ‐ its aggregation
If the application is a tire store, you will care
about the tire independent of a car ‐ its association

26.
An Association may be named. • Usually the name is an active verb or verb phrase that communicates the meaning of the relationship. eg. a Lecturer teaches a Course • Association name is optional. • Names are added to improve the clarity . • Aggregation relationships typically are not named. They are read using the words “has”, “part of” or “contains”.

27.
The end of an association where it connects to a class is called an association role. • Role name can be used instead of association names. • It is a noun that describes the reason the relationship exists. • The role name is placed on the association near the class it modifies. Course Offering +Teacher Lecturer

28. Composition aggregation
Composition aggregation
another form of the aggregation relationship.
but the child class's instance lifecycle is dependent on the parent class's instance lifecycle.
the composition relationship is drawn like the aggregation relationship, but this time the diamond shape is filled.

29. Example of a composition relationship
Example of a composition relationship

30.
lifetime of the part (Engine) is managed by the whole (Car), in other words, when Car is destroyed, Engine is destroyed

31. The Inheritance Relationship
The Inheritance Relationship
Consultation
Dentistry
Surgical
Department
INHERITANCE
“IS_A; IS_A_KIND_OF”

32. Generalization versus Specialisation
Generalization versus Specialisation
Generalization
Finding Superclasses
Needs abstract thinking
Domain knowledge helpful
Helps in creating reusable Classes
Finding Subclasses
Concrete lower level implementation thinking
Helps in using reusable Classes
Specialization

37. Multiplicities Provide Business Rules; Invaluable in DB Design.
Provide Business Rules;
Invaluable in DB Design.
Multiplicities

38. Multiplicity Indicators
Multiplicity Indicators
1 Exactly one 0..* Zero or more 1..* One or more 0..1 Zero or one 5..8 Specific Range (5,6,7 or 8)

39. Multiplicities on class Diagrams
Multiplicities:
An Object of one Class Relates to How Many Objects of the Other Class
Multiplicities on class Diagrams
Hospital
Department
Doctor
1..*
1..4 1 1 1
Operating Theatre
Dentistry
Surgical
Consultation
0..1
1..2

40. Multiplicities on class diagrams
Multiplicities on class diagrams
Multiplicities encompass Business Rules
They are for Objects belonging to Classes
They are useful for Database Design
Multiplicity states:
For two Classes in an Association (Or Aggregation) relationship
“An Object of one Class deals with How many Objects of Another Class”
A Car object associates with Four Wheels
Then multiplicity will be 1 for Car and 4 for Wheel
Note: Multiplicities are meaningless for Inheritance relationship

41. Reflexive relationships
Reflexive relationships
• Some times a class is in an association with itself. • This can happen when a class has objects that can play a variety of roles. • This is shown on the class diagram as a reflexive association or aggregation. • Role names rather than association names are typically used for reflexive relationships.

42. Reflexive relationships cont..
Reflexive relationships cont..
One Course object playing the role of Prerequisite is related to zero or more course objects.
• One Course object is related to zero or more
course objects playing the role of Prerequisite.

47. Here is a brief descrition for a writing a text document:
Here is a brief descrition for a writing a text document:
Suppose that you're writing a document in some of famous text processing tools, like MicrosoftWord for example. You can start typeing a new document, or open an existing one. You type a text by using your keyboard.
Every document consists of several pages, and every page consists of header, document's body or/and footer. In header and footer you may add date, time, page number, file location e.t.c.
Document's body has sentences. Sentences are made up of words and punctual signs. Words consists of letters, numbers and/or special characters. Also in the text you may insert pictures and tables. Table consists of rows and columns. Every cell from table may hold up text or pictures.
After finishing the document, user can choose to save or to print the document.

48.
classes
document, text processing tool, MicrosoftWord, text, keyboard, header, footer, document's body, date, time, page number, location of file, page, sentence, word, punctual sign, letter, number, special character, picture, table, row, column, cell, user

52.
Component diagram
UML component diagrams shows the dependencies among software components, including the classifiers that specify them (for example implementation classes) and the artifacts that implement them; such as source code files, binary code files, executable files, scripts and tables.

53.
Component diagram

54.
Component diagram
Component diagrams illustrate the pieces of software, embedded controllers, etc., that will make up a system.
Modern software development proceeds via components (eg. Table, data file, executable, DLL, document etc) which is particularly important in team-based development efforts

55. Component diagram • Why do you model components?
Component diagram
• Why do you model components?
Visualize the components of a system.
Construct executables by using forward and reverse engineering.
Describe the organization and relationships of the components.
Clients can see the structure of the finished system
Developers have a structure to work toward
Technical writers who have to provide documentation and help files can understand what they are writing about
you are ready for reuse

56. Component Diagrams contain mainly
Component Diagrams contain mainly
Components
Interfaces
relationships.
Components are related via dependency relationships.
Run time components show the mapping of classes to run time libraries such as:
– Java applets
– Active-X components
– DLLs

58. Representing Components
Representing Components
Components are represented as a rectangular classifier with the keyword «component»; optionally the component may be displayed as a rectangle with a component icon in the right-hand upper corner.

59.
Assembly Connector
The assembly connector bridges a component’s required interface (Component1) with the provided interface of another component (Component2); this allows one component to provide the services that another component requires.

60.
Components with Ports
Using Ports with component diagrams allows for a service or behavior to be specified to its environment as well as a service or behavior that a component requires.
Ports may specify inputs and outputs as they can operate bi-directionally.

61.
The following diagram details a component with a port for online services along with two provided interfaces order entry and tracking as well as a required interface payment.

62.
A component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment.

63. Aggregation (Shared association)
Aggregation (Shared association)
Definition
A kind of association that has one of its end marked shared as kind of aggregation, meaning that it has a shared aggregation.

64. Association (Without aggregation)
Association (Without aggregation)
An association specifies a semantic relationship that can occur between typed instances. It has at least two ends represented by properties, each of which is connected to the type of the end. More than one end of the association may have the same type.

65. Composition (Composite association)
Composition (Composite association)
An association may represent a composite aggregation (i.e., a whole/part relationship).
Only binary associations can be aggregations. Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it.

66.
Generalization
A generalization is a taxonomic relationship between a more general classifier and a more specific classifier. Each instance of the specific classifier is also an indirect instance of the general classifier. Thus, the specific classifier inherits the features of the more general classifier.

67.
Interface
An interface describes a group of operations used or created by components.

68.
Usage
A usage is a relationship in which one element requires another element (or set of elements) for its full implementation or operation. In the metamodel, a Usage is a Dependency in which the client requires the presence of the supplier.

70.
Deployment Diagram
Shows the physical architecture of a computer-based system. It can show
– the computers and devices,
– their connections with one another
– the software that sits on each machine

71.
Deployment diagram
UML deployment diagram depicts a static view of the run-time configuration of hardware nodes and the software components that run on those nodes. Deployment diagrams show the hardware for your system, the software that is installed on that hardware, and the middleware used to connect the disparate machines to one another.

72. Used for distributed systems only. The main hardware item is a node, a
Used for distributed systems only.
The main hardware item is a node, a
generic name for any kind of computing
resource.
Node is specialized by:
device
execution environment
UML node icon

74.
Deployment diagram

75.
Deployment diagram

76.
artifact
artifact is a classifier that represents some physical entity, a piece of information that is used or is produced by a software development process, or by deployment and operation of a system. Artifact is a source of a deployment to a node.
Some real life examples of artifacts are:
text document
source file
script
binary executable file
archive file
table in a database

77. Associations between Artifacts
Artifacts can be involved in associations to other artifacts, e.g. composition associations. For instance, a deployment descriptor artifact for a component may be contained within the artifact that manifests that component.
Application book-club.ear artifact contains EJB user-service.jar artifact and deployment descriptor.

78. The book-club.war artifact depends on web-tools-lib.jar artifact.
Dependency between artifacts is notated in the same way as general dependency,
i.e. as a general dashed line with an open arrow head directed from client artifact to supplier artifact.
The book-club.war artifact depends on web-tools-lib.jar artifact.

80.
Object diagram
UML 2 Object diagrams (instance diagrams), are useful for exploring real world examples of objects and the relationships between them. It shows instances instead of classes. They are useful for explaining small pieces with complicated relationships, especially recursive relationships.

81.
Object diagram

82.
package
UML package helps to organize and arrange model elements and diagrams into logical groups, through which you can manage a chunk of project data together.
You can also use packages to present different views of the system's architecture.

83. Package diagram visualizes packages and depicts the
Package diagram visualizes packages and depicts the
Dependency
import
access
generalization
realization and merge relationships between them.

84.
The members of the package may be shown within the boundaries of the package. In this case the name of the package should be placed on the tab.
Package org.hibernate contains SessionFactory and Session

85.
Members of the package may be shown outside of the package by branching lines from the package to the members.
A plus sign (+) within a circle is drawn at the end attached to the namespace (package). This notation for packages is semantically equivalent to composition (which is shown using solid diamond.)

86. Package org.hibernate contains interfaces SessionFactory and Session
Package org.hibernate contains interfaces SessionFactory and Session

87.
visibility
Owned and imported elements may have a visibility that determines whether they are available outside the package.
If an element that is owned by a package has visibility, it could be only public or private visibility.
Protected or package visibility is not allowed.
The visibility of a package element may be indicated by preceding the name of the element by a visibility symbol ("+" for public and "-" for private).

88. visibility www.hndit.com
All elements of Library Domain package are public except for Account

89.
Package can be used as a template for other packages. Note, that [UML Specification] inconsistently calls it both package template and template package.

90.
Package merge
A package merge is a directed relationship between two packages that indicates that content of one package is extended by the contents of another package.
Package merge is similar to generalization in the sense that the source element conceptually adds the characteristics of the target element to its own characteristics resulting in an element that combines the characteristics of both.

91. A keyword is shown near the dashed arrow to identify which kind of package import is intended. The predefined keywords are «import» for a public package import, and «access» for a private package import. By default, the value of visibility is public
Private import of Presentation package and public import of Domain package

92.
ML Kernel package merges Constructs package which imports Primitive Types.

94.
Package diagram
UML 2 Package diagrams simplify complex class diagrams, it can group classes into packages. A package is a collection of logically related UML elements. Packages are depicted as file folders and can be used on any of the UML diagrams.

95.
Package diagram

96. Composite structure diagram
Composite structure diagram
UML 2 Composite structure diagrams used to explore run-time instances of interconnected instances collaborating over communications links. It shows the internal structure (including parts and connectors) of a structured classifier or collaboration.

97. Composite structure diagram
Composite structure diagram
Dashed oval : collaboration , rectangular : instances of any type of classifier, including classes, objects, or interfaces

98. end