Seminar 1

Object- Oriented Design IV1350

Seema Bashir
sfbashir@kth.se
29-03-23
Object- Objected Design Seminar 1
Solution

1 Introduction

Seminar 1 in the course object- oriented design primarily consists of analysis. The aim of
analysing is to better understand the reality in which the program operates. To analyse a
system, a model is first created. This is a streamlined view of the reality. It should be noted
that this model does not describe the developed program. Instead, the model visualises the
reality in which the current program exists and thereby operates. This model of reality
consists of a domain model and a system sequence diagram. The domain model is the domain
itself depicting the reality of the program under development. Additionally, the SSD
illustrates how the instances send messaged to each other. These messages form a sequence of
events which happened in a specified time order.

The solutions presented in this report are created by Seema Bashir, Razan Yakoub and Esra
Salman. The program in this seminar consists of scenarios described as basic flow and
alternative flows. These flows are for processing sale at a point of sale in a retail store. A
basic flow consists of the sequence of events that occur at the point of sale. The basic flow
specifies the interactions between the actors and the system clearly enough for an outsider to
easily understand. The specifications relating to the system itself represent what the system
does and not how the system is designed to perform the required behaviour. Additionally, the
alternative flows of events cover the behaviour of optional and exceptional scenarios.

The scenario given in this seminar is regarding a specific sale operation in which a customer
arrives at a point of sale to purchase goods. Consequently, there is an interaction between the
actors and the system. The customer will interact with the cashier at the retail store, who in
return is interacting with the system present.

1
Object- Objected Design Seminar 1
Solution

2 Method

The domain model consists of the domain which depicts the reality represented in the
program under development. Initially a UML class diagram is used to construct the DM. The
elements in the DM represent physical things which exist in reality. Therefore, they represent
the classes better known as entities in the domain.

To start with, a noun identification method is used in order to find relevant class candidates.
The purpose of this task is to find as many possible class candidates as possible. In order to
identify all the nouns, present in the requirement specification, all nouns are listed as class
candidates. These nouns are all considered as possible classes, each of them is a part of the
early draft of the domain model. In order to gain a better perspective of the reality, more
suitable classes need to found.

Additionally, another complementary method used in order to find additional class candidates
is known as the category list. The category list is defined as a table in which the rows specify
a certain category a class may belong to. The list consists of categories such as transactions,
physical objects as well products or services. This step allows one to find additional classes
which are not nouns from the requirement specification. Once all the class candidates are
gathered, they are added to the domain model.

Thereby the list of classes is sorted. This allows for the removal of any irrelevant classes
which are not essential to the program functionality. Moreover, certain classes can also be
grouped as a property of another entity otherwise known as attributes of a class. Any class
which consists of a string, integer, time or a boolean value can be made as an attribute of
another class.

Lastly, associations are added between two classes in order to better clarify the domain
model. These associations consist of a name and an arrow pointing from one class to another
clarifying the association the classes have to one another. This process is rather iterative in
which new class candidates can be found and added to the domain model whilst considering
attributes and associations.

2
Object- Objected Design Seminar 1
Solution
Furthermore, a system sequence diagram, SSD, is a sequence diagram displaying the
interaction between the system under development and the actors using it. The actor is any
person or external system interacting with the system, such as giving the system an input to,
or receiving input from, the system. The operations, otherwise known as messages which the
actors can perform on the system are known as system operation. The SSD demonstrates the
tasks which the system can be asked to do as well as the possible responses it may give to
actors present.

In order to create the SSD, the present actors interacting with the system are first identified.
Thereby, the requirement specification is again analysed to identify what the actor can tell the
system to do and how the system in turn responds to the request. It is also a standard
requirement that the system operation has a name starting with a verb. Hence describing the
action that is carried out. Moreover, system operation parameters are to be identified. Each
system operation can have its own set of argument. These set of arguments are directly
dependent on the system operation at hand and the needs of the system itself in order to
complete the action.

Lastly, a return value must be decided upon in case the operation is a request. The return
values are decided based on the requirement specification. It should also be noted that a
return value is not always a necessity as every operation is not a request, such as when an
input is sent or when an operation is started in the system.

3
Object- Objected Design Seminar 1
Solution

3 Result

Figure 3.1: An illustration illustrating the created domain model.

The main classes in our domain model are placed in the centre of the diagram. These classes
consist of the cashier, the customer as well as the item sold. The domain model primarily
consists of the entities one is able to see at the point of sale in the retail store in order to better
understand the reality.

