Modeling has been a natural part of software development a long time. But why
do we really bother to make a model, instead of just hacking away at the
keyboard and create some software? The answer is that by having a model we gain
a lot of things that cannot easily be accomplished in any other way.
Here are some of the benefits, when it comes to producing source code:
Speed up coding with code generation
The amount of time spent on modeling can be gained multiple times by adding
automatic code generation that reads the model and creates parts of the source
code. A large part of the code will have standard implementation patterns and
are tedious and time consuming to do manually. Code generation keeps that work
to a minimum and developers can concentrate on the interesting algorithms
instead. This means that more development time will be spent on business logic
rather then on "bulk" programming.
Style consistency
The produced code will automatically have a more homogenous coding style. This
is due to the fact that more code is generated directly from the model and
will therefore have the same style. Naming of code artifacts will also be more
consistent, since the modeling tools can enforce naming conventions and good
naming suggestions. Consistent coding style makes it easier for other
developers to understand what the code does.
Accuracy in coding
A specific problem with software development is to know when a software
package is completed and supports all the intended functionality. One way is
of course to test everything, but you must have a list of functions that
should be there. Naturally, the model supplies with that list. It is far more
easy to check that the model is complete then that a bunch if source
files are.
Increased quality of code
A large software system typically have a lot of different places where the
same component is references and/or used. For example, an attribute name is
used for database creation, database access statements, data structure
definitions, client controls and much more. To ensure that the naming and
behavior is consistent throughout the whole code mass is easier if we have a
single definition that feeds all of these uses. That definition comes from the
model.
Understandability and documentation
Instead of having to scan the file system in order to find what you are
looking for, the model can be browsed and queried by development tools. These
tools can be tailored to support the development process and also to produce
adequate documentation, that encompasses not just the developer notes, but
also the intent of each component edited by some system analyst of designer.
By having documentation in the model itself and not just in the code,
documentation text and source code can be edited in parallel.
But, modeling is much more then "just" describing the software components.
Companies that uses our software lives in a world where "business is
constantly changing" and our task is to make an application that is capable of
changing in the same pace. As the size of the application increases and the pace
of business change also increases, the problem of keeping up with software
development is getting bigger and bigger. We cannot recode every part of the
software each time. By the time the new functions are ready the business may
have changed again and the whole thing continues over and over again.
Also, packaging different flavors of the application into industry solutions
and customizations makes it necessary to have a componentized application that
can be assembled later on to an appropriate mix.
The trick is to identify what those components should be and how they should
be assembled. They identify these components and describes them in such
detail that they can be used both as input to the implementation models and as
basis for component assembly and configuration.
More modeling benefits, this time from modeling the greater picture with
logical components:
Easier to understand
Since the logical model contains components that are expressed in business
terms rather then software notation, the logical models are more suitable to
present to customers, developers, analysts, etc. When someone needs more
detail, it is possible to drill down to the individual implementation models.
Runtime configuration
Due to the fact that the application should fit many slightly different
business scenarios, it is more convenient to configure the software components
then to change them. By basing the configuration on logical components rather
then physical ones, configuration can be made in business terms that are easy
to understand for an administrator at the customer site.
Planning for changes and impact analysis
All models are linked together with references to each other and the logical
model. It is therefore an easy task to analyze how components are dependent of
each other. This is very helpful when planning for software changes and making
impact analysis, answering the question "what will be affected if we change
this component".
