Home > Archive > Software Engineering > July 2006 > Multiple OO project management
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 |
Multiple OO project management
|
|
|
| Hi
I have multiple OO projects to manage.
They are connected one to each other.
1. Common Project
2. Core project
3. customer A project
4. customer B project
Now, I would like both A,B projects to be updated and as close as
possible to the sources in core,common, however if i do that then they
would get destabilized, however i dont really like the idea of
branching projects and having multiple source codes since then for
every fixture i do in one project i have to do it in another project.
Is there any elegant solution for such a problem at all?
10x
Tomer
| |
| H. S. Lahman 2006-07-09, 6:59 pm |
| Responding to Tom...
> I have multiple OO projects to manage.
>
> They are connected one to each other.
>
> 1. Common Project
> 2. Core project
> 3. customer A project
> 4. customer B project
>
> Now, I would like both A,B projects to be updated and as close as
> possible to the sources in core,common, however if i do that then they
> would get destabilized, however i dont really like the idea of
> branching projects and having multiple source codes since then for
> every fixture i do in one project i have to do it in another project.
As I understand this, A and B provide customized solutions for
particular customers. IOW, they solve different, albeit similar,
problems. In that case they will <usually> have different code and you
will have to manage that via branching of some sort in the version
control system.
> Is there any elegant solution for such a problem at all?
No single solution because it depends upon the particular problem being
solved. You can mitigate the problem with application partitioning by
isolating code that is likely to be different. However, you already
seem to have done that by identifying Common and Core projects.
[Note that there is a distinction between logical design and deployment.
If you deploy A and B as, say, DLLs then for all practical purposes
they are unique applications that are independent of one another. In
that case worrying about version control may be wasted angst and it
would be easier to manage them as unique applications.]
There is another approach to mitigating the differences, though. If one
encodes just the problem space invariants and relegates detailed context
differences to configuration data, then one can effectively change the
solution by changing the data parametrically and not touching the code.
If you can abstract the processing for A and B to the level of some
common invariants, then you may be able to define the differences
between them parametrically in configuration files so that the source
code is the same for both.
A good modern example of this are GUI builders that abstract the GUI
paradigm in terms of generic entities like Window and Control. The
specific problem semantics is relegated to the values of text strings
for labels and titles and those strings are provided externally. That
allows one to specify an arbitrary GUI by defining a resource file and
registering callbacks to the main program logic.
The first example I ever saw of this was in the '70s with IBM's Impact
system for inventory control. The IBM suits would come visit the client
with a questionnaire that filled a loose leaf binder. Once the client
answered all the questions, the suits would disappear. A w or two
later they would come in an install Impact with a mongo database that
had all the answers to the questions in it. Impact would then do pretty
much exactly what the particular client wanted. However, the core
Impact code was essentially the same for all customers.
There are some small-scale examples of Invariants and Parametric
Polymorphism in that category in my blog that may be of interest.
*************
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
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
| |
| David Lightstone 2006-07-09, 6:59 pm |
|
"Tom" <tomerbd2@gmail.com> wrote in message
news:1152447069.118708.81320@m79g2000cwm.googlegroups.com...
> Hi
>
> I have multiple OO projects to manage.
>
> They are connected one to each other.
>
> 1. Common Project
> 2. Core project
> 3. customer A project
> 4. customer B project
>
> Now, I would like both A,B projects to be updated and as close as
> possible to the sources in core,common, however if i do that then they
> would get destabilized, however i dont really like the idea of
> branching projects and having multiple source codes since then for
> every fixture i do in one project i have to do it in another project.
>
> Is there any elegant solution for such a problem at all?
You are managing a product line, the only question is whether you are
rediscovering the wheel as you go or if you has seen the game plan that
others have developed. See Clements and Northrup's book - Software Product
Lines Practices and Patterns, if you are rediscovering the wheeel..
Configuration Management is a big issue when such tasks are addressed. It is
not my area of expertise, so other than what I have read in the above
mentioned book and currently experiencing similar such problems (at the
level of developer rather than product line manager) there is little I can
directly indicate as applicable.
There is a reference in the indicated book to a strategy used at HP on a
project called "Owen". It seems to be coupled with a tool developed by
truesoft (www.truesoft.com)
Not be tasked to solve this problem at work, I only note the existance
>
> 10x
>
> Tomer
>
| |
|
| Tom wrote:
> I have multiple OO projects to manage.
>
> They are connected one to each other.
>
> 1. Common Project
> 2. Core project
> 3. customer A project
> 4. customer B project
That's called "Software Product Lines". Read the SEI verbiage about that.
If you are very smart, you might possibly realize all that verbiage is
telling you the following very simple tips:
> Now, I would like both A,B projects to be updated and as close as
> possible to the sources in core,common, however if i do that then they
> would get destabilized, however i dont really like the idea of
> branching projects and having multiple source codes since then for
> every fixture i do in one project i have to do it in another project.
Write many unit tests for every feature. (H. S. Lahman doubtless told you
that.)
Pass all tests before checking in code.
Build a common test server, between the projects, and make sure it tests
each time someone commits code.
Write tests for each flavor of your project. The difference between flavors
should be a configuration setting, not conditional compilation. So the same
executables can generally evaluate each product line.
When a developer working on Product A tests their code, all the tests for
Product B must pass.
If they don't, the developer should revert their code and try again. (They
should not, for example, debug, and they shouldn't need to know Product B's
requirements. All requirements are invested in tests.)
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| David Lightstone 2006-07-09, 6:59 pm |
|
"Phlip" <phlipcpp@yahoo.com> wrote in message
news:uH9sg.63149$fb2.28896@newssvr27.news.prodigy.net...
> Tom wrote:
>
>
> That's called "Software Product Lines". Read the SEI verbiage about that.
>
> If you are very smart, you might possibly realize all that verbiage is
> telling you the following very simple tips:
>
>
> Write many unit tests for every feature. (H. S. Lahman doubtless told you
> that.)
>
> Pass all tests before checking in code.
>
> Build a common test server, between the projects, and make sure it tests
> each time someone commits code.
>
> Write tests for each flavor of your project. The difference between
> flavors should be a configuration setting, not conditional compilation. So
> the same executables can generally evaluate each product line.
>
> When a developer working on Product A tests their code, all the tests for
> Product B must pass.
>
> If they don't, the developer should revert their code and try again. (They
> should not, for example, debug, and they shouldn't need to know Product
> B's requirements. All requirements are invested in tests.)
>
Perhaps you would care to expend upon what you mean by "flavor". I will
suspend judgement, but clearly indicate I am leaning very. very strongly
toward the following rhetorical questions and their corresponding
implications
Phlip, have you ever worked on a project that was attempting to implement a
Software Project Line? or are you just speculating as to the nature of the
applicable strategies?
The whole idea behind software product line is avoiding the efforts needed
to develop code and tests for each "flavor" of your project. Product A and B
are coupled only by the infrastructure that they share. The infrastructure
can change, but when it does, it damn well better not adversely impact
Product A or Product B. Adversely implies functional and non-functional
evaluation criteria.
> --
> Phlip
> [url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
>
>
|
|
|
|
|