I am learning UML and I've focused on a Netflix-like project on which to practice on.
I've put together a class association diagram, but have been told that the multiplicities are incorrect. The multiplicities in red represent what I think they should be changed to.
Could someone please offer some clarity of where I have gone wrong?
Please, ask any questions that would help gain a fuller understanding of the diagram in reference to the project.
Thanks in advance.
Movie Catalog - User: The 0..* multiplicity is correct. There can be an arbitrary number of users and not only a single one. That would only work if that Netflix was made for a very single person. And that would be pointless, I guess.
Movie - Membership - Member: This represents an association class for the user to track payments (and access, etc.). So it must be the 1, not 0..*. The stream is sent for that single Membership where it is accounted. An association class has a n-1-1-m relation.
In your model it looks like this:
And from my POV it is:
since the Membership is just used to control access to the movies. It is arguable whether there is only a 1-1 relation and not a (preferable) m-1 relation between Member and Membership.
Related
I have an assignment for school where I'm asked to represent the system of a company that I am to upgrade with a domain model and draw a conceptual class diagram with the four most important use cases of the system. I don't really understand the difference between the two, can someone help me ?
In short
Domain model and a conceptual mean different things to different people. There is no universal authoritative definition of these terms.
Nevertheless, objectively a domain is more than interrelated classes. If we consider that conceptual means independent of any solution implementation, we can claim that a conceptual class diagram is a subpart of the domain model.
Some more arguments
A domain model describes the elements of the real word for which a software shall provide a solution.
For example, for a real estate application:
you’d have “business objects” such as real estate assets (houses, flats, …), owners, tenants, sellers, buyers, agents, contracts, payments, geographical regions, etc.
But you would also have domain logic, such as the lifecycle of things: at first a party can be a prospect for an asset, then an interested prospect after a visit, then a tenderer if a bid is submitted, the. a buyer if the bid is accepted. The domain model can also describe business rules, e.g. if a tenderer proposes a price below the price demanded by the seller, the agent has to insure agreement of the seller before continuing negotiations.
DDD practitioners would also remind us that domain entities and aggregates (the things) are related to domain events that express what happens to entities and aggregates.
Hence, a domain is more than interrelated classes. If you’re bot convinced, imagine a Model-View-Controller application where the Model would ignore the business logic: would it be useful?
The term “conceptual” means something abstract that is independent of any concrete implementation. In this regard, a conceptual class diagram refers in principle to a diagram of classes that describes the domain, independently of any concrete/implementable solution.
As a consequence, a conceptual class diagram in UML only describes a static subpart of the domain model. Because by construction, the class diagram is designed for representing the static structure of classes. UML foresees other diagrams to describe the dynamic aspects of a system or its domain, such as activity diagrams, sequence diagrams or state diagrams, that allow to focus on some dynamic parts of the domain.
So a conceptual class diagram can only be a part of the domain model.
You’ll nevertheless find articles and peers who use the term “domain model” to refer to the “model of the entities of a domain”. This is a misleading shortcut in the language.
Hi I am new to graph database modeling and have some doubts about expressing an endorsment for a service provided by a Person. The use case is the following. PersonA gives Endorsement to a Service provided by PersonB.
The key point is that If I am recipient of the endorsment, I would like to know who has endorsed me. I have come up with several scenarios on how I could potentialy do that, but because of my lack of experience I have doubts on what would be the best aproach.
Scenario 1.
Endorsment is expressed direcly as a relationship and the service falls as a property under the endorsment So it will look like:
PersonA-------ENDORSE{service}--->PersonB
Scenario 2
I model an entity named Service. The problem is that when I do the relationship "ENDORSE" to service I would loose information on who am I endorsing. So I would have to keep a property in the relationship on who am I endorsing. Then the PersonB would AQUIRE endorsment for the SERVICE but he would not know who has actualy givern the endorsment. So..... it will look like this:
PERSONA----ENDORSE{personB}--->Service------ENDORSMENT{personA}--->PERSONB
Does this make sense ?
Scenario 3:
I normalize the second relationship "ENDORSMENT" and exclude the personA as a property , but than I need to query all Person to find out who have they endorsed.
How would you model this kind of relationship ?
Two important principles for validating a data model for a graph database:
if an entity or fact can be used more than once, then it should be stored
as the node
if the relationship of two nodes requires to store node
identifiers, then this relationship must be transformed into a node
So #Raj pointed the right way, in which case the model might look like this:
I recommend you read this:
https://neo4j.com/graph-databases-book/
http://patterns.dataincubator.org/book/
The second approach looks good, you don't have to add these properties on relationships.
It's possible to get person A who endorsed person B for service S.
The only issue with this is there will be multiple nodes for any service S. If that's not acceptable.
You can replace the Service node in the second approach with Endorse node E and connect this E to service node S.
So there will be four types of nodes.
EDIT:
Adding an image for clarification.
Rename REL1 and REL2 as you wish.
#Stdob suggested some good names for these relationships.
There is one example to explaining associations in UML.
A person works for a company; a company has a number offices.
But I am unable to understand the relationship between Person, Company, and Office classes. My understanding is:
a company consists of many persons as employees but these classes exist independently so that is simple association with 0..* multiplicity on Person class' end
a company has many offices and those offices will not exist if there is no company so that is composition having Company as the parent class and 0..* multiplicity on Branch class' end.
But I am not sure of 2nd point. Please correct me if I am wrong.
Thank you.
Why use composition or aggregation in this situation at all? The UML spec leaves the meaning of aggregation to the modeler. What do you want it to mean to your audience? And the meaning of composition is probably too strong for this situation. Thus, why use it here? I recommend you use a simple association.
If I were you, I would stay truer to the problem domain. In the world I know, Offices don't cease to exist when a Company goes out of business. Rather, a Company occupies some number of Offices for some limited period of time. If a Company goes out of business, the Offices get sold or leased to some other Company. The Offices are not burned to the ground.
If you aren't true to the problem domain in an application, then the shortcuts you take will become invalid when the customer "changes the requirements" for that application. The problem domain doesn't actually change much, just the shortcuts you are allowed to take. If you take shortcuts to satisfy requirements in a way that are misaligned with the problem domain, it is expensive to adjust the application. Your customer becomes unhappy and you wind up working overtime. Save yourself and everyone the trouble!
While Jim's answer is correct, I want to add some extra information. There are two main uses for aggregation
Memory management
Database management
In the first case it gives a hint how long objects shall live. This is directly related to memory usage. If the target language is one which (like most modern languages) uses a garbage collector, you can simply ignore this model information.
In the second case, it's only partially a memory question. A composite aggregation in a database indicates that the aggregated elements need to be deleted along with the aggregating element. This is less a memory but in most cases a security issue. So here you have to think twice.
A shared aggregation however has a very esoteric meaning in all cases.
I am having issues during a ProcessUpdate on a SSAS dimension. Here is, albeit simplified, how the dimension is set up:
In a "Reservation" dimension, I have my DimensionKey attribute set to be the reservation itslef (Key attribute: ReservationKey, Name Attribute: Reservation Code). To that member is attached (flexible Relationship) a "ReservationAgent" Member (Key: ReservationAgentCode, Name: ReservationAgentName) and to the "ReservationAgent" member, I have "ReservationAgentCode" member which is related by a rigid Relationship to the "Reservation Agent Name".
Now I'm sure you'd agree with me that it is impossible for the "ReservationAgent" to suddenly relate to a different "ReservationAgentCode" since the key of both attributes is the SQL column "ReservationAgentCode".
I have come in a situation where all Reservations of a given ReservationAgentCode were moved to a different ReservationAgentCode. so in essence, the old ReservationAgentCode is now non-existent. Remember here that "Reservation" and "ReservationAgentCode" Relationship is flexible.
Upon doing a ProcessUpdate on the dimension, SSAS gives me an error about not being able to change a rigid relationship between "ReservationAgent" and "ReservationAgentCode".
Since both the "ReservationAgent" and "ReservationAgentCode" members are effectively new, there is no movement of the old "ReservationAgent" to a different "ReservationAgentCode". Only the old members need to be deleted in a sense.
Has anyone come to that kind of situation? Is it something i'm not quite understanding correctly? To me it seems like a glitch/bug but before open a connect ticket at MS, i'd like to have feedback from the experts here.
Let me know if you need more info and I could also elaborate a quick solution demonstrating my issue if needed.
Thanks in advance!
It's not a bug, David.
Process Update removes the old ReservationAgentCode member from dimension (since on stage of members detecting doesn't see it in source). Server won't allow this deletion, since we have rigid relation later ("rigid attribute relationship is one where the member relationships are guaranteed to be fixed" - performance guide 2008 r2).
By the way, what is the benefit of using rigid relations there (performance / process time / both)?
As i read through software engineering appendix 1 from Roger Pressman book that
an association between two classes means that there is a structural
relationship between them
what structural relationship means?
UML differentiates 'structural' and 'behavioural' models. Class Diagrams, Package Diagrams and a few other capture the structural aspects. State/Sequence/Activity Diagrams capture behavioural aspects.
'Structural' means it holds over time. For example, the association between Order and OrderLines ("Order consists of 1 or more OrderLines / OrderLine is part of exactly one Order"). Or Dog and Person ("Dog is owned by exactly one Person / Person owns many Dogs"). Used well, Associations capture invariant rules from the problem domain. To use the Dog example: the association says a Dog can't ever be owned by more than one Person at any given time. Doesn't matter if the Dog is running, sitting, or eating: it must have exactly one Owner. Note also the owner could change over time: but there can never be more than one at any point.
An alternative is to think of Associations as the kind of thing that might be captured using foreign keys in a relational database.
hth.