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 ... 3 4 [5] 6
61
General Board / Re: Constraints sections in RTF
« on: August 28, 2002, 09:34:17 pm »
We are using MS Word macros to clean up the rtf generated by EA.  A sort of "post processing" step.  Not very elegant but does give total control over the output.

Phil.

62
General Board / Re: Scenario Tab of Use Cases
« on: August 14, 2002, 11:48:27 pm »
We are using the scenario tab in the same way as you describe and plan to record a Word macro to clean up the rtf documentation.

The macro will do things like remove the {Basic Path} tag by doing a global replace of "{Basic Path}" to a null string.  It will include other "clean up" tasks as well.

Our guess is that this will be easier than trying to get into the automation interface even though it is not a very elegant solution.

63
Uml Process / Announce Open UP and EPF Composer
« on: August 17, 2007, 06:57:14 pm »
A quick search suggests that no one else seems to have mentioned this so here goes.

Eclipse have released and "open source" version of the Unified Process "Open UP".

The process can be customised using the companion EPF Composer tool which is based on the Eclipse framework.

I am not associated with eclipse but thought the tools would be of interest to the EA community.

64
Uml Process / Re: Business process model example
« on: April 18, 2003, 08:13:24 pm »
JEff,

Points on points, on points...

1. Take your point but if one wants to be pedantic a branch (xor) without guard consditions is meaningless cos you can't take all branches of an exclusive or.

Universal question - how do we communicate precisely with business users?  I don't have the answer but here are some things I've found.

a) Don't explain too much.  Just start using fork/join.  If you use it consistently people get the idea.  If someone asks "what's that?".  Don't offer too much explanation.  Don't call it a "uml-fork-join-concurrent-widget-a-bob".  Just say it means that all of the activities to the left must be complete before this one can start.

b) Cut slack to the bsuiness people while you work with them but build rigour into the models behiond the scenes.

c) Accept that very often rigour is simply not necessary.  This is particularly true if we are modelling business processes as a precursor to defining software requirements.

d) Try to build an understanding of the importance of standards by analogy.  Is it really important to follow Accounting Standards?  Is it really important to adopt best practice HR standards?  Do we really need to have ISO9000?  (Be careful onm the last one they might say no :o)

Finally "dumb down" the UML by all means but either stick to the vanilla standard or develop a UML Profile that allows you to do what you want.

4) What I was saying in a round-about way was decomposition for buisness activities is quite OK and I would say essential.  Decomposition is only bad as a software design approach.

Hope this helps,
PhilR

65
Uml Process / Re: Business process model example
« on: April 16, 2003, 07:07:46 pm »
Hi Jeff,

I have a few constructive comments that may help.

First thing - great idea to use diagram to illustrate your points.  UML is all about "visual" modelling.  Right?

Also, remember that the diagrams you are using are Activity Diagrams with a "stereotype" symbol for an activity to highlight the fact that we are modelling business activities rather than the activity flow of a class operation etc.

This means that the diagram should obey the rules of activity diagrams.  One of the clearest descriptions of Activity Diagrams I have ever come across is at (shock horror)

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dniuml/html/rep
resentationofactivities.asp

Another (less surprisingly) is at

http://www.therationaledge.com/content/jan_02/t_activityDiagrams_me.html

As for your points:

1) The branch symbol (diamond) should be associated with "Guard Conditions" on the dependencies flowing out of the branch.  A branch can be regarded as an "xor" and is optional.  Be certain that you are not trying to show concurrency, which uses the "Fork/Join" notation.

The dashed line on an Activity Diagram indicates object flow.  If you want to show an Actor "executing" an Activity it might be better to use swimlanes.  Alternatively you can stereotype a Dependency (or Association?) as <<executes>> and use this to associate Actors and Activities.

2) No problems that I am aware of.

3) The UML has a stereotype icon for an Activity that can be "decomposed".  EA does not support it.  See UML 1.4.

