3. Use Case Modeling and UML¶
2.4 Use Case Modeling¶
- use case: is a description of how the user will use the planned system to accomplish business goals.
- The consideration of system requirements starts with identifying the actors for the system-to-be.
- actor: is any entity (human, physical devices, other systems) that will interact with the planned system.
- actors have responsibilities, they use the system to help in managing their responsibilities.
- actors set goals to accomplish their responsibilities. Goals are context and time dependent.
- actors perform actions to accomplish their goals.
- actors can be:
- initiating actors: closer to reach the goals. expect services from the system, usually the end-user.
- participating actors: deliver to initiating actors. help the system to serve initiating actors. 2 sub-categories:
- supporting actor: helps (provide services) the planned system. eg. some external api that the system uses.
- offstage actor: passively participates in the planned system (does not provide services to the planned system). eg. external analytics service.
- the planned system itself is an actor and its responsibility is to assist the initiating actors to fulfill their goals. in this process the planned system may seek help form other systems or participating actors.
- the actor is associated with a role, not the person(entity), so the same person can appear as different actors depending on their role in this use case.
- if a participating system provides different services to the planned system, then this participating system will have different actors.
summary use cases¶
- a use case: is a usage scenario for an external entity (actor) and the planned system.
- a use case represents: an action that an actor performs on the planned system, and what the system does in response.
- a use case describes: when an actor disturbs the planned system from its stationary state, and what happen in the system until it reaches a new stationary state.
- the planned system is reactive, not proactive, if it left undisturbed it will stay in its stationary state (equilibrium) for ever.
- summary use cases === user stories
- summary use cases (as user stories):
- they do not describe the details of the business process.
- they just identify the user role (actor type) and the capability that the planned system will provide.
- effort estimation for summary use cases:
- same techniques used with user stories.
- we can use user stories points and development velocity to estimate the effort according to the equation: duration = sum of points / development velocity.
- we can not use the use case points for this estimation because they require detailed use case description.
Use cases diagram¶
- use cases diagram: is a diagram that sums the actors, use cases, and the relationships between them.
- two use case categories:
- first tier: the meaningful services that the planned system provides to an actor.
- second tier: the services that are sub-services of the first tier, usually actors does not interact directly with those services.
- relationships between the first tier and second tier services:
- extend: optional extension of the first tier services.
- include: required subtasks of the main task.
- login is not a first tier service, it is a second tier service. because users don’t login for the sake of login.
- use cases diagram: should not replace the use cases, it is a concise visual form of the use cases that summarize the system features and their relationships.
- use cases: are text stories that detail exactly what will happen when an actor attempts to obtain a service from the planned system.
- use cases diagram is the index of a book, while use cases are the actual textual content of the chapters in the book.
2.4.2 System Boundary and Subsystems¶
- it is hard to define the system boundaries during development, cause everything is subjective to change.
- any subsystems that we own (no matter of how complex they are), eg. DBMS, web server, etc. are considered as within the system boundaries.
- any third parties subsystems, eg. external services, etc. are considered as outside the system boundaries even if they appeared in the core of the system; these are participating actors.
- traceability matrix: maps system requirements to use cases, to check that all requirements are covered by use cases, and none of the use cases created without a reason.
- PW: stands for Priority Weight, is a number that represents the importance of a requirement.
- use cases with high PW are more important than use cases with low PW, and must be developed and shipped first.
2.4.3 Detailed Use Case Specification¶
- detailed use case specification is:
- a use case represented as a sequence of interactions between the actor and the planned system.
- written as usage scenarios or scripts listing specific sequences of interactions between the actor and the planned system.
- specifies what information must pass the boundaries of the system when interacting with other systems.
- scenario is:
- a recipe like description of th use case.
- describes step-by-step how the actor will interact with the planned system and what the system will do in response.
- also called use case instance since: it represents one of several possible courses of action for a given use case.
- main success scenario is:
- a normal scenario assumes that everything flows perfectly.
- usually does not include branching (linear).
- alternate scenarios or extension :
- derived from the main success scenario.
- can result from:
- Inappropriate data entry: eg. actors enter data that is not valid.
- system’s inability to respond as desired: can be temporary. eg. system is overloaded.
- each alternate scenario is a different use case instance and must have an event flow exactly describing what will happen.
- alternate scenarios are usually more important since they are dealing with security/critical issues, or things that break.
- at the time of writing detailed use cases, we also write the corresponding user acceptance tests.
System Sequence Diagrams¶
-
System Sequence Diagrams are:
- a visual form a usage scenario that an actor experiences while trying to obtain a service from the system.
- summarizes the textual description of a use case scenario.
- purpose: represent what information must pass the system boundary and in what sequence.
-
Note: use cases are not suitable for:
- systems that are heavily algorithm-driven: eg. biology labs, financial systems, etc.
- data-intensive systems: eg. systems with huge and multiple databases.
2.4.4 Security and Risk Management¶
- every business process is a risk, the software engineer should be aware of the risk management and implement this in the planned software.
- The root causes and potential consequences of the risks should be analyzed, and reduction or elimination strategies devised.
- some risks are intolerable, while others are acceptable: the intolerable risks must be treated before delivering the software, acceptable risks can be handled if resources allow.
- probability of an accident arising because of the hazard should be made as low as reasonably practical (ALARP).
- we tend to make stand-alone one-task-only systems to better manage the risk. every system has a risk management process that’s independent of the main system status.
- A positive aspect of a stand-alone, one-task-only system is its simplicity and lack of dependencies, inherent in the main system, which makes it resilient;
- a negative aspect is that the lack of dependencies makes it myopic, not much aware of its environment and unable to respond in sophisticated manner.