We are preparing a project in Sparx Enterprise Architect. Our recipe

    Dear Habr, we decided to share notes and our basic recipe for preparing projects in Sparx Enterprise Architect. Moreover, by project we mean the creation of some kind of information system. Ahead of you is a story about how everything is organized with us - examples of diagrams, project structure in Enterprise Architect, a little about requirements, design and development plans.

    A source

    1. Instead of a foreword

    1.1. About the beginning

    Once upon a time, in a distant, distant galaxy ... No, not that. Once upon a time, it seems, last Friday, we decided that perhaps there would be enough word, paper, individual jira tasks, etc. - it's time to use something more suitable. It became inconvenient, since everything was confused in cross-links, in different ways to maintain historicity and several approaches. So began our journey to using Enterprise Architect (EA). Why is that enough? There are many reasons. Each of the participants in the process has its own. The main reason is absolute power.

    Darth Sidious analyzes impact. The dependencies are shown in blue (frame from the movie Star Wars: Episode 3 - Revenge of the Sith)

    Absolute power in the sense that we really wanted to influence the minds and rule everyone to understand the connections between the elements of the information systems being created (elements in the broad sense - not only what is developed and works later, but also the requirements, and specifications, and other things that were used to create the system) and not only understand, but also quickly find these very connections, analyze, show the customer for whom “any change can be real izovat one day and wonder why you need two weeks. "

    A perfectly fair question - “Why did you choose Enterprise Architect, and not any other tool?” At the time the process began, we had jira, confluence, MS office, SP, Sybase Power Designer (now SAP Power Desiner) and Sparx Enterprise Architect. Actually, the question was decided by personal preferences and skills of EA at that time (it was 2011-2012), as well as people who were pioneers who gave hearts and minds to Enterprise Architect. Perhaps this was a mistake.

    1.2. A bit of captainhood

    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 according to GOST, and simply on the basis of common sense. It:

    1. concept,
    2. sketch,
    3. terms of reference (collection and identification of requirements),
    4. technical design (architecture development),
    5. detailed design (development and design),
    6. implementation
    7. operation and maintenance.

    Note: the numbers are here for illustrative purposes - stages can be combined, have no clear boundaries, go into iteration, etc.

    For concepts, we do not yet use Enterprise Architect, since we usually need to do everything quickly, urgently, very beautifully. So this is word, visio with various extensions or other drawing machines (where, well, beauty in general). The sketch, unfortunately, is not of interest to the customer, although we would be happy to prepare it in EA. The last two points are either about mistakes (they are solved (in any case with us) by other means and tools) or about improvements, and then it all wraps up in points 3-5.

    Therefore, we’ll talk about such stages as the terms of reference (collection and identification of requirements), technical design (development of architecture), detailed design (development and design).

    1.3. For those who can’t wait to try the result (spoiler)

    Diagram of components (in this case, each component is one deployment module), the relationships between them, the basic protocols.

    Deployment diagram of general software by nodes, indicating the main relationships

    2. About the recipe

    2.1. Ingredients

    Here is the basic thing you need.

    • Discomfort - if you are comfortable in your current process of creating an information system, if everything suits you, then you either already have EA (maybe something like that), or you do not need it, and everything is fine with you anyway.
    • System metamodel - 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 the message (in our opinion). And then a formal language comes to the rescue. We used UML.
    • The knowledge of Enterprise Architect is at least minimal, but the more you have desires like versioning, access control, working in one project, etc., the deeper the immersion is right up to the development of your modules for EA (we don’t have them yet).

    Not prevent:

    • Patience and flexibility. Unbending rigidity is not our motto. The introduction of a new approach, some serious changes in the old one, is hard (especially for the first time). There will be many questions, mistakes, inertia, outright resistance, so you need to endure and compromise and take this into account in your personal recipe. For example, we are now very calm about exceptional situations when EA becomes just a tool to document and store what has already been done. Further we will stop on it on an example of work with requirements.
    • Healthy laziness and delicious coffee. Laziness in the sense that laziness is a lot of routine that can be automated. This is correct, in our opinion. So, for example, we were finally lazy to write documents - we create them from EA. True, in some cases these are documents in accordance with GOST, and then we do it in two stages - first the “meat” from EA, and then our valiant technical writers turn it into GOST with VBA scripts. Well, coffee - without it, of course, you can, but where without it? We really love java.

    Oh yes, I almost forgot - I still need a friendly and enthusiastic team. Nowhere without it. We have just that.

    2.1.1. About discomfort

    For us, these were:

    • Different tools - we want one.
    • The lack of centralization in the system descriptions (I want to stop behaving like a protein that hid a nut somewhere and forgot where) is one storehouse for everything.
    • We do not have the absolute power to conduct a quick analysis of the impact - we want to know what will fall apart if we divide the component into two or that the change in the scenario of the system’s operation, etc.
    • Tired of writing documents - I want the “click” and the document to be.

    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 beautiful or connected, maybe with the "holes" in the presentation. But, nevertheless, it can. So is the case with the creation of an information system. At the top level, we all probably imagine that there are requirements - functional and some others, important and not very clear and blurry, there is something that shows the basic principles for translating these requirements - which blocks in the system, which basic technologies are used that the system surrounds, how all this is interconnected. There are details of requirements and implementation principles, a description of data structures, etc. All these basic parts and rules of communication between them we called the "metamodel".

    Our metamodel. Beauty!

    In our recipe, the metamodel is enough for the skater - we outline its contours and then look at each part in a bit more detail:

    • requirements
    • information system structure
    • staging
    • design.

    2.1.3. About language

    We cannot boast of long torments of choice, since we almost immediately chose UML as the most common option. Well, "rushed." Surely, one could use various combinations of different languages ​​and notations and, probably, we will come to this by choosing our own metamodel for each part, but for now we are happily spared both the pains of choice and the crossing of notations and languages.

    2.1.4. About Enterprise Architect Knowledge

    There was no knowledge at the very beginning. In the sense, of course, there were, but fragmented, about how to work alone or how to create simple documents. In general, looking back, you are amazed at our dementia and the courage of self-confidence and the speed of learning. Since then, plunging more and more into the abysses of Enterprise Architect, we still discover new horizons. Now we own the following aspects: work with the EA project and elements, versioning, access control, document generation.

    2.2. Cooking

    So, we have discomfort, metamodel, formal language, Enterprise Architect knowledge, friendly team, laziness, coffee, patience and flexibility.
    Now you need to take EA, create a project in it, create a structure according to our metamodel and start making elements and connections.
    We try - we look at the result, evaluate - we liked it, apply it further. I didn’t like it - we correct the metamodel, update the elements, connections and so on until we cook it.

    How to understand what did not like? You do not like it, you are even more uncomfortable, you do not feel the benefit. Somehow very banal and vague, right? You are absolutely right, dear readers. But it’s difficult to propose some very clear and strict criteria for the general case, and probably it’s 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 every ordinary package includes elements (here elements are EA elements) and diagrams.
    Root directories can be located locally in the EAP file, or they can be located centrally in the database. In addition, each package can be saved as xml to the repository of the version control system.

    We could not cope with the storage of the project in the database. At first it was cool - the changes were reflected in everyone, but after some time we started to make mistakes, some strange situations with the disappearance of elements, etc. As a result, we spat it to treat and forgot for a while. But we pulled the version control system and screwed 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 relationships between them. In our example, it’s a bit more complicated, because some of these parts are spread out on the packages of the first level. But in general, the principle is traceable. In addition, by “screwing” SVN we got the opportunity to work with branches and releases and access control according to the principle of “one package - one owner”.

    2.2.2. About requirements

    The requirement (as an EA element) looks like this:

    An example of a requirement for ensuring electronic interaction

    This is how the vast majority of EA elements for UML look like (so I saw one - I saw the others).

    The metamodel, in terms of requirements, is rather boring with us - just this part is lower in a larger closeup.

    In general, there is nothing special to say - we create a requirement, formulate it and, if necessary, connect it with other requirements. But there is one “but” - our requirements in the stage of active identification and collection have not taken root in EA. And we spank them the old fashioned way - 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, presentations (and even beautiful ones). They don’t want to see anything else.
    • We have not learned how to quickly and conveniently work with EA in terms of requirements, when they need to be formed and agreed very quickly. But we think that we will succeed, we are working on it, and there is hope that the next shaft of requirements will go to EA.

    As soon as we agreed on all our requirements, we immediately uploaded them to EA in the corresponding part of the metamodel. And now all the changes in the requirements pass only through EA.

    2.2.3. About the structure

    When the basic requirements were assembled, we began to sketch out design decisions - the structure of the IP, technology, communications between components, individual technical solutions according to this part of the metamodel:

    It happened like this. A diagram was created for a solution that does not exist yet. Due to this, we accumulated elements describing the system in the Enterprise Architect project and, when creating solutions in which these elements were involved, we simply reused them by dragging them to the necessary diagrams. In this case, the connections necessary for the analysis of influence begin to work.

    To describe the structure, we used four types of diagrams - use cases, components, deployment, and classes (to describe a logical data model). Plus, in some cases, EA’s capabilities for using external objects — drawings, files, rich-text documents — were used.

    Here's how, for example, the descriptions of one physical component (the equivalent of a deployment module) look like on a diagram in an EA project and its relationship, and nothing complicated.

    2.2.4. About the productions

    After the basic solutions have been worked out, you can start designing and developing the program code, but for the latter you need “development statements”.

    The statement includes a description of how the IP should work in detail in terms of some function or scenario, 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 the pictogram of the use case) means a certain complex process of the system, for example, processing the application for opening a savings account from the user can hide the “weighty” process of interaction between several systems or parts of one 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 for the function.
    • Algorithms used in the script.
    • Architectural requirements - a limitation that must be observed when implementing or algorithmizing one or another step.
    • Detailing and refinement of 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 icon of the use case are redundant - we thus link the steps of the specification of the script of the function and the corresponding interface.
    • Clarification of relationships between elements.

    After these works, we used this information to design and develop code and test it.

    The transfer process itself is organized through jira - a task is created, it indicates the place in the EA project where the statement is located, as well as the SVN branch.

    The statement looks like this:

    2.2.5. About design

    The design includes a description of the base classes, software interfaces, packages (in java terms) and their relationship with the structure of the system.

    In addition to this, in design we have an order of interaction between components and classes that show the implementation of system functions.

    We keep this part of the recipe secret.

    3. Instead of a conclusion

    After going through the somewhat confused steps of our recipe, we got our dish - a project in EA.

    To some our recipe will seem strange, ridiculous. Someone will learn new things for themselves. Someone will start to cook and will be happy with the result, while someone will not.
    And this is normal - after all, this is only our recipe, for our IT-kitchen.

    We are confident that our notes will not be taken in hostility and that there will be constructive criticism and useful questions, starting from which we can correct our recipe and continue our notes about using Enterprise Architect and publishing them on Habré.

    Also popular now: