Entity relationship modelling, comment on my ERD - uml

Note: Due to low reputation I can't post images so i have added the links accordingly.
I have this assignment I'm working and I am stuck in a recursive relationship, following is part of the case scenario that I am currently modelling;
Now, from the first Three paragraphs i have deducted the following business rules;
Employee is allocated ONE branch and a branch employs ONE or MANY employees
Each branch is designated ONE manager and ONE assistant manager
Employee is managed by ONE manager and supervised by ONE assistant manager
Employee submits ZERO, ONE or MANY previous employment records, a instance of a record is associated to ONE employee only
Employee is assigned ONE job position only, a job position can be assigned to ONE or MANY employees
(note: I have assumed in rule n.2 that a branch is also designated an assistant manager)
And now this is the ERD diagram for the above rules;
So from the scenario, the assistant manager only supervises the staff, but it does not say that it has any relationship with the branch entity, however i assumed that a branch should have a relationship with the the manager and the assistant manager, but i am a bit confused so i havent added it yet to the erd diagram. Can you guys help me out?

Firstly it appears you seem to be drawing a UML Domain model not a ER diagram. These are not the same thing. You've identified an employee but seem to be trying to use it polymophically for all things. This premature optimisation (and for re-use), when you should be following the rules of normalisation of entity relationships. Take a step back, create tables for manager, assistent manager and employee. Add the fields to those, THEN try to normalise.

Related

Limiting Child Objects in Class Diagram

I want to model a simple system using a Class Diagram:
I have 3 possible classes: Company, Employee, Manager.
The Company must have 20 Employees (aggregation?).
The Company must have 1 Manager (aggregation?).
A Manager is an Employee (generalization?).
Each Employee can only be in 1 Company.
In other words, I want to limit this system to have 20 Employees, 1 of which must be a Manager. However ONLY 1 can be a Manager. This would make it so that there are 19 Employees and 1 Manager objects at all times.
I have the setup in my head of how I want this system to work, but I can't get the model quite right. This is what I got:
I feel like I am very close, but my issue is that although the Company 1 to 1 relationship to the Manager seems correct, the 1 to 19 to the Employee seems off. Since a Manager is an Employee, I have no way of limiting how many of those 19 Employees are Managers. I am trying to do this without splitting Employees up into Non-Manager and Manager classes.
Am I on the right track? Is there something I am missing? Or is it clear enough that 19 MUST be Employee objects and 1 MUST be Manager object?
The problem
Your model has a weakness: a Manager of one Company could be Employee of another, because nothing in your model says that the employment relationship with the Company is the same for both classes.
Why? If you apply the UML generalization semantics:
Employee has an association with Company,
Manager is a specialization of Employee, and therefore inherits all its properties, operations and associations, including the association with Company.
Manager has in addition its own association with the Company. So it has two distinct associations: the inherited one and its own one.
Potential solutions
It would be helpful to label the ends of the association, e.g. employer/ employee and company/manager:
The simplest solution could be to remove the association between Manager and Company, since it is inherited. But there is no easy way to tell that there must be a Manager among the employees. Moreover, there wouldn't be an easy way to find the Manager of a Company. So this solution does not appear appropriate.
Another solution would be to add a constraint that specifies that for the Manager, manager.company is the same than employee.employer. Since a Manager manages one and only one company, no other manager could by deduction exist among the employees. But this sounds somewhat artificial.
The best solution in my view is therefore to keep both associations but use UML smeantics to explain that company {subsets employer} and manager {subsets employee} Be aware that this solution requires 20 employees, since it makes clear that the manager is one amont the 20.
If you're interested to know more about subsetting, I advise you this artile about redefinition, specialization and subsetting of associations, which could also inspire you other variants.
Minor remarks
The aggregation are fine. However, aggregation is a modelling placebo since the UML specs clearly say page 110:
Precise semantics of shared aggregation varies by application area and modeler.
Therefore, I'd suggest to avoid them when possible. You could therefore as well use normal UML associations. Especially for the manager where there is only one.
Another remark made by qwerty_so in the comments is that the + should be removed in +has : The + is about public visibility. It’s not the association itself that is public or private, but the association end (e.g. employer and employee in my proposal).

Class diagram for a mini JEE project

