Module6 - Object Oriented Design - UML Diagrams in Design II
Module6 - Object Oriented Design - UML Diagrams in Design II
Software Engineering
Computer Science
Academic Year 2023/2024
1
Contents
1. Introduction
• What will we learn
2. Object Oriented Design
- Design principles
- Design patterns
- Operation contract and Class diagram normalization
- Object responsibilities assignment
- Behavioral modeling. Sequence diagram and State diagram
- Software Architecture
- Components and Packages
1. Introduction
What will we learn?
OOA/D Design
OOA/D
Exercises
2.3 UML Diagrams in Design
Sequence diagrams
(Event diagrams, Event scenarios)
• Sequence diagrams are one of the most widely use UML diagrams. During the design phase of
software development, sequence diagrams help developers and architects plan and understand how
different components and objects will interact to accomplish specific functionalities. They provide a
blueprint for the system’s behavior.
• They allow a temporal (dynamic, evolution over time) representation of interactions between two or
more entities within a scenario or use case.
• Capture the exchange messages between classes and actors and the timeline of events. These
diagrams focus on showing detailed interactions, such as which objects are involved in an interaction,
which methods are invoked, and the sequence of events.
2.3 UML Diagrams in Design
• Two read directions:
ü Horizontally : Arrows indicate
direction of the message.
ü Vertically : Chronological
order of the messages.
• Elements of a sequence diagram:
ü Participants
ü Lifeline
ü Interaction messages
ü Activation or execution
specification
2.3 UML Diagrams in Design
• We will further specify each use case (when it starts, the flow of events, and when it ends). We will
also include variations on each use case that represent exceptions.
• To illustrate, we can write a description for the Reader use case Request passport stamp:
• Main flow of events: The use case starts when the Reader chooses to
request a passport stamp. The system will compare the Reader’s
unspent minutes to the number of minutes needed to earn a passport
stamp and add an empty stamp slot to the Reader’s passport. The
number of minutes spent on the stamp are deducted from the
Reader’s account, ending the use case.
ü We will also create static system views composed of class diagrams, which show
the responsibilities of each class within the system. One class might have
responsibilities related to many collaborations. In other words, one class might
have responsibilities related to fulfilling many use cases.
2.3 UML Diagrams in Design
• We will use the Request passport stamp use case as an example:
ü In the Request passport stamp use case, a Reader (an actor outside) chooses to request a passport stamp,
and the system compares the Reader’s unspent minutes (minutes that have not already been awarded a
passport stamp) with the amount needed to earn a stamp. If the Reader has enough minutes, the minutes
will be deducted from their account and an empty stamp slot will be added to their passport. If the Reader
does not have enough minutes, the system will inform them and no changes will be made.
• Finding objects and classes, requires both invention and discovery. To discover objects within the
responsibilities, we should look for things. You can start with nouns in a description, but do not
limit yourself to nouns or expect that all nouns will be objects. Objects might be, for example,
concepts, organizations, events, algorithms, or interactions. We might also invent objects to
manage an interaction between other objects or facilitate some other collaboration within the
system.
• We will assess objects in our modeling according to other principles, such as whether they are a
natural part of the design or a collaboration mechanism, whether the same pattern of
collaborating objects has been used successfully to solve problems like the problem you are
solving, whether each object has a coherent set of responsibilities (high-cohesion), and whether
the objects are loosely coupled, meaning they are as independent as possible from the rest of the
system.
2.3 UML Diagrams in Design
Example: Sequence diagram and Design – Library
• In our use case, Request passport stamp, we can see what objects we can discover and invent.
• If we read the use case and responsibilities we found in the use case, we find some candidates: a
reader account, a passport, and a stamp. These are “things” in our list of system responsibilities.
If they are things which aggregate data and have a coherent set of responsibilities related to that
data, then they may end up as objects in our system.
• There are also several responsibilities related to the user-computer interface, such as giving the
Reader the choice to request a stamp, displaying an empty stamp slot in the passport, and
providing information that informs the Reader if the stamp request was rejected. It is practical to
separate the interface from the core part of our system that models the library reading program,
so we will factor out interface responsibilities from our discussion here.
• We have discovered several candidate objects from the Request passport stamp use case: reader
account, passport, and a stamp.
2.3 UML Diagrams in Design
Example: Sequence diagram and Design – Library
• We assign to the ReaderAccount object the name and uniquely identifying information for a
Reader, as well as the free minutes (minutes that have not been spent on a passport stamp), and
a passport. The ReaderAccount object allows the Reader to log minutes and request a stamp.
• This data and these responsibilities all relate to the reader account, so encapsulating this data
and these responsibilities together gives us a coherent object.
• The Passport object contains a list of stamps and can process stamp requests and allow the
Reader to choose a stamp. This is also an encapsulation of data and responsibilities that relate to
one “thing” from our requirements (the Passport object).
• The Stamp object will contain some data (such as text or an image, depending on whether we
have a graphical or text interface), and a minute value (the “cost” of the stamp). The Stamp
object will be able to display itself.
2.3 UML Diagrams in Design
Example: Sequence diagram and Design – Library
• We can draw a class diagrams for the ReaderAccount, Passport, and Stamp classes
with the responsibilities and data that we have assigned so far:
2.3 UML Diagrams in Design
• The next class diagram figure below shows the associations between these classes.
ü The Passport class has a composition association with the ReaderAccount class, because there should be one
passport for each Reader. A ReaderAccount has one Passport that is created when the ReaderAccount is
created, and the ReaderAccount destroys the Passport when the ReaderAccount is destroyed. Because the
Passport object is created with the ReaderAccount and is destroyed with the ReaderAccount, it is part of the
ReaderAccount.
ü The Passport object contains a list of Stamp objects. The list will be empty before the Reader logs minutes and
requests a stamp, so the cardinality of the Stamp objects is zero to many. Because there will be potentially
many ReaderAccount objects and therefore Passport objects, but a Stamp will not necessarily be contained in
any Passport lists, the cardinality of the Passport objects is also zero to many.
ü A Stamp object does not have a composition relation with a Passport object, as a Stamp object might be
displayed in many Passport objects (and therefore does not belong to, or live and die with, any one Passport
object). Therefore, the association between Passport and Stamp is a single-direction navigation association.
2.3 UML Diagrams in Design
Example: Sequence diagram and Design – Library
• The UML diagrams that we have looked at for our case study thus far are structural diagrams.
• They do not show the dynamic behavior of the system being developed. In other words, they do
not show how work is accomplished. A dynamic view or model will show the way that objects
collaborate to complete the tasks.
• A sequence diagram will show the objects that are collaborating to fulfill a use case by showing the
time ordering of the messages they send.
• We do not yet know what messages our objects will send to fulfill the Request passport stamp use
case. Drawing a sequence diagram will allow us to propose a candidate sequence of messages. We
can then use the full set of sequence diagrams to refine our class designs.
• The next chart is a proposed sequence diagram for the Request passport stamp task or use case.
2.3 UML Diagrams in Design
Example: Sequence diagram and Design – Library
• The next chart is a proposed sequence diagram for the Request passport stamp task or use case.
• Generally, the object that begins the use case is on the left side
of the diagram, with the objects most involved in the use case
to the left side and less important objects to the right.
2.3 UML Diagrams in Design
ü The next Request passport stamp use case begins when the
ReaderAccount object sends a request_stamp message to
the Passport object.
ü The ReaderAccount passes itself as a parameter, so the
Passport object can send messages back to the
ReaderAccount as needed.
ü You can see, by the activation box on its lifeline, that the
Passport object has control for the rest of the diagram as it
handles the request_stamp message.
ü The first message it sends is the get_free_minutes message
to the Passport object. The Passport object responds to the
message by returning the number of free minutes it is
storing. The Passport object will then determine if the
ReaderAccount has accumulated enough free minutes to
earn a stamp. This logic, as it does not require any message
sends, is not shown in the diagram. The Passport object will
also add an empty stamp slot to itself, which, at this time,
also does not require message sends.
2.3 UML Diagrams in Design
ü The Passport object will send a deduct_free_minutes
message to the ReaderAccount object with the number of
minutes to deduct as a parameter. The Passport object is
responsible for knowing how many minutes each stamp
costs, and so this number will be the same or smaller than
the free_minutes value returned by the ReaderAccount in
response to the get_free_minutes message.
ü The ReaderAccount object will deduct the minutes from its
total free minutes. Again, because this operation does not
require a message send, it is not shown here.
ü Finally, the Passport object will complete processing the
request_stamp method by returning a status value. For the
sequence diagram shown, this will be a success value, as this
sequence diagram shows the messages that are sent if the
ReaderAccount has enough minutes to earn a stamp. If the
ReaderAccount did not have enough minutes, the Passport
object would not send the deduct_free_minutes message
and would return a failure status.
2.3 UML Diagrams in Design
ü While designing, we might realize that the Stamp objects would benefit from a manager object, a single object
responsible for creating and maintaining the list of all Stamp objects.
ü There is no StampManager in our description, but some system responsibilities do not seem to belong in any other
object in our system, such as displaying the list of available stamps when the Reader chooses a stamp. There is a need
for some organization of the Stamps beyond a simple list, so we invent the StampManager object.
• The output of the execution shows that the ReaderAccount object does not change after an
unsuccessful stamp request – its minutes and Passport object remain in the same state as before
the call.
• A ReaderAccount object with the exact number of minutes needed for a stamp has the minutes
reduced to zero and the stamp added to the Passport object, and a ReaderAccount object with
more minutes than are needed has the minutes reduced by the cost of a stamp and a stamp
added to the Passport object.
• The design of the system that fulfills the Request passport stamp use case uses encapsulation
to separate the responsibilities and data of the system into objects
2.3 UML Diagrams in Design
Example: Sequence diagram and Design – Library
• The design of the system that fulfills the Request passport stamp use case uses encapsulation to
separate the responsibilities and data of the system into object:
ü Each object represents either a “thing” from the original design or an invention with a
coherent set of responsibilities and data that facilitates fulfillment of the use case.
ü Well-designed encapsulated objects have the following advantages: Objects facilitate
information hiding, or restricting access to implementation details that are likely to change
as the system is developed and maintained.
ü Each object has an interface, or set of public attributes (usually methods), that other objects
in the system can use to interact with it. The implementation details of how information is
represented and how methods work is private to the object.
ü This way changes can be made to the object’s implementation without affecting other parts
of the system. If object data is private and the methods are carefully designed, then the
only way the data can be changed is in well-defined ways. It is less likely that data will
become corrupted if access to it must come through the object’s interface.
2.3 UML Diagrams in Design
Example: Sequence diagram and Design – Library
• The design of the system that fulfills the Request passport stamp use case uses encapsulation to
separate the responsibilities and data of the system into object:
ü Some well-designed objects can be reused in other systems, just as well-designed functions
can be reused. Objects can sometimes be replaced with other objects with similar
functionality.
ü For example, we might design our reading program software to allow an individual library to
use a passport stamp reward or a different sort of reward, such as an animated sticker book
to which the Reader can add characters and items.
ü If we design the system to be general enough (for example, if we use the language “request
reward” rather than “request stamp”), then we could allow individual libraries to select
whatever reward system they want. In the implementation, we would “plug in” the reward
object corresponding to the reward selected by the library.
2.3 UML Diagrams in Design
• These benefits do not come automatically with object-oriented design. They must be considered
and built in as the system is being designed.
• For example, it is difficult to design a reusable or replaceable component if the component is not
loosely coupled to the rest of the system – in other words, as independent as possible.
• Objects’ responsibilities should relate to their data, and they should protect the data from
manipulation that is not prescribed by the design of a use case.
• For example, the ReaderAccount allows the free minutes to be logged and a value to be deducted
from free minutes, but it does not allow the number of free minutes to be arbitrarily changed.
• Finally, if interfaces are carefully designed to provide the necessary functionality without relying on
a specific implementation, objects can be modified without requiring changes in the rest of the
system (If we decide that stamps should have a Surface image as part of their data, or that the
StampManager will store stamps in multiple lists by value, we do not need to make any changes to
the other objects in the Request passport stamp use case).
• Changes will be localized to the affected objects. Good object-oriented design can help us write
resilient, reusable programs.
2.3 UML Diagrams in Design
• You can learn more about Python implementation of UML models
https://youtu.be/k58R_CsvVoE?si=MPOQSb34MzXVu65m
2.3 UML Diagrams in Design
• You can learn more about Python implementation of UML Sequence diagrams
https://youtu.be/TpxuwZBVF2s?si=7TTzULkELXqOOVr5