At the top of the diagram, we have placed five classes which are essential objects that are
easily seen at the POS. These classes are not associated with other classes as they are not
directly connected to the functionality of the model itself. Hence, they are not connected to
the main classes presented below.

In the domain model above, it can be seen that at a POS, the customer purchases the goods.
The goods in our diagram is represented by a single item. The act of purchasing signifies the
association between the two classes, customer, and item.
4
Object- Objected Design Seminar 1
Solution

It can also be noted that there is an association between the retail store and the cashier. This
association is signified by the retail store employing the cashier. This step is essential for the
success of the sale operation to occur.

Another important association is illustrated in between the classes retail store and item. This
association indicates that the retail store sells the goods (item). This association further
conveys the connection between the cashier and the item sold.

Figure 3.2: A diagram depicting the created system sequence diagram.

The diagram above shows the series of interactions between the system and the actors using
it. The actors interacting with the system in the diagram above are the cashier who is the

5
Object- Objected Design Seminar 1
Solution
person giving input to as well as receiving output from, the system. Additionally, there are
also other external system interacting with the system such as the printer, the external
accounting system, the external inventory system as well as the discount data base.

The messages, which are operations the cashier and the other external system perform on the
system are the system operations. These reflect the interactions of the requirement
specifications. The first system operation is depicted at the very top of the diagram between
the cashier and the system where the cashier starts a new sale. This marks the first interaction
between the actor and the system visualised by an arrow, at the POS.

Thereupon, there are series of interactions which occur iteratively. The condition for these
interactions is sufficed by there being at least 1 or more items bought at the point of sale. If
there are no items being bought at the retail store, there would not be a need for interaction
with the system and any of the actors.

If the condition is sufficed, the cashier starts an operation in the system by entering the item
identifier. As long as the item identifier is valid, the cashier will enter the item quantity in the
system. The system will send a request to the external inventory system to request the item
information. The system will also send the certain idem identifier as a parameter to the
external system. The external inventory system will thereby return 3 values back to the
system. These include the item VAT, the item description and the item price corresponding to
the item identifier.

Thereby a series of requests depend on the specifications from the alternative flow relating to
optional and exceptional behaviour. These include when the cashier starts an operation in the
system by entering an invalid item identifier or when several goods with the same identifier
are entered consecutively. In such scenarios, the system will either return an invalid item
message to the cashier or return a message informing the cashier that the item quantity is
updated.

3.2 Updated results

1. System sequence diagram:

6
Object- Objected Design Seminar 1
Solution

Figure 3.3: An updated illustration of the system sequence diagram of the sale-operation

7
Object- Objected Design Seminar 1
Solution
Based on the feedback received, we identified certain parameters that were missing in the
system sequence diagram's operations. These parameters were crucial for the diagram to
accurately depict the necessary actions and ensure the system functions correctly. Previously,
some functions were empty and lacked the essential data, such as the identifier needed to
search for an item. To address this, we added parameters to operations like
registerItemIdentifier(identifier), registerItemQuantity(quantity), pay(amount), and
sendSaleInformation(saleInformation).

Additionally, we noticed that certain method names were focused on describing the actions of
the cashier rather than conveying the purpose of the operations. Consequently, we modified
some of the names, such as changing "entersAmountPaid" to "pay" and "entersItemIdentifier"
to "registerItemIdentifier." As a result, all operation names now clearly describe their
intended purpose.

It's important to note that these changes were specific to the system sequence diagram, and
the rest of the report and discussion remain unchanged, as they accurately represent the
system's functionality. The identified modifications addressed the key issues and ensured the
diagram correctly represents the system's operations.

4 Discussion

8
Object- Objected Design Seminar 1
Solution
One typical mistake which can be made while creating the domain model is creating a DM
which depicts the program instead of the reality. Such a programmatic program essentially
assigns aspects which are part of the system to the DM as well as the notion of time. Thus,
the classes are associated to one another in such a manner that reflects sequential order of
sort.

Likewise, another important class displayed in the domain model without any association to
other classes is, DiscountCondition. This class contains the conditions of the total discount a
customer is entailed to. The reason why we have decided to include this class is for the client
to have a better understanding how a customer earns discount. It should be noted that these
conditions are fetched from a separate data base, the discount data base, therefore it is not
associated with other classes. We perceived this as part of the system and therefore is not
displayed in relation to anything else in the domain model, as it is not part of the reality.

