Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Are these diagrams correct? I am talking just about UML specifications. The first one is a class diagram of a code implementation. The second one is an activity diagram showing how to repair some 3D models.
The diagrams look good, although there are a few minor errors:
GameObject is used as a type, but not defined. You will have to define it as a class, an interface or a data type.
List<...> is not correct. In UML, use the multiplicity *, as follows: - NPCs : GameObject[*]
In the activity diagram, the labels along flows leaving a decision should be between square brackets, e.g. [yes] and [no].
There is a merge symbol missing before search for holes. If an action has two incoming flows, this means that the action is executed after all incoming flows have been followed, but in your case, you want the action to be executed after one of the three flows has been followed.
One final remark: you didn't specify any multiplicities for the association between Character_Controller and Teleporter. This is okay, but it means that the multiplicities are undefined, i.e. it is not specified to how many instances of Teleporter a Character_Controller is associated and it is not specified to how many instances of Character_Controller a Teleporter is associated. Since you did specify multiplicities for the aggregations, I would advise to specify multiplicities here as well.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 months ago.
Improve this question
How do I draw a UML Sequence diagram showing the Participants and Method calls for BuildOrder.getOrder() in the code: Source code
A participant c:Client that calls an operation method() of another participant o:Order() is shown in a sequence diagram as a message:
The case of getOrder() is a special case in two ways:
first, it is a static operation, which is not related to a specific instance of the class. A static operation can nevertheless be shown as a message to an object of the class (see UML quote below).
second, it creates the order with which you'll interact. You would therfore show it as a create message: the arrow is dashed and open headed, and is directed to the box atop of the lifeline:
Remark: you could just show «create». However, nothing prevents you from specifying precisely the static operation that is called, as the UML specifications explain:
Lifelines cannot directly represent Types. However, any Lifeline representing a ConnectableElement with a Type having an Operation with isStatic = true, can accept Messages with a signature associated with that static Operation.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
In Lucidchart, which all data types are built in to use for attributes and parameters in class diagram?
A UML Class Diagram is simply a way to structure data about the way your code is organized. What you put into the diagram is entirely up to you and is dictated by the part of the code you are diagramming. You can try searching online for introductory guides for class diagrams that will give examples.
Within Lucidchart, absolutely any text content is valid within a UML Class Diagram shape. You will notice that the class diagram shapes contain some default text when you first add them to your diagram. This text is just an example of one notation you could use to annotate your classes and objects that you represent in your diagram. Lucidchart is just a tool that is designed to be as nonrestrictive as possible as you create your class diagram. It does not perform any logic to verify the attributes or parameters you choose to list in your diagram.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
If we imagine we are given with a domain diagram and we also have a use case.
I am struggling to understand, what exactly can we derive?
Ex domain model, found on google.
I want to get to the interaction diagrams as a result.
I think the path is, system sequence diagrams -> operation contracts -> interaction diagrams
I just dont get the logic of how to derive all this from a domain diagram because on communication diagrams we can have instance creations that comes out from no where.
Can anyone explain how to derive all this from a domain diagram (if there are steps)?
This domain model represents the static structure of your domain. It does not give any information about its dynamics (how it behaves/changes over time). Sequence diagrams and interaction diagrams model the dynamics. They cannot be derived from the domain model.
In your question, you wrote: "We also have a use case". A use case gives information about the dynamics, so maybe you can derive the sequence/interaction diagrams from the use case.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am creating a sequence diagram for an alarm system which involves a few different states and events which cause different behaviour depending on the state.
I am wondering the best way to present it. I planned on creating reference sequences to common events - such as entering a pin, a sensor going off and the alarm being activated - along the path of 'no fault'. This would be the alarm being off, being armed and then being turned off again. Without the alarm being set off by the sensors or pin entry failure.
Here's what I've got so far. Is there a better way (I will obviously define the reference sequences) or is this clear enough?
My approach to this is to keep sequence diagrams limited to a single level. The sequence diagram should only describe the behavior of one operation of one single class. To describe behavior of other operations of the same or other classes I use different sequence diagrams.
Furthermore I try to limit the number of messages in a sequence diagram to something like 15 or so. In general my rule is that I should always be able to print a diagram on A4 size and still be able to read it. If not there's too much on the diagram and it should be divided over several different diagram.
More details can be found here: UML Best Practice: One Operation => One Sequence Diagram
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Is there a correct way to refer to the two classes in this relationship? I was thinking of something similar to A being the parent and B being the child, but this sounds wrong for composition.
A UML composition is intended to capture a special case of a part-whole relationship. Since it's called "composition", it seems natural to call the two classes involved component class and composite class.
There is no accepted standard for the names of these classes.
The UML standard text uses terms Container - Part. But they are not parts of the standard itself, they are merely terms used for explanation.
The most often and, IMHO, convenient terms are: A is container class, B is item class.