Download
1 / 7
70 likes | 266 Views
No. 1. register. registered user. user. login. Use case r egister Primary actors : User Secondary actors : -. Use case l ogin Primary actors : Registered User Secondary actors : -. request appointment. doctor. registered user. Use case view appointment
E N D
No. 1 register registered user user login Use case register Primary actors : User Secondary actors : - Use case login Primary actors : Registered User Secondary actors : - request appointment doctor registered user Use case view appointment Primary actors : Patient, Doctor Secondary actors : - <<include>> view appointment Use case request appointment Primary actors : Patient Secondary actors : Doctor patient Use case cancel appointment Primary actors : Patient, Doctor Secondary actors : - cancel appointment
No. 1 • Some notes on No. 1 • Note 1 • The question was primarily to give a Use Case diagram; so the most important elements for you to figure out are the use cases and the actors. Details like: • The patient provides the time she wants and the name of the doctor ... if she is free at the given time ... .if so, the patient can confirm the request, and the system will reserve the time for her. • Although important, is irrelevant for identifying those elements. That detail comes as the flow or pre/post conditions of one or two use-cases, but this is not what is asked. • Note 2 • Some solution proposed Time as a secondary actor to some use-case. This is usually overkill. A actor is something outside the system itself, that interacts with or being interacted by the system. Most system can ask time to itself, so there is no need to model it as a secondary actor. Using Time as a primary actor is a different story. This is a work around so that you can model activities that the system itself activates. • Note 3 • Since there can be more kind of users than just patient and doctor, ideally you shouldn’t let them be the actors of request/view/cancel appointment. But the text is indeed a bit ambiguous on this.
No. 2 1 1..2 * Company paySalaries(type) Dept 1 1 all employees * * The attribute salary represents the employee’s salary on monthly-base. The operation calcSalary() should calculate the salary that the employee should receive periodically. Employee name address salary calcSalary() StdEmployee ExtEmployee getOperation() calcSalary() ExtAgency 1 Director addEmp(e) remEmp(e) reAssign(e,dept) changeSalary(e,newSal) Manager changeAddress(e,newAdr) SOLUTION 1, with inheritance. ExternalEmp must override the calcSalary operation. This solution is not so good, because it doesn’t allow a Director or a Manager to be an external employee as well.
No. 2 1 1..2 * Company paySalaries(type) Dept 1 1 * all employees * StdEmployee Employee name address 1 SalaryType salary calcSalary() Director addEmp(e) remEmp(e) reAssign(e,dept) changeSalary(e,newSal) Manager changeAddress(e,newAdr) 1 ExtEmployeeSalaryType calcSalary() ExtAgency SOLUTION 2 : this solution allows any type of employee to be external as well. What is not so nice is that ExtAgency is associated to SalaryType; while it seems to be more logical to associate it directly to Employee. We can do that, and put a multiplicity of 0..1. But then we also have to put a constraint that an employee with an ExtAgency must have ExptEployeeSalaryType.
No. 3 1 * * Person Person ConnectionType The one above is a correct solution. The composition/aggregation in the model can be dropped . (This kind of question was discussed during the lecture btw, as well in in the book. There is also a similar problem in the exercises pack distributed to you.) The model below is not correct. 1 1 * * ConnectionType Person Person For example, you can’t model this situation: P1 is connected to Q1 (friendship) P1 is connected to Q2 (professional) P2 is connected to Q1 (friendship) P2 is connected to Q3 (professional) This is because in the model above every person can have just 1 connection type.
No. 3 1 * * 1 Person ConnectionType Person The model above is also not correct. You can’t model this situation: P1 is connected to Q1 (friendship) P1 is connected to Q2 (professional) P2 is connected to Q1 (professional) P2 is connected to Q3 (professional) Notice that we have two persons P1 and P2; both are connected to Q1, but each has a different type of connection.
No. 3 A proposed solutions by some students: 2 * Person ConnectionType This solution is possible, though not very nice. In a way this is some sort of encoding of the first solution I gave (setting aside details on composition/aggregation and navigation), which is: * * Person ConnectionType Person 1 1 The first solution above bundles the two separate association above into a single association, but with a double multiplicity. In the first model it is implicit which of the two persons in the association there will take the role of the left person in the original association.
