Kein Folientitel

1
Last update 15 November 2006
IT Systems Implementation UML Class diagrams
II
Bettina Berendt
Humboldt-Universität zu Berlin, Institut für
Wirtschaftsinformatik http//www.wiwi.hu-berlin.de
/berendt/lehre/2003w/isi/ (Partially based on
Barker, Ch. 10)
2
Agenda
Object orientation
Structural relationships between classes
Behavioural possibilities of classes operations
Specifying attributes and operations in more
detail
Additional refinements of UML class diagrams
3
RecallThe modelling / programming paradigm
object orientation

• A simplified description When you develop OO
  software,
• You describe a world with potentialities
• The world is defined by what types of
  things/entities exist.
• These are generally described by classes
• A class has structure (its attributes).
• A class has behavioural possibilities (its
  operations/methods).
• You write a theatre play for prescribing a
  certain course of action
• A number of actors enter the stage at different
  times.
• Each actor is an instance of a type. ( Each
  object is an instance of a class.)
• To enter the stage, actors have to be created
  (usu. by calling the respective classs
  constructor method).
• The play unfolds by actors sending messages to
  one another. This happens by one actor addressing
  another actor and invoking one of ist methods.
• The play is specified in the main method (unique
  in each Java program).

4
How does this translate into a checklist for
modelling and programming languages? Features of
object orientation

• (Programmer creation of) abstract datatypes
  encapsulation
• Inheritance
• Object identity
• Polymorphism

5
Features of object orientation (1) the feature
abstract datatypes which is realized in UML
(and Java) by the classes

• (Programmer creation of) abstract datatypes
  encapsulation
• An abstract datatype is a user-defined data type
  that specifies structure as well as behaviour
• An abstract datatype encapsulates structure and
  behaviour of an object behind the walls of the
  objects interface ? other objects can only
  access and modify an object through its
  interface. This interface are the publicly
  visible operations/methods.
• An objects structure is described by its
  attributes
• Inheritance
• Object identity
• Polymorphism

6
Agenda
Object orientation
Structural relationships between classes
Behavioural possibilities of classes operations
Specifying attributes and operations in more
detail
Additional refinements of UML class diagrams
7

• pp. 4875 of last weeks slide set

8
Agenda
Object orientation
Structural relationships between classes
Behavioural possibilities of classes operations
Specifying attributes and operations in more
detail
Additional refinements of UML class diagrams
9
Features of object orientation revisited

• (Programmer creation of) abstract datatypes
  encapsulation
• An abstract datatype is a user-defined data type
  that specifies structure as well as behaviour
• An abstract datatype encapsulates structure and
  behaviour of an object behind the walls of the
  objects interface ? other objects can only
  access and modify an object through its interface
• An objects structure is described by its
  attributes
• An objects behavioural range is described by its
  
• operations (UML) the services that can be
  requested of the object
• aka methods (Java and other OO programming
  languages)
• Inheritance
• Object identity
• Polymorphism

10
Class diagram (12) Description of classes
containing their operations
11
Class diagram (12) Description of classes
containing their operations UXF version

• ltClass NAMEStudent gt
• ltAttribute NAME name /gt
• ltAttribute NAME ssn /gt
• ltAttribute NAME birthdate /gt
• ltAttribute NAME gpa /gt
• ltOperation NAME dropCourse /gt
• ltOperation NAME chooseMajor /gt
• ...
• lt/Classgt

12
Agenda
Object orientation
Structural relationships between classes
Behavioural possibilities of classes operations
Specifying attributes and operations in more
detail
Additional refinements of UML class diagrams
13
Class diagrams Full description of classes
containing their attributes (2nd compartment) and
operations (3rd c.)
Attribute detailed notation Attribute
with data type and visibility
-
String
Operation detailed notation Operation with
signature and return type and visibility
registerForCourse (x Course) boolean
Short notation Attribute or operation name only,
() indicates that it is an operation
14
More options in class diagrams Operation
parameter lists
registerForCourse (in x Course) boolean
Detailed notation Operation with signature and
return type and visibility
Note The parameter list often also contains
the direction of the parameter in, out, inout
15
UXF version of the previous two slides full
specification of attributes and operations

• ltClass NAMEStudent gt
• ltAttribute NAME name TYPE String
• 
  VISIBILITY private /gt
• ...
• ltOperation NAME registerForCourse
• RETURN_TYPE
  boolean VISIBILITY publicgt
• ltParameter NAME x TYPE Course
  DIRECTION ingt
• lt/Operationgt
• ...
• lt/Classgt

16
More options in class diagrams Attributes

• Default values for attributes
• Ex. a default value for a Students grade point
  average gpa (of type int)
• -gpa int 0
• In UXF
• ltAttribute NAME gpa TYPE int
• VISIBILITY
  private INITVAL 0 /gt

17
Naming conventions

• Class names start with a capital letter, continue
  with small letters
• Attribute and operation names
• start with small letters
• Do not contain underscores, but capital letters
  where a new word begins
