1. Software Engineering OO Analysis (Object-Relationship and Object-Behaviour Models)

2. Objectives 1.To show the object-relationship design process 2.To introduce the core UML class diagram notation

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, Define a class hierarchy Class Responsibility Collaborator (CRC) Cards 3. Build an object-relationship model (structural) Conceptual Class Diagram 4. Build an object-behaviour model (dynamic) Interaction Diagrams

4. What is structural modeling? lStructural model: a view of a system that emphasizes the structure of the objects, including their classifiers, relationships, attributes and operations. lIllustrates meaningful concepts in a problem domain lthe most important artifact to create during OO analysis lusually expressed in the form of static diagrams lis a representation of real-world things; not software components lno operations are defined in conceptual model lshould 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 lStatic View  Do not show temporal information lUsed in both analysis (conceptual) and design (specification and implementation) lConceptual class diagrams only require a subset of the full UML notation

6. Developing an Object-Relationship Model lWith reference to the CRC model: 1.An unlabelled network of collaborating classes is drawn. 2.Connections are named and oriented from client to server. 3.Each end of a connection is evaluated to determine cardinality.

7. UML Class Diagram Example Class Association Label and Navigability Multiplicity system audible alarm control panel sensor sensor event contains  polls  recognizes  produces  111 1..* 1 * 1 *

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. lFor an object A to send a message to B. B must be visible to A. polls 

11. Multiplicity lMultiplicity is not always symmetrical. The relationship of B to A may not be the same as A to B lExample: A system may produce many audible alarms BUT each audible alarm is produced by only one system. lUse the labels and classes names to help in deciding 1 1.. * 0..1 *

12. Generalization lGeneralization: identifying commonality among classes and defining supertype and subtype relationships. lIs-a Rule: use phrase “Subtype is a Supertype” to test l100% Rule: all the functionality of the supertype is true in the subtype

13. Defining Subtypes 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 supertype 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 supertype. lAll subtypes have the same association with another class which can be factored out and related in the supertype.

15. Aggregation lA composite aggregation (filled diamond) means that the multiplicity at the composite end may be at most one. lShared aggregation (hollow diamond) means that the multiplicity at the composite end may be more than one.

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 6. Control panel

18. Example: Package Reference

19. 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