I am trying to reverse-engineer a school project into a Class Diagram. I noticed that when it's done, all my associations have this little bullet kind of thing in front of the one-way navigable arrow like this:
What is it and what does it do? Also how do I turn it on or off, or get rid of it?
I would greatly appreciate your help as I cannot find any relevant information on Google and it is due tomorrow to finish it.
I found it! :D
For some magical reason stackoverflow gave this in related questions: setting the association-end ownership in uml
I didn't know how to describe what I was looking for, ownership is what it is! :)
Related
I'm currently taking part in a "Data modeling" course. And for my final project, I need to make a research about "R-tree index for spatial searching". However, I'm not at all familiar with many concepts concerning the subject matter (spatial data, multi-dimentional data,...).So, I read the wiki and as I encountered new concepts, I tried to learn them on the way.
However, I don't think this top-down approach is a very efficient way to go about this. Thus, I'd really appreciate it if anybody can suggest a way/lists of things that I need to read up in advance, in order to understand R-tree, and hopefully make some kind of implementation out of it.
Start with the original paper and check out (shameless self promotion) a basic R-Tree implementation in Java.
In the last days I have found the componed based entity system.
I think i understand and know how it works, but if I try to implement it, I get a lot of problems.
Here a diagram with the most Problems:
http://s7.directupload.net/file/d/3327/pzy7kanj_jpg.htm
And I wonder me, can I add the same component twice to an entity, or should I dont allow this?
If no, how I can add multiple sprites to an Entity?
And if a make a CollisionComponent or a Physik Component, the Physik and the MoveComponent must communicate, right ?
I hope anyone can me help.
Here I have made another diagram, from Ideas:
http://s1.directupload.net/images/130725/5p83qysu.jpg
Ok there seem to be a lot of related questions between this post and the diagrams you linked to. The answer to these questions are 'it depends.' and I am guessing you would like some guidance on the subject of CBSEs rather than one line answers to all of your questions. Rather than try and regurgitate the discussion based on similar queries I will post some links here that should get you thinking more about these issues.
First there is the ES wiki. This wiki is still in its infancy, but it holds some great discussion on entity systems.
Next, there some really productive discussion over at gamedev stack exchange (maybe this question should be moved there as well). First take a look at this question, it's a good starting point because it explains why there are no clear trends in ES design (when that answer was written) and from what I've seen it still holds true today. Then there is an absolutely amazing answer given by Byte56 that explains the basics of the system-component approach extremely well, and is well worth reading even if you think you've already got a handle on it. Next there is a helpful series of questions asked by Yannbane. These questions address some of the finer points in more detail. Here are all three questions. Also, there are some questions on how to integrate input and Game States.
Finally, you should check out some open source entity systems that have had a lot of attention such as Artemis written in Java (There seems to be a server issue right now for that link but this article is a good intro, and there are c# and c++ repositories available, so you can dig into some code). There is also ash written in AS3.
Now I feel I must answer one of your questions directly:
And if a make a CollisionComponent or a Physik Component, the Physik and the MoveComponent must communicate, right ?
From the diagrams you linked to you seem to be using the systems-based approach (similar to artemis). From my reading I believe that this is one area that has been generally agreed on by the community: in the system approach the idea is to centralize the component logic so that (aside from a few simple methods as mentioned in the answer to Yannabe's second question) the component is little more than a data container. So if your components are stored in entities then your systems are required to sift through all of your entities. The systems that require more than one component should be asking each entity for all the components it needs to do its work. If it doesn't find all of those components the system should move on. So based on what you have decided so far the answer is no, components should not be communicating with eachother.
Anyway, good luck on this.
I am in need of some resources on how to design the main components of a basic 2d game.
Let's call it an "engine". How should I design my renderer, scene manager, entity manager a.s.o. and how should they interact with each other? What about event management, resource management, ...
Maybe someone has some cool UML? Or any "tutorial"? Some general hints and tips?
I've actually also struggled some in order to get a hold of some good tutorial for a while. I found tons of mediocre sites with working game-code but lacking explanations.
What helped me the most was probably just skimming through game code I found casually looking around, and also reading the chapters of the book on this site: Killer Game Programming with Java
You can find some game-code to look through on these sites:
http://www.cokeandcode.com/info/tut2d.html
http://www.javacooperation.gmxhome.de/TutorialStartEng.html
Hope you found this helpful!
this question might look dumb but I need to have a clear idea when learning about something new :)
In SSADM, do we have to do a comprehensive study about the "feasibility" (Stage0)? How can we get an idea about the feasibility before even performing "investigation" (Stage1) about the business?
What is actually expected in Stage0 anyway?
Thanks. Hope someone would shed a light on this.
My references are not available to me at the moment so this is from memory - I think the feasibility stage is about getting the project off the ground - why should people commit resources to even an investigation. So when they are talking about feasibility, and the contents of the report things that are likely to be covered are a broad statement of the problem; why it is a problem; why a system solution looks like the way to go to solve the problem; who will pay for it; who is sponsering it and who will benefit from it.
By definition, it is impossible to do a comprehensive study of feasibility before getting into the work, but rather I think of a feasibility picture as painting a picture of what might be if this project were to go ahead - so broad stroke rather than detailed and comprehensive.
In essence the feasibility stage is answering the questions "why should we bother with this project; and if we are bothered to do this project do we think we are capable of doing it.
More often than I'd have hoped I seem to come across method/property definitions in Apple's documentation that are vague at best and meaningless, to me, at worst. For example, take the following method description from NSNumberFormatter Class Reference:
setPartialStringValidationEnabled:
Sets whether partial string validation
is enabled for the receiver.
- (void)setPartialStringValidationEnabled:(BOOL)b
Parameters
b YES if partial string validation is enabled, otherwise NO.
So, let's just assume that the shoddy educational system I went through and any previous projects I've worked on didn't cover "partial string validation" in Cocoa and I would like to dig into it some more to see what this property is all about. Where does one look (aside from Google)? I hate to pester forums for something I should be able to look up easily myself.
I have come across situations like this enough times now that I think I may be approaching Apple's docs incorrectly. Any suggestions? Tips/tricks? 3rd party resources?
Partial string validation is explained in NSFormatter class.
Setter methods like that are sometimes explained in more detail in the getter method, the introduction text in class documentation, or one of the documentation companion guides you see linked on the bottom left. Sometimes you can also find clues in the Cocoa headers, by right-clicking on the name when you're writing code and selecting 'jump to definition'.
Otherwise, there's really no other resource other than google, asking about it on sites like this or using a mailing list. You could always write some code to test what happens when you change its value. And of course, if it's something really confusing it's good too to take the time to file a radar bug report so it will hopefully be improved in the future.