Use Case Diagram


I want to make a top-down approach towards software modeling. I start with learning the practicality of Use Case Diagram.

Use Cases

A system is composed of one or many structural entities. In order to serve its purpose, a structural entity must have one or many capabilities. A Use Case captures one of the capabilities of the system. A use case is required to have visible capability to Actor(s), an object entity external to, and interact with, the structural entity / system. Visible capability means that a use case capability must have a meaning to an actor by means of either sending information to or receiving information from the actor.
In order to construct a use case, simply complete the following sentence:

A (system / structural entity) is capable to [Use Case].

To further complete the description of the system, simply complete either of the following sentence:

A (system / structural entity) can [Use Case] a(n) [Actor].


A(n) [Actor] can make the (system / structural entity) to [Use Case].

System Boundary

I understand the philosophy of whoever came up with this use-case-diagram concept that includes system boundary, I just don't like it.

Any human made system is finite. It is finite so the system creator can maintain it The human mind is only capable to create, design, and implement a finite, bounded set of logic at one given time frame to maintain a complete control over the system they create. Anything that works outside a boundary is called either a probability, uncertainty, or chaos, because they cannot be fully understood by human mind except by theories and conjectures. As for a human made system, if the capability of the system gets outside boundary, it is deemed unstable, unorganised, or simply, broken.

Thus, in the sense of Use Case Diagram, a System Boundary is, without a doubt, the boundary of the system. The system or structural entity's capabilities, and therefore Use Cases, are contained within the system boundaries. What is outside the boundary, including Actors, is external to the system.


Actors are object entities external to, and interact with, the structural entity / system. Objects can be another system or structural entity, anything that interacts to the system. Sometimes, in practice, it is not required to also design the actors. The abstraction of actors to describe their interactions to the system is enough in cases when designing these object entities are beyond the system creator's scope, such as designing pilots, drivers, airplanes, or cars, as actors.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License