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

Lecture BA16 More on Classes Session schedule Business Analysis Schedule Academic Year 2014-5 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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