TL;DR
Do not mix the Analysis of the problem with the Design (project) of the solution, nor with the Technological Implementation.
Analyzing
An analyst is the professional responsible for identifying a problem to be solved or need to be met and eliciting the requirements for creating a solution.
The set of requirements defines what the system should do to meet the identified needs.
Based on the requirements, the analyst continues the Analysis process identifying at a high level what functionalities the system should have to meet the requirements.
A common solution to map each functionality is through Use Cases (not to be confused with the UML Use Case Diagram). A use case is in general a kind of step-by-step interaction between user and system, although this concept may vary. In addition, it usually describes the necessary preconditions for the correct execution of that use case and the post-conditions, which are the results of the action performed.
Note that we are still at a high level and nothing here has to do with the technological solution involved.
Continuing, if the analyst is trained in object orientation and UML, he can choose to model this knowledge of the domain and problem using the appropriate diagrams, which are usually: Use Case Diagram, Activity Diagram, Class Diagram and State Diagram.
The Case Diagram of Use is a simple visual representation of the system’s interactions with the external world. The actors that interact with the system are representations of users, other systems or any entity external to the system that communicates with it. This diagram does not exclude the need to map use cases as described above.
The Diagram of Activities represents the case steps of use in a kind of flowchart, including forks with alternative scenarios, error scenarios, etc. Not all scenarios need to be represented in the same diagram.
The Class diagram, at this stage of a project, should include only domain classes, not including specific classes of frameworks, libraries, nor any reference to the technology that will be used for implementation. We could call this diagram Diagram of Domain Classes. The function of the diagram is to represent the necessary entities and the relationship between them. In short, it is the modern object-oriented form of the Entity-Relationship Diagram (ERI), although both can be used. ERI is usually associated with structured modeling.
The State diagram is used for system entities that follow a stream of states. For example, a portion may be "open", "settled", "in arrears", "at a loss". This diagram represents the states and how transitions occur between them.
Through all this, the analyst can validate the solution, not considering the technological part, but checking if the classes and use cases meet the requirements. For example, if there is a requirement that "the manager can extract a report with the total of products sold in the month", then the analyst should look at whether the class Produto
has a "navigable" relationship with Venda
and ItemVenda
. It can also add to the classes some most important methods and attributes to meet these requirements.
Design
Based on all this information, architects and developers take action to propose a technological solution to the problem. This does not necessarily come in sequence, but much can occur in parallel.
Technical designers will be able to create several other diagrams to represent what will be implemented, but will hardly reach the level of detail of placing classes in a framework.
The most relevant and commonly used diagrams are:
- Diagram of Components: represents the high-level division of the main components of the system. The split does not represent the folder structure of the project files, but is a logical division of responsibilities.
- Deployment diagram: a representation of the environment where the system will be executed.
- Sequence Diagram: for a given action in the system, this diagram represents the interaction between several objects through the calls executed and the return, allowing to visualize the sequence of calls to methods in time.
Design can also be done agnostically, that is, without considering what technologies, frameworks and libraries will be used. However, I believe that it is more productive to model the division of components and classes already thinking about the implementation, so as not to generate another gap information.
Note that each of these diagrams can be made for several different cases. When we speak of Class Diagram or Component Diagram, we do not speak of a single diagram that represents the system as a whole. The representation can be made in different levels, for example, one showing the general system components and other diagrams showing the internal structure of each component individually. The representation can also be done in different contexts, for example, several diagrams can be made to represent only what is necessary for an important functionality, ignoring classes and packages not relevant in this context.
Implementation
The implementation must follow what has been defined in the design, but this does not mean that each method, class, package and component must be mapped one-to-one in the "physical" project, its files and directory structure.
The programmer should have the freedom to find the best solution to meet what was requested with the structure he wants. It would be bad from the point of view of good practice to impose every detail of what should be implemented. If that were possible, we wouldn’t need programmers, but a code generator.
Building the bridge
When studying carefully the "phases" (in quotes because they are not a linear sequence) of a software development project, it is possible to notice that there is a big leap (gap). An analogy commonly used in Software Engineering books is to build a bridge between what the customer needs and the technological solution.
Even today, Software Engineering is a somewhat immature discipline, we do not have a standardized form as the Civil or Electrical to work. The validity of an Analysis Model, a Design Model or the solution implemented depends almost exclusively on human factors, such as the communication capacity and understanding of analysts.
There is no formal rule for data modeling. UML was a major breakthrough, but the various diagrams in general vary in detail, comprehensiveness and many other design factors for design, from team to team and from individual to individual.
Final considerations
Even with the last statements above, I do not want to be pessimistic. Although there is no definitive answer to the modeling of systems, there are some principles that can guide us:
- Put the communication first. The purpose of a diagram is to communicate information and not simply to mirror the code. If a diagram does not communicate something useful, do not waste time with it. Consider your team and your project and make diagrams that are relevant with the relevant details so that people know what they’re doing. Your team can gather at a table and discuss a diagram, scribbling it and using it as a basis for conversation?
- Do not diagram specific technologies. If someone wants to know how Servlets, Rails or Django work, they better buy a book. You’ll just confuse people. I’ve seen many diagrams out there that are nothing more than the MVC model with different names.
- Make sure the diagram meets the requirements. Your diagram should be useful not only to understand what needs to be done, but also to validate whether your solution meets what the customer needs. Do logical mind tests, looking at classes, methods and relationships, checking if they have a reason to be there, whether for a certain scenario you can extract the necessary data, etc.
As I mentioned a few times, Analysis, Design and Implementation will probably be done many times during the development cycle. Don’t expect to have everything right in the beginning. Investing too much time in detail is bad, according to several authors.
This method of identifying classes through nouns can be useful when you have no idea what you’re doing, but it’s bad because it’s an attempt to create a "dumb" way of extracting information without critical analysis.
In fact, the word "extract" is often misused. When we create a system, no extract the requirements and the necessary classes as if they already existed there, hidden in some way. As for the classes, we simply set in a spurious way which classes a system will have in order to meet the needs. It is a creative process and not an extraction process as with raw material. By "creative", don’t think of post-modern art, but something more methodical.
My recommendation is to identify through the requirements, what data is needed for the system to work and the relationship between them. The Dbas say so: data is the heart of the system. So we have the necessary entities.
Then, based on the functionalities the system should have, you can create classes that will be responsible for handling these functionalities.
Anyway, there is no absolute answer, but I hope to have well exemplified a path I learned over a few years studying and reflecting on how to develop software well, not only from a technical point of view.
I won’t answer because an answer is too difficult. The problem is because the market thinks that the programmer should understand of all possible domains whose law does not require a professional own certificate in any way. Most programmers don’t know as much about business rules as companies would like, so the organization of a system, those obvious classes, doesn’t end up being so obvious. The programmer does a lot of things without thinking correctly. And in cases involving technology directly? No one is expert at all.
– Maniero
Most people don’t understand security, competition, a specific API. Even learning to use ready-made things for these things is part of the programmer’s obligation. But only an expert will understand the subject in the depth that is required. More so. He will not dominate alone, he needs an extensive team, need to have other people to consult. In short, a specialist programmer has a great chance to choose the correct way to create these classes, but can still make mistakes. Imagine what is not an expert on the subject he is creating the class.
– Maniero