The domain model resented in figure 3.1 models the reality in which the program acts. The
DM is not a visualisation of the program itself. As seen in the figure, there are no classes
which depict the program itself. The classes we have chosen for the solution include things
which can can be seen at the POS when a customer arrives to buy goods from the retail store
at a cashier. These include the physical things such as a display monitor on which the
customer sees the name of the item, the quantity of the item bought, running total as well as
the amount, they pay and the change they might receive. It should be noted that the class
monitor does not have an association with another class. As the monitor is a physical entity
which exists in the reality, thereby it does not influence any other classes. Similarly, other
classes with no associations can be found at the top of the domain model as seen in figure 3.1.

Moreover, the associations are chosen with great consideration such that they do not depict a
method call. The associations chosen for the specific classes in the domain model are
carefully used to clarify the association the classes have to one another. An example of this is
seen in more abstract classes such as payment. Hence payment is exchanged for item.

From the requirement specification, two parts of the system were obtained. These include
external accounting system and external inventory system. These two systems are used when
updating the sale information. However, these systems cannot be seen at the point of sale by
the cashier or the customer since they are part of the system. Note that these systems are not
9
Object- Objected Design Seminar 1
Solution
associated to any of the classes in the domain model. Therefore, they are presented separately
on the side to provide a better understanding for the client to whom we present the model.

Lastly, the domain model presented in the solution is not dependent of time. The classes in
the domain model are not concerned by the notion of time. The main, most important classes,
the item, the cashier, the customer are placed in the centre of the domain model. Naturally
these classes will have the greatest number of association with other classes in the domain.
This does not create a spider-in-the-web, instead these main classes help to elaborate the
association with other entities part of the reality. The goods purchased by a customer at the
POS is not reflected in a specific sequence throughout the domain model. Therefore, it is
apparent that things in the domain model do not happen sequentially.

Another common mistake when creating a domain model is a model which depicts reality,
however, does not convey any information besides what is stated in the requirement
specification. This is a classic example of a naïve domain model where the main classes
might be the only ones which associate with the other classes. It also main focuses on what
the actors do and not instead of giving a static picture of what exists in relation to others.

The domain model presented as part of the solution in figure 3.1 is not naïve as it clearly
elaborates on giving a static picture of the classes which exist. The associations further help
elaborate what a specific class is and adds further value to the requirement specifications. An
instance of this can be seen in the association between ID and customer. An ID identifies a
customer. This association clarifies what the purpose of the class ID has. Additionally,
another example of a coherent association is the one between classes customer and item, item
isPurchasedBy customer. This association allows for a better understanding of the purpose for
an item in relation to the customer.

One class we decided to remove from the domain model was additionalPurchase. This class
was obtained from noun identification method as a part of the requirement specification. The
requirement specification stated that the cashier would ask the customer in case they wanted
to purchase anything more. To which the customer responds “no”. Initially, we decided to
associate this class to both the cashier and the customer. There was an association of cashier
asksFor additional purchase (class). As well as customer saysNoTo Additional purchase

10
Object- Objected Design Seminar 1
Solution
(class). We decided to remove the additional purchase class from the final domain model
since this class depicts a direct interaction between the classes cashier and the customer.

The system sequence diagram, SSD in figure 3.2 displays the system under development as
well as the actors interacting with it. These actors obtained from the requirement specification
include the cashier, the external accounting system, the external inventory system, the printer,
and the discount database.

In the final solution, the cashier sends a request to the system to end the sale. Here we chose
to delay the return message from the system to end the sale. This is because the cashier needs
to send an additional request to the system to get the discount. This is signified by the sale
operation sendDiscountRequest(customerid). The cashier sends the requests with a parameter
customer id which allows the system to fetch the specific discount for that customer. This in
turn continues with the system sending a request to the external system discount database to
fetch the discount information about a specific customer. This is illustrated by the system
specification fetchDiscountInformation (customerId). Thereby the total amount of sale is sent
back as a return message for the discount request instead of a returning an end sale message
to the cashier.

Lastly, the sale completely ends once the system sends its last request to the external system
of a printer. The request entails that the printer prints out the receipt which contains the sale
information gathered and organized by the system. This request has no return message since
the output will be a physical object seen by the cashier. Hence no need for a return message
to the cashier from the system.

In the final solution of the system sequence diagram, we chose not to include an external
system called the register. It is mentioned in the requirement specification that the program
increases the amount present in the register. We chose to look at the register as an internal
part of the system. Hence the system will automictically update the amount present in the
register once the system receives the enterAmountPaid request from the cashier. Thus, the
register is updated at the same time when the system updates its external parts with the sale
information.

11
Object- Objected Design Seminar 1
Solution

12