This article explains various artifacts involved in the design phase. This article can be considered as an extension of my previous article Artifacts involved in the Requirements phase. The design phase is considered to be the key phase after the requirements phase. The design phase involves understanding the requirements and building the design and architecture of the system based on the same. It is to be understood that unless a requirement is clear, the design should not be started.

Many (naïve) developers always feel that documentation towards the design is a big wastage of time and resources. They feel that instead of doing the same if they spend that time in construction (coding), it would yield better results. Unfortunately, this will lead to serious problems. Let us discuss why we need to document the artifacts related to design.

1.    Quick and efficient Knowledge Transfers – With the standard tools or conventions that we follow, the design can be easily understood in a quick and efficient manner. UML is the widely adopted standard throughout the industry.

2.    Process centric and not People centric – By documenting the artifacts it is a Process centric approach and not people centric. At least theoretically, this approach will have less of an effect due to the attrition rate.

3.    Maintainability – By documenting all the artifacts related to design the software maintainability is at ease.

4.    Upgradeability – All the up gradations done to the system will also be documented. This will enable the future versions of the software to be built easily.

Let us start listing all the widely used artifacts and then understand each of them in detail.

·         Integrated Design documents

·         Sequence Diagrams

·         Class Diagrams

·         Component Diagrams

Integrated Design document (IDD) speaks about the design and architecture of a module in the proposed Application or System in detail. Its main focus would be on the integration aspects with other modules. If the module is a service then it should explain the interface that will be exposed to all the clients so as to use the service. If the module is a client then it explains all the services used to perform the operations. IDD also gives a brief on the total application if the module is targeted to a particular application in general. It is to be noted that IDD document is generally prepared for generic components or reusable components. Let us discuss the contents of the IDD document.

1.    Introduction – Brief of what the Module does.

2.    Architecture Description – A Diagram consisting of all the components in the Module showing how they are interacted with each other supported with a verbal explanation. This section can also have the design patterns followed and an explanation towards the same.

3.    Proposed Application – It explains what kind of application can use this module.

4.    Interfaces exposed – To use this module as a service, the interfaces are exposed by the module. It also explains the configuration settings with some real time examples. This is the most important section as this deal with the integration with other modules.

5.    Dependency of other modules – A module can consume another module. For example, Exception framework consumes logging framework. Exception uses logging to log the exceptions. Such kinds of dependencies are illustrated here.

6.    Database Design with all the Tables – In case a module is using a database, the design of the database is explained in brief.

Sequence diagrams are one of the most popular UML diagrams explaining the dynamic behavior of the software. A Sequence diagram explains the object life cycle from its creation to its termination with respect to other objects. The two important parts of a sequence diagram are lifeline and messages. A lifeline shows the scope of the object. It represents the lifeline of the object showing the scope of the object from creation to termination. A message generally represents a method of an object or an operation of the object. In sequence diagrams we can even show the self methods of an object. Figure 1 shows an object "SomeObject" with a message "Some Message." The vertical rectangle shown defines the scope of the object. It should be noted that the scope of the object shown is always relative to another object.

Figure 1

Let us take a meaningful example to understand a sequence diagram. Let us explain a simple log-in page authentication. For simplicity, let us omit the database provider and limit our self with the authentication provider. Figure 2 shows the object LogIn.aspx page with user name and password given by the user and clicks on the button Log-In. After this the Authenticate Credentials method gets called for the object AuthenticationProvider.

Figure 2

 

Class diagrams show the static behavior of the software. A class diagram depicts Classes, Interfaces, and methods with their relationships. Let us see how a class is shown in a Class diagram. As shown in figure 3 there are three parts of a class diagram. The class name, members and Methods. A member can be a public or private variable. A method can be a public or private. The return type of the method should also be shown. UML does not have standard for C# properties, but we can use stereo types for defining the properties. Stereo types are the way in which we can customize a UML diagrams. A stereo Type is represented as <<"Some Stereo Type">>.

Figure 3

Figure 4 shows the usage of stereotypes in class diagrams. A stereotype <<Interface>> has been created for showing that this is an interface and not a Class.

Figure 4

Showing the relationships among the classes is the most important aspect of the Class diagram. To show the design pattern we need to show the classes with their relationships. Let us understand different types of relationships.

·         Association – Association is the simple relation between two classes. In most of the cases it is the users relationship. Class A uses Class B. Therefore, Class B is associated with Class A.

·         Generalization – Generalization is the Base class and child class relationship.

·         Aggregation – Aggregation is the whole and part relationship. Class A forms the part of Class B.

·         Composition – Composition is a special type of Aggregation where the life time of the part is controlled by the Whole.

Figure 5 shows the Prototype design pattern showing the relationships between the client, Prototype and the ConcretePrototype class.

Figure 5

·         Prototype – Declares the base interface for cloning itself(Base class).

·         ConcretePrototype – Implements the declared interface for cloning (Implements the base class). The relationship shown with the base class is Generalization.

·         Client – Creates the new object by asking a prototype to clone itself. Hence, the relationship is a simple Association.

Prototype

The design phase is considered the key phase after the requirements phase. The design phase involves understanding the requirements and building the design and architecture of the system based on the same. The article has exposed some of the important artifacts for the design phase like IDD, Sequence diagrams and Class diagrams.