UML class diagrams ERGHHH!

[stoke1863]

GIVEN UP! i just dont get this at all. If any one has any ideas with my scenarios or any easy to learn links PLEASE share

 

[Pho]

I'm a lead business analyst/Techncal product manager/Scrum master/office gimp

Do you know what we use?
Photos taken with my phone of the whiteboard while were discussing functionality, maybe some screen mockups, some scenarios, spreadhseet with meta data fields and use cases and possibly some acceptance criteria. Anything that gets the message across loud and clear.

Although I must say that the devs do produce a class diagram like the above mentioned, or DB schema

Sounds like you need a smartboard or something where you work . It's always interesting to see how other people design software.

I do quite like class diagrams, not too sure about the rest of UML mind .

 

[Gypo]

UML...oh no this brings back bad memories from uni.

 

[Dj_Jestar]

I'm a lead business analyst/Techncal product manager/Scrum master/office gimp

Do you know what we use?
Photos taken with my phone of the whiteboard while were discussing functionality, maybe some screen mockups, some scenarios, spreadhseet with meta data fields and use cases and possibly some acceptance criteria. Anything that gets the message across loud and clear.

Although I must say that the devs do produce a class diagram like the above mentioned, or DB schema

Ditto.. Scrum for the win, btw

 

[Pho]

GIVEN UP! i just dont get this at all. If any one has any ideas with my scenarios or any easy to learn links PLEASE share

Can you post what you have so far? Can't you use what Daz suggested above and create the diagram (or is that the part you've having problems with?)

 

[MarcLister]

I remember doing all this some years ago now, never really made all that much sense to me really.

Ditto. It "looked" easier than it was I found. Deceptively so. I'd do a UML case diagram and show it to the lecturer who said it was right. I'd go . Eh?! I couldn't understand how we were getting across quite complicated situations in silly little drawings.

 

[stoke1863]

Can you post what you have so far? Can't you use what Daz suggested above and create the diagram (or is that the part you've having problems with?)

Its missing quite a lot

 

[johnno93]

I'm pretty sure that variables are not supposed to have spaces in them and that they should have their type declared.

 

[stoke1863]

I'm pretty sure that variables are not supposed to have spaces in them and that they should have their type declared.

Yea i realsed that i just havent changed it.

And don't ask why but the lectures said they aren't fussed about having the type.

Probably becuase we are not actually coding anything

 

[johnno93]

Also in the Job title I'm sure that there shouldn't be methods for specific jobs as this is data that will be held not methods to perform. Although I am very rusty as I haven't done one of these for about 4 years and aren't even in the computing industry at the moment.

 

[iNPUt]

Yea i realsed that i just havent changed it.

And don't ask why but the lectures said they aren't fussed about having the type.

Probably becuase we are not actually coding anything

Oh no UMP, I hate these yours look better than mine ever did so I will quickly step back, good luck.

 

[megakid]

Comments:

* No spaces in any names - lookup Pascal Case (for method names) or Camel Case (for field names) rules.
* Each box should be a entity - Search For Jobs is not a noun therefore shouldn't be there - e.g. JobSearch() should be a method on another new box called AvailableJobCollection (or just JobCollection), JobManager or something similar.
* Stuff in the lower boxes are methods - stuff you can do to class - they should be named according to what they achieve. You seem to be doing a whole heap of different things with them. Job Title, whilst you could argue it might be a valid entity (though I would delete it entirely), shouldn't have methods called WebDesigner(), KFCSalesAttendent() etc.

Sorry I haven't got time to put the rest of my comments but hopefully that'll help...

 

[NickK]

UML.. Useless Muddled Lines.

The idea of drawing up a design is well worth while.. but UML is just so overkill.

Not really - the idea behind it is sound.

Use Cases Diagrams - such as those in the original poster's diagram, are useful when doing requirements analysis and discovery. They are there to uncover and rationalise requirements.

