Modelling with Classes

1
Object-Oriented Software Development

• Modelling with Classes Part I

2
What is UML?

• The Unified Modelling Language is a standard
  graphical language for modelling object oriented
  software
• At the end of the 1980s and the beginning of
  1990s, the first object-oriented development
  processes appeared
• The proliferation of methods and notations tended
  to cause considerable confusion
• Two important methodologists Rumbaugh and Booch
  decided to merge their approaches in 1994.
• They worked together at the Rational Software
  Corporation

3
What is UML?

• In 1995, another methodologist, Jacobson, joined
  the team
• His work focused on use cases
• In 1997 the Object Management Group (OMG) started
  the process of UML standardization

4
Goals of UML

• Provide users a ready-to-use, expressive visual
  modeling language so they can develop and
  exchange meaningful models.
• Provide extensibility and specialization
  mechanisms to extend the core concepts. In
  particular, users need to be able to
• Build models using core concepts without using
  extension mechanisms for most normal
  applications
• Add new concepts and notations for issues not
  covered by the core
• Choose among variant interpretations of existing
  concepts, where there is no clear consensus and
• Specialize the concepts, notations, and
  constraints for particular application domains.

5
Goals of UML

1. Be independent of particular programming
   languages and development processes.
2. Provide a formal basis for understanding the
   modeling language.
3. Encourage the growth of the OO tools market.
4. Support higher-level development concepts such as
   collaborations, frameworks, patterns, and
   components.
5. Integrate best practices.

6
UML diagrams

• Class diagrams
• describe classes and their relationships
• Interaction diagrams
• show the behaviour of systems in terms of how
  objects interact with each other
• State diagrams and activity diagrams
• show how systems behave internally
• Component and deployment diagrams
• show how the various components of systems are
  arranged logically and physically

7
UML features

• It has detailed semantics
• It has extension mechanisms
• It has an associated textual language
• Object Constraint Language (OCL)
• The objective of UML is to assist in software
  development
• It is not a methodology

8
What constitutes a good model?

• A model should
• use a standard notation
• be understandable by clients and users
• lead software engineers to have insights about
  the system
• provide abstraction
• Models are used
• to help create designs
• to permit analysis and review of those designs.
• as the core documentation describing the system.

9
Essentials of UML Class Diagrams

• The main symbols shown on class diagrams are
• Classes
• represent the types of data themselves
• Associations
• represent linkages between instances of classes
• Attributes
• are simple data found in classes and their
  instances
• Operations
• represent the functions performed by the classes
  and their instances
• Generalizations
• group classes into inheritance hierarchies

10
Classes

• A class is simply represented as a box with the
  name of the class inside
• The diagram may also show the attributes and
  operations
• The complete signature of an operation is
• operationName(parameterName parameterType )
  returnType

11
Symbol for a Class

• SomeClass
• SomeClass

12
Symbol for an object

• someObjectSomeClass
• someObjectSomeClass

13
Attributes

• An attribute represents information about an
  object.
• The term attribute is not quite synonymous with
  variable. An attribute represents an abstractly
  defined property, independent of how that
  property is internally implemented. A variable,
  on the other hand, is an internal implementation
  mechanism.
• Nevertheless, eight times out of ten, an
  attribute turns out to be implemented as a simple
  variable, identical in nature to the attribute
  itself. For example, the length attribute may be
  implemented with the length variable.

14
Attributes

• In general, an attribute is both gettable and
  settable from outside an object.
• Some attribute are read-only that is, only
  gettable from outside the object. Typically,
  these attributes are derived from others.

15
Operations

• In the class diagram, operations appear in the
  lowest compartment with their full formal
  signatures. Each formal signature comprises the
  operation name, together with a list of the
  operations input and output arguments.
• The UML standard calls for the keywords in and
  out before each argument to show its direction
  into or out from the operation (and inout
  signifies an argument that is both in and out).
  For convenience, we designate input arguments as
  the default, so we dont mention the keyword in.

16
Putting it all together

• Person
• nameString
• dateOfBirthDate
• heightLength
• / ageDuration

17
Class Symbol with attributes

• Cuboid
• lengthLength
• breadthLength
• heightLength
• / capacity Volume

18
Class Symbol with Operations

• Person
• nameString
• dateOfBirth Date
• height Length
• / ageDuration
• getName()String
• setName(name String)
• getAge()Duration
• getHeight(date Date) Length)
• setHeight(date Date, height Length)

19
Class Symbol with Operations

• Cuboid
• length Length
• breadth Length
• height Length
• / capacity Volume
• getLength() Length
• setLength(length Length)
• getCapacity() Volume
• scale(factor PositiveReal)

