Download presentation
Presentation is loading. Please wait.
1
Software Engineering Introduction to UML
2
Introduction NOW, Systems must be developed in "Internet time." This faster pace has increased the need for flexible systems. System changes must happen fast. This is where the Unified Modelling Language (UML) enters the picture. UML is the industry standard modelling notation for object oriented systems, and is the premiere platform for rapid application development
3
Introduction to Object Oriented
With object oriented programming, developers create blocks of code, called objects. These objects are then used by the various applications. Should one of the objects require modification, a developer needs to make the change only once.
4
Object Oriented Advantages
One of the primary advantages of the object oriented paradigm is the ability to build components once and then use them over and over again (Reusability) The benefit of flexibility can be realized only by designing an object oriented system well. This requires knowledge of some principles of object orientation: Encapsulation Inheritance Polymorphism
5
Object Oriented Advantages cont.
Encapsulation means combining a piece of information with the specific behaviour that acts upon that information, then packaging these into an object. Another way to look at encapsulation is that we divide the application into small parts of related functionality The benefit of encapsulation is that it limits the effects of changes to the system
6
Object Oriented Advantages cont.
Inheritance is a mechanism that lets you create new objects based on old ones One of the major benefits of inheritance is ease of maintenance. When something changes that affects all child objects, only the parent object needs to change—the child objects will automatically inherit the changes
7
Object Oriented Advantages cont.
Polymorphism means having many forms or implementations of a particular functionality
8
System Development Life Cycle
Requirements Collection Requirements Analysis System Design System Development System Testing System Deployment System Maintenance
9
System Modeling – How? A model helps you plan a system before you build it Take the business needs of the users Map them into requirements that your team can use and understand Take these requirements and generate code from them By mapping the requirements to the code, you can ensure that the requirements are actually met by the code, and that the code can easily be traced back to the requirements Business Needs Requirements Model Code
10
Visual Modeling is the process of taking the information from the model and displaying it graphically using a standard set of graphical elements A standard is vital to realizing one of the benefits of visual modeling: communication Communication between users, developers, analysts, testers, managers, and anyone else involved with a project
11
Visual Modeling – What can we Model?
How the system works on several levels The interactions between the users and a system The interactions of objects within a system The interactions between systems
12
UML - Unified Modeling Language
UML DIAGRAMS Use Case diagram Activity diagram Sequence diagram Collaboration diagram Class diagram These model diagrams illustrate different aspects of the system
13
Software Engineering Use Case Diagram
14
Use Case Diagram Use cases represent system functionality, the requirements of the system from the user's perspective Use cases just focus on automated processes Use Case diagrams show the interactions between use cases and actors Emphasis what the system does, rather than how it does it Are created during the early stages of a project - during the analysis phase rather than during the design phase.
15
Elements of Use Case Diagram
Actor An actor is anyone or anything that is outside the system’s scope but interacts with it (Individual, group, company,…) There are three primary types of actors: Users of the system physical person, or a user who will be directly using the system Other systems that will interact with the system being built Time Time becomes an actor when the passing of a certain amount of time triggers some event in the system
16
Elements of Use Case Diagram
It is the functionality the system will provide a value to the end user Use cases are an implementation-independent: High-level view of what the user expects from the system Focus on what the system should do, not how the system will do it A typical system will have somewhere between 20 and 70 use cases The use cases should be named in user terms, not technical terms, and should be meaningful to the customer
17
Use Case: Flow of Events
Elements of Use Case Diagram Use Case: Flow of Events To actually build the system, you'll need more specific details. These details are written as the flow of events The purpose of the flow of events is to document the flow of logic through the use case Although it is detailed, the flow of events is still implementation-independent
18
Use Case: Flow of Events cont.
Elements of Use Case Diagram Use Case: Flow of Events cont. This document will describe in detail what the user of the system will do and what the system itself will do Notice the pattern in the flow of events: The user does something, then The system does something in response, Then the user does something, then the system responds, and so on
19
Use Case: Flow of Events cont.
Elements of Use Case Diagram Use Case: Flow of Events cont. It includes: A brief description: Each use case should include a short description that explains what the use case will do Preconditions: list any conditions that have to be met before the use case can start at all. For example, the precondition for one use case may be that another use case has run Typical flow of events: Most important section describes regular flow of events Post conditions: are conditions that must always be true after the use case has finished executing. Like preconditions, post conditions can be used to add information about the order in which the use cases are run
20
Use Case: Flow of Events Types
Elements of Use Case Diagram Use Case: Flow of Events Types There are three types of flows: Primary flow is the "happy day" scenario, or the most frequently used path through the use case Alternate flows are deviations from the primary flow that do not suggest an error condition Error flows are deviations from the primary or alternate flows that suggest some sort of error condition. Error flows suggest that there is a problem with the system itself
21
Use Case: Flow of Events Users
Elements of Use Case Diagram Use Case: Flow of Events Users There are three primary users of the flow of events: 1- The customers will be reviewing this document to make sure it accurately reflects their expectations 2- The system designers will be using it to create the system design and eventually to build the system 3- The quality assurance team will use the flow of events to create test scripts The flow of events must give them enough information to understand the sequence of events that needs to occur through the use case
22
Elements of Use Case Diagram
Relationships The association relationship is used to show the relationship between a use case and an actor There are three types of relationships between use cases Includes relationship Extends relationship Generalization relationship These relationships are used when there is a certain amount of commonality between the use cases There is only one relationship allowed between actors. This is a generalization relationship
23
Relationships: Association
Elements of Use Case Diagram Relationships: Association Association relationship is used to show the relationship between a use case and an actor Every use case must be initiated by an actor, With the exception of use cases in includes and extends relationships
24
Relationships: Includes
Elements of Use Case Diagram Relationships: Includes Includes relationship allows one use case to use the functionality provided by another use case This relationship can be used in one of two cases: First, if two or more use cases have a large piece of functionality that is identical The second case where an includes relationship is helpful in a situation in which a single use case has an unusually large amount of functionality An includes relationship suggests that one use case always uses the functionality provided by another <<includes>> Purchase Ticket Check Credit
25
Elements of Use Case Diagram
Includes: Example
26
Relationships: Extends
Elements of Use Case Diagram Relationships: Extends Extends relationship allows one use case the option to extend the functionality provided by another use case It is very similar to an includes relationship, because in both of these types of relationships, you separate some common functionality into its own use case <<extends>> Change Reservation Check Credit An abstract use case is one that is not started directly by an actor. Instead, an abstract use case provides some additional functionality that can be used by other use cases. Abstract use cases are the use cases that participate in an includes or extends relationship
27
Elements of Use Case Diagram
Extends: Example
28
Relationships: Generalization
Elements of Use Case Diagram Relationships: Generalization Generalization relationship is used to show that several actors or use cases have some commonality For example, you may have two types of customers. If the type A customers will be initiating some use cases that type B customers will not, it's probably worth including the actor generalizations. If both types of customers use the same use cases, it's probably not necessary to show an actor generalization Phone Salesperson Salesperson In person Salesperson Salaried Employee Employee Hourly Employee
29
Generalization between use cases: Example
Elements of Use Case Diagram Generalization between use cases: Example
30
Generalization between actors: Example
Elements of Use Case Diagram Generalization between actors: Example
31
Example: Draw a use case diagram
The Customer comes to the store and picks movies. Once he\she is done, they go to the register to pay for their rentals. If they are new customers, the clerk asks them to fill a new customer form stating their name, address, and phone number. The clerk then enters this information into a computer terminal and a new customer record is created. If they are returning customers, the clerk asks for the ID. The ID is then entered into the system to get the customer record. The clerk then checks the customer record for overdue rentals. If the customer has not returned rented movies, the clerk informs the customer that he\she needs to return old movies before allowing them to rent new ones. If the customer has returned the movies late, then the clerk calculates the late fees ($1 per late day). The clerk then gives the customer a bill for the late fees. Then the clerk enters the new movies into the system as rentals into the customer record along with the due date and issues a bill with the new rental and gives the customer the movies after collecting the payments. When a customer finishes viewing a movie, he\she goes to the store and drops it in a box outside the store. Once a day, the clerk checks the box and for each returned movie, if it is returned on time, the clerk removes the rental from the customer record. If it is late, the clerk adds a late notice in the customer record
32
Example cont: The Customer comes to the store and picks movies. Once he\she is done, they go to the register to pay for their rentals. If they are new customers, the clerk asks them to fill a new customer form stating their name, address, and phone number. The clerk then enters this information into a computer terminal and a new customer record is created. If they are returning customers, the clerk asks for the ID. The ID is then entered into the system to get the customer record. The clerk then checks the customer record for overdue rentals. If the customer has not returned rented movies, the clerk informs the customer that he\she needs to return old movies before allowing them to rent new ones. If the customer has returned the movies late, then the clerk calculates the late fees ($1 per late day). The clerk then gives the customer a bill for the late fees. Then the clerk enters the new movies into the system as rentals into the customer record along with the due date and issues a bill with the new rental and gives the customer the movies after collecting the payments. When a customer finishes viewing a movie, he\she goes to the store and drops it in a box outside the store. Once a day, the clerk checks the box and for each returned movie, if it is returned on time, the clerk removes the rental from the customer record. If it is late, the clerk adds a late notice in the customer record
34
Software Engineering Activity Diagram
35
Activity Diagram Activity diagrams illustrate the flow of functionality in a system It used in requirements gathering to illustrate the flow of events through a use case These diagrams define where the workflow starts, where it ends, what activities occur during the workflow, and in what order the activities occur An activity is a task that is performed during the workflow
36
Elements of Activity Diagram
Notation Representation Element Show where the flow begins. Each activity diagram must have one and only one start state Start State Show where the flow ends. You can have more than one end state on the diagram (Optional) End State Activity A step in the process Select Flight
37
Elements of Activity Diagram cont.
Notation Representation Element An entity that is used or changed by an activity in the flow. You can understand where and how the object's state changes. Object Name Objects [State] Link objects to activities. from an activity to the object it changes, or from the object to the activity that needs to use it (as input). Object Flows Transitions shows how the flow of control moves from one activity to another
38
Elements of Activity Diagram cont.
Notation Representation Element A way to show that two or more branches of a flow occur in parallel. It can be either horizontal or vertical Synchronization Shows decision point in the work flow Decision points
39
Ticket Enter Credit Information [Unconfirmed] [Invalid account, credit system not available ] [Approved] Ticket Reserve Seat [Purchased] Generate Confirmation Number
40
Elements of Activity Diagram
Activity: Actions A detailed steps can be added to the activity by using actions. Actions are smaller steps that take place within an activity They may occur at one of four times: Upon entering the activity. An entry action occurs as soon as the activity begins - "entry“ When exiting the activity. An exit action occurs as you are leaving the activity - "exit“ While performing the activity. These actions occur while in the activity and continue until you leave the activity - do“ Upon a specific event. These actions happen if and only if a specific event occurs - "event” followed by the event name
41
Activity: Actions cont.
Elements of Activity Diagram Activity: Actions cont. Display Available Flights entry/ Find all flights for selected cities entry/ Determine flights with available seats do/ Display list of flights with available seats event/ User request cost information/ Display cost information
42
Transitions: Limitations
Elements of Activity Diagram Transitions: Limitations Event: The event must happen in order for the transition to occur The transition arrow is labeled with the event name, along with any arguments in parenthesis Reserve seat Cancel reservation Refund credit purchase Cancel
43
Transitions: Limitations cont.
Elements of Activity Diagram Transitions: Limitations cont. Guard condition: While an event triggers a transition, a guard condition controls whether or not the transition can occur If a guard condition is present, it must be true in order for the transition to occur The guard condition is listed along the transition arrow, following any event, and is enclosed in square brackets Reserve seat Generate Confirmation Number [New reservation]
44
Synchronization & Decision Point Example
Elements of Activity Diagram Synchronization & Decision Point Example Enter Credit Information [Invalid account, credit system not available ] [Approved] Reserve seat Generate Confirmation Number Generate Display Confirmation Number
45
Example Draw a detailed activity diagram for the rent a video item use case. Clerk scans card Clerk scans desired video(s) Terminal displays details of each video scanned Verify customer(not a customer, unreliable, customer found) Terminal displays price and due date Terminal prints receipt for signature
46
Example
47
Practice Draw a use case diagram for a Bank system The following use cases are defined: Open customer account Deposit funds Transfer funds Withdraw money Order bank statment View account history Change PIN Draw a detailed activity diagram for the Open customer account and Withdraw money use cases.
48
Use case Diagram: Bank system
49
Activity Diagram: Open customer account
50
Activity Diagram: Withdraw money
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.