>>53719206
i model, but idgaf about UML standards. first quick draft on paper, then yEd.

oh, and don't expect to adhere to your model. it just helps writing better code by structuring your head in the beginning, nothing more.

(also true for work stuff, incidentally)

I model things like control flow and project requirements on paper ahead of time to make sure it fits with the goal and isn't completely retarded so I don't waste my time

>>53719248
Oh, and like this guy says, fuck UML

>>53719248
>>53719330
>>53719351
These.

>Graduate from Purdue in 2002
>Take the software engineering track
>3 Semesters of UML and methodologies
Never used any of it outside the courses since.

Nope.

Shit's hardly ever used in industry anyway. Also fuck whoever invented UML with a rake.

>>53719468

So what is used in the industry today? I'm still in college so I wouldn't know. Surely people don't just start coding big projects, right?

Im really bad with visualising things, so I find it easier to just have a rough idea in my head then expand on it.

>>53719435
Hey I go to Purdue currently. What did you get your degree in?

>>53719568
Imo, good system engineer/senior software engineer still use them to help their junior programmer to get started.
It's just that some/many company doesn't really need those seniors people and let the programmer start themselves.
This especially true for fast moving project like android apps.

>>53719568
Sure, you draw charts and models. You just use whatever's clear and don't give a fuck about UML rules.

>>53719206
Literally
NOBODY
IN THE FUCKING WORLD
does this shit, pajeet.
Fuckoff.

>>53719248
as a clarification, what i mean when i say "don't expect to adhere to your model" is "don't get cucked by it". sometimes you will break it in code because it just makes more sense.

>>53719702
this, pretty much


if it helps you, here is how i usually work:
1. functional flow block diagram, but i rarely go beyond the top level presentations. only if i want to document for somebody else or i don't have a clear picture in my head what needs to happen when.
2. functional block diagram. this later determines which functions and data structures have to be written.
3. system architecture. basically just a rearranged FBD. rearrange by what logically belongs together.

depending on the project, any of these can be omitted. just do what helps you write better code.

https://en.wikipedia.org/wiki/Functional_flow_block_diagram (there's also something nice on youtube)
https://en.wikipedia.org/wiki/Functional_block_diagram (use blocks for actions and arrows for state and format of data)

in any case, find your own way to do it. keep in mind that these diagrams should not usually contain the implementation, so focus on REQUIREMENTS as opposed to SOLUTIONS. so, for example "hierarchical key-value-store" is a requirement; JSON is a solution.

fuck whoever invented UML with a rake, to quote the other anon. i have yet to see the project that wrote code according to an UML diagram. UML is only good for doing graphical representations of already existing code, i.e. after the fact, not before.

>>53720000
might as well keep going while i'm at it.

something about system requirements, it's an ieee standard, if you can get it for free through your uni have a read: http://ieeexplore.ieee.org/servlet/opac?punumber=5982

http://www.dau.mil/pubs/pdf/SEFGuide\%2001-01.pdf
systems engineering guideline by the US military press. you will be interested in the chapters "functional analysis" and "design synthesis". again, take this with a grain of salt. it's all just guidelines; just do projects and try what works for you. engineering is a lot of experience, it can't all be standardized even though you look for "the one right way".

>>53720000
>>53720084

Thanks for the extensive answer, I will make sure to check those links out to get some ideas as to what could work for me.

Also, if I'm allowed to be a tard, quads checked.

>>53720405
you're welcome.
you are allowed. i hadn't noticed.

Not User Mode Linux. Dropped.