Published:
12 Jun 2007
|
Abstract
This article examines all of the artifacts involved in the design phase, like Use Case Diagrams, Sequence Diagrams, Database Modeling tools and Class Diagrams, etc. with real examples. It also discusses some important documents like Integrated Design Documents (IDD). |
|
by Uday Denduluri
Feedback
|
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days):
35471/
61
|
|
|
Introduction |
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.
|
Artifacts involved in Design |
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 documents |
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 |
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 |
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
|
Relationships among the classes |
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.
|
References |
|
Conclusion |
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.
|
|
|
User Comments
Title:
Mr.
Name:
PeterB
Date:
2007-06-12 10:39:37 AM
Comment:
If Integrated Design Document deal with a module and it's interaction with other modules within the project or system,
Which document will provide the complete Resources:
http://envstudies.brown.edu/thesis/2004/Molly_Macgregor/How_When/Integrated_Design.htm
Many More
|
|
Product Spotlight
|
|