UML for a migration project.
Michael Scorpio
I'm fairly new to UML, but I'm trying to integrate it into projects as
I get the opportunity.
Currently I'm working on a migration project and I'm using Enterprise
Architect to document the target database including adding
constraints. I then generate DDL to create a target database and write
SQL by hand to populate the target.
I'd like to use UML to document the migration, and also get some ideas
on how practical it would be to have the migration model driven.
Does anyone have any suggestions on how to approach this, or links to
methodologies that others may have used to do this?
I appologise for what to some will seem like UML 101, but I don't yet
know enough to know which questions to ask, so I've tried to keep it
to what I'm trying to acheive.
Thanks in advance.
H. S. Lahman
The first thing you need to figure out is exactly what you are modeling...
>
> I'm fairly new to UML, but I'm trying to integrate it into projects as
> I get the opportunity.
>
> Currently I'm working on a migration project and I'm using Enterprise
> Architect to document the target database including adding
> constraints. I then generate DDL to create a target database and write
> SQL by hand to populate the target.
>
Schema definitions is Data Modeling. UML is fine for that but
constructing and interpreting the models requires a somewhat different
mindset than, say, an OOA/D model of a problem solution.
"Somewhat" is probably an understatement. The form/query/table view of
RAD solutions for CRUD/USER processing represents an approach for
software development, P/R, that I would argue is fundamentally
incompatible with the OO approach. Typically Data Modeling is the
cornerstone of P/R. One uses the same UML notation, but the way one
constructs OOA/D models is very, very different. As soon as you use
'database', 'SQL', and DDL in the same paragraph, it strongly suggests
P/R. However, ...
> I'd like to use UML to document the migration, and also get some ideas
> on how practical it would be to have the migration model driven.
>
When you want to "document the migration", that sounds to me like you
want to document the /process/ of migration, which would be more of a
Domain Modeling context. UML can certainly be used for that, but I'm the
wrong guy to speak to that since I don't do much of it. B-( Somebody
else can jump it if that is where you are going.
OTOH, making the migration itself model driven is pretty much what I do.
[I happen to be a translationist, so I provide an OOA model that
resolves functional requirements and then push a button and let a
transformation engine create a 3GL or Assembly application program. (A
little more complicated than pushing a button but the basic idea is that
I never need to look at 3GL code.)] For that you need OOA/D where you
design a solution for the customer's problem, in this case migrating
software.
So the next thing to resolve is exactly what sort of migration do you
mean? A priori I would assume you mean that you want to create New
Maintainable Application B to replace Old Unmaintainable Application A
using some new suite of technologies and a new <hopefully OO>
construction methodology.
If that is accurate, then I suspect you will need to provide multiple
views of the project in UML. If you need a lot of work on RDB schemas
and whatnot, you need a Data Modeling view. If the application is
primarily CRUD/USER, you need a P/R construction view. If you need to
ensure that requirements are extracted from Application A and are moved
to Application B, then you will probably need some sort of process view
of how that gets done. Similarly, if you do piecemeal replacement, you
need a Master Plan and process strategies for doing that. If the
business environment has changed, you may need a Domain Modeling view as
a kind of requirements specification. Finally, if you have to actually
build Application B in an OO fashion, you would need an OOA/D view of
that solution.
Bottom line: UML is a very versatile notation, but its value as a
communication vehicle is directly proportional to separating different
concerns and goals with different views that need to be interpreted for
the specific context. Corollary: UML is just a notation that records
things; it doesn't define things or make them happen. To be used
properly one needs a construction methodology that is consistent with
the view context.
>
> I appologise for what to some will seem like UML 101, but I don't yet
> know enough to know which questions to ask, so I've tried to keep it
> to what I'm trying to acheive.
>
Actually, it's not UML 101. My main point above is that what you want to
do is probably not at all simple and the task can raise some rather
subtle issues. [Not to mention controversial, if you provide more
information on your context and people start providing actionable
advice. B-)]
--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer
H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
Michael Scorpio
it.
What am I trying to model?
I'm migrating data from one system to another. Both are RDBMs and
provide similar functionality, but are implemented very differently.
I'm currently writing the data transformation required in SQL. So I
guess what I'm trying to model is data transformation...how each
target attribute is populated from fixed values, source attributes,
and in some cases aggregates from the source data.
It seems to me that if data transformation can be modeled at the most
granular level, that a model driven migration should be possible,
though this is not my goal. In the event that I can't model at the
most granular level, then I'm looking to create an abstraction that
will be useful as an aid to understanding for others. (If the former
is possible, I may in fact do both anyway; thus catering for different
audiences).
I hope this adds some clarity around what I'm trying to achieve.
Thanks again...
> software blog:http://pathfinderpeople.blogs.com/hslahman/index.html
H. S. Lahman
> Thanks for the lengthy response. You've obviously put some time into
> it.
>
Not really. On these forums I am known for being able to describe any
picture in a thousand words. B-)
> What am I trying to model?
> I'm migrating data from one system to another. Both are RDBMs and
> provide similar functionality, but are implemented very differently.
> I'm currently writing the data transformation required in SQL. So I
> guess what I'm trying to model is data transformation...how each
> target attribute is populated from fixed values, source attributes,
> and in some cases aggregates from the source data.
>
OK, so you are not going to muck with the RDBs; you just want to get
data from one to the other and the vehicle will be SQL queries from one
DB to the other, right? [I haven't used an RDB in a decade or so, but my
recollection is that one can specify the DB in a SQL query so the fact
the input and output tables are in different DBs should not be a problem
syntactically for a SQL engine, .NET, or whatever.]
If so, this sounds like a basic mapping problem from one schema to
another. So one has something like:
<pre>
[DB1:Table]
+ tableName
| 1
|
| R1
|
| *
[DB1:Attribute]
+ attributeName
+ type
+ value
| 1
|
R2 |-------------[Translator]
|
| 1
[DB2:Attribute]
+ attributeName
+ type
+ value
| *
|
| R3
|
| 1
[DB2:Table]
+ tableName
</pre>
This is the kind of model one might create if one were going to write
some software to automatically generate the SQL queries. The role of
[Translator] would be to provide the mapping and deal with any type
mismatches. (I'm using 'type' here as a placeholder for all the field
attribute baggage modern DBs provide for things like string patterns.)
Some other object would then "walk" the structure and churn out the SQL
strings.
The problem here is that this describes the megathinker structure but it
isn't too helpful to anyone trying to write the SQL queries because the
actual mapping occurs when R2 is instantiated and that is not visible
here. Thus somebody would probably sit down and create some mongo
configuration file full of entries like "DB1:tableID:AttributeID ->
DB2:tableID:AttributeID" that would be used by a factory pattern to
instantiate this structure and that would be where the mapping occurs.
In fact, that kind of underscores a problem with using UML for this sort
of DB processing. Once one has defined the schema, everything else is
just instantiation of those data structures. That is, all of the
semantic details are defined parametrically as data in fields like
tableName. Providing that parametric data for R2 via a mundane external
configuration file is then the obvious choice for attacking the mapping
problem in an automated process. [There is a category on by blog,
Invariants and Parametric Polymorphism, that talks about this in
detail.] But if the SQL queries are to be created manually, one may as
well skip the configuration tables and go directly to encoding queries
(though creating them provides a systematic way to document the mapping
details). IOW, UML may be overkill for the actual conversion.
OTOH, if you plan to make a habit of this or you expect a lot of future
changes, you might want to consider software to automatically generate
the queries. That software would be quite generic so all you would have
to do is create/modify the configuration file. With some care in
formatting that would be less error prone than mucking around in 3GL
code to do maintenance. Throw in some more classes and you could deal
with situations where you needed to create schemas in a new DB.
<caveat>
The model above is probably a bit simplistic, even at this level of
abstraction. There is likely to be some weirdness like a telephone
number as a single field in DB1 that needs to be split into {country,
area code, exchange, number} fields in DB2. My point here is just to
highlight some basic issues. Also, the model just describes the
structure of the mapping. If this were to be automated there would be
other objects to handle things like actually constructing queries and
saving them. Even if your process will be manual, it might be useful to
model what such software might look like to automate the generation.
That effectively becomes documentation for the process of manual query
production.
</caveat>
--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer
H. S. Lahman