- 1 Introduction to Usecase diagram and Data Flow Diagram
- 1.1 What is the use case and how to make use case diagram?
- 1.2 How to make use case diagram?
- 1.3 Fully Formatted Description of the single-use case
- 1.4 Benefits of making use case diagram
- 1.5 Steps to identify use cases in the system
- 1.6 Structure cases of use
- 1.7 Major parts of the use case diagram
- 1.8 Mistakes to Avoid while making use cases
- 1.9 Requirements Engineering
- 1.10 What are some modelling principles?
- 1.11 Analysis of Modeling Approaches
- 1.12 Data Flow Diagram
- 1.13 What is Data Flow?
- 1.14 What is data stores?
- 1.15 Properties of DFD
- 1.16 Partitioning in a DFD
- 1.17 Case Study on DFD
- 2 Conclusion
Introduction to Usecase diagram and Data Flow Diagram
Use cases are not object-oriented but are an integral part of the unified process. Use cases are a commonly used mechanism for discovering and documenting requirements (especially functional) the use case model is the compilation of all use cases – the device features and environment model. Use cases are stories about the use of a goal-Ivar Jacobson introduced a summary of domain processes the concept of using cases to define functional specifications in 1986. For example anything with actions, e.g. an individual, a program, an organization.
What is the use case and how to make use case diagram?
The scenario of the use case
A basic sequence of actions and interactions between stakeholders and processes under discussion.
Format of use case
Sample Case study on Usecase diagram
Previously, The Air Ticket Sales System user interface is old-fashioned. The first release of the existing system took place in the last century. The technology at the time did not allow a GUI (Graphical User Interface). This must change in the new system.
Our highest priority for the new system is the GUI (graphical user interface). It must be clear, consistent and make the system easy to use for the end-user. One of the major problems with our existing system is that it does not have any security measures and its vulnerability to attacks i.e. the administrator must have full access to the system stock, the advisors will have access to their own stock and respective sales reports only. The office manager is also the only role who can generate all types of reports.
Our existing system has some functional limitations, which make it difficult to use so our new software must rectify these mistakes. Some examples are given below to illustrate this:
If a record about a sale is associated with a particular USD rate, which was found to be incorrect. With the current system, the only way to alter the record is to delete it first and then create it again with a correct rate it very inefficient way. The new system must provide extensive functionality to allow Travel Agents to improve their relationship with these kinds of customers.
Our new system provides the functionality of sell tickets by Advisor, cancel and buy tickets by Customer, give discounts by Travel agents, update and report stock, the office manager can also apply commission rates and the generation of total sales report.
How to make use case diagram?
The use case explains how a consumer uses a program to accomplish a particular objective. The use case diagram consists of the framework, the associated use cases and the actors, and relates them to each other in order to visualize: what is described? (System), who is going to use the system, (Actors) and what do the actors want to do? (Use cases), therefore, use cases to help ensure that the correct framework is built by capturing the criteria from the user’s point of view.
The use case is a list of actions or event steps that usually describe the interactions between the role of an agent and the mechanism to achieve the objective. Case usage is a valuable method for defining, clarifying and organizing program specifications. The use case consists of a collection of potential interaction sequences between systems and users that describe the features to be introduced and the resolution of any errors that may be encountered.
Although the use case itself can dig into a lot of detail (such as the flow of events and scenarios) about every possibility, a use-case diagram may help provide a higher-level view of the system.
Note: This is the use case diagram for the case study above
Fully Formatted Description of the single-use case
|Use Case ID: UC1||Use Case: Make Sale|
The travel advisor wants to make sales of the ticket and this use case started with the main success scenario and ends with postcondition.
|Primary Actor: Travel Advisor|
|Secondary Actor: None|
The system must be in a working state.
Tickets Sales Report generated successfully, tax and commission rate can be calculated successfully.
|Main Success Scenario (or Basic Flow of Events):|
1. This use case stated when the company has been invited to develop an “IT system to report sales of air tickets” for AirVia Ltd.
2. AirVia wants to sell tickets through the local Travel Agent companies.
3. The Air Ticket Sales (ATS) system will keep records of tickets sold by a Travel Agent company to customers, and produce the reports required by the Financial Department of AirVia Ltd.
|Alternative Scenario/Flow (or Extensions):|
1. The company has not invited to develop and “IT system to report sales of air tickets” for AirVia Ltd.
2. AirVia did not sell tickets.
3. The tax and commission cannot be calculated correctly and sales report may not be generated correctly.
Benefits of making use case diagram
Using cases is an effective strategy for eliciting and recording black-box functional criteria.
Since the use of cases is easy to understand and offers an ideal way to communicate with consumers and users, as written in natural language. Use cases can help handle the complexity of large projects by splitting the issue into different useful features.
The use case can define requirements from the user perspective. The use case scenario, often represented by a sequence diagram, includes the coordination of several objects and classes, use cases to help define messages (operations and information or data required-parameters) that connect objects together.
The use of cases is an appropriate technique to evoke and document black-box functional requirements. Since the use of cases is easy to understand and offers an excellent way to communicate with customers and users, as written in a natural language. Use cases can help handle the complexity of large projects by separating the problem into specific product features (i.e. use cases) and identifying specifications from the user perspective.
The use case scenario, often described by a sequence diagram, involves organizing multiple objects and classes, using cases to help identify messages (operations and information or data required-parameters) that bind objects together.
Steps to identify use cases in the system
- We should identify the Actors from the given case study
- We should identify all-important users from the case study.
- We should identify what users are needed by the program to achieve these goals.
- Make Use cases for each target.
Structure cases of use
- Verify users.
Note: The usage case explains how the actors use the process to accomplish a particular goal. The client typically implements use cases in order to fulfil the goals of the project and the differences involved in the achievement of the goal.
<<include>> Use Case
The time to use the < < include > > the relationship is after you have completed the first cutout overview of all your key Use Cases. You can now look at Use Cases and recognize common user-system interaction sequences.
<<extend>> Use Case
The extension of the use case is, in effect, an alternative course of the base use case. The < < extend > > > use case does this by conceptually inserting additional action sequences into the base-case sequence.
Major parts of the use case diagram
Actors are typically individuals who are active in a structure identified by their positions. The actor may be a person or an external machine.
The use case explains how the actors use the method to accomplish a particular objective. The customer usually introduces use cases in order to satisfy the aims of the operations and variations involved in the achievement of the aim.
It is the relationships between the actors and the use cases from the scenarios.
It is defined as the system boundary defines the system of interest in relation to the scenario around it.
Mistakes to Avoid while making use cases
Include User Interface Details
By far the most common error we see in use cases is that they use the user interface language to speak about user actions.
The use of user interface information contributes to confusion. This is counter-intuitive because “press the new account button” tends to be much more precise than “create an account.” However, often the name of the user interface feature does not clearly define the action the user is taking and therefore creates confusion about the exact move that the user needs in order for the program to be efficient.
Not Specify a System Response to a User Action
The next most common mistake we see, particularly from individuals with little exposure to information technology projects, is that the use cases are very process-oriented. The use case is clear about all the steps that the user needs to take, but the corresponding device action that needs to be taken in response to each user move is lacking.
In the use case, just about every user move should have an acceptable user response or action. When it does not, the engineering team does not know what the program is going to do to keep up its end of the contract. This leads to conclusions being made or concerns being answered during implementation.
Include Technical Details
Another common error, which appears to come from more technologically trained experts, is that the use case requires technical specifics that are not needed to understand how the user interacts with the device.
Different examples of technical information shall include:
- Relevant data elements or tables.
- Names of system elements that will not be apparent to the ordinary end-user of the program.
- System-triggered processes or procedures that need to be performed.
The stages of Requirements Engineering is as below:
What are some modelling principles?
The primary aim of the development team is to develop software, not to construct models.
- Travel light — do not build more templates than you need.
- Strive to generate the simplest model that explains the problem or program.
- Create models in a way that makes them adaptable to change
- To be able to state a specific intent for each model that is generated
- Get your reviews as soon as you can.
Analysis of Modeling Approaches
Considers data and processes that turn the data as independent entities.
- Data objects are modelled to describe their attributes and relationships.
- Processes represent the transformation of data objects as they move through the system.
- Considers the data and processes that convert the data into autonomous entities.
- Data objects are modelled in order to define their attributes and relationships.
- Processes are the creation of data objects as they pass through the network.
Data Flow Diagram
Notations used to make DFD (Data Flow Diagram)
What is Data Flow?
What is data stores?
Properties of DFD
- Data Flow Diagram Focus on the flow of data
- Data Flow Diagram Show ‘what’ and not ‘how’
- Data Flow Diagram Constructed top down
- It is Partitioned
- Data Flow Diagram do not show sequence explicitly or separately
- Data Flow Diagram do not show iterations explicitly
- Data Flow Diagram do not show conditions explicitly
Partitioning in a DFD
- Contains only one process/bubble reflecting the research domain
- Contains net device inputs/outputs and external entities
DFD 1st Level (Intermediate Levels)
- The refinement of the 0 stage DFD, partitioning takes place
- Data centres are being implemented
- Data flow needs to be balanced between rates
Unit names are different from level to level
DFD lower level (primitive level)
- Bubbles are ‘zooming in’
- Data flow needs to be balanced between rates
- Unit names are different from level to level
Case Study on DFD
Note: This is the very first level in which maximum details are hidden.
Note: This is 1st level DFD in which some of the details are prompted by the user.
Note: This is the Primitive level DFD that shows each and everything with maximum details.
The use case diagram and Data flow diagram are two important concepts of Software engineering. You must learn them in details to transform the requirements into working software. In this article, I have tried to provide insight into the Data flow diagram and use case diagram.
If you like this post please consider it sharing.