I want to start a project in JEE and I need to confirm about my class diagram. I need to know if the methods used are correct and if the composition I used is correct or not.
This is my class diagram:
The project is about an online sales store, that wants to set up a management tool to sell products, and to manage its products. This tool must include the following features:
Identification module: identification of clients, managers, supervisors
Sales module: make purchases for users
Product Management Module: Adding / Deleting Products
Statistical module: visualization of sales statistics
Functional Specifications
It is necessary to act on the application, to connect to the application with a user ID and password. To facilitate its use and in order to avoid any mishandling thereafter, here is the solution:
User Profile:
The user will be able to visualize the products sold by My Online Races. The user can place an order, provided that he has registered with the site My Online Races.
Manager profile:
The manager will be able to manage the products:
Add / Edit / Delete Products
Add / Edit / Delete category
These data insertions can be made using CSV or XML files, but also through various forms on the website.
The manager will be able to view the sales statistics.
Supervisor Profile:
The supervisor can add managers whose roles are specified above.
The supervisor will be able to view the sales statistics.
The supervisor will be able to view all the actions performed by the managers, a sort of audit trail.
Well I wish to know already if you have remarks about my design. As well as I have a confusion for several methods, for example adding, modifying and deleting a product. Should I put them in the manager or product class? Is the composition I put correct or should I remove it?
Quick review of the diagram and advices
First some minor remarks about class naming: Ordered should be called Order.
The composition between Article and Order is just wrong (not from a formal view, but from the meaning it conveys). Use a normal one-to-many association: it would reflect much better the real nature of the relation between the two classes. Please take into account that a new article may exist without having been ordered, so it shoud be 0..* instead of 1..*
+belongs and +do in the middle of an association are syntactically incorect. You should use a plain triangle instead (or nothing at all). The triangle should be oriented in the reading direction Person do |> Order and Article belongs to |> Category
The methods seem ok. You do not need to add a suffix.
How shall objects be managed (created/updated/deleted) ?
A more advanced concern is not about the diagram but about how you want to organise persistence (i.e. database storage):
do you really want the object to be an active record, that is an object that adds, updates and deletes itself (to the database) ? It's simple to set up, works well, but makes the class dependent on the underlying database implementation and thus makes maintenance more difficult;
or wouldn't it be better to use a repository for each object ? In this case the repository acts as a collection that manages all the database operations. The domain object (Article, order, User, ...) then have nothing to know about the database, wich leads to more maintainable code.
But this is a broader architectural question. If it's just for a first experimental project with JEE, you can very well use the active records. It's simpler to set up. Be sure however in this case to disambiguate the Add/Update/Delete on Person, since it currently may give the impression that any person can add anyone.
Improvement of the model
A final remark, again not about the diagram itself, is about the domain. Your model considers that an Order is about a single Article.
In reality however, orders are in general about one or several articles: if this would also be the case here, your Order would become an OrderItem and the real Order would be inserted between Person and OrderItem. You could then make the relation between Order and OrderItem a composition (i.e: OrderItem is owned by Order, which has responsibility for creating its items, and the items have no sense without the related order).

Is there a better way to represent this Sequence Diagram for a Employer-System-Applicant Scenario?

I've been asked to make a Sequence Diagram for a Casual Employment System in which includes mainly the Applicant, Employer and System. Following my Use Case and Class Diagram, I have used the info I Have to produce a sequence diagram for the Applicant which I have been assigned as actor. My teacher came up with the following comments:
Frames can only be alt, opt or loop.
You can't have multiple arrows into the same activity bar.
It looks like applicant and employer are humans. sequence diagrams are of software not humans.
There is no method name for the driver method on the left.
There is only one participant for the software "System". You need to have many participants each is a class.
My question would be:
what other participants can I have besides the "system" for the Applicant to interact, what other classes can I make?
User Story:
As an applicant, I want to be able to
create an account so that I can apply/search for available jobs.
create a job preference so that I can work in my desired field.
update my employment status.
change my job preference.
create and modify my availability regularly so that my work time will cope with my personal / school schedule.
add or update my employment records.
add or update my reference.
upload my CV online.
select my interview time, IF I get an invitation to an interview (for shortlisted candidates ONLY).
accept/reject job offer.
make a complaint about my employers if necessary.
If you know how to create a class diagram: take the classes in that diagram.
If you know an object-oriented programming language, take the classes you would have in the software.
Otherwise, look at the nouns in the user story: account, job, etc. These will be classes. Some nouns are not classes, but just attributes of classes: desired field, employment status etc. You may ignore these.
All these classes are part of the system. Do not include System as a participant.

