System Behavior Specification: Static Behavior: Use Cases, Use Case Diagram Components, Use Case Diagram
Embedded Files
INTRODUCTION
To model the system, the most important thing is to capture the dynamic behavior. Strong behavior refers to the behavior of the system in which it operates.
Direct behavior alone is not enough to model the system rather dynamic behavior is more important than statistical behavior. In UML, there are five diagrams available for modeling a dynamic space and the model diagram is one of them. Now that we have to discuss that the diagram of the use case varies in nature, there should be internal or external factors to make the connection.
These inner and outer ones are known as actors. Use character drawings contains characters, usage conditions and their relationships. The diagram is used to build a sub-system / application system model. One-use case diagram captures the performance of a particular system.
So to model the whole system, many application case diagrams are used.
Purpose Of use case Diagram
The sketches used are usually developed in the early stages of development and people often use modeling for the following purposes:
Specify the system context
Take the system requirements
Verify system architecture
Call for use and generate test cases
Developed analysts and field experts
A diagram of a typical usage case is defined in the Combined Modeling Language as shown in the Use case Diagram example below:
Use Case Diagram
A diagram of a typical usage case is defined in the Combined Modeling Language as shown in the Use case Diagram example below:
Notation Description
Actor
Someone is dealing with a usage case (system function).
Named after.
The actor plays a role in the business
Same with the user concept, but the user can play different roles
Example: Professor. can be a teacher and researcher play 2 roles in two programs
The character creates the conditions for use.
The character is responsible for the program (input), while the actor is responsible for the program (output).
Use case
System function (process - automatic or manual)
Named by verb + Noun (or Noun phrase).
i.e. Have a finger in the pie.
Each character should be connected to the operating mode, while other operating conditions may not be connected to the characters.
Communication Link
•The role of the character in the mode of use is indicated by connecting the character to the operating cage via a solid link.
• Actors may be connected to use cases by organizations, indicating that the character and the nature of the use are communicating to each other using messages.
Boundry Of The System
•The system boundary is probably the whole system as defined in the requirements document.
•For large and complex programs, each module can be a system boundary.
• For example, in an organization's ERP system, each module such as staff, payroll, accounting, etc.
can create a system boundary of usage conditions applicable to each of these business functions.
• The whole system can integrate all of these modules that reflect the boundary of the entire system
Structurs of Use Case Diagram with Relationships
Use situations to share different types of relationships. Defining the relationship between the two use cases is the decision of software analysts of the use case. The relationship between the two use cases is basically an example of dependence between two use cases. Re-use of the existing use environment through different types of relationships reduces the effort required to build a system.
Extends
Indicates that the "Incorrect Password" usage may include (depending on the specification of the extension) the behavior specified on the basis of the use "Login Account".
Show with a straight arrow around the dotted line. The point of the arrow head indicates the case of using the base and the case of child use is attached to the bottom of the arrow.
The stereotype "<<extends>>" identifies it as an extended relationship
Include
Indicates that the "Incorrect Password" usage may include (depending on the specification of the extension) the behavior specified on the basis of the use "Login Account".
Show with a straight arrow around the dotted line. The point of the arrow head indicates the case of using the base and the case of child use is attached to the bottom of the arrow.
The stereotype "<<extends>>" identifies it as an extended relationship
Generalization
The normal relationship is the parent-child relationship between use charges.
The case of child abuse is the development of the case of child abuse.
The standard design is shown as a straight arrow with a triangular arrow head.
The baby case case is attached to the bottom of the arrow. The arrow point is connected to the parent usage mode.
Use Case Examples
Use Case Examples
Association Link
A Use Case diagram illustrates a set of use cases for a system, i.e. the actors and the relationships between the actors and use cases.
Include Relationship
Integrated relationships can add additional unspecified functionality to the base application environment. The <<include>> relationship is used to incorporate normal behavior from the embedded usage status to the base use condition to support the re-use of normal behavior.
Extend Relationship
Extend Relationship
Extended relationships are important because they reflect voluntary performance or system behavior. The <<extend>> relationship is used to incorporate voluntary behavior from an extended use status to an extended usage status. See an example of a usage case diagram below. Displays the extended connector and the "Search" extension point.
Generalization Relationship
Generalization Relationship
Normal relationships mean that the child abuse case inherits the behavior and definition of the parent abuse case. The child may add or subtract parental behavior. The figure below provides an example of usage by showing two common connectors that connect between three use cases.
How To Recorgnized Actors?
In general, people find it much easier to begin the process of soliciting requests by identifying the characters. The following questions may help you to identify the characters of your system (Schneider and Winters - 1998):
1. Who is using the system?
2. Who installs the system?
3. Who starts the program?
4. Who maintains the system?
5. Who closes the program?
6. What other programs use this program?
7. Who gets the information in this program?
8. Who provides the information in the system?
9. Is something happening automatically in the present?
How to idenify Use case
Identifying Terms of Use, then the status-based request process goes on to ask what is the most visible, tangible value that each character desires. The following questions can be asked to identify usage conditions, once your characters have been identified:
1. What roles will the character want in the show?
2. Does the system store information? Which actors will create, read, review or delete this information?
3. Does the program need to inform the character about changes in the internal environment?
4. Are there any external events that the system should be aware of? Which actor appreciated the sequence of events?
Use Case Diagram Tips
Now, check out the tips below to see how you can apply the application case successfully to your software project.
1) Always plan and edit a case study plan from the point of view of the characters.
2) Use scenarios should start easily and look as high as possible. Only then
refined and elaborated.
3) Use sketch-based drawings so it should focus on "what" and not "how".
Real Life Example
Use Case Diagram - Car Sale System
The figure below shows an example of a diagram of the use of a car system. As you can see even the big system as a car sales system does not contain more than 10 usage cases
That is the beauty of using a case model.
The use case model also shows the use of extension and integration. Apart from that, there are associations that link between players and usage cases.
Page updated
Google Sites
Report abuse