COMMONWEALTH OF AUSTRALIA

FIT2005 Software Analysis, Design & Architecture

Copyright Regulations 1969 WARNING

Module 3: Modelling Software Internals: Static Structure

Includes many images from the book UML 2 and the Unified Process by Arlow

This material has been reproduced and communicated to you by or on behalf of Monash University pursuant to Part VB of the Copyright Act 1968 (the Act). The material in this communication may be subject to copyright under the Act. Any further reproduction or communication of this material by you may be the subject of copyright protection under the Act. Do not remove this notice.
www.monash.edu.au
2

Module 3 Objectives
On completion of this session you should have a conceptual understanding of: Classes and Objects Attributes and Operations Associations and Links Multiplicities Dependencies The UML notations for UML class and object diagrams

Module 3 Objectives (continued)

On completion of this module you should be able to:
identify classes; identify responsibilities for classes; identify relationships between classes; produce class and object diagrams; interpret a class or object diagram to reason about a system; use multiplicities to constrain relationships

Object-Oriented Some definitions

Superficially the term object-oriented means that we organise software as a collection of discrete objects that incorporate both data & structure [Rumbaugh et.al 1991] An object has state, behaviour & identity; the structure and behaviour of similar objects are defined in their common class [Booch 1991] The object-oriented approach attempts to manage complexity inherent in real-world problems by abstracting our knowledge and encapsulating it within objects.
[Wirfs-Brock, Wilkerson & Wiener, 1990].

FIT2005 Software Analysis, Design & Architecture

Overview of Object-Orientation
www.monash.edu.au

Objects - Overview
object instances & classes attributes operations associations

Encapsulation & Information Hiding

encapsulation:
Vehicle (Attributes) Stock # Make Model VIN Date Received Date Sold Registration Number Purchaser Name (Operations) Create New Vehicle Sell New Vehicle Register New Vehicle ..
7 8

containment of data & behaviour within an object

information hiding:
restriction of the interface which an object offers to others object displays some properties in a public interface object hides others and all internal details

these are related - but different.

states events activities & actions messages.

Objects
Entities with individual identity Individual properties, behaviours For example: A Person Object
Properties name (not necessarily unique) weight, height, address, tax file number, etc Behaviours eat, drink, groom, grow, heal, dress

Objects in Information Systems

Something which: can be defined as a concept or abstraction has meaning for the problem/system provides a practical basis for modelling has crisp boundaries
can clearly determine if an object instance belongs to the class.

Behaviours only operate on that entity

eat() only changes the weight property of THAT person object

Properties can only be changed by that objects behaviours

9 10

Objects can be...

concrete, tangible
bicycle, employee, account

Objects .
have a distinct identity even if it is indistinguishable from others of its class require no specific identifier in the object model
do include identifying attributes if they are part of the data

events or incidents
payment, EFTPOS, collision

roles
employee, analyst, insurer

interactions
employment, authentication

11

12

Objects

Object Classes
A class is derived from groups of objects Reduce complexity of a system Generalised from a few specific cases Grouped on common features of instances Special cases can invoke more specialised behaviours.

13

14

Object Classes
group objects into classes based on
common attributes common behaviour common relationships to other objects common semantics

Objects

grouping depends on the system & its purpose classification is inherently subjective
many different models may be correct. statement of assumptions becomes essential object instance - one thing

15

16

Objects

Objects

object class
- generic features shared by a set of object instances

object classes - a different set of shared features

17

18

Objects

Attributes
attributes describe properties of an object represented as the data values
e.g. CAR - make, model-year, colour, weight,
Data Process

attribute names are unique within a class

object classes a different set of features

attributes are pure data values

unlike objects, they do NOT have identity (NOT fields)

encapsulated within the object

can only be set or changed by the objects own processes

19

20

Operations and Methods

An Operation is a function or transformation that may be applied to an object or by an object in one or more classes
e.g. COMPANY object may hire-staff; sell-goods; pay-dividend.
Data Process

Relationships & Communication

Objects can be related to other objects
One object knows about the other ones existence

Objects expose a public interface

Operations that can be invoked by other objects

Messages are the means of communicating between objects

message passing involves exchanging commands or requests between the objects. Corresponds to invoking a method of the target object

Operations may have arguments (parameters), and could return a value. A Method is the implementation of an operation in code

