Finally a book on UML that makes sense to me (and is short enough so I was willing to read it, in one morning).
Milestone 1: requirement review
Everything starts with an analysis of the problem at hand. One thing
learned and I'd like to clarify is
it is a set of constraints (thus the word
should). Requirements often cause confusion as they are taken as the
system's objectives → in essence they are, but they are measured
as a set of conditions that the system will have to behave
within boundary. Thus, viewing them as the law for your
design, it's a valid test to your test, but your design
can come in many forms, and that's where engineering has some fun.
So it becomes clear & natural that design and implementation are like people living in society → his behavior is completly boxed by law he has to obey, that's the minimal. Anything that no law permits nor prohibits (functions that links to no requirements), well, is just to keep the developers happy.
Any description of what the client is trying to do or what they want. There is no restriction at all. What comes out of it are:
- domain modeling
- Uses shall, must.
- Have a N-N mapping to use case → traceability from requirement → design → code → test.
- Many ways to cut it: functional requirement, data requirement, performance requirement, and so on.
- A use case describes a unit of behavior.
- Requirements describe the laws that govern that behavior.
- Functions are the individual actions that occur within that behavior.
Quite similar to ERD from Django graph. The difference is that it doesn't yet care attributes or methods, and they are not necessarily translated 1-1 into a DB table.
- Pick out the
nouns→ domain models
Formulating 3 relationships:
- generalization: parent → children class
- aggregation: roll up, eg.
- association: the closest understanding I can get is to describe the many-to-many relationships.
This is the soul of UML (or at least for this book) since everything derives from it.
- Inputs: domain models & requirements.
- Two types:
- basic course of action
- alternative course of action → thus we can cover any exceptions we need to handle.
- Go expansive on case statement. We want to derive two things out of
- domain objects
- What helps ← visual and mockup user experience:
- GUI prototyping
- write a user manual in use case statement, or reverse engineering case statements from a legacy user manual
- wire frame, or any kind of GUI mockup
- what happens → then → then.... use the word
- what else can happen? → alternative course
- what happens → then → then.... use the word
- Being thorough is key
Once you have done so called analysis, you reach the first milestone
— requirement review. That's when client should sign off to
recognize these set of
use case do represent what they want to do.
Milestone 2: design review
With a set of use cases, we can break them down into design
elements. This book talks in context of OOD, thus words like
object are essentially a CLASS in code. We don't have to be
bound by this. Instead, taking
model as an abstract — it can
be a database table, or a service — it's just a representation
of a logical element that describes our view of breaking down the
initial problem into a set of items who interacts with each other.
Robustness diagram is optional. It is the transition from problem domain → solution domain because it starts to speak using design language, not natural English (as in use case) anymore.
Robustness diagram is essentially a MVC framework. This is optional in the sense that this is a transition between problem domain to solution domain.
- Three types of objects:
- boundary obj ← interface, UI falls in this category →
- entity obj → can result in more domain models → the
- control obj → will be translated to helper models, methods
- boundary obj ← interface, UI falls in this category → the
- One diagram per use case
- The good thing about robustness diagram is, there is strict rule of
what is allowed:
- Actor can talk only to boundary objects.
- Boundary objects can talk only to controllers and actors.
- Entity objects can also talk only to controllers.
- Controllers can talk to both boundary objects and controllers, but not to actors.
This is where the solution domain starts. Sequence diagram represents detailed design.
- Per use case ← both basic course and alternative course, try to fit them to the same diagram.
- On the side of sequence, note which use case it is for → traceability.
- We will end up with a list of
- allocation methods to class ← design pattern, eg. class factory vs. iterator
- Per class from sequence diagram, but cherry pick the important ones ← if it has only two states (on/off), don't bother.
- Three types of events:
- entry: do this when you enter this state
- exit: do this when you leave this state
- do: do this when you are at this state
- "guard": condition (True/False)
Milestones 3 & 4: development and UAT
UML doesn't address development. For completeness I'm adding two more milestones here:
- dev: topics such as test case fall into this place.
- release: the only thing matters is the UAT, which should come straightly from use cases.
Here I also want to highlight the separation between development tool
from test tool → programming your solution in Python does not
dictate you to test in Python. If you look at the two type of
test cases, I think unit test (whitebox) is tightly determined by
implementation details → how thorough I traverse code paths
if-else). It's often a matter of convenience to write them
in the same language because the language itself offers a toolset for
the purse, for example, Python's unit test framework.
blackbox cases have not such restriction — performance
test can well be done using a tool that has no relevance with Python
whatsoever because it only concerns
use case which represents
requirements! Therefore, these tests are what UAT is about. The
whitebox tests, on the other hand, are for management purpose so you
can have control of quality.
Now, this separation of purse is not to support that quality is just for the internal use as long as UAT passes. In practice, use cases (= requirements) are simply not possible to address all qualities. Again going back the analogy of requirement being the law you obey in daily life, law often tells you what not to do, but does not tell you what you should do ← you can always live a despicable life but being a lawful citizen at the same time.
We have a cowboy named Bill Bob, who is driving down the road at 80 miles an hour while drinking beer, scratching, and tossing the empty beer cans out the window of his pickup truck.
- domain models & relationships
- basic course use case diagram
— by Feng Xia