We are preparing a project in Sparx Enterprise Architect. Our recipe
Dear Habr, we decided to share notes and our basic recipe about the preparation of projects in Sparx Enterprise Architect. And under the project, we mean the creation of any information system. Ahead of you is waiting for a story about how we are all organized - examples of diagrams, project structure in Enterprise Architect, a little about the requirements, design and development.
A source
Once upon a time, in a far-away galaxy ... No, not that. A long time ago, it seems, last Friday we decided that, perhaps, there would be enough of a Word, paper, some jira tasks, etc. - it's time to use something more appropriate. It became inconvenient, since everything was confused in cross-references, in different ways to maintain historicity and several approaches. So began our journey to using Enterprise Architect (EA). Why enough? There are a lot of reasons. Each of the participants in the process has its own. The main reason is absolute power.
Darth Sidious conducts an impact analysis. The blue color shows dependencies (frame from the movie “Star Wars: Episode 3 - Revenge of the Sith”)
')
Absolute power in the sense that we really wanted toinfluence the minds and to rule everyone to understand the connections between the elements of the information systems being created (the elements in the broad sense are not only what is developed and works afterwards, but also requirements, specifications and other things that are used when creating the system) and not just understand, but also quickly find these very connections, analyze, show to the customer, for which “any change can be implemented in one day and it is not clear why you need two weeks”.
Quite a fair question - “Why did you choose Enterprise Architect, and not any other tool?” At the time when the process started, we had jira, confluence, MS office, SP, Sybase Power Designer (now SAP Power Desiner) and Sparx Enterprise Architect. Actually, the question was decided by the personal preferences and skills of EA at that time (it was 2011-2012), as well as people who were pioneers and gave away the hearts and minds of Enterprise Architect. Perhaps this was a mistake.
The main stages of the life of a project to create an information system (and in general, probably, almost any project up to the definition of each stage) are quite obvious - both in accordance with GOST and simply on the basis of common sense. It:
Note: the numbers here are for clarity - the stages can be combined, not have clear boundaries, go into the iteration, etc.
For concepts, we are not using Enterprise Architect yet, as you usually have to do everything quickly, urgently, very beautifully. So this is a word, visio with various extensions or other drawing machines (where is the beauty in general). The sketch, unfortunately, does not interest the customer, although we would be happy to prepare it at EA. The last two points are either about errors (they are solved (at least with us) by other means and tools) or improvements, and then it all wraps up in paragraphs 3-5.
Therefore, let's talk about such steps as the technical task (collection and identification of requirements), technical design (architecture development), design engineering (development and design).
The component diagram (in this case, each component is one deployment unit), the connections between them, the basic protocols.
A diagram of the deployment of common software on sites, indicating the main links
Here are the main things you need.
Not prevent:
Oh yeah, I almost forgot - we still need a friendly and enthusiastic team. Without this, nowhere. We have just this.
For us, these were:
In our opinion, consciously or unconsciously, almost any team of people involved in the process of creating something can tell about it: what it creates, what it consists of, how it works, etc. Maybe not very nice or connected, maybe with the “holes” in the presentation. But, nevertheless, it can. So it is with the creation of an information system. At the top level, we probably all imagine that there are requirements - functional and some more, important and not very clear and vague, there is something that shows the basic principles of implementing these requirements - which units in the system, which basic technologies are used that the system surrounds, as all this is connected to each other. There are details and requirements, and implementation principles, description of data structures, etc. We called all these basic parts and the rules of communication between them the “metamodel”.
Our metamodel. Beauty!
In our recipe, the meta model is quite a figure skater - we outline its contours and then we will look at each part in a little more detail:
We can not boast of a long agony of choice, since we almost immediately chose UML as the most common option. Well, "rushed." Surely, we could use different bundles of different languages ​​and notations, and we will probably come to this by choosing our own model for each of the parts of the metamodel, but so far we are happily relieved of the agony of choice and of crossing notations and languages.
At the very beginning there was no knowledge. In the sense, of course, there were, but fragmentary ones, about how to work alone or how to form simple documents. In general, looking back, you are struck by ourdementia and courage of self-confidence and speed of learning. Since then, plunging more and more into the depths of Enterprise Architect, we still discover new horizons for ourselves. Now we have the following aspects: working with the EA project and the elements, versioning, access control, document generation.
So, we have discomfort, metamodel, formal language, knowledge of Enterprise Architect, friendly team, laziness, coffee, patience and flexibility.
Now we need to take EA, create a project in it, create a structure according to our metamodel, and start contributing elements and links.
We try - we look at the result, we estimate - we liked it, we apply further. I didn’t like it - we are correcting the metamodel, updating the elements, connections, and so on until we prepare it.
How to understand what did not like? You do not like, you are even more uncomfortable, you do not feel good. Somehow very trite and vague, right? You are absolutely right, dear readers. But some very clear and rigorous criteria for the general case are difficult to propose, and probably not necessary. But we, of course, will share our experience.
A project in Enterprise Architect consists of a set of root packages.
In turn, each root package may contain other packages. And each normal package - elements (here elements are referred to as elements of EA) and diagrams.
Root directories can be located locally — in an EAP file, or they can be centrally located in a database. In addition, each package can be saved as xml in the repository version control system.
We did not manage to store the project in the database. At first it was great - the changes were reflected in everyone, but after a while we had errors, some strange situations with the disappearance of elements, etc. In the end, we spat it to treat and at the time forgot. But the version control system we pulled and screwed the SVN.
Project in Enterprise Architect
In the most primitive version, you can create the main parts of your metamodel as root packages or first-level packages and get a structure for storing model elements and the connections between them. In our example, a little more complicated, since some of these parts are spread over packages of the first level. But as a whole the principle is traced. In addition, by “screwing” SVN, we were able to work with branches and releases, and delineate access based on the principle of “one package - one owner”.
The requirement (as an EA element) looks like this:
An example of the requirement for providing electronic interaction
This is how the vast majority of EA elements look for UML (so I saw one - I saw the rest).
Metamodel, in terms of requirements, we have quite a boring one - below is just this part in a larger plan.
In general, there is nothing special to say - we create a requirement, formulate it and, if necessary, associate it with other requirements. But there is one “but” - our requirements in the stage of active identification and collection did not take root in EA. And we slap them in the old manner - directly into word.
Repeatedly wondered why this is happening. At the moment we have come to the following conclusions.
As soon as we agreed on all our requirements, we immediately loaded them into EA in the appropriate part of the metamodel. And here all changes of requirements pass only through EA.
When the basic requirements were collected, we began to outline design solutions - the structure of IP, technology, communication between components, individual technical solutions according to this part of the metamodel:
It happened like this. A chart was created for a non-existent solution. Thanks to this, we collected in the Enterprise Architect project the elements describing the system and when forming solutions in which these elements were involved, we simply reused them, dragging them onto the necessary diagrams. In this case, the connections necessary for the analysis of influence start to work.
To describe the structure, we used four types of diagrams - use cases, components, deployment, and classes (to describe the logical data model). Plus, in some cases, EA's ability to use external objects — pictures, files, rich-text documents — was used.
Here is how, for example, the descriptions of one physical component (equivalent to the deployment module) look like on a diagram, in an EA project and its relationship, and nothing complicated.
Once the basic solutions are developed, you can begin to design and develop software code, but for the latter, “development” are needed.
The statement includes a description of how the IC should work in detail in the part of some function or scenario of work, which components and methods are involved in it, which entities of the logical data model are used.
Just in case, hereinafter, the function of the system (described as an icon of the use case) implies a complex process of the system, for example, processing an application for opening a savings account from the user can hide the “spreading” process of interaction between several systems or parts of the same system.
At this stage, the function of the system is the center. The following works are being built around the center.
After this work, we used this information to design and develop the code and test it.
The transfer process itself is organized through jira - a task is created, a place is indicated in the EA project, where the production is located, as well as the SVN branch.
The staging looks like this:
The design includes a description of the base classes, program interfaces, packages (in java terms) and their links with the system structure.
In addition, in the design we have the order of interaction of components and classes, showing the implementation of system functions.
This part of the recipe, we still keep a secret.
After going through several muddled steps of our recipe, we got our dish - a project in EA.
Someone, our recipe will seem strange, ridiculous. Someone will get a new one. Someone will start cooking and will be happy with the result, and some will not.
And this is normal - this is just our recipe, for our IT-kitchen.
Weare sure we hope that our notes will not be taken loosely and that there will be constructive criticism and useful questions, starting from which we can correct our recipe and continue our notes on the use of Enterprise Architect and their publication on Habré.
1. Instead of the preface
1.1. About the beginning
Once upon a time, in a far-away galaxy ... No, not that. A long time ago, it seems, last Friday we decided that, perhaps, there would be enough of a Word, paper, some jira tasks, etc. - it's time to use something more appropriate. It became inconvenient, since everything was confused in cross-references, in different ways to maintain historicity and several approaches. So began our journey to using Enterprise Architect (EA). Why enough? There are a lot of reasons. Each of the participants in the process has its own. The main reason is absolute power.
')
Absolute power in the sense that we really wanted to
Quite a fair question - “Why did you choose Enterprise Architect, and not any other tool?” At the time when the process started, we had jira, confluence, MS office, SP, Sybase Power Designer (now SAP Power Desiner) and Sparx Enterprise Architect. Actually, the question was decided by the personal preferences and skills of EA at that time (it was 2011-2012), as well as people who were pioneers and gave away the hearts and minds of Enterprise Architect. Perhaps this was a mistake.
1.2. A bit of captaincy
The main stages of the life of a project to create an information system (and in general, probably, almost any project up to the definition of each stage) are quite obvious - both in accordance with GOST and simply on the basis of common sense. It:
- concept,
- sketch,
- terms of reference (collection and identification of requirements),
- technical design (architecture development),
- design engineering (development and design),
- introduction,
- operation and maintenance.
Note: the numbers here are for clarity - the stages can be combined, not have clear boundaries, go into the iteration, etc.
For concepts, we are not using Enterprise Architect yet, as you usually have to do everything quickly, urgently, very beautifully. So this is a word, visio with various extensions or other drawing machines (where is the beauty in general). The sketch, unfortunately, does not interest the customer, although we would be happy to prepare it at EA. The last two points are either about errors (they are solved (at least with us) by other means and tools) or improvements, and then it all wraps up in paragraphs 3-5.
Therefore, let's talk about such steps as the technical task (collection and identification of requirements), technical design (architecture development), design engineering (development and design).
1.3. For those who can not wait to try the result (spoiler)
2. About the recipe
2.1. Ingredients
Here are the main things you need.
- Discomfort - if you are comfortable in your current process of creating an information system, if everything suits you, then either you already have an EA (maybe something like that), or you don’t need it, and you and everything is fine.
- Meta-model of the system - understanding and description of how and in what terms the system will be described.
- Formal language - natural language is not well suited to accurately and compactly convey the meaning of a message (in our opinion). And here comes the formal language. We used UML.
- Enterprise Architect's knowledge is at least minimal, but the more desires you have, such as versioning, access control, working in one project, etc., the deeper the immersion is up to the development of your own modules for EA (we don't have them yet).
Not prevent:
- Patience and flexibility. Inflexible stiffness is not our motto. The introduction of a new approach, some serious changes in the old - this is hard (especially for the first time). There will be a lot of questions, mistakes, inertia, frank resistance, so you need to endure and come to compromises and take this into account in your personal recipe. For example, we now calmly treat exceptions when EA becomes just a tool to document and store what has been done. Next we will focus on this example of working with requirements.
- Healthy laziness and delicious coffee. Laziness in the sense that laziness to do a lot of routine that can be automated. This is correct, in our opinion. So, for example, we finally became lazy to write documents - we create them from EA. However, in some cases, these are documents according to GOST, and then we do it in two stages - first, the “meat” from EA, and then with the VBA scripts our gallant technical writers turn it into GOST. Well, coffee - without it, of course, possible, but where without it? We really love java.
Oh yeah, I almost forgot - we still need a friendly and enthusiastic team. Without this, nowhere. We have just this.
2.1.1. About discomfort
For us, these were:
- Different tools - we want one.
- The lack of centralization in the descriptions of the system (I want to stop behaving like a protein, which somewhere hid a nut and forgot where) - one store for everything.
- We do not have the
absolute powerto conduct a quick impact analysis - we want to know what will fall apart if we divide the component into two, or what will affect the change in the scenario of the system, etc. - Tired of writing documents - I want to "click" and the document was.
2.1.2. About metamodel
In our opinion, consciously or unconsciously, almost any team of people involved in the process of creating something can tell about it: what it creates, what it consists of, how it works, etc. Maybe not very nice or connected, maybe with the “holes” in the presentation. But, nevertheless, it can. So it is with the creation of an information system. At the top level, we probably all imagine that there are requirements - functional and some more, important and not very clear and vague, there is something that shows the basic principles of implementing these requirements - which units in the system, which basic technologies are used that the system surrounds, as all this is connected to each other. There are details and requirements, and implementation principles, description of data structures, etc. We called all these basic parts and the rules of communication between them the “metamodel”.
In our recipe, the meta model is quite a figure skater - we outline its contours and then we will look at each part in a little more detail:
- requirements,
- information system structure
- productions,
- design.
2.1.3. About language
We can not boast of a long agony of choice, since we almost immediately chose UML as the most common option. Well, "rushed." Surely, we could use different bundles of different languages ​​and notations, and we will probably come to this by choosing our own model for each of the parts of the metamodel, but so far we are happily relieved of the agony of choice and of crossing notations and languages.
2.1.4. Knowledge of Enterprise Architect
At the very beginning there was no knowledge. In the sense, of course, there were, but fragmentary ones, about how to work alone or how to form simple documents. In general, looking back, you are struck by our
2.2. Cooking
So, we have discomfort, metamodel, formal language, knowledge of Enterprise Architect, friendly team, laziness, coffee, patience and flexibility.
Now we need to take EA, create a project in it, create a structure according to our metamodel, and start contributing elements and links.
We try - we look at the result, we estimate - we liked it, we apply further. I didn’t like it - we are correcting the metamodel, updating the elements, connections, and so on until we prepare it.
How to understand what did not like? You do not like, you are even more uncomfortable, you do not feel good. Somehow very trite and vague, right? You are absolutely right, dear readers. But some very clear and rigorous criteria for the general case are difficult to propose, and probably not necessary. But we, of course, will share our experience.
2.2.1. About the project (which is in EA)
A project in Enterprise Architect consists of a set of root packages.
In turn, each root package may contain other packages. And each normal package - elements (here elements are referred to as elements of EA) and diagrams.
Root directories can be located locally — in an EAP file, or they can be centrally located in a database. In addition, each package can be saved as xml in the repository version control system.
We did not manage to store the project in the database. At first it was great - the changes were reflected in everyone, but after a while we had errors, some strange situations with the disappearance of elements, etc. In the end, we spat it to treat and at the time forgot. But the version control system we pulled and screwed the SVN.
In the most primitive version, you can create the main parts of your metamodel as root packages or first-level packages and get a structure for storing model elements and the connections between them. In our example, a little more complicated, since some of these parts are spread over packages of the first level. But as a whole the principle is traced. In addition, by “screwing” SVN, we were able to work with branches and releases, and delineate access based on the principle of “one package - one owner”.2.2.2. About requirements
The requirement (as an EA element) looks like this:
This is how the vast majority of EA elements look for UML (so I saw one - I saw the rest).
Metamodel, in terms of requirements, we have quite a boring one - below is just this part in a larger plan.
In general, there is nothing special to say - we create a requirement, formulate it and, if necessary, associate it with other requirements. But there is one “but” - our requirements in the stage of active identification and collection did not take root in EA. And we slap them in the old manner - directly into word.
Repeatedly wondered why this is happening. At the moment we have come to the following conclusions.
- Our customers love (and for us it's a bit strange) word and excel. Well, of course, the presentation (and even beautiful). They don't want to see anything else.
- We have not learned how to work with EA quickly and conveniently for ourselves in terms of requirements, when they need to be formed and coordinated very quickly. But we think that we will succeed in the end, we are working on it, and there is hope that the next wave of requirements will go to EA.
As soon as we agreed on all our requirements, we immediately loaded them into EA in the appropriate part of the metamodel. And here all changes of requirements pass only through EA.
2.2.3. About the structure
When the basic requirements were collected, we began to outline design solutions - the structure of IP, technology, communication between components, individual technical solutions according to this part of the metamodel:
It happened like this. A chart was created for a non-existent solution. Thanks to this, we collected in the Enterprise Architect project the elements describing the system and when forming solutions in which these elements were involved, we simply reused them, dragging them onto the necessary diagrams. In this case, the connections necessary for the analysis of influence start to work.
To describe the structure, we used four types of diagrams - use cases, components, deployment, and classes (to describe the logical data model). Plus, in some cases, EA's ability to use external objects — pictures, files, rich-text documents — was used.
Here is how, for example, the descriptions of one physical component (equivalent to the deployment module) look like on a diagram, in an EA project and its relationship, and nothing complicated.
2.2.4. About productions
Once the basic solutions are developed, you can begin to design and develop software code, but for the latter, “development” are needed.
The statement includes a description of how the IC should work in detail in the part of some function or scenario of work, which components and methods are involved in it, which entities of the logical data model are used.
Just in case, hereinafter, the function of the system (described as an icon of the use case) implies a complex process of the system, for example, processing an application for opening a savings account from the user can hide the “spreading” process of interaction between several systems or parts of the same system.
At this stage, the function of the system is the center. The following works are being built around the center.
- The specification of the script functions.
- Algorithms used in the script.
- Architectural requirements are a restriction that must be met when implementing or algorithmizing a particular step.
- Detailing and refining the logical data model.
- Formation of a physical data model.
- Formation of "business interfaces" for components - a set of operations that are significant from the point of view of the subject area, which then need to be implemented. It should be noted here that the methods shown in the metamodel by the use-case icon are redundant - we thus link the steps of the specification of the function’s scenario and the corresponding interface.
- Refinement of links between elements.
After this work, we used this information to design and develop the code and test it.
The transfer process itself is organized through jira - a task is created, a place is indicated in the EA project, where the production is located, as well as the SVN branch.
The staging looks like this:
2.2.5. About design
The design includes a description of the base classes, program interfaces, packages (in java terms) and their links with the system structure.
In addition, in the design we have the order of interaction of components and classes, showing the implementation of system functions.
This part of the recipe, we still keep a secret.
3. Instead of conclusion
After going through several muddled steps of our recipe, we got our dish - a project in EA.
Someone, our recipe will seem strange, ridiculous. Someone will get a new one. Someone will start cooking and will be happy with the result, and some will not.
And this is normal - this is just our recipe, for our IT-kitchen.
We
By the way, we have jobs!
Source: https://habr.com/ru/post/352826/
All Articles