Software Engineering OO Analysis ObjectRelationship and ObjectBehaviour Models

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

Objectives l To show the object-relationship design process l To introduce the core UML class diagram notation

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

What is structural modeling? l Structural model: a view of a system that emphasizes the structure of the objects, including their classifiers, relationships, attributes and operations. l Illustrates meaningful concepts in a problem domain l the most important artifact to create during OO analysis l usually expressed in the form of static diagrams l is a representation of real-world things; not software components l no operations are defined in conceptual model l should show concepts, associations between concepts, attributes of concepts

Class Diagrams l Descendent of Entity-Relationship Diagrams l Show the static structure of the model - the entities that exist - internal structure - relationship to other entities l Static View - Do not show temporal information l Used in both analysis (conceptual) and design (specification and implementation) l Conceptual class diagrams only require a subset of the full UML notation

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

UML Class Diagram Example Label and Navigability contains u system 1 1 control panel polls u 1 1 sensor 1. . * 1 recognizes q Multiplicity produces q * * Association audible alarm Class sensor event

Class l Derived from the CRC Cards: - Each card represents a class - Its responsibilities become attributes and methods l Sections: name, attributes, methods l BUT don’t provide any details for attributes and methods Name the Attributes Methods

Association l Focus on those associations for which knowledge of the relationship needs to be preserved for some duration (“need -to-know”) l It is more important to identify classes than to identify associations l Too many associations can be confusing l Classes may have association with themselves person * 1 manages q

Navigability l Navigability indicates that it is possible to move uni -directionally across the association from objects of the server to client class. l Indicated by an arrow head polls u l Implies visibility; usually attribute visibility. l For an object A to send a message to B. B must be visible to A.

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

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

Defining Subtypes l Additional Information: - The subtype has additional attributes of interest - The subtype has additional associations of interest l Additional Behaviour: - The subtype is operated upon, handled, reacted to, or manipulated differently than the supertype or other subtypes

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

Aggregation l A composite aggregation (filled diamond) means that the multiplicity at the composite end may be at most one. l Shared aggregation (hollow diamond) means that the multiplicity at the composite end may be more than one.

Aggregation Guidelines l There is an obvious physical or logical assembly l The part and composite have the same lifetime l Some properties of the composite propagate to the parts. Example: the limbs of a robot are offset from a common origin l Operations 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

Package Diagrams 6. Control panel l If the class diagram becomes too large it may be necessary to bundle it into packages. l Each package: - Provides a pointer to a more detailed class diagram - Represents a black box with well defined external associations

Example: Package Reference

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