Published on

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Unified Modeling Language1. Understanding Unified Modeling Language.2. USE CASE DIAGRAM.3. Activity Diagram.4. Class Diagram.5. Collaboration and Component Diagram.6. Sequence Diagram.7. DFD.
  3. 3. UML Fundamentals Why we model software?To achieve high quality.Ease of development.Shorter development cycles.Better user documentation.Less bugs through better testing.Drastically reduction in development time.By proper modeling and documenting.
  4. 4. How to create a quality System?Six possible scenarios when developing a system.( Analysis, Design, Implementation).1. A lot of analysis, good design , less implementation.2. Less analysis, better design and a lot of implementation.3. Small analysis , bad design, good implementation.4. A lot of analysis, bad design and your development is overcompensating to try to fix it.5. Bad design, design is overly complicated, implementation is trying to overcompensate.6. Good analysis, design is overly complicated, implementation is not solid enough.
  5. 5. Different doses of analysis, design and implementation. Analysis Design ImplementationAnalysis Design Implementation Analysis Design Implementation Analysis Design ImplementationAnalysis Design Implementation Analysis Design Implementation
  6. 6. (DOSE #1) a lot of analysis, good design , less implementation. (IDEAL) Analysis Design Implementation Your product does what the client expects, it has good design, with a small number of bugs.
  7. 7. (DOSE #2) Less analysis, better design and a lot of implementation.Analysis Design Implementation You do not know what the client expects, the design emphasizes the wrong expectation, and the product is riddled with bugs.
  8. 8. (DOSE #3): Small analysis , bad design, good implementation. Analysis Design Implementation You know most of what the client wants, but the design does not support the need of the analysis and the product is riddled with bugs.
  9. 9. (DOSE #4): A lot of analysis, bad designand your development is overcompensatingto try to fix it. Analysis Design Implementation• You know what the client needs, but your design does not implement it and your implementation is overcompensating to try to fix it.
  10. 10. (DOSE #5): Bad design, design is overlycomplicated, implementation is trying toovercompensate.Analysis Design Implementation• You have no idea what the client wants, the design is overly complicated for the functionality you will provide, and your implementation is trying to overcompensate for the problems.
  11. 11. (DOSE #6): Good analysis, design is overly complicated, implementation is not solid enough. Analysis Design Implementation• You have a good idea of what the client wants, the design is overly complicated for the needs analyzed and the implementation is not solid enough.
  12. 12. Understanding the Unified Modeling ProcessUML is only a language. It is not how to design asystem but it is how to model a system.There are a number of methods that have beendesigned but the most popular and probably thefirst to deal with UML, is Rational Unified Processalso called Unified Process.
  13. 13. Understanding the Unified Modeling Process A Software development process is a set ofphases that are followed to bring a product, or asystem from conception to delivery. In Unified Process, there are 4 of thesephases:1. Inception2. Elaboration3. Construction4. Transition
  14. 14. Inception PhaseIdentify the system you are going to develop, including what it contains & its business case.Various activities of this phase are: Initial Analysis Discussion with software experts (domain experts) what the system you will be designing should do Business requirements need to be identified, fleshed out and modeled in use case diagrams.
  15. 15. Elaboration PhasePerform detailed design and identify foundation of your system.Various activities of this phase are: Unified image of how the system should be constructed Iteratively pare down the system into subsystems Subsystems can be modeled separately. Evolve the use cases discovered in the inception phase into a design of the domain, its subsystems and business objects related to it.
  16. 16. Construction PhaseWrite the softwareVarious activities of this phase are: Code will be developed in portions that are manageable. Each code will go through mini cycles similar to entire unified process. Construction phase will call for changes to the design and questions for the analysis.
  17. 17. Transition PhaseDeliver the systems to the user. (rolling out the system) It deals with the delivering the product to the customers, perhaps a beta site or even the actual client.
  18. 18. Process WorkflowsThe rational Unified Process consists of nine process workflows:1. Business Modeling: Describe the structure and dynamics of the organization.2. Requirements: Describe the use case based method for eliciting requirements.3. Analysis and Design: Describe the multiple architecture views.4. Implementation: Takes into account software development, unit test and integration.
  19. 19. Process Workflows contd…5. Test : Describe test cases, procedures and defect tracking metrics.6. Deployment: Covers the deliverable system configuration.7. Configuration Management: controls changes to and maintains the integrity of a project’s artifacts.8. Project Management: Describes various strategies of working with an iterative process.9. Environment: Covers the necessary infrastructure required to develop a system.
  20. 20. TERM: (OMG) OBJECT MANAGEMENT GROUPA group of over 800 s/w vendors, developers and users dedicated to promotion of object technology used in developing distributed computing systems. OMG is not profit consortium. Common frameworks for object oriented applications to build upon.
  21. 21. Salient features of UMLFirst two members of UML dreamteam, Grady Booch and Jim Rumbaugh, started at rational creating the new notation in 1994.•They offered their own design methods. –Booch Method –Object Modeling Technique (OMT)•In 1995, Dr. Ivar Jacobson joined the team, offering his own method, object oriented software engineering.•Jacobson is known as father of use cases.
  22. 22. Salient features of UML• First version of UML was UML 0.8• In 1996, UML 1.0• In 1997, UML 1.1• In 2001, UML 1.4• In JIIT, UML 2.0
  23. 23. Pieces of UML• Two main pieces: – Structural Diagram – Behavioral Diagram
  24. 24. Structural Diagram• Two main types of structural diagram – Class Diagram – Implementation DiagramThis can be explained as: Class diagram Object diagram Component diagram Deployment diagram
  25. 25. Behavioral Diagrams• Use Case Diagram• Activity Diagram• Sequence Diagram• Collaboration Diagram• State - chart diagram
  26. 26. Structural Diagram : CLASS DIAGRAM • Used to represent classes, their relationships top each other and which subsystem they belong to. • Include attributes, operations and type of roles & associations.
  27. 27. Structural Diagram : OBJECT DIAGRAM• Very similar to class diagram• Instead of dealing with classes, it shows objects that are instances of classes.• Objects deal with individual unique things, where as classes are more generic.
  28. 28. Structural Diagram : COMPONENT DIAGRAM• How components of a system interact with each other.• It would show dependencies between source files and classes as well as components
  29. 29. Structural Diagram : DEPLOYMENT DIAGRAM• How the component winds up after they are installed on systems.• How these systems interact with each other.
  30. 30. Behavioral Diagrams: USE CASE DIAGRAM• Are starting point of analysis phase when designing a system• Originally invented by Ivar Jacobson, use cases are the foundation of a use case diagram• Use cases can be used to diagram the main flow of events in a system, for when there are no errors.
  31. 31. Behavioral Diagrams: ACTIVITY DIAGRAM• Used to analyze the behavior with more complex use cases and show interaction with each other.• Used to represent business activities.• Activity diagram is similar to state-chart diagrams but state-chart diagram are used to show how system changes state & reaches milestones or positions.
  32. 32. Behavioral Diagrams: SEQUENCE DIAGRAM• Show interaction between actors and objects and many other objects.• Messages are sent from: – Actor to object – Object to object – Object to actor• Sequence diagrams are used to realize use cases by documenting how a use case is solved with current design of the system
  33. 33. Behavioral Diagrams: COLLABORATION DIAGRAM• Used to bring class diagrams to the next step.• Use to represent relationships between the objects created in earlier steps of your domain modeling process.
  34. 34. Behavioral Diagrams: STATECHART DIAGRAM• Used to model behavior of subsystems, to model the interactions with classes and the system interface.• Are a wonderful way to visualize the flow of an application.
  35. 35. UML Modeling Tools• Rational Rose – All –in – one package that allows you to reverse engineer your code into models, change your models and then update your code to reflect the chages.
  36. 36. UML Modeling Tools• VISIO –Now owned by Microsoft. –Very comparable to Rational Rose –Cheaper than Rational Rose –It is easy to get up and running with visio (because interface, controls & functionality are as standard as those in word & Excel).
  37. 37. Unified Modeling Language (USE CASE DIAGRAM)
  38. 38. Use Case DiagramsOriginally from the works of Ivar Jacobson insweden.Used to enumerate the business requirementsof a system in ways that everybody involved withthe system can understand.Use case diagram is highest form of detail abouta system.Use case diagram illustrate who will use thesystem and what they will be able to do with it.
  39. 39. What is difference between a use case and use case diagram?• Use case describe the actions that user take on a system.• Use case diagram includes users, use cases & many relationships between two within a system.
  40. 40. Questions?• What should use case diagrams illustrate? – Business Requirements. • In which phase of the Unified Process do use case diagram first appear? – Inception Phase• What can be modeled with use case diagram? – Functionality, including tests, normal process flow and exception process flow
  41. 41. Notational Components of a use case diagram. Four basic components of Use case Diagram1. System2. Actors3. Use Cases4. Relationships
  42. 42. Notational Components of a use case diagram : System• A system as we began to discuss earlier in this module, is something that perform a function.• A system is a piece or multiple pieces of software that perform sort of function for its users.• It is possible for a system to have subsystems.
  43. 43. Notational Components of a use case diagram : Actors• Most common notational component of a use case diagram is the actor.• An actor is used to represent something that uses our systems.• Naming Recommendations – Avoid giving actors that represent people real people names, such as jason, kimbery or zachary. – Better you should name your actors based upon their job title when using the system.
  44. 44. Notational Components of a use case diagram : Actors• Actors don’t necessarily have to be people; they could be other systems that are external to that system that you are modeling. teacher monster developer
  45. 45. Notational Components of a use case diagram : Use Cases• Use cases are the actions that a user takes on a system.• For instance a develop would create software with a development system, a teacher would record grades with a grading system and a monster might do a number of different things with some sort of scaring system.
  46. 46. Notational Components of a use case diagram : Use Cases Create Software Record Grades Score Somebody
  47. 47. Notational Components of a use case diagram : Use CasesDevelopment:: Create Grading ::Record Software Grades Scaring ::Score Somebody
  48. 48. Notational Components of a use case diagram : Relationship • Relationships are simply illustrated with a line connecting actors to use cases. Develop SoftwareEntry Level ProjectDeveloper Manager Chief Technology Senior Officer Developer
  49. 49. Generalization Techniques• Use Case to Use Case Relationship• Actor to Actor Relationship
  50. 50. Generalization Techniques: Use Case to Use Case Relationship• Consider this example: Compile Application scheduler developer
  51. 51. Generalization Techniques: Use Case to Use Case Relationship• Although both the developer and the scheduler are compiling the application, they are doing it differently: Compile Application GUI compilation Command line compilation schedulerdeveloper
  52. 52. Generalization Techniques: Use Case to Use Case Relationship• Generalization can be broken down to more than two children use cases. API Compile Magically Compile Compile Software GUI compilation Command line compilation
  53. 53. Generalization Techniques: Use Case to Use Case Relationship• Generalization can even be hierarchical, where children use case of a parent use case can have their own children. Use Case 1 Use Case 1.1 Use Case 1.2 Use Case 1.1.1 Use Case 1.1.2
  54. 54. Generalization Techniques: Use Case to Use Case Relationship Use Case 1 Use Case 1.1 Use Case 1.2Use Case 1.1.1 Use Case 1.1.2 Actor A Actor B
  55. 55. Generalization Techniques: Use Case to Use Case Relationship Cook Dinner Cook Pasta Cook ChineseCook Spaghetti Cook Lasagna Cook
  56. 56. Generalization Techniques: Actor to Actor Relationship It is just like generalization of use cases, except we replace two use cases with two actors. Generalized Generic Actor Actor
  57. 57. Generalization Techniques: Actor to Actor Relationship Cook Mother Cook Father Cook
  58. 58. Generalization Techniques: Actor to Actor Relationship• Let use combine generalized actors so that they join our generalized use cases for an example of a very generalized use case diagram where Father Cook knows how to cook spaghetti while mother cook knows hot to cook lasagna and cook Chinese.
  59. 59. Cook Dinner Cook Pista Cook ChineseCook Spaghetti Cook Lasagna Mother Cook Father Cook Cook
  60. 60. How to include & extend relationships?<<include>> is used to indicate that a usecase will include functionality from anadditional use case to perform its function.<<extend>> indicates that a use case maybe extended by another use case.
  61. 61. Include Relationship• Notation for include: << include >> Including Use Case Included Use Case
  62. 62. Include Relationship • Example: GRADING SYSTEM Record Grades << include >> Save Grades Update Grades << include >>Teacher Grades Will always be saved.
  63. 63. Extend Relationship• Notation is same as of include but instead of include keyword extend is used in guillements.• Notation for include: << include >> Extending Use Case Extended Use Case
  64. 64. Extend Relationship • Example: GRADING SYSTEM Record Grades << include >> Save Grades << extend >> << include >> Update GradesTeacher Notify Grades Grades Will always be saved.
  65. 65. Questions ?• What type of relationship is used to always use another use case?• What type of relationship is used to occasionally use another use case?.• What are the symbols that encapsulate the include and extend strings in the use case diagrams?
  66. 66. What are Extension Points?• Notation for extension point: USE CASE NAME Extension Point list of extension points.
  67. 67. Extension Point • Example: GRADING SYSTEM Record Grades << include >> Save Grades << extend >> << include >> Update Grades Teacher Notify Guardian We want to notify the guardians Extension Pointof a student when a failing grade failing grade is saved.
  68. 68. How to Model Use Cases ?There are five tasks for creating use cases in the system. 1. Find the actors and use cases in the system. 2. Prioritize the use cases. 3. Detail each use case 4. Structure the case model 5. Prototype use interface
  69. 69. Case Study: How to describe use cases: TEACHER RECORD GRADES:1. The teacher identifies the student that they will be recording grades for.2. The system looks to ensure that student is in the database.3. The teacher indicates for which assignment they will be entering grades.4. The system begins transaction in database.5. The system adds the assignment to database for the student.6. The teacher enter the grades for the student’s assignment.
  70. 70. Case Study: How to describe use cases:7. The system validates the grades entered to ensure it is with correct range.8. The system record the grade for the assignment.9. The system ends the transaction.10. The system notifies the teacher that the grade has been recorded.
  71. 71. Model Use Case: Find Actors and Use Cases• Actors • Use Cases: – Teacher – Record Grades – Administrator – Update Grades – Student – Generate Report Cards – Check Report Cards for Accuracy – Distribute Report Cards – View Grades
  72. 72. Model Use Case: Prioritize Use Cases1. Record Grades.2. View Grades.3. Update grades.4. Generate report Cards.5. Check Report Cards for accuracy.6. Distribute report cards.
  73. 73. Model Use Case: Detail Each Use Case• Detail description of old and newly found use cases: – Logon – Save Grades – Record Grades – Load Grades – View Grades – Update Grades – Generate Report Cards – Distribute Report Cards
  74. 74. Model Use Case: Structure the Use Case Model >> << include Save Grades Record Grades << include >>Teacher Load Grades Update Grades << include >> Logon Distribute Record << include >> Cards View Grades Generate Report Cards StudentAdministrator
  75. 75. Assignment: COOK SPAGHETTI• Put water in pot.• Put pot on stove.• Turn stove on.• Wait for water to boil.• Put spaghetti in pot.• Stir spaghetti occasionally.• When spaghetti is done, turn stove off.• Pour contents of pot into strainer.
  76. 76. UML Class Diagram and Packages
  77. 77. Agenda• What is a Class Diagram?• Essential Elements of a UML Class Diagram• Packages and Class Diagrams• Analysis Classes Approach• Tips
  78. 78. 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. – A graphical representation of a static view on declarative static elements.• A central modeling technique that runs through nearly all object-oriented methods.• The richest notation in UML.
  79. 79. Essential Elements of a UML Class Diagram• Class• Attributes• Operations• Relationships – Associations – Generalization – Dependency – Realization• Constraint Rules and Notes
  80. 80. Classes• A class is the description of a set of objects having similar attributes, operations, relationships and behavior. Class Name Window size: Size Attributes visibility: boolean display() Operations hide()
  81. 81. Associations• A semantic relationship between two or more classes that specifies connections among their instances.• A structural relationship, specifying that objects of one class are connected to objects of a second (possibly the same) class.• Example: “An Employee works for a Company” Employee Department Company
  82. 82. Associations (cont.)• 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.
  83. 83. Associations (cont.) Role name Association name instructorStaffMember Student 1..* instructs * Role Navigable Multiplicity (uni-directional) association * pre - requisites Courses 0..3 Reflexive association
  84. 84. Associations (cont.)• To clarify its meaning, an association may be named. – The name is represented as a label placed midway along the association line. – Usually a verb or a verb phrase.• A role is an end of an association where it connects to a class. – May be named to indicate the role played by the class attached to the end of the association path. • Usually a noun or noun phrase • Mandatory for reflexive associations
  85. 85. Associations (cont.)• Multiplicity – The number of instances of the class, next to which the multiplicity expression appears, that are referenced by a single instance of the class that is at the other end of the association path. – Indicates whether or not an association is mandatory. – Provides a lower and upper bound on the number of instances.
  86. 86. Associations (cont.)– Multiplicity Indicators Exactly one 1 Zero or more (unlimited) * (0..*) One or more 1..* Zero or one (optional 0..1 association) Specified range 2..4 Multiple, disjoint ranges 2, 4..6, 8
  87. 87. 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. 2..* 1..* Car Door House Whole Part
  88. 88. Aggregation (cont.)• Aggregation tests: – Is the phrase “part of” used to describe the relationship? • A door is “part of” a car – Are some operations on the whole automatically applied to its parts? • Move the car, move the door. – Are some attribute values propagated from the whole to all or some of its parts? • The car is blue, therefore the door is blue. – Is there an intrinsic asymmetry to the relationship where one class is subordinate to the other? • A door is part of a car. A car is not part of a door.
  89. 89. 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. 1 Circle Circle Point 3..* Point Polygon
  90. 90. Generalization • Indicates that objects of the specialized class (subclass) are substitutable for objects of the generalized class (super- class). – “is kind of” relationship. An abstract Shape Super{abstract} is a {abstract} class Classtagged value thatindicates that the Generalizationclass is abstract. relationshipThe name of an Subabstract class should Circle Classbe italicized
  91. 91. Generalization• A sub-class inherits from its super-class – Attributes – Operations – Relationships• A sub-class may – Add attributes and operations – Add relationships – Refine (override) inherited operations• A generalization relationship may not be used to model interface implementation.
  92. 92. Dependency• A dependency indicates a semantic relation between two or more classes in which a change in one may force changes in the other although there is no explicit association between them.• A stereotype may be used to denote the type of the dependency. <<friend>> Iterator Vector
  93. 93. Realization• A realization relationship indicates that one class implements a behavior specified by another class (an interface or protocol).• An interface can be realized by many classes.• A class may realize many interfaces. <<interface>> LinkedList List LinkedList List
  94. 94. 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. Customer 1 * may be Order { total < $50 } canceled id: long { value > 0 } Constraint Note
  95. 95. TVRS Example TrafficReport OffenderTrafficPoliceman 1 issues * id : long 1..* 1 name : String description : String id : long occuredAt : Date reports of 1..* Policeman id : long Violation name : String id : long rank : int description : String <<abstract>>
  96. 96. UML Packages• A package is a general purpose grouping mechanism. – Can be used to group any UML element (e.g. use case, actors, classes, components and other packages.• Commonly used for specifying the logical distribution of classes.• A package does not necessarily translate into a physical sub-system. Name
  97. 97. Logical Distribution of Classes• Emphasize the logical structure of the system (High level view) – Higher level of abstraction over classes. – Aids in administration and coordination of the development process. – Contributes to the scalability of the system.• Logical distribution of classes is inferred from the logical architecture of the system.
  98. 98. Packages and Class Diagrams• Add package information to class diagrams A F E D B G C
  99. 99. Packages and Class Diagrams• Add package information to class diagrams b a b.a a.A b.b b.a.F b.b.E b.b.D a.B b.a.G a.C
  100. 100. Unified Modeling Language (Activity Diagram)
  101. 101. Activity Diagram• What are the two major roles of an activity diagram? – To model use case – Complex object workflows
  102. 102. Activity Diagram• What are 3 reasons why we model activity diagrams? – To elaborate a use case – To identify ore and post conditions of a use case. – To discover new use cases.
  103. 103. Activity Diagram• What are 3 major notational components of an activity diagram. – Activities – States – Transitions
  104. 104. What is difference between an activity and a state.• An activity indicates that an action is taking place, where as a state indicate that a milestone or internal setting has changed.
  105. 105. Activity Diagram• What are two special states? – Start State – End State
  106. 106. Activity Diagram• What is transition? – A representation of control flow from one activity or state to other. • A state to an activity • Between activity • Between states.
  107. 107. Activity Diagram• What are decision points? – Notation to indicate that a decision will be made and control can flow to different locations accordingly.
  108. 108. Activity Diagram Action State One guard guardAction State One Action State One
  109. 109. Activity Diagram• What are guards? – Expressions that, when evaluated to true, allow control to flow across their transitions.
  110. 110. Activity Diagram• What are Events? – Events are activities that occur that force control flow from one activity to another. Print File Printing Print [File, Printer] Ready Save File SaveAs(FileName) Ready CreateNew Create New File
  111. 111. Activity Diagram• What are swim lanes used for? – Swim lanes are compartments used to separate activities by their object or domain. Lane One Lane Two Lane Three
  112. 112. Activity Diagram• Example: Teacher and web interface Lane One Lane Two LOGON Validate User Choose Student Retrieve Student Information Change Student Information Persist User Information
  113. 113. Activity Diagram• What are forks and join used for? – Forks are used to initiate parallel processing and joins are used for multiple processes to catch up with others to resume single- processing. Parallel Three Parallel Four First Activity Last ActivityParallel One Parallel Two
  114. 114. How to Model activity Diagram?• There are five tasks for creating activity diagram: 1. Identify the use cases that require activity diagrams. 2. Model primary paths for each use case. 3. Model alternative paths for each use case. 4. Add swim lanes for identifying business areas for activities. 5. Refine high level activities into more activity diagrams.
  115. 115. Identifying Use Cases• Identifying Use Cases <<include>> Save Grades Update Grades <<include>> Load Grades
  116. 116. Activity Diagrams• Modeling Primary Paths Choose Load Modify SaveLogon Student Grade Grade Grade
  117. 117. Activity Diagram • Modeling Alternative Paths Choose Student Logon [Valid] Validate [UID, PWD] Load Validate Classes Load Grades [error loading]Error Occurred [inValid] Display [error loading] ErrorChanges Saved [error saving] Save Student Modify Student Display Student Information Information Information
  118. 118. Activity Diagram• Adding Swim Lanes Teacher Website Validate [UID, PWD] Logon Validate [Invalid] [Valid] Display Logon Error Not Validated Validated Choose Student Load Load Student Student Information
  119. 119. Collaboration, and Component Diagrams
  120. 120. Collaboration Diagram• Sequence diagram is time ordered• Like activity diagrams but shows association with other objects in the system
  121. 121. Elements• Object• Relation/Association• Message – Number represents order of interaction
  122. 122. Component Diagram• Represents Implementation perspective• Reflect grouping of different design elements of system
  123. 123. Component Elements• Component – Interacting objects within system• Class/Interface/Object• Relation/Association
  124. 124. Component Diagram Example
  125. 125. Deployment Diagram• Represents physical relationships among software and hardware components as realized in running system• Nodes represent computational elements (i.e. processor, server, etc.)
  126. 126. Deployment Diagram Skeleton
  127. 127. Example
  128. 128. Example
  129. 129. Courseware Example• Construct the design elements for a system that can be used to manage courses/classes• The organization offers a courses in areas such as learning management techniques and understanding different software languages and technologies• Each course consists of a set of topics• Tutors assigned courses to teach according to their specialty and availability• Publishes and maintains calendar of courses and assigned tutors• Course Administrators who manage content, assign courses to tutors, and define schedule
  130. 130. Identify Actors• Tutors• Course Administrators• Students• Course Administrator is main actor
  131. 131. Use Case• Manage courses – View courses – Manage topics for a course – Manage course information• Manage course assignments – View course calendar – View tutors – Manage tutor information – Assign courses to tutors
  132. 132. Use Case
  133. 133. Class Diagram
  134. 134. Activity Diagram
  135. 135. Sequence Diagram
  136. 136. Collaboration Diagram
  137. 137. Component Diagram
  138. 138. Unified Modeling Language (Sequence Diagram)
  139. 139. What is Interaction Diagram ?• An interaction diagram is a diagram that shows an interaction.• An interaction is a set of messages exchanged among a set of objects to accomplish a particular purpose within a given context.• There are two kinds of interaction diagrams: collaboration diagrams and sequence diagrams.
  140. 140. What are two types of interaction diagrams?• Sequence Diagram• Collaboration Diagram
  141. 141. sequence diagram• A sequence diagram is an interaction diagram that focuses on the time-ordering of messages. Sequence diagrams and collaboration diagrams are semantically equivalent, which means you can convert one type of diagram to the other without losing any information. However, a sequence diagram has two key features that a collaboration diagram does not: lifelines and foci of control.
  142. 142. Sequence Diagram usage• Shows object interactions in one use case scenario in time sequence• Depicts objects/classes and the message exchange between them needed to carry out the functionality of the scenario• Depicts the translation of requirements to system responsibilities• Shows messages between instances, which is the only way objects can interact
  143. 143. Diagram Contents• Objects (with lifelines)• Links• Messages (stimuli)
  144. 144. Diagram Contents• Labels – timing constraints, – descriptions of actions during an activation located – at margin – near transition or activation• Timing constraints – expressed using time expressions on message or stimuli names• Construction marks – indicate a time interval to which a constraint may be attached
  145. 145. objects• In a Sequence Diagram an object can be named with – Object name only – Class name only – Both Object name and Class name
  146. 146. lifeline• A lifeline is a vertical dashed line on a sequence diagram that represents the life of a given object.
  147. 147. focus of control• A focus of control is a tall, thin rectangle on a sequence diagram that shows the period of time during which a given object has control.
  148. 148. InteractionHow do active objects communicate with each other?• An interaction is a set of messages exchanged among a set of objects to accomplish a particular purpose within a given context (such as a collaboration).• With Messages.
  149. 149. What are valid active objects?• Actors• Objects (class instances)
  150. 150. message• A message is a conveyance of information from one object to one or more other objects with the expectation that activity will ensue, in the form of an action. A message can be either a signal or a call.• Within a process or a thread, messages are ordered in sequence by time.
  151. 151. arrow variations• filled solid arrowhead – Procedure call or other nested flow of control. The entire nested sequence is completed before the outer level sequence resumes. – The arrowhead may be used to denote • ordinary procedure calls, but it may also be used to denote • Concurrently active instances when one of them sends a Signal and waits for a nested sequence of behavior to complete before it continues.• stick arrowhead – Asynchronous communication; that is, no nesting of control. The sender dispatches the Stimulus and immediately continues with the next step in the execution.• dashed arrow with stick arrowhead – Return from procedure call.
  152. 152. What do synchronous and asynchronous mean?• Synchronous means one at a time, while asynchronous means multiple at the same time.
  153. 153. Synchronous Message Example: DatabaseTeacher Web Interface Wrapper Login Teacher Validate User [successful validation] Lookup Student Info Retrieve Student Information
  154. 154. Asynchronous Message Example: Log Web InterfaceTeacher Login Teacher Log Logon Attempt [successful logon] Log Successful Logon [unsuccessful logon] Log unsuccessful Logon [successful logon] Lookup Student Log Student Retrieval [successful logon] Log Changes to Student Info Change Student [successful logon] Logout
  155. 155. What are two types of control flow changes?BranchingAlternative Flows
  156. 156. branching• A branch is shown by multiple arrows leaving a single point, each possibly labeled by a condition.• Depending on whether the conditions are mutually exclusive, the construct may represent – conditionality or – concurrency.
  157. 157. Alternative FlowAlternative flow also allows the control flow to change basedupon conditions, but it allows the flow to change to analternative lifeline branch of the same object. ObjectOne ObjectTwo [condition one] [condition two]
  158. 158. Alternative Flow example:In the next example, the editor sends a messge to the Filesystemif the user deletes a file or saves a file. Obviously, the Filesystem us going to perform two very different activities and willrequire separate lifelines for each flow. ObjectOne ObjectTwoDeveloper Exit App [delete file] [save file]
  159. 159. Sequence Diagram with Concurrent Objectstiming constraint active object construction mark
  160. 160. Sequence Diagram with...• Focus of Control• Conditional branching• Creation• Destruction• Recursion
  161. 161. lifeline split• The lifeline may split into two or more concurrent lifelines to show conditionality.• Each separate track corresponds to a conditional branch in the communication.• The lifelines may merge together at some subsequent point.
  162. 162. How to Model Sequence Diagram?There are four tasks for creating sequence diagram:• Decide on the workflow that you will model.• Lay out your objects from left to right.• Include messages and conditions to build each workflow.• Draw a generic diagram to combine the separate diagrams.
  163. 163. Step #1: Decide on Workflows• The first step in modeling your sequence diagram is to decide on the workflows you are going to model. For the purpose of this exercise, we are going to model the view grades use case or a grading system. In doing this, we identify at least three workflows that we should model:1. The teacher views the grades for a student successfully.2. The teacher attempts to view the grades for a student, but the student doesn’t exist in the system.3. The teacher attempts to view the grades for a student, but the student does not have any grades in the system.
  164. 164. Lay Out Objects Web Interface Database Student Student Wrapper Information GradesTeacher
  165. 165. Include Messages and Conditions Web Interface Database Student Student Wrapper Information GradesTeacher Request Student Information Get Student Data Load Student Return Student Info. Load Grades Return Student Display Information Return Grades for Student Student Information
  166. 166. Creating and Destroying• What is the name of the message to create an object within a sequence diagram? • <<create>>• What about the message to remove it? • <<destroys>>
  167. 167. Include Messages and Conditions Web Database Student Student Interface Grades Wrapper InformationTeacher Request Student Get Student Load Student Information Data [student not [failure] found] Message <<create>> Box Display Error <<destroy>>
  168. 168. Include Messages and Conditions Web Database Student Student Interface Grades Wrapper InformationTeacher Request Student Get Student Information Load Student Grades Data [no grades found for student] [failure] Message <<create>> Box Display Error <<destroy>>
  169. 169. Draw Generic Sequence Diagram• Combine diagrams of previous two slides.
  170. 170. Exercise• Draw Complete generic sequence diagram for the removing an item from Inventory After a Sale use case.
  171. 171. Questions?1. Why are sequence diagrams modeled?2. What are the four types of messages and what are the differences between each of them?3. Model the creation of a database object, the connection of that object to a data source and the query of the object for a resultset.4. What are four steps to modeling a sequence diagram?5. What is difference between use case diagram and sequence diagram?6. What are two keywords used when instantiating an object with a sequence diagram?
  172. 172. Functional Modeling
  173. 173. Key Definitions• A functional model is a formal way of representing how a business operates• Data flow diagramming shows business processes and the data that flows between them
  174. 174. Key Definitions• Logical process models describe processes without suggesting how they are conducted• Physical models include information about how the processes are implemented
  175. 175. Data Flow Diagrams
  176. 176. Reading a DFD
  177. 177. DFD Elements
  178. 178. DFD Shapes from Visio Visio 5.x Visio 2000 From Software Diagram / From Flow Chart /From Flow Chart / Gane-Sarson DFD Data Flow DiagramData Flow Diagram ID # Process Process Process Data Store Data Store 1 Data Store ID # External External Entity External Entity Entity
  179. 179. DFD – Practical ExampleLaunched Dec. 11, 1998, the Climate Orbiter plunged too steeplyinto the Martian atmosphere Sept. 23, 1999, and either burned upor crashed. In an initial failure report released Oct. 15, 2000 thereview board blamed the navigation error on a communicationsfoul-up between NASAs Jet Propulsion Laboratory and primecontractor Lockheed Martin. W ho was T r a n s fe r o f F lig h t C o n tr o l D a ta re s p o n s ib le T h is p ro c e s s f o r th is ta s k ? w a s m is s in g J P L -1 ? ? L M -1 C o lle c t, T ra n s fe r d a ta C o n v e rt d a ta C o n tro l a n a ly z e , f ro m M e tric to s p a c e f lig h t g e n e ra te f lig h t E n g lis h c o n tro l d a ta M e tric d a ta E n g lis h d a ta J1 J P L s to re LM 1 L M s to re
  180. 180. Structured EnglishCommon Statements ExampleAction Statement Profits = Revenues - Expenses Generate Inventory - Report Add Product record to Product Data StoreIf Statement IF Customer Not in Customer Data Store THEN Add Customer record to Customer Data Store ELSE Add Current-Sale to Customer’s Total-Sales Update Customer record in Customer Data StoreFor Statement FOR all Customers in Customer Data Store Generate a new line in the Customer-Report Add Customer’s Total-Sales to Report-TotalCase Statement CASE If Income < 10,000: Marginal-tax-rate = 10% If Income < 20,000: Marginal-tax-rate = 20% If Income < 30,000: Marginal-tax-rate = 31% If Income < 40,000: Marginal-tax-rate = 35% ELSE Marginal-tax-rate = 38% ENDCASE
  181. 181. Key Definition• Decomposition is the process of modeling the system and its components in increasing levels of detail.• Balancing involves insuring that information presented at one level of a DFD is accurately represented in the next level DFD.
  182. 182. Context Diagram• Shows the context into which the business process fits• Shows the overall business process as just one process• Shows all the outside entities that receive information from or contribute information to the system
  183. 183. Relationship Among DFD levels
  184. 184. Decomposition Diagram
  185. 185. Level 0 Diagram• Shows all the processes that comprise the overall system• Shows how information moves from and to each process• Adds data stores
  186. 186. Level 1 Diagrams• Shows all the processes that comprise a single process on the level 0 diagram• Shows how information moves from and to each of these processes• Shows in more detail the content of higher level process• Level 1 diagrams may not be needed for all level 0 processes
  187. 187. Level 2 Diagrams• Shows all processes that comprise a single process on the level 1 diagram• Shows how information moves from and to each of these processes• Level 2 diagrams may not be needed for all level 1 processes• Correctly numbering each process helps the user understand where the process fits into the overall system
  188. 188. Data Flow Splits and Joins• A data flow split shows where a flow is broken into its component parts for use in separate processes• Data flow splits need not be mutually exclusive nor use all the data from the parent flow• As we move to lower levels we become more precise about the data flows• A data flow join shows where components are merged to describe a more comprehensive flow
  189. 189. Alternative Data Flows• Where a process can produce different data given different conditions• We show both data flows and use the process description to explain why they are alternatives• Tip -- alternative data flows often accompany processes with IF statements
  190. 190. Your Turn• At this point in the process it is easy to lose track of the “big picture”.• Describe the difference between data flows, data stores, and processes.• Describe in your own words the relationship between the DFD and the ultimate new application being developed.
  191. 191. Creating Data Flow Diagrams
  192. 192. Steps in Building DFDs• Build the context diagram• Create DFD fragments for each scenario• Organize DFD fragments into level 0• Decompose level 0 DFDs as needed• Validate DFDs with user
  193. 193. DFD Fragment Tips• All process names must be verb phrases• Maintain organization’s viewpoint in naming processes• Layouts often place – processes in the center – inputs from the left – outputs to the right – stores beneath the processes
  194. 194. A DFD Fragment Example
  195. 195. A Second DFD Fragment Example
  196. 196. Level 0 Tips• Generally move from top to bottom, left to right• Minimize crossed lines• Iterate as needed – The DFD is often drawn many times before it is finished, even with very experienced systems analysts
  197. 197. Composite & Elementary Flows
  198. 198. Tips for Level 1 and Below• Sources for inputs and outputs listed at higher level• List source and destination of data flows to processes and stores within each DFD• Depth of DFD depends on overall system complexity – Two processes generally don’t need lower level – More than seven processes become overly complex and difficult to read
  199. 199. Flows to & from Data Stores
  200. 200. Validating the DFD• Syntax errors – Assure correct DFD structure• Semantics errors – Assure accuracy of DFD relative to actual/desired business processes• User walkthroughs• Role-play processes• Examine lowest level DFDs• Examine names carefully
  201. 201. Summary• The Data Flow Diagram (DFD) is an essential tool for creating formal descriptions of business processes and data flows.• Use cases record the input, transformation, and output of business processes.• Eliciting scenario descriptions and modeling business processes are critically important skills for the systems analyst to master. 201