Modeling with classes

1
Modeling with classes

• Lecturer Dr. Mai Fadel

2
What is UML?

• The unified modeling language (UML) is a standard
  graphical language for modeling object-oriented
  software.
• UML consists of a variety of diagram types,
  including
• Class diagrams, interaction diagrams, state
  diagrams, activity diagrams, component and
  deployment diagrams
• UML is much more than a set of notations for
  drawing diagrams it has the following additional
  features
• The diagrams you create with it are intended to
  be interconnected to form a unified model.
• It has a detailed semantic, describing
  mathematically the meaning of many aspects of its
  notations.
• It has extension mechanisms, which allow software
  designers to represents concepts that are not
  part of the core of UML.
• It has an associated textual language called
  Object Constraint Language (OCL) that allows you
  to formally state various facts about the
  elements of the diagrams.
• It is not a methodology because it does not
  describe, in a step-by-step way, how to do things.

3
Why use a standard modeling language?

• As systems become larger and larger, such
  developers have increasingly difficult time
  seeing the big picture and are liable to create
  poor design and take much longer in their work gt
  most systems are documented with the use of
  diagrams
• Diagrams provide views of structure and
  functionality that would be difficult to grasp by
  looking at code or textual descriptions
  diagrams provide abstraction
• A model captures an interrelated set of
  information about the system a diagram is simply
  one view of that information.
• Several diagrams can present the same information
  in slightly different ways, either with
  different notations or with different level of
  detail.

4
Why use a standard modeling language?

• A model can lead software engineers to discover
  problems and other properties of the system.
• Simple diagrams can help communicate with clients
  and users (easy to understand views)
• Advantages of using a well-defined standard
  modeling language
• It is a standard notation, everybody who looks at
  the model will be able to interpret it in the
  same way
• There is a wide variety of tools available to
  build UML models and enable simulation,
  animation, and/or generation of code for all
  parts of the system.

5
Essentials of UML Class Diagrams

• Class diagrams describe data found in a software
  system.
• Many classes in these diagrams correspond to
  things in the real world.
• The main symbols shown on class diagrams are
  classes, associations, attributes, operations,
  generalizations (refer to description pp.172-173)

6
Classes

• A class is represented as a box with the name of
  the class inside.
• Name should be singular and start with capital
• When you draw a class in a class diagram, you are
  saying that the system will contain a class by
  that name, and that when the system runs,
  instances of that class will be created.
• The class may be drawn at several different
  levels of detail
• An operation signature is specified using the
  following notation
• operationName(ParameterName parameterType,)retu
  rnType

Rectangle
Rectangle getArea() resize()
Rectangle height width
Rectangle height width getArea() resize()
Rectangle -height int -width getArea()
int resize(int,int)
7
5.3 Associations and multiplicity

• Refer to pp.173-175
• Labeling associations pp.175,176

8
Analyzing and validating associations

• To avoid making errors, you should get into the
  habit of reading every association in both
  directions to verify that it makes sense.
• Ask yourself whether a less restrictive
  multiplicity could also makes sense in some
  circumstances. i.e. using many or optional
  instead of one or some other specific number.
• Using less restrictive multiplicities makes the
  system more flexible
• On the other hand, using many, as opposed to
  one, when it is not justified, will increase a
  systems complexity and reduce its efficiency

9
Analyzing and validating associations

• Common patterns of multiplicity
• One-to-many
• Many-to-many
• One-to-one
• The most common multiplicity pattern is
  one-to-many. The next one is many-to-many.
• Many-to-many can be split into two one-to-many
  associations.
• One-to-one associations are less common.
• Ask yourself if one or both ends should be
  changed to optional or many
• A common error is to use 1-1 association between
  two classes, where the two classes should really
  be one.
• If a true 1-1 association, consider whether it
  should be an aggregation.
• Implications of this association
• Whenever you create an instance of one of the
  classes, you must simultaneously create an
  instance of the other
• When you delete one you must delete the other

10
Analyzing and validating associations

• A multiplicity pattern involving three classes.

11
Association Classes

• In some circumstances, an attribute that concerns
  two associated classes cannot be placed in either
  of the classes.
• e.g. a student registering in courses a student
  can register in any number of course sections,
  and course section can have any number of
  students.
• In which class should the student grade be put?
• Solution create an association class to hold the
  grade
• Aside from being attached to an association, an
  association class is no different from any other
  class. It can have subclasses.
• Any time you see a many-to-many association, you
  should consider whether an association class is
  needed.
• Any pair of classes, linked by a many-to-many
  association with an association class, can be
  transformed into a three classes.

12
Association class
IsRegisteredIn
Student
CourseSection


Student
CourseSection


Registeration grade
Equivalent diagram
Registeration grade


1
1
CourseSection
Student
13
Reflexive association (RA)

• It is possible for an association to link a class
  to itself.
• e.g. Course class
• Asymmetric RA
• e.g. successor-prerequisite RA
• the roles at each end are completely different
• Label them using association roles instead of
  association names
• Symmetric RA
• e.g. Mutually exclusive courses if the two
  courses cover the same material then taking one
  may preclude a student from taking the other.
• ?

14
Directionality in association

• Associations by default are bidirectional
• e.g. if a Driver object is linked to a Car
  object, the Car is also implicitly linked to that
  Driver. If you know the car, you can find out its
  driver or if you know the driver, you can find
  out the car.
• It is possible to limit the navigability of an
  association by adding an arrow at one end.
• Decisions about directionality should normally be
  deferred to later phases of development, when the
  detailed design is created.
• Making associations unidirectional can improve
  efficiency and reduce complexity, but might also
  limit the flexibility of the system.

