How can you discover why the system is designed the way it is? How can
you learn which parts of the system are stable and which parts aren’t?
This problem is difficult because:
• The lessons learned during a development process are rarely
recorded in documentation. Furthermore, the developers’ perceptions
and memory of design decisions tend to warp over time. Therefore,
you can only rely on source code and must reconstruct the
learning process from there.
• The system is large and has been released in successive versions, and
therefore you have a large quantity of source code to analyze. Text
comparison tools (such as Unix diff) will not scale up for the sizes
you’re dealing with.
• Even if you have a tool to identify the changes between two subsequent
releases, most of the changes will concern adding new functionality.
For the reconstruction of the learning process and how this
consolidated into the class design, you’re main interest lies in what
happened with the old functionality.
Yet, solving this problem is feasible because:
• You have a good understanding of the system’s structure (for example
obtained via Initial Understanding), so you’re able to focus on
• You have access to the subsequent releases of the system, so you can reconstruct
the changes by comparing the source code of the versions.
• You have the means to examine what happened with individual
source code entities. For instance, you have a metrics tool at your disposal,
which allows you to quantify the size of entities in the sourcecode
and use these numbers as a basis for comparison. As an alternative,
you have a configuration management system that can provide
you with information about particular changes to source-code entities.
142 CHAPTER 5. DETAILED MODEL CAPTURE
• You have enough expertise with refactorings in the implementation
language being used, so you are able to recognize refactorings from
their effects on source-code. Moreover, once you know which refactorings
have been applied, you can use this expertise to make an
educated guess at the underlying design rationale.
• You have a source-code browser that allows you to query which methods
invoke a given operation (even for polymorphic operations), so
you can find out dependencies between classes and investigate how
they are affected by the refactorings.
Use the metrics or configuration management tool to find entities where
functionality has been removed, because such entities are a sign of a consolidating
design. Also, look for entities which change often as these may
point you to an unstable part of the design.
Your goal is to get a feeling for how and why the system has evolved to
its current state. In particular, you want to understand which parts of the
system have been heavily refactored, which parts have become stable, and
which parts are hot spots of activity.
Portions of the software system that have been heavily extended are
simply a sign of growth, not of evolution of the design. On the other hand,
portions where software has been removed are signs that the design of the
system has been altered. By understanding how it has been altered, you
can obtain insights into the stability of the design.
Unstable design. If you detect repeated growth and refactoring in the same
portion of the system, that should be a sign that the design is unstable. It
may indicate opportunities to redesign that portion of the system to better
accommodate the kinds of changes and extensions that habitually take
Mature and stable design. A mature subsystem will exhibit some growth
and refactoring, followed by a period of stability. Early versions of the
subsystem will show growth followed by refactoring, followed by a period
in which only new classes and subclasses are added. As the hierarchy
stabilizes, classes near the top of the hierarchy will exhibit only moderate
growth, but little refactoring.
eagle081183 on How do I debug a VBScript… los angeles dui atto… on VMWare Server network Bridge… Fifa 14 Gratuit on 2010 FIFA World Cup Spons… another nike bot on VMWare Server network Bridge… Dao Phuong on Đề thi cao học Đại học Bách Kh…
- January 2018
- December 2017
- November 2017
- October 2017
- July 2017
- June 2017
- May 2017
- April 2017
- April 2015
- March 2015
- January 2015
- November 2014
- October 2014
- September 2014
- April 2014
- February 2013
- January 2013
- October 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- October 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- October 2010
- September 2010