Lesson 11. W.C.Udwela Department of Mathematics & Computer Science

Size: px

Start display at page:

Download "Lesson 11. W.C.Udwela Department of Mathematics & Computer Science"

Angelica Cathleen Craig
5 years ago
Views:

1 Lesson 11 INTRODUCING UML W.C.Udwela Department of Mathematics & Computer Science

2 Why we model? Central part of all the activities We build model to Communicate Visualize and control Better understand the system suppose Manage risk

rises to help their users visualize the final product We may even build

3 Success of the Dream House Modeling is a proven and wellaccepted engineering technique We build architectural models of houses and high rises to help their users visualize the final product We may even build mathematical models in order to analyze the effects of winds or earthquakes on our buildings

4 UML Requirements & Analysis Design & Construction

5 Cont The Unified Modeling Language (UML) is a standard language for writing software blueprints UML Ref. The UML is a language for Visualizing The UML is a language for Specifying The UML is a language for Constructing The UML is a language for Documenting

6 Learning Path to UML Learn three major elements of UML language Basic building blocks The rules that dictate how those building blocks may be put together Some common mechanisms that apply thorough out the UML Once you grasp these ideas, you will be able to read UML models and create some basic ones. As you gain more experience in applying UML, you can build conceptual models using more advance features of the UML.

7 Diagrams dynamic static Diagrams Case study Class diagram Object diagram Use case diagram Sequence diagram Collaboration diagram Statechart diagram Activity diagram Component diagram Deployment diagram An class object diagram diagram shows shows a set a set of of A classes, objects use case and interfaces, diagram their relationships. and shows a set of use collaborations and their relationships. Object cases diagrams and actors represent (a special static kind of A snapshots class) component and of their diagram instances relationships. shows the An An interaction diagram of shows the an organizations activity diagram and dependencies is a special kind of These things interaction, Use case found diagrams diagrams consisting in class are address diagrams. the of a most set the of among A a deployment statechart a set of diagram components. shows that shows a the static A the common objects state configuration collaboration These flow use machine, from and diagrams case their activity of view consisting diagram run-time relationships, address found of to a activity is in system. of an states, the static These interaction within modeling including transitions, Component processing design a diagrams the view system. object-oriented events, nodes diagrams messages or static are and that especially the address activities. that process systems. may the view important emphasizes be static components dispatched implementation in organizing the that among structural live on them. and view them. modeling of a of a system as do class diagrams, the organization Activity Statechart system. diagrams diagrams Class but behaviors of from diagrams the perspective of the address address system. objects address that the the Interaction of the real static the send dynamic Deployment and view receive of diagrams of a system. messages. address or the design prototypical dynamic They static deployment are view view related cases of a of system. a to view system. class of diagrams an They in Sequence They are diagrams and in architecture. that are a component especially important typically maps in A Class sequence diagrams diagram that include is collaboration modeling to one or the more diagrams function behavior classes, of are of a interfaces, an system active classes interaction address diagram the static that isomorphic, and interface, or They collaborations. emphasize are class, related meaning the or to collaboration flow that component of you control process can view emphasizes of a system the time-ordering of take among and diagrams one objects and in that transform the a node event-ordered it typically into the messages other. behavior encloses of one an or object more components.

9 USE CASE Diagram Identifying Actors Actors represent external entities that interact with the system. An actor can be human or an external system

10 Cont Questions for identifying Actors Which user groups are supported by the system to perform their work? Which user groups execute the system s main functions? Which user groups perform secondary functions, such as maintenance and administration? With what external h/w or s/w system will the system interact?

11 Cont Once the actors are identified, the next step is to determine the functionality that will be accessible to each actor. This information can ne extracted using scenarios and formalized use cases.

12 Cont A scenario is a concrete, focused, informal description of a signal feature of the system from the viewpoint of a single actor Can not replace use cases as they focus on specific instances and concrete events Scenarios can not contain descriptions of decisions

13 Cont Questions for identifying scenarios What are the tasks that the actor wants the system to perform? What information does the actor access? Who creates that data? Can it be modified or removed? By whom? Which external change does the actor need to inform the about? How often? When? Which events does the actor need to inform the system about? With what latency?

14 USE CASE Diagram Once developers have identified and described actors and scenarios, they formalized scenarios into use case. Use case specify all possible scenarios for a Use case specify all possible scenarios for a given pies of functionality.

15 Simple use cases writing guide Use case should be named with verbs (What the user is trying to accomplish) Actor should be named with noun phrases Boundary should be clear (Steps accomplished by user and system should distinguished) Flow of event should phrased in the active voice Use case should describe the complete use transaction

16 Cont Exception should be described separately Use case should not describe the interface of the system Use case should not exceed two or three Use case should not exceed two or three pages in length. Otherwise use include and extend relationships to decompose it in smaller use cases.

17 Cont Identifying relationships among Actors and Use Cases Communication relationship between actors and use cases

18 Cont Extend relationship between use cases A use case extends another use case if the extended use case may include the behavior of the extension under certain conditions.

19 Cont Advantages of separating exceptional and optional flows of evens from the base use case Base use case becomes shorter and easier to understand The common case is distinguished from the exceptional case which enables developers to treat each type of functionality differently

20 Cont Include relationships between use cases Redundancies among use cases can be factored out using include relationships Assume Dispatcher needs to consult the city map when opening an incident and when allocating resources. In this case ViewMap use case describes the flow of evens required when viewing the city and is used by both the OpenIncident and the AllocateResources use cases

21 Cont Heuristics for extend and include relationships Use extend relationships for exceptional, optional, or seldom-occurring behavior. Use Include relationships for behavior that is shared across two or more use cases

22 From Use Case to Objects Identifying Entity Objects Participating objects form the basis of the analysis model. Part of Speech Model component Examples Proper Noun Instance Kamla Common Noun Class Field officer Doing Verb Operation Creates, submits. Selects Being Verbs Inheritance Is a kind of, is one of either Having verb Aggregation Has, Consist of, includes Modal verb Constraints Must be Adjectives Attributes Incident Description

23 Class Diagram What is a class diagram? A class diagram describes the types of objects in the system and the various kinds of static relationships that exist among them Essential Elements of a UML Class Diagram Class Attributes Operations Relationships Associations Generalization Dependency Realization Constraint Rules and Notes

24 Objects Objects have three responsibilities: What they know about themselves (e.g., Attributes) What they do (e.g., Operations) What they know about other objects (e.g., Relationships)

25 Class A class is the description of a set of objects having similar attributes, operations, relationships and behavior. Class Name Attributes Operation s Objects

26 Relationships Generalization (Class-to-Class) (Superclass/Subclass) Inheritance Ex: Person - FacultyPerson, StudentPerson, Staff... Ex: ModesOfTravel - Airplane, Train, Auto, Cycle, Boat... [Object] Associations FacultyInformation - CourseInformation StudentInformation - CourseInformation [Object] Aggregations & Composition (Whole-Part) Assembly - Parts Group - Members

27 Generalization (Class-to-Class) (superclass subclass; supertype subtype) A Generalization follows a is a or is a kind of heuristic from a specialization class to the generalization class. (e.g., student is a person, video is a kind of inventory). Common attributes, operations and relationships are located in the generalization class and are inherited by the specialization classes Unique attributes, operations and relationships are located in the specialization classes. Inherited attributes and operations may be overridden or enhanced in the specialization class depending on programming language support. Inherited operations in the specialization classes may be polymorphic. Only use when objects do NOT transmute (add, copy, delete) Multiple inheritance is allowed in the UML but can complicate the class model s understanding and implementation (e.g., C++ supports but Java and Smalltalk do not).

28 Generalization Example <<abstract>> Role attributes operations Student attributes operations Staff attributes operations Visitor attributes operations Note: <<abstract>> = no objects

29 Generalization Inheritance Common Unique Generalization a1 a2 a3 o1 o2 o3 Specialization a4 a5 a6 o4 o5 o6 One-Way Inheritance from the Generalization to the Specialization (a = attribute; o = operation) Generalization a1 a2 a3 o1 o2 o3 Specialization a1 a2 a3 a4 a5 a6 o1 o2 o3 o4 o5 o6

30 Associations Relationships between instances (objects) of classes Example: An Employee works for a Company An association between two classes indicates that objects at one end of an association recognize objects at the other end and may send messages to them. This property will help us discover less trivial associations using interaction diagrams.

31 Cont

32 Cont

33 Cont Multiplicity: The multiplicity of a role indicates how many objects can participate in the relationship. In the example above, a school has many students and each student attends only one school. Exactly one 1 Zero or more (unlimited) * (0..*) One or more 1..* Zero or one (optional association) 0..1 Specified range 2..4 Multiple, disjoint ranges 2, 4..6, 8

34 Cont Navigability: Sometimes a role has an arrow indicating its navigability. This shows which class has the responsibility for maintaining the relationship between the classes. In the example above, the school class has a responsibility for knowing which students attend. Therefore, you don't have to explicitly define a getstudents operation in the school class (although you may) since it is already implicitly defined by the navigability of the association.

35 Aggregation A special form of association that models a whole-part relationship between an aggregate (the whole) and its parts. Models a is a part-part of relationship. An order is made up of several products, but a product continues to exist even if the order is destroyed.

36 Composition A strong form of aggregation The whole is the sole owner of its part. The part object may belong to only one whole Multiplicity on the whole side must be zero or one. The life time of the part is dependent upon the whole. The composite must manage the creation and destruction of its parts. A polygon is made up of several points. If the polygon is destroyed, so are the points.

37 Constraint Rules and Notes Constraints and notes annotate among other things associations, attributes, operations and classes. Constraints are semantic restrictions noted as Boolean expressions. UML offers many pre-defined constraints.

38 Analysis Classes A technique for finding analysis classes which uses three different perspectives of the system: The boundary between the system and its actors The information the system uses The control logic of the system

39 Boundary Classes Models the interaction between the system s surroundings and its inner workings User interface classes Concentrate on what information is presented to the user Don t concentrate on user interface details Example: ReportDetailsForm ConfirmationDialog System / Device interface classes Concentrate on what protocols must be defined. Don t concentrate on how the protocols are implemented

40 Entity Classes Models the key concepts of the system Usually models information that is persistent Contains the logic that solves the system problem Can be used in multiple behaviors Example: Violation, Report, Offender.

41 Control Classes Controls and coordinates the behavior of the system Delegates the work to other classes A control class should tell other classes to do something and should never do anything except for directing Control classes decouple boundary and entity classes Example: EditReportController AddViolationController

42 Cont

43 Tips Don t try to use all the various notations. Don t draw models for everything, concentrate on the key areas. Draw implementation models only when Draw implementation models only when illustrating a particular implementation technique.

44 State Diagram Used to describe the behaviour of one object (or sometimes an operator) for a number of scenarios that affect the object They are not good for showing interaction between objects (use interaction diagrams) Only use when the behaviour of a object is complex and more detail is needed

45 Cont

46 Cont State A state is a condition during the life of an object during which it satisfies some condition, performs some activity, or waits for some external event Event An event is the specification of a significant occurrence. For a state machine, an event is the occurrence of a stimulus that can trigger a state transition

47 Cont Transition A transition is a relationship between two states indicating that an object in the first state will, when a specified set of events and conditions are satisfied, perform certain actions and enter the second state. Self-Transition A self-transition is a transition whose source and target states are the same

48 Sequence Diagram Illustrates how objects interacts with each other. Emphasizes time ordering of messages. Can model simple sequential flow, branching, Can model simple sequential flow, branching, iteration, recursion and concurrency.

49 Cont

50 Object Object naming: syntax: [instancename][:classname] Name classes consistently with your class diagram (same classes). mybirthdy :Date Include instance names when objects are referred to in messages or when several objects of the same type exist in the diagram. The Life-Line represents the object s life during the interaction

51 Messages An interaction between two objects is performed as a message sent from one object to another If object obj sends a message to another If object obj 1 sends a message to another object obj 2 some link must exist between those two objects (dependency, same objects)

52 Cont A message is represented by an arrow between the life lines of two objects. Self calls are also allowed The time required by the receiver object to process the message is denoted by an activation-box. A message is labeled at minimum with the message name. Arguments and control information (conditions, iteration) may be included.

53 Return Values Optionally indicated using a dashed arrow with a label indicating the return value. Don t model a return value when it is obvious what is being returned, e.g. gettotal() Model a return value only when you need to refer to it elsewhere, e.g. as a parameter passed in another message. Prefer modeling return values as part of a method invocation, e.g. ok = isvalid()

54 Synchronous Messages Nested flow of control, typically implemented as an operation call. The routine that handles the message is completed before the caller resumes execution.

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

56 Control Information (Cont.) Iteration examples:

57 Control Information (Cont.) The control mechanisms of sequence diagrams suffice only for modeling simple alternatives. Consider drawing several diagrams for modeling complex scenarios. Don t use sequence diagrams for detailed modeling of algorithms (this is better done using activity diagrams, pseudo-code or state-charts).

58 Cont

59 Activity Diagram

60 What is it? Describes activities and flows of data or decisions between activities Provides a very broad view of business processes Can be used to break out the activities that occur within a use case Good for showing parallel threads

61 When to use it? When describing work flow across many use cases When analysing a use case, and before methods are assigned to symbols When dealing with multi-threaded applications

62 Creating an Activity Diagram This diagram is useful in showing work flow connections and describing behaviour that has a lot of parallel processing. When you use an activity diagram you can choose the order in which to do things. It expresses the essential sequencing rules to follow. It is different from a flow chart in that it shows parallel processes, not just sequential processes.

63 Activity Diagram Shows a set of activities, the flow from activity to activity. Represents the dynamic view of a system. Models the function of a system.

64 Activity Diagram Activity diagrams show the flow of control between activities They can model the sequential and concurrent steps in a computational process They can also model the flow of an object as it moves from state to state at different points in the activity

65 UML Activity symbols ActionState initial state final state Transition Transition (Fork) (Join) Control Flow Decision Swimlane

66 Action State In a conceptual diagram an activity is a task that needs to be done either by a human or a computer In a specification-perspective diagram or an implementation-diagram, an activity is a method on a class

67 Sequential Branching A sequential branch is represented as a diamond It may have one incoming transition and two or more outgoing transitions Guards are associated with each transition. The guards are evaluated upon entering the branch, and the one that evaluates to true is then taken

68 Example

69 Branch & Merge Calculate Risk [ risk high] Ask for Authorization [ risk low] Issue a Loan Continue

70 Forking and Joining Concurrent activities within an activity diagram are modelled with the use of synchronised bars Synchronisation bars are drawn as a thick horizontal or vertical line Joins and Forks should balance The number of flows that leave a fork should The number of flows that leave a fork should equal to the number of flows entering the corresponding join.

71 Fork & Join Issue a Loan Reserve Money Make a Agreement Make an Offer

72 PrepareMeal [ in the mood for wine] CookSpaghetti MakeSauce OpenBottleWine Combine Serve

73 Forks, Joins & conditional Threads PrepareMeal [ in the mood for wine] CookSpaghetti MakeSauce OpenBottleWine Combine Serve

74 Swim lanes The activities of an activity diagram may be performed by different groups. Each zone or lane represents the responsibilities of a particular group. If swimlanes are used, each activity can belong to one and only one swimlane. To use swimlanes, you must arrange your activity diagrams into vertical zones separated by dashed lines.

75 Swim lanes Finance Desk Administration Issue a Loan Reserve Money Make a Agreement Make an Offer

76 Key point Activity diagrams are useful for Business Process Redesign Work Flow Modelling Analysing Use Cases

What is a Class Diagram? A diagram that shows a set of classes, interfaces, and collaborations and their relationships

Class Diagram What is a Class Diagram? A diagram that shows a set of classes, interfaces, and collaborations and their relationships Why do we need Class Diagram? Focus on the conceptual and specification