Introduction to UML

1. Introduction to UML Course Instructor: Aisha Azeem

2. Specifying Introduction • UML stands for Unified Modeling Language. • It is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. Constructing Documenting Visualizing Communications Business Modeling

3. UML Building Blocks • Class: • Class represents set of objects having similar responsibilities. • Use case: • Use case represents a set of actions performed by a system for a specific goal. • Interaction: • Interaction is defined as a behavior that consists of a group of messages exchanged among elements to accomplish a specific task.

4. Cont . . . • State machine: • State machine is useful when the state of an object in its life cycle is important. • It defines the sequence of states an object goes through in response to events. Events are external factors responsible for state change. • Note: • A note is used to render comments, constraints etc of an UML element.

5. Cont . . . • Generalization: • Generalization can be defined as a relationship which connects a specialized element with a generalized element. It basically describes inheritance relationship in the world of objects. • Aggregation: • Whole part relationship i.e. large part “whole” contains one or more parts. E.g. building “whole” contains rooms ”parts” • Composition: • Is a relationship in which if the “whole” part dies, the child has to die as well. E.g. if building collapse , rooms no more exist

6. UML Models, Views, Diagrams • UML is a multi-diagrammatic language • Each diagram is a view into a model • Diagram presented from the aspect of a particular stakeholder • Provides a partial representation of the system • Is semantically consistent with other views • Example views

7. Models, Views, Diagrams

8. UML Diagrams • UML diagrams are the ultimate output of the entire discussion. • All the elements, relationships are used to make a complete UML diagram and the diagram represents a system. • UML includes the following nine diagrams • Class diagram • Object diagram • Use case diagram • Sequence diagram • Collaboration diagram • Activity diagram • State chart diagram • Deployment diagram • Component diagram

9. UML Modeling Types • Different diagrams are used for different type of UML modeling. • There are three important type of UML modeling : • Structural modeling: • Structural modeling captures the static features of a system. • They consist of the followings: Class diagrams , Objects diagrams , Deployment diagrams , Component diagram etc • Structural model represents the framework for the system and this framework is the place where all other components exist. • They all represent the elements and the mechanism to assemble them. • E.g. class written once remain same through out the execution.

10. Cont . . . • Behavioral Modeling: • Behavioral model describes the interaction in the system. • It represents the interaction among the structural diagrams. • Behavioral modeling shows the dynamic nature of the system • Activity diagrams , Interaction diagrams, Use case diagrams • Depends upon the behavior of an object/entity object can have more then one state, and depending upon its state its behavior would be different. • E.g. bank account may be working(deposit/ withdraw) Not working(closed/ dead)

11. Cont . . . • Dynamic Modeling: • The dynamic model is used to express and model the behavior of the system over time. • It includes support for activity diagrams, state diagrams, sequence diagrams • e.g. user login(id, password), valid tries to login , its set of sequences will be different as compared to an invalid user. 

12. Use-Case Diagram Use Case Diagram is used to describe the functionalities provided by a system and the users associated with that system. The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as "actors" and the processes are called "use cases." The Use case diagram shows which actors interact with each use case.

13. Use-Case Diagram • The main purpose of the use-case diagram is: • to help development teams visualize the functional requirements of a system • To help identify relationship of "actors" (human beings who will interact with the system) with essential processes • and understand the relationships among different use cases

14. Elements of a use-case diagram • Use-case diagrams contain the following elements: • Actors, which represent users of a system, including human users and other systems. • Use Cases, which represent functionality or services provided by a system to users.

15. Actor UML notation used to represent an actor • Definition: • The outside entity which communicates with the system: • A Person (user) • An external system • Physical Environment • An Actor has a unique name and an optional description • Symbol:

16. Actor (Example) • Consider the following scenario related to a “University Management System” : • In a university management system, a Student can submit the assignments, the instructor marks those assignments and then uploads the result. The Student is allowed to view the Results. • Now, by recalling the definition of actor, can you identify the actors in this System? • Student • Instructor

17. Instructor Actor (Example/2) Student Student is an external entity which interacts with the system. Student is a user of this system, as some services are used by it. Instructor is another external entity which interacts with the university management system. Student Instructor

18. Use-case Represent functionality or services provided by a system to users. It is a description of set of sequence of actions that a system perform that produces an observable result. A use case represents a class of functionality provided by the system as an event flow. Use cases describe the interaction between a primary actor and the system itself

19. Use-case UML notation used to represent a use-case The use case technique is used in software and systems engineering to capture the functional requirements of a system. Each use case describes how the actor will interact with the system to achieve a specific goal. One or more scenarios may be generated from each use case, corresponding to the detail of each possible way of achieving that goal. Symbol :

20. Use-case (Example) • Consider the same example again: • In a university management system, a Student can submit the assignments, the instructor marks those assignments and then uploads the result. The Student is allowed to view the Results. • Now, by recalling the definition of use-case, can you identify the use-cases in this System? • Submit Assignments • Mark Assignments • Upload Results • View Results

21. Use-case (Example/2) • The use-cases are linked with the functional requirements of this system. In this example : • Student submit the assignments. • Instructor marks the assignments. • Instructor upload the marks. • Student can view the marks. • It is now clear that how actors are interacting with different use-cases of this system. • Now, lets combine actors and use-cases in one diagram?

22. Symbols in Use-Case Diagrams ACTOR USE-CASE INTERACTION: denotes set of messages exchanged among objects NOTES/COMMENTS

23. Use-Case Diagram (University Management System) SYSTEM BOUNDARY Submit Assignments Mark Assignments Student Upload Results View Results Instructor Package: University Management System

24. Cont . . . • Other types of associations and relationships; • Generalization between use cases • Generalization between actors • Include relationship between use cases • Extend relationship between use cases

25. Generalization between Use cases • Represented by a line and a hollow arrow • From child to parent • A use case generalization shows that one use case is simply a special kind of another. • A child can be substituted for its parent whenever necessary. • Generalization appears as a line with a triangular arrow head toward the parent use case Parent use case Child use case

26. Example Register car sharer Transfer car sharer from web server Manually add car sharer CarMatch Administrator Web Server Example : ATM

27. Generalization between Actors (examples) student Foreign student Local student

28. Include relationship between use cases • Some times one use case includes the functionality of another use case. • Include relationship is drawn as an open arrow with dashed lines that points towards the use case that is being included • The word include is written in << . . . . . . >> Or • If x is a task and y is a sub task but acting as a part of it then use <<include >> stereotype • Arrowhead towards the subtask

29. Example

30. Extend relationship between use cases • There are occasions where one use case may optionally be extended by the functionality in another use case. • The relationship is drawn as an open arrow with dashed line the points towards the use case that is being extended. • The word extend is written in <<……..>> Or • If x is a task and y is a sub task of x but little bit different • Arrow head towards the main task

31. Passenger Purchase Ticket <<extends>> OutOfOrder <<extends>> TimeOut <<extends>> <<extends>> Cancel NoChange Example Take turn Driver <<extends>> <<extends>> Turn left Turn right

32. Practice • Read the following case : • Identify the actors • Identify (extract ) the use cases • Construct a proper use-case diagram (with proper symbols & notations)

33. Case-Study Consider the Library Management System of UOW. A Student is allowed to issue books for a period of two weeks. Student can read newspapers/magazines in the library and can even access the databases for e-books. The Library Staff is responsible for maintaining the records of students and along with the issued books. The Staff marks an entry in the register whenever a student issue or return a book. A fine is charged on a student if he/she fail to return the book on time. The Librarian is there to manage the staff, check the records and prepare reports for DG/DEAN.

34. Class diagrams • Gives a graphical representation of domain model. • It represents relationship of classes objects with object specification in detail. • It gives static view of the system • Each class is represented by a rectangle subdivided into three compartments • Name • Attributes • Operations

35. Class Diagram: Visibilities • Modifiers are used to indicate visibility of attributes and operations. • ‘+’ is used to denote Public visibility (everyone) • ‘#’ is used to denote Protected visibility (derived) • ‘-’ is used to denote Private visibility (no one) • By default, attributes are hidden and operations are visible. • The last two compartments may be omitted to simplify the class diagrams

36. Name Account_Name - Custom_Name - Balance Attributes +AddFunds( ) +WithDraw( ) +Transfer( ) Operations An example of Class

