Design: A Projection of Requirements over Architecture

Abstract

This article attempts to portray a relation between the triad of Architecture, Requirements and Design.

This article revolves around the concept that design is a projection of requirements over a given architecture. It attempts to create a design given the architecture and requirements are available for the same with a graphical/mathematical approach.

The article explores geometric representation of the said ideas and then formulates algebraic techniques to explore the ideas in more detail.

Given a requirement such as login which takes a user name and password and has an operation authenticate which validates the given combination, the requirement may be implemented on architecture with a web interface, business layers, data access components, etc. The design may be derived as a projection or a shadow. This said mechanism of projection forms the basis of this article. The article attempts to describe this mechanism of projection and describes how to use it to derive architecture from a set of requirements and design.

This article begins with a set of definitions of terms used in this article, it then details the core idea of design projection which is the central theme of this article as a concept and shows the consciences of the usage. This is followed by a mathematical treatment of the subject using sets and group. The article concludes with unexplored areas and consciences.

Introduction

Software development is driven by three cornerstones: requirements, architecture and design.

Requirements form “what” of the problem. Requirements define what is to be done by the application. The architecture of the application is the blueprint; it defines how the problem will be solved in general and what participating agencies are. The architecture is a mega structure which generalizes the mechanism of how the requirements will be implemented. The design describes how a specific requirement will be implemented. It uses the blue print as described in the architecture and using requirements creates the participating components.

Consider an example, it is required to create an application wherein an application where a user can be searched by ID, name and by the department she/he works in. This requirement has three use cases:

1. Search User given the user id
2. Search User given the user name
3. Search User given the department

For this example, let us assume that a web based application will be available, with a UI layer, entity layer, a business layer, a data access layer and a table.

Each layer having a defined set of tasks and goals for example, the UI layer is responsible to obtain user input and convert it into an entity. It should call the relevant methods on business layer and display the returned result. This layer has the following responsibilities:

1. Capture of user input
2. Conversion of user input to Entity
3. Execution of business result
4. Display of result

Other layers will have similar well defined responsibilities.

Once the requirements and architecture of an application have been nailed down, the design of the application may be argued to be an algorithmic task provided proper modeling approach is present.

Consider the design of requirement “Search User given the user id” using the architecture “capture user input”. It clearly states that the user web front end should be able to capture the user id using a web page.

In this article, we shall discuss formalization using graphical and non graphical methods of the above stated design methodology.

Some Common Terms

Before we dive deep into the mechanism of projection of design, we will go through some common representations and terms used in this article.

Requirement – In this article, a requirement is defined as a set of variables on which a given operation is to be performed. Requirements are derived from use case and for this article will be detailed to a level by which creation of entity is trivial. The requirement has two dimensions; the representation and operation.

Consider the requirement “A user can be saved to database”. This requirement may be decomposed into a representation user and operation Save. In further course of this article, a mathematical representation of this will be detailed out.

Architecture – In the context of this article, architecture is layered architecture approach. Each layer will have well defined responsibilities. The architecture will have an ordered flow of execution control.

Design Projection

We now dive deep into the very core of this article which is interpreting design as a projection of requirements over architecture. This concept will be featured in this section graphically with an arbitrary set of simplifications to highlight the core of the idea while ignoring other details, such as how detailed the architecture should be. These topics will be taken up in later sections of the article.

Let us consider a very simple set of requirements in an application:

1. Save a user to the database

Let us first detail out the requirements in the established mechanism and then try to depict them graphically.

• Requirement – Save user given some user parameters into the database
• Representation – User: user name, first name, last name, password
• Operation – Save

Let us depict this as shown in Figure 1.

Now let us use a simple web based application architecture for the same with the following layers:

1. User Interface
2. Business Layer
3. Data access layer
4. Database

The responsibility of each layer so as to obtain tangible components is as under. A tangible component of an architecture is a statement which may be readily interpreted into a programming structure such as methods, classes or database components.

1. Web layer – This layer forms a user interface. It provides a web based UI for input and output of data. It converts input into a business entity. The tangible components are
   1. A Web Form
   2. Mechanism to call business layer
2. Business layer – This layer calls the database layer. The tangible components are
   1. A mechanism to call the DB layer
3. Data access layer – This layer calls the DB store to save or retrieve data
   1. DB access logic
   2. Conversion of entity to a structure understood by the database
4. Database – This is a RDBMS which stores the data. It will have tangible components as
   1. Database tables
5. Entity – A mechanism to transport user input, having tangible component
   1. Transport entity

It may be argued that once the tangible components are defined and the exact requirement definition is available, design can be readily created. This mechanism of design creation is defined as projection for reasons which will become clear as this example progresses.

The design is only a set of tangible items which are concrete. Some tangible items are influenced by the representation such as the Entity and the database while others are influenced by the operation or both. What influences the creation of the tangible item may also be defined as the part of architecture.

The design is thus an image of architecture with gaps of exact functional details filled in by the requirements.

It should be noted although there are reasons to group tangible components in layer as good architecture practices, this article will treat these decisions as arbitrary.

This mechanism is called projection because the requirements are projected through the architecture’s tangible items to form the design. Consider the analogy that requirement is a light of a given color and the architecture is a shape the design then forms a colored projection on a display as shown in Figure 3.

Let us further explore a part of this example where user save requirement is projected over the Web layer to form the design tangible items.