15
Generalization-Avoiding unnecessary
generalizations

• A common mistake made by beginners is to overdo
  generalization.
• To justify the existence of each class, there
  must be some operation that will be done
  differently in that class

16
Avoiding unnecessary generalizations - Example
A Poor Design
17
Avoiding unnecessary generalizations - Example
A Better Design
18
Generalization Handling multiple generalization
sets

• A generalization set is a labeled group of
  generalizations with a common superclass the
  label describes the criteria used to specialize
  the superclass into two or more subclasses.
• The label of a generalization set will typically
  be an attribute that has a different value in
  each subclass.
• There must also be other differences in the
  features of the subclasses in order to justify
  their existence attributes, operations, or
  associations.
• Implementation challenge if an animal was an
  AquaticAnimal, it could not be a Carnivore. How
  to represent a carnivores such as Sharks?
• Create a higher-level generalization set
  (habitat), and the to have generalization sets
  with duplicate labels at a lower level in the
  heirarchy.
• Use multiple inheritance
• Use the player-role pattern.

19
Handling multiple generalization sets - Example
20
Handling multiple generalization sets - Example
21
Generalization Avoiding having objects change
class

• When creating generalizations avoid the need to
  change class.
• An object should never need to change class.
• In programming languages changing classes is
  simply not possible you have to completely
  destroy the original object and create a new
  instance of the second class.
• This is complex and error prone because you have
  to copy all the instance variables and make sure
  that all links that connected to the old object
  now connect to the new one.
• e.g. changing the status of a student from
  full-time to part-time and vice versa.
• Poor model destroying an object and creating a
  new one
• Solution 1 make attendanceStatus an attribute of
  Student and to omit the two subclasses completely
• Problem we loose the advantage of polymorphism
  for any operations that differ between the
  subclasses.
• Solution 2 use the Player-role pattern.

22
Avoiding having objects change class - Example
23
Object Diagram

• Class diagrams tell us what classes will exist in
  a given system, but they are quite abstract.
  Sometimes it can be hard to visualize the
  relationship among the objects that will exist at
  run-time.
• An object diagram shows an example configuration
  of objects and links that may exist at a
  particular point during execution of a program.
• Symbols and notations
• Objects rectangles- underlined names preceded by
  a colon. Class name may be used
• A link between two objects a simple line
• Links you can imagine that each of the two
  objects contains a pointer to the other object.
• A given object diagram is generated by a class
  diagram. i.e. It contains instances and links of
  the classes and links present in the class
  diagram.
• A class diagram can generate an infinite number
  of object diagrams.

24
Object diagrams continued

• While we put multiplicity symbols on
  associations, we never put them
• An object diagram can never contain a
  generalization, and can only contain links
  generated by associations, not the associations
  themselves

25
(No Transcript)
26
More advanced features of class diagrams

• Aggregation, and interfaces
• It is important to understand the meaning of
  these features when used in class diagrams, but
  most modeling, especially at the analysis level ,
  can be done without them.

27
Aggregation

• Aggregations are special associations that
  represent part-whole relationships.
• whole sides is often called assembly or
  aggregate
• Many aggregations are one-to-many, but this is
  not a requirement.
• Use aggregations instead of associations when
• You can state that parts are part of the
  aggregate, or the aggregate is composed of the
  parts
• When something owns or controls the aggregate,
  then they also own or control the parts
• Not an aggregate the members of a club in the
  relationship with the club. A member is said to
  be part of the club, but the owner of the club
  does not own the members.

28
Aggregation

• A composition is a strong kind of aggregation in
  which if the aggregate is destroyed, then the
  parts are destroyed as well.
• The parts of a composition can never have a life
  of their own the rooms of a building cannot
  exist without the building
• In ordinary aggregations, the parts can have a
  life of their own

29
Drawing aggregations as a hierarchy

• Leaving an aggregation as an ordinary
  association is not an error, whereas
• marking a non-aggregation with a diamond is an
  error and can cause confusion.
• Making aggregations explicit provides the
  designer with useful information.

30
Implementing class diagrams in Java

• Before we were explaining strictly about
  modeling.
• Now explain in brief about the detailed design
  stage in order to introduce how to implement
  your models.
• Good modelers have to develop an understanding of
  how their model will be concretized as a real
  system.
• The implementation of some aspects of class
  diagrams are straightforward
• Attributes are generally implemented as instance
  variables. You have to choose an appropriate
  class (e.g. String)
• Generalizations are implemented using the extends
  keyword, and interfaces are implemented using the
  implements keyword.

31
Implementing class diagrams in Java continued

• There are several ways to implement associations.
• We will suggest typical ways to implement
  associations as objects in a running Java
  program.
• More sophisticated techniques are needed when
  objects have to be loaded from a database.
• Associations are normally implemented using
  instance variables.
• You divide each two-way association into two
  one-way associations so that each associated
  class has an instance variable representing the
  other end of the association.
• To implement a one-way association where the
  multiplicity at the other end is one or
  optional you declare a variable whose type is
  that class.
• e.g. SpecificFlight should have the following
  declarations
• private TerminalOfAirport destination
• private Airplane airplane
• private FlightLog flightLog

32
Implementing class diagrams in Java
implementing associations

• To implement a one-way association where the
  multiplicity at the other end is many, you use
  a collection class such as ArrayList.
• e.g. SpecificFlight would have the declarations
• private List crewMember // of Employee role
• private List bookings
• to implement an association where the
  multiplicity at the other end has a small, fixed
  upper bound, you can use a regular array. e.g.
  Person would declare
• private PersonRole roles new PersonRole2
• See the code needed to implement a responsibility
  in RegularFlight to create new SpecificFlight.
  (p. 217)