Messages

76

Uml Process / Re: Object, class in a class diagram

« on: April 16, 2003, 06:36:39 pm »

I use object diagrams when I work with users.  I have found over many years that the average person has great difficulty working with an abstract concept such as a "class".

Rather than Human, Man, Woman etc I use Fred, Bill, Mary... when I am working on a white board with users.  I then convert these into Classes "behind the scenes".

Naturally we normally work with much more difficult concepts than the above.  And that is where this approach has real benefits.

I also use object links liberally to help identify associations.  Even the people who get the idea of classes usually stumble over associations.

PhilR

77

Uml Process / Re: Unified Process and EA

« on: March 25, 2003, 06:19:00 pm »

I have been using EA to quite happily model software life-cycle processes.  Why not model your Disciplines as packages and your phases as Another set of packages.  Activities can be used to describe instances of discipline activities performed within a phase or iteration. (Hope this makes sense.  See the OMG SPEM model for a meta model of life cycle processes).

You could then use the matrix function of EA (Project|Relationship matrix...) to cross reference use cases to phases.  Not sure about reporting though?

When a new project is created EA uses a "model project" as a template.  The default one that comes with EA has a standard set of views.  Nothing to stop you defining a UP "model project" and ignoring the standard one.

Hope this helps,
PhilR

78

Uml Process / Re: USE CASE Cookbook

« on: March 19, 2003, 06:50:45 pm »

I couldn't access the on-line handbook just now but I could earlier in the week  

If you are interested try

http://process.mit.edu/eph/

seems to work now.

PhilR

79

Uml Process / Re: USE CASE Cookbook

« on: March 13, 2003, 07:02:11 pm »

Hi Everyone,

Jon - the concepts in your book UML Modelling in Colour had a profound affect on my work.  Having taught object modelling for more years than I care to mention, and been concerned (and depressed) that many people simply didin't "get it", I found a method that was "teachable" in your book.  Whats more, everyone in the class gets simsilar results so no lengthy (and boring) philosophical debates!  Thanks.

All -  in regards to the use case cookbook, I re-discovered this paper recently "Tools for inventing organizations: Toward a handbook of organizational processes" read it at
http://ccs.mit.edu/papers/CCSWP198/index.html

The paper describes a similar concept but for processes.  (It is also similar to the "Domain Neutral Component Catalogue" (or whatever it was called) that came on the CD with the UML in Colour book.

I couldn't access the on-line handbook just now but I could earlier in the week    When it comes back on line spend some time browsing through it.  I can easily imagine a similar thing for use cases.

Hope this proves useful.

Phil

80

Uml Process / Re: USE CASE Cookbook

« on: February 10, 2003, 07:49:09 pm »

I'm thinking of starting something similar for data structures, since most of my work is in database design.

Andrew,

Take a look at Data Model Patterns: Conventions of Thought
by David C. Hay.
http://www.amazon.com/exec/obidos/tg/detail/-/0932633293/qid=1044935170/sr=8-1/r
ef=sr_8_1/104-2446082-3500760?v=glance&s=books&n=507846


PhilR

81

Uml Process / Re: USE CASE Cookbook

« on: December 18, 2002, 01:46:25 am »

For a good read on use cases try
http://www.amazon.com/exec/obidos/tg/detail/-/0201702258/qid=1040204651/sr=2-1/102-4315568-0380965?v=glance&s=books

and

http://www.amazon.com/exec/obidos/tg/detail/-/0201721848/qid=1040204721/sr=1-3/ref=sr_1_3/102-4315568-0380965?v=glance&s=books

Phil

82

Uml Process / Re: Use Case Alternatives

« on: March 04, 2003, 12:00:44 am »

I try to group my use case into three categories:

1. Business process use cases
2. CRUD use cases
3. System admin use cases

"Business Process" use cases define the requirements of a tool (i.e. software system) to support a particular business process.  Potential users should immediately understand these use cases and more importantly, recognise the value that they provide.

These use cases should consume the bulk of the use case modelling effort.

"CRUD" use cases ensure that the life cycle of system objects can be fully managed.  For example in a video rental store, the business process use cases might be "Acquire video" and "Rent video".  There is also a need for "Dispose of video" so that damaged, obsolete or stolen videos can be removed from the system.  This use case will also be required to correct data entry errors.  However, it is natural that the potential users of the system will see little value in this use case.  In some situations they will not even poperly understand the purpose of a CRUD use case.

In some situations, scenarios can be used to reduce the total number of CRUD use cases as the example below illustrates:

1. The system displays the following options 'Add', 'Change' or 'Delete' a ...

Scenario 1:  The user selects 'Add' option at step 1
...

Scenario 2:  The user selects 'Change' option at step 1
...

Scenario 3:  The user selects 'Delete' option at step 1
...

"System admin" use cases are use cases that provide pure system administration functions.  For example, if a secure logon is required then some mechanism to add/change/delete user details will be required.  Users will most likely be even less interested in these use cases and may really struggle to see much value in them.

The dilema is how to keep the users interest and involved without boring them with lots of use cases that they regard as rather uninteresting?

A simple strategy is to group the use cases into the three categories described above.  Each category can be sent to different group of reviewers.

A more radical strategy is to abandon use cases all together for the "CRUD" and "System Admin" categories.  Replace them with simple statements of functional requirements.  For example:

The system shall allow the deletion of video details.
The system shall allow user details to be added, changed and deleted.

Also don't forget the use of patterns.  If there are a lot of very similar CRUD style use cases why not describe the basic CRUD interaction and then list the objects that the pattern applies to.

Phil

83

Uml Process / Re: Use Case Alternatives

« on: February 13, 2003, 07:15:16 pm »

Hi Chris,

Back-end code should not really be a consideration when writing a use case  

Use cases describe the interaction between an actor (human or non-human) and the system under study i.e. your harvest management system.

For a human actor interactions go something like this:

1. The user does something
2. The system responds by doing something of value for the user

For example:

1. The user enters a harvest code
2. The system display the harvest details
3. The user ... etc etc

For a non-human actor (i.e. another system) interactions go something like this:

1. The client system (actor) makes a request
2. The server system responds by doing something of value to the user of the client system

Note step 2 carefully.  Opening sockets, accessing DNS servers, http requests etc etc provide absoutely no value to me when I surf the web to read the news

For example:

1. The web browser requests a web page
2.  The web server returns the web page (so that Phil can read the news...)

Hope this helps,
PhilR

84

Uml Process / Re: A first contribution on the PUP/EUP

« on: December 17, 2002, 03:53:45 am »

Mebbe the XP M.O. of banging out source code using a text editor is one reason there is so much bad code out there!  Kinda like building a circuit without first developing a schematic...

I agree but there is a lot of foolish modelling as well.

Some things I have observed.

I once saw the same diagram consisting of three boxes being photocopied over and over again.  The boxes were then given different labels.

'What are you up to?' I enquired.  'Oh! The methodology says we have to do a Structured-Twiggle-Module-View for each Fooble and Feeble.  Since they are all identical this seemed the best way to do it'.

Another popular approach.

Spend half a year dumping 'stuff' into a CASE tool.  Look at the project schedule and panic.  Start coding and never look at the CASE tool stuff again.

And finally.

Spend a week debating whether the milk() operation belongs on the Cow class or the MilkingMachine class.  Best if you let the debate get so heated that people then have trouble working together constructively.

Phil.

85

Uml Process / Re: A first contribution on the PUP/EUP

« on: December 17, 2002, 03:43:26 am »

Your points have also been well taken. This is just a friendly (if a bit provocative) discussion!

Actualy I realise that that is one of the attractions of XP.  It is provocative and forces one to justify doing more analysis, modelling etc.

Remember the old Structured Analysis days when a 'small miracle' was required to get from DFDs to Structure Charts and thus to COBOL?  So many blindly following and achieving so little.

XP brashly says 'prove you need it'

Phil.

86

Uml Process / Re: A first contribution on the PUP/EUP

« on: December 13, 2002, 12:52:10 am »

Jaime,

I am replying here as this thread will eventually get moved to the new forum.

Don't get me wrong.  I am deeply suspicious of some aspects of the XP philosophy.  However, they also make some good points at the same time.  My suggestion was more along the lines of taking a minimalist starting position (point taken about non procedural tools) and then justifying adding more products.

Phil.

87

Uml Process / Re: A first contribution on the PUP/EUP

« on: December 11, 2002, 02:22:24 am »

Wow!  There certainly seems to be a lot of enthusim here.  Not being at home is a bit of a handicap and I deliberately did not bring my laptop cos its a holiday  That means I don't have access to a whole load of useful stuff.  Of course my family thinks thats a good idea  

It seems to me there are several themes in this thread.  Firstly names.  It seems to me that names are not really that important if you are not interested in branding a product.  I like Geoff's 'UML Process'.  No confusion about what it is aye?

Then we have the issue of what we are trying to achive here.  I agree that the world already has more than enough processes.  If you want a comprehensive 'open' process take a look at The OPEN Process at http://www.donald-firesmith.com/

My feeling is that we want to create something specifically to support the use of EA.  This thread has been started in response to a number of posts asking for advice in that area.

One of the problems with RUP and other processes is simply that they that they are processes.  What I find more useful is to start with 'products' rather than 'activities'.

Here's a proposal based on some eXtreme Programming (XP) ideas:

The minimum level of design product required to create a working software application is plain old source code created using a text editor. (By the way this is the way the majority of developers work!)

We have one of the best visual UML modelling tools around in the shape of EA.  Now lets justify the creation of some additional UML work products using EA and THEN describe the process for creating them.

Why do I need a class diagram?  How detailed does it need to be?  Does the level of detail vary according to the type of project/application?  How does the detail evolve/change during each phase of the project? When is it a waste of time to develop a class diagram?  Do I need to keep the class diagram up to date once the application is in use?

It is my belief that these are the real issues of UML Modelling not the 'follow the yellow brick road' process approach.

I like being provocative on holiday  

Phil

88

Uml Process / Re: A first contribution on the PUP/EUP

« on: December 09, 2002, 02:14:49 am »

Hi Jaime,

I am sitting in my brother's study looking out of the window at the pale northern sun, logged on to his expensive internet connection so this will be brief...

I agree with al your comments but would like to float a few suggestions.

1) We only address the <<product oriented process>> leaving people free to use whatever <<project management process>> they choose.

The PMBOK (or Prince2) culd be used as the basis of deciding what is product oriented and what is project oriented.

2) We adopt the SPEM (and RUP) concept of discipline workflows being different to project phases.  Project phases are what PMBOK describes.  Disciplines workflows are the logical workflows to create a work product.

Activities from a discipline workflow can be allocated to project phases in an unlimited number of ways.

3) We develop a product breakdown structure before we think about a work breakdown structure.

This will allow us to concentrate on what is required rather than what we do.

I see this could work by everyone submitting a rationale for a required workproduct to this forum.

4) We make the process agile by including explicit tailoring guidelines.  Initially this would be a rationale for requiring/not requiring the work product.

Ideas?
Phil.

PS Sorry about the over use of the word <<Rationale>> must be subliminal.