c) Design Classes and Diagrams - A class
is a description of a set of objects that share the same responsibilities, relationships,
operations, attributes, and semantics. The associated class diagram is a visual
representation of the class that shows the attributes, operations, and static
relationships (associations, subtypes) of a class. Once modeled, most modeling tools such
as Rational Rose will provide the capability to generate the attribute and method
signature code as well as the associated documentation into the source code. Beyond this
capability, Rational Rose provides the ability to read the design model and generate body
code into the methods. When new classes are built based upon various development
frameworks (e.g., Java Development Kits such as JDK, JSDK, EJB), many of the methods that
are implemented in every class can be code-generated based upon the design specification
contained in the model. This strategic step will reduce the time required to code, unit
test, and code review each class.
d) Sequence Diagrams - Because the goal of
object-oriented design is to produce very small cohesive methods in well-defined classes,
it can be difficult at times to understand the interaction between various objects and
their corresponding methods. Sequence diagrams are valuable to visually communicate the
interaction between the various objects.
e) State Diagrams - A state diagram describes the
dynamic behavior of objects in terms of state transitions. They are particularly important
to designers and to the person that unit tests the modeled object.
f) Data Model - The data model describes the logical
and physical representation of persistent data in the system. Tables, columns, and keys
are included in the model. Once modeled, most modeling tools such as Rational Rose will
provide a mechanism to create the tables in the database.
g) System Test Plan - A test model or plan
delineates what is to be tested and the target of the test (entire system or part of the
system). The role of the test model is to communicate what is to be tested and how to test
it. The test model includes a collection of test cases. Test cases define a collection of
inputs, execution conditions and expected results. The majority of the test cases are
derived from use cases, scenarios, or use-case realizations, and correspond to an
execution of a use case as it traverses the test target.
The cornerstone of the iterative construction process is
reuse. Reuse is the process of designing and implementing software components using
existing software assets. Reuse can be achieved in various areas including the reuse of
development processes, design models, design patterns, development frameworks, and code.
Reuse is an integral part of software engineering and
enables organizations to reduce the development time and risk.
Reuse Example
If you need to develop a new business class called Order,
what kind of software reuse can be achieved? If the order must be persisted to a back-end
database and a persistence framework was available to provide services to retrieve and
maintain objects, then the first source of reuse would be to define the new Order class
based upon the Persist class (inherit from it). The Persist class would
define common data and operations for all objects of this type. Whatever services the
Persist class offered would be reused by the derived class (Order class). Because the new
Order class is built based upon the foundation class, we are achieving both design and
code reuse.
Since other application classes have been built based upon
the Persist class, the class diagram for the Order class can easily be created by coping
the model from another business class such as the Customer class. The Customer class is a
design pattern for defining the new Order class.
Benefits of Reuse
When new components are built on proven foundation
frameworks, design, coding, and unit testing can be significantly reduced.
Software reuse provides a basis for dramatic improvements
in quality, reliability, and reduced costs for software development and maintenance.
Because reuse is a by-product of good software engineering
practices, the risks associated with new development are significantly reduced. |