• Getters and setters special names for
  getting and setting the value of a private
  attribute, e.g. for name (of a Student, etc.)
• getName() String
• setName(n String) void

18
The UML class diagram of a Student Registration
System (with attributes and operations)
(adapted from Barker, p. 377)
19
Agenda
Object orientation
Structural relationships between classes
Behavioural possibilities of classes operations
Specifying attributes and operations in more
detail
Additional refinements of UML class diagrams
20
Abstract classes

• No-one is just a person. Everyone is either a
  student, or a professor, or ...
• An abstract class is one that cannot be
  instantiated.
• It only serves to define all attributes and
  behaviours that all subclasses (or their
  instances) have in common.

Class name in italics!
21
Abstract classes UXF version

• ltClass NAMEPerson IsAbstracttruegt
• ltAttribute NAME ssn TYPE String
  VISIBILITY private/gt
• ltAttribute NAME name TYPE String
  VISIBILITY private/gt
• lt/Classgt
• Professor and Student inherit from this class /
  are derived via a generalization relation as
  before.
• The default value of IsAbstract is false, in
  other words, classes are by default not abstract.

22
Generalization coverage motivation
Are professors and students disjoint sets of
people (? of objects)?
disjoint
overlapping
Or can a person be both a lecturer and a student
(e.g., a PhD student)?
23
GENERALIZATION COVERAGE
overlapping - a superclass object can be a member
of more than one subclass
disjoint - a superclass object is a member of at
most one subclass
(from http//course.cs.ust.hk/comp211/2002Spring/
Slides/02OOModeling.ppt)
24
GENERALIZATION COVERAGE (contd)
complete - all superclass objects are also
members of some subclass
incomplete - some superclass object is not a
member of any subclass
(from http//course.cs.ust.hk/comp211/2002Spring/
Slides/02OOModeling.ppt)
25
GENERALIZATION COVERAGE (contd)
overlapping, incomplete
overlapping, complete
(from http//course.cs.ust.hk/comp211/2002Spring/
Slides/02OOModeling.ppt)
26
GENERALIZATION COVERAGE (contd)
disjoint, complete
disjoint, incomplete
(from http//course.cs.ust.hk/comp211/2002Spring/
Slides/02OOModeling.ppt)
27
Specifying generalization coverage in UXF or
ArgoUML

• There appears to be no way in UXF to describe a
  generalizations coverage.
• There is also no way to describe coverage in the
  UML tool we use (ArgoUML).
• One problem is that generalization coverage
  describes all the links into a superclass (e.g.,
  a Student is a Person, and a Professor is a
  Person), thus it is a property of more than one
  relational element of a UML class diagram.
• ? When you are asked to specify coverage, please
  do it in free-text form.

28
Free-text specification of generalization coverage

• Examples, taken from the previous slides
• Player is an overlapping generalization of
  TennisPlayer and of SoccerPlayer.
• Person is a disjoint generalization of Male and
  Female.
• UniversityStudent is a complete generalization of
  UndergraduateStudent and PostgraduateStudent.
• Tree is an incomplete generalization of Oak, Elm,
  Birch.
• Player is an overlapping generalization of
  TennisPlayer and of SoccerPlayer.
• Player is an overlapping, incomplete
  generalization of TennisPlayer and of
  SoccerPlayer.
• UniversityCourse is an overlapping, complete
  generalization of UndergraduateCourse and
  PostgraduateCourse.
• ... Note This is not the case at Humboldt
  university!!
• UniversityStudent is a disjoint, complete
  generalization of UndergraduateStudent and
  PostgraduateStudent.
• Tree is a disjoint, incomplete generalization of
  Oak, Elm, Birch.

29
Multiple inheritance

• An Employee is a UniversityMember.
• A Student is a UniversityMember.
• A Professor is an Employee.
• A ResearchAssistant is a Student.
• A ResearchAssistant is an Employee.
• Not supported in Java!
• Why?

ResearchAssistant
30
Roles in a structural relation
taughtClass
31
Roles in a structural relation UXF version

• ltClass NAMEProfessor ...gt ...
• ltAssociation NAMEteaches PEERSectiongt
• ltAssocRole MULTIPLICITY1 ROLENAME
  instructor /gt
• ltPeerAssocRole MULTIPLICITY0..
• ROLENAME
  taughtClass/gt
• lt/Associationgt
• lt/Classgt

32
Navigability

• When the maintains association is modelled like
  this, we can find, given a Student, his/her
  Transcript, and, given a Transcript, his/her
  owner
• ltClass NAMEStudent ...gt ...
• ltAssociation NAMEmaintains
  PEERTranscriptgt
• ltAssocRole MULTIPLICITY1gt
• ltPeerAssocRole MULTIPLICITY1gt
• lt/Associationgt
• lt/Classgt
• When the association is modelled like this, we
  can only find the Transcript of a given Student
  (we cannot navigate back from a given Transcipt)
• ltPeerAssocRole MULTIPLICITY1
  NAVIGABILITYtrue/gt

33
Agenda