Unified Modeling Language (UML)

1. Unified Modeling Language(UML)

2. What is a Model? A model is a simplification of reality. A model may provide • blueprints of a system • Organization of the system • Dynamic of the system

3. Why We Model • Model is built to • Communicate the desired structure and behavior of the system • Visualize and control the system’s architecture • Better understand the system that being built • Manage risk • Expose opportunities for simplification and reuse

4. Why We Model • We build models so that we can see and better understand the system we are developing.

5. Importance of Modeling • Models help us • to visualize a system as it is or as we want it to be. • to specify the structure or behavior of a system. • in providing a template that guides us in constructing a system. • in providing documenting the decisions we have made.

6. Objected-Oriented Modeling • Two most common ways in modeling software systems are • Algorithmic • Procedures or functions • Object oriented • Objects or classes

7. What is UML? • Stands for Unified Modeling Language • UML is a language for • Visualizing • Specifying • Constructing • Documenting

9. 1. Class Diagram • A class diagram describes the types of objects in the system and the various kinds of static relationships that exist among them • A graphical representation of a static view on static elements • A central modeling technique that is based on object-oriented principles

10. Objects and Classes

11. Objects • Each of object has a unique identity. • The state of an object is composed of a set of fields (data fields), or attributes. • Each field has a name, a type, and a value. • Behaviors are defined by methods. • Each method has a name, a type, and a value. • Each method may or may not return a value. • Features are a combination of the state and the behavior of the object.

12. Classes • A class defines a template for creating or instantiating its instances or objects. • A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics.

13. Classes • A class defines -- • the names and types of all fields • the names, types, implementations of all methods • The values of the fields are not defined or fixed in the class definition. • Each instance of the class has its own state. • Different instances of the class may have different states. • The implementations of methods are defined in the class definition and fixed for a given object.

14. Example Class name: Point class Point { Fields: x, y int x, y; Method: move public void move (int dx, int dy){ // implementation }

15. UML Notation for Classes

16. Field Declaration • The name of the field is required in the field declaration. • Field declaration may include: [Visibility][Type]Name[[Multiplicity]][=InitialValue] [Visibility]Name[[Multiplicity]][:Type][=InitialValue] • Visibility or accessibility defines the scope: • Public -- the feature is accessible to any class • Protected -- the feature is accessible to the class itself, all the classes in the same package, and all its subclasses. • Package -- the feature is accessible to the class itself and all classes in the same package. • Private -- the feature is only accessible within the class itself.

17. Visibility syntax in Java and UML

18. Examples

19. Method Declaration • The name of the method is required in the method declaration. • Method declaration may include: [Visibility][Type]Name([Parameter, ...]) [Visibility]Name([Parameter, ...])[:Type] • Each parameter of a method can be specified by -- Type Name

20. Examples

21. Example

22. UML Notation for Object

23. Examples

24. Message Passing orMethod Invocation • Objects communicate with one another through message passing. • A message represent a command sent to an object -- recipient • A message consists of the receiving object, the method to be invoked and the arguments to method.

25. Example

26. Modeling Relationships and Structures • A class diagram consists of • A set of nodes that represent classes and interfaces • A set of links represent relationships among classes • Class diagrams can be used to model: • Inheritance -- extension and implementation • Association -- aggregation and compostion • Dependency

27. Inheritance • Define a relationship among classes and interfaces • Inheritance model -- the is-a(n) relationship

28. Example

29. Association • Association represents binary relationship between classes * enroll * Student Course advisee * * teach 1 1 Faculty adviser

30. Aggregation and Compositon • Aggregation is a special form of association • Has-a or part-whole relationship • Composition is a stronger form of aggregation

31. Example 1 1 1 * * * University College Department Student 1 1 Chairman-of Member-of 1 1..* Faculty

32. Dependency • Dependency is a relationship between entities such that the proper operation of one entity depends on the presence of the other entity, and changes in one entity would affect the other entity.

33. Example

34. 2. Sequence diagram Depict object interaction by highlighting the time ordering of method invocation

35. Example

37. Object • Object naming: • syntax: [instanceName][:className] • Name classes consistently with your class diagram (same classes). • Include instance names when objects are referred to in messages or when several objects of the same type exist in the diagram. • The Life-Linerepresents the object’s life during the interaction

38. Messages • An interaction between two objects is performed as a message sent from one object to another • A message is represented by an arrow between the life lines of two objects.

39. Return Values • Optionally indicated using a dashed arrow with a label indicating the return value.

40. Object Creation • An object may create another object via a <<create>> message.

41. :A :B <<destroy>> Object Destruction • An object may destroy another object via a <<destroy>> message. • An object may destroy itself. • Avoid modeling object destruction unless memory management is critical.

42. [ok] borrow(member) Control information • Condition • syntax: ‘[‘ expression ’]’ message-label • The message is sent only if the condition is true • example: • Iteration • syntax: * [ ‘[‘ expression ‘]’ ] message-label • The message is sent many times to possibly multiple receiver objects.

43. 3. Use Case Diagram • Use cases describes the externally observable behavior of system functions in the form of interactions between the system to be developed and the external entities -- Actors. • Actors may represent roles played by users of the system or other systems. • Consist of a name and scenarios • One of scenarios is the main scenario

44. Use Case Diagram • Consist of: • Use cases • Actors • Relationships among actors and use cases

45. Extension relationships among actors

46. Dependency relationships among use cases

47. Case Study: An E-Bookstore