My software modeling is approach to software analysis based on reasonable diagrams. In this post I present my five tips.
Models evolve over time
You can start with the basic case, but you’ll quickly decide to turn it into several system use cases. You can also decide to develop a set of Object-Role Model diagrams (ORMs) placed on the whiteboard as a contribution to the UML class diagram, which in turn will transform into source code.
Analysis models must be only good enough
Try to make your models as simple and light as possible. Focus on understanding, not documentation. Use the simplest and most general tools available. Realize that your models do not have to be perfect.
Each model can be used for many purposes
Data flow diagrams can be used both as an analysis technique to examine existing business processes and as design techniques to redefine them. Similarly, the BPMN or state machine diagrams can be used for both analysis and design purposes as well as for use cases for requirements, analyzes and sometimes even design.
Modeling lines are often blurred
The traditional concept of software development phases – requirements, analysis, design, coding, testing and implementation – left many people convinced that we need to distinguish between different types of modeling. But if the person concerned provides us with a requirement, such as the need to obtain a student’s home address, we will often go through these phases at intervals of a few seconds. We will start to think about how the user interface should look like, about the different data elements to be acquired, the need for the Address class, the possibility of using the Contact Point formula, the need to create the Address table in the database, and how to write the code for all this in Java, thus departing from the requirement through analysis and design to write code without stopping to create a complete model of requirements, or a complete analysis model, etc. As it is important to ask questions like what you need (requirements), what does it mean (analysis) and how we intend to build it (project), we will often do it in an iterative, not serial way.
Use the same terminology as the shareholders
Do not force shareholders of your project to use artificial, technical jargon. It is for them that the system is created; therefore, you should use their terminology in the system model.