Use Cases Architecture

We have already learned the following three facts:

· A complex business process can be represented by a set of mini-business processes.

· A sub-process is a mini-business process or subset of activities logically grouped together.

· A use case can represent a sub-process.

· A use case isolation property tells us that the functionality of each use case can be programmed independently of any other use case.

The idea behind dividing a software product into use cases is simple: follow the entities (nouns) that a business process operates on. Each specific entity (noun) of the business process is what the use case is about.

Let's take another look at the following UML use case diagram, which defines the dental receptionist business process as four use cases in which the receptionist participates:

Looking at diagram, we can say that the administrator business process works with the following entities: patient, identity document, appointment, and visit. This means that we need to be able to collect and store data about these entities, for example in a database, which leads us to four tables and CRUD operations for each entity.

Given some existing database and going through the process of splitting the monolithic software product that uses it into use cases, we can say that we need a use case for each individual table in the database.

Ultimately, we can give another definition of a use case as a set of actions related to processing data of a particular entity, where CRUD operations are a subset of such actions .

In software engineering terms, a use case is a set of assemblies containing components responsible for handling the transitions of business subprocesses from the current state to one of the target states, where each assembly is a set of dynamic-link libraries (DLLs).

Table of Content Software Architecture Previous: Distributed Architecture Next: Layered Architecture