Lots to read here....

Hi there - I have found another UML modeling tool. The program is called Visual Paradigm and the link is here.

The specific program is called Visual Paradigm for UML. The installation was a bit involved, requiring downloading and registering and once a key is obtained, installing the correct version - the Community Version (read 'free' - the right kind of price).

So far I have used this to redesign the use case diagrams for the Car Park practice examples and I have taken to it. It didn't hang  and crash like NetBeans and VP provides a heck of a lot more functionality than Smart Draw which is just a glorified graphics package. 

(VP also manages Entity Relationship modeling...*hint hint*) 

So, take a look at the program. I think, after the initial grunt work, you may like it. We don't know what we'll ultimately end up using but that shouldn't stop us from looking around and educating ourselves as to what IS out there.

Green St. Car Park - revised.

Per our class yesterday (with the understanding I worked the process backwards) I have reassessed my work. 

I reread the system requirements and my noun table was pretty much unchanged. ( will insert later)

I also did a Goals and Outcomes sketch - 

Goals:

Increase Security

Ease of use for Employees

Prevent unauthorized use of Car Park

Desired Outcomes/Needs:

ID cards for Employees - 

must wear

displays name, department, staffID AND EMPLOYEE PERMIT ACCESS to car park - ergo ONE CARD for BOTH PURPOSES

One Barrier One card reader at one entrance

Employee inserts ID card to reader, id checked, validated, Reader sends signal to barrier.

Barrier raised, car enters. NO RECORD KEEPING

Exit barrier - raised when car approaches. NO READER

Sign - with two states off/FULL  sign activated only when all spaces are taken, deactivated upon exit off when a single car leaves.

Access exception:

Visitor Card

displays Visitor id #, current date, car park access

obtained in advance OR collected from reception

returned to reception upon departure

Actors:

Employee

Visitor

Receptionist

HR Admin

*********************

I think that pretty much sketches out the basics of our required system. :) Now to a diagram.

DIAGRAMS, IMAGES, ETC - 

From now on I will put my graphic work  in a picture gallery my Apple Mobile Me account:  Here

Just right click and open in another window. I think you'll find it easier to see than if I paste it in here. You can also download it for yourself. 

Green St. Car Park continued:

UCD.GSC.1

OK - so I created this diagram after reflecting on our class yesterday. 

Granted, it is more complicated than what Frank suggested we do but I based this on some of the material I have been reading. It really isn't that complicated. 

Primary actors are on the left and secondary actors are on the right - this removes the need to have a separate set of use case diagrams for that half of the equation, as it were. The secondary actors are not in the system to my thinking. They are actors. (If the receptionist is out sick and no one else fills that role then the visitor will not get his pass.) 

I have added some high level use case description on the far left for each use case scenario.

As you can see I have expanded the 'visitor get card' scenario to accommodate both obtaining the card in advance (via the mail) and in person. I have also experimented where with what are called extensions - extending that use case scenario by introducing something not in the requirements, in this case the use of the mail to achieve the goal of a visitor obtaining a card in advance. It wasn't stated in the reqs but it is a logical conclusion to how the outcome can/ought to be achieved. 

Next time - extended use case descriptions and some class diagrams.