4) Don't get me started on activity decomposition   ::) Functional decomposition of *software* is bad, bad, bad and one of the major drivers behind the switch to OO techniques.  Why is it bad?  Because software designs based on *functional* decomposition are hard to reuse and change.

This fact has led some people to think that all types of decomposition are bad.  Try convincing systems engineers that this is true!  The UML allow the decomposition of Activities but sort of hides it due to an awkward embarrassment about decomposition in general.

Hope this helps Jeff and I welcome any corrections from others if I got it wrong.

PhilR

66
Uml Process / Re: Proposed Product Oriented Nature of This Forum
« on: December 20, 2002, 02:00:35 am »
How about if we use the diagrams listed in EA's outlook bar as a starting point?

That would give something like the following structure.

Process (Analysis)
Use Case
Activity
State
Sequence
Class (Logical)
Deployment (Physical)
Requirements (Other)

(I don't actually have a copy of EA with me at the moment so I am working from screen shots)

Each of these can be further decomposed by the diagram elements and finally by each of the tabs on the element detail screens.

For example Use Case Diagrams would have.

Use Case (Requirements, Constraints, Scenarios etc)
Actor

If we then follow Jason's suggestion we can describe the work product for each phase of a project.  Inception, Elaboration etc etc.

Phil.

67
Uml Process / Proposed Product Oriented Nature of This Forum
« on: December 18, 2002, 01:55:30 am »
Hi everyone,

Here is a proposal for organising this forum.  I suggest that we start a thread for each of the work products that can be produced with EA.

For example,

Process diagram
Class diagram
Use case diagram and use case narrative
Collaboration diagram
etc

Under each thread people post advice on the process followed to create the diagram, reason for the diagram, quaity measures etc etc.

The 'Use Case Cookbook' thread is shaping up as a useful use case thread.

Also think that we will be needing a process FAQ at some point as the wisdom accumulates?

What do people think?
Phil.

68
Uml Process / Re: Hierarchical Decomposition of Use Cases
« on: March 30, 2003, 07:57:56 pm »
Quote
By the way, are you known with the J-Std-016 / Mil-Std-498 standard?

No I am not but I will check it out.  Sounds interesting.

Nick, you make the point very well.  I must be able to write some (sensible) text for my use case.  In fact Alistair Cockburn jokes that his entire book on use cases describes what to put between the two braces of a use case UML tag.  In other words the use case description.

I tend to regard use case diagrams as not much more than a bullet list of use cases such as:

  • Add new product
  • Add new customer
  • Add new inventory location

etc...

Appart from the actors invloved a use case diagram does not convey much more information.

PhilR

69
Uml Process / Re: Hierarchical Decomposition of Use Cases
« on: March 27, 2003, 06:08:44 pm »
Hi Tjerk,

Yes you are correct that the top-level grouping of use cases should be done with packages.  You can even stereotype the package and import a .wmf graphic for it if you want to make it different to plain old boring packages.

I am of the growing opinion that use cases need to be suplemented with written requirements in some areas for exactly the reasons you mention.  In fact, there is a need to associate some or all of the following with use cases depending on the type of project and approach followed:

functional and non-functional requirements
business rules
data elements included in the interface
project issues and requirements
attributes of persistent classes that are updated by the use case

Use cases are great but the whole technique was originally spawned from about three pages of a book by Ivar Jacobsen.  All sorts of 'ideas' have been sucked in to fill the vacum.

To sum up I think we need to stay agile but abide by the rules which strengthen communication.  I don't care how you arrive at your use cases but I do care that we both understand exactly what they mean.

PhilR

70
Uml Process / Re: Hierarchical Decomposition of Use Cases
« on: March 26, 2003, 06:57:49 pm »
Hi Guys,

Interesting debate this.  Here's my perspective.

When I was an electrical engineer  8) (many, many eons ago) I used a standard notation for circuit diagrams.  There were (still are) standard symbols for resistors, capacitors etc etc.  The semantic meaning of the symbol was defined by the physical behaviour of the component being represented.

