Messages

1

Suggestions and Requests / RSS Support

« on: April 13, 2005, 09:15:55 am »

Need I say more?

While in a lengthy project I'm usually absent from this forum(s), and RSS support would be welcome to find out about new stuff in EA or SparxSystems in general.

Regards,

Javier

2

Suggestions and Requests / Re: Tree Style Orientation

« on: November 15, 2004, 09:08:32 am »

I'll "third" it.

Moreover, I'd like to see the orientation be anywhere top, bottom, left, or right.

In addition, I'd request the tree style to be added to other connectors (e.g., aggregation).

Regards.

3

Suggestions and Requests / Knowledge Base

« on: November 09, 2004, 01:09:53 pm »

I am proposing a EA knowledge base.

The purpose would be to provide information on:

• Current issues with Enterprise Architect.  An issue would be somewhat similar to what Microsoft offers in their software support

• HOWTO articles that provide help to newcomers--and experts!

• FIX articles that explain an issue that has been fixed and the versions applicable, etc. (I don't know about you, but I find hard to read the release notes for each version of EA--kinda get lost.
  

Any ideas?

4

Suggestions and Requests / Re: Hide operations selectively

« on: November 04, 2004, 12:00:35 am »

I made a similar suggestion about a year ago...guess it hasn't been fulfilled.

Elision--thanks for the new term--is available in Rational Rose, and I assume in XDE.

IMO it should be doable to associate a view of a particular class with a given diagram.

Regarding Whitehorse, it's interesting to note that Microsoft approached the OMG about a year or two ago, then they came out with Whitehorse.  Talk about "embrace and extend" yet again.  IMO, Whitehorse will be a good test for UML.

I like UML, particularly UML2 because I can finally get a lot of the missing functionality in sequence diagrams and activity diagrams in particular.

It remains to be seen if Whitehorse is not one of those often underdeveloped tools, such as the clunky UML support for Visio for Enterprise Architects or the class designer in previous versions of Visual Basic.  Moreover, everybody but a naive architect knows that the diagrams are only part of the story, but verbal communication still has an important role in making a software architecture succeed.

If you hang out at the World Wide Institute of Software Architects (http://www.wwisa.org), you'll hear some horror stories from software architects consulting for Microsoft.  In addition, check Ward Cunningham (inventor of the Wiki concept) blog at Microsoft--he works for Microsoft now--and you'll see that (working) code is still very much appreciated over architecture and design.

Regards,

Javier

5

Suggestions and Requests / Re: Interfaces in UML2 and EA 4.0

« on: April 01, 2004, 12:38:22 pm »

Bruce,

Regarding your quotes:

The execution time semantics for an assembly connector are that signals travel along an instance of a connector, originating in a required port and delivered to a provided port.  

Perhaps an example would clarify this quote:

In COM, a component willing to provide events needs to provide an interface marked as a [source] interface.  A component willing to listen for those events needs to:
a) implement the interface in question (design time)
b) query the providing component for IConnectionXxx--basically, "registering" as a listener (runtime)
c) tear down the connection later on (runtime)

This corresponds to "signals travel along an instance of a connector, originating in a required port and delivered to a provided port. "

I believe that the second paragraph of the quote falls in nicely after this explanation.

In C# the mechanism is delegates.  In Java the mechanism is the DEM --Delegation Event Model.  In C++ is a DEM-like mechanism or using a signals libraries--boost.signals, or libsig++

Now, regarding your comment as whether it should be in a structural diagram, even though it looks like a behavioral element, I believe it should be.  To me, the icon can be used both at a component and at a class level, and it tells me that:
a) The interface must be implemented
b) There's a connection/disconnection mechanism--at runtime.

This connector is richer than the notation existing in previous versions of UML, where there's a bidirectional association and one of the sides states the role and the interface that it implements.

Multiple connectors directed from a single required interface or port to provided interfaces on different components indicates that the instance that will handle the signal will be determined at execution time

This next paragraph of your original quote simply means that if I have M components that provide interface I, and a component C that implements I as a required interface, at runtime, a user should be able able to create n instances of C, where instance C_n will be connected to component M_n

Regards,

Javier Estrada

6

Suggestions and Requests / Re: Default destructor visibility

« on: April 01, 2004, 12:44:26 pm »

It's still present in EA 4.00 build 722 and apparently it was not fixed in 723--from the release notes.

Have you reported it as a bug?

7

Suggestions and Requests / Re: Feature Overload

« on: August 21, 2003, 03:08:39 pm »

I've been evaluating EA for some time now, on and off, as I have time, and I find some of tkadom arguments compelling.

The core functionality for the product is great, but I think that EA is trying to be all things to everybody.  Some of the shortcomings that I've seen are in "transitional" features--e.g., you cannot get help in a dialog box by selecting the [?] button anymore, but you can get help by selecting Help.

While I appreciate the additional features--and the price point--, I think that they make the product intimidating if you do not have a few miles with the UML specification and a software development process, and I think it would be acceptable--at least I would pay if it is in a range such as EA--to have other product out of the "ancillary" functionality (something in the terms of requirements management and project management, for example).

On the other hand, I understand that the bandwidth for Sparx Systems may be limited to polish the ancillary features that JourneyManDave mentions.

Regards,

Javier

8

Suggestions and Requests / Re: Responsibilities on Associations

« on: August 13, 2003, 10:19:35 am »

Sean,

I think I have to clarify my position.

What we have in our company is a software development process that creates the following (most important) artifacts:

- System Specification and Design.

The artifact is a document where we specify the use cases for the system.  Requirements that are not part of the use cases are specified in the document.  At the moment, we DO NOT track requirements--although we have the tool, RequisitePro, we just use it to store the use case documents and associate it with a Rose model's use cases.  Only one requirement is created in RequisitePro: the one created by Rose to associate a use case document with RequisitePro.  The use case document is beefed up.  We've polished it very well over the years and the participants know how to obtain information from there.

- Software Architecture Document

Out of the specification, we may come out with several of these.  Again, these include use case realizations from the specification.  The name is a little bit of a misnomer, because it reflects either the software architecture for the system or the detailed design of a specific component in the system.

When used as a software architecture, this component identifies the software architecture for the system, the main components and their interaction.

When used as detailed design of a component, this artifact includes the specific component to be delivered, the UML model and the specific technology and programming language to use.  We're very thorough with the technology and programming language aspects--a component has to be implemented somehow ;-).

Like several shops out there, our resources are limited.  We have a team of 4 people that may produce system design and specs, 3 that produce software architectures and a team of 10 developers.  I'm in all three groups, and some of the other people is in two groups.

Some of the problems (and relevant to this discussion) that we face as a team are:
- Time to market.  Missing a business opportunity because of a delayed product is BIG for the company, perhaps more significant than other companies (though competition).

- UML knowledge.  All of our teams know the necessary UML to fulfill their task.  It's been until this year that we're discussing raising the bar for our developers, because us modelers can express more in our designs with the experience and feedback that we've obtained in the last 5 years.

So, when you say to track something in the model, my position is that you have to strike a balance.  I agree that in an ideal world everything should be in the model, but is it really cost effective?  Updating the model takes time (I came back a few days ago from a design review and I haven't been able to catch up on the changes that have to be done), and, although MDA will address this very problem, it'll take years for the industry to buy into that approach--same as it was for UML.

You may be asking yourself, how do you then address the problem? orally:  let the developer talk to the modeler.  You'd be surprised that this approach works most of the time.  We modelers decide to eliminate some detail from the model, knowing that the developer will have some questions, but we address it with an office chat.  Ultimately, what we try to do is to get the best bang for the buck when it comes to time.

Of course, this is my soapbox ;-), but I'll step down now.

We're (still) a Rational tools shop and we integrate Rose and RequisitePro, using SoDA to generate the documents.  I'm evaluating EA because I see it as a superior UML tool, but it must be able to generate artifacts similar to what we have today with the same automatic features.

