UML diagrams and specifications for attendance system and sightseeing application

Creating a use case diagram for the attendance system

The sequence diagram below shows how the different components of an attendance system work together. When a card is presented to a card reader in a teaching room, the reader recognizes the card’s id and forwards it to the attendance monitoring system (AMS), which (1) looks up the room the card reader is installed in and retrieves the current teaching session from the timetabling system and (2) looks up the student owning the card and the module to which the session belongs and checks with the module registration system if the student is registered for this module. If this is the case, the AMS returns true to the card reader and the student’s attendance for the session is recorded.

Create a use case diagram based on this sequence diagram. Assume (for the purpose of this Question 1.i only) that our task is to implement the AMS.

ii. Create a component diagram at type level, consistent with the sequence diagram.

iii. Detail the interfaces of the components as UML interfaces, including full operation signatures.

iv. Describe effect of the invocation true = checkIn(card, reader) using textual pre and post conditions and a visual contract based on the informal description of the scenario, the sequence diagram and the class diagram.

This sequence diagram describes a scenario where an onboard system in a car interactswith an external service to discover and select nearby sightseeing opportunities, called sights, and then supports the driver in booking a ticket for a selected sight.

To answer the following questions, you have to discover and correct inconsistencies between different models or between models and XML code.

i. Component Diagram

The following component diagram has been derived from the sequence diagram above. Enumerate all inconsistencies between the component diagram and the sequence diagram above and provide an improved component diagram correcting the inconsistencies you discovered. To highlight your changes, write the number of each inconsistency you identified next to your correction in the new component diagram.

ii. Matching pre and post conditions

The sequence diagram above represents the design of the application in a top-down development, starting from the end-user requirements rather than the existing services. The first visual contract below models the pre and postconditions of the bookTicket() operation from the requester’s point of view. The specification of the corresponding operation implemented by the provider is shown as the second visual contract.

Enumerate all inconsistencies between the requestor and provider specifications of this operation and provide an improved version of the requestor specification correcting the inconsistencies you discovered. To highlight your changes, write the number of each inconsistency you identified next to your correction in the new visual contract.

iii. Mapping to WSDL

Enumerate all inconsistencies between the use of the operation in the sequence diagram and its declaration in the port type and provide an improved version of the port type specification, correcting the inconsistencies you discovered. Highlight your changes by underlining them and write the number of each inconsistency you identified next to your correction in the code.

iv. Adapter

ii. Assume that we are unable to change either the requestor’s expectations or the provider’s implementation of the Sights service, so we have to create an adapter instead mitigating between them.

• Adding an adapter component to the component diagram.

• Defining the provided interface of the Sights service according to the given pre and postconditions in Question 2.ii.

• Extending the second part of the sequence diagram (between the user messages labelled select sight and ticket) to include the communication with the adapter.