INTRODUCTION TO UNIFIED MODELING MODEL (UML) & DFD Slides by: Shree Jaswal
What is UML? 2 It is a standard graphical language for modeling object oriented software. It was developed in mid 90 s by collaborative effort by James Rambaugh, Grady Booch and Ivar Jacobson. The current custodian of UML is OMG (object management group). In 2005 UML was also published by the International Organization for Standardization (ISO) as an approved ISO standard
What is UML? 3 UML provides a standard notation for modeling It allows to analyze various properties of models thus leading s/w engineers to have insights about the system. It provides abstraction by letting you show as much as you want.
Model Views 4 Structural View Implementation View Class Diagrams Object Diagrams User View Use Case Diagrams Component Diagrams Sequence Diagrams Collaboration Diagrams Activity Diagrams State Chart Diagrams Behavioral View Environment View Deployment Diagrams
Tools Available 5 Open source tools: Argo UML, Eclipse UML, Papyrus, etc. Proprietary tools: Rational Software Architect, MS Visio, Magic Draw, Star UML, etc.
USE CASE DIAGRAMS
Developing use case models of 7 systems An actor is a role that a user or some other system plays when interacting with your system. A use case is a typical sequence of actions that an actor performs in order to complete a given task.
Use cases 8 Use cases are an essential tool in requirements capturing and in planning and controlling an iterative project. UML delivers the use cases to analyze the requirements of a system. Use cases are typical interactions a user has with the system. A use case indicates a function that the user can understand and that has value for the user.
Use cases 9 Following can be used to describe a complete use case 1. Name 2. Actors 3. Goals Use case name 4. Preconditions 5. Description 6. Related use cases 7. Steps 8. Postconditions
Example: Use case description 10
11 Actors An actor is a role that a user or other system plays with respect to the system to be developed. Typical examples for actors: Trading manager Trader Salesperson Accounting System A single actor in a use case diagram can represent multiple users (or systems). A single user (or system) also may play multiple roles. Actors don t need to be human, e.g., an external system that needs some information from the current system is also an actor.
Use Case (Basic) Example 12 Credit Card System Customer Perform Card Transaction Process Customer Bill Retail Institution Manage Account Financial Institution
13
Use Case Relationships 14 Generalization: A generalized Use Case describes the common characteristics of other specialized Use Cases. Inclusion: A Use Case is a part of another Use Case. Extension: A Use Case may extend another Use Case.
Generalization Relationships 15 Used when a number of Use Cases all have some subtasks in common, but each one has something different about it The generalized and specialized use cases share the same goal A specialized Use Case may capture an alternative scenario of the generalized Use Case The Specialized use case may interact with new actors. The Specialized use case may add pre-conditions and postconditions (AND semantics). If we have multiple ways which are fundamentally different, we can use generalization. Specialized Generalize d
Include Relationship 16 In older versions: uses When a number of Use Cases have common behavior, which can be modeled in a single use case X << includes >> Y indicates that the process of doing X always involves doing Y at least once The included Use Case must be complete X must satisfy the pre-conditions of Y before including it Not necessarily preserves the pre or post conditions. Include relationships can be viewed as a type of call to a subprogram X << include >> Y
Extend Relationship 17 Serves as extension point to another Use Case The extended Use Case must explicitly declare its extension points The extension conditions of the extended Use Case are part of the pre-conditions (AND semantics) Extensions mean this use case is similar to that use case with the exception of.... Think of this as an IF statement. Extended use case << extend >> Base use case
Use Cases (Advanced) 18 Actor Specialized Use Case General Use Case Base Use Case <<extend>> Extending Use Case Base Use Case Special Actor Special Actor <<include>> Included Use Case
19
20
Use Case Hints 21 Uses language of user Avoids implementation constraints Gets good scenarios Names single, identifiable and reasonably atomic behavior Describes flow of events clearly enough so outsider can follow
Use Case Hints 22 Show only use cases that are important to understand system Show only actors that relate to use cases Specify actor names by specific roles Decompose top-level use cases to different scenarios
Guidelines for finding Actors 23 Who is using the system? Or who is affected by the system? Or which groups need help from the system to perform a task? Who affects the system? Which external hardware or other systems (if any) use the system to perform tasks? What problems does this application solve (that is, for whom)?
Steps for finding Use cases: 24 For each actor, find the tasks and functions that the actor should be able to perform or that the system needs the actor to perform Name the use cases. Describe the use cases briefly by applying terms with which the user is familiar. This makes the description less ambiguous.
Rational Rose 25
INTERACTION DIAGRAM
Interaction Diagrams 27 Interaction diagrams that show dynamic aspects of models. Reveal the details of message passing: how objects respond to messages.
Interaction Diagrams (Cont.) 28 UML Sequence Diagrams Emphasizes time ordering of messages. Collaboration Diagrams Emphasizes structural relations between objects.
Object 29 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-Line represents the object s life during the interaction (time for which object is alive) mybirthdt :Date
Focus of control/ Activation box: 30 Represented by tall, thin rectangle. Represents the period of time during which an object is performing an action. :Client :ATMMachine Focus of Control
Messages 31 An interaction between two objects is performed as a message sent from one object to another (simple operation call, Signaling, RPC) If object obj 1 sends a message to another object obj 2 some link must exist between those two objects (dependency, same objects)
Messages (Cont.) 32 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.
Control information 33 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.
Return Values 34 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.
Object Creation 35 An object may create another object via a <<create>> message. :A <<create>> :B
Object Destruction 36 An object may destroy another object via a <<destroy>> message. An object may destroy itself. Avoid modeling object destruction unless memory management is critical. :A :B <<destroy>>
37 Sequence Diagram Scenario: Invalid Pin Number :Client :ATMMachin :Bank Insert ATM card() Request PIN() Enter PIN Number() Eject ATM Card() Verify PIN Number() Bad PIN Number() Display main screen()
ACTIVITY DIAGRAM
Activity Diagrams 39 Show how activities (flow of tasks/events) connect to one another in a process. Represents Dynamic behavioral aspects. Represents Sequential or concurrent activities Often used to: model the flow of events in a use case model internal system processes
Graphic Elements 40 Start and End points Activities Transitions Decisions Forks and Joins Swimlanes Object Flows Signal Sends and Receives
Start and End Points 41 Start is a dot End is a dot inside a circle
42 Activity Check air traffic An oval shape with a descriptive verbbased. Is an ongoing nonatomic (interruptible) execution. A step in the overall process
Transitions/Trigger 43 transition Get the Credit Card Numb Validate the Credit Card Num Specifies flow from one activity to another. Simple sequence Triggered by completion of the prior activity Initiates the next
Decision Activity 44 Decision Activity Decision Activity: Represented as a diamond. Guard: Determines which trigger is used.
Synchronization /Concurrent / Parallel 45 Activities Called Synchronization States Fork :- initiates parallel activity. Synchronization of 2 or more concurrent flows of control. Join :- occurs when all transitions into it are complete.
Activity diagram in general 46
47
Example Activity: Withdraw money from an ATM. 48
DATA FLOW DIAGRAM (DFD)
50 Functional Modeling: Data Flow Diagram Every computer-based system is an information transform... computer based system output
Notation 51 external entity process data flow data store
External Entity 52 A producer or consumer of data Example: person, device, system, sensor Data must always originate from somewhere, and must always be sent to something
Process 53 A data transformer (changes input to output) Example: compute taxes, determine area, format report, display graph Data must always be processed in some way to achieve system function
Data Flow 54 Data flows through a system, beginning as input and be transformed into output base height compute triangle area area
Data Store 55 Data is often stored for later use report required sensor # look-up sensor data sensor number sensor #, type, location, age type, location, age sensor data
56 Data Flow Diagramming: Guidelines all icons must be labeled with meaningful names the DFD evolves through a number of levels of detail always begin with a context level diagram (also called level 0) always show external entities at level 0 always label data flow arrows do not represent procedural logic
Constructing a DFD I 57 review the data model to isolate data objects and use a grammatical parse to determine operations determine external entities (producers and consumers of data) create a level 0 DFD
Level 0 58 user video source processing request NTSC video signal digital video processor requested video signal monitor
Constructing a DFD II 59 write a narrative describing the transform parse to determine next level transforms balance the flow to maintain data flow continuity develop a level 1 DFD use a 1:5 (approx.) expansion ratio
Level 1 60 x a P b y level 0 a p1 c p2 f d level 1 p3 e p4 5 g b
Flow Modeling Notes 61 Each bubble is refined until it does just one thing The expansion ratio decreases as the number of levels increase Most systems require between 3 and 7 levels for an adequate flow model
Example: Level 0 62
Level 0 63
64
65
66
THANK YOU! 69