"The foundation of a good application begins with a good design and the foundation of a good design begins with good use cases. Of all the artifacts produced from a software design, use cases are the most important. Use cases capture the business process and, collectively, describe the software application’s functionality from the user’s perspective.
This article overviews use cases and the challenges associated with them, offers tips in their creation and suggests a structured approach to produce them."
"Use cases are a necessary artifact of object-oriented application system design and development. Actually, more than that, they provide the foundation for the design of the entire application since application classes and their relationships emerge from the use cases.......use cases as “sequences of interactions between the system and its external actors, related to a particular goal.” The idea is that users (and systems) have domain goals that need the help of computer systems to achieve them."
How something is to be used to achieve the user's goal is a use case specified by the user and sets the course for system development. The use case of money is established by the banking system: To use money in the form of a loan that is a debt establishment contract that creates the money that is loaned into circulation and extinguishes the money as it is paid back in accordance with the contract. The benefit of the debt to the bank is interest on the loan.
If that is the use case of the bank user of money then the entire system is designed to serve that use.
However, it is not only the bank that is involved in the Use Case spec;
"A stakeholder is someone of some "thing" with a vested interest in the behavior of the system. Not all of the stakeholders are present while the system is executing but the system must protect and satisfy the stakeholders interests at all times. Examples of the stakeholders include company shareholders, customers, vendors, and government regulatory and reporting agencies.
A use case describes the behavior that protects and satisfies the stakeholder’s interests."
Our stakeholder vested interest via our government is "Stable Prices and Full Employment" and perhaps it should have been added: "Do No Evil Harm"
The banking system had hand to specify the use case and therefore loaded the dice by making money a debt object in its creation to serve the purpose of debt creation use. Once created for that purpose it is placed into circulation as a medium of exchange.
"Actors have goals that are achieved by use cases.
An Actor stimulates the system by providing input or receiving something from it. The primary actor is the stakeholder that initiates or triggers an interaction with the system to achieve a goal. The primary actor will be the user sitting at a computer or another computer system.
The primary actor is the one that initiates the use case's main success scenario.
Supporting actors are actors that assist the primary actor to achieve the goal. They interact with the use case but do not trigger it. They are often external systems or third party components.
An actor can be the primary actor for one use case and the secondary actor for another."
Use Case described by Wikipedia here
In systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. The detailed requirements may then be captured in SysML or as contractual statements.
My summation: Specifying how something is to be used at a high level drives development of a system to use it. Banks are actors that are primary stakeholders in the money system and have the greatest say in how money is to be used and therefore control of the system to use it. Banks not only determine how money is to be used (MakeLoan) but what the money is being loaned to do through risk analysis decisions.
My thinking is that if I control the Object design properties then I control what the object will do (or Cannot do) in a system
Banks determine the Use Case of an Object and that controls the properties of the Object Design. While the FED is tasked to use money to maintain stable prices and full employment I would like to see how that is implemented as the driving factor in their system design!
A Use Case was specified for money by the government, with weak implementation in the system design. Just lipstick on the pig to deceive what it really is and does and no real regulation of operation. Certainly no certification that the system does to attain the government goals. It has not achieved the goals by any measure.
A new Use Case Specification is required and a new system to implement the use of money.
A debt free money system. We are the primary stakeholders in the decision of what money is to do in use and therefore what it is designed to be as an object. A debt free object at the point of creation.
UML Use Case diagram explanation here
Use Case has a functional orientation that I always regarded as being lesser important design approach that causes things to be built to much into object properties and perhaps obviating properties that should naturally be attributed to them as a matter of independence from their use.
At a high level design concept, Use Case is a good place to start. I would start by specifying all the objects used in the system and then go on to how they are used. Use Case would only be an object discovery tool.
Is there a strong pre disposition to choose incorrect objects for the system base on perceived uses.
Object Form vs Function which drives the development of system to use it?
This is from Use Case Pitfalls
Symptom: The use case model looks like a data/process flow diagram.
Cure: Watch out when the use case model includes use cases that are not directly associated with an actor, but are associated with <<uses>> or <<extends>> relationships. Sometimes this is an appropriate way to model the use cases. But many neophyte use case modelers (especially those who are programmers, or who have a process modeling background) misuse these associations, functionally decomposing the problem, rather than focusing on the interactions between actors and the system.
More Use Case Pros and Cons from Knowledge Systems Corporation by Donald G. Firesmith
See the full list at the link, these are selections:
The Dangers of Misusing Use Cases
Because of their many important advantages and extreme popularity, use cases have become a fundamental part of object technology and have been incorporated in one form or another into most major object-oriented development methods. In the rush to jump onto the use case bandwagon, use cases have been perceived by some as either a panacea or as an end in-and-of themselves. Unfortunately, this has often led to the uncritical acceptance of use cases without any examination of their numerous limitations and ample opportunities they offer for misuse. The following provides an overview of the major risks associated with use cases:
Cure: Watch out when the use case model includes use cases that are not directly associated with an actor, but are associated with <<uses>> or <<extends>> relationships. Sometimes this is an appropriate way to model the use cases. But many neophyte use case modelers (especially those who are programmers, or who have a process modeling background) misuse these associations, functionally decomposing the problem, rather than focusing on the interactions between actors and the system.
More Use Case Pros and Cons from Knowledge Systems Corporation by Donald G. Firesmith
See the full list at the link, these are selections:
The Dangers of Misusing Use Cases
Because of their many important advantages and extreme popularity, use cases have become a fundamental part of object technology and have been incorporated in one form or another into most major object-oriented development methods. In the rush to jump onto the use case bandwagon, use cases have been perceived by some as either a panacea or as an end in-and-of themselves. Unfortunately, this has often led to the uncritical acceptance of use cases without any examination of their numerous limitations and ample opportunities they offer for misuse. The following provides an overview of the major risks associated with use cases:
- Use cases are not
object-oriented. Each use case captures a major functional abstraction
that can cause the numerous problems with functional decomposition that
object technology was to avoid. These problems include:
- The functional nature of use cases naturally leads to the functional decomposition of a system in terms of concrete and abstract use cases that are related by extends and uses associations. ...... This scattering of objects to use cases leads to the Humpty Dumpty effect, in which all the kings designers and all the king's coders are unlikely to put the objects and classes back together again without a massive expenditure of time and effort.
- The use case model and the object model belong to different paradigms (i.e., functional and object-oriented) and therefore use different concepts, terminology, techniques, and notations. ..........The simple structure of the use case model does not clearly map to the network structure of the object model with its collaborating objects and classes.
- Being created at the highest level of abstraction before objects and classes have been identified, use cases ignore the encapsulation of attributes and operations into objects. Use cases therefore typically ignore issues of state modeling that clearly impact the applicability of some use cases.
- Another major problem corresponds to the archetypical subsystem architecture that can result from blindly using use cases. Several examples in books and papers have consisted of a single functional control object representing the logic of an individual use case and several dumb entity objects controlled by the controller object.
- Use cases are defined in terms of interactions between one or more actors and the system to be developed. However, all systems do not have actors and systems may include signification functionality that is not a reaction to an actor's input. Embedded systems may perform major control functions without significant user input.
- Finally, the use of use cases as the foundation of incremental development and project tracking has its limitations. Basing increments on functional use cases threatens to cause the same problems with basing builds on major system functions.
- ------------------------------------------- Back to my comments:
- This is a good analysis of what is wrong with Use Cases. To some extent it might be a methodology catering to "process oriented" managers or management environment. Catering at the expense of good object design. Process oriented higher level opinionated "my way of doing things" management with focus on doing more than the things. They probably might do better as line supervisors.
- Use Case Diagrams for Bank Management Systems
No comments:
Post a Comment