Hey im learning Java and UML in uni wanted some tips

[matto97]

Just wanting tips for Java coding and UML

[LePawel]

use UML to make better JAVA?

As a student in EXACTLY same position, Java coursework for next friday built from a set of UML diagrams: Use the ultimate resource thread. There's no "Top 10 Tips" for Java and "Best 5 UML Class Diagram Layouts" for 2014, There's no silver bullet. Practice practice practice, alternatively procrastinate till week before deadline, shit pants, and practice for just a week, but without sleep.

Get your hands on Visio if you want, it's fairly easy to wrap your head around.

[Charle692]

Hey guys instead of using Vizio you could use Umple. http://cruise.eecs.uottawa.ca/umple/ It's a tool from which you create UML diagrams or state machines. Then from your diagram you can generate Java code. Although it's still buggy i think it's a lot better than Vizio especially since it saves you some time with coding. 

[lutzee]

UK uni student here, I hated learning UML, me and a couple of friends did some in depth investigation into the use of UML in business, and as we expected it is rarely used to create and design programs, and mainly used to document them. From experience the UML diagrams created before code and the ones generated finished were nothing alike. Code generation is often terrible and not useful.

 

TL;DR UML is a documentation tool, not a design tool.

[MikeD]

UK uni student here, I hated learning UML, me and a couple of friends did some in depth investigation into the use of UML in business, and as we expected it is rarely used to create and design programs, and mainly used to document them. From experience the UML diagrams created before code and the ones generated finished were nothing alike. Code generation is often terrible and not useful.

 

TL;DR UML is a documentation tool, not a design tool.

I (strongly) disagree.

 

UML is not supposed to be used to generate code. Not automatically, at least. It is also not supposed to be generated from a finished program either for documentation or other purposes.

When I was taking my Object Oriented Programming class at uni our project had as its first deliverable, even before starting coding, a UML diagram. The aim was to translate the specification into a high-level scheme of how the classes would be related to each other and what fields and methods would be necessary so it would be easier to reason about the solution. And since the teachers graded the UML before we started coding we could correct mistakes and find alternative solutions that saved a lot of work later when things were already too hard to modify.

Since we implemented some design patterns that we learned during the 2nd half of the semester in the project, the UML diagrams also helped understand where some pattern made sense and made the adaptations to the code easier because we had the "big picture" right there.

[lutzee]

I (strongly) disagree.

 

UML is not supposed to be used to generate code. Not automatically, at least. It is also not supposed to be generated from a finished program either for documentation or other purposes.

When I was taking my Object Oriented Programming class at uni our project had as its first deliverable, even before starting coding, a UML diagram. The aim was to translate the specification into a high-level scheme of how the classes would be related to each other and what fields and methods would be necessary so it would be easier to reason about the solution. And since the teachers graded the UML before we started coding we could correct mistakes and find alternative solutions that saved a lot of work later when things were already too hard to modify.

Since we implemented some design patterns that we learned during the 2nd half of the semester in the project, the UML diagrams also helped understand where some pattern made sense and made the adaptations to the code easier because we had the "big picture" right there.

Where planning a project in diagrams before hand is a good idea, UML is TOO formal, we spent ~6weeks working on perfecting UML diagrams to get marks for grades, when within the first  couple of those weeks we had a firm understanding of the system required. The next problem with UML is there is not formal standard, only 6-8 'standards' proposed and done differently. 

 

UML is too complicated as a starting base for a program, it works great as a documentation tool for showing people how a system works, but is by far not a good design tool set.

I'm currently working on a group AI project, we built initial class diagrams to map out everything we wanted, but we did not by far follow any formal specification while doing so. If UML was a pseudodiagram design tool with no formal specification and each item was just a guideline on how things would be useful, it would be much much better. 

[LePawel]

I (strongly) disagree.

 

UML is not supposed to be used to generate code. Not automatically, at least. It is also not supposed to be generated from a finished program either for documentation or other purposes.

When I was taking my Object Oriented Programming class at uni our project had as its first deliverable, even before starting coding, a UML diagram. The aim was to translate the specification into a high-level scheme of how the classes would be related to each other and what fields and methods would be necessary so it would be easier to reason about the solution. And since the teachers graded the UML before we started coding we could correct mistakes and find alternative solutions that saved a lot of work later when things were already too hard to modify.

