Software is all about Changes
Software is all about Changes. Changes are the fact of every software development
life cycle. Generally, we follow the policy of “give what they want”.
We try to achieve 100% client satisfaction but we cannot avoid changes. We can only minimize changes or manage them efficiently. When we think of change management in software development terms, we usually tend
to think of requirements management with its requirements trace matrix or code
management through version control systems.
Most of the time we think change management is a phase of software management life
cycle, so we will handle those changes during that period but change management is an approach which needs to be followed during entire software development life-cycle or we
can say change management is an integral part of SDLC.
Change is inevitable. No matter how much you like your software right now it’s probably
going to change tomorrow. The harder you make it for your software to change, the more
Difficult it’s going to be to respond to your customer’s changing needs. Even small
changes can turn into big problems.
Business Analysis & Requirements
The Requirement Analysis phase is the most crucial phase of the software development life
cycle. The analysis phase defines the requirements of the system, independent of how
these requirements will be accomplished. This phase defines the problem that the
customer is trying to solve.
Always in a hurry!
We are always in a hurry. While gathering requirements from client during requirement
analysis phase generally we use “OK” “YES” “we understand” “no problem” kind of words.
At that time we have a mixed feeling should I ask or not. Basically we should ask questions
to the client. Try to put more and more questions and try to analyze the requirement.
Make rough sketches or use case diagrams.
This will help in minimizing future changes. If we have the clear understanding of
customer business requirements and process then only we can achieve maximum client
satisfaction and can minimize changes.
Design (Object Oriented Analysis and Design)
Top to Bottom approach:
While designing the architecture we should try to have the Top to Bottom approach. In the
below figure the “Top” area is broader than the “Bottom”. Here the Topmost area
represents the base architectural classes and bottom area uses those classes or the
implementation of base classes. This model is independent of domain or business
requirements but we can design our business entities (Objects) according to this approach.
It is easy to handle changes (fixable Design ) so when we change base class the bottom will
automatically get changed no need to change at each and every page or class. This
approach is good for large applications as most of the things are at top level.
How to achieve:
As there could be many types of relationship can be implemented among the Business
Entities (Classes).But Aggregation, Composition, and Generalization are used to implement
top to Bottom approach.
Association, Aggregation, Composition, Abstraction, Generalization, Realization and Dependency
These terms signify the relationships between classes. These are the building blocks of
object-oriented programming and very basic stuff
Association
Association is a relationship between two objects. In other words, association defines the
multiplicity between objects. You may be aware of one-to-one, one-to-many, many-to-one,
many-to-many all these words define an association between objects. An aggregation is
a special form of association. A composition is a special form of aggregation.
Example: A Student and a Faculty are having an association.
Aggregation
Aggregation is a special case of association. A directional association between objects.
When an object ‘has-a’ another object, then you have got an aggregation between them. The direction between them specified which object contains the other object. Aggregation is
also called a “Has-a” relationship.
The composition is a special case of aggregation. In a more specific manner, a restricted
aggregation is called composition. When an object contains the other object, if the
contained object cannot exist without the existence of container object, then it is called
composition.
Difference between aggregation and composition
The composition is more restrictive. When there is a composition between two objects, the
composed object cannot exist without the other object. This restriction is not there in
aggregation. Though one object can contain the other object, there is no condition that
the composed object must exist. The existence of the composed object is entirely optional.
In both aggregation and composition, the direction is a must. The direction specifies which the object contains the other object.
Example: A Library contains students and books. Relationship between library and
student is aggregation. Relationship between library and book is composition. A student
can exist without a library and therefore it is aggregation. A book cannot exist without a
library and therefore its a composition. For easy understanding, I am picking this example.
Don’t go deeper into example and justify relationships!
Abstraction
Abstraction is specifying the framework and hiding the implementation level information.
Concreteness will be built on top of the abstraction. It gives you a blueprint to follow while implementing the details. Abstraction reduces complexity by hiding low-level
details.
Example: A wireframe model of a car.
Generalization
Generalization uses an “is-a” relationship from specialization to the generalization class.
Common structure and behavior are used from the specialization to the generalized class.
At a very broader level, you can understand this as an inheritance. Why I take the term
inheritance is, you can relate this term very well. Generalization is also called an “Is-a”
relationship.
Realization
Realization is a relationship between the blueprint class and the object containing its
respective implementation level details. This object is said to realize the blueprint class. In
other words, you can understand this as the relationship between the interface and the
implementing class.
Dependency
Change in structure or behavior of a class affects the other related class, then there is a
dependency between those two classes. It need not be the same vice-versa. When one
class contains the other class it this happens.
Example: Relationship between shape and circle is a dependency
Let’s Look into the Code…..
In my application, I need to create my own control library. So I need some reusable classes
which can be used during control library development by the control developers.
So I have created two classes “StringHelper” and “ViewStateHelper” there are the helper
class to support control development.
StringHelper Class is used to display a string representation of a given value (see fig)
ViewStateHelper Class is used to check the viewstate object for a value using the
parameterName as the key. If key exists the value is returned, otherwise the default value is
returned
* Reduces redundant coding when checking for values in ViewState
These both the classes will reduce redundant coding and also saves the development time
this will also maintain application coding standard. Most importantly this approach will
make your design reusable and flexible. If you made any change in the base classes (top
Classes) the control library will automatically get changed.
I have customized TextBox control and added new “DataField” Property. Now we need
maintain the state of this new property and that could be easily handled by the
ViewStateHelper Class
I have also added new “SetValue” Property of Object type to set the Text of the
TextBox automatically
As it is a generic property now the developer can pass any type of value from the page. But
the Text property of TextBox only except String value so we need a handler which can
handle this conversion.
So there is a need for a new class which can handle this conversion and that class can be used
by Entire control library. To achieve that we have created “StringHelper Classes“(see fig
below)
So there is an Aggregation relationship between TextBox, ViewStateHelper and
StringHelper Classes
UML Diagram:
