Software (not graphics) modeling

I'm looking for something I can use to model my classes and help me more easily visualize the flow of messages throughout the system, but despite being a programmer for a long time, I've never really used such software before and I am at a loss for where to begin looking. I'm not even sure what I should be looking for. Is UML modeling software the way to go, or are there better ways of doing things that fit into Unity well?

 

UML is only good... well, it isn't even good... but it's only intended for modeling individual classes and interfaces -- methods and properties, that sort of thing -- not relationships, which it sounds like you're looking for. The only diagramming I've seen of systemic flows are "actor models" and other analyst- or rules-oriented systems. They are less technically-oriented than requirements-oriented.

Hopefully somebody else will chime in with something, I've often wished for something along the same lines.

 

Uh, that's not true. UML has a lot to do with relationships.

As for the original question - I don't think you really need to bother with UML. UML is a standard, and diagrams are designed in a certain way that requires education to write and understand. It's used for big projects with a lot of coders. If you're just wanting to map what you have in your mind on to paper, I suggest you do just that. Start organizing your thoughts in a way that makes sense to you. You can take inspiration from UML but I'm not sure adhering to its principles and rules is necessarily that helpful.

But yeah, UML does have some nice tools, so if you wanna go down that road you should definitely check out
http://argouml.tigris.org/

 

IMO event sequence diagrams are the good for this type of thing. And this tool IMO is the absolute best for creating sequence diagrams: http://www.websequencediagrams.com/

Cut and paste this into http://www.websequencediagrams.com/ and see what I mean:

Title Example sequence diagram
participant class1 as c1
participant class2 as c2
participant class3 as c3
c1->c2: setPlayerScore(int score)
c2->c3: setScoreText(string text)
note over c3: writes score to text widget
c3->c2: return
c2->c1: return
c1->c2: setPlayerName(string name)
c2->c3: setNameText(string text)
c3->c2: return
c2->c1: return
​

and you can easily keep all your diagrams as similar blocks of text and version manage them like all other project source (and track changes since they're just text).

 

You want to diagram before you code, or just see a diagram?

Diagramming before you code doesn't make much sense because you're basically just typing all the stuff into a UML editor that you would normally just type into a code window. Stubbing out your code in C# isn't hard. After you stub it out, you can (in visual studio) "right-click->view class diagram" and it will show you the diagram for what you typed.

If you do it the other way and want to diagram first, then in visual studio add a new item of type "class diagram". You can build your diagram and it will create the class files with stubbed out code for you.

 

Actually I want to design before I code. Diagrams are just a tool.

 

While I've bought myself a book on UML and am starting to read up on it, the sequence diagrams are exactly what I need to start with. Thanks!

 

Designing is super handy. It's not about typing, it's about thinking through a problem. Sure you can stub code in, but then you're still only looking at a class or a function at a time. The idea of diagramming as a tool is to help think at a higher level by seeing the whole system at once.

I'm of two minds on this. I absolutely agree that there's no particular need to stick to UMLs rules just to get your thoughts in order. On the other hand, as soon as you start sharing your design with other people then you need to all be able to understand the diagrams being made and shown, which means you need a common set of rules... and UML is exactly that.

You could make your own set of rules, but then everyone is just learning a non-standard thing and re-inventing the wheel.

 

I didn't say anything about designing, I said diagramming (with respect to UML) is pointless because you might as well just type the code rather than write out classes. UML is something they teach in like 100 level programming courses to people who don't know how to code yet.

Designing ahead of time is critical. Whether you do it on paper, in your head, or on a napkin at your local sandwich shop. Designing is "What is the overall goal, what components do I need, what design patterns will I use, and how will I compartmentalize the development, designing isn't "What properties and methods do all of my classes need". That's coding.

Trying to write your classes in UML ahead of time is a waste of time in my opinion, but if you're going to do it, at least do it in a tool like visual studio class designer, which would create the framework of your code as you design and stay up to date as your design matures.

 

My thoughts when I first saw this thread the other day were mostly along these lines too. Only I believe this would be a great opportunity for a visual solution built inside of Unity. You could even take it one step further by supporting both visual node-based scripting in addition to straight C#.

 

I know. My point is that design is important (we agree there) and that diagrams are a great tool for that.

I used to think so too, but experience eventually changed my mind.

When you're designing by writing code stubbs, you can "see" one or two pieces at once. You have to hold in your brain the relationships between pieces, and you have to navigate between views to answer questions like "does this class/component have access to all of the data it requires?" Some individual things are also likely to be larger than one screen's worth of info, so you might even have to navigate around within them to answer even simple questions questions. I'm not arguing that you can't reach the same end, but for me at least it's a heck of a lot slower.

With a decent diagram a large part of the system is immediately visible at once, perhaps even all of it. I can look at one class/component and easily see all of its relationships in front of me at once. I can answer questions like the above without changing views at all, which is already a great speed boost. Adding and removing relationships is also as easy as adding or erasing lines, which is faster than writing the relevant code, so iteration speed gets a boost there, too.

In short, I can make more effective decisions in less time, and something that saves time can hardly be seen as wasting time.

I think this is why its value is so often mistaken. It's too often taught while people are still coming to grips with the low level aspects of "making code work", so higher level concepts of software design are completely lost on them. Worse, even if they do design something up front, that actually makes the coding harder unless they already understand all of the specifics in their language of choice to properly map their design into code, which leads to compromise and frustration.

 

What @angrypenguin wrote above is pretty much the reason I over-simplified UML to say it's mainly for visualizing classes. Whenever I've heard someone say UML they're usually talking about the so-called lollipop-diagrams. You can model other parts of the system with the other UML schemes, of course, but whenever I've seen it done for a system of any significance (it was super-trendy in the early 2000s) you end up with a mostly-incomprehensible mess.

We had some corporate "astronaut architects" who tried to mandate design-by-UML for awhile and it was miserable. In effect you end up writing the code in your head just so you can draw these pictures, and then you have to write the code for real. Eventually model-first turned into a rule to build the code, then use VStudio to barf out UML, then pretty it up and store it with the documentation, where it would immediately become outdated and irrelevant. Now nobody uses it.

Of course, that's one story from one company, but I've worked at and contracted for many different companies and I literally never see it used.

I do often seen people sketching out quick-and-dirty informal diagrams along the same lines as the web sequence diagrams linked above, but that's typically either working through requirements or explaining something, it's rarely detailed enough to actually build code from.

 

What you want is a pencil, an eraser, and some paper. Alternatively if you have the space, a whiteboard. I've tried a lot of diagramming software, and my favourites are Dia and Visio, but I still find them cumbersome compared to pencil and paper.

I rarely find a need for class diagrams, but flowcharts and sequence diagrams can be really helpful at times.

 

It sounds to me like people have trouble thinking about software without thinking in terms of code. Is that the case? At some point you have to map from whatever your design language is to whatever your implementation language is, but your implementation language generally shouldn't have a huge influence on the design stage.

 

I'm not here to argue about it or anything. My original intent was to answer the OP's question about class designers, and to point out that visual studio has a built in class designer that you can use to visualize pre-existing classes, or to create new classes depending on the OP's need.

I don't have a problem thinking about software without thinking of code. If you say "write me x software", my brain will automatically start breaking the idea down into pieces that need to be implemented. That's the design phase for me. There may or may not be a whiteboard, notepad, text editor, or another person/people to bounce ideas off of, but I've been doing this for 20 years so the design phase is nearly automatic. I've never once in my professional career seen or used a hand made UML diagram. Flowcharts, diagrams, loose drawings, sketches on white boards, yes, but never a UML class diagram. We've created UML diagrams using tools from existing code for documentation purposes, but always after the fact.

 

Actually, I wasn't asking about class designers. I've made plenty of UML class diagrams before, that being the only part of UML I really know anything about, and I generally use Dia for it, though I didn't know VS had that kind of thing built in.

Really, what I was looking for without knowing it was sequence diagrams, because the real issue I was having is that my little learning project, small though it is, had become kind of muddled in it's flow of control from me having put things in, ripped things out and replaced parts so often as I learned new things about Unity. I needed something to help me visualize what is actually going on and what should be going on instead.

 

Check out lucidcharts.com. Its a free, online, web based diagramming tool that works very well. Its what we use now that visio is no longer included with MSDN.