General comments (applicable to several of the reports): G1) Ensure you have covered all components; - design decisions - Use cases (Diagram and textual) - Analysis level model (high level classes + attributes, high level sequence charts) - Design model; detailed classes (diagram), detailed sequence diagrams for use cases and make clear which part of your report belong to which model. G2) Clearly give the connection between the components. G3) This is a report not just a collection of the components above; it should have the structure of a report. G4) Ensure you also cover the management of stock, orders, users, etc. Even if a part keeps track of its stock you still need to have a system / database component which keeps a list of all parts (& users, orders, etc.) Note that stock/order management is more complicated than simple counting; e.g. when cancelling an order you have to know if the components were reserved or ordered - when parts arrive you need to know which orders to update etc. - when configuring laptop you need to know remaining delivery time; is the part available - on order (with non-reserved parts in this order) or needs to be ordered, etc. Make sure you have enough info to cover all such use cases. G5) Use the naming conventions & syntax as introduced in the notes; e.g. Numbering of alternative usecases, Format/meaning of MSCs (don't overlap actions), internal actions in MSCs should have a meaning and thus labelled and/or explained; otherwise omit them - it is already implicitly assumed that the instances will be doing things between the communications. No standard get/set in class diagrams G6) Use consistent level of abstraction within a model; e.g. the described steps in a use case should be of a somewhat similar complexity (motivate deviations). --- Group 1 G1, G3, G5. Use cases too high level. They should cover all functionalities (create account log on, manage parts, etc.) UC Buy laptop; parts not reserved (see also comment above) Give continuation after exceptional case; does the UC fail, continue at step X, etc. (e.g. alt 8,9) Check order: pre: user is logged in; your system does not offer a way (UC) to achieve this. Delete order: triggered by viewing ?? should also update stock SM: level of detail is inconsistent e.g. define model info is relatively big step `added to the system' is not clear; what does this mean, what effects does this have. Design decisions: fulfilling part order outside but issue order and manage stock definitely to be included. (See informal requirements.) Analysis Model: give connections with UCs, attributes in class diagram. calling master SM would already help give connection. Seq. diagrams: Part of analysis or design model? Explain relation to use cases. Buy laptop: step 1: choose model -> to system, returns part choice options. what is step 3? what is the alternative for log in ? (the remaining steps should be all within the log in alternative as they cannot be performed without logging in.) similar confirm order will not happen after payError ! payment involves 3e party. --- Group 2 UCD: Registration and login also requires user interaction (add lines) system is not an actor; instead create part management use cases (& use includes - auto order is only one(part) of these, also (un)reserve parts etc.) UC 1 BL Don't call a user `it' step 6+7 could be combined; needs alt - payment fails. SD: can show alts in diagram as well. do you mean the `precedes operator' (different arrow) or simply a confirmation message (simple put it in between, not connecting the two points). (should likely return selectable options for the model) missing a message delivery time and costs info from system to user before login and pay. Note that lines are instances not only actors; could have many more lines than actors. UC 3 Cancel: Cancel order and return parts to stock not reflected in MSC. UC 9: use dashed lines for things without order. other laptop models may have different parts that can be configured. MSC does not match textual description alt 3-10; would add a ref to use case define part. UC 10: Ack does not make sense; do you mean list of parts? This step is missing in textual description. Classes: G4 --- Group 3 UCD: for logged customer; you are giving steps in a use case not different use cases (combine some e.g. into a `configure system'). Check the syntax for UCDs. (Choose laptop, choose parts etc begin with `completed previous' and end with `continues ...' which is a clear indication that these are really part of one use case not multiple.) Gather design decisions (e.g. user logged in before allowed to configure laptop) G4 Analysis level: add features, description and RELATION TO USE CASES. Design level: extends analysis level; map functionality onto components. The ordering does not create parts - it only selects options for them. Class parts does not have the `choose parts()' functionality that you use in the MSC. You seem to be confusing parts and part models. --- Group 4 UCD: No link 3e party website for cancel order (think I-deal; only for payment no user confirmation needed to reimburse - goes directly to the users bank account.) Log in included in other use cases as well. Create account - how will you check user does not create 2 accounts ? (Can check a user name is not used twice but not that a user does not also have another account.) Give continuation after exceptional case; does the UC fail, continue at step X, etc. (you do for some but not e.g. for UC order laptop). Note that same part model may be used by different laptop models. Analysis model No need to explicitly stop the user or include inactive instances. Order laptop; returnDays() this seems to be data; nr of days not a function call (User has no such function). Diagram user class = user account or user DB ? G1 (Design vs Analysis level diagrams, consistency classes - diagrams - use cases) G4. --- Group 6 G3, G4, G5 UCD order includes customise model and choose shipment type and pay... Customize model (and others): link exceptional cases to the steps in main ! (as alt to 3 I assume). (Also give how the UC continues after the exceptional case; fails, continues at step X, ...) Gather design decisions. Sys level diagram: after deny the rest of the steps do not happen; move all steps to the ack brach of the Alt. Semantics are defined for any MSC, no need to give them separately. Design level: Order influences stock. Register a client is a function of a client DB not of a client. Define model should allow defining other parts. --- Group 7 2.1 UCD order new parts does not include cancel order (though they share a component; stock management). similar for purchase and order customize IS part of purchase. 2.2. use actions not goal as a trigger. two different users cannot have the same password ??? Class diagram not sufficient to cover all use cases/requirements (see G4). 4 create account; why does the user have to receive the message before the account can be created message can be sent? (and how will the system know the user got the message.) (Similar for other cases.) Does not reflect the use case; no form and `user is notified' in use case, (can be solved by adding explanation; form implement steps 2,3,4...) alternatives of use case not covered. You seem to be mixing messages and conditions; e.g. User name+password are correct is a condition not a message to the user. ( but if incorrect; show error message and loop...) --- Group 8 Many of your UCs are more steps within a single UC; suggest combining some (e.g. search + choose). Order laptop includes pay. UC make account forwarded to web server (from where ?) - too detailed for this model; simply combine 2-3-4 in one step (similar for others). missing: User name taken exception. Indicate what happens after exceptional case; UC fails, continues at step X,... Analysis model: add main features. class diagram is insufficient to cover use cases (see G4). MSC9: does not match use case handle payment with out user activity is not possible; there should be messages going to/from user (`redirect... from system to 3e party' is NOT a message to the user but should be e.g. sys->user: payment link, user->3e party: follow payment link, etc.). What is system an instance of ? (In the design MSCs it should be an actor or an instance of some class in your class diagram...) --- Group 9 Give Use case diagram + overview + Design decisions (e.g. logged in before start configuring order) Order: missing stock update, deliv time+price notification to user (see G4). MSC notation; dashed vs solid vertical lines, notation for alternatives. SM modifies DB; what use case, what DB ? Class diagram; User is used to model a single user as well as a DB of users. (e.g. register is a system/DB function not a user function). --- Group 10 G4 in UCs UC 2.1) 6.1 & reserved for when arrives ? (otherwise msc does not match UC - for msc use opt: order parts) sd buylaptop (p22): add order is not part of the opt. --- Group 15 1 UCD Pay for -> Place + <> PAY, <> configure, <> login etc. explain why SM subset Customers. 2.1.1 trigger; use actions not goal as a trigger. (a) chooses a rather than enters his/her (they don't exist yet). 2.1.2 a-1 etc: no need to detail this; it is all standard - actors can decide to stop UCs (combine all these into a general remark); only if something special happens/needs to happen do you need to specify this. 2.1.4 b user chooses which order to cancel 2.2.1 a-1: So what happens next ? (also for other alternatives; specify what happens after this exception occurs - UC fails, continues at step X, ...) 3.1 5) Third party should be another instance! High level spec of the classes missing. Clearly give connections between models (UCs, analysis, design). Missing "System" class used in MSC (See G4) 4.2.1 a customers will not (should not) know all user names that exist (see G4). Check consistency with 2.1.1 4.2.2 related to 2.1.2 --- Group 16 MSC could model send-receive to self without intermediate steps as internal actions. 1.1.1 but still need to track stock ! 1.1.4 Not consistent with informal requirements 1.1.5 what are these classes; state functionality that will not be further detailed; if you name classes you already have a model (just an incomplete one) 4.1.2 use loop syntax, inconsistent with use case missing use case `get report' for SM `sub' UC log in is convenient (as used in order, look up, cancel ...) 2.2 Why distinguish a and b unless you alraedy check after a (so c-1 -> b-1; go back to a) 2.2 UC Order - use actions as triggers not goals (same for other UCs) (c) selects options for all parts (may also be other parts with options) (o) this is far to late; customer needs to get this before buying. alternatives: always make clear what happens after the alternative steps; does the UC fail, does it continue (at which step). Include references to other use cases where relevant 2.2 UC cancel order Inconsistent with informal requirements - order cannot be cancelled once it reaches the assembly line. a-1 when does this happen ? a-2 when does this happen and aborted how (or is this meant to be a second step in a-1?) UC look up order pre: at lookup status page There is no use case that will get the user there. (b-1) see above - when in shipment the order cannot be cancelled (it is already on its way to the customer...) G1; Clearly distinguish use cases analysis model and design model + give links between them. Fig2: is missing create model (create part has a different signature) --- Group 18 G1; destinction models, low level mscs G3 MSCs hard to read on print X wants ... is not a scenario step (But can be part of an accompanying description) Generalize you scenario's into use cases. Provide possible alternatives with the use cases. 1.2.2 diagram: User -> SM 2.1 shop seems to be missing functionality needed for reporting (which would become clear from the design level MSCs) G5; get/set, annotations. --- Group 19 G1 - use case diagram G3 1 - use action not goal as trigger (user wants to buy will not have any effect on the system). Inconsistent with requirements; user must have and use account. 1.14: G6 is much more complex than other steps - should be worked out some more (or defined as separate use case). Alt 1 G5 numbering - who is the manager? Why can the user not also cancel at 10-13 ? 2 2a how do you check this ? 2b and what is then the next step / result ? 3. 2-1.4; if possible -> give the actual condition i.e. not yet reached assembly phase. the user is returned to step 1. Figure 1 etc. G5; MSCs Figure 2: Not consistent with use case (e.g. user name taken situation not covered.) Figure 3: No update on current order after successful cancel? G1 High level classes Figure 10: explain your classes (and link to use cases) How is e.g. stock management achieved. Parts also have names (e.g. CPU). I don't see why part model would need multiple parts ? (It belongs to a single part). Instead part should have several part models (options for this part). Similar; why does partmodel have a laptopmodel? Laptop model should have multiple parts; the ones that can be configured for this laptop model. Figure 11 Alt missing an option separator ? Figure 12 Don't overlap actions;e.g. internal action customize laptop needs to start after return laptop models. Indicate how these steps implement the use case (1). Ensure the calls are consistent with your classes; e.g. there is no `getShipping()' defined for System (nor any other class for that matter). --- Group 22 Missing use case register new user (and perhaps log on). Make order: Steps are a bit too course grained; don't combine so many actions in a single step. This also removes the possibility of defining a desired order; e.g. a user will want to see price and delivery time before having to choose a payment method. Include references to the sub-use cases. 4. delivery; do you mean confirmation that the order is placed ? (delivery of the order is when the laptop physically arrives at the customer.) Cancel / Status Order; how does the user get to select on of their orders (e.g. order management use case which provides a list of orders?) Try to have useful steps; e.g. a use case X description like; 1. issues command to do X 2. do X 3. confirm X done is not very helpful; you should try to detail how X is done instead; `issues command' is covered by the trigger and `confirm X done' more or less by the guarantee. (You can include a confirmation step if you feel it is important). G4 Fig 5 Check order and cancel order should be optional My print out has no yellow rectangles Fig 7 Difference getReport and showReport? Fig 8 Model -> Laptop model ? Fig 11 AvailabilityReport -> Availability ? OrderReport -> PartOrderReport ? etc. -- Group 23 G3 Use case diagram; G5 clic -> click use case ADM view all products: Note that a use case is about actions/events not conditions; also add refs to other use cases where relevant. replace e.g. admin can reach a button ... by e.g. options (buttons) to remove or modify each product on the list are offered to Admin; see use cases ... and ... . Use case descriptions: use case X; do X is not helpful. You should describe how to do X. E.g. give more details on what is `all products' or where they are retrieved from. Or perhaps they should not be separate use cases but steps within a bigger use case. (Manage products, create order, ...) Please use a spell checker. Use case Register: Starts with user enters details not hits confirm button. Also give what information the user should (at least) enter; e.g. user name password, etc. Step 4 and 5 are the same ? Missing alt. : username already taken. UC View all products 2a,3a: these are design choices (logged on before build system). Record your design choices. Analysis model; also give features of main classes. Hard to read figure. Explain and link to use cases. Seems insufficient to cover use cases eg G4 Your sequence diagrams also need explanation; e.g. what is User Object and how can system do a check (which main class does it use) without consulting user object which seems to keep the user records ? MSC looking shopping cart; (please use same order and names as in use cases) The use case starts with a user action not with the order sending a list to the user ? Are these system level charts or a design level charts ? Seems to be an odd mix - Give a high level chart with the analysis model and low level (with system instances actual classes and messages actual function calls within these classes) with the design model. You are using calls e.g. get all parts to PARTS which are not defined for that class and instances which do not correspond to classes (or actors) e.g. SYSTEM, USER OBJECT --- Group 24 G3, add explanations to each part. Defining new part/part model not really covered. UC add laptop Sets available part ... and default part model for this part and the other options b.1,c.1 followed by ? UC remove laptop Would expect a list of laptops is first displayed to the user so they can choose which laptop to remove (seeing as there is no separate use case for listing models). UC Buy Laptop Missing info on shipping time and price shown to user and payment. Analysis model Also give relation classes (or add e.g. list of partmodel to order etc) (e.g. High level class diagram) G5 Msc View part report Link to steps in use case. Use labeling consistent with use case and high level classes. The partModel class does not have a list of orders feature so how is it going to find the ongoing orders. Add laptop Explain link with use case... Buy Laptop In response to choose model there should be a list of options given (thus this must be available to model somehow). Cancel orders Not consistent with your use case. Make sure your MSCs implement your use cases. G4 Low Level Seq diagrams Should use actual function calls of the classes. Cannot remain unchanged. How does an order instance know about all the other orders? See G4. Buy laptop Here one would expect that a new order object is created by one of the other instances. --- Group 25 UC Buy Laptop Donīt use none as trigger. Instead use step 1 as the trigger. UC Configure laptop Seems to be missing user selects a laptop model and gets a list of options. UC Manage orders 4a.1 step 8 ? SD buy laptop Explain the numbering or use a numbering consistent with the use case description. SD detaillevel manager There is no class Webshop so what is this instance ? (See G4) --- Group 26 UC diagram 1 System is not really an actor. Fill in web form is a step but not really a separate use case. UCD 2 Why is a manager subset user; managers need not be customers? Again system will be what enables the collection of use cases not a separate actor The textual use case description is insufficient; use the standard format which explicitly describes the steps of each use case. MSC2: 5 request payment - I'd say select payment or proceed to payment; a customer will not request to pay ;) G3; also correct the order G1; Missing: low level diagrams (in terms of classes and function calls) high level overview classes link classes - use cases G4 --- Group 27 UC diagram Seems to be missing the main buy laptop UC. You do give all the parts (perhaps even too many; e.g. authentication is likely only a step in login not a separate use case) but not the main UC itself. Specify delivery time for the order Suggest renaming this to e.g. for the parts order (to avoid confusion with laptop customer orders) if you keep this at all; perhaps only a step in the define/update parts. Registration; Preconditions - these are conditions to be satisfied before the scenario starts; you are describing conditions to be checked during the use case. Similar for post condition - Post condition; (after successful completion of the use case) the user has an account. Except 1: G5 (call it e.g. 2a) clarify; what happens next - e.g. user is allowed to accept; continues to step 3 or try a new user name; go back to step 1. 2 -> wrong password ? (i.e. shorter that length 5?) ... i.e. return to step 1. No check on password in main scenario? (Change 2 to check user name and password). Get report Here you are mixing things - getting a report e.g. on availability of the parts is something a SM can always do; it does not depend on the availability A second thing is that parts need to be ordered if availability is too low but this is a completely different use case/functionality. Specify delivery time for order Here you are not consistent with the informal requirements (How can availability be less than 0 - needs explanation ?) You are mixing provider of parts (relevant for the parts not in stock at the Lap.store) and delivery of laptop from store to customer (as given by chosen shipping option). Exception 1 ??? (Note that the requirements are that the customer is notified of delivery time BEFORE accepting the order; so timely update is not applicable.) Analysis Class Diagram; G5 - your labellings are not consistent with the arrows. I would expect the DB(Wrapper) to have more than 1 user details and possibly more than one sales manager. It should also contain a list of part models (how else to implement the add/remove part (models)). Your naming does not follow that of the requirements; in the requirements a part is a category such as CPU or HDD and a part model is a specific option for such a part - e.g. a 500GB HD). A model should have a list of (configurable) parts and for each a list of part models as options for that part. Split your design level SD into different SDs per use case. (It should be clear how they implement the use cases and for each message which function call on the class of the instance is being used.) --- Group 28 Good that you motivate your choices for use cases. Functionality to define new part models seems to be missing. Add a combined use case order laptop (which includes: customize, pay, reserve and order parts, etc. otherwise not all steps involved in the ordering will be triggered.) login 4.1 - and what is the continuation; e.g. back to step 2 or error shown and login UC failed... (similar for other alternatives; give what happens next) System is not an actor (see comment `order laptop' use case). Order part UC Inconsistent with the requirements - the provider is supposed to provide a (fixed) delivery time before hand not a delivery date during the order. (If both are to be used then this is a design decision which must be documented.) Customize a laptop Terminology; replace it with another part model Cannot replace e.g. a CPU (part) with a Graphics Card (other part) but can replace default part model (E.g. DualCore 2GHz) with other part model option for the same part (e.g. QuadCore 3GHz). G4 MSCs e.g. cancel order; These 5 pictures hardly make sense separately and can easily be shown as a single MSC. (which also clarifies the link to the UC) Specifie -> Specify Low level; System -> Company ? (there is no class system) Is the sales manager the actor or the class ? (Seems the actor while many of the things you call system would be the class; e.g. class SM has a function addLaptop which could satisfy the `Request to add' message) Please separate more clearly between analysis and design models. --- Group 29 G3 UCs Please add main functionalities; e.g. create account, login which are shared amongst use cases and/or can also be used without placing an order. You can also see this from the check order pre-condition; user has a registered and is logged in - then there should be a use case that achieves these things. UC Place order has chosen a computer model and confirmed the parts This is not a precondition this is what happens in the UC. So either remove this from the precondition or move this to a separate UC `configure a model'. Design decision: must be logged on to configure model needs to be documented. UC cancel order No the Webshop will reimburse the money. The third part website (e.g. IDEAL) will likely not be involved. UC Add model must be a sales manager - how is this checked ? e.g. is logged in using an SM account is clearer. SD SM The alt should be for the response of the system, and should offer options (see P28 of second part of the handout) i.e. 1 add model alt [model does not exists] internal action add model response model added ----------------------- [model exist] response model not added G4; stock management seems to be missing from your Design model. (See e.g. place order; no updates to stock No function to update Part availability... (no var which stores availability; how does part answer the getAvailableNumber query?) --- Group 30 Give UC diagram & relation between use cases. Also give relation use cases & system level diagram Check arrows and arrow labeling in the class diagram; e.g. I assume your system class has fields user list, catalogue, part list; and is not a subtype of part. Note that the spec says there may be different parts besides the ones listed. So there may be a need for other part subclasses. Gather design decisions. Your additional notes do not match the class diagram; for example there is no database defined and there is no id defined for these classes. --- Group 31 Give UC diagram Check your use cases list; does not match your use cases - seems to be copy paste errors. Gather design decisions. Give features of classes in Analysis diagram G4 System level seq. diagram; the notation you use suggests no order at all (MSC notation; solid line for ordered - dashed line for unordered). Class diagram; still missing features. e.g. part: has a name (and then don't give the standard get/set for these.) Add part MSC: Uses a different order than the use case; why? Should use the same order or at least allow that order. (Imposing no order seems reasonable - i.e. use dashed line for the part enter name, specs, upload image.)