Home > Archive > Software Engineering > May 2005 > Decomposition of an exisiting large system
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Decomposition of an exisiting large system
|
|
|
| We are working on decomposing our system to sub-systems and modules.
The rationale is very clear (increase deployment flexibility -
versioning per module rather than per the whole software, compile each
module separately, etc.) however the way towards it is rather vague. I
believe that we should analyze the existing architecture, and just
start up top down, with analyzing and fixing what we know (in a
software engineering metrics) is "wrong" - for example - cyclic
dependencies etc. While doing that we can get a better understanding of
what we would like to do in the later future. Another option is to
start from specifying our "dream architecture" - where we would like to
be, and then derive from that what we need to do. I am a little afraid
that this is too ambitious on a very large scale system (written fully
in Java). Would like to get some insights from anyone who have some
experience with such a process.
Thanks
| |
|
| zets wrote:
> We are working on decomposing our system to sub-systems and modules.
> The rationale is very clear (increase deployment flexibility -
> versioning per module rather than per the whole software, compile each
> module separately, etc.) however the way towards it is rather vague.
You are asking how to refactor a legacy system. Read /Refactoring to
Patterns/ by Josh K. for the architectural goals.
Refactor by making the smallest possible edits - each so small that you
could undo it manually if you felt like it - and run all your tests between
each change.
If you don't have tests, read /Working Effectively with Legacy Code/ by Mike
F.
--
Phlip
[url]http://www.c2.com/cgi/wiki?Z Land[/url]
| |
|
| 1. No we don't have tests.
2. I'm asking mainly on the strategy: either start with local
maximization (solve things that need to be refactored, and hence move
towards a better composed system) or start with a level 0 "dream
architecture" and then start adjusting the system towards this
architecture.
| |
| Neeraj 2005-05-24, 3:56 am |
| zets,
You suggest two approaches:
1. Refactor code and make local improvements to architecture
2. Define optimal architecture and and make incremental improvements
towards it
Sometimes, code becomes so strongly coupled that people come up with a
third option - go back to the drawing board and re-implement. This is
almost always the highest risk option. Therefore, you have done well to
narrow your approach to one of the two that you list.
The difficulty with the first approach is that without a clear view of
the current hierarchical decomposition it is difficult and inefficient
to get the architecture right purely by local improvements especially
when there is a large amount of legacy code and a team of developers
who don't all share the same view. The difficulty with the second
approach is that it is very hard to come up with the "right"
architecture up front.
I think that your best bet would be to first examine what your current
architecture is and then define how you would like to change it. Since
you have the system already developed, I would suggest that you get the
top level decomposition correct initially and focus progressively on
lower levels over time. This means identifying dependencies that are
problematic at the top level before delving into dependencies that
might be problematic at lower levels.
I have experience doing this kind of analysis for many large systems
(several of which have been java). I have also done research on this
subject which I would be happy to forward to you. Please check out our
web site for more information and feel free to email through our
website.
Neeraj Sangal
Lattix, Inc
www.lattix.com
| |
|
|
Neeraj wrote:
> zets,
>
> You suggest two approaches:
>
> 1. Refactor code and make local improvements to architecture
> 2. Define optimal architecture and and make incremental improvements
> towards it
>
> Sometimes, code becomes so strongly coupled that people come up with
a
> third option - go back to the drawing board and re-implement. This is
> almost always the highest risk option. Therefore, you have done well
to
> narrow your approach to one of the two that you list.
>
> The difficulty with the first approach is that without a clear view
of
> the current hierarchical decomposition it is difficult and
inefficient
> to get the architecture right purely by local improvements especially
> when there is a large amount of legacy code and a team of developers
> who don't all share the same view. The difficulty with the second
> approach is that it is very hard to come up with the "right"
> architecture up front.
>
> I think that your best bet would be to first examine what your
current
> architecture is and then define how you would like to change it.
Since
> you have the system already developed, I would suggest that you get
the
> top level decomposition correct initially and focus progressively on
> lower levels over time. This means identifying dependencies that are
> problematic at the top level before delving into dependencies that
> might be problematic at lower levels.
>
> I have experience doing this kind of analysis for many large systems
> (several of which have been java). I have also done research on this
> subject which I would be happy to forward to you. Please check out
our
> web site for more information and feel free to email through our
> website.
>
> Neeraj Sangal
> Lattix, Inc
> www.lattix.com
Thanks very much for your insights. Just to clarify, when you are
suggesting to start up with "getting the top level decomposition
correct", do you mean by (as you suggest in the following sentence)
identifying top level dependencies (which seems natural to me) or by
re-examining the overall top level decomposition (which seems to me
like something that I can get back to in a later phase). I have no
experience in decomposing legacy systems. If you could recommend also
some tools, it would be great. I tried using Headway ReView, for
getting the dependencies, it was very helpful (although alittle scary
to see all dependencies). Also used MagicDraw.
Thanks,
Zets
| |
|
| zets wrote:
> Thanks very much for your insights. Just to clarify, when you are
> suggesting to start up with "getting the top level decomposition
> correct", do you mean by (as you suggest in the following sentence)
> identifying top level dependencies (which seems natural to me) or by
> re-examining the overall top level decomposition (which seems to me
> like something that I can get back to in a later phase).
When you refactor, make small changes, and pass all tests between each
change. If you have enough tests, the code will remain releasable between
each tiny incremental change.
Under such refactors, fixing the low-hanging fruit is by far the optimal
strategy. Start at the level of individual code statements. Suppose two
methods concatenate the same string. Perform Extract Method Refactor to
create a common string concatenator. Keep going with the low-level obvious
stuff, until the only remaining refactors are the high-level ones that
satisfy your top-level decomposition.
Don't refactor from hard to easy, refactor from easy to easy.
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
|
|
Phlip wrote:
> zets wrote:
>
>
> When you refactor, make small changes, and pass all tests between each
> change. If you have enough tests, the code will remain releasable between
> each tiny incremental change.
>
> Under such refactors, fixing the low-hanging fruit is by far the optimal
> strategy. Start at the level of individual code statements. Suppose two
> methods concatenate the same string. Perform Extract Method Refactor to
> create a common string concatenator. Keep going with the low-level obvious
> stuff, until the only remaining refactors are the high-level ones that
> satisfy your top-level decomposition.
>
> Don't refactor from hard to easy, refactor from easy to easy.
>
> --
> Phlip
> [url]http://www.c2.com/cgi/wiki?ZLand[/url]
So are you suggesting bottom up approach? As I was thinking more, to
look at the top level and see the problematic relations and
dependencies, and start by detaching them. Then go inside one subsystem
and do the same recursively.
| |
| Neeraj 2005-05-26, 3:57 am |
| Zets,
One thing that you could do would be to look at the existing
documentation and/or by asking the architects how they would decompose
the system. As an example, a large number of systems decompose into a
layered architecture, with layers such as "user interface",
"application", "domain", "infra-structure" etc.
Distribute your code into these layers and look into the resulting
dependencies. The resulting dependencies will suggest whether you got
the decomposition right and also how coupled your system has gotten.
You may have to iterate and move things around to get the architecture
that matches what it actually is.
Our approach uses a method based on Dependency Structure Matrix (DSM)
to allow you to rapidly and easily create the architecture of the
software system. You can then specify design rules against which the
architecture can be tested at any time. These become part of your
standard tests. Architectural violations can then be caught as soon as
they are introduced preventing the quality degradation that is quite
common.
You can get more information at the website including a number of
papers which describe the technique in greater detail.
Neeraj Sangal
Lattix, Inc.
www.lattix.com
| |
| H. S. Lahman 2005-05-27, 4:01 pm |
| Responding to Zets...
> We are working on decomposing our system to sub-systems and modules.
You might want to check out the category Application Partitioning on my
blog for a systematic approach to such decompostion.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH
|
|
|
|
|