Classes and their relationships

1
Classes and their relationships

2
How to find classes?

• Bertrand Meyers suggestions
• nouns in requirements document or use case
  descriptions do not provide adequate solutions
• each class should contain a distinct set of
  operations relevant to the system under
  consideration
• think of a class as an ADT
• ignore a candidate class
• if it does not suggest any operation relevant to
  the current application
• if all operations of this class are already
  covered by other classes in the system
• if this class overlaps with several abstractions
• If this classs name indicates an action

3
Selecting the right classes

• remove irrelevant classes
• those that are not mandatory or not important for
  the current application
• Information about employment details of a
  customer is NOT RELEVANT while modeling a bank
  transaction system
• may be useful, but NOT NECESSARY
• requires thorough knowledge of the application
  domain and possibly the help of domain experts

4
Selecting the right classes (continued)

• remove vague classes
• classes that do not adequately describe
  themselves
• a class that represents the internet
• trade off between vague classes and abstract
  classes
• vague classes are too abstract
• most likely, vague classes do not have any
  concrete methods
• define several component classes that together
  define the vague class
• the internet class one or more concrete classes
  such as web server, OS interface, user
  options model and so on

5
Selecting the right classes (continued)

• do not include implementation-oriented classes in
  the analysis model
• may be introduced later during design and/or
  implementation
• examples array, tree, list

6
Identifying associations

• an association corresponds to a semantic
  dependency between classes
• class A uses a service from class B
  (client-server)
• a TV object requires a signal from a Cable object
• class A has a structural component whose type is
  class B (aggregation)
• remember aggregation is a special case of
  association
• a TV object includes a Screen object
• class A sends/receives data to/from class B
  (communication)
• a TV object sends and receives signal to and from
  a VCR object

7
Identifying associations (continued)

• include only those associations that are relevant
  to the current model
• constrained by assumptions, simplifications,
  system boundary (what is expected to be provided
  by the system)
• Faculty member teaches Course in a course
  registration system
• Faculty member creates Course in a curriculum
  development system
• Faculty member evaluates Course in a course
  evaluation/inspection system

8
Identifying associations (contd)

• eliminate redundant associations
• some associations can be derived from others
• Faculty member teaches Course
• Course is taught between Time to Time
• therefore, Faculty member teaches between
  Time to Time
• use transitivity between associations
• Give a similar scenario between a TV object, a
  VCR object and a Cable object
• remember that subclasses inherit the associations
  of a superclass

9
Identifying aggregations

• aggregations are also associations
• identify as association if it is not clear
  whether it is association or aggregation
• Mail has Address (aggregation)
• Mail uses Address for delivery (association)
• Customer has Address (aggregation)
• Customer resides at Address (association)
• TV includes Screen (aggregation)
• TV sends information to Screen (association)

10
Identifying structural components

• must be done for each class independently
• some identified by aggregation
• remember the definition of aggregation
• deciding the types of attributes is not a primary
  concern during analysis
• implementation dependent

11
Identifying structural components (continued)

• include only those attributes that are relevant
  to the current application
• size for a TV object is not necessary if the
  application is concerned only with connections
  between TV and other objects
• do not attempt to include every attribute at the
  beginning
• more attributes can be added when the model is
  iterated
• iteration of the model occurs almost at all
  times, particularly for large projects

12
Identifying structural components (continued)

• avoid derivable attributes instead, create a
  function to derive each such attribute
• age can be derived from birthday and
  current-date
• total of all transactions can be dynamically
  computed when necessary, rather than storing it
  somewhere

13
Identifying specialization

• some of them are obvious in the application
  domain
• derivable from requirements document
• specialization (top-down approach)
• Student, Full-time Student, Part-time
  Student
• TV, Plasma TV, Flat Panel TV
• Customer, Bank manager

14
Identifying specialization (continued)

• some of them are discovered during analysis
• motivated by identifying similarities and common
  features among classes
• generalization (bottom-up approach)
• Part-time Instructor derived from Instructor
  and Student while modeling a department
• User derived from Customer, Bank Manager
  and Teller while modeling an ATM system
• Material derived from Book, Journal and
  Magazine while modeling a library catalog system

15
Identifying specialization (continued)

• remember the constraints on superclasses and
  subclasses
• superclass and subclass must be necessarily
  different
• otherwise they are duplicates and hence are
  redundant
• superclass and subclass must not be completely
  different
• must have at least something in common
• may become completely different when specialized
  several times (huge hierarchy)

16
Identifying specialization (continued)

• avoid large hierarchy of specialization
• difficult to see the relationships between the
  leaf class and the root class
• remember the concepts specialization and
  aggregation and choose the appropriate
  relationship
• influence of the application domain

17
Identifying specialization (continued)

• move structural and behavioral components to the
  appropriate superclasses (or to subclasses)
• do not keep features just for code reuse
• may require to iterate a few times
• superclasss (or subclasss) relationship with
  other classes may influence this move
• try to avoid multiple specialization
• potential conflicts during implementation

18
Deriving components of a class diagram from a
usecase diagram

• Actors are potential candidates for classes
• Sometimes, an actor may not be modeled as a class
• Generalization or specialization between actors
  will end up in generalization or specialization
  relationship between the corresponding classes

19
Deriving components of a class diagram from a
usecase diagram

• Two actors will be related if they are connected
  through a series of use cases
• The classes corresponding to these actors will
  thus have an association
• See the ATM example the actor User is related
  to Account because of the use cases deposit
  and update account
• The relationship among use cases will be
  exploited later in dynamic modeling

20
Iteration in developing a class diagram

• quite common in large projects
• iterate major components
• classes, associations, structural components,
  inheritance hierarchy
• separate basic and derivable information