As always the english used and the names chosen are vital. Understanding the definitions is vital too.

What the OP has written for his class diagram is incorrect. He has mixed the objects types (entities/classes) with operations.

For example "Search for Jobs" is an operation, not a class. Think of classes as real things you can prod first:
Applicant - a type of person, who is looking for a job. An instance for each individual applicant.
Employee - a type of person that employed and associated with a Job Role already directly as they fill the job. An instance for each employee.
Job Role - a it's a type of job, you can instance this for different job roles for all those that are both

Next you could approach this in different ways:
Recruitment Opportunity - this could be a temporary that applicants could be linked with that then links to a Job Role that needs to be filled.

You can then have an Applicant that applies() to a Recruitment Opportunity. << can you see the use of english driving the model based on simple operations?

OO patterns could be used but this would be very visible that you've had help.. Things such as a collection instance "Recruiter" holding a set of ROs, then the collection supports a search protocol given parameters. You could then apply to the recruiter as a single point which then hides the search behind the scenes, returns a set of search results which the applicant can call apply() on, or, you could have an application class that handled the operation.. etc etc. I hope you can see the use of classes for operations, however "application" would exist only in the time to apply.. it depends on everything else but as always the rule with OO patterns is use if required but not if it just to use patterns.

In short I think you need to revise how you approach "Search For Jobs" .. is this more than one class? Is this really a "Search Results" class that holds all the jobs that match the search criteria?

There's a difference between class model for modelling the objects from the real world.. and those that are more abstract (not the OO keyword) and exist to serve to find things, to make the the object model easier to handle.

 

[Blackvault]

In class diagrams to you need to list every variable and every method being used within that class?

Blackvault

 

[Dj_Jestar]

Not really - the idea behind it is sound.

Use Cases Diagrams - such as those in the original poster's diagram, are useful when doing requirements analysis and discovery. They are there to uncover and rationalise requirements.

As always the english used and the names chosen are vital. Understanding the definitions is vital too.

What the OP has written for his class diagram is incorrect. He has mixed the objects types (entities/classes) with operations.

For example "Search for Jobs" is an operation, not a class. Think of classes as real things you can prod first:
Applicant - a type of person, who is looking for a job. An instance for each individual applicant.
Employee - a type of person that employed and associated with a Job Role already directly as they fill the job. An instance for each employee.
Job Role - a it's a type of job, you can instance this for different job roles for all those that are both

Next you could approach this in different ways:
Recruitment Opportunity - this could be a temporary that applicants could be linked with that then links to a Job Role that needs to be filled.

You can then have an Applicant that applies() to a Recruitment Opportunity. << can you see the use of english driving the model based on simple operations?

OO patterns could be used but this would be very visible that you've had help.. Things such as a collection instance "Recruiter" holding a set of ROs, then the collection supports a search protocol given parameters. You could then apply to the recruiter as a single point which then hides the search behind the scenes, returns a set of search results which the applicant can call apply() on, or, you could have an application class that handled the operation.. etc etc. I hope you can see the use of classes for operations, however "application" would exist only in the time to apply.. it depends on everything else but as always the rule with OO patterns is use if required but not if it just to use patterns.

In short I think you need to revise how you approach "Search For Jobs" .. is this more than one class? Is this really a "Search Results" class that holds all the jobs that match the search criteria?

There's a difference between class model for modelling the objects from the real world.. and those that are more abstract (not the OO keyword) and exist to serve to find things, to make the the object model easier to handle.

The idea behind it is sound, yes, but like every bloody thing in the IT sector, it gets far too much attention from analysts worried about performance and red-tape efficiency who try to ratify every process known to man in the name of "best practice" and all we end up with is a vastly over-complicated pile of manure, like UML.

I'll say again, as I did before, the idea of drawing your design/use case/etc is sound, UML is not.

UML, just like everything else, was first created to be used in small specific cases, and then exploded when it was adapted, changed, made to be generic.