Modeling

What, then, is a model?

Simply put, A model is a simplification of reality.

A model may be

1. Structural, emphasizing the organization of the system,

2. Behavioral, emphasizing the dynamics of the system.

Why do we model? There is one fundamental reason.

We build models so that we can better understand the system we are developing.

Through modelling, we achieve four aims.

1. Models help us to visualize a system as it is or as we want it to be.

2. Models permit us to specify the structure or behavior of a system.
3. Models give us a template that guides us in constructing a system.
4. Models document the decisions we have made.

Principles of Modeling

Four basic principles of modeling are:-

1. The choice of what models to create has a profound influence on how a problem is
attacked and how a solution is shaped:- In software, the models you choose can
greatly affect your world view. If you build a system through the eyes of a database
developer, you will likely focus on entity-relationship models that push behavior into
triggers and stored procedures. If you build a system through the eyes of a
structured analyst, you will likely end up with models that are algorithmic-centric,
with data flowing from process to process. If you build a system through the eyes of
an object-oriented developer, you'll end up with a system whose architecture is
centered around a sea of classes and the patterns of interaction that direct how
those classes work together. Any of these approaches might be right for a given
application and development culture, although experience suggests that the object-
oriented view is superior in crafting resilient architectures, even for systems that
might have a large database or computational element. That fact notwithstanding,
the point is that each world view leads to a different kind of system, with different
costs and benefits.

2. Every model may be expressed at different levels of precision:- Sometimes, a quick

and simple executable model of the user interface is exactly what you need; at other
times, you have to get down and dirty with the bits, such as when you are specifying
cross-system interfaces or wrestling with networking bottlenecks. In any case, the
 best kinds of models are those that let you choose your degree of detail, depending
on who is doing the viewing and why they need to view it.

3. The best models are connected to reality:- In software, the Achilles heel of
structured analysis techniques is the fact that there is a basic disconnect between its
analysis model and the system's design model. Failing to bridge this chasm causes
the system as conceived and the system as built to diverge over time. In object
oriented systems, it is possible to connect all the nearly independent views of a
system into one semantic whole.

4. No single model is sufficient. Every nontrivial system is best approached through a

small set of nearly independent models:- If you are constructing a building, there is
no single set of blueprints that reveal all its details. At the very least, you'll need floor
plans, elevations, electrical plans, heating plans, and plumbing plans. The operative
phrase here is "nearly independent." In this context, it means having models that can
be built and studied separately but that are still interrelated. As in the case of a
building, you can study electrical plans in isolation, but you can also see their
mapping to the floor plan and perhaps even their interaction with the routing of
pipes in the plumbing plan.

Object-Oriented Modeling
Object-oriented modeling (OOM) is the construction of objects using a collection
of objects that contain stored values of the instance variables found within an
object. Unlike models that are record-oriented, object-oriented values are solely
objects.

The object-oriented modeling approach creates the union of the application and
database development and transforms it into a unified data model and language
environment. Object-oriented modeling allows for object identification and
communication while supporting data abstraction, inheritance and encapsulation.

 Object-oriented modeling is the process of preparing and designing

what the model’s code will actually look like.
 During the construction or programming phase, the modelling techniques
are implemented by using a language that supports the object-oriented
programming model.
 OOM consists of progressively developing object representation
through three phases: analysis, design, and implementation.

During the initial stages of development, the model developed is abstract

because the external details of the system are the central focus. The model
becomes more and more detailed as it evolves, while the central focus shifts
toward understanding how the system will be constructed and how it should
function.

Definition
"Modelling is a central part of all the activities that lead up to the deployment of good
software. We build models to communicate the desired structure and behavior of our
system. We build models to visualize and control the system's architecture. We build
models to better understand the system we are building, often exposing opportunities
for simplification and reuse. And we build models to manage risk."

Introducing the UML

The Unified Modeling Language (UML) is a standard language for writing software blueprints.
The UML may be used to visualize, specify, construct, and document the artifacts of a software
intensive system.

An Overview of the UML

The UML is a language for
· Visualizing
· Specifying
· Constructing
· Documenting
the artifacts of a software-intensive system
Links and Associations Concept
A link is a physical or conceptual connection among objects. For example, Joe Smith WorksFor
Simplex company. Most links relate two objects, but some links relate three or more objects.

An association is a description of a group of links with common structure and common

semantics. For example, a person WorksFor a company. The links of an association connect
objects from the same classes.

Example 1:
In the class diagram, a person may own stock in zero or more companies; a company may have
multiple persons owning its stock. The object diagram shows some examples. John, Mary, and
Sue own stock in the GE company. Sue and Alice own stock in the IBM company. Jeff does not
own stock in any company and thus has no link.

The asterisk is a multiplicity symbol.

Multiplicity(*) specifies the number of instances of one class that may relate to a single
instance of another class.
Multiplicity
Multiplicity specifies the number of instances of one class that may relate to a single instance
of an associated class. Multiplicity constrains the number of related objects. The literature often
describes multiplicity as being “one” or “many,” but more generally it is a (possibly infinite)
subset of the nonnegative integers.

The UML specifies multiplicity with an interval, such as:-

“1” (exactly one), “1..*” (one or more), or

“3..5” (three to five, inclusive).

The special symbol “*” is a shorthand notation that denotes “many” (zero or more).

Example 2:-
Each country has one capital city. A capital city administers one country. (In fact, some countries,
such as The Netherlands and Switzerland, have more than one capital city for different purposes.
If this fact were important, the model could be modified by changing the multiplicity or by
providing a separate association for each kind of capital city.)
Example 3:-
A workstation may have one of its windows designated as the console to receive general error
messages. It is possible, however, that no console window exists. (The word “console” on the
diagram is an association end name).

NOTE:- Do not confuse “multiplicity” with “cardinality.” Multiplicity is a constraint on the

size of a collection; cardinality is the count of elements that are actually in a collection.
Therefore, multiplicity is a constraint on the cardinality.

Association End Names

Generalization and Inheritance
Generalization is the relationship between a class (the superclass) and one or more variations
of the class (the subclasses). Generalization organizes classes by their similarities and
differences, structuring the description of objects. The superclass holds common attributes,
operations, and associations; the subclasses add specific attributes, operations, and associations.