37. Other representations of class Boeing 737 Boeing 737 length: meter fuelCapacity: Gal doors: int Boeing 737 Boeing 737 length: meter lift() roll() lift ( ) fuelCapacity: Gal roll ( ) doors: int thrust ( )

38. Class Attributes (Cont’d) Person Attributes are usually listed in the form: attributeName : Type A derived attribute is one that can be computed from other attributes, but doesn’t actually exist. For example, a Person’s age can be computed from his birth date. A derived attribute is designated by a preceding ‘/’ as in: / age : Date name : String address : Address birthdate : Date / age : Date ssn : Id

39. Class Attributes (Cont’d) Person + name : String # address : Address # birthdate : Date / age : Date - ssn : Id Attributes can be: + public # protected - private / derived

40. Class Diagram: Association • Associations represent relationships between instances • of classes . • An association is a link connecting two classes. • Bi-directional associationAssociations are assumed to be bi-directional • Uni-directional associatione.g. Bank Account and person Person BankAccount Person BankAccount

41. Association: Multiplicity and Roles teaches learns from Student Instructor 1..* 1..* Multiplicity Symbol Meaning 1 One and only one 0..1 Zero or one M..N From M to N (natural language) * From zero to any positive integer 0..* From zero to any positive integer 1..* From one to any positive integer Note: if no multiplicity is given it is assumed to be 1 Association name: represents nature of participants classes in a relationship. Association Role: role played by the participant class

42. Notation of Class Diagram: Generalization Supertype Student Employee Person Subtype2 Subtype1 TeachingAssistant Generalization expresses a relationship among related classes. It is a class that includes its subclasses. Student

43. Separate target style Vehicle Bus Truck Car Shared target style BoeingAirplane Boeing 737 Boeing 757 Boeing 767 Cont . . .

44. Automobile windows Engine COMPOSITION Notation of Class Diagram: Composition Whole Class Class W • Composition: expresses a relationship among instances of related classes. • It is a specific kind of Whole-Part relationship. • It expresses a relationship where an instance of the Whole-class has the responsibility to create and initialize instances of each Part-class. Composition should also be used to express relationship where instances of the Whole-class have exclusive access to and control of instances of the Part-classes. ClassP2 ClassP1 Part Classes Example

45. Cont . . . Car 1 1 1 1 4 4, 10 2, 5 1 Wheel Light Door Engine

46. Notation of Class Diagram: Aggregation Container Class AGGREGATION ClassC Aggregation: expresses a relationship among instances of related classes. It is a specific kind of Container-Containee relationship. It expresses a relationship where an instance of the Container-class has the responsibility to hold and maintain instances of each Containee-class Aggregation is appropriate when Container and Containees have no special access privileges to each other. Class E2 Class E1 Containee Classes Example Bag Milk Apples

47. 1 * Consists Of Team Player class Cont. . .

48. Aggregation vs. Composition • Composition is really a strong form of aggregation • components have only one owner • components cannot exist independent of their owner; • both have coincident lifetimes • components live or die with their owner • e.g. (1)Each car has an engine that can not be share with other car • (2) If the polygon is destroyed, so are the points. • Aggregations may form "part of" the aggregate, but may not be essential to it. • They may also exist independent of the aggregate. Less rigorous than a composition • e.g. (1)Apples may exist independent of the bag. • (2)An order is made up of several products, but the products are still there even if an order is cancelled.

49. Class Diagram example class Name Order Multiplicity: mandatory -dateReceived Attributes * Customer -isPrepaid 1 -number :String -name -price : Money -address Association +dispatch() Operations +creditRating() : String() +close() 1 Generalization Corporate Customer Personal Customer -contactName -creditCard# -creditRating -creditLimit Multiplicity: Many value +remind() +billForMonth(Integer) * Multiplicity: optional 0..1 Employee * OrderLine -quantity: Integer 1 * Product -price: Money -isSatisfied: Boolean

50. Interaction Diagrams • In object oriented systems, tasks are performed by objects interacting with other by passing messages. • In UML this interaction is provided by sequence diagrams. • Class diagrams model static nature of system • Interactions diagrams model the dynamic nature of system and emphasis the order of the message over time