1

ITSS SOFTWARE DEVELOPMENT/

SOFTWARE DESIGN AND CONSTRUCTION
Lab 08 - Class Design
Lecturer: NGUYEN Thi Thu Trang, [email protected]

1. SUBMISSION GUIDELINE
You are required to push all your work to the valid GitHub repository complying
with the naming convention:
“<MSTeamName>-<StudentID>.<StudentName>”.
For this lab, you have to turn in your work twice before the following deadlines:
 Right after class: Push all the work you have done during class time to
Github.
 10 PM the day before the next class: Create a branch named
“release/lab08” in your GitHub repository and push the full submission
for this lab, including in-class tasks and homework assignments, to this
branch. Remember to export your diagrams to PNG files and push them
with .astah files to GitHub.

2. IN-CLASS ASSIGNMENT
In this section, we will get familiar with the software detailed design process and
try ourselves with class design for the Case Study.
You are asked to work individually for this section, and then put all your file(s)
and directories to a directory, namely “DetailedDesign/ClassDesign”. After that,
push your commit to your individual repository before the announced deadline.
2.1. CREATE INITIAL DESIGN CLASSES
In this step, we try to map the analysis classes and design elements (e.g., class,
group of classes, package, subsystem). A design class should have a single well-
focused purpose and should do one thing well. We would identify design classes
by considering each class in the unified class diagram from architectural design,

HANDS-ON LAB GUIDELINES

© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
 2

along with its class stereotype. Note that we have not applied any design
patterns1 in this lab yet.
2.1.1. Design Boundary Classes

User interface (UI) boundary classes

In case of the Case Study, JavaFX 15 works as our tool to develop our UI. Thus,
from our architecture viewpoint, each UI boundary class is corresponded to
design class(s) handling the events/actions from humans which are captured in
corresponding FXML files. Although in JavaFX, the design class(s) is called the
“controller” of the FXML files, it does not play as the role of the control class in
UML. Consequently, most of those event handlers are quite simple, and hence the
mapping here is 1-1.

System/device boundary classes

In the previous lab, we have evolved the boundary class for Interbank into a
subsystem. This subsystem, however, has not well-designed: the
InterbankSubsystemController is so complex, and a part of the
InterbankBoundary might be reusable. There is only one external web
information system (i.e., interbank) in the current Case Study; however, the
future is an unknown whereas there are a huge number of systems that require
communication with REST APIs over HTTP. One of them could be the next
external system of our developing AIMS Software while the communication
protocols for those systems are similar and consistent. As a result, for the
reusability, we need a new class, for example, API, to be responsible for API
communication such as HTTP GET and HTTP POST. Besides, we would consider
the problem or the controller later.
2.1.2. Design Entity Classes
For the current Problem statement and the 2 use cases “Pay Order” and “Place
Order”, most of the entity classes in the architectural design are simple and could
be 1-1 correspondence to the design classes.
2.1.3. Design Control Classes
Likewise, most of the control classes in the architectural design are simple and
could be one-to-one correspondence to the design classes. However, the
InterbankSubsystemController is currently responsible for at least 2 tasks: (1)
1
A software design pattern is a general, reusable solution to a commonly occurring problem within a
given context in software design. See more at this link.
HANDS-ON LAB GUIDELINES
© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
 3

data flow control and (2) data conversion (e.g., to convert the requests with data
to the required format and to handle the response). Thus, we need at least
another class (e.g., JSON or MyMap) to take the responsibility of data conversion
(based on the design, this can also be reused when communicate with other web
information systems).

2.1.4. Group Design classes in Packages

A package is a general purpose mechanism for organizing elements into groups.
They provide the ability to organize the model under development. A package is
represented as a tabbed folder.
Later in this module, we will contrast “vanilla” packages, as defined above, with
subsystems.
When identifying classes, you should group them into packages, for
organizational and configuration management purposes.
The Design Model can be structured into smaller units to make it easier to
understand. By grouping Design Model elements into packages and subsystems,
then showing how those groupings relate to one another, it is easier to
understand the overall structure of the model.
You might want to partition the Design Model for a number of reasons:
• You can use packages and subsystems as order, configuration, or delivery
units when a system is finished.
• Allocation of resources and the competence of different development teams
might require that the project be divided among different groups at different
sites.
• Subsystems can be used to structure the Design Model in a way that reflects
the user types. Many change requirements originate from users; subsystems
ensure that changes from a particular user type will affect only the parts of the
system that correspond to that user type.
• Subsystems are used to represent the existing products and services that the
system uses.
When the boundary classes are distributed to packages, there are two different
strategies that can be applied. Which one to choose depends on whether or not
the system interfaces are likely to change greatly in the future.
HANDS-ON LAB GUIDELINES
© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
 4

• If it is likely that the system interface will be replaced, or undergo considerable