As presented in this more detailed example, a design is a process of making a concrete result from an abstract architecture which gives guidelines. To save a user, we need to fulfill the requirements of capturing the five attributes as an input. The architecture provides a general guideline that a web form should be present. The design focuses on these two aspects and projects that a web form captures the five attributes which should be present.

Till now in this article, architecture was defined was arbitrary. This was done to highlight the projection technique. We will take a quick look at the conceptual definition of layered architecture in context to the presented article.

Layered architecture is represented as a set of layers with each having well defined responsibilities. The layers are partially ordered with respect to execution flow. A responsibility is a well defined tangible component. This tangible component is a concept which is abstract and its presence produces design items. These well defined tangible components can be projected and are influenced by the requirements representation and/or requirements operations during projection..

Projection Algebra

This discussion will now formalize the concepts discussed in the previous section into a mathematical form. The discussion will start with the notation for various elements such as architecture, requirements and tangible items. It will then define operations to successfully model the operation of projections.

Till now, we have discussed two elementary concepts; the Requirement and the Architecture. Let us formalize their representation in mathematical terms.

Representations – Representation is a physical attributes. Examples of representations are User, Employee and Department. They are equivalent to entities. It should be noted that for the discussions it is not of interest if a representation is atomic such as age or composite such as a User (name, age, sex). In this article, the set E will be used to denote a set of representation, individual elements of representation will be denoted by e₀, e₁ etc.

Operation – Operation is computable P function which requires representation as the argument. For example, Save is an operation which requires a User representation. A set of operations in this discussion will be represented by O. The individual operation itself will be represented as o1, o2, etc. It should be noted that the definition of an operation may be interpreted to encapsulate representation, however for this discussion representation will be treated separately. This is done because the intent of an operation is to define a verb, the process or the intended steps to be performed with the representation.

Requirement – A requirement is a set of tuples created by combination of a representation and an operation. A requirement is represented by R. A requirement is an arbitrary combination of elements from the domain or representations and operations:

R ={(e,o) | e e E and o e O}

For example: {(User,Save), (User,Update)} is a set of requirements.

Tangible Item – A tangible item is defined as an atomic task which may be performed as part of the execution of a requested operation. Tangible items however lack exact details intent and hence can only have a generic algorithm to represent it. Examples of tangible items include Receive user input using a web form, operate on user input. A set of tangible items is represented by T in this article. It should be noted that for this discussion the relation of tangible item with representation and operation will not be considered.

Layer – A layer is a poset of tangible items which defines responsibilities to be performed. A layer is represented by a tuple of tangible items. A layer is represented by L. For example:

WebLayer = (Accept user as input, validate user, call the save method)

Layered Architecture – A layered architecture is a poset of layers which describe the general flow control. Architecture is denoted by A. For example:

Architecture = (WebLayer, BusinessLayer,DataAccessLayer,Database)

Architecture may be represented by replacing tuples of layers with tuples of tuples of tangible items. A tuple of tangible items may be represented as A[l] where l is layer name, for example:

Architecture[WebLayer] = (Accept user as input, validate user, call the save method)

It should be noted that layered architecture may be interpreted as a partial ordering of tangible components and the presence of arbitrary layer is a convenience to group them.

Design Item – Design is a tangible item in which details of intent are described by conjunction of requirements. Design is essentially filling the gaps around exact details of the problem description which are lacking at creation of tangible item.

A design item is a projection operation of requirement on a tangible item of a layer. The projection operation is denoted by x. The projection operation results in multiple design items on a given layer.

Consider the following:

Let e be a representation, o an operation and t_l a tangible item in layer l, the requirement is represented as (e,o) and the projection item is as (e,o) x t_l and denoted as ((e,o),t_l).

This is interpreted as a design item which performs the task t on representation e to contribute to operation o. Design items are represented as d.

For example if e is User, o is Save and t is accept input then design item may be interpreted as accept input of type user to save.

Design - Design is defined as projection of requirements over architecture. It is a set of design items in various layers.

D = R x A
D = {((ei,oi),tlk) | (ei,oi) e R and tlk e A[l]} 

Applications

The remainder of this article will detail out inferences and areas of possible application of the stated results. These are unexplored areas and only the initial approach for these has been discussed.

Design – The findings in this article have primarily been associated with design experience and the style of the author. It is a technique using which we have successfully designed many projects.

Design Automation – The ideas presented in this article are quite abstract. By applying constraint mechanisms of design automation may be created. For example, one may argue that there are only n operations possible such as Create, Update, Read, Delete, Sort, etc. which generic algorithms may be produced. The design representation can also be decomposed into primitive types. Using this information, it is possible to propose a solution which produces design. This would however require formalization of notation and representations. It will also require deeper exploration of tangible items.

Estimation – Some of the definitions used in this document lead to estimation of a number of programming structures, for example:

• Number Of Classes = n(R) n(A)
• Number Of Methods = n(E) n(O) n(A)

Other results of interest may also be computable such as what may define a static class, etc.

Other architecture styles – This document primarily focuses on layered architecture, application of the suggested technique in other styles is an area for exploration.

Conclusion

The ideas presented in this article are in a nascent stage. They are formulation and modeling of experiences of the author. It is strongly believed that they may form a new approach to design methodologies.

History

• 23^rd April, 2009: Initial post