1. Software Engineering Object-Oriented Analysis (Class Diagrams) James Gain (jgain@cs.uct.ac.za)jgain@cs.uct.ac.za http://people.cs.uct.ac.za/~jgain

2. Objectives 1.Show the object-relationship design process 2.Introduce the core UML class diagram notation 3.Provide a case study class diagram

3. Analysis = Process + Models ProcessModel Output 1. Elicit customer requirements and identify use-cases Use-Case Diagrams 2. Extract candidate classes, Identify attributes and methods Class Responsibility Collaborator (CRC) Cards 3. Build an object-relationship model (structural) Conceptual Class Diagram 4. Build an object-behaviour model (dynamic) Interaction and State Diagrams

4. What is structural modelling? lStructural (object-relationship) model:  A view of a system that emphasizes the structure of the objects, including their classifiers, relationships, attributes and operations.  Illustrates meaningful concepts in the problem domain  The most important artifact to create during OO analysis  Expressed in the form of static diagrams  Should show concepts, associations between concepts, attributes of concepts

5. Class Diagrams lDescendent of Entity-Relationship Diagrams lShow the static structure of the model  the entities that exist  internal structure  relationship to other entities  Does NOT show temporal information lPerspective is Important:  Used in both analysis (conceptual class diagram) and design (specification and implementation class diagram)  Difference is a matter of detail lConceptual class diagrams only require a subset of the full UML notation

6. Developing a Class Diagram lStarting from the CRC model: 1.Draw an unlabelled network of collaborating classes 2.Connections are drawn between a class and its collaborators 3.Connections are named and oriented from client (caller) to server (callee). 4.Each end of a connection is evaluated to determine cardinality (also called multiplicity)

7. Case Study: UML Class Diagram Class Association Label Multiplicity

8. Class lDerived from the CRC Cards:  Each card represents a class  Its responsibilities become attributes and methods lSections: name, attributes, methods lBUT don’t provide any details for the attributes and methods Name Attributes Methods

9. Association lFocus on those associations for which knowledge of the relationship needs to be preserved for some duration (“need-to-know”) lIt is more important to identify classes than to identify associations lToo many associations can be confusing lClasses may have association with themselves person manages 1 *

10. Navigability lNavigability indicates that it is possible to move uni-directionally across the association from objects of the server to client class. lIndicated by an arrow head lImplies visibility; usually attribute visibility of the server from the client lNo arrow means bi-directional visibility lFor an object A to send a message to B. B must be visible to A.

11. Multiplicity lMultiplicity is not always symmetrical. The relationship of B to A may not be the same as A to B lExample: An edge attaches to only one overlay BUT each overlay may have many edges attached to it lUse the labels and classes names to help in deciding 1 1.. * 0..1 0..*

12. Generalization lGeneralization: identifying commonality among classes and defining supertype and subtype relationships

13. Defining Subtypes lIs-a Rule:  Use phrase “Sub-type is a Super-type” to test l100% Rule:  All the functionality of the Super-type is true in the Sub-type lAdditional Information:  The subtype has additional attributes of interest  The subtype has additional associations of interest lAdditional Behaviour:  The subtype is operated upon, handled, reacted to, or manipulated differently than the Super-type or other subtypes

14. Defining Supertypes lThe potential subtypes represent variations on a similar concept. lThe subtypes will conform to the 100% and Is-a rules. lAll subtypes have some attributes (and methods) which can be factored out and expressed in the Super-type. lAll subtypes have the same association with another class which can be factored out and related in the Super-type.

15. Aggregation lComposition (filled diamond):  Strong ownership of one class (the part) by another (the whole)  Exclusive relationship lAggregation (hollow diamond):  Loose informal relationship. Indicates that the whole is more important than the part  Non-exclusive. The part may participate in other aggregations

16. Aggregation Guidelines lThere is an obvious physical or logical assembly lThe part and composite have the same lifetime lSome properties of the composite propagate to the parts. Example: the limbs of a robot are offset from a common origin lOperations applied to the composite propagate to the parts such as destruction, movement, recording. Example: moving the torso of a robot also moves the attached limbs

17. Package Diagrams lIf the class diagram becomes too large it may be necessary to bundle it into packages. lEach package:  Provides a pointer to a more detailed class diagram  Represents a black box with well defined external associations 1. Geometry

18. Class Diagram Tips lDon’t try and use all the notation every time lMake certain of and don’t mix perspectives:  Conceptual class model for analysis  Specification class model when building software lDon’t draw models for everything. A few key diagrams that are frequently used are better than many forgotten, obsolete models lDon’t get bogged down in implementation details too early