describe four principles of analysis modelling
Answers
Answer:
Create an ER diagram. Create a DFD diagram. Create a control flow model• Large class of applications are driven by events. ... Create a Process Specification(PSPEC)• Used to describe all flow model processes that appear at the final level of refinement.
Explanation:
Answer:
Modeling has rich history in all the engineering disciplines. That experience suggests four basic principles of modeling.
First principle of modeling:
The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped.
Choose your models well. The right models will highlight the most nasty development problems. Wrong models will mislead you, causing you to focus on irrelevant issues.
Second principle of modeling:
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 to complex details such as cross-system interfaces or networking issues etc.
In any case, the best kinds of models are those that let you choose your degree of detail, depending on who is viewing it. An analyst or an end user will want to focus on issues of what and a developer will want to focus on issues of how.
Third principle of modeling:
The best models are connected to reality.
In software, the gap between the analysis model and the system’s design model must be less. Failing to bridge this gap causes the system to diverge over time. In object-oriented systems, it is possible to connect all the nearly independent views of a system into one whole.
Fourth principle of modeling:
No single model is sufficient. Every non-trivial system is best approached through a small set of nearly independent models.
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.
The same is true of object-oriented systems. To understand the architecture of such a system, you need several complementary and interlocking views: a use case view (exposing the requirements of the system), a design view (capturing the vocabulary of the problem space and the solution space), a process view (modeling the distribution of the system’s processes and threads), an implementation view (addressing the physical realization of the system) and a deployment view (focusing on system engineering issues). Depending on the nature of the system, some models may be more important than others.
Explanation: