Classes, Relationships, and Common Mechanisms

1. Classes, Relationships, and Common Mechanisms 主講人 : 劉建宏

2. Outline • Classes • Relationships • Common Mechanisms • adornments : notes • extensibility mechanisms : • stereotype • tagged value • Constraint • Example : ATM

3. Classes • Modeling a system involves identifying the things that are important to your particular view. These things form the vocabulary of the system you are modeling. • In the UML, all of these things are modeled as classes. A class is an abstraction of the things that are a part of your vocabulary. • A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. • In UML, a class is rendered as a rectangle. It contains name, attributes, and operations.

4. Name, Attribute, and Operation • Every class must have a name that distinguishes it from other classes. A name is a textual string.(p.49) • An attribute is a named property of a class that describes a range of values that instances of the property may hold. Therefore, an attribute is an abstraction of the kind of data or state an object of the class might encompass.(p.50) • An operation is the implementation of a service that can be requested from any object of the class to affect behavior. An operation is an abstraction of something you can do to an object and that is shared by all objects of that class.(p.51)

5. Responsibilities • When you model classes, a good starting point is to specify the responsibilities of the things in your vocabulary. • A responsibility is a contract or an obligation of a class. • At an abstract level, the class’s attributes and operations are the class’s responsibilities. • Ref. p.53

6. CRC Card • Class-Responsibility-Collaborator Card Class Name 1st responsibility collaborate with some class collaborate with some class 2nd responsibility

7. Class Example name Shape originX : int originY : int color : Color = NULL attributes move(x:int, y:int) getColor():Color display() operations responsibilities Responsibilities -- maintain the information, such as coordinates, color -- draw the shape

8. Relationships • In OO modeling, there are three kinds of relationships: • Dependencies • Generalizations • Association

9. Dependency, Generalization, and Association • A dependency is a using relationship that states that a change in specification of one thing may affect another thing that uses it. (p.63) • Use dependencies when you want to show one thing using another. • A generalization is a relationship between a general thing (superclass or parent) and a more specific kind of that thing (subclass or child).(p.64) • An association is a structural relationship that specifies that objects of one thing are connected to objects of another.(p.65) • Use association when you want to show structural relationships.

10. The adornments of association • There are four adornments that apply to associations: • Name : We can use name to describe the nature of the relationship. (p.66) • Role : A class has a specific role that it plays in that relationship. (p.66) • Multiplicity : It’s important for us to state how many objects may be connected across an instance of an association. We can show a multiplicity of exactly one (1), zero or one (0…1), many (0…*), or one or many (1…*). (p.67) • Aggregation : To Model a “whole/part” relationship, in which one class represents a larger things (the “whole”), which consists of smaller things (the “part”). It’s a “has a” relationship. (p.67)

11. Relationships Window dependency open() close() move() display() handleEvent() Event association multiplicity generalization Button Edit 1 * ConsoleWindow DialogBox Control transfer input handler receiver Combo name Static aggregation role name direction

12. Dialog

13. Common mechanisms • There four common mechanisms in the UML : • Specifications • Adornments • Common divisions • Extensibility mechanisms • We will explain adornments and extensibility mechanism : • Notes are the most important kind of adornment. • Extensibility mechanisms include stereotype, tagged values, and constraints.

14. Note • A note is a graphical symbol for rendering constraints or comments attached to an element or a collection of elements. (p.78) simple text embedded URL link to document Publish this component in the project repository after the next design review. See http://www.gamelan.com for an example of this applet. See encrypt.doc for details about this algorithm

15. Stereotype, Tagged Value, and Constraint • A stereotype is an extension of the vocabulary of the UML, allowing you to create new kinds of building blocks similar to existing ones but specific to your problem. (p.80) • A tagged value is an extension of the properties of a UML element, allowing you to create new information in that element’s specification. (p.81) • A constraint is an extension of the semantics of a UML element, allowing you to add new rules or to modify existing ones. (p.82)

16. Extensibility Mechanisms EventQueue{ version = 3.2 author = egb } <<exception>> Overflow { ordered } add() remove() flush() stereotype tagged value constraint p.30 figure 2-19

17. Summary of Extensibility Mechanisms • Finally, we can say : (p.75) • Notes model comments. • Stereotypes model building blocks. • Tagged value model properties. • Constraints model semantics.

18. Example : ATM Use Case Classes 顧客 提款 inputCard() inputPW() inputMoney() 密碼 顧客 存款 金額 櫃員機 金融卡 查詢餘額 checkCard() checkPW () getMoney()