UML use case diagram "cafeteria system" validation

I've written a script to make a cafeteria system at college. I need to know whether my diagram is correct, especially the shares of the operations.
The student selects one of the restaurants available in the cafeteria.
The student selects the item you want with the possibility of adding some ingredients to the item and receive the sellers.
The student pays to the seller. The delivery of a request is included, an update to the store at the moment the student is paid.
The seller's issue the invoice to the student and includes an addition to the account of exports and imports of the restaurant.
Administrator for the restaurant When you want to add new item, the sellers are notified of the new item added.
Administrator records attendance and absence of sellers.
Use correct naming for use cases: predicate, subject (, object).
Do not use include/extend as it's simply mistaken for functional decomposition, which is plain wrong.
Synthesize function descriptions to extract the added value hidden behind those descriptions and make them use cases (single added values the system under consideration delivers to its actors).
It's ok to indicate primary and secondary actors by using directed associations. However, this in no standard, but a convention and needs to be explained in separate modeling rules.
Your saller should likely be Seller. Note the upper case first char too (also wrong with Student).
With little effort your diagram could have been uncluttered!

UML Activity Diagram - how to design?

MAKE RESERVATIONS is the activity and it states the following:
A customer contacts a reservation officer about a car rental.
The customer quotes the start and end dates needed, the preferred vehicle, and the
pickup office.
The reservation officer looks up a prices file and quotes a price.
The customer agrees to the price.
The vehicle availability is checked to see if an appropriate vehicle is available for the
required time at the required office.
If the requested vehicle is available at the nominated pickup office, then it is
reserved for the customer. An entry is made in the vehicle availability registering the
reservation.
The reservation officer issues a rental number to the customer.
A rental agreement is then created in a rental file, including the rental number, the
rental period, the vehicle type and the pickup office.
Exceptions
An appropriate vehicle is not available at the pickup office. The customer is offered
an alternative vehicle.
The customer does not agree to a price and asks for an alternate vehicle and/or
period.
I designed the activity diagram for the activity above yet I don't know whether I have to put the question in the decision node or above on the control flow? In my case, the Agree to Price should it be on the decision node or on the control flow arrow that inputs the node?
As well as that, if a use case only specifies a condition, such as " If a vehicle is available, the customer is offered the vehicle and a price is quoted. If the customer accepts then a rental is initiated." how does the decision node look like?
Moreover, what if there are three different actors, should there be a swimlane representing the actors or can the activity diagram be drawn without one?
The activity diagram for the use case above is posted below
I don't know whether I have to put the question in the decision node or above on the control flow?
They are written in the flow, as you did. In UML the decision node is empty (this is a difference from basic flowcharts, where one would write the condition within the node). Each flow coming from a decision node may be annotated with a guard (i.e. condition). When the decision node is executed, any flow whose guard evaluates as true may be selected for execution (Usually, the conditions of the guards are exclusive, and only one guard may be selected, but that is not a requirement).
As well as that, if a use case only specifies a condition, such as " If a vehicle is available, the customer is offered the vehicle and a price is quoted. If the customer accepts then a rental is initiated." how does the decision node look like?
It looks as in your figure, but there should be an action node for asking the client before the decision node, because the only purpose of the decision node is choosing among several possible flows. No actions are executed as part of the execution of the decision node.
Moreover, what if there are three different actors, should there be a swimlane representing the actors or can the activity diagram be drawn without one?
It depends on what you are modelling, if you have different actions performed by different parts of your system, you may use swimlanes (I recently drawn an example here), but you may avoid swimlines if it is not interesting to model that separation. Normally, the actors would provide input to the system, but they will not be executing actions by themselves.
For instance, your example model the behavior of the reservation officer (which is part of your system) based on input from the customer (the initial quote and agreement) and the customer receives output (the rental number). I recommend that you ask that as a separate question emphasizing on the third actor.

Resources