Regards,

Javier

9

Suggestions and Requests / Re: Responsibilities on Associations

« on: August 12, 2003, 01:18:48 pm »

SeanKearon, jbeebe,

I see the value to attach responsibilities to the class, but not to the associations.  In my opinion, the association ***already represents a responsibility for the class***, and defining the association correctly will define the responsibility correctly.  My question is, what would you define in the association that is not already there? multiplicity? role? constraints? ordered?  On the other hand, I think that the association can be tracked to a requirement--a Customer shall have a maximum of 5 accounts.  In this case, I agree that it is valuable to have this information, but doesn't the current association properties dialog box cover most of this already?  It seems to me that it is overkill to "track" the requirement by having to maintain the dialog box than by inspecting the class diagram.

On the other hand, in my experience, sequence diagrams are used to support use case realizations---they're merely a way to see a "collaboration" in action.  Granted, you can use them to track requirements, and a particular requirement can be realized by a collaboration represented in a sequence diagram, but again, I think it is overkill to maintain this information in the model.  What I usually do is that I associate a sequence diagram with a use case realization by creating it underneath it.  That way I maintain the relationship and know what it's realizing.  I also try to give the happy sequence diagram and a couple of failure scenarios to exemplify the most common paths.

My standpoint does not come from a "naysayer" perspective.  It's that I've always had to strike a balance between how much information I want in the model and how much time I have for a particular project.  In addition, let's not forget that whenever something changes, the model needs to be maintained, too.  Too soon it becomes prohibitive to have to maintain all this information in a medium to large project.

Regards,

Javier

10

Suggestions and Requests / Re: Responsibilities on Associations

« on: August 08, 2003, 03:31:59 pm »

SeanKaron,

What is your need?  I do not see the value of methods for an association, and what additional attributes would you be looking for?

UML (and EA) allows you to qualify the association today (multiplicity, roles, name, etc.), but obviously you have a need in your specific project.  Could you provide additional detail?

Regards,

Javier

11

Suggestions and Requests / Re: Moving Associations

« on: July 30, 2003, 10:04:55 am »

Sean,

I'll be the devil's advocate.  I'm not in favor.  The reason is that from the implementer's point of view, it would be ambigious what you want to do with the association:

1. Place it in a different position in the same class to make way for another association?  This is the current behavior, or...

2. Associate it with another class.

Hmm.  

In order to disambiguate, perhaps adding a CTRL+something to let EA know that we want to move to another class.  Let's assume EA supports this feature.  We move it then to the other class.

Now, it's in the other class.  What are the attributes of the association in terms of: role, visibility, multiplicity, navigability...

Then, it seems to me it is simpler at this point to just get rid of the association and create another one :-)

Given the fact that it'll probably take you a minute or two to delete-then-recreate, and that it's not a common task, I vote no.

Regards,

Javier

12

General Board / Re: UML recognised certification

« on: November 11, 2005, 10:49:19 am »

I passed the OCUP Fundamental last year, when they were Beta-testing the tests.  What I can tell you is that it is challenging and you should have some experience on your shoulders.

I would recommend the following material :
1. Download the UML 2.0 Superstructure PDF from OMG
2. Get The Unified Modeling Language User Guide book or another tutorial (for UML 2.0)
3. Get  The Unified Modeling Reference Manual (for UML2.0)

The last two books are optional--you can get similar books--and I did without them in during my preparation.

Kind regards,

Javier

13

General Board / Software Architect Positions

« on: November 11, 2005, 11:18:35 am »

