CIS224 Software Projects: Software Engineering and Research Methods

1
CIS224Software Projects Software Engineering
and Research Methods

• Lecture 4
• Class Models
• (Based on Fowler (2004, Chapters 3 5) and
  Stevens and Pooley (2006, Chapters 5 6))

David Meredith d.meredith_at_gold.ac.uk www.titanmus
ic.com/teaching/cis224-2007-8.html
2
Class diagrams

• UML class diagrams document the static structure
  of a system
• What classes there are
• How the classes are related
• Each class represented in UML diagram as a
  rectangle containing the name of the class

3
What makes a class model good?

• Ultimate aim
• Build, as quickly and cheaply as possible, a
  system which satisfies the users requirements
• Objects must provide every piece of required
  behaviour
• Build a system which will be easy to maintain and
  adapt to future requirements
• Use encapsulated modules with low coupling and
  high cohesion
• Use classes which represent enduring types of
  domain concepts

4
How to build a good class model

• Can use any method you like!
• Unlikely to get it right first time
• Classes that correspond to classes of domain
  object (e.g., book, copy of book, library member)
  are easiest to identify
• What drives the design?
• Data-driven design (DDD)
• Identify all the data and divide it up into
  classes before considering classes
  responsibilities
• Noun identification technique
• Responsibility-driven design (RDD)
• Identify all the responsibilities of the system
  and divide between classes before considering the
  data
• Class-responsibility-collaboration (CRC) cards
• In practice, DDD and RDD can be used together

5
Identifying classes in DDDNoun identification

• Identify candidate classes by selecting all nouns
  and noun phrases in the requirements
  specification
• Use singular form of each noun or phrase
• Do not include or or and in a single class
  name
• Discard inappropriate candidate classes to get
  initial class list

6
Noun identification techniqueDiscarding
candidate classes

• Consider discarding candidate classes if they are
• Redundant
• Different nouns or phrases correspond to the same
  class (e.g., library member, member of the
  library)
• Vague
• Not clear what the noun or phrase means
• Events or operations
• Is the event or operation a thing with state,
  behaviour and identity? If not, discard it!
• e.g., short term loan
• Part of the meta-language
• Nouns and phrases that refer to aspects of the
  project, not domain objects
• e.g., requirements, system
• Outside the scope of the system
• Nouns and phrases that refer to objects that are
  not inside the system
• e.g., library
• Actors often discarded for this reason if no need
  to represent them by objects within the system
• Attributes
• Nouns and phrases that refer to simple things
  with no interesting behaviour of their own
• e.g., name of library member, duration of loan
• May also be other reasons to discard a candidate
  class

7
What sorts of things are represented by classes?

• Most commonly
• Tangible or real-world objects and concepts
• e.g., book, copy, course, hovercraft
• Roles
• e.g., library member, customer, manager
• Less commonly
• Events
• e.g., loan, arrival, departure
• Interactions
• e.g., match, meeting
• Events and interactions can help with identifying
  associations between classes representing domain
  concepts and roles
• Main class that just provides program entry point
  usually not included in class model
• e.g., class containing main method in Java

8
Associations

• Classes correspond to nounsAssociations
  correspond to verbs
• An association between two classes often
  represents a real-world relationship between the
  classes of real-world things or concepts
  represented by the classes
• Just as an object is an instance of a class, a
  link is an instance of an association
• A link connects a pair of objects (not classes)
• e.g., link between objects representing David
  Meredith and copy 4 of Fowler (2004) might
  represent the fact that David Meredith borrows or
  returns copy 4 of Fowler (2004)

9
Associations

• Class A and class B are associated if an object
  of class A has to know about an object of class
  B, i.e.,
• An object of class A sends a message to an object
  of class B
• An object of class A creates an object ofclass B
• An object of class A has an attribute whose
  values are objects of class B or collections of
  objects of class B
• An object of class A receives a message with an
  object of class B as an argument

10
Associations

• Class model should represent well the real-world
  relationships between domain concepts
• Class model should make sense to a domain expert
• Class model should also permit a sensible
  implementation that realizes the required use
  cases
• Satisfying both these criteria leads to a system
  that is easy to maintain because it is easy to
  understand

11
Association in a class diagram

• May be two or more different associations between
  same pair of classes
• e.g., LibraryMember has reserved Copy,
  LibraryMember has Copy on loan
• Represented by multiple labelled lines on class
  diagram

12
Attributes and Operations

• In order for the objects of a class to have state
  and behaviour, the class must have attributes and
  operations
• Attributes variables inside objects where data
  is stored
• Declared in second compartment of class icon
• Do not include attributes that implement
  associations (e.g., copies Copy1..)
• Types of attributes should not be classes in the
  diagram
• Operations the messages that the objects in a
  class understand and respond to
• Declared in third compartment of class icon
• Provide selector, arguments and return type
• Same operation may be implemented by different
  methods in different classes related by
  inheritance

13
Generalization

• MemberOfStaff is specialization of LibraryMember
• Can do everything that a LibraryMember can do and
  more (e.g., borrow a journal)
• MemberOfStaff should conform to interface of
  LibraryMember
• Liskov substitution principle
• May override methods in LibraryMember
• Should be no conceptual gulf between what a
  derived class and its base class do on receipt of
  the same message

14
Generalization

• Class B may be a specialization of class A if
• every member of class B is a member of class A
• e.g., Every member of the class MemberOfStaff is
  a member of the class LibraryMember
• All members of class B share one or more
  properties or behaviours that they do not share
  with the other members of class A
• e.g., all members of the class MemberOfStaff can
  borrow journals whereas the other membes of class
  LibraryMember cannot
• But inheritance increases coupling so only use
  when necessary
• Every member of the class Border Collie is a
  member of the class Dog
• But may not need subclass Border Collie if the
  only relevant property or behaviour that Border
  Collies do not share with other dogs is the name
  of their breed
• Could implement this as an attribute called Breed
  in an object of class Dog

15
Class models and class diagrams

• Each system has only one class model or static
  structural model which describes the static
  structure of the system, particularly the classes
  and the relationships between them
• Maybe two or more class diagrams used to
  graphically represent the single class model of a
  system (e.g., at different levels of detail)
• May represent the same class more than once on
  the same class diagram, but all icons
  representing a class must be consistent with the
  single class that they all represent
• Suggestion only represent a class once on any
  given diagram unless using a tool that enforces
  consistency

16
Aggregation

• An aggregation is a special association that
  shows that objects of one class are parts of
  objects of another class
• e.g., degree programme consists of 12 or more
  courses
• Each instance of the part class may be
  associated with more than one instance of the
  whole class
• e.g., the course CIS109 is part of several
  different computing degree programmes

17
Composition

• A composition is a special association that shows
  that each object of one class is part of at most
  one object of another class
• If an object of the whole class is copied or
  deleted, so are all the objects of the part
  class that are associated with it
• e.g., an object representing a chess board may
  contain a collection of objects of class Square
• Each Square object only associated with one
  ChessBoard object
• Square objects deleted or copied when ChessBoard
  object deleted or copied

18
Examples of aggregation and composition

• Are the associations between the following
  examples of aggregation or composition?
• Player and Team
• Aggregation
• Wheel and Car
• Composition
• Account and Customer
• Composition (What about joint accounts?)
• Song and Playlist
• Aggregation

19
Role names on associations

• Can label roles of classes within relationship
  represented by association in class model

20
Navigability of associations

• If class A must know about class B, then draw
  arrow with stick arrowhead from class A (source)
  to class B (target)
• Each object of class Course must know which
  students are taking that course in order to
  generate a list of students for that course
  (e.g., to print registers)
• Each Course object must be able to send messages
  to the Student objects that are linked to it
  (e.g., to retrieve the names of the students)
• Each Course object might have an
  attribute students Students0..would not
  explicitly give this attribute in the attribute
  compartment of the Course icon because implied by
  the directed association
• If class A knows about class B, then class A
  cannot be reused without class B
• Increases coupling
• Dont introduce navigability unless required!
• Does the association between Student and Course
  need to be bidirectional?
• What if we want to know the courses that each
  student is taking?

21
Bidirectional navigability and non-navigability

• Show bidirectional navigability by putting arrow
  heads at both ends of the association
• Leaving both arrowheads off means unspecified
  navigability
• Fact that class A does not know about class B
  indicated by placing a cross on the association
  near class B (new in UML 2.0)

22
Qualified associations

• Multiplicity of 1 at Square end of association
  indicates that, if we take a ChessBoard object,
  b, then there is exactly 1 Square object
  associated with any specific pair of values
  assigned to the row and column attributes of b
• Only one or zero lines in any given order
  associated with a particular product
• Order object has (at most) one OrderLine per
  product

23
Derived associations

• Fact that Lecturer class is associated with
  Student class is implied by association between
  Lecturer and Course and association between
  Course and Student
• Three options
• Can leave out association between Lecturer and
  Student
• Can put it in as an ordinary association
• Can indicate that it can be derived from other
  associations by preceding label with a forward
  slash, /
• Indicates that association exists by virtue of
  other associations no need to be implemented
  separately

24
Constraints

• A constraint is a condition that must be
  satisfied by a correct implementation of a design
• In UML, a constraint must be given between
  braces, e.g., xor, total number of items
  borrowed must be no more than 12
• Can use either formal language, such as Object
  Constraint Language (OCL), or natural language or
  a programming language to express a constraint

25
Association classes

• An association class allows an association to
  have attributes and operations
• Where do we store the result a student gets for a
  course? In the Student object or in the Course
  object?
• Can make an association class and store result
  there
• Alternatively can make a Result class and
  associate it with the Course object and the
  Student object
• If student takes course twice, can make two
  Result objects, but cannot make two association
  objects
• Can only be at most one association object for
  any given pair of linked objects

26
Interfaces and abstract classes

• Abstract operation is declared but not
  implemented
• Written in italics in class icon
• Class is abstract if at least one of its
  operations is abstract
• Class name written in italics
• Abstract class cannot be instantiated
• All operations of an interface are abstract
  (i.e., no implementation provided)
• Dependency arrow used to show that class requires
  interface
• Dashed generalization arrow shows that class
  provides interface
• Weak form of inheritance
• Class may provide more than one interface
• Good idea to depend on as general a class as
  possible to allow for different implementations
• Order depends on List interface
• get, equals and add operations dynamically bound
  to implementations in ArrayList

27
Dependency
Employee data gateway
Employee
Benefits window
Benefits data gateway

• Class A depends on class B if a change in class B
  may necessitate a change in class A
• A is client, B is supplier or server
• Dependency indicated by dashed arrow with stick
  head on class diagram
• Difference between dependency and assocation
• Dependency indicates relationship between class
  definitions
• Change in definition of class A may necessitate
  change in defiinition of class B
• Association indicates relationship between
  objects within classes
• Objects of class A need to know about objects of
  class B
• Can usually be more specific about the nature of
  a dependency than merely stating that it exists
  (e.g., generalization, implementation of
  interface)
• Dependency can exist between A and B if
• A sends a message to B
• A has an attribute of class B
• A has an operation parameter of class B
• Change in Employee might mean Benefits window has
  to be changed
• Change in Benefits window will not affect
  Employee
• Change in Employee data gateway may also
  necessitate change in Benefits window, but only
  if it necessitates change in public interface of
  Employee

28
Summary

• UML class diagrams document static structure of
  system
• Object-oriented approach should allow us to
  build, cheaply and quickly, systems that can be
  adapted to satisfy changes in requirements
• Can use various techniques for identifying the
  classes in a system
• (e.g., noun identification technique)
• Classes often represent tangible "real-world"
  objects and concepts
• less often, they represent events and
  interactions
• Associations represent the relationships between
  classes
• Classes are associated if one has to know about
  the other
• Two classes can be connected by two or more
  associations
• Multiplicities
• Attributes and operations
• Generalization
• Distinction between class models and class
  diagrams
• Aggregation and composition
• Role names
• Navigability
• Qualified associations
• Derived associations
• Constraints