Hi, all.
I've been doing a lot of traveling, so it has been only until doday that I can post my unconventional approach:
I rename the namespace (the root of my project tree, originally named "Views") with the name of the company or institution that sponsors the project. As long as it does not get too large, or as long as there are no intra-company confidentiality considerations, I try to use a single .EAP file for each company or institution.
I rename the use case view with the name of the project; i.e., Sistema Informático Comunitario. This is important because --as you will see later-- this is going to be the title of the RTF document.
If this is the second project for the same sponsor (the second project under the same namespace), I create a new view, and give it the name of the new project. In other words, the use case view or the new view will be the root package for the project.
I delete all other predefined views, except the logical view (because it has a cool icon to represent "structural things"). I place all my infrastructural and reusable stuff here, such as the package I made with the Ericksson-Penker businss process metamodel diagram and its classes (which I copied from their book), as well as packages with patterns that I have been accumulating over time (such as Fowler's dynamical hierarchies and measurements).
I rename this view as "Infrastructure", and it will be a common view to all projects under the same namespace.
Under my project root view (the former use case view), I either create, rename or import --shamelessly steal from existing projects-- the following packages:
1. Project Definition, with a brief introduction in the package's text. The Project Definition consists of two packages:
a. Requirements, with its own goals and requirements diagram, and its corresponding objects (no classes are stored here: goal classes, for example, reside in the EP metamodel). Each goal and each requirement contains a description, and in the diagram they are shown with dependency links. This package is not an indispensable part of the model, so I sometimes omit creating it.
b. Project Organization, with an org chart that represents the classes and instances for each resource (usually stereotyped as «worker»). All human resources (workers, actors, sponsors...) are kept and maintained in this package.
I obtain all project definitions (mainly goal and requirement descriptions) by copying and pasting from the Project Scope Document that serves as the formal contract with the customer. The Scope Document is created outside EA, but I'm working on trying to create the core of this document from within EA. I still find it practical --mainly because of time pressure-- to reuse scope documents (with their attached project plans) from previous projects.
2. Processes (or Process Model). I present the business process diagram and its objects here.
3. Use Case Model. I present a diagram with a general view of the use cases, and a package for each significant group of use cases. As has been previously discussed, I nest sequence diagrams under their respective use cases.
4. Domain Model. This is a representation of "real world" objects and their relationships. It can be seen as the most important structural antecedent for the data base model, but it also plays a very important descriptive role in the project.
5. Design Model. Usually contains the following packages:
a. If I have a situation in which the previously described use case model package contains the "as is" description of the current state, I include a Projected Use Cases Model (with their interactions) under this design model package.
b. Database Model. It contains --of course-- the diagram (or diagrams) for the database, and all persistent, structural classes. It can contain a sub-package for views (that is, views that are not real tables). I nest all State elements under their respective classes in this package.
c. Interface Model: Windows, dialogs, and so forth, which were discovered during interaction diagram elaboration. When we use the EA screen definition feature, this package contains the screens.
d. Control Object Model, with modeling elements for stored procedures and other control objects. Generally, I do not need to diagram these, because their behavior is already modeled in the interaction diagrams.
6. My last package is the Technical Architecture Package. I try to get away with a single diagram for nodes and components, but I can break this up as needed. All nodes (elements for hardware and so forth) and components (EXEs, and so forth) are stored and described here.
I have numbered the main packages here, but in order to have flexibility I do not number them in my actual project tree.
If the project is large, I try to split each main package into supackages so that each modeler "owns" a subpackage. Each subpackage can be conveniently exported, imported, EMailed... as an XMI.
I generate RTFs from the root of each project (that is, from what use to be the use case view), and each main package is a "chapter" of the RTF documentation.
Please note that what I have described here does not conform to Spark's recommended way of doing things. Keep in mind that preserving EA's original views makes your project compatible with EA's rich features and documentation. You will lose some of these if you do things as I have described above.
Also, please take into account that my intention in including this posting is not to tell everybody else that my way of doing things is the best, but only to contribute ideas that could be useful to other forum participants.
Jaime Gonzalez
