AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
Generalization in use case diagrams9/13/2023 For example, for an ERP system for an organization, each of the modules such as personnel, payroll, accounting, and so forth, can form the system boundary for use cases specific to each of these business functions. For large and complex systems, each of the modules may be the system boundary. The system boundary is potentially the entire system as defined in the problem statement. Note that the actors in the system are outside the system boundary. The use cases of this system are enclosed in a rectangle. The figure shows the system boundary of the clinic application. A use case is shown as an ellipse in a use case diagram.Ī use case diagram depicting the system boundary of a clinic application As business functionality becomes clearer, the underlying use cases become more easily evident. Remember that identifying use cases is a discovery rather than a creation. Each of these business functions can be classified as a potential use case. As the first step in identifying use cases, you should list the discrete business functions in your problem statement. The key term here is "distinct business functionality." To choose a business process as a likely candidate for modeling as a use case, you need to ensure that the business process is discrete in nature. Use case: A use case in a use case diagram is a visual representation of a distinct business functionality in a system.For example, in the statement "patients visit the doctor in the clinic for medical tests," "doctor" and "patients" are the business roles and can be easily identified as actors in the system. To identify an actor, search in the problem statement for business terms that portray roles in the system. An actor is shown as a stick figure in a use case diagram depicted "outside" the system boundary, as shown in the below figure. If an entity does not affect a certain piece of functionality that you are modeling, it makes no sense to represent it as an actor. But it is up to you to consider what actors make an impact on the functionality that you want to model. Similarly, the person who provides service at the counter is also an actor. For example, for modeling a banking application, a customer entity represents an actor in the application. An actor in a use case diagram interacts with a use case. The different roles the actor represents are the actual business roles of users in a given system.
0 Comments
Read More
Leave a Reply. |