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 - JEff Russell

Pages: 1 [2]
Uml Process / Re: Business process model example
« on: April 17, 2003, 07:25:37 am »
Thanks for the comments.

Here's some points on your points:

1.) I was cheating with the branch symbol: trying to show a decision to continue or quit, implying parallel courses were taken when continuing (there should be a fork/join symbol).  The problem is, this would scare most non-technical types.  
[Side bar:] My most recent experience was a company with executives/non-engineering management that documented the company's processes with PowerPoint.  The level of rigor was limited by the "autoshapes" and the page size :-(  I got snickered out more than one meeting for being too concerned with details, and I would hessitate to show a "real" UML diagram to such a crowd.  My point being...?  [end of side bar]

Does anyone "dumb" down UML diagrams for non-technical types, thereby breaking UML rules?  Or would it be best to try and teach notational concepts like fork/join and guard conditions?  

4.) I see your point on functional decomposition for software.  However, these diagrams attempt to model real-life business processes (that will not necessarily become software). I've heard of business consultants using UML to diagram business flows. Shirley, they must use functional decomposition.


Uml Process / Business process model example
« on: April 15, 2003, 10:04:06 am »
If interested, please comment on the following attempt at modeling a business process. This (mostly) academic exercise closely resembles a real-life business process...

My goal is to construct an analysis model for a computer-aided design tool for embedded systems, specifically to assist during a system-level design phase. To set the context, I modeled a design flow that would be used by an engineering organization. Of course, this process exists in a company-wide product lifecycle model.  A key aspect is that the Product Lifecycle diagram both intersects and hierarchically represents a portion of the Codesign Flow diagram.

The diagrams are shown below (if I figured out the YABB buttons).  My discussion points are:
1. Any general advice from you experienced UMLers.
2. Some of the (same) discrete processes show up in both diagrams, but the connecting flows differ. Any problems with this?  (E.g. In the Product Lifecycle diagram, "Describe Product Concept" flows through a decision before reaching "Analyze System Requirements"; while in "Codesign Flow" the two diagram elements are directly connected.
3. In the Product Lifelcyce diagram, the "Development" entity hierarchically represents the rest of the Codesign Flow diagram (elements "System-Level" design through the end).
I'm sure this breaks UML semantics... but this is a real-life process.
4. Let's say I want to define the Codesign Flow element "System-Level Design". Is is right/wrong to explode this into its own flow of processes?  For example, I want to show about 3-4 sub-processes, with iteration, that define this System-Level Design activity, maybe even with an activity diagram...   What would I start and end this diagram with? Events? And how would those events tie back into higher level diagrams?

Thanks for indulging such a long discussion-starter, and feedback on appropriateness of using pictures is welcome, too.
JEff Russell

The Product Lifecycle diagram:

(Also at:
The Codesign Flow from the engineering point of view:

(Also at:

Uml Process / Re: Use Case Arrows - what to use?
« on: October 07, 2003, 11:27:16 am »
Thanks for the comments, they really are appreciated.
For what its worth in your model: I further disagree that everything ends up in procedures.(Granted its a sample) You are following the well traveled path of functional decomposition of Use Cases in your thinking - it will not lead you to where you want to be. Your referenced Domain Model contains Class Diagrams, Sequence Diagrams, etc. These are your: Objects!!

Just to clarify a point: the "procedures" are objects in the domain model, not procedures that would be used to implement my UML modeled system. (The domain is the interactive analysis of a hardware design specified with a hardware description language whose fundamental grouping of operations is a "procedure".)

Also, discounting the specialization aspect of the use case diagram, I fully expect an actor to invoke each <<included'd>> use case either separately or from the "top" level.  Granted, it is functional decomposition, but it is decomposed from the actor's point of view.  The actor may display everything (e.g. architecture), or only lower levels of detail (e.g. functional architecture or a single procedure).
Originally, I listed each of these use cases separately with a corresponding association to the actor.  I found the diagram very busy.  Adding the hierarchy (from decomposition) helps organize these related use cases.
What do you think, now, with a little more explanation?
I like your "returns something to the actor rule".  My reasoning doesn't directly address this one.

Uml Process / Re: Use Case Arrows - what to use?
« on: October 02, 2003, 12:53:46 pm »
I have a question regarding your statement:
<<extends>> and <<include>> are the only arrows that should be between Use Cases.  

In my little corner of the universe, I decided to decompose a use case into <<included>>'d cases to focus on different aspects during phased development.   In the attached diagram, a use case displays information about an "architecture" which at some low level consists of "procedures".  (The domain model expresses this relationship.) In addition to decomposing the use cases, I made the "Display procedure" use case abstract.  Then, it is specialized as two different use cases: a text display case and a graphics-based case.  What the use case accomplishes is the "same", but from the user perspective (and the required system design), these are separate use cases, right?
Any comments?  Good/bad approach?  
(The abstract use case also helped with documentation because the requirements "pass through" to the specialized use cases.)

Uml Process / Re: Sequence Diagrams
« on: September 25, 2003, 01:01:59 pm »
You easily import source code into a Class Diagram, then you will have your classes (with their methods and attributes) in EA.  
From a class diagram, right-click to the "Import from Sources..." menu choice. Have fun.

Uml Process / Re: please help me? i am confused..mix up
« on: September 19, 2003, 08:33:53 am »
I spent several days evaluating UML tools in April.  The initial criteria were Windows based, under $1K, and support for code generation.
Embedded Architect made the competition look silly, i.e. it is a great choice.
Interesting side note, I almost didn't evaluate it because it was so inexpensive...
JEff Russell

Uml Process / Re: Object, class in a class diagram
« on: April 17, 2003, 06:56:16 am »
I think your mention of object/class faimiliarity was where I started from, being relatively new to OO stuff.  I thought starting with objects and then converting things to classes (when they were discovered) would help. After a day or so, that step wasn't so important (for me).

So, PhilR, when you are throwing around objects in a tool like EA, do you draw relationships? What type to you use? (This whole problem started with me trying to draw an inheritance link between objects---which, I agree, was silly.)  I would think a general "Association" link with a text label like "is a" or "has a" would help non-UML types more than squares and arrows.


Uml Process / Re: Object, class in a class diagram
« on: April 11, 2003, 01:16:48 pm »
Thanks for the comments. I guess I should be using classes, as I am looking to create an "ad hoc" class diagram. I am applying the ideas from Rosenberg's "Use Case Driven Object Modeling...". He suggests a high-level domain analysis before starting Use Cases, to sort out the domain vocabulary. I would think this leads to a rather abstract description of the objects in the problem domain (which might or might not resemble the "real" set of classes used in the system).  
The real confusion started because EA objected to setting an inheritance relationship between objects.  I had interpreted generalization relationships between problem domain objects to be something slightly different than the inheritance relationship between classes, since inheritance is just one way to implement generalization.  
(Do you buy that last point?)


Uml Process / Object, class in a class diagram
« on: April 11, 2003, 11:39:36 am »
Probably a simple question:
What differentiates an "object" and a "class" in EA's class diagram toolbox? Why isn't an "object" some sort of stereotype?
What kinds of relationships might be used with an "object"?


Pages: 1 [2]