I have 3 classes:
product
product_list
and customer
The product_list class has an array list, which stores product objects.
If I have a viewProduct method, it should belong to customer class or product_list class?
With my own concept, a viewProduct method should belong to customer class, because customer views products. But in code-wise, how a method in customer class gets data from product_list class?
A class is a data structure, bound together with the algorithms working on it.
Thus, if you decide where to put a method, the rule of thumb is this: select the class, on whose data structures it works the most. If you do it well, it should not even access the data members of other classes directly, only their methods.
Also from the name of the method is it visible, that you are right, that viewProduct should belong to customer: if it would belong to a product, then the viewProduct name would be redundant. Then a view name would be better.
You example does not say anything, how customers relate to specific products. For example, if you would develop a webshop, then the customers would likely choose a product from a list which your controllers generated for them.
Your specification lacks the mechanism, how customers relate to products. Think on it, and you will know the answer.
Related
Hi, I have recently started to learn system analysis and design and am having some trouble understanding domain model class diagram (DMCD) association class.
As per image, when drawing the DMCD, I'd like to understand if an association class is allowed to contain attributes of the classes it derives from. The Invoice needs to contain the attributes apptNo and svcName.
Association class inquiry image:
Do I include the attributes as shown in the image?
Or do I assume that the Invoice would already have these attributes because it is derived from Appointment and Service and that it is not necessary to include them as they can be referred back to the keys apptNo and svcID?
I am confused about the concept. How should I present the association class?
Can someone please provide some guidance?
Thank you.
As already pointed out by Geert Bellekens in his comment above, you don't repeat any of the attributes of the classes involved in an association class in the association class. You only include attributes that specifically characterize the links classified by the association class.
In your example, you should only include attributes that are specific for Invoice links, such as invNo, invDate and totalPrice.
This rule holds independently of the kind of class diagram (domain/design/implementation model).
However, your model is only good for invoices refering to one appointment and one service. It does not account for invoices concerning one appointment, no matter how many services it includes. In a model for this business logic, Invoice would no longer be an association class, but an ordinary class associated with Appointment. This would allow it to access each service included in an appointment and turn it into an invoice line.
To make it short:
is (sort of; please read the comments below) an alternative notation for
which means that Class3 already has associations to both Class1 and Class2. So there's no point in adding attributes of the latter in the association class. If you're on a DB level you eventually introduce redundancy for performance reason at the cost of violating the principle of single source of truth. But that's another story.
It depends.
A domain model class diagram models the concepts found in the domain, i.e. the part of the real world relevant for your project. In the classes, you only include attributes that are indicated by domain experts or by other sources describing the domain.
I will assume that a domain expert knows what an appointment number and a service name are. If these were just technical data, they should not be attributes of Appointment and Service in the first place. To determine whether these attributes should also be included in Invoice, you need to ask domain experts what they think. Does an invoice always include an appointment number and a service name? Only if the domain expert says "Yes", I would model them as attributes of Invoice.
(To double check, you could ask "Is it also valid to say that the appointment number is not part of the invoice, but that the invoice is somehow associated with an appointment having a particular appointment number?")
Maybe the domain expert says an invoice does not contain the appointment number or the service name, because the corresponding Appointment and Service are always associated to the Invoice as attachments or hyperlinks or otherwise. In that case, the fact that Invoice is an association class on the association between Appointment and Service is enough. You don't have to include attributes of these classes in Invoice. These will probably be added later, when the domain model class diagram is turned into a system model class diagram or database model class diagram.
I know this is an opinionated question. However it comes up often at work.
When creating methods it's often a struggle to know which class should be responsible.
e.g.
bool result = ProductService.CategoryHasSoldOutOfProducts(int categoryId)
vs
bool result = CategoryService.CategoryHasSoldOutOfProducts(int categoryId)
In my opinion, the CategoryService should be responsible, as the method is taking a categoryId and is specific to the Category.
Others at my work say the ProductService should be responsible as the method is dealing with if Products have sold out.
Just trying to develop a better understanding of service architecture and good process. I'm interested in other peoples explanations for why they would choose one over the other.
Thanks
Disclaimer - this is a purely IMHO answer. I am answering this in the spirit of having a design brainstorm.
Based on the OP, it seems the relationship between Category and Product is an optional one to many : Category (0..1) <--------> (*) Product.
Implementation wise, this means that the Category entity probably has a Container of Products, and the Product entity has a reference to a Category which may be NULL.
In this case, I agree with the decision to place CategoryHasSoldOutOfProducts under the responsibility of the Category entity. The method name clearly implies that the Category entity should be responsible for informing its API user on the status of its products.
There is another option, however: An association class/entity. The motivation behind this entity is to describe the relationship between two other entities.
In this case, you can have a functional association entity which we will call ProductContainment for the sake of this example.
ProductContainment will have no internal state, and will hold functions which are provided with Category and/or Product entities as parameters.
It is then the responsibility of the association entity to provide the implementation of functions which relate to how Category and Product relate to one another.
If you end up using ProductContainment - then CategoryHasSoldOutOfProducts should be one of its functions.
Since you're asking for opinions, here is mine:
(Disclaimer: That's probably something you cannot easily implement in the business world)
As you are using the term "class", I assume you want to have something object-oriented. The problem is, a service is nothing a valid object could be created from. Instead, it's just a namespace for functions.
Additionally it's very general. It's like calling a class "Manager". You can put possibly everything inside of it and this class has the potential to grow to have hundreds of functions.
My advice: Create small entities. Small enough to be created without the use of any setters, just by calling the constructor. If you notice your object needs more functionalities, create a decorator that is a little bit smarter and can do the work for you.
I would need a few more details about your environment to be more precise, but I guess in your case, you would have something like a Category class that contains products and knows when it's sold out. Just imagine you have a team of persons and everyone knows something. Ask the right guys to do the stuff and stay away from managers or services.
So I am working on this class diagram, I do get the idea that we need to implement observer pattern with order and customer class, however I couldn't understand what is the best possible way to maintain a relation between order queue ,staff and orders.
Original Question
A simple web application that allows customer to place orders select one or multiple items. As soon as the customer proceeds and confirms the order, The order get enlisted in the order Queue. Customer gets a confirmation for the order that he/she has place and mean while staff also gets notified for the new order via GUI of system.
The Class Diagram that I have so far
You have different observers i-e Customer and Staff member. So you will be having Staff and Customer as subclass of Observer.
Subject is Order. Whenever an order is placed/updated, you go through list of observers and notify them. So your diagram is correct where Order is subclass of Subject.
The orderItem can be of different type. You should inherit different subclasses from parent "Item" class.(You are currently inheriting items from Gift Item".
There should be an aggregation relationship between "Item" and subject.
I have a base class Participants inherited by Artist, Author and TextWriter.
I have only one table in the data store:
Participants {
ID,
FirstName,
LastName,
IsArtist,
IsAuthor,
IsTextWriter,
}
The idea is to have a class for all the roles that a participant can have.
I've managed to create the edmx file but when I try to get an Participant (as Artist) that is also an Author I receive the following error:
All objects in the EntitySet 'Participants' must have unique primary keys. However, an instance of type 'Artist' and an instance of type 'Author' both have the same primary key value, 'EntitySet=Participants;ID=1'.
Thank you
Yes, this is possible. What you're asking for is "table per hierarchy" inheritance. Your table needs to contain any "discriminator column" which identifies the type of each row.
However, no record for one person can have more than one concrete type when materialized (read from the DB), because an object can only have one type. I've written about this issue before:
One of the mental barriers that you have to get over when designing a good object relational mapping is the tendency to think primarily in object oriented terms, or relational terms, whichever suits your personality. A good object relational mapping, though, incorporates both a good object model and a good relational model. For example, let’s say you have a database with a table for People, and related tables for Employees and Customers. A single person might have a record in all three tables. Now, from a strictly relational point of view, you could construct a database VIEW for employees and another one for customers, both of which incorporate information from the People table. When using a one VIEW or the other, you can temporarily think of an individual person as "just" an Employee or "just" a Customer, even though you know that they are both. So someone coming from this worldview might be tempted to do an OO mapping where Employee and Customer are both (direct) subclasses of Person. But this doesn’t work with the data we have; since a single person has both employee and customer records (and since no Person instance can be of the concrete subtype Employee and Customer simultaneously), the OO relationship between Person and Employee needs to be composition rather than inheritance, and similarly for Person and Customer.
If "Bob" is a Participant who is both an Artist and an Author, then he cannot be of type, say, Artist and Author at the same time, unless one is a supertype of the other. Either Artist and Author should have a subtype relationship with the other or you should use aggregation rather than inheritance to relate Participant with Artist and Author. An instance of an object can have only one concrete type; this does not change because you store it to the DB.
I am trying to draw a domain model or class diagram in UML for car dealership. I am stuck with how to present test drive in the model. One way is to have appointment class and then test-drive as sub class. A dealer also offers after-sale vehicle service so i could have appointment/booking class as super class and then vehicle service and test-drive as two sub classes.
Another way is to have the customer class have a direct relationship with test drive class and vehicle service class under appointment class.
A dealer also sells new and used cars and their parts.
A dealer also offers finance for car sale.
Would testdrive class have relationship with vehicle class or there is separate class for display and testdrive class?
Another question is how do I show potential customers and their inquiries about sale and service in the model. A dealer wants to save details of potential customers if they allow for marketing purposes. Shall I have two classes: one for customers and one for potential customers or it can be achieved just by using an attribute in customer class?
You can really only distinguish the right decision by having a good set of use cases or expected behaviors of the model.
This will inform whether a particular sub-classing is really accurate.
I can see that an appointment might contain several test-drives, which are themselves linked to individual vehicles, So a test-drive itself is nothing more than a link from a customer to a vehicle which are linked to an appointment.
test-drive would contain the information relevant only to the test-drive:
reference to the customer - even this might be debatable to include
reference to the vehicle
length of test drive
location (perhaps the vehicle was driven at a different location than could be determined from the owning appointment)
customer temperature (hot or cold - i.e. did the customer seem enthusiastic)
comments
etc.
But what is not in the test-drive object is anything related to the appointment - since it is always contained in a collection - possibly as part of an appointment or some other event container. Now if the containers which can contain test-drives always include customer information, I might not even include the customer reference in the test-drive object - after all, it will be redundant.
It depends if test-drives can occur in non-appointment scenarios - perhaps at a "sales event" or an "open house" or something where appointments are not actually created in the use cases - or if test-drives for multiple customers will occur within a container.
The second part of your question has been forgotten (easily done when you ask two questions in one):
Another question is how do I show potential customers and their inquiries about sale and service in the model. A dealer wants to save details of potential customers if they allow for marketing purposes. Shall I have two classes: one for customers and one for potential customers or it can be achieved just by using an attribute in customer class?
I think your use case there is "A dealer wants to save details of potential customers if they allow for marketing purposes." and the simplest solution is to have a Mailing List collection which holds name and address of each potential customer.
I think you miss the point. The aim of the domain model is make famliiar you with the domain:
-- What kind of entities you have in yor domain?
-- If they are important for your system under desing,
what kind of properties they have, how they behave?
-- What kind of business rules they obey?
The rest is details. Think like a map maker. Record what there is.Create a simple map so you can not lost your way in that domain. Not try to invent.Abstract what exist in the domain: Not run behind the "fancy abstractions" you created yourself.
Domain model can be used as a source
for object oriented analysis/design.
But their aim is not to represent
software abstractions.