1. Chris Russell O2.41 02920 41 6431 crussell@cardiffmet.ac.uk
Business Analysis
More on Classes
Chris Russell
O2.41
Lecture BA16 More on Classes

2. Lecture BA16 More on Classes
Session schedule
Business Analysis Schedule
Academic Year
Semester 2
Week
Topic 1
Introduction 2
Investigate situation: rich picture, context diagrams 3
Consider perspectives: types of participation, CATWOE, Power-Interest, Thomas-Kilmann 4
Analyse needs 1: Use Cases 5
Analyse needs 2: structured techniques 6
Define requirements 1a: SSADM 7
Define requirements 1b: SSADM
EASTER 8
Define requirements 2: UML 9
Generic assignment feed-forward and task review 10
Balance good enough software against quality costs; Prioritise requirements 11
Assignment submisison
Lecture BA16 More on Classes

3. Activities and Paradigms
Investigate Situation
Consider Perspectives
Analyse Needs
Define Requirements
Socio-technical
Rich picture
CATWOE
Types of participation
Thomas-Kilmann
Power-Interest X
Functional
Level 0 diagram
Structured techniques
DFD, ERM and ELH
Object-Oriented
Context diagram
Use Cases
Class and Sequence diagrams
Lecture BA16 More on Classes

4. Lecture BA16 More on Classes
Contents
CRC cards
Types of relationships
Associations
Aggregation
Dependency
Generalization
Constraints
Visibility and keys
Lecture BA16 More on Classes

5. Lecture BA16 More on Classes
CRC cards
Class Name: What am I?
Responsibilities:
What do I know?
What do I do?
What do I decide?
Collaborations:
Who do I interact with?
Lecture BA16 More on Classes

6. Types of relationships
Anything with a line
Association
Aggregation
Dependency
Generalization i.e. Inheritance
Composition (not discussed further)
Realizations (not discussed further)
Lecture BA16 More on Classes

7. Lecture BA16 More on Classes
Association…
‘An association is a structural relationship, specifying that objects of one element are connected to another’ (Object Management Group 2001)
Association indicates a stronger coupling than dependency due to the structural nature of the relationship
Lecture BA16 More on Classes

8. Lecture BA16 More on Classes
…Association
Represented by:
Solid line between the same or different classes
Usually labelled with a name (always if more than one association between two classes)
Name usually accompanied…
Cardinality should be indicated at each end of the association…
Lecture BA16 More on Classes

9. Lecture BA16 More on Classes
Types of multiplicity
0..n (1 or >1), 1..n, n..m
n (1 or >1)
0..*, 1..*, n..*
* ‘implies “0..*”’ (Object Management Group 2004) but can be confused with 1..* so should be avoided
Lecture BA16 More on Classes

10. Lecture BA16 More on Classes
Role names
As well as the association being named, the role that each object plays in the association can also be named (at each end of the relationship)
Especially important in the case of multiple relationships between classes
Example: employee and manager are both roles of Person, rather than separate classes
Lecture BA16 More on Classes

11. Reflexive associations
Instances of the same class can be linked by a reflexive association
In this case it is critical to identify roles
Examples: a relationship ‘manages’ between role boss of Person and role staff of person; a relationship ‘is married to’ between role husband of Person and role wife of person
Lecture BA16 More on Classes

12. Lecture BA16 More on Classes
Association classes
Represented by:
A class connected by a dotted line to the relationship it details
Examples: role boss of Person ‘manages’ role staff of person whereby mange entails an attribute performance rating and an operation evaluate
Useful where attributes/operations are not characteristic of the class itself and only meaningful in the context of a relationship (an instance cannot exist independently of the relationship)
Lecture BA16 More on Classes

13. Lecture BA16 More on Classes
Aggregation
Attributes that have structure and/or behaviour are depicted as objects e.g. car/engine
Composite aggregation
Represented by ‘filled in’ diamond at the ‘parent’ end of the relationship
Used when ‘parent’ (whole) exercises complete lifecycle control over its ‘children’ (parts) e.g. order line to order
Shared aggregation
Represented by ‘empty’ diamond at the ‘parent’ end of the relationship
Used when the ‘child’ may have a broader/longer lifecycle than the ‘parent’ e.g. an engine may outlive a car
Lecture BA16 More on Classes

14. Lecture BA16 More on Classes
Dependency…
‘A dependency is a using relationship, specifying that a change in one element may affect another element that uses it, but not necessarily the reverse’ (Object Management Group 2001)
Earlier in the module we have seen examples of this between uses cases:
<<include>>
<<extend>>
Lecture BA16 More on Classes

15. Lecture BA16 More on Classes
…Dependency
Represented by:
Directional arrow with a dashed line and open arrowhead
Optionally labelled with stereotype and individual name
Key stereotypes
<<use>> one class requires the use of another to fulfil its correct responsibilities e.g. calling an operation of another class
<<instantiate>> one class creates an instance of another class
<<friend>> one class is granted special visibility rights to the private parts of another class
Lecture BA16 More on Classes

16. Lecture BA16 More on Classes
Generalization
Through a process of generalisation, further classes are arrived at.
Generalisation with regard to classes is somewhat different than generalisation with regard to use cases. At this stage – nearer implementation – it ‘is associated with inheritance in programming languages. The subclass inherits all the methods and fields of the superclass and may override inherited methods’ (Fowler 2000).
Thus, generalisation here means looking for commonality rather than looking for alternatives.
This means that the generalisations previously identified are no longer apt, whilst there may be scope for generalisation elsewhere.
Lecture BA16 More on Classes

17. Lecture BA16 More on Classes
Constraints
These are used to add limiting information to a class diagram e.g.
{ordered} constraint next to an association indicates that objects are in a defined order and accessed by that order
{Abstract} constraint after a class name indicates it is a super-class and will never be instantiated itself
Lecture BA16 More on Classes

18. Lecture BA16 More on Classes
Visibility and keys
Visibility should only be shown on design diagrams
+ Public
# Protected
- Private
~ Package
Do not model keys unless specifically drawing a logical or physical database schema (they are a data concept not an OO concept)
Lecture BA16 More on Classes

19. Multiple class diagrams?
Conceptually there is only one class diagram for a system, containing all the relevant (static) information about the objects in it
However, it is usually clearer to have a number of class diagrams to capture different aspects, rather than clutter a single diagram with all the details
This can be achieved via use of packages
Lecture BA16 More on Classes

20. Business analysis example
Cadle, Paul and Turner, 2010
Lecture BA16 More on Classes

21. Lecture BA16 More on Classes
Where to stop
‘The nature of the associations - their multiplicity - represents a set of business rules...and these rules should properly be investigated by business analysts... However, it is less clear that the operations...are the province of business analysts’ (Cadle, Paul and Turner, 2010, p.224)
They suggest leaving operations and even attributes for systems analysts, designers, software architects or software developers
Lecture BA16 More on Classes