Well Written Use Cases
Naturally Flow into
Service Oriented Architecture Solutions
Use Cases Written Using Building Requirements Consensus™ Methodology
Use cases that look like service oriented architecture (SOA) services is an intentional design goal of the Building Requirements Consensus™ Methodology. This result occurs whether the analyst understands SOA or not.
How can this be? The answer is in applying the three fundamental concepts of the Building Requirements Consensus™ Methodology - use case, system and role. In particular, the role concept that maps one-to-one to a specific use case is the main idea that produces SOA-like use cases.
Consider a common electronic calculator. It can be used to perform many different kinds of mathematical functions.
Let's look at it from the calculator's perspective. When the calculator is being used, does it have any knowledge of who or what is entering values or commands? No, it does not.
A calculator can easily be described as a service oriented architecture service. For example, Mary totals her monthly bills and later Paul calculates how much paint it will take for the family room and living room.
During the calculations, the calculator does not know anything about Mary or Paul nor does it know the meaning of the result it delivers - dollars for Mary or square feet for Paul.
The person using the calculator and the meaning of the result it delivers belong outside the calculator. They live in different systems; they do not belong to the calculator system.
All a calculator does is responds to input that it understands and delivers a result it knows how to calculate. The calculator does not care how, or if, anyone uses the result it delivers.
The concept of "not knowing" is called loose coupling.
Loose coupling is a cornerstone of service oriented architecture. (Page opens in a new window.)
The calculator is very loosely coupled with Mary and Paul because the calculator system has no knowledge whatsoever about them. Mary and Paul are loosely coupled with the calculator because they know that it is Mary's calculator that she let Paul use. However, this information is not pertinent to the calculations and most likely will not be modeled.
The Calculation Systems
The calculation diagram for Mary applying the Building Requirements Consensus™ Methodology will have three systems: 1) the Human Being system where Mary belongs, 2) the accounting system and 3) the calculator system.
There are also three systems for Paul: 1) the Human Being system where Paul (and Mary) belongs, 2) the house system and 3) the calculator system.
While the 1st and the 3rd systems are the same for Mary and Paul, the 2nd system varies because of the goal each one has during this execution of the Calculate Result use case.
Note: the goal for the use case does not change. It remains "Present calculated value" for anyone who uses it. It is Mary's and Paul's goals that differ. Those goals live outside the calculator and do not affect its functionality one iota!
A calculator is, in fact, a service. Interestingly, many objects in our daily life behave this way. They respond to events they understand and do what they know how to do to deliver a result. SOA imitates real life!
From SOA to Use Case Basics 101
From Service Oriented Architecture to Building Requirements Consensus™ Home