21

22

Relationships & Communication Example

Bank Object
1. transfer(act1,act2,150)

Relationship of objects to classes

Each object is an instance of some class.

Objects send messages to other objects

messages 3. deposit(150) 2. withdraw(150)

Account Object (act1)

Account Object (act2)

23

[Arlow]

24

Levels of Scope
Instance Scope attributes and operations which belong to or operate on specific objects
Must be accessed via an instance Each instance has its own version of the attributes Such operations influence the particular object

Levels of Scope - notation

Class Scope attributes and operations which belong to or operate on the whole class of objects
Can access/use without needing an instance Such attributes can be considered as shared. Such operations do not influence a particular object

Source: Arlow Figure 7.15

25 26

Object construction and destruction

Constructor special operation to create a new instance of a class
Not usually shown in analysis Can be shown as a create operation, or as an operation with same name as class name.

Links and Messages

Link a semantic connection between two objects to allow messages to be sent from one to the other
The objects at either end may fulfill roles with respect to each other

Destructor special operation that clean-up when an object is destroyed

Inconsistent meaning between different programming languages Not usually shown in analysis; operation shown as ~ClassName (tilde at front of class name)

Message a request for an object to perform an operation

May convey information via parameters May return information as return values

Example:
A Bank object could send the message Withdraw $150 to an Account object, but only if it has a link to that account object

27

28

Static View vs Dynamic View

Software systems are modeled from multiple views
FIT2005 Software Analysis, Design & Architecture

The Static view considers the structure/organisation of elements that make up a system
E.g. Class diagrams

The Dynamic view considers behavioral aspects of the elements system

E.g. Interaction diagrams, state machine diagrams

Modelling Static Structure

www.monash.edu.au
30

Classes and Class Diagrams

Classes are the basic construct for organising and representing information and behavior in a system UML Class Diagrams are used to graphically present classes to emphasise their contents, and the relationships of classes to other classes A class diagram is a specification of potential objects and links between those objects at run time. A UML Object diagram can show a snapshot of objects and the links between them at a particular point in time

Summary of Complete UML Notation for a Class

Source: Arlow Figure 7.7

31 32

Showing Classes in UML

Only the Name compartment is mandatory For analysis, usually include:
Class name Significant attributes (usually only the names) Significant operations (usually only the names) Stereotypes but only if they have significance for the model

UML Notation for an Object (Instance)

Source: Arlow Figure 7.4

33 34

Object Diagram showing links

Association
Associations are relationships between classes For a link to occur between two objects, there must be an association defined between their classes
A link is an instance of an association

Associations can have:

A name for the association Role names for each participant of the relationship Multiplicity navigability Bidirectional link

Source: Arlow Figure 9.2

35 36

Associations in UML (1)

Associations in UML (2)

Source: Arlow Figure 9.6

Source: Arlow Figure 9.7

37

38

Multiplicity
One of the constraint mechanisms of UML Multiplicity constrains the number of objects that can be involved in a particular relationship at every point in time Given as a range: min..max Examples:
1 1..5 0..1 1..* 1..3,7..9 * only one at least one, and at most five maybe one, maybe none any number, but at least one either 1, 2, 3, 7, 8, or 9, but never any other number any number, possibly none

Effect of multiplicities

Note there are 2 distinct/separate associations between Person and Bank Account.

Source: Arlow Figure 9.9

39

40

Reflexive Associations
Class Diagram:

Navigability
Navigability indicates that objects of one class know about objects of another, and can traverse the link to reach the other object.
Indicated by arrows showing direction of permitted traversal A cross indicates that traversal in that direction is not permitted If no navigability is shown, assume navigable (although strict UML means navigability has not yet been defined for that direction)

Object Diagram:

[Source: Arlow]
41 42

Activity: Your Turn

How might you model the following:
Various companies employ various people as employees A given person may work for multiple companies (e.g. several part-time jobs)

Activity 2: Your Turn

How might you model the following:
Various companies employ various people as employees A given person may work for multiple companies (e.g. several part-time jobs)

How can we add the following to the model?

Each particular person has a particular salary for each particular company they work for

43

44

Association Class
An Association Class is an association that is also a class
Defines a set of features (attributes, operations, even associations) that belong to the association

Qualified Associations
A qualified association reduces multiplicity from n-tomany to an n-to-one association, by specifying a unique object from the many by stating a key the qualifier

