1. Basic Structural Modeling Pertemuan ke 4 Classes

2. Sung Kim CS6359 Slide 2 Overview Classes – Attributes – Operations – Responsibilities Modeling the vocabulary of a system. Modeling the distribution of responsibilities. Modeling non-software “things”. Modeling primitive types. Modeling quality abstractions.

3. Class Vs Objek

4. Sung Kim CS6359 Slide 4 Classes Description of a set of objects that share the same attributes, operations, relationships, and semantics. Window origin size open() close() name attributes operations

5. Sung Kim CS6359 Slide 5 Names Distinguishing identity. Textual string. Simple name. Prefixed by package name to generate path name. Customer Account Temperature Sensor Circuit Java::awt::Rectangle Simple names path name

6. Sung Kim CS6359 Slide 6 Name Rules Consists of letters, numbers, and certain punctuation marks. Short noun phrases drawn from vocabulary of the domain. First letter of every word capitalized. TemperatureSensor BrokerageAccount

7. Sung Kim CS6359 Slide 7 Attributes Named property of a class. Describes a range of values that an instance of the property may hold. Short noun representing property of its enclosing class. First letter of every word capitalized except the first. birthDate userAccount

8. Sung Kim CS6359 Slide 8 Attributes (cont’d) attributes height : Float width : Float isStudent : Boolean = false origin size You can further specify an attribute by stating its class and possibly a default initial value

9. Sung Kim CS6359 Slide 9 Operations Abstraction of something that can be done to an object. Shared by every object of the same class. May cause object to change state. Short verb representing behavior of representing class. First letter of every word capitalized except the first. addUser() isEmpty()

10. Sung Kim CS6359 Slide 10 Operations (cont’d) operations reset() setAlarm( t : Temperature ) value() : Temperature add() move() You can specify an operation by stating its signature, covering the name, type and default value of all parameters and a return type

11. Sung Kim CS6359 Slide 11 Organizing Only a subset of attributes and operations are typically relevant to any one view. Elide a class; hide non-relevant information. Use stereotypes to categorize. Use ellipsis to specify additional attributes or operations > new() new( p : Policy ) > process( o : Order ) … > isSuspect( o : Order )

12. Sung Kim CS6359 Slide 12 Responsibilities Contract or obligation of a class. Carried out by attributes and operations. Techniques – CRC cards (Class-Responsibility-Collaborator); Kent Beck and Ward Cunningham; ’89 – Use case based analysis.

13. Sung Kim CS6359 Slide 13 Responsibilities (cont’d) Free-form text; one phrase per responsibility. Responsibilities -- determine the risk of a customer order -- handle customer-specific criteria for fraud FraudAgent responsibilities

14. Sung Kim CS6359 Slide 14 Modeling Techniques Vocabulary. Distribution of responsibilities. Non-software things. Primitive types.

15. Sung Kim CS6359 Slide 15 Modeling Vocabulary Things used to describe the problem or solution. Found through CRC cards and/or use case analysis. Identify responsibilities for each abstraction. Provide attributes and operations needed to carry out responsibilities.

16. Sung Kim CS6359 Slide 16 Modeling Distribution of Responsibilities Identify a set of classes that work together to carry out some behavior. Identify responsibilities for each class. Split classes with too much responsibility. Collapse classes with trivial responsibility. No class should do too little or too much.

17. Sung Kim CS6359 Slide 17 Modeling Non-software Things Model the thing as a class. Use stereotypes to give a distinctive cue. Consider nodes to model hardware. Use a unique icon.

18. Sung Kim CS6359 Slide 18 Modeling Primitive Types Model as a type using a class notation. Use stereotypes as necessary. Use constraints to represent valid values. > Boolean false true > Int { value range –2**31 to +2**31-1 }

19. Sung Kim CS6359 Slide 19 Hints & Tips Well-structured class – Provides a crisp abstraction drawn from vocabulary of problem or solution. – Embodies small, well-defined set of responsibilities. – Provides clear separation of the abstractions specification and implementation. – Understandable and simple. – Extensible and adaptable.

20. Sung Kim CS6359 Slide 20 Hints & Tips (cont’d) Drawing a UML class – Show only properties that are important in a specific context. – Organize long lists of attributes and operations by grouping. – Show related classes in the same diagrams.

21. Sung Kim CS6359 Slide 21 Summary Classes – Name. – Attributes. – Operations. – Responsibilities. Modeling techniques. – Vocabulary. – Responsibilities. – Non-software things. – Primitive types.

22. Basic Structural Modeling Class Diagrams

23. Sung Kim CS6359 Chapter 8Slide 23 Overview Modeling simple collaborations. Modeling a logical database schema. Forward and reverse engineering.

24. Sung Kim CS6359 Chapter 8Slide 24 Class Diagram Typical Contents – Classes – Interfaces – Collaborations – Relationships Dependencies Generalizations Associations – Notes

25. Sung Kim CS6359 Chapter 8Slide 25 Class Diagram Uses Model static design view of a system. – Vocabulary of the system. – Collaborations – Logical database schema.

