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 - PhilR

Pages: 1 2 3 [4] 5 6
General Board / Re: EJB and UML modelling
« on: September 19, 2002, 11:28:24 pm »
Kelly, I will post some references under a new thread so that more people can use them.

General Board / Re: EJB and UML modelling
« on: September 19, 2002, 12:47:34 am »
Drives you mad doesn't it?  As well as resitance to change, I blame the way that people acquire knowledge in this industry.  First they hear a buzz word or acronym.  Then they read the minimum to see if it is relevant to them.  The they start talking about it as if they are experts.

Try this on people...

The UML is a standard notation similar to the one used for electrical circuit diagrams.  The standard tells you nothing about how to do analysis/design etc  Any more that a notation for electrical circuits tells you how to design satellite receivers!

The original designers of the UML (known as the three Amigos) also developed a process called the Unified Process (note the complete lack of an 'R' for Rational).  UP tells you how to apply the UML to the analysis and design of software.  It is in the public domain and there is a text book which fully describes it.

UP is not a complete software development process - it lacks advice on things such as project management, change control, quality assurance and configuration management.  

By strange coincidence, all of the Amigos work for Rational (and are probably major shareholders as well).  RUP is Rational's proprietary version of the UP.  It adds the missing bits to UP to make it a full-blown methodology.

Tools such as EA, Rose, Together J or Poseiden serve two functions:  they provide a drawing tool that conform to the UML notation and a repository which is linked to objects on diagrams created with the drawing tool.

In a perfect world, the tool would have no influence on the process being followed (hard to acheieve in practice because tool designers love to impose their own restrictions and interpretations).

Ideally you have three quite independent things: notation (UML), process (UP) and tool (EA rules).  You should be able to make a rational (pun intended), and cost-justified decision on what to use in each area, independently of what you use in the other areas.

If you are a marketing manager.  You try to build a strong link between the three so that you fill everyone's mindspace with the UML/Rose/RUP trinity. watch their eyes glass over and label you a subversive, wierdo or whatever.

Final point.  You can quite nicely combine combine UP with other public domain stuff such as the PRINCE2, or PMBOK project management methodologies.  You can get lots of process guidance from the CMM.  Then buy a copy of EA and you pretty well have the entire Rational circus.  Total cost US$150 :o  

I have some more references on this if anyone is interested.


General Board / Re: EJB and UML modelling
« on: September 15, 2002, 08:25:04 pm »
Wierd isn't it?  I have seen a lot of this during my career and think its a resistance to change - not a good thing in our industry.

Good luck with the profile.


General Board / Re: EJB and UML modelling
« on: September 12, 2002, 10:56:43 pm »
The friend is either misguided or has some underlying motive for saying this.

There is a UML profile for EJB developed by Sun.  EA has a neat facility for defining profiles.  Why not post to this board and ask if anyone has defined a profile or define one yourself based on the UML profile (not difficult).

Try the folowing link for more details

General Board / Re: Creating professional documentation
« on: September 12, 2002, 06:53:11 pm »
Did ramble on a bit didn't I?

I can imagine using the HTML template (because I know HTML) but RTF - spare me.


General Board / Re: Creating professional documentation
« on: September 11, 2002, 10:01:35 pm »
We are well advanced into a project which plans to produce client documentation directly from EA.  The approach we have taken is to use the RTF generator combined with Word macros.  Not elegant but it works and only required a modest investment of time.  We did a bit of up front planning as to how to organise our project stucture so it looks good in the final documents.

In general terms I can see a number of options for generating custom documentation.

1) Use the automation interface - undoubtedly the best in the long run but requires a knowledge of VB (which I don't have)
2) Use the standard RTF generator with Word Macros (as described above)
3) Dump the project to XML and generate the documentation from the XML.  I believe that PHP would make a great tool for this job (probably because I do know PHP!) but have not tried it yet.  This approach is vunerable to changes in the stucture of the XML file but since it is based on a standard (XMI) the core UML feature should be OK.
4) Open the .eap file in MS Access and develop reports based on the underlying tables.  This approach is not to be recommended because the structure of the underlying tables may change but it might get you out of a serious hole once in a while.  Also you must make sure the tables are opened read only or else documentation will be the least of your worries.

There is one other approach based on the automation interface which I have played with a bit.  PHP has a COM object interface and it appears possible to use the automation interface from PHP.  Combine this with a web server and you can have online access to the EA repository via a browser.  

Add HTMLDoc and you can even generate postscript and pdf files from the HTML!


Happy Documenting ;)

General Board / Re: Robustness Diagrams
« on: September 11, 2002, 10:22:46 pm »

What are you hoping to achieve with the stereotypes?

Good question  ???

Mainly an understanding of how useful they are.  I have read the book you mention and the point of robustness diagrams did not jump out and grab me.  Mainly because I missed the bit about control objects you quoted.

I get the point now - Thanks.

General Board / Re: Robustness Diagrams
« on: September 09, 2002, 09:20:25 pm »
Mmm... that sounds interesting.  Do you have the reference by any chance?

Perhaps there are four things involved  :-/

<<entity>> and <<boundary>> classes as normal
<<responsibility>> which replaces the <<control>> classes in the roubustness diagrams
<<responsibility>> is then allocated to the <<entity>>, <<boundary>> classes as per your description
<<control>> classes can be introduced to represent the use case and some of the responsibilities could be allocated to them as well?