changes, the interface should be separated from the rest of the Design Model.
When the user interface is changed, only these packages are affected. An
example of such a major change is the switch from a line-oriented interface to
a window-oriented interface.
• If no major interface changes are planned, changes to the system services
should be the guiding principle, rather than changes to the interface. The
boundary classes should then be placed together with the entity and control
classes with which they are functionally related. This way, it will be easy to see
what boundary classes are affected if a certain entity or control class is
changed.
Mandatory boundary classes that are not functionally related to any entity or
control classes, should be placed in separate packages, together with boundary
classes that belong to the same interface.
If a boundary class is related to an optional service, group it in a separate
subsystem with the classes that collaborate to provide the service. The subsystem
will map onto an optional component that will be provided when the optional
functionality is ordered.
A package should be identified for each group of classes that are functionally
related. There are several practical criteria that can be applied when judging if
two classes are functionally related. These are, in order of diminishing
importance:
• If changes in one class' behavior and/or structure necessitate changes in
another class, the two classes are functionally related.
• It is possible to find out if one class is functionally related to another by
beginning with a class — for example, an entity class — and examining the
impact of it being removed from the system. Any classes that become
superfluous as a result of a class removal are somehow connected to the
removed class. By superfluous, we mean that the class is only used by the
removed class, or is itself dependent upon the removed class.
• Two objects can be functionally related if they interact with a large number of
messages, or have an otherwise complicated intercommunication.
• A boundary class can be functionally related to a particular entity class if the
function of the boundary class is to present the entity class.

HANDS-ON LAB GUIDELINES

© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
 5

• Two classes can be functionally related if they interact with, or are affected by
changes in, the same actor. If two classes do not involve the same actor, they
should not lie in the same package. The last rule can, of course, be ignored for
more important reasons.
• Two classes can be functionally related if they have relationships between
each other (associations, aggregations, and so on). Of course, this criterion
cannot be followed mindlessly but can be used when no other criterion is
applicable.
• A class can be functionally related to the class that creates instances of it.
These two criteria determine when two classes should not be placed in the same
package:
• Two classes that are related to different actors should not be placed in the
same package.
• An optional and a mandatory class should not be placed in the same package.

2.2. DEFINE RELATIONSHIPS BETWEEN CLASSES

To illustrate, the following figures show the relationships between classes. We do
not display the attributes and operations/methods of classes since it would be
hard for you to see the relationships.

HANDS-ON LAB GUIDELINES

© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
 6

2.3. CLASS DESIGN

In this subsection, we illustrate how to do class design step by step.

2.3.1. Class “InterbankInterface”

Attribute
None

Operation
# Name Return type Description (purpose)

1 payOrder PaymentTransaction Pay order, and then return the payment

transaction

2 refund PaymentTransaction Refund, and then return the payment transaction

HANDS-ON LAB GUIDELINES
© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
 7

Parameter:
- card - the credit card used for payment/refund
- amount - the amount to pay/refund
- contents - the transaction contents
Exception:
- PaymentException - if responded with a pre-defined error code
- UnrecognizedException - if responded with an unknown error code or
something goes wrong

Method
None

State
None

When you are programming, please always remember to do the programming

documentation immediately, especially public elements. The programming
documentation for this class is illustrated as follows.

HANDS-ON LAB GUIDELINES

© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
 8

Please see the following links for better understanding:

https://users.soe.ucsc.edu/~eaugusti/archive/102-winter16/misc/
howToWriteJavaDocs.html
https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html

HANDS-ON LAB GUIDELINES

© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
 9

2.3.2. Class “PaymentController”

Attribute
# Name Data type Default value Description

1 card CreditCard NULL Represent the card used for payment

2 interbank InterbankInterface NULL Represent the Interbank subsystem

Operation
# Name Return type Description (purpose)

1 payOrder Map<String,String> Pay order, and then return the result with a
message

Parameter:
- amount - the amount to pay
- contents - the transaction contents
- cardNumber - the card number
- cardHolderName - the card holder name
- expirationDate - the expiration date in the format "mm/yy"
- securityCode - the cvv/cvc code of the credit card
Exception:
- None

Method
- getExpirationDate: Given the String “date” representing the expiration date
in the format "mm/yy", this method convert it into the required format
“mmyy.” The algorithm is illustrated as follows.

HANDS-ON LAB GUIDELINES

© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
 10

State
None
2.3.3. State Machine Diagram for an “Order” Object
We only need to define states for objects having named states so that we know
how an object’s state affect its behavior and model its behavior. At first, we find
candidate classes having named states, then find all possible states for an object
of that class. After that, we model by drawing state machine diagram.
Clearly, “Order” object is one of those having named states. The following figures
illustrate the state machine diagram for an “Order” object from the moment when
a customer places an order until the time an admin processes the order.

HANDS-ON LAB GUIDELINES

© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
 11

2.4. CLASS DIAGRAM

Finally, we put all the design classes into 1 general class diagram. Note that we
shall not show the details of subsystem(s). In case there are too many details, we
can either do the same with packages or make class diagrams for each
package/subsystem.

HANDS-ON LAB GUIDELINES

© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
 12

2.5. CLASS DESIGN FOR “PLACE RUSH ORDER”

In this part, you are asked to design classes for “Place Rush Order” step-by-
step by yourself.
When you complete your tasks, please export your work into a PDF file, and then
save it inside “DetailedDesign/ClassDesign” directory. Remember to push all your
work to your individual repository.

HANDS-ON LAB GUIDELINES

© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E