I am currently learning to create uml diagram, especially class diagram and have some multiple difficulties understanding some concept in the process, here is the question
Does multiplicity always 2 sided? like when i have this classes, PP class is the buyer Class, and Cart is the class to save the buyer order info, i assign 1 - 1 multiplicity because 1 buyer would always have 1 cart vice versa, in Cart it is clearly defined (in my code) that i have a variable with type PP, but inside class PP there is no cart variable at all, so does the multiplicity wrong? should i just assign 1 sided multiplicity in PP and have none in Cart? or does having the variable inside class is not important? i am quite confused on understanding this
About dependency relationship, if i have this PP class which have variable shippingAddress inside the class and using data type ShippingAddress as parameter in some of the function, should i used dependency relationship or association
Thanks a lot
qwerty_so already provided a concise and accurate answer. Nevertheless, I'd like to add some more thoughts to complete the picture.
1
In an association there are always at least 2 sides, and there is a multiplicity on each side: The first diagram says that a PP always has 1 Cart and the Cart always 1 PP. If you meant "sometimes" instead of always, change it to 0..1
There can be more than 2 sides in an n-ary association: Then you'll have n multiplicities.
WHen in a diagram there is no multiplicity indicated on one side, it doesn't mean that there is no multiplicity, but that we don't know what the multipliity is (or that it's not important for what we want to show in the diagram).
Now your question about multiplicity and how to implement it raises another topic:
it is clearly defined (in my code) that i have a variable with type PP, but inside class PP there is no cart variable at all, so does the multiplicity wrong?
It's the question of navigability: If in the implementation of Cart you have a PP variable, this means that you can easily navigate from the a given Cart to the associated PP. If you don't have a Cart variable in the PP implementation, it is difficult to find the corresponding Cart, so it's not navigable. Navigability is shown with an open arrow.
Multiplicity and navigability are two orthogonal concepts.
2
If you have both a dependency and an association, you'd usually show the association. There is no need to also show the dependency, since it is implied by the association. However it's not wrong if you want to show both (but with a dashed line and open arrow) (for example, if you want to add some explanatory comments for each).
Now if in the PP implementation you have a ShippingAddress, it's not only a question of navigability, but it's also a question of ownership of the association end. So you can use the dot notation on the side of the ShippingAddress.
If you don't have an association, but use another class as parameter or return type of an operation, then you may want to show s simpe «use» dependency.
Multiplicity is defined where needed. If it's not given then it's undefined and could be anything from zero to infinity. It depends whether you define that. One reason is simplicity, if you want to just show "it's associated". For a complete model (if that is needed) you have to specify multiplicities at all edges.
Dependency is just a weak relation. If you use some class only in parameters or as pass-through you use a dependency relation. Your 2nd picture would be wrong as you should draw the dependency (dashed line with open arrow) downwards since PP uses/depends on ShippingAddress and not the other way around.
Related
I'm having a pretty hard time trying to figure out how to model a certain scenario as a UML design class diagram.
Suppose I have the following situation:
I have a class named CPoint that has two attributes: x and y (coordinates in a R2 plane). Additionally, I have a class named CLine that should have two CPoint as attributes.
This is pretty straight forward to code (I'll use C++ in my example):
class CPoint{
float x;
float y;
//Constructor, gets and sets here
}
And for CLine:
class CLine{
CPoint p1;
CPoint p2;
//Constructor, gets and sets here
}
Now my question is: How do I model such a thing in UML?
I thought of something similar to this:
But then I was told that this is violating the principles of object oriented modeling, so then I did this:
But it does not convince me at all. Additionally, I was reading about design patterns and came to this UML design while reading about singletons:
Which makes me think my initial approach was just right. Additionally, I'm able to see that my first approach is just alright if I think about it as a C++ program. In Java, however, I'd still have to create the object by doing new CPoint(0, 0) in the CLine's constructor. I'm really confused about this.
So, how do I model this situation? Am I perhaps being too concrete when I attempt to model the situation?
Thanks in advance! This isn't letting me sleep at night
In UML an association or an attribute (property) are more or less the same thing, so they are both correct.
In most UML tools however they are different things.
There is not really a rule here, but there are best practices.
My UML Best Practice: Attribute or Association says:
Use Associations for Classes and Attributes for DataTypes
If your CLine has exactly two ends represented by point, than you can define it in UML as class CLine with attributes (just like your CLine on the first example is OK but without association "has") or you can design it as CLine class with two association to CPoint. Multiplicity at CPoint will be 1 with role p1 for the first one and p2 for the second one at the CPoint side.
There is not one best solution. It depends on the context and what you want to model. I agree with Vladimir that you would have two relations with roles p1 and p2. The members x and y should be private I guess (-x, -y) and not public (+x, +y). Furthermore you could model the relation as aggregate or composite (open or closed diamond symbol) but if a single point can be the endpoint of two lines then that is not appropriate. Again, this depends on what you want to model. If construct a new point in the line constructor as stated in the question, then you probably want to use a composition relation as these points do not exist without the line.
(Btw, in the code the coordinates are float and in the diagram ints).
REST seems to focus most on collections of resources -- lists of things. How should one model something that exists exactly once in a system? And more specifically something very simple. Suppose the modeled system is a classroom, which has students, 1 teacher, and a door that is either open or closed. How would one model the door? I'm thinking it would be something like the following:
GET and POST operations are supported.
GET https://<ipaddress>/classroom/door_status
Returns 200 if successful, with a response containing:
DoorStatus - String - Value of door status, either "Open" or "Closed"
POST https://<ipaddress>/classroom/door_status
Specify the attribute of:
DoorStatus - String - Value of desired door status, "Open" or "Closed"
Returns 201 if the status was successfully modified.
DELETE would always fail.
A classroom could of course have multiple doors, but bear with me for the moment. And of course a building with classrooms often has multiple classrooms. Again bear with me.
Next, we might add a light_status resource for the classroom. Given this is likely, should we start with a "global_properties" resource, which would have DoorStatus and LightStatus properties instead.
Thanks for suggestions, help, or (especially) examples. ...Alan
I don't think there is anything in REST that makes single instance entities illegal or undesirable. That said, in your particular example, you need to evaluate if the door and the light:
Are their own entities related but otherwise independent from the class, OR
Are just attributes or contained objects of the class without their own identity and whose existence depends on the existence of the class
the second option is the one that seems more reasonable to me. If we accept it, then you can return the light and door status as part of the class properties:
GET /class -- Returns the class attributes, including light and door status
PUT /class -- updates class attributes, including light and door status
According to wikipedia
Dependency is a relationship that shows that an element, or set of elements, requires other model elements for their specification or implementation.[1] The element is dependent upon the independent element, called the supplier.
So is it not the same as unidirectional association?
Do we use dependency when an operation in one class uses object of the other class as its parameter?
How are unidirectional association and dependency different.
Any example would be very helpful
Dependency :
Indicates that a client element(of any kind, including classes,
packages, use cases, etc) has knowledge of another supplier element,
and a change in supplier can effect the client.
So "dependency" is very broad relationship.Suppose that if a class-object(client) has another class-object(supplier) as a member,if a class-object send a message to another class-object,if a class-object takes another class-object as an parameter from its methods, even if a class(client) is subclass of another class(supplier) there will be dependency since change from supplier will effect clients.
Technically all of those relationships can be shown by "Dependency" line. But some of above relationships already has special notations: such as for superclass-subclass relationship we have generalization relationship.No need to show also "dependency" line because if they have generalization relationship, they have dependency. And we have "association" relationship for class-object(client) who has another class-object as a member [attribute]. So also no need to show extra dependency line in this situation.
Actually "Dependency" is badly defined relationship for class diagrams. But it can be usefull for showing dependency in which UML has no special notation such as :
if you has another class-object(supplier) as a parameter in one of your class(client) methods
if you have dependency to global variables
when you call static methods on another classes.
local variables (which you think you have important dependency)
public class RepositoryManager
{
public UpdatePriceFor(ProductDescription description)
{
Time date = Clock::GetTime();
Money oldPrice =description.GetPrice();
...
}
private IList<Item> itemsList = new List<Item>();
}
So all "associations" are also shows "dependency".But "dependency" is
broad-general-weak relationship.As a rule if there is a special
relationship which is more specific-stronger than dependency
relationship than use it. And lastly use all your relationship
"economically". Show only important ones based on modeler-model reader
perspectives.
[ Source : Adapted from Craig Larman's Applying UML and Patterns book ]
Check Fowlers bliki for further information DependencyAndAssociation
Association means that the two associated entities are linked semantically. Dependency only declares that there is a... well, dependency of some sort. All associations are dependencies, while a dependency does not actually mean association. For example, class 'A' depends on class 'B' if it has a method that takes 'B' and passes it as argument to a function in another class. But if 'A' calls some method of class 'B', it should be modeled as association.
Disclaimer I have read the UML specification and also asked myself this question a number of times. I arrived at at the definition above, but I'm still not sure it is 100% correct.
Looking inside the runtime.h, I found the definition of the structure objc_class.
Among various members, We have this :-
struct objc_method_list **methodLists
We definitely need to know what all methods a class has,
But a list of methods should be fine, but why do we have "lists" ?
Why not just one list ?
Also, can anyone specify that, Are methods inherited from superclass part of that list or we get to them via superclass pointer that points to parent class's structure.
Here is my detail investigation into struct objc_method_list **methodLists : http://blog.csdn.net/jasonblog/article/details/7303618
And in short, methodLists stores SEL-IMP mapping of the instance methods by default. In this situation, it has only one list.
As the name 'methodLists' suggests, it can contain more than one list. If you add a category to a class, the runtime system will insert one more list into methodLists, which points to the method-list of the category.
I tried to answer this question several months ago, but at that time SO discard my answer due to network problem. Now I meet it again :)
The purpose is explained in objc-class.m, as linked by Georg:
cls->methodLists may be in one of three forms:
NULL: The class has no methods.
non-NULL, with CLS_NO_METHOD_ARRAY set: cls->methodLists points
to a single method list, which is the class's only method list.
non-NULL, with CLS_NO_METHOD_ARRAY clear: cls->methodLists points to
an array of method list pointers. The end of the array's block
is set to -1. If the actual number of method lists is smaller
than that, the rest of the array is NULL.
Attaching categories and adding and removing classes may change
the form of the class list. In addition, individual method lists
may be reallocated when fixed up.
Classes are initially read as #1 or #2. If a category is attached
or other methods added, the class is changed to #3. Once in form #3,
the class is never downgraded to #1 or #2, even if methods are removed.
Classes added with objc_addClass are initially either #1 or #3.
The short answer is therefore "because of categories." When a category is injected, rather than try to combine its method list with the one existing list, a new entry is simply added to methodLists, and set to the list coming from the category. This probably makes category injection faster, since it avoids (potential) large reallocations and copying.
Portfolio A → Fund 1
Portfolio A → Fund 2
Portfolio A → Fund 3
I couldn't frame my sentence without not using is/has. But between 1 & 2,
1) has a:
class PortfolioA
{
List<Fund> obj;
}
2) is a:
class PortfolioA : List<Fund>
{
}
which one do you think is better from the point of extensibility, usability? I can still access my funds either way, albeit with a small syntactical change.
I vote with the other folks who say HAS-A is better in this case. You ask in a comment:
when I say that a Portfolio is just a
collection of funds, with a few
attributes of its own like
TotalPortfolio etc, does that
fundamentally not become an "is-a"?
I don't think so. If you say Portfolio IS-A List<Fund>, what about other properties of the Portfolio? Of course you can add properties to this class, but is it accurate to model those properties as properties of the List? Because that's basically what you're doing.
Also what if a Portfolio is required to support more than one List<Fund>? For instance, you might have one List that shows the current balance of investments, but another List that shows how new contributions are invested. And what about when funds are discontinued, and a new set of funds is used to succeed them? Historical information is useful to track, as well as the current fund allocation.
The point is that all these properties are not correctly properties of a List, though they may be properties of the Portfolio.
do not 'always' favor composition or inheritance or vice-versa; they have different semantics (meanings); look carefully at the meanings, then decide - it doesn't matter if one is 'easier' than the other, for longevity it matters that you get the semantics right
remember: is-a = type, has-a = containment
so in this case, a portfolio logically is a collection of funds; a portfolio itself is not a type of fund, so composition is the correct relationship
EDIT: I misread the question originally, but the answer is still the same. A Portfolio is not a type of list, it is a distinct entity with its own properties. For example, a portfolio is an aggregate of financial instruments with an initial investment cost, a total current value, a history of values over time, etc., while a List is a simple collection of objects. A portfolio is a 'type of list' only in the most abstract sense.
EDIT 2: think about the definition of portfolio - it is, without exception, characterized as a collection of things. An artist's portfolio is a collection of their artwork, a web designer's portfolio is a collection of their web sites, an investor's portfolio consists of all of the financial instruments that they own, and so on. So clearly we need a list (or some kind) to represent a portfolio, but that in no way implies that a portfolio is a type of list!
suppose we decide to let Portfolio inherit from List. This works until we add a Stock or Bond or Precious Metal to the Portfolio, and then suddenly the incorrect inheritance no longer works. Or suppose we are asked to model, say, Bill Gates' portfolio, and find that List will run out of memory ;-) More realistically, after future refactoring we will probably find that we should inherit from a base class like Asset, but if we've already inherited from List then we can't.
Summary: distinguish between the data structures we choose to represent a concept, and the semantics (type hierarchy) of the concept itself.
The first one, because you should try to favour composition over inheritance when you can.
It depends whether the business defines a Portfolio as a group (and only a group) of funds. If there is even the remote possibility of that it could contain other objects, say "property", then go with option 1. Go with option 2 if there is a strong link between a group of funds and the concept of Portfolio.
As far as extensibility and usefullness 1 has the slight advantage over 2. I really disagree with the concept that you should always favour one over the other. It really depends on what the actual real life concepts are. Remember, you can always^ refactor.
^ For most instances of always. If it is exposed publicly, then obviously not.
I would go with option (1) - composition, since you may eventually have attributes specific to the portfolio, rather than the funds.
The first one, because it is "consists of". => Composition
I will differ with what appears to be the common opinion. In this case I think a portfolio is very little more than a collection of funds... By using inheritance you allow the use of multiple constructors, as in
public Portfolio(CLient client) {};
public Portfolio(Branch branch, bool Active, decimal valueThreshold)
{
// code to populate collection with all active portfolios at the specified branch whose total vlaue exceeds specified threshold
}
and indexers as in:
public Fund this[int fundId] { get { return this.fundList[fundId]; } }
etc. etc.
if you want to be able to treat variables of type Portfolio as a collection of funds, with the associated syntax, then this is the better approach.
Portfolio BobsPortfolio = new Portfolio(Bob);
foreach (Fund fund in BobsPortfolio)
{
fund.SendStatement();
}
or stuff like that
IS-A relation ship represents inheritances and HAS-A relation ship represents composition. For above mentioned scenario we prefer composition as PortfolioA has a List and it is not the List type. Inheritances use when Portfolio A is a type of List but here it is not. Hence for this scenario we should prefer Composition.