Rules for allocating repsonsibilities might go something like this:

responsibility for querying <<entity>> state allocated to <<boundary>> classes
responsibility for responding to user gestures (clicks etc) allocated to <<control>> classes
responsibility for collaborations which realise the use case to <<entity>> classes

In effect this approach provides a bridge between the mode-view-controller pattern and robustness diagrams.

General Board / Re: Robustness Diagrams
« on: September 09, 2002, 07:21:06 pm »
I pobably didn't explain myself too well.  I am not really advocating a single control class but rather warning about generating masses of contol classes as a result of developing a robustness diagram.

I believe that control classes on robustness diagranms are not really classes but represent responsibilities of some other class.  This is because they are pure function.  Classes that are pure function can lead to weak OO designs.  Peter Coad derides such classes as "functional blobs".

However, having said this, I agree with your comments.  Used in the correct way, robustness diagrams are powerful technique for generating a first cut design.  Sequence diagrams require too much attention to sequence which is of course their strength in other situations :-)

Maybe what is required is a stereotype for a class <<responsiblity>> which can be used on a robustness diagram instead of a <<control>> class?

Finally, I am influenced by J2EE where control classes map naturaly to Session beans.  Sun's recommendation is to go for coarse-grained session beans rather than lots of fine-grained session beans.

Thanks for your thought-provoking comments.


General Board / Re: Robustness Diagrams
« on: September 04, 2002, 09:07:29 pm »
Be careful that you don't end up with stacks of controller classes.  I tend to view them as a rather abstract concept i.e. not every controller will become an actual class in the design.  The opposite problem is to create 'god' controllers that do (and know) too much.

Also if you adopt the model-view-controller pattern, boundary classes (GUI elements) can directly request the state of an entity class thus breaking the "rule" that boundary classes can only talk to controllers.

Also like to include another type of "boundary" class which is a data management class (boundary between the application and database).  This approach decouples the application from a specific database.  For example, the boundary classes encapsulate all the necessary SQL.  This class also talks directly to entity classes.

My robustness diagrams then look something like this:

ACTOR<-->Boundary (GUI)<-->Controller<-->Entity<-->Boundary (SQL)<-->DATABASE

This just happens to map rather neatly to an n-tier architecture.

Conclusion? Modelling rules where just made to be broken which is why EA is such a cool tool - it doesn't enforce lots of fussy rules ;-)


General Board / Re: Robustness Diagrams
« on: September 02, 2002, 07:53:44 pm »
Try double clicking on a class to display the class properties and then select the drop down list for 'stereotype' (directly under the class name).

If you select the 'entity', 'control' or 'boundary' stereotype the correct icon should be displayed in the diagram.


General Board / Re: How to keep track of datamodel changes
« on: September 10, 2002, 07:46:10 pm »
We are a team of three and we use the EA Change element as a sort of "Post It Note".  Anyone who wants to change an area of the model that is someone else's responsibility adds a change element to the digram describing the necessary changes.

Works well.


General Board / Re: Import from Rational Rose
« on: August 19, 2002, 08:32:17 pm »
I have sucesfully imported a model from Poseiden UML.  I got all the classes OK but no diagrams.  Luckily it was a simple matter to drag and drop the classes onto a new EA diagram.

Even without the diagrams this was a time saver.

General Board / Re: Tracing Requirements to Problem Statements
« on: September 02, 2002, 08:08:24 pm »
We are sort of doing this except that we started to use EA after our requirements had been defined (in Word).

I am guessing that the EA 'Requirement' element is a stereotype class (Sparx comment?).  In which case you can relate requirements to other model elements using an 'Implements (Relisation)' relationship. I have tried this and it seems to work OK.

You could then use the 'relationship Matrix' to check on reqirements tracability.  If say, you had requirements as row headings and all other elements as column headings, a blank row would be an unfulfilled requirement and a blank column would be an element that could not be traced to a requirement.

The only problem I can see is that requirements definition is primarily a text based exercise and entering and editing large volumes of text in EA could become tedious.

There is a product that would make a good complement to EA in this area as a text management tool.  It exports XML so it should be possible to transform its output into XMI.  See

Don't be put off by the description of the product as a PIM it is a good general purpose text database.

Hope this helps,

General Board / Re: Link between use case and classes?
« on: August 29, 2002, 08:53:40 pm »
I agree with Jaime's comments especially regarding the 'CRUD' matrix as a powerful tool although I prefer to call this a 'Responsibility' matrix to get away from the database connotations.  

In fact, the matrix can be viewed as a summary of CRC (Class-Responsibility-Collaboration) cards.  Depending on how you arrange the matrix, column headings are Classes, row headings are Use Cases, row contents are Collaborations between Classes which realise a Use Case.  Column contents are the sum of all responsibilities for a Class.

Also I drag Classes directly on to Use Case diagrams and connect them to a use case with an Association.  Users love it as they can see everything on one diagram.  I do a single 'context' diagram with all use cases and actors but no classes and then a diagram for each use cases showing the classes.

As far as I can see this is a legal UML diagram since Classes and Use Cases are both classifiers and can have associations.  If its not legal I don't care since my users love it  ;).


Pages: 1 2 3 [4] 5 6