There are different approaches to development. You can start to write a code immediately, make a layout and think about the structure and architecture while coding. This approach isn’t efficient, it allows to start at once but not to keep sufficient development pace.
It often appears that you need to change something in app architecture. But it’s expensive as you’ve spent a big amount of time for current solution and changes involve a big part of application.
It’s one of the most popular problems. When you work on such projects you’re thinking about rewriting it at all.
Minimization of fundamental (architectural) changes guarantees successful and qualitative project fulfillment.
Let’s think over the above and find out what is “architecture” and what’s hidden there. It’s worth to read Martin Fowler’s collection of materials. There are some definitions:
- architecture is the decisions you wish you could get right early in a project;
- architecture is about the important stuff. Whatever that is.
You need to do this before the actual programming to define key solutions and find out important application’s parts.
And now there is a question on how to do it better? Descriptively or schematic? What level of abstraction to reach?
One of the obvious options is schematic structure and project behaviour image. From general schemes, that show connections and interactions between project systems, to specific, that show each system realization.
There are many types of diagram:
- use case diagram;
- class diagram;
- object diagram;
- sequence diagram;
- interaction overview diagram;
- state machine diagram;
- activity diagram;
- deployment diagram.
Analyzing all the options, we chose two of them:
- activity diagram shows sequence of conditions and system’s activities;
- class diagram shows general structure of system’s classes hierarchy, their cooperation, attributes, methods, interfaces and its interactions.
Activity diagram allows to understand product work algorytm.
Class diagram helps to develop particular solution before programming. And what is more important, it helps further task formulation.
In some cases other diagrams can be useful. But these two are required minimum, as we think.
Firstly we develop activity diagram.
Then we separate application to modules. And prepare class diagram.
Class diagram can be used for:
- separation the whole project to tasks that allows to get more detailed terms for development
- separation the whole project to modules that allows to make the code less coupled and more cohesive
What advantages we got:
- product work algorithm
- more predictive development process
- product quality increasing
- additional tech documentation
- it’s easier way to add a new team member
Benefits are obvious, so don’t ignore this stage.