Why We Model
Why We Model
[email protected]
Why We Model
>> Modeling is a central part of all the activities that lead up to the
deployment of good software.
>> We build models to better understand the system we are building, often
exposing opportunities for simplification and reuse.
>> For example, we build architectural models of houses and high rises to help
their users visualize the final product. We may even build mathematical
models to analyze the effects of winds or earthquakes on our buildings.
>> Unsuccessful software projects fail in their own unique ways, but all
successful projects are alike in many ways.
>> We build models so that we can validate our theories or try out new ones
with minimal risk and cost.
>> A good model includes those elements that have broad effect and omits
those minor elements that are not relevant to the given level of
abstraction.
>> The larger and more complex the system, the more important modelling
becomes, for one very simple reason:
- We build models of complex systems because we cannot full
meaning of such a system in its entirety.
>> Because there are limits to the human ability to understand complexity.
>> The more complex your project, the more likely it is that you will fail or
that you will build the wrong thing if you do no modeling at all. All interesting
and useful systems have a natural tendency to become more complex over
time. So, although you might think you don't need to model today, as your
system evolves you will regret that decision, after it is too late.
>> In other words, choose your models well. The right models will
brilliantly illuminate the most wicked development problems, offering
insight that you simply could not gain otherwise; the wrong models will
mislead you, causing you to focus on irrelevant issues.
>> In other words, we need multiple views to capture the breadth of the
system. That means, having multiple models that can be built and studied
separately but that are still interrelated. For example, object-oriented
software systems.
>> Each of these views may have structural, as well as behavioral, aspects.
Together, these views represent the blueprints of Object-Oriented
Software System.
>> In software, there are several ways to approach a model. The two most
common ways are from an algorithmic perspective and from an object-
oriented perspective.
>> For example, a simple three-tier architecture for a billing system involves
• a user interface (objects such as buttons, menus, and dialog boxes)
• business services (objects such as transactions, business rules,
customers, products, and orders)
• a database (objects, such as tables)
>> Grady Booch, James Rumbaugh and Ivar Jacobson. Chapter 1: Why We
Model, The Unified Modeling Language User Guide.