The company I work for, Plant Equipment (http://www.peinc.com) has software architecture positions open.  I would like to encourage competent software architects to apply for a position.  We are located in sunny Southern California in Riverside County, in Temecula (60 miles north of San Diego on I-15).

Plant Equipment has been in business for 38 years and is in a big growing spurt.  We have a software development process in place, where we go from software requirements to formal software architecture and design using UML.

Our work environment is casual, and we put a lot of emphasis on quality due to the nature of the business--public safety, 9-1-1 emergency.

Our modeling tools are Rational Rose and RequisitePro :-( and our models are realized in C++, VB6 and .NET/C# (thus the requirement to be familiar with .NET below).  In addition, we're heavy on telephony and distributed environments, which is a plus.

So if you have experience in the fields listed below, chime in and send your resume to hour HR department ;-)

Regards,

Javier Estrada
Senior Software Architect
Plant Equipment, Inc.

* * *

Plant Equipment, Inc. (PEI) is proud to be the dominant provider of innovative
9-1-1 telecommunication and information solutions that help save lives in communities all across America. Our expert teams develop, manufacture, integrate and support call center and call related products for environments that demand rapid and accurate performance. PEI is continually looking for talented professionals who thrive on challenges in a team environment.

As a Software Architect for PEI, you will be responsible for leading part or all software architecture efforts associated with product development. This includes envisioning and documenting the software architecture that will be used as the basis for the detailed design of one or more software components or applications. Uses the information in a system specification to formulate a software architecture that will address the system level requirements. Forms the foundation for all subsequent detailed software design and implementation tasks. Assignments are of a complex nature and require advanced technical knowledge, including the use of new technologies, techniques, methodologies and design patterns.

Mandatory Qualifications:

* BS degree in Computer Science or equivalent combination of education and experience.

* Extensive experience applying OOAD practices and strategies.

* Extensive experience with a modern, object-oriented programming language such as C++, C#, Visual Basic or Java.

* Broad understanding of the current Microsoft server and workstation operating systems.

* In-depth understanding of the current Microsoft development tools such as Visual Studio and Visual Studio.NET.

* In-depth understanding of the development technologies such as ATL, STL, MFC, COM/COM+, the .NET framework.

* Experience architecting distributed solutions based on the TCP and IP protocols.

Must be a subject matter expert in one or more of the following areas:

* Computer Telephony experience. Architecting solutions that use CTI (TAPI, JTAPI, etc.); interface with and/or programmatically control a telephone switch, preferably a Nortel Meridian 1, Nortel Business Communication Manager, and/or Avaya G3; use VoIP in a LAN and/or WAN network environment.

* .NET experience. Architecting solutions that use .NET technologies such as the .NET Framework, ASP.NET, and .NET Remoting; use web services, SOAP, XML and UDDI; browser-based software solutions using IIS.

* Database experience. Architecting high performance database solutions with the current release of Microsoft SQL Server; developing entity/relationship diagrams; database access mechanisms included in the current release of MDAC.

A Software Architect must be able to work required hours for the position and may be required to travel on occasion. UML certification such as OMG-Certified UML Professional and/or MSCS professional certification in software architecting and/or MCAD for Microsoft .NET credential a plus.

Qualified candidates are asked to apply directly to our web site at www.peinc.com. No relocation assistance is available for this position. Must be a U.S. resident. Candidates who do not provide salary requirements will not be considered.

PEI is a great place to work. We offer employees a robust portfolio of benefits and we’re market competitive in our wage and salary practices. PEI is ISO-9000 certified and is an Equal Opportunity and Affirmative Action Employer.

14

General Board / Re: I'm Definitely Not God

« on: November 02, 2004, 11:19:10 pm »

Remember that any of these titles (guru, geek ,etc.) cut both ways...either can be interpreted as the most knowledgeable or the least ignorant  

15

General Board / Re: Multiple instances of a class in a diagram

« on: November 10, 2004, 09:06:02 am »

KP,

In my opinion, it just makes sense to have multiple instances of the same class in a diagram.  The reason is to avoid clutterness.  Consider the Kernel::Root diagram in the UML2 specification--it seems you have it

Often times--at least in my designs--, a class has multiple associations and drawing a comprehensible diagram becomes an exercise in frustration once the association lines start crossing.

Without comparing to EA, I find the feature very useful in Rose and I believe several users would benefit from such an enhancement.

Regards,

Javier