Means that there can only be one link between two particular objects at any given point in time.

Source: Arlow Figure 9.19

45 46

Analysis Classes
Classes which map to real-world business concepts
FIT2005 Software Analysis, Design & Architecture

Classes that represent a crisp abstraction from the problem domain

Need small, well-defined set of responsibilities Name should clearly indicate its intent

Analysing Use Cases to find Analysis Classes

www.monash.edu.au

Analysis model should only contain Analysis classes not any design classes
Examples of design classes are classes that compose user interfaces, classes to manage collections, classes for network communication, etc.

48

Abstraction
The act of identifying the essential characteristics of a thing that distinguish it from all other kinds of things and omitting details that are unimportant from a certain viewpoint. Abstraction involves looking for similarities across sets of things by focusing on their essential common characteristics. An abstraction always involves the perspective and purpose of the viewer; different purposes result in different abstractions for the same things. All modelling involves abstraction, often at many levels for various purposes. The higher the level of abstraction, the less detail included.
[Rumbaugh 2005]

Abstraction
Example: An abstraction of a Cat. It just shows the typical shape of all cats. We can see that a cat has a belly, a face and two ears Things which in reality are quite different, are treated as being essentially equivalent

49

50

Abstraction as a process of analysis

In OO system analysis, we perform abstraction to find out what are the essential, common things about different possible objects.
Start by considering the individual actual things Gradually eliminate the specifics of the individuals, to be left with the essence of them

Determining appropriateness for inclusion

How do we know which features about an object are appropriate to keep in the abstraction? For OO modeling, we only consider those things which have relevance in the setting of the computer program For example: a system that keeps track of customer orders needs to maintain information about the customers. Which things about customers from the following list are relevant to the system:
Name, Age, Address, Place of Birth, Hair colour, Mothers name, Fathers name, Phone number, number of children, drivers licence number, credit card number.

We then develop models to represent this remaining information.

Use UML Class Diagrams to document it

51

52

Finding Classes
There is no simple way to find the right classes Several techniques available:
Noun/Verb Analysis CRC Analysis RUP Stereotypes Archetype patterns (covered in a module later in semester)

Finding Classes by Verb/Noun Analysis

Read through the textual problem description Underline all nouns
Likely candidates for classes, or attributes

Highlight all verbs

Likely candidates for responsibilities or operations for classes

Need to be aware of synonyms and homonyms

Synonym Different words meaning same concept Homonym Same word meaning different concepts in different situations

Be aware that some classes may be implicit, and not found in the text.
53 54

Finding Classes by CRC Analysis

Make up a set of cards / sticky-notes divided into sections for each of the following: Class name Responsibilities what this class will do Collaborators other classes which together with the class under consideration will work to realize part of the system functionality
Class Name: BankAccount Collaborators: Bank Responsibilities: Maintain balance

CRC Analysis procedure

Phase 1: Brainstorm/Gather information
Ask the stakeholders to name the things that matter in their business environment, e.g. customer, product Write each thing on a sticky note each could become a class or an attribute of a class Ask what responsibilities each thing might have. Record in the responsibilities compartment Try to work out which groups of classes (e.g. pairs) will work together for some tasks. Record in the collaborators comparment

Phase 2: Analyse information

Determine which things are best classes, which are attributes.

Note: CRC Analysis is generally used in conjunction with noun/verb analysis

55 56

Finding Classes using RUP Stereotypes

The Rational Unified Process defines the following stereotypes: Boundary Class A class that mediates interaction between the system and its environment Control Class A class that encapsulates use-casespecific behavior Entity Class A class that models persistent information Analysis is usually only concerned about entity classes. You consider the other two (Boundary and Control) in the Design workflow.

Artifacts for Analysis Model

Artifacts document the result of your thinking. Class Diagrams
Show classes and their relationships

Object diagrams
Show example possible configurations of objects and links

Project Glossary
Defines key concepts for the project Each class should be included (example template on next page) Alphabetically sorted for quick reference

57

58

Template for Class in Glossary

Class Name
Synonyms: Subtype of: Description: Author: Date: Type: Domain: (Concrete or Abstract) (explained later in unit)

Readings
Arlow: Chapters 7, 8 and 9

Attributes:

Operations:

59

60