• Advertisement
Sign in to follow this  

Unity Help Choosing The Correct UML Diagram (Beginner) -- After

This topic is 4645 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This is a continuation from this thread Help Choosing The Correct UML Diagram (Beginner) . It seems like I cannot reply to it; it always send me to the first page when I try. Now that I'm done with my project, I have the following to say (long!). Fastlane69 you were right, I did blow off my leg! I started with the Use-case and the Sequence Diagrams. I really liked doing them because they helped me with emphasing on the clients' requirements and also depicting how the finished program "is going to" operate. They did blow up in my face though--more on this later. Then came the Class Diagram, and man that was a though cookie. At first, I started to think about all the classes that I would need, and how I would connect them together. I ended up with 3 base classes: 1 with 2 subclasses and another one with 3. Then came the nightmare, I couldn't connect them. I mean, could not reproduce the flow of my Sequence Diagram. I spent two days trying to fix it by either adding more classes or functions that would handle the other classes. Fed up, I took a two days break playing Megaman Zero 3. And one morning, while in the bus, it just "clicked". Literally, the clouds moved away and the solution appeared in front of me. I had too many classes... and after droping them one by one (it was a lot of fun actually), I was left with 1 class and 3 subclasses. I also reslized that my Sequence Diagram was poorly designed in the first place, hence all the trouble. Lesson #1 : The less classes the better.
Quote:
Until you actually sit down and code out the project, you're not going to really be aware of all the little nuances.
So TRUE Clash. I got my confidance back because I though I had a good design (for my first try at least). But that saying put me back to reality real fast. All the nuances started to pop up one after another. I guess I was too focused on the high level stuff and when I got to the low level, the design was no help at all. The worst is, and I am sure of it, that some of them I would have been able to predict. For example, in one function, I was outputting and formating the result directly to a textbox. To realize that I would need that value later on. Sure, the solution is easy--return the value. But when the value is 10$ and you only need the 10, and you cannot change the value of the textbox, it's a pain. Time and effort lost! Lesson #2 : Never think your design is completed. So that's it. Although I wasted a lot of time, I did finish the project on time. I also have to say that Clash your post is very demotivating. I have read it at least 20 times and don't see anything positive. I didn't want to believe it back then, but your right. Now, that TDD seems interesting. I didn't look to much into it. It would be cool if you could elaborate on it. Darkneon

Share this post


Link to post
Share on other sites
Advertisement
Quote:
I also have to say that Clash your post is very demotivating. I have read it at least 20 times and don't see anything positive. I didn't want to believe it back then, but your right.
I used to think that becoming a better system architect meant that I would have to redo less. That as I got better my first designs would be closer and closer to perfect. At some point I realized that was simply impossible. There are lots of reasons why, both political and technical. All the fuss going on about "Agile Development" isn't just hype. The fundamental idea is all about writing code earlier in a project. Writing that code in such a way that there are no extra features and it is easy to refactor.

I suggest you read up a bit on Agile methodologies. In particular, I think XP has a lot of good ideas (one of which is Test-Driven Development). Take a look at these two books:

Extreme Programming Explained:
http://www.amazon.com/exec/obidos/tg/detail/-/0321278658/qid=1117592351/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/002-0279005-5628819?v=glance&s=books&n=507846

Test-Driven Development:
http://www.amazon.com/exec/obidos/tg/detail/-/0321146530/qid=1117592335/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/002-0279005-5628819?v=glance&s=books&n=507846

Share this post


Link to post
Share on other sites
I second that motion. I find that the people that think Agile is a buzzword are the people that aren't willing to give up their old school way of developing software and are just dead set in doing things the HARD LONG way.

Agile, at its core, is a methodology that is Human-Based...ie it starts with the correct belief that you will NOT get something right the first time but through careful iteration, you will get something that was better!! This is in sharp contrast to the old school developers that is Computer-Based and who think that their first pass at code should be 99% correct and keep wondering "why doesn't that last 1% work? It should work!" and keep trying to pound a square peg into a circular hole :} LOL

Beside, Agile complements UMLs fantastically since drawing is a much more expresive and efficient way to communicate large complex ideas (all too common is soft dev).

Remember your two lessons, they will take you far. Especially with UML, it is easy to see when you are overwhelming your system and I suspect this will NOT be the first time that you will look at a UML diagram and have a eureka moment by merely subtracting one class...try to do that with procedural, non-iterative programming!!!!

Share this post


Link to post
Share on other sites
Quote:
Original post by Darkneon
Lesson #1 : The less classes the better.

This is somewhat wrong. A good design has the correct number of classes. This class count can be rather big. Using some OO programming principle might increase the class count (for instance, if you choose to follow the 'favor composition over inheritance' principle, you'll probably end up with a large amount of small object. This is not bad at all, since most of these objects will have a clearly defined interface and will be easily reusable).

Quote:
Original post by Darkneon
Lesson #2 : Never think your design is completed.

... but you'll have to stop it one day, because if you don't then you won't be able to finish your product :)
Perfection doesn't exist, but you may consider that your design is finished whe it is "good enoug". Remember we speak about software engineering in this forum, and engineers tend to have things to create - just thinking about something is not sufficient.

Quote:
Original post by Darkneon
So that's it. Although I wasted a lot of time, I did finish the project on time.

Then it is good! It should be interresting for the community to share your experience about this first use of UML.

Regards,

Share this post


Link to post
Share on other sites
Thanks guys for posting. I will first answer to Emmanuel Deloget comments.

First Comment: OK, I can't comment anything right or wrong on this one! I can't because I don't have enough knowledge at the moment. But I don't discard what you said, I'll just put it in my bag until reality proves me right or wrong. As a side note, I have read it somewhere (can't remember where) where the person was suggesting to put only the important classes in the diagram and to indicate that the other classes exist without including them.

Second Comment: Sure, it's like the saying that "perfectionists never finish anything", which I personally totally disagreed with. But that's not the point, the point is what Clash mentioned before "[that] until you actually start making the API calls and writing the functions, you can't know if your design is correct". Now, replace 'correct' with my 'completed'. Plus, I'll say that it's not when you start off writing the code that you'll catch a problem with you design. You can write out 3/4 of the program and realize that the rest is off or something is missing. That's why from now on I am going to go back and forth between my programs and designs.

Furthermore, I started reading "Test-Driven Development By Examples" and I am also reading articles by Martin Fowler.

I have a question about TDD. Lets say that my primary goal it to save time. Is using TDD going in the opposit direction? I mean if you test every 3 minutes, even if it is for 30 seconds, at the end of the week that's a lot of hours lost. It has become an habit since I started programming, and I found it to be the most time consuming part. Or is it an "in the long-run" thing?

Thanks
Darkneon



Share this post


Link to post
Share on other sites
Quote:
Original post by Darkneon
Furthermore, I started reading "Test-Driven Development By Examples" and I am also reading articles by Martin Fowler.

I have a question about TDD. Lets say that my primary goal it to save time. Is using TDD going in the opposit direction? I mean if you test every 3 minutes, even if it is for 30 seconds, at the end of the week that's a lot of hours lost. It has become an habit since I started programming, and I found it to be the most time consuming part. Or is it an "in the long-run" thing?
It's definetly something that doesn't pay off until the end of the project. You can test now, when the code is fresh in your mind and fixes are blatantly obvious, or you can test later, when you'll have to spend more time remembering what the code does, and then fixing it. Unit testing is orders of magnitude easier and more productive than intergration testing.

It also (at least for me) is huge morale booster. There are few things better than seeing all of your tests pass.

Whether it reduces development time is irrelevant to TDD - it's all about increasing the quality of the code. It usually taking the same amount of time as "traditional" testing methods, but produces much cleaner code. It's also a great way to debug designs - when you're writing your tests, the design's flaws are more apparent than when writing the actual code.

Share this post


Link to post
Share on other sites
When you first start doing test-driven design your productivity will drop for a while as you get accustomed to it. After a few months your productivity will end up higher than it was when you started. Why? Well... aside from having better designed code, TDD essentially automates your debugging process. Rather than having to step through the code and place print statements everywhere, you automate the checks. This lets you recheck the entire application without doing anything. You'll see the benefit to this everytime you add any non-trivial feature. It'll be immediately known if something else broke.

Of course this assumes that your tests have good coverage. But if you find a bug that doesn't cause a test to fail; write the test so it fails and then fix the bug.

The unit tests also serve as good sample-code for the code being tested.

Share this post


Link to post
Share on other sites
Quote:
Original post by Darkneon
Furthermore, I started reading "Test-Driven Development By Examples" and I am also reading articles by Martin Fowler.

I have a question about TDD. Lets say that my primary goal it to save time. Is using TDD going in the opposit direction? I mean if you test every 3 minutes, even if it is for 30 seconds, at the end of the week that's a lot of hours lost. It has become an habit since I started programming, and I found it to be the most time consuming part. Or is it an "in the long-run" thing?

Thanks
Darkneon

Lost? How so? Consider this, the longer you wait between running tests, the more debugging you end up having to do to fix the bugs that cropped up because you didn't run the tests. Secondly, the loss of time is an illusion. While it does appear that you are spending more time coding tests and running them, in fact you will generally find (in the long run with experience, and in the short run afterwards) that not only does it consume less time than traditional "wait till the very end then fix all the fuckups" method of coding, but it also enables you to quickly make changes and verify that they don't fuck up anything else.

Refactoring is a core principle of XP, along with TDD. I would definantly recommend picking up the book by the same title. Refactoring also relies on unit tests, mind you. Which means that if you have already coded in the tests, then you've saved yourself from having to code in the tests on code that "works". The advantage here is one of perspective. Rarely will you be able to think through and complete cover the workings of "working" code. However if you write the tests as you develop the code, then your coverage will be more complete.

Also, a test that passes, but should fail is often more informative than a test that should pass but fails.

Finally, in parting, I have this link for you: JustTenMinutesWithoutAtest

Share this post


Link to post
Share on other sites
I'm getting confused here.

Quote:
TDD essentially automates your debugging process. Rather than having to step through the code and place print statements everywhere, you automate the checks.

What do you mean by 'automates your debugging' and 'automates your checks'?

Quote:
Which means that if you have already coded in the tests, then you've saved yourself from having to code in the tests on code that "works".

Let me try to rephrase it. If you have code that has been tested and debugged, now that it works, you don't have to modify it anymore? But working code is not shielded from future code.

Quote:
However if you write the tests as you develop the code, then your coverage will be more complete.

You will be able to spot stuff that otherwise you would have missed. The questions: "I need to write a function that will ..." and "I need to test a function for ..." lead to different answers even though they imply (more or less) the same thing.

Good link by the way.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Tags

  • Advertisement
  • Popular Now

  • Similar Content

    • By Innoc uous
      I'm working on a space game, and I suck at art. I would love to get some help from someone who is more skilled than me. Things I need include modular space ship parts and GUI elements. Nothing too fancy, just functional so I can get a prototype put together. This could potentially become a serious project, but for now this is just a hobby project.
       
      In this video, you can see a few things I already completed
      :2018-02-24 20-08-13.flv2018-02-24 20-08-13.flv
    • By Innoc uous
      If you want to incorporate noise into your shaders, the Turbulance Library has you covered. Using code I gathered from this library, I made a cginc file that contains all you need to easily implement noise into your unity shaders. Who knows how this stuff works, but man, does it work well!
       
      https://pastebin.com/LLCUpJut
       
      Here is an example of what you can create using these noise functions.
       
    • By Nio Martinez
      I'll be buying a new laptop as my workstation for building games, Mostly 3D but not hard core. 
       
      I'm stuck at choosing between these 2 specs below. Does this really matter and if so, can some one tell my how and why it matters. 
      Choice1:
      Intel core i5-8250U (8th gen Kabylake refresh)(6 MB Smart Cache, 1.6 GHz Base with Turbo Boost up to 3.4 GHz) 4 cores 8 threads
      RAM 8 GB DDR4 (2400 MHz)
      GPU 2 GB DDR5 Nvidia MX150 256 bit
      SSD: yes
      Choice2:
      Intel core i7-7500U 2.70GHz Base Processor (4M Cache, up to 3.50 GHz Boost) 2 Cores, 4 Threads
      RAM 4 GB DDR4 (1800 MHz)
      GPU 2 GB DDR5 Nvidia GeForce 940MX 256 bit
      SSD: No
       
    • By Manuel Berger
      Hello fellow devs!
      Once again I started working on an 2D adventure game and right now I'm doing the character-movement/animation. I'm not a big math guy and I was happy about my solution, but soon I realized that it's flawed.
      My player has 5 walking-animations, mirrored for the left side: up, upright, right, downright, down. With the atan2 function I get the angle between player and destination. To get an index from 0 to 4, I divide PI by 5 and see how many times it goes into the player-destination angle.

      In Pseudo-Code:
      angle = atan2(destination.x - player.x, destination.y - player.y) //swapped y and x to get mirrored angle around the y axis
      index = (int) (angle / (PI / 5));
      PlayAnimation(index); //0 = up, 1 = up_right, 2 = right, 3 = down_right, 4 = down

      Besides the fact that when angle is equal to PI it produces an index of 5, this works like a charm. Or at least I thought so at first. When I tested it, I realized that the up and down animation is playing more often than the others, which is pretty logical, since they have double the angle.

      What I'm trying to achieve is something like this, but with equal angles, so that up and down has the same range as all other directions.

      I can't get my head around it. Any suggestions? Is the whole approach doomed?

      Thank you in advance for any input!
       
    • By devbyskc
      Hi Everyone,
      Like most here, I'm a newbie but have been dabbling with game development for a few years. I am currently working full-time overseas and learning the craft in my spare time. It's been a long but highly rewarding adventure. Much of my time has been spent working through tutorials. In all of them, as well as my own attempts at development, I used the audio files supplied by the tutorial author, or obtained from one of the numerous sites online. I am working solo, and will be for a while, so I don't want to get too wrapped up with any one skill set. Regarding audio, the files I've found and used are good for what I was doing at the time. However I would now like to try my hand at customizing the audio more. My game engine of choice is Unity and it has an audio mixer built in that I have experimented with following their tutorials. I have obtained a great book called Game Audio Development with Unity 5.x that I am working through. Half way through the book it introduces using FMOD to supplement the Unity Audio Mixer. Later in the book, the author introduces Reaper (a very popular DAW) as an external program to compose and mix music to be integrated with Unity. I did some research on DAWs and quickly became overwhelmed. Much of what I found was geared toward professional sound engineers and sound designers. I am in no way trying or even thinking about getting to that level. All I want to be able to do is take a music file, and tweak it some to get the sound I want for my game. I've played with Audacity as well, but it didn't seem to fit the bill. So that is why I am looking at a better quality DAW. Since being solo, I am also under a budget contraint. So of all the DAW software out there, I am considering Reaper or Presonus Studio One due to their pricing. My question is, is investing the time to learn about using a DAW to tweak a sound file worth it? Are there any solo developers currently using a DAW as part of their overall workflow? If so, which one? I've also come across Fabric which is a Unity plug-in that enhances the built-in audio mixer. Would that be a better alternative?
      I know this is long, and maybe I haven't communicated well in trying to be brief. But any advice from the gurus/vets would be greatly appreciated. I've leaned so much and had a lot of fun in the process. BTW, I am also a senior citizen (I cut my programming teeth back using punch cards and Structured Basic when it first came out). If anyone needs more clarification of what I am trying to accomplish please let me know.  Thanks in advance for any assistance/advice.
  • Advertisement