Wintermute
easy tiger
This might - with any luck - sink off the boards without so much as a second read, but if any of you do know about all this stuff, I could do with a bit of help.
Anyway. I've got to rebuild a ticketing and membership system, from pretty well the ground up. And it's not small, in terms of users, business complexity or money. In short, it's a fucking big project.
Now... websites, I can do. Tell me you want your stock online bookable, or you want to put your photos of mice online, I'm your dude. However, this project is going to require <deep breath> actually planning and scoping out in advance. It's just too big for me to bang together a schema and tweak it into place as I develop the site around it. Plus which, my boss wants some funky diagrams to impress the client with.
So... ignoring for the moment the fact that the first thing I did was bang together a schema, the first thing I did was download a set of Visio UML 2.0 shapes and draw a lot of pretty flowcharts. So I've sort of specced out the business rules for tickets (as in, every ticket that can be bought and the combinations thereof, and the rules that apply to them), and the functionality that the system needs to offer to customers and to admin users.
Roughly.
Obviously, Google is my friend. I've been reading exhaustively and boy, is it fun. Just tell me about those low-fidelity prototypes one more time. But most of what I've seen is articles - pretty in-depth stuff about best practices and blistering attacks on the 5NF. Or something.
What I want is... well, to know what all these interesting Visio symbols actually mean, for one. What's the difference between a straight and a routable relationship? I know what classes and objects are - or I think I do - but what's a socket? Or a transition?
I want... to see some basic Use Case diagrams with their symbols explained. I want "this is how your generic customer-adding-ticket-to-basket would look in UML - these are your inputs, this is your process, these are your outputs."
I want... an explanation of code specification techniques for people who usually just write the code.
Err.. as you were, then

Anyway. I've got to rebuild a ticketing and membership system, from pretty well the ground up. And it's not small, in terms of users, business complexity or money. In short, it's a fucking big project.
Now... websites, I can do. Tell me you want your stock online bookable, or you want to put your photos of mice online, I'm your dude. However, this project is going to require <deep breath> actually planning and scoping out in advance. It's just too big for me to bang together a schema and tweak it into place as I develop the site around it. Plus which, my boss wants some funky diagrams to impress the client with.
So... ignoring for the moment the fact that the first thing I did was bang together a schema, the first thing I did was download a set of Visio UML 2.0 shapes and draw a lot of pretty flowcharts. So I've sort of specced out the business rules for tickets (as in, every ticket that can be bought and the combinations thereof, and the rules that apply to them), and the functionality that the system needs to offer to customers and to admin users.
Roughly.
Obviously, Google is my friend. I've been reading exhaustively and boy, is it fun. Just tell me about those low-fidelity prototypes one more time. But most of what I've seen is articles - pretty in-depth stuff about best practices and blistering attacks on the 5NF. Or something.
What I want is... well, to know what all these interesting Visio symbols actually mean, for one. What's the difference between a straight and a routable relationship? I know what classes and objects are - or I think I do - but what's a socket? Or a transition?
I want... to see some basic Use Case diagrams with their symbols explained. I want "this is how your generic customer-adding-ticket-to-basket would look in UML - these are your inputs, this is your process, these are your outputs."
I want... an explanation of code specification techniques for people who usually just write the code.
Err.. as you were, then

) but I suspect one of the words you're looking for in combination with "UML" is "glossary", which turfs up a 