If I had suggested to my fellow engineers that I wanted to use different symbols or change the meaning of an exisiting symbol they would have looked at me as if I were mad  ??? and probabaly would have thrown me out of the profession (I left of my own accord as it happens :o ).

My point?  The UML is a standard notation.  The meaning of a use case is defined in the UML.  If people assign a different meaning to a use case they muddy the water and confuse people.  If you don't like use cases then use functional decomposition but please don't call the end result use cases.

One of the problems with our industry is the 'fashion police'.  Functional decomposition is 'out' use cases are 'in'.  This means that we shouldn't refer to functional decomposition even if need to do it.  Call it a use case hierarchy instead.

The reason that functional decomposition gets such a bad review is that it is a poor paradigm for internal software design (OO is a much better paradigm).  However that should not stop people using it for organising requirements becasue requirements are totally independent of design aren't they?

Finally, if you want to classify actors, you can use generalise (inherit) relationships between them.  This is really useful for documenting the situation you describe Paul.

PhilR

71
Uml Process / Re: Hierarchical Decomposition of Use Cases
« on: March 25, 2003, 06:28:43 pm »
Simple answer - don't decompose use cases.  Use cases are NOT functions.  They are represent a sequence of interactions between an Actor and a System.  The sequence of interactions provide some value to the Actor.  Each individual action is a use case step.

This means that option d) is the only valid option.  However, there is nothing wrong with giving your packages functional sounding names such as "Customer Maintenance", "Transaction Posting" etc etc.

Packages are the correct UML mechanism for "seeing the wood from trees".  Note that you can create a diagram showing a hierarchy of packages by dragging a package on to a diagram canvas.

Hope this helps,

PhilR

72
Uml Process / Re: The best way to write use cases?
« on: January 23, 2003, 09:20:49 pm »
Mikkel

Quote
All that is needed to do what you require of the tool, is a documentation generator that is a little more flexible. I have some plans in my head about implementing something that works through the EA automation interface, but I can't promise that I'll ever have the time to finish it.


You could create a stereotype use case of "internal" or something like that.  Use this stereotype to decompose use cases to everyone's satisfaction and then expand the decomposition in the text as you suggest.

Only problem.  EA does not display use case stereotype text in the use case symbol.  However, it will display any metafile image that you define for the stereotype.

What will the symbol for an internal use case look like?

Phil

73
Uml Process / Re: The best way to write use cases?
« on: January 22, 2003, 11:39:05 pm »
Hi Mikkel,

I bet you knew this would spark a lively discussion when you made the post ;-)

I can't resist my 2 cents either.

I teach use case modelling and find that people who are just beginning to use use cases should stay clear of extend, include and generalise.  Too confusing.  Especially if you read the official UML stuff complete with extension points and so on.

Mnay developers turned analysts carry over their desire to decompose and remove the redundancy from everything they ceate.  The result is a gizillion use cases that often smell of functional decomposition.

Redundancy is a problem when you have to maintain use cases as requirements evolve.  In fact I find that for me this is the most pressing driver for breaking up a use case.

Finally, why can't the tool switch between the two views.  I create a use case model complete with extends and includes but when I decide to print it out for the users to review the top-level use case is fully expanded by physically including the text of included use case etc.

74
Uml Process / Re: Object, class in a class diagram
« on: April 18, 2003, 07:54:55 pm »
I meant users not "suers".  Interpret this slip as you will  ;D

75
Uml Process / Re: Object, class in a class diagram
« on: April 18, 2003, 07:53:51 pm »
JEff,

To be honest I never draw object diagrams in EA.  They remain forever white board dumps which I then convert to class diagrams.  I gusess if the suers wanted a "prettied up" version I would draw one but I always discourage this.

PhilR

Pages: 1 ... 3 4 [5] 6