1. ITEC0724 Modern Related Technology on Mobile Devices Lecture Notes #2 suronape@mut.ac.th 1

2. Class Diagrams 2  Class Diagram shows the static design view of a system.  Class Diagram consists of a set of classes and/or interfaces, and their relationships.  Class diagrams can be used to do forward and reverse engineering.

3. Example 3

4. Classes 4  The most important parts of an class are  Name  Attributes  Operations

5. Names 5  Every class must have a unique name.  A name is a textual string.  The name may be a simple name or a qualified name.

6. Attributes 6  An attribute is a named property of a class that describes a range of values that instances of the property may hold.  A class may have any number of attributes or no attributes at all.

7. Operations 7  An operation is the implementation of a service that can be requested from any object of the class to affect the behavior.  A class may have any number of operations or no operations at all.

8. Visibility 8  In the UML, you can specify any of four levels of visibility:  public  protected  private  package  In your design, you should only expose the features that are necessary to carry out responsibilities (information hiding).

9. Instance and Static Scope 9  For each attribute, its scope specifies whether each instance of the attribute has …  its own distinct value,  or just a single value shared by all instances of the class  For operation, static are used for operations that are like global procedure or operations that manipulate static attributes.

10. Abstract, Leaf, and Polymorphic Elements 10

11. Multiplicity 11

12. Final Hints and Tips 12  When you model classifiers in UML, a well- structured classifier:  Has both structural and behavioral aspects.  Is tightly cohesive and loosely coupled.  Exposes only those features necessary for clients to use the class and hide all others.  Is unambiguous in its intent and semantics.  Is not over-specified and under-specified. .

13. Relationship 13  In object-oriented modeling, there are four kinds of relationships that are important:  Dependencies represent using relationships among classes.  Generalizations links generalized classes to their specializations  Associations represent structural relationships among objects.  Realization specifies contract and the one that guarantees to carry out.  When you build webs of relationships in your model, if you over-engineer, you’ll end up with a mess of relationships. If you under-engineer, you’ll miss a lot of richness of your system.

14. Example 14

15. Dependencies 15  A dependency is a relationship that states that one thing uses the information and services of other things.  Most often, you use dependencies between classes to show that one class uses operations from another class or it uses variables or arguments typed by the other class.  It’s a using relationship.  There may be a stereotype on the relationship to tell different flavors of dependency including bind, derive, permit, instanceOf, instantiate, powertype, refine, use, import, access, extend, include, send, and trace.

16. Modeling Simple Dependencies 16  Create a dependency pointing from the class with the operation to the class used as a parameter in the operation.

17. Generalizations 17  A generalization is a relationship between a general kind of thing and a more specific kind of thing.  The general kind can be called the superclass, base class or parent.  The specific kind can be called the subclass or child.  Generalization is sometimes called an “is-a-kind-of” relationship.

18. Generalization Properties 18  A child inherits the properties of its parents. Often,, the child has its own attributes and operations.  An implementation of an operation in a child overrides an implementation of the same operation of the parent.

19. Associations 19  An association is a structural relationship that specifies that objects of one thing are connected to objects of another.  Given an association connecting two classes, you can relate objects of one class to the other class.

20. Associations (2) 20  An association that connects exactly two classes is called binary association.  It’s legal to have both ends of an association circle back to the same class, which is called self association.  You can have associations that connect more than two classes; these are called n-ary associations.

21. Associations (3) 21

22. Associations (4) 22  There are adornments that apply to associations.  Name  Role  Multiplicity  Aggregation  Composition  Navigation

23. Associations (5) 23

24. Associations (6) 24  Composition is a stronger form of aggregation.  Aggregation simply specify a whole-part relationship.  Composition means a strong ownership. Part must also be removed when whole does not exist.  Whole is responsible for decomposition of parts.

25. Association (7) - Navigation 25  You can explicitly specify the direction of navigation of association relationship.  Navigation means that you can easily get objects at the other end, given the object at the source end.  It does not mean that you will not ever get objects for the opposite direction.

26. Drawing Styles 26  Typically, modelers choose one of two styles for drawing lines.  Oblique lines at any angle.  Rectilinear lines drawn parallel to the sides of the page.  Most line crossings should be avoided. If a line crossing is necessary, a small arc can be used to indicate line crossing.

27. Modeling Structural Relationships 27  With associations, you are modeling classes that are peers of one another.  Given an association between two classes, you can often navigate in either direction.

28. Modeling Structural Relationships 28  To model structural relationships:  For each pair of classes, look whether you need to navigate from objects of one to the another.  For each association, specify multiplicity and role names.  If the association is a whole-part relationship, mark it as an aggregation.  When part totally depends on whole, make it as a composition.

29. Modeling Structural Relationships 29

30. Realization Relationship 30  Realization is a relationship between a classifier that specifies contract and the one that guarantees to carry out.  Most of the time, realization is used between interface and class, or between use case and collaboration.

31. Realization Relationship Example 31

32. Modeling relationships 32  When you model relationships,  Apply use cases and scenarios to discover relationships.  Start at structural relationships.  Next, find opportunities for generalizations. Avoid multiple inheritance.  Then, look for dependencies.  Start with basic form and use advanced feature only necessary.  You may use several diagrams to focus on different views.

33. Final Hints and Tips 33  Use associations for structural relationships.  Use generalization if you have an “is-a-kind-of” relationship or class with common attributes or operations.  Beware of cyclical generalization relationships.  Keep your generalization relationships balanced. Inheritance should not be too deep nor too wide.  Use dependencies only for other using relationships.  Use Realization for class and interface

34. How to find class  Responsibility  CRC Cards  Use case analysis  Find the noun in use cases  Common classes for a particular context

35. Common Uses of Class Diagram 35  When you model the static design view of a system, you typically use class diagrams in the following ways:  To model the vocabulary of a system  To model a logical database schema

36. Modeling the Vocabulary of a System 36  Identify those things that users or implementers use to describe the problem or solution. Use use case- based analysis to find these abstractions.  Provide the attributes and operations that are needed to carry out these responsibilities for each class.

37. Modeling the Distribution of Responsibilities in a System 37  Make sure that your abstractions provide a balanced set of responsibilities.  You don’t want one class to be too big or too small.  Each class should do one thing well.  If class is too big, the models will be hard to change and are not very reusable.  If class is too small, there will be too many abstractions than you can manage or understand.

38. Common Steps to Manage Distribution of Responsibilities 38  Identify a set of classes that work together closely to carry some behavior.  Identify a set of responsibilities for each class.  Look at this set of classes as a whole  Split classes that have too many responsibilities.  Collapses tiny classes that have trivial responsibilities.  Reallocate responsibilities so that each abstraction reasonably stands on its own.

39. Modeling a Logical Database Schema 39  Many of the systems you’ll model will have persistent objects.  The UML’s class diagrams are comparable to E-R diagrams, except that they have operations in addition.  To model a schema,  Identify classes in your model that must go beyond the application lifetime.  Create a class diagram that contains these classes.  Expand the details of the classes.  Watch for things that will complicate the database design.

40. Example 40