26. Sung Kim CS6359 Chapter 8Slide 26 Modeling Simple Collaborations Identify the mechanism to be modeled; a mechanism represents some function or behavior. For each mechanism, identify the classes, interfaces, and other collaborations that participate in this collaboration. Identify the relationships among those entities. Use scenarios to walk through the model.

27. Sung Kim CS6359 Chapter 8Slide 27 Example Collaboration

28. Sung Kim CS6359 Chapter 8Slide 28 Modeling a Logical Database Identify classes whose state must be persistent. Create a class diagram using standard tagged value. Expand to include structural details, specifically attributes and associations. Identify common patterns which cause database problems; create intermediate abstractions if necessary. Use tools if available to transform logical design into physical design.

29. Sung Kim CS6359 Chapter 8Slide 29 Example Logical Database

30. Sung Kim CS6359 Chapter 8Slide 30 Forward Engineering Forward engineering—the process of transforming a model into code through a mapping to an implementation language. Steps – Identify the rules of mapping to a specific language. – Constrain use of UML to match language semantics (e.g. inheritance). – Use tagged values to identify language. – Use tools when possible.

31. Sung Kim CS6359 Chapter 8Slide 31 Example Forward Engineering public abstract class EventHandler { private EventHandler successor; private Integer currentEventId; private String source; EventHandler() {} public void handleRequest() {} }

32. Sung Kim CS6359 Chapter 8Slide 32 Reverse Engineering Reverse engineering—the process of transforming code into a model through mapping from a specific implementation language. Steps – Identify the rules of mapping from a specific language. – Use a tool; point the tool to the code. – Query the model to obtain desired information for the model.

33. Sung Kim CS6359 Chapter 8Slide 33 Hints & Tips Separate your analysis models from your design models. – Different levels of abstraction. – Different contextual vocabulary. Elements of a well-structure class diagram. – Focused on one aspect of a system’s static design view. – Contains only essential elements for that aspect. – Provides sufficient details for the level of abstraction.

34. Sung Kim CS6359 Chapter 8Slide 34 Hints & Tips (cont’d) Give diagrams a name that communicates their purpose. Diagram layout. – Minimize crossing of arcs. – Co-locate semantically related elements. – Use notes and color as visual cues. – In general one relationship type will dominate each diagram; don’t confuse the issue.

35. Sung Kim CS6359 Chapter 8Slide 35 Summary Class diagram contents. Modeling simple collaborations. Modeling logical databases. Forward engineering Reverse engineering.

36. Advanced Structural Modeling Advanced Classes

37. Sung Kim CS6359 Chapter 9Slide 37 Overview Classifiers Advanced notations Special properties – Attributes – Operations Template Classes

38. Sung Kim CS6359 Chapter 9Slide 38 Advanced UML Notations

39. Sung Kim CS6359 Chapter 9Slide 39 Classifiers Classifier—mechanism that describes structural and behavioral features. ClassesComponents InterfacesNodes Data typesUse cases SignalsSubsystems

40. Sung Kim CS6359 Chapter 9Slide 40 Classifier Examples

41. Sung Kim CS6359 Chapter 9Slide 41 Visibility Public—access allowed for any outside classifier with visibility to the given classifier (+). Protected—access allowed for any descendant of the classifier (#). Private—access restricted to the classifier itself (-).

42. Sung Kim CS6359 Chapter 9Slide 42 Scope Instance—each instance of the classifier holds its own value. Classifier—one value is held for all instances of the classifier (underlined). header : FrameHeader uniqueID : Long Frame class scope instance scope

43. Sung Kim CS6359 Chapter 9Slide 43 Generalization

44. Sung Kim CS6359 Chapter 9Slide 44 Multiplicity Constraint on the number of instances of a class or attribute. consolePort [ 2..* ] : Port NetworkController 1 ControlRod 3 multiplicity could be singleton

45. Sung Kim CS6359 Chapter 9Slide 45 Attributes Syntax [ visibility ] name [ multiplicity ] [ : type ] [ = initial-value ] [ {property-string } ] property-string – changeable—no restrictions (default) – addOnly—values may not be removed or altered, but may be added – frozen—may not be changed after initialization

46. Sung Kim CS6359 Chapter 9Slide 46 Attributes (cont’d) Examples originName only + originVisibility and name origin : PointName and type head : *ItemName and complex type name [ 0..1 ] : StringName, multiplicity, and type origin : Point = { 0, 0 }Name, type, and initial value id : Integer { frozen }Name and property

47. Sung Kim CS6359 Chapter 9Slide 47 Operations Syntax [ visibility ] name [ (parameter-list ) ] [ : return-type ] [ (property-string) ] parameter-list syntax [ direction ] name : type [ = default-value ] direction – in—input parameter; may not be modified – out—output parameter; may be modified – inout—input parameter; may be modified

48. Sung Kim CS6359 Chapter 9Slide 48 Operations (cont’d) property-string – isQuery—state is not affected – sequential—not thread safe – guarded—thread safe (Java synchronized) – concurrent—typically atomic; safe for multiple flows of control

49. Sung Kim CS6359 Chapter 9Slide 49 Template Classes Parameterized element

50. Sung Kim CS6359 Chapter 9Slide 50 Summary Classifiers Visibility Scope Multiplicity Attributes Operations Template Classes