20
Class Symbol with basic get and set operations
omitted

• Person
• nameString
• dateOfBirth Date
• height Length
• / ageDuration
• height(date Date) Length
• setHeight(date Date, height Length)

21
Class Symbol with basic get and set operations
omitted

• Cuboid
• length Length
• breadth Length
• height Length
• / capacity Volume
• scale(factor PositiveReal)

22
Overloaded Operations

• Operations that are overloaded will appear many
  times on the class diagram, each time with a
  different signature.
• SellableProductLine
• price Money
• / totalUnitsSold Integer
• recordSale(saleDate Date, numOfUnits Integer)
• markDown(discountPercent Percentage)
• markDown()
• totalUnitsSold(date Date)
• totalUnitsSold()

23
Visibility of Attributes and Operations

• SomeClass
• publicAttr Class1
• protectedAttr Class2
• - privateAttr Class3
• publicOperation()
• protectedOperation()
• - privateOperation()

24
Class Attributes and Operations

• Example of a public class attribute and a private
  class operation.
• Order
• nextOrderNum Integer
• -bumpNextOrderNum()

25
Abstract Operations and Classes

• Polygon
• abstract
• /area Area
• getArea(out area Area)abstract

26
The Utility

• The utility (or utility package) is a group of
  procedures and functions encapsulated into a
  single unit with a set of private data. It
  differs from the class in that individual objects
  are never instantiated from it the utility is
  more like a group of traditional functions and
  procedures.
• The utility is like a class with no objects Its
  operations are, in effect, class operations
  (Alternatively, you could regard a utility as a
  class with only one, predefined object)
• The utility is valuable for implementing a
  software construct with only one instance, such
  as a Math package.

27
Example of a Utility class in UML

• ltltutilitygtgt
• SymbolTable
• insertSymbol(symbol Token) Integer
• findSymbol(symbol Token) Boolean

28
Parameterized Classes
T
Set
29
A bound class, formed from a parameterized class

• Set ltCargt
• Fleet Set ltCargt

30
Summary

• The class symbol is central to UML. It is
  typically shown with three compartments from top
  to bottom, they contain the class name and any
  supplementary information, the attributes, and
  the operations, respectively.
• Objects appear in a similar form to classes,
  except that the objects name, in the top
  compartment, is underlined and usually expressed
  as objClass

31
Summary

• An attribute represents a piece of information
  about an object and appears in the middle
  compartment of the class symbol.
• Each attribute is listed by name, followed by its
  class (or data type).
• By implication, when an attribute is listed, the
  operation compartment contains a get operation
  and a set operation.
• If the set operation is not necessary, or is not
  allowed, the attribute name is preceded with a
  forward slash /

32
Summary

• The operations are listed in the third
  compartment of the class symbol.
• Each operation is listed with its full formal
  signature (its name, followed by the formal input
  and/or output arguments.
• Conventionally, get and set operations are
  omitted for brevity, unless a designer needs to
  emphasize an operation such as a get operation
  that requires an input argument.

33
Summary

• Names of public, protected and private attributes
  and operations are prefixed by a plus sign (), a
  number sign (), and a minus sign (-),
  respectively.
• The sign is normally dropped, because
  visibility is public by default.
• Class attributes and operations, which are not
  instantiated for individual objects, are given
  underlined names.

34
Summary

• An operation is overloaded if it appears several
  times on a class diagram, each time with a
  different signature.
• The name of an abstract class appears in italics
  and is followed by the property abstract.
• An abstract operations name also appears in
  italics and has the property abstract

35
Summary

• The name of a utility class is preceded by the
  ltltutilitygtgt stereotype.
• Even though a utilitys operations are in effect
  class operations, by convention, their names are
  not underlined.
• A parameterized class (or generic or template
  class) appears with a dotted box over its top
  right corner.
• The dotted box contains a list of formal argument
  names, each of which represents a specific class
  to be supplied to the parameterized class.

36
The Generalization Construct

• PoweredVehicle
• Car Truck

37
Multiple Inheritance (not allowed in Java)

• Aircraft PoweredVehicle
• Airplane Car Truck

38
Generalization

• Specializing a superclass into two or more
  subclasses
• The discriminator is a label that describes the
  criteria used in the specialization

39
The Association Construct

• An association in UML represents a varying
  population of relationship links between classes.
  
• For example, if we have two classes
  LibraryPatron and LibraryBook. An association
  between them might be Borrowing, a set of
  relationship links stating which patron is
  currently borrowing which book. Today, the
  Borrowing association may contain the following
  links

40
Associations

• Fred is borrowing Software Engineering
• Mary is borrowing To Kill a Mocking Bird
• Sally is borrowing Memoirs of a Geisha
• Bob is borrowing Snow Falling on the Cedars
• Ann is borrowing Ordinary People
• Stan is borrowing A Walk in the Woods
• Dave is borrowing The Assault

41
Associations

• Tomorrow, Borrowing may contain these eight
  links.
• Mary is borrowing To Kill a Mocking Bird
• Stan is borrowing A Walk in the Woods
• Bob is borrowing Snow Falling on the Cedars
• Dave is borrowing Shane
• Ann is borrowing The Refuge
• Sally is borrowing The God of Small Things
• Mike is borrowing The Wall Jumper
• Cindy is borrowing From Beirut to Jerusalem

42
Associations

• Next, month the library is closed for
  renovations there may be no instances of
  Borrowing.
• Each link in a (binary) association connects
  together one instance of the first class with one
  instance of the second class, reflecting a
  particular business relationship between these
  instances. The business relationship in this
  example is book borrowing.
• Notice that Borrowing represents a bunch of
  links, the actual number of which changes over
  time. In this respect, an association is really
  like a class whose instances are links.

43
Associations and Multiplicity

• An association is used to show how two classes
  are related to each other
• Symbols indicating multiplicity are shown at each
  end of the association

44
Labelling associations

• Each association can be labelled, to make
  explicit the nature of the association

45
Analysing and validating associations

• One-to-one
• For each company, there is exactly one board of
  directors
• A board is the board of only one company
• A company must always have a board
• A board must always be of some company

46
Analysing and validating associations

• Many-to-many
• A secretary can work for many managers
• A manager can have many secretaries
• Secretaries can work in pools
• Managers can have a group of secretaries
• Some managers might have zero secretaries.
• Is it possible for a secretary to have, perhaps
  temporarily, zero managers?

47
Problems for discussion

• Create two or three classes linked by
  associations to represent the situations below.
  Take care to specify appropriate multiplicity, as
  well as labels for the associations. If there is
  more than one reasonable alternative, explain the
  advantage and disadvantage of each.
• Vehicles possessing wheels
• A video rental shop, where you must purchase a
  membership before renting something.

48
Problems

• Countries and their heads of state.
• A student taking courses in a school
• People registering for fitness activities in a
  gym.
• A library lending books to patrons.
• Person working on projects using a programming
  language
• Explain the consequences of the associations in
  terms of the creation and destruction of
  instances. Think about the order in which
  instances can be created or destroyed.

49
Avoiding having instances change class

• An instance should never need to change class

50
Analysing and validating associations

• Avoid unnecessary one-to-one associations
• Avoid this do this

51
A more complex example

• A booking is always for exactly one passenger
• no booking with zero passengers
• a booking could never involve more than one
  passenger.
• A Passenger can have any number of Bookings
• a passenger could have no bookings at all
• a passenger could have more than one booking

52
Association classes

• Sometimes, an attribute that concerns two
  associated classes cannot be placed in either of
  the classes
• The following are equivalent

53
Reflexive associations

• It is possible for an association to connect a
  class to itself

successor

Course
isMutuallyExclusiveWith



prerequisite
54
Directionality in associations

• Associations are by default bi-directional
• It is possible to limit the direction of an
  association by adding an arrow at one end

Note
Day
55
Instance Diagrams

• A link is an instance of an association
• In the same way that we say an object is an
  instance of a class

PatEmployee
WayneEmployee
OOCorpCompany
OOCorp's Board
AliEmployee
CarlaEmployee
UML incCompany
UML inc's Board
TerryEmployee
56
Associations versus generalizations in instance
diagrams

• Associations describe the relationships that will
  exist between instances at run time.
• When you show an instance diagram generated from
  a class diagram, there will be an instance of
  both classes joined by an association
• Generalizations describe relationships between
  classes in class diagrams.
• They do not appear in instance diagrams at all.
• An instance of any class should also be
  considered to be an instance of each of that
  classs superclasses

57
Activities during Object Modeling

• Main goal Find the important abstractions
• What happens if we find the wrong abstractions?
• Iterate and correct the model
• Steps during object modeling
• 1. Class identification
• Based on the fundamental assumption that we can
  find abstractions
• 2. Find the attributes
• 3. Find the methods
• 4. Find the associations between classes
• Order of steps
• Goal get the desired abstractions
• Order of steps secondary, only a heuristic
• Iteration is important

58
Class Identification

• Identify the boundaries of the system
• Identify the important entities in the system
• Class identification is crucial to
  object-oriented modeling
• Basic assumption
• 1. We can find the classes for a new software
  system (Forward Engineering)
• 2. We can identify the classes in an existing
  system (Reverse Engineering)

59
Class Identification

• Objects are not just found by taking a picture of
  a scene or domain
• The application domain has to be analyzed.
• Depending on the purpose of the system different
  objects might be found
• How can we identify the purpose of a system?
• Scenarios and use cases
• Another important problem Define system
  boundary.
• What object is inside, what object is outside?

60
Pieces of an Object Model

• Classes
• Associations (Relations)
• Generic associations
• Canonical associations
• Part of- Hierarchy (Aggregation)
• Kind of-Hierarchy (Generalization)
• Attributes
• Detection of attributes
• Application specific
• Attributes in one system can be classes in
  another system
• Turning attributes to classes
• Operations
• Detection of operations
• Generic operations Get/Set, General world
  knowledge, design patterns
• Domain operations Dynamic model, Functional model

61
Object vs Class

• Object (instance) Exactly one thing
• This lecture on Analysis on March 5 from
  600-900
• A class describes a group of objects with similar
  properties
• Game, Tournament, mechanic, car, database
• Object diagram A graphic notation for modeling
  objects, classes and their relationships
  ("associations")
• Class diagram Template for describing many
  instances of data. Useful for taxonomies,
  patters, schemata...
• Instance diagram A particular set of objects
  relating to each other. Useful for discussing
  scenarios, test cases and examples

62
Class identification

• Finding objects is the central piece in object
  modeling
• Approaches
• Application domain approach
• Ask application domain expert to identify
  relevant abstractions
• Syntactic approach
• Start with use cases. Extract participating
  objects from flow of events
• Use noun-verb analysis (Abbots technique) to
  identify components of the object model
• Design patterns approach
• Use reusable design patterns
• Component-based approach
• Identify existing solution classes

63
How do you find classes?

• Finding objects is the central piece in object
  modeling
• Learn about problem domain Observe your client
• Apply general world knowledge and intuition
• Take the flow of events and find participating
  objects in use cases
• Try to establish a taxonomy
• Do a syntactic analysis of problem statement,
  scenario or flow of events
• Abbott Textual Analysis, 1983, also called
  noun-verb analysis
• Nouns are good candidates for classes
• Verbs are good candidates for operations
• Apply design knowledge
• Distinguish different types of objects
• Apply design patterns

64
Finding Participating Objects in Use Cases

• Pick a use case and look at its flow of events
• Find terms that developers or users need to
  clarify in order to understand the flow of events
• Look for recurring nouns (e.g., Incident),
• Identify real world entities that the system
  needs to keep track of (e.g., FieldOfficer,
  Dispatcher, Resource),
• Identify real world procedures that the system
  needs to keep track of (e.g., EmergencyOperationsP
  lan),
• Identify data sources or sinks (e.g., Printer)
• Identify interface artifacts (e.g.,
  PoliceStation)
• Be prepared that some objects are still missing
  and need to be found
• Model the flow of events with a sequence diagram
• Always use the users terms

65
Object Types

• Entity Objects
• Represent the persistent information tracked by
  the system (Application domain objects, Business
  objects)
• Boundary Objects
• Represent the interaction between the user and
  the system
• Control Objects
• Represent the control tasks performed by the
  system
• Having three types of objects leads to models
  that are more resilient to change.
• The interface of a system changes more likely
  than the control
• The control of the system change more likely than
  the application domain
• Object types originated in Smalltalk
• Model, View, Controller (MVC)

66
Example 2BWatch Objects
Button
Year
ChangeDate
Month
LCDDisplay
Day
Entity Objects
Control Objects
Interface Objects
67
Naming of Object Types in UML

• UML provides several mechanisms to extend the
  language
• UML provides the stereotype mechanism to present
  new modeling elements

ltltBoundarygtgt Button
ltltEntitygtgt Year
ltltControlgtgt ChangeDate
ltltEntititygtgt Month
ltltBoundarygtgt LCDDisplay
ltltEntitygtgt Day
Entity Objects
Control Objects
Boundary Objects
68
Recommended Naming Convention for Object Types

• To distinguish the different object types on a
  syntactical basis, we recommend suffixes
• Objects ending with the _Boundary suffix are
  boundary objects
• Objects ending with the _Control suffix are
  control objects
• Entity objects do not have any suffix appended to
  their name.

Button_Boundary
Year
ChangeDate_ Control
Month
LCDDisplay_Boundary
Day
69
Example Flow of events

• The customer enters a store with the intention of
  buying a toy for his child with the age of n.
• Help must be available within less than one
  minute.
• The store owner gives advice to the customer. The
  advice depends on the age range of the child and
  the attributes of the toy.
• The customer selects a dangerous toy which is
  unsuitable for the child.
• The store owner recommends a more appropriate
  toy.

70
Mapping parts of speech to object model
components Abbott, 1983

Part of speech
Model component
Example

Proper noun
object
Jim Smith

Improper noun
class
Toy, doll

Doing verb
method
Buy, recommend

being verb
inheritance
is-a (kind-of)

having verb
aggregation
has an

modal verb
constraint
must be

adjective
attribute
3 years old

transitive verb
method
enter

intransitive verb
method (event)
depends on
71
Another Example
Flow of events

• The customer enters the store to buy a toy.
• It has to be a toy that his daughter likes and it
  must cost less than 25
• He tries a videogame, which uses a data glove and
  a head-mounted display. He likes it.
• An assistant helps him.
• The suitability of the game depends on the age of
  the child.
• His daughter is only 3 years old.
• The assistant recommends another type of toy,
  namely the boardgame Candyland".

Is this a good use Case?
Not quite!
Candyland is probably a left over from the
scenario
The use case should terminate with the customer
leaving the store
72
Textual Analysis using Abbots technique
Grammatical construct
UML Component
Example
Concrete Person, Thing
Object
Monopoly"
noun
class
toy"
Adjective
Attribute
"3 years old"
verb
Operation
enters"
Intransitive verb
Operation (Event)
depends on."
Classifying verb
Inheritance
is a" ,either..or", kind of"
Possessive Verb
Aggregation
"Has a ", consists of"
modal Verb
Constraint
must be", less than"
73
Generation of a class diagram from flow of events
Customer
Flow of events

• The customer enters the store to buy a toy.
• It has to be a toy that his daughter likes and it
  must cost less than 25
• He tries a videogame, which uses a data glove and
  a head-mounted display. He likes it.
• An assistant helps him.
• The suitability of the game depends on the age of
  the child.
• His daughter is only 3 years old.
• The assistant recommends another type of toy,
  namely a boardgame.
• The customer buy the game and leaves the store

toy price buy() like()
74
Order of activities in modeling

1. Formulate a few scenarios with help from the end
   user and/or application domain expert.
2. Extract the use cases from the scenarios, with
   the help of application domain expert.
3. Analyse the flow of events, for example with
   Abbot's textual analysis.
4. Generate the class diagrams, which includes the
   following steps
5. Class identification (textual analysis, domain
   experts).
6. Identification of attributes and operations
   (sometimes before the classes are found!)
7. Identification of associations between classes
8. Identification of multiplicities
9. Identification of roles
10. Identification of constraints

75
Project Management Heuristics

• Explicitly schedule meetings for object
  identification
• First just find objects
• Then try to differentiate them between entity,
  interface and control objects
• Find associations and their multiplicity
• Unusual multiplicities usually lead to new
  objects or categories
• Identify Inheritance Look for a Taxonomy,
  Categorize
• Identify Aggregation
• Allow time for brainstorming , Iterate, iterate

76
Who uses class diagrams?

• Purpose of Class diagrams
• The description of the static properties of a
  system (main purpose)
• Who uses class diagrams?
• The customer and the end user are often not
  interested in class diagrams. They usually focus
  more on the functionality of the system.
• The application domain expert uses class diagrams
  to model the application domain
• The developer uses class diagrams during the
  development of a system,that is, during analysis,
  system design, object design and implementation.

77
Class-diagrams have different types of users

• According to the development activity, the
  developer plays different roles.
• Analyst
• System-Designer,
• DetailedDesigner
• Implementor.
• In small systems some of the roles do not exist
  or are played by the same person.
• Each of these roles has a different view about
  the models.
• Before I describe these different views, I want
  to distinguish the types of classes that appear
  in class diagrams.
• Application domain classes
• Solution domain classes

78
Application domain vs solution domain

• Application domain
• The problem domain (financial services,
  meteorology, accident management, architecture,
  ).
• Application domain class
• An abstraction in the application domain. If we
  model business applications, these classes are
  also called business objects.
• Example Board game, Tournament
• Solution domain
• Domains that help in the solution of problems
  (telecommunication, data bases, compiler
  construction, operating systems, .)
• Solution domain class
• An abstraction, that is introduced for technical
  reasons, because it helps in the solution of a
  problem.
• Examples Tree, Hashtable, Scheduler

79
The Role of the Analyst

• The analyst is interested
• in application classes The associations between
  classes are relationships between abstractions in
  the application domain.
• whether the use of inheritance in the model
  reflects the taxonomies in the application
  domain.
• Definition Taxonomy A hierarchy of abstractions
• The analyst is not interested
• in the exact signature of operations.
• in solution classes.

80
Designer

• The designer focuses on the solution to the
  problem, that is the solution domain.
• Design consists of many tasks (subsystem
  decomposition, selection of the hardware
  platform, data management system, etc.).
• An important design problem is the specification
  of interfaces
• The designer describes the interface of classes
  (object design) and subsystems (system design).
• The goal of the designer is usability and
  reusability of interface
• Design-Usability the interfaces are usable from
  as many classes as possible within in the system.
  
• Design-Reusability Definition of interfaces,
  such that they can also be used in other (future)
  software systems. gt Class libraries.

81
Three Types of Implementors

• Class implementor
• Implements the class. The implementor chooses
  appropriate data structures (for the attributes)
  and algorithms (for the operations), and
  realizes the interface of the class in a
  programming language.
• Class extender
• Extends the class by a subclass, which is needed
  for a new problem or a new application domain.
• Class-user (client)
• The programmer, who wants to use an existing
  class (e.g. a class from a class library or a
  class from another subsystem).
• The class user is only interested in the
  Signatures of the class operations and the
  preconditions, under which they can be invoked.
  The class user is not so much interested in the
  implementation of the class.

82
Why do we distinguish these different users of
class diagrams?

• Models often dont distinguish between
  application classes (address book") and
  solution class (array", tree").
• Reason Modelling languages like UML allow the
  use of both types of classes in the same model.
• Preferred No solution classes in the analysis
  model.
• Many systems dont distinguish between
  specification and implementation of a class.
• Reason Object-oriented programming languages
  allow the simultaneous use of specification and
  implementation of a class.
• Preferred The object design model does not
  contain implementations.
• The key for creating high quality software
  systems is the exact distinction between
• Application and solution domain classes
• Interface specification and implementation
  specification

83
Class diagrams are always part of models

• Analysis model Application domain model
• System Design and Object design models Solution
  domain model
• Depending on our role, we look at objects and
  models from a different perspective. Often we
  are only interested in limited aspects of a
  model
• gt 3 kinds of interfaces in the object design
  model
• Depending on our role and the model we have
  different interpretations for different UML
  constructs
• Different interpretations of associations
• Different interpretations of attributes
• Different interpretation of inheritance
• Lets take a look at these different
  interpretations.

84
Analysis model

• The Analysis model is constructed during the
  analysis phase.
• Main stake holders End user, Customer, Analyst.
• The diagram contains only application domain
  classes.
• The analysis model is the base for communication
  between analyists, experts in the application
  domain and end users of the system.

85
Object design model

• The object design model (sometimes also called
  specification model) is created during the object
  design phase
• Main stake holders are class specificiers,
  class implementors and class users
• The class diagrams contain application and
  solution domain classes.
• The object design model is the basis of
  communication between designers and implementors.

86
Instance Diagrams

• A link is an instance of an association
• In the same way that we say an object is an
  instance of a class

PatEmployee
WayneEmployee
OOCorpCompany
OOCorp's Board
AliEmployee
CarlaEmployee
UML incCompany
UML inc's Board
TerryEmployee
87
Associations versus generalizations in instance
diagrams

• Associations describe the relationships that will
  exist between instances at run time.
• When you show an instance diagram generated from
  a class diagram, there will be an instance of
  both classes joined by an association
• Generalizations describe relationships between
  classes in class diagrams.
• They do not appear in instance diagrams at all.
• An instance of any class should also be
  considered to be an instance of each of that
  classs superclasses

88
Instance Diagram

• United Nations is member of
• is member of
• is member of France Canada is
  part of Ontario
• is member of is member of
  is part of borders
• NATO Quebec
• is member of is member of borders borders
• Mexico borders United States is part of
  New York State

89
More Advanced Features Aggregation

• Aggregations are special associations that
  represent part-whole relationships.
• The whole side is often called the assembly or
  the aggregate
• This symbol is a shorthand notation association
  named isPartOf

VehiclePart
Vehicle






Region
Country
90
Aggregation

• Aggregation is typically described as is part
  of relationship, in which objects representing
  the components of an object are associated with
  the object containing the entire assembly.
• Aggregation implies that an object owns or is
  responsible for a group of other objects. A
  classical example is the parts explosion diagram
  shown on the previous page.
• In comparison, an association link implies that
  an object knows of another object in the sense
  that they must interact in some capacity.

91
Aggregation

• The objects in an aggregation are independent,
  but are more tightly coupled than through an
  ordinary association.
• Aggregation is transitive. That is, if A is part
  of B, and B is part of C, implies A is a part of
  C. Aggregation is not symmetric. A is a part of
  B does not imply that B is a part of A.
• A polygon is an aggregate of three or more (many
  ordered points).
• Polygon ordered Point
• 3

92
When to use an aggregation

• As a general rule, you can mark an association as
  an aggregation if the following are true
• You can state that
• the 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

93
Composition

• A composition is a strong kind of aggregation
• if the aggregate is destroyed, then the parts are
  destroyed as well.
• Two alternatives for addresses

Room
Building
94
Aggregation hierarchy
Vehicle


Door
BodyPanel
Chassis

Wheel
Transmission
Engine
Frame
95
Propagation

• A mechanism where an operation in an aggregate is
  implemented by having the aggregate perform that
  operation on its parts
• At the same time, properties of the parts are
  often propagated back to the aggregate
• Propagation is to aggregation as inheritance is
  to generalization.
• The major difference is
• inheritance is an implicit mechanism
• propagation has to be programmed when required

96
Justification for the composition

• A polygon is composed of line segments
• An object that manipulates a polygon also
  manipulates the line segments
• When the polygon is translated or scaled, the
  line segments are also translated or scaled
• The perimeter of the polygon is computed as the
  sum of the lengths of all the line segments
• Removing a line segment from a polygon would mean
  that the polygon is no longer a polygon,
  therefore the polygon must have complete control
  to prevent such a change
• The line segments are deleted when the polygon is
  deleted

97
Interfaces

• An interface describes a portion of the visible
  behaviour of a set of objects.
• An interface is similar to a class, except it
  lacks instance variables and implemented methods

interface
Machine
Person
Machine
Person
Cashier
withdraw
Cashier
Cashier
deposit
ATM
Employee
ATM
Employee
98
Distinction between inheritance and Interfaces

• Inheritance is characterized by an isa
  relationship between a superclass and a subclass.
  
• In the case of interfaces, the relationship
  between the implementing class and the interface
  can be described as can-be-seen as.
• In the previous example, both bank employees and
  automatic teller machines can be seen as a sort
  of cashier. That is, it is possible to interact
  with one or the other in order to deposit or
  withdraw money.
• Though they share common operations, they have
  different superclasses.
• So, they cannot be put in the same inheritance
  hierarchy.

99
Notes and descriptive text

• Descriptive text and other diagrams
• Embed your diagrams in a larger document
• Text can explain aspects of the system using any
  notation you like
• Highlight and expand on important features, and
  give rationale
• Notes
• A note is a small block of text embedded in a UML
  diagram
• It acts like a comment in a programming language

100
Object Constraint Language (OCL)

• OCL is a specification language designed to
  formally specify constraints in software modules
• An OCL expression simply specifies a logical fact
  (a constraint) about the system that must remain
  true
• A constraint cannot have any side-effects
• it cannot compute a non-Boolean result nor modify
  any data.
• OCL statements in class diagrams can specify what
  the values of attributes and associations must be

101
OCL statements

• OCL statements can be built from
• References to role names, association names,
  attributes and the results of operations
• The logical values true and false
• Logical operators such as and, or, , gt, lt or ltgt
  (not equals)
• String values such as a string
• Integers and real numbers
• Arithmetic operations , /, , -

102
An example constraints on Polygons
edge-gtforAll(e1,e2
e1 ltgt e2
implies e1.startPoint ltgt e2.startpoint
and e1.endPoint ltgt e2.endpoint)
a LinearShape is any shape
ordered
that can be constructed of line
edge
LinearShape
LineSegment
segments (in contrast with
1..
shapes that contain curves).
startPoint Point
endPoint Point
length int
Path
Line
Polygon
startPoint ltgt endPoint
length
edge-gtfirst.startPoint
edge-gtsize1
edge-gtlast.endPoint
length
edge.length-gtsum
RegularPolygon
edge-gtforAll(e1,e2
e1.length e2.length)
103
OCL expressions

• OCL expressions do not have to be written
  directly on a diagram. In order to avoid
  clutter, you can write them separately and
  specify a context for each expression, as shown
  below
• context LineSegment inv
• startPointltgt endPoint
• In the above expression, inv means that the
  statement is an invariant (always true of the
  class LineSegment)

104
The Process of Developing Class Diagrams

• You can create UML models at different stages and
  with different purposes and levels of details
• Exploratory domain model
• Developed in domain analysis to learn about the
  domain
• System domain model
• Models aspects of the domain represented by the
  system
• System model
• Includes also classes used to build the user
  interface and system architecture

105
System domain model vs System model

• The system domain model omits many classes that
  are needed to build a complete system
• Can contain less than half the classes of the
  system.
• Should be developed to be used independently of
  particular sets of
• user interface classes
• architectural classes
• The complete system model includes
• The system domain model
• User interface classes
• Architectural classes
• Utility classes

106
Suggested sequence of activities

• Identify a first set of candidate classes
• Add associations and attributes
• Find generalizations
• List the main responsibilities of each class
• Decide on specific operations
• Iterate over the entire process until the model
  is satisfactory
• Add or delete classes, associations, attributes,
  generalizations, responsibilities or operations
• Identify interfaces
• Apply design patterns
• Dont be too disorganized. Dont be too rigid
  either.

107
Identifying classes

• When developing a domain model you tend to
  discover classes
• When you work on the user interface or the system
  architecture, you tend to invent classes
• Needed to solve a particular design problem
• (Inventing may also occur when creating a domain
  model)
• Reuse should always be a concern
• Frameworks
• System extensions
• Similar systems

108
A simple technique for discovering domain classes

• Look at a source material such as a description
  of requirements
• Extract the nouns and noun phrases
• Eliminate nouns that
• are redundant
• represent instances
• are vague or highly general
• not needed in the application
• Pay attention to classes in a domain model that
  represent types of users or other actors

109
Identifying associations and attributes

• Start with classes you think are most central and
  important
• Decide on the clear and obvious data it must
  contain and its relationships to other classes.
• Work outwards towards the classes that are less
  important.
• Avoid adding many associations and attributes to
  a class
• A system is simpler if it manipulates less
  information

110
Tips about identifying and specifying valid
associations

• An association should exist if a class
• possesses
• controls
• is connected to
• is related to
• is a part of
• has as parts
• is a member of, or
• has as members
• some other class in your model
• Specify the multiplicity at both ends
• Label it clearly.

111
Actions versus associations

• A common mistake is to represent actions as if
  they were associations

borrow
return



Better The
operation creates a
, and
borrow
Loan
Bad, due to the use of associations
the
operation sets the

return
returnedDate
that are actions
attribute.
112
Identifying attributes

• Look for information that must be maintained
  about each class
• Several nouns rejected as classes, may now become
  attributes
• An attribute should generally contain a simple
  value
• E.g. string, number
• It is not good to have many duplicate attributes
  
• If a subset of a classs attributes form a
  coherent group, then create a distinct class
  containing these attributes

113
Tips about identifying and specifying valid
attributes
114
An example (attributes and associations)
Employee
RegularFlight
Passenger

name
time
name
employeeNumber
flightNumber
number
jobFunction
supervisor



















Booking






SpecificFlight
seatNumber
date
115
Identifying generalizations and interfaces

• There are two ways to identify generalizations
• bottom-up
• Group together similar classes creating a new
  superclass
• top-down
• Look for more general classes first, specialize
  them if needed
• Create an interface, instead of a superclass if
• The classes are very dissimilar except for having
  a few operations in common
• One or more of the classes already have their
  own superclasses

116
An example (generalization)
Person
0..2
0..2
0..2
0..2
0..2
0..2
PersonRole
name
idNumber
RegularFlight

EmployeeRole
time
PassengerRole
flightNumber
jobFunction
supervisor



















Booking






SpecificFlight
seatNumber
date
117
Allocating responsibilities to classes

• A responsibility is something that the system is
  required to do.
• Each functional requirement must be attributed to
  one of the classes
• All the responsibilities of a given class should
  be clearly related.
• If a class has too many responsibilities,
  consider splitting it into distinct classes
• If a class has no responsibilities attached to
  it, then it is probably useless
• When a responsibility cannot be attributed to any
  of the existing classes, then a new class should
  be created

118
Allocating responsibilities to classes

• To determine responsibilities
• Perform use case analysis
• Look for verbs and nouns describing actions in
  the system description

119
Categories of responsibilities

• Setting and getting the values of attributes
• Creating and initializing new instances
• Loading to and saving from persistent storage
• Destroying instances
• Adding and deleting links of associations
• Copying, converting, transforming, transmitting
  or outputting
• Computing numerical results
• Navigating and searching
• Other specialized work

120
An example (responsibilities)






Airline
Person
0..2
0..2
0..2
0..2
0..2
0..2

• Creating a new regular flight
• Searching for a flight
• Modifying attributes of a flight
• Creating a specific flight
• Booking a passenger
• Canceling a booking

PersonRole
name
idNumber