Since we implemented some design patterns that we learned during the 2nd half of the semester in the project, the UML diagrams also helped understand where some pattern made sense and made the adaptations to the code easier because we had the "big picture" right there.

Well, after working with UML for 5-ish months, and now working off a properly finished UML diagrams in Java, they are useful but only as a guideline. You can get "Big picture" from header files or in case of java class prototypes. Yes you don't have fancy arrows, but you can press 1 button to jump around all declarations easily.

The problem at the moment is that no tool on the planet allows to quickly generate those diagrams, especially class diagrams. The fun part is that it pretty much undermines the first rule of OO, and that is not to do stuff more than once, while with UML you don't only have to do it in diagram form as well as code form, but also do it with freaking tables of dropdown menus in 3 different pop up windows each with 5 tabs. I wouldn't mind using them at all that if you could reliably port those diagrams with some common format through different IDEs and vice versa, keeping both the code and all diagrams constantly updated.

And I do talk about all UML diagrams, not just class ones, but that's nearly impossible.

[MikeD]

Where planning a project in diagrams before hand is a good idea, UML is TOO formal, we spent ~6weeks working on perfecting UML diagrams to get marks for grades, when within the first  couple of those weeks we had a firm understanding of the system required. The next problem with UML is there is not formal standard, only 6-8 'standards' proposed and done differently. 

 

UML is too complicated as a starting base for a program, it works great as a documentation tool for showing people how a system works, but is by far not a good design tool set.

I'm currently working on a group AI project, we built initial class diagrams to map out everything we wanted, but we did not by far follow any formal specification while doing so. If UML was a pseudodiagram design tool with no formal specification and each item was just a guideline on how things would be useful, it would be much much better. 

The more formal it is, the less ambiguity there is. If you had to hand your project to someone else it'd be better than if it were the kind of sketches we do on a piece of paper. Every time someone walks into a room in uni with some diagram on a whiteboard they have a different interpretation of what it represents. I have taken part in one too many hour+-long discussions about the architecture of some project because we didn't understand each others drawings! (Mainly because someone else would always walk in and say we were all wrong, but still!)

But of course UML is not intended as a tool for school projects. Apart from OOP class we only used UML and such in a Modelling class where we had to respond to a "request for proposals for the specification of requirements and the analysis and design of a system of systems, conceptually made of one logical system and one physical system.". We were the company that was going to design the system and our results would be handed off to two other companies that would do the actual systems. We had to do requirements elicitation from the document that we were given and use different kinds of UML diagrams (sequence, class, deployment, etc.) and even BPMN and SysML to model the systems. In this context UML makes sense, but for school projects, sketches on paper were just fine (if everyone was on the same page about their meaning!).

By the way, i assume that by "only 6-8 'standards' proposed and done differently" you were talking about the different UML diagrams? Because UML is a well-defined standard (ISO/IEC 19505).

 

Well, after working with UML for 5-ish months, and now working off a properly finished UML diagrams in Java, they are useful but only as a guideline. You can get "Big picture" from header files or in case of java class prototypes. Yes you don't have fancy arrows, but you can press 1 button to jump around all declarations easily.

The problem at the moment is that no tool on the planet allows to quickly generate those diagrams, especially class diagrams. The fun part is that it pretty much undermines the first rule of OO, and that is not to do stuff more than once, while with UML you don't only have to do it in diagram form as well as code form, but also do it with freaking tables of dropdown menus in 3 different pop up windows each with 5 tabs. I wouldn't mind using them at all that if you could reliably port those diagrams with some common format through different IDEs and vice versa, keeping both the code and all diagrams constantly updated.

And I do talk about all UML diagrams, not just class ones, but that's nearly impossible.

The thing is, you shouldn't need to generate UML diagrams from code because they are supposed to be (mostly) done before writing any code at all. In fact, our OOP teacher did not want to see any automatically generated diagrams or code (and he actually encouraged us to use a text based editor for coding with java as opposed to an IDE for that class, so that we wouldn't get any bad habits!).

In the example I used above - the Modelling class - our "company" was only responsible for designing the architecture and the other 2 companies would have to actually build the systems based on our diagrams. In total we had 48 diagrams and 69 tables. Of course in that case we were talking about a public contract, which means there were stricter rules, the diagrams had to be near perfect and we had to provide complete traceability; in a normal company there would be space for UML improvement as the project went on (and if we were talking about an agile process instead of waterfall there would probably be no diagrams at all!!).

[LePawel]

The thing is, you shouldn't need to generate UML diagrams from code because they are supposed to be (mostly) done before writing any code at all. In fact, our OOP teacher did not want to see any automatically generated diagrams or code (and he actually encouraged us to use a text based editor for coding with java as opposed to an IDE for that class, so that we wouldn't get any bad habits!).

In the example I used above - the Modelling class - our "company" was only responsible for designing the architecture and the other 2 companies would have to actually build the systems based on our diagrams. In total we had 48 diagrams and 69 tables. Of course in that case we were talking about a public contract, which means there were stricter rules, the diagrams had to be near perfect and we had to provide complete traceability; in a normal company there would be space for UML improvement as the project went on (and if we were talking about an agile process instead of waterfall there would probably be no diagrams at all!!).

Coding in text editor, are we in stone age? How's using IDEs a bad habit? Good luck with debugging the damn thing, especially the one that's made of your 48 diagrams.

Also, depending on what you do, these diagrams can be done before work, and then ignored half-way through development cycle because they become obsolete or you can go back and make sure they are up do date so a 3rd person can come in the middle and go "ok, that's the structure" instead of figuring everything by himself. Next, why not use generated code if it works? All you can do with a class diagram is create basic classes with empty functions, speeds up the process of actually getting into the code and learning that you forgot a convert function, or that toString overload.

The larger the project the more holes the UML will have, and it's pointless getting down to the minute detail you can't test at all. Unless you're a company that just designs the software using the best OO practices and don't get involved in the development cycle at all, because it almost makes sense. Even better if your client uses TDD on top of OO.

[MikeD]

Coding in text editor, are we in stone age? How's using IDEs a bad habit? Good luck with debugging the damn thing, especially the one that's made of your 48 diagrams.

Also, depending on what you do, these diagrams can be done before work, and then ignored half-way through development cycle because they become obsolete or you can go back and make sure they are up do date so a 3rd person can come in the middle and go "ok, that's the structure" instead of figuring everything by himself. Next, why not use generated code if it works? All you can do with a class diagram is create basic classes with empty functions, speeds up the process of actually getting into the code and learning that you forgot a convert function, or that toString overload.

The larger the project the more holes the UML will have, and it's pointless getting down to the minute detail you can't test at all. Unless you're a company that just designs the software using the best OO practices and don't get involved in the development cycle at all, because it almost makes sense. Even better if your client uses TDD on top of OO.

Not in the stone age, but learning. And it was not mandatory, just encouraged. I personally think that not using an IDE while learning was a good thing. After that class I had others with Java and we used Eclipse. While it is a great tool and saves a lot of time it also attempts to fix mistakes for you and if you don't know what you're doing it may make things more confusing to someone.

We did not have to implement anything in the project with all the diagrams. Like I said, we were the architecture company and our final product were the diagrams (and most of them were sequence diagrams, use cases, SysML and BPMN).

Yes, the structure of a system will most definitely change over time (especially with agile development methods), so the UML diagrams should be kept up to date, not ignored.

I agree with what you said about automatically generated code, if you know what you are doing. But for a beginner it might not be the best thing. One could trust the generator too much and not double check if everything is correct. And, if you're a teacher, you'll probably be a little suspicious and pay more attention to mistakes if you're grading a project with artifacts (e.g. comments) from an automatic generator!

The level of the UML diagram will depend on the stakeholder it was intended to. The systems administrator will probably only need a deployment diagram, the project manager a UML with only the classes/packages and relationships and the actual developer of a certain module will probably need a more detailed diagram of that specific module. A single diagram will not give information about the whole thing and will have many holes, but the set of all diagrams should be mostly complete. Of course it need not have every single implementation detail or you'll sacrifice readability.