Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - jaimeglz

Pages: [1] 2 3 ... 11
General Board / Re: Deployment diagram / Relationship matrix
« on: October 16, 2002, 06:33:57 am »
Hi Stephan,

Let's go at it step by step, so we can determine what the problem is.

I am using EA 3.10 Build 504.

I create a deployment diagram called, say, "PC Deployment". In this diagram I have created a node called "Community_proj_PC": this is not an instance (object), but a representation of the classifier itself. I have stereotyped it as "pc" (it could be something else, though).

In the same project, I have created four components: Linux, PostGreSQL, StarOffice and community_system, and only the last component is stereotyped (as executable).

I have dragged the components inside the node (again: as classifiers, not as instances), and I have "Use Stereotype Icons" checked in my Diagram Properties.

In this diagram, both nodes and components are shown with their respective icons.

As Mikkel has said, I drag the components out of the node, and an aggregation relationship appears. I drag the components inside the node again, because that is the place I want them to be.

I open my relationship matrix, choose the root of the project tree as both source and target; choose Node and Component as "Type", Aggregation as "Link Type", Bi-Directional (or Target -> Source) as "Direction". The matrix correctly shows that "Community_proj_PC" has the components. I save the matrix as a new profile (Profiles -> Save as New Profile).

Are you using instances of nodes or instances of components? In that case, you are right, and EA is showing instances with object (and not with node or component) icons. The "Community_proj_PC" has the PC icon in the upper right corner, but otherwise it is an object icon (even though I have selected "Instance has classifier style" in the Diagram Behaviour dialog).

In the case of instances there is problem, and I want to call Sparx attention to it (although, in all modesty, there is probably some good reason for this).

However, as to your original question, I do get a correct matrix if I compare object vs object, choose aggregation and the appropriate source to target (or biderectional) as Direction. I wouldn't like to use the object vs object matrix, because it does get confusing: in this matrix I have all sorts of objects, and not only instances of nodes and components.

I hope this helps.


General Board / Re: Deployment diagram / Relationship matrix
« on: October 15, 2002, 10:06:44 am »

The way I do it is by nesting the components in the nodes. For example, I drag the PostGreSQL and StarOffice components into the PC node in the project tree.

It shows up fine in the diagram when I drag the components into the nodes (without auto-instance).

I do not see any conflict in having nodes (a classifier, say the "feline_brain" class) containing components (another classifier, say the "paw_control_center"). There would be a conflict if I embed an instance (the concrete "Timy:paw_control_center") inside a classifier (the general "feline_brain"), or viceversa. In other words, an instance should be nested inside an instance, and a classifier inside another classifier.

Also, check your diagram properties (double click on the diagram) to see if "Use stereotype icons" is activated.

Hope I am not confusing things.

Jaime Gonzalez

General Board / Re: Which views to divy-up the artifacts?
« on: October 09, 2002, 12:46:28 pm »
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

General Board / Re: Mix and Match Project Views - How
« on: May 29, 2006, 07:17:59 am »

I must begin by admitting that I don't understand very well what you are trying to do (and I don't understand at all what .cat files are); but, anyway, I would like to contribute a solution I have found useful for handling objects that are common to different projects.

1. Create an "Infrastructure" view package, with subpackages for metamodel elements (for instance, a class diagram for "objective", "problem", "resource"... ), and also for your home-made reusable components (classes, tables, whatever...), as well as commercially available components, hardware, and so forth. You can define your best-practices and reusable ensembles here (for  instance, your account, sub-accounts, cost center classes, their use cases, state charts...).

2. Create a general "Reusables" view package, for individual components that are not strictly part of your metamodel or your ensembles. You can include a "Dust bin" package here, so you can phase out elements instead of deleting them.

3. All your projects must have very similar high-level views and packages (requirements, business processes, use cases, database model, user interface model, architecture), even if they vary in detail.

4. Be sure your technology-independent conceptual (or "domain") model is kept up to date, so you have good "canonical" classes.

It seems to me that the challenge is much more logical (that is, a good hierarchy of reusables) than technological.

Hope this helps,


General Board / Re: So long and thanks for all the fish...
« on: April 24, 2007, 03:29:43 pm »
Hope to see you back, Sargasso. Although I don't write often, I still check this forum often. Both as a modeller and project manager, I still find EA's value way above the rest.

Cheers and good health!

General Board / Re: database engineering -- views
« on: February 12, 2006, 07:50:12 pm »
I'm probably stating something obvious, but what I do to import a view and its attributes is to create a temp table with the view, and then reverse-engineer it into EA. In Oracle 10g, for instance:


FROM vi_audit
WHERE rownum < 2

For convenience, I reverse-engineer t_tmp into a diagram that exists in a package called tmp (a multi-purpose diagram outside the main model). In the tmp diagram, I rename t_tmp with the real view name, change the stereotype from <<table>> to <<view>> (you can create a new UML stereotype, and name it <<view>> or << table view>>) and then drag the newly created class into its permanet package ("DB views", for instance) in the model.

You can create ordinary class diagrams for your views, so they become visible to developers and other users. For completeness, you can create other specialized diagrams, where you can join the views to their corresponding table or tables by dependency relationships (the dependency stereotype can be <<derive>>). This way you can always keep track of view dependencies.

Hope this helps, although it is somehow time-consuming for a large number of views.


General Board / Re: stand alone oracle sequence generators
« on: June 03, 2006, 02:39:37 pm »
Hi, dmaxwell,

Here is what has worked for me:

1. Create a new "sequence" or "db_sequence" stereotype for classes. This is the stereotype you will use for your sequences, which you will model as classes.

2. Create one or several ordinary class diagrams with your tables joining their respective sequences with dependency links (stereotype <<call>>). This way you can keep track of which tables have collaborating sequences.

3. In other collaborations in this forum, I have described schematically how to use the custom code generation feature in EA, and how to create Oracle custom code templates (you can find a better description in EA help, anyway). I will include here only the code for the "sequence" stereotype override template, at the Class Body level:


FROM dual;

4. You have to generate your sequences with Ctrl+G (and not as DDLs).

To my knowledge, sequences give the highest transactional performance (and practically no contention at all) when generating consecutives for your PKs. So they have become a very important part of my modeling, as well as of my database objects.

I hope this helps,


General Board / Re: Create Temporay Table
« on: May 25, 2006, 07:31:25 am »
Hi Ifernigrini,

I suggest the following solution:

1. Create a class stereotype called "temp table".
2. Create the "Oracle" language in the customized code generation templates (Settings -> Code generation templates). Take a look at an existing language template (for example, the C++ templates), so you can understand the basics for your Oracle templates.

Your will only need a File template that lists your classes...

--   DDL / PL/SQL
--   File: %fileName%
--   %eaDateTime%
%list="Class" @separator="\n"%
--   End of gen'd code

... a simple class template...

--   Version: %classVersion%
--   %ClassBody%

... and a stereotype override for "temp table" at the Class Body level. Here's my stereo override for the "view" class stereotype:


You will probably not need the opBehaviour for what your want.

3. In the diagram, do a Ctrl + G  in the temp table class, fill in the file you want to generate, and be sure to specify Oracle as the language.

As stated in previous forum contributions, there is a learning curve involved in using customized templates, but this is the way to unleash EA's power. And it certainly has helped me to model, document and maintain hundreds of objects that are not currently supported (views, stereotypes, START scripts...).

Hope it helps,


General Board / Re: EA uml 2.0 implementation
« on: May 16, 2006, 07:04:32 am »

I use EA quite intensively, and so far have not found any inconsistency with  UML 2.0. What I have found is that EA's help documentation is pretty much up to date in regards to 2.0. Hopefuly, the EA critics that elaborated the survey could be more specific.



General Board / Re: Track changes in requirements
« on: May 15, 2006, 06:42:26 am »
Hi Zatak,

Here is another possible solution.

Under the package that contains your use cases, or even as a high-level package in your model, you can create a package called "Model evolution", or whatever seems appropriate. In that package, you can create a diagram for your particular package or use case, where you will relate the old package (or the old use case, activity, or whatever...) with the new one. UML has the <<trace>> dependency relationship stereotype, which is defined by Rumbaugh as "a dependency that indicates a historical relationship between two elements...".

Keep the old elements in the "Model evolution" package, and place the new behaviour elements in your use case (or whatever) model. You can now create a matrix with the dependencies between the old and the new, and keep a very neat history of your model evolution.

Hope this helps,


General Board / Re: State Machine - How to defer an event?
« on: March 29, 2006, 07:54:42 am »
Hi Juergen,

Add an operation to the state (right-click on the state, then click on Operations), in the form: event-name / defer. You can overwrite "Do Action" with the event name, and write "defer" as the Name. As Rumbaugh explains in his UML Reference: "The reserved action name defer indicates an event that is deferable in a state and its substates".

Hope this helps,


General Board / Re: Use Case Report
« on: March 25, 2006, 01:14:29 pm »
Hi rowmarcus,

I've been embeding use cases in a similar way, and it works fine in generating the documentation. To generate the RTF with all the use cases, here is what works for me:

1. Click on the package you want to generate, and press F8.
2. Click on Switch Generator.
3. Fill-in and choose whatever info or selections you prefer, but make sure to select "Process all children" (under Options, in the lower right hand side of the dialog).
Then, just click on "Create".

By the way, embeding sequence diagrams or state machines under their respective use cases makes the use case scenarios very clear and understandable.

Hope this helps,


General Board / Re: Controlling diagram size in RTF Docs
« on: March 25, 2006, 01:37:20 pm »
Hi all,

EMFs sometimes (not allways) have to be resized; but, at least in my experience, they scale very, very well and come out great both in display and printed forms. So, I'm willing to put up with a little extra work after generating the documentation. However, in order to dimish the tedious resizing effort, it is best not to generate the whole project, but only to generate the pertinent package and then cut-and-paste into the deliverable document. (This can be automated via the MS Word Master Document technique that is explained in the EA documentation.)



General Board / Re: slow RTF generation
« on: March 22, 2006, 06:26:52 am »
Hi Steve,

I'm working on a medium-to-large project, with over 2300 elements. Generating an RTF of the whole project with an outdated machine (1 GHz, 256 MB of RAM) takes about 20 min, and generating the html takes about the same. So, my guess is that the 2 hours can be due to networking bottlenecks. If you are working on a centralized EA database (SQL Server, Oracle...), do try to copy your project to a local file (Tools -> Data Management -> Data Transfer), open your the local project you have just copied, and gen your RTF on your local disk.

Another solution would be to gen the RTF by package by package, and check what is causing the delay.



General Board / Re: Any way to change name of Oracle sequence?
« on: March 21, 2006, 08:41:31 pm »
Hi Walter,

Hopefully, others will contribute a simpler solution on this topic; but, in my experience, sequences are totally independent of the tables, and should be modelled as such. For example, you can create a special package called "Sequences" in the package that contains your table's definition in your model. Since each table and it's corresponding sequence are independent from one another, there is nothing in Oracle that could directly tell a CASE tool that a sequence is tied to a table. (If you do model your seqs, I would suggest to create a <<dependency>> or a <<call>> relationship between each table and it's corresponding sequence in the diagram, so as to keep track of what seq belongs to what table.)

Please note that modelling sequences is not essential.

What can solve your code gen problem, however, is to include the CREATE SEQUENCE code together with (and just before) the trigger's code as one of the table's operations: create a new operation (say, tdb_cat_key), stereotype it as "trigger", copy or write your trigger's code into the operation's "Behaviour" tab, and have EA include both the CREATE SEQUENCE and CREATE TRIGGER code in the DDL:

-- Won't work if it is not initialized
FROM dual;
-- Create the trig
SELECT seq_cat.NEXTVAL INTO :new.cat_key FROM dual;
END tdb_cat_key;

When generating your DDL, and having selected the option to generate the trig, you will see this operation's code in the generated code. The seq and the trig will now be generated together with your table.

Hope it works for you as well as it has worked for me.


Pages: [1] 2 3 ... 11