Software Product

This chapter defines a software product, software program, and their structure.

Software Product and Software Program Definitions

There are many reasons why software products are developed. For example, replacing paperwork with digital data, automating tedious tasks, or conducting data analysis using collected data, to name a few. But in any case, to be useful, a software product must reflect a set of physical business processes. Each such physical business process must be represented by a separate digital analogue - a program or application. For example, a software product “Dental Clinic's Information System” may consist of a website and mobile application where patients can make an appointment with a dentist, desktop applications for receptionists, drug providers, dentists' workstations, and so on.

That is, a software product is a digitized representation of a set of logically related physical business processes , and a software program, or application, is an indivisible unit of this set. That is, a software program or application is a digital representation of a business process .

A software product can be as complex as an information system or as simple as a calculator. This means that in some cases, a software program can represent an entire software product, which allows us to say that the software product represents a digitized business process, or a software product is a digitized business process .

Software Product Structure

We have already learned the following facts: a business process is a set of sub-processes, a use case is a sub-process, therefore a business process is a set of use cases. This knowledge allows us to rephrase the definition of a software product as follows: a software product is a set of digitized use cases , or a software product is a set of programmed use cases :

The use case isolation property tells us that the functionality of each use case can be determined independently of any other use case. This means that each use case can be programmed independently of every other use case:

Most of the programmed use cases will be specific to the software product, but some of them, due to their versatility, can be included in many software products if the functionality they provide satisfies the requirements of the software products. For example, “Person Registration” use case can be reused in any software product that requires person registration.

So, we can say that any software product can be assembled from programmed use cases. But there’s a catch: the use cases are isolated from each other, unaware of each other’s existence, and therefore cannot represent the entire software product on their own.

One piece is missing – the part that knows how to connect use cases together, controlling the movement of the entire business process flow from the beginning of the business process to the end, moving it through the use cases according to business rules. This missing piece is an “Application Use Case” — a very special use case that can do all of the above:

Functional and Non-functional Architecture

The combination of use cases represents the business functionality of a software product or Functional Architecture. Functional Architecture is an architecture that represents the functionality of business process .

Functional Architecture depends on Non-functional Architecture. A non-functional architecture does not reflect the functionality of a business process, but supports it by providing the underlying infrastructure for exception handling, logging, communication between application components, etc. Non-functional Architecture is a set of components that serve a Functional Architecture, resulting in the entire software product being functional . Components of a non-functional architecture are typically implemented once and reused across many software products:

Software Product Logic

From the chapter “Business Process Activities,” we learned that a software product requires different logic to perform different actions when a business process transitions from one state to another.

In end-user facing software, the transition is initiated in Presentation Logic. Presentation Logic sends a request to Business Logic with all the data collected from the user input.

Business Logic redirects request to Data Processing Logic for preparing all the necessary data needed to make a decision about the target state of the business process after transition completion.

Data Processing Logic coordinates the data preparation process by working with Data Access Logics and other Data Processing Logics.

Data Access Logic interacts with data storage to bring the requested data to Data Processing Logic.

Business Logic analyzes the prepared data according to business rules and makes a decision about the target state of the business process.

The following diagram shows the relationships between the various logics of the software product:

A software product requires different logic to perform different actions when a business process transitions from one state to another, since the responsibilities of each such logic are unique. The uniqueness of each logic tells us that the functionality of each such logic can be determined independently of any other logic. This means that each such logic can be programmed independently of any other logic:

Alternative Definition of a Software Product

We can now give another definition of a software product by saying that  a software product is a collection of functional architecture components logically grouped into use cases and various logical layers, served by components belonging to the non-functional architecture layer.

Table of Content Introduction into Business Process Previous: Pipeline of Activities