Refining and designing new models on SMS software

Question 1: Design Class Diagram

You are expected to refine some of the models provided in the Appendix (and made available as a Visual Paradigm project, released via Moodle with this assignment) and develop a set of new models on the SMS software by answering the following questions.

The Appendix offers an analysis class diagram of the SMS software. You are expected to refine the Shipment package included in the diagram and add design level details to the classes, the relationships between them and design the access to this subsystem of SMS from the other parts of the system (subsystems). The Shipment package contains the following classes:

-Shipment,

-ShipmentHistory,

-Recipient

-ShipmentClass

The following details must be added:

1. Each analysis class should be refined and its attributes and operations (methods) must be fully specified with types, visibility and, if appropriate cardinality (arrays, vectors, etc.). For each of the methods a return type must be clearly defined, too.

2. Constructors (one or more) should be added to each of the design classes, as necessary, with full details – parameters and their types.

3. The associations between design classes should be refined, too: the simple associations in the analysis class model should become aggregations/compositions and navigability should be added. 1-to-many associations should be refined using “collection” classes such as arrays, vectors (check the lecture notes and Arlow’s book if in doubts).

4. Design should also try to achieve loose coupling between classes included in different packages/subsystems by revising the associations between classes captured in the analysis class diagram. Some of the associations shown in the analysis class diagram may be dropped. You may also discover that some new associations are needed. You may apply CRC cards and refine the responsibilities of the classes or even discover new class responsibilities, which are delegated to other (new helper) classes.

5. Finally, in design you must add classes from the solution domain. You are expected to demonstrate your understanding about how in design we mix problem domain classes (which are shown in the analysis model) and classes from the implementation domain by addressing the following three aspects:

A. Assume that the SMS software uses a local database (e.g. the popular embedded SQL Lite or a more advanced RDBMS such as PostgrSQL) to store the relevant data. Provide a minimalistic design of database connectivity, which includes:

1. an interface for database access to store/retrieve data from the classes in the Shipment subsystem to a database of choice, and

Question 2: State machine

2. an implementation class that realizes the above interface (you can refer for examples to the lecture notes and to the model answers of the Tutorial on system design);

3. You are also expected to show which problem domain classes will be using/accessing database connectivity. If necessary, you can add helper classes to simplify the database access.

B. Design the communication between the Shipment subsystem and the other subsystems, e.g. with the classes which belong to the Accounts and Payment packages (subsystems). You may define an interface, provided by the Shipment subsystem, which the other sub-systems will use to access the functionality of the Shipment subsystem. You may also need to define “required” interface(s),5

which the Shipment subsystem will use to access the other subsystems of SMS software, e.g. Payment package (subsystem).

Hint: You do not need to provide implementation classes for the “required”  interfaces as these will be provided by the other sub-systems.

C. Consider using design patterns, e.g. Façade or other, suitable for the particular context to reduce the coupling between the subsystems of SMS software. (50 marks)

Now consider a fragment of a class diagram, which models the class Shipment.

The attributes of the class Shipment are used to store:

1. “IDNumber” the unique id of Shipment.

2. “status” – this attribute takes values from the set {“unconfirmed”, “confirmed”, “delivered”, “archived”}.

3. “arrivalTime”, “departureTime” and “expectedDeliveryTime” – capture the times the

shipment has arrived in the warehouse, has been sent and the expected time of delivery to respective recipient.

4. “price” – the price of shipment.

5. “summary” – a brief description of the content of the shipment.

6. “size” – the size of the parcel (“small” or “large”).

7. “distance” – the distance to destination (“domestic delivery” or “overseas delivery”).

8. “weight” – weight of the parcel in kg.

The class Shipment offers a number of operations, which allow for retrieval and modification at run time of the values of the following object attributes:

- “distance”

- “size”

- “weight”

Changes of these attribute values are made by calling suitably defined setter methods for the class (e.g. setDistance(), etc.). Each of the changes will lead to recalculation of the price: the attribute price will be assigned a new value, which will be calculated by calculatePrice().

Develop a behavioural state machine diagram, which models the work of an instance of the class Shipment. The diagram should show:

Question 3: Deployment Diagram

1. the states of an instance of Shipment together with the actions (entry/exit) and activities (do) associated with each of the states the instance may be in,

2. the transitions between the states with their events (triggers), guards and actions. Consider the events, which change the status of Shipment and alter the attributes (size, destination and weight) which may lead to price recalculation. Once the Shipment status has become “archived”, the object may be destroyed.

Hint: Remember that the state of an instance is represented by the values of its attributes,  the links that the instance may have with instances of other classes and the do activity  associated with the state. In this case, the links of objects with a Shipment object are fixed at the time the object is created and no new links are created throughout the life of the  object, hence the state changes will be caused by either call events (method invocations) or caused by completion of a do activity, if specified for a state. (25 marks)

Let us assume that SRU plan to implement the SMS Software as a web-application and use Java as the programming language1. Let us further assume that a deployment package sms.war has been created to simplify the deployment of SMS Software on a J2EE compliant Java application server such as Red Hat JBoss AS 7.1 or similar. This server will be installed on a dedicated server machine (AS_Server) with Linux operating system (e.g. Fedora 28). The application will store the data on a PostgreSQL 9.0 RDBMS deployed on a different server machine (DB_Server) running Windows Server 2016 as an operating system. The database file accessed by PostgreSQL RDBMS is called SMS.DBF.

SMS Software shall be accessible via a web browser and the developers are encouraged to optimise the application for access from a mobile device using the latest version of the popular JavaScript library, JQuery.js.

The printing service is run on a separate computer (HPPrinterServer) and the communication of JBoss with this computer uses an “HP protocol”.

SMS uses a third-party SMTP server run on a separate device (SMTP server) with Windows Server 2016 operating system. The SMTP software used is “hMailServer”. The communication between SMS Software and hMailServer adheres to “SMTP protocol”.

For online payment, SMS Software uses PayPal, which is deployed by the respective vendor, and “PayPal Express” API protocol is used in communication between SMS Software and PayPal.

Develop a deployment diagram, in which you model the deployment of SMS on dedicated hardware, as described above, and show the communication channels (links) between the SMS software and the 3rd party services (Print, SMTP and Payment) defined in the case study. You may need to make additional assumptions (e.g. about the hardware on which browser is run to access SMS Software, etc.), if the details provided above are insufficient to complete the deployment diagram. (15 marks)