I have been told to create an analysis diagram but it states that only date classes should be added. I thought that is what you use anyway, or am I thinking about this wrongly
"The models include a domain/analysis class diagram (which contains data classes only)"
I wouldn't ever use this terminology but my guess is that the instructor/manager wants your model to contain only the classes that will be later on implemented in the database (i.e. those that represent the concepts that you´ll need to store information about). To me this set coincides with what I´d refer to as domain classes but maybe your instructor has a different interpretation
Related
I am making a class diagram. I have a Person class and an Address class. I am thinking there is a 'Has-A' relation between the Person class and Address class (Aggregation):
Am I right in marking the relationship as association?
Does it depend on us how we want the model the relationship?
For example, if I have two classes, Book and Library, I could say that Books shall not exist without a Library (composition) or I could say that Books may exist independent of library(Aggregation).
There is no one correct answer. There are many valid ways to model a scenario. In this case you could either mark the relationship between Person and Address as an association (more specifically aggregation), or you could mark it as a complex attribute.
Yes, details like that should be discussed with stakeholders / people who understand the domain you are modelling.
Is the association right?
Yes, you are right: a simple association expresses perfectly that a Person has an Address. Nobody could claim on the base of your narrative that your model would be wrong.
But modeling is a form of communication: You may well chose a different notation to add nuance in what you express, and you may decide for different semantics to tell how you see things in view of your needs.
Does it depend on us? Notation
In our example, you may want to clarify what you mean with the association by giving it a name:
Or you may prefer to clarify the role of the address in the association:
Or in complex diagrams you may prefer the shorter but equivalent property notation, nevertheless keeping in mind that "A useful convention for general modeling scenarios is that a Property whose type is a kind of Class is an Association end, while a property whose type is a kind of DataType is not":
Does it depend on us? Semantics
You could go for aggregation, but I'd strongly discourage it since UML does not define any semantic for it. So there's no benefit compared to a simple association.
You could consider composition. It might in general not be the best choice, as addresses exist independently of the persons. But in an application that creates separate Address objects for each Person, it could reveal how you intend to manage addresses.
Or you may want some richer semantics, for example with an association class to tell that people could have plenty of addresses of different kinds:
I was wondering if it was possible to have differences between my conceptual model and the class diagram?
In the conceptual model, I explain that the user can create a message.
But in the class diagram the user must go through a class that contains all methods of creating a "ManageMessage" message.
here is an example
Can you help me ? Thank you
It's up to you how you show your classes in different diagrams. So in one you can show detailed attributes and operations and in another you show just the class name. However, in most cases it's better to create domain model which focuses on business aspects in the beginning. It does not have technically imposed structural elements and mainly you use attributes (YMMV). Later you derive a technical design from that model where you create a copy that links back with <<trace>> dependencies (UML tools offer transformation for that). Although you have to (mostly) manually synch the two models it's best to communicate with either business and developers.
N.B. about your design above: A message with zero related users does not seem to make much sense. Also you should not use the shared aggregation since it has no defined semantics.
I am currently making a domain model of a combat game, and I have difficulties determining whether certain elements should be a class of their own or attributes of some class. For example, I have used a category list to determine the following ideas/objects: Fighter, Level, Weapon, Armor, Attributes, Skills, Arena, Game Mode, Game Log, Opponent.
For example, I can't tell whether Level, Weapon, Armor, Attributes, Skills should be simply stated as attributes of a fighter or should they be delimited as their own object. I can't tell either if an opponent should be a distinct class since it is ultimately a fighter object with an 'attack/defend' association to another fighter.
How does one determine what would be the correct choice for each element in a category list? Can these be subjective?
FYI, I am using Craig Larman's "Applying UML and Patterns" 3rd Edition as an information source.
To clarify your question for a moment -- each Class in your domain model will have a set of Attributes. The question I think you are asking is whether the Type of each of these Attributes should be a Class themselves, or some other data structure (e.g. a struct, enum, primitive etc.)
If this is correct, then the answer comes down to design choices that stem from your analysis; there is no one 'correct way' -- this is the art of software design. There are however a few key things you might want to look for in making your decision:
Evidence of behavioural requirements. Does the object that an Attribute refers to need to encapsulate behaviour itself? Clearly it's impossible for certain data structures to encapsulate behaviour, which may lead you to make choices towards those that can (e.g. a class vs a struct).
Complexity of data structure. Does the object that the Attribute refers to need to encapsulate complex data structures? (e.g. multiple, possibly hierarchical, data of various primitives and/or complex types) Or is it simple? (e.g. a single integer value). Again, complexity in structure will limit how you can represent it.
What are the non-functional requirements of your system? (e.g. performance requirements?) NFRs like performance, scalability and security may constrain your design choices, so that you might choose to represent complex types in simple ways or eliminate behavioural needs etc..
Does the design choice help you or hinder you? There's no point in representing something in an overly complex way that hinders your work or the system.
Audience. This is possibly the most important point -- who are you putting the domain model together for, and what are you trying to communicate to them?
So, for example, you could represent "Weapon" as an attribute typed as a class or using a simple type. Does "Weapon" have behaviour of its own? Does it contain multiple complex data? Is there a NFR that means it can only really be treated as an enum? And so on.
Sorry for this newb question, i'm new to UML.
The diagram for a system is this one:
From what I know of UML, none of the classes in this diagram can own instances of the associated class as there's no aggregate relationship with it.
Does this mean in an implementation of the system in Java, based on the diagram, an outside class has to own instances of the associated class?
Sorry if the answer is obvious. I've spent hours scratching my head over it.
First off, terminology. #Daniel is right, you don't have an association class. However, I don't think you mean Association Class:
Does this mean in an implementation of the system in Java, based on the diagram, an outside class has to own instances of the associated class?
If I understand correctly that's the nub of your question. In implementation terms, which class(es) have a member variable containing a list of references to instances of Associated Class?
Again - if I understand right - your question stems from the following logic:
In UML, "ownership" is commonly described as a quality of Aggregation (or Composition) relationships.
The relationship between Aggregated/Composite PART Class and Associated Class is a simple binary association - not Aggregate/Composite.
Therefore the "ownership" property doesn't apply
Therefore who owns the list of references to Associated Class instances?
If that's right then the issue is with the specific meaning of "ownership". Whilst not tightly defined in UML, "ownership" typically means responsibility for managing full lifecycle.
I think you're interpreting it more generally: that if an association isn't aggregate, then the participating classes can't hold references to each other.
That's not the case. It's perfectly reasonable for Aggregated/Composite PART Class to hold a reference (or list of references) to instances of Associated Class. The inverse is equally valid. In some cases both are valid (with the attendant need to maintain consistency).
So in summary: is it necessary for an outside class to own the instances of Associated Class? No. It's perfectly valid for either or both ends of a binary association to manage instances of the relationship.
hth and apologies if I misunderstood your question.
PS: a final observation: be very careful about what you mean when using Aggregation. It's notoriously imprecise in the UML spec. Composition has a more rigorous definition, and you can cover 99% plus of all modelling scenarios using Composition and plain Binary Associations. About the only place Aggregation has a well-defined meaning not completely covered by the other two is denoting when recursive relationships must be acyclic.
UML does not specify the full behaviour of a system. So what do you mean, when you say an object owns another object? Also instances AssociatedClass could be root objects that are not owned by any other object.
The diagram you provided doesn't really contain an association class. The class you named 'associated class' is just a normal class. It also isn't owned by anything (that we see in the diagram).
If what you had in mind was association class, then take a look at example diagram with association class:
In this example, the MilleageCredit is an association class. So for each distinct combination of Fligh-FrequentFlyer there is one MilleageCredit.
As for ownership, since the Association class represents a relation between 2 associated objects, it gets deleted when
the association is cleared
either or both of associated objects are deleted
So if you delete either the Flight or FrequentFlyer the MilleageCredit will be gone too.
Also if you unlink Flight from FrequentFlyer again the MilleageCredit will be delete.
There's plenty of good UML docs online, for example UML basics: The class diagram
Hope this helps, otherwise please provide more info in the question.
Are there any tools out there that let you model how a class (or a class hierarchy) can change at runtime? For example, if I have a given number of mixin classes that will be combined at runtime and I don't know which ones will be combined until the program runs, how do you go about diagramming that type of runtime behavior?
Here's a better example. Let's say that I have a base class called IceCream, and I have over 100 possible flavors that all derive from that one IceCream class. Let's also suppose that any instance of the IceCream class can be combined with another instance of the IceCream class to create a completely unique IceCream type altogether. Given this domain, how do you use a graphical model to actually say that any one of these types can be combined at runtime?
It would be inefficient to model all the possible combinations of IceCream types, given that there can be a virtually infinite number of permuations for these 100 IceCream types. So again, here's the question: Are there any graphical modeling languages that let you specify this sort of behavior?
Your design sounds a little disturbing. If two different ice creams have different behavior, then why is it wrong to model all the possibilities? Where are you loading the behaviors from? It very well could be the case, but if so I'd guess that you want to contain the behavior instead...
If they don't have different behaviors, then all you are talking is a class "IceCream" with a "Flavor" member. Never create a second class when the only difference is data--the code must actually differ in the two cases to warrant different classes.
If I totally missed something I apologize.
Edit: Let me be more specific about "Containing behavior". If each of your ice-cream flavors had a "Taste" (which is code) and the taste is different between Vanilla, Strawberry and Chocolate--then you have 3 "Taste" ice-cream classes that are contained in one "Cone" class.
The Cone class would be what I think you are trying to model as "IceCream". Since the cone contains all three, a "Lick" method can combine those three in any way possible. Either you can lick(bottom), lick(middle) or lick(top), or you can just lick() and allow the lick method to combine all three into a single call (to be more real-code, you might pass a single variable to lick() that would be forwarded to all contained flavors).
I wonder if the personal db approach of Bento or DabbleDB could be relevant for the actual modelling part. Then maybe the Django admin's model introspection for the logic part. Sounds like you want to create an interface to a scripting language. A kind of vpl library. So, a beefed up and more reflective Django admin might be a starting point.
In general, if you want to create UML class diagrams you can exploit Generic Types in UML. Also, there is the concept of Template Parameters in UML.
Have a look at this site: Defining Generics with UML Templates
They use the Eclipse Modeling Framework as a tool.