Modeling principles

In the past three slides we talked a lot about the model that created during software development workflows.
Lets step back a minute and ask an important question. Why do we want to create any these models?
If the ultimate goal is to create software, why should I waste time creating models?
..... then he wrote: we build models we can better understand the system we are developing.

Then building a house you could just buy some lumber and start nailing board together and hope that all that walls fit together.
And then you have room ... a kitchen (м.б. украсить или выбрать кухню).
Such [анхак] approach to build a house is unlike little fail.
Instead you hiring an architect and designer [хелс].
The architect create some model of the [хелс] in his head, but he must share his vision with you, the client.
In the construction [крую], it takes order in a house to construction requeres unique view of the architecture.
You, as an owner need to see artistic renderings of the exterior and landscaping,
the builder need to see three-dimensional views of rooms, doors, stairs and so on.
The electrician needs a wiring view, the plummer needs the view of pipes and so on.

Software development also uses models to represent aspects of the system.
All software developers have a mental model of the system they are building.
You can draw your own diagrams to visualize those mentals models. You can also draw a diagram to capture a design of some existing system.

Communication is very important for success of any software project.
Models help communicate the design and decisions being made about the project.
These decisions must be share with stakeholders, so everyone is on the same page about stages and direction of the project.
In large teams each workflow may be performer by different workers. As the project transitions from one workflow to the next,
it is important that workers document and communicate decisions to the next workflow group.
Models help document those decisions.

Specific UML diagrams show different views of these models.
For example you can use a class diagram to show types ant entities of the system.
And you can use the sequence diagrams to show time order flow of messages between objects to accomplish some functional requirements.