Guidelines for the

homework

Dr. Balázs Simon, BME, IIT 1

Mandatory tools
 For class diagrams and other diagrams:
 WhiteStarUML: https://sourceforge.net/projects/whitestaruml/
 For sequence diagrams, one of the following:
 WhiteStarUML
 Web sequence diagrams:
https://www.websequencediagrams.com/
 You must not use any other tool!
 If the tool does not follow the standard notation, make
sure to describe this in the submitted documentation

Dr. Balázs Simon, BME, IIT 2

To be uploaded
 The following files in a single ZIP file
 Documentation according to the template, as a PDF file
 Requirements
 Use-case diagram and use-case descriptions
 Class diagram
 Description of the classes
 Sequence diagrams
 State machines
 Work activity log
 Diagrams:
 WhiteStarUML: the complete model in the tool’s own UML format
 each sequence diagram on a separate tab
 Web sequence diagrams: the textual sources of sequence diagrams as
separate TXT files
 in case you used this tool instead of WhiteStarUML for sequence diagrams
 but the sequences must conform to the class diagram designed in
WhiteStarUML

Dr. Simon Balázs, BME, IIT 3

Methodology
 Most important advice: Think!
 You can discuss ideas with each other in general
 But you have to draw the diagrams on your own!
 Don’t copy any parts of the diagrams from each other,
or draw the diagrams together!
 Submissions with plagiarism won’t be accepted!

Dr. Balázs Simon, BME, IIT 4

Expected solution
 Object-oriented design
 distribute responsibilities (methods) between classes evenly
 model the world of the game, think about how the real world
works
 the model should be easily extendable and maintainable in case
new requirements arrive
 Concentrate only on the logic of the game
 the model should have functions that can be called by the
controller
 the controller calls functions when a key is pressed, the mouse is clicked
or a timer ticks
 starting from these functions all the other functions should be accessible
through sequence diagrams
 don’t include the controller or the view (graphics) in the model
at all
 no multiple threads
Dr. Balázs Simon, BME, IIT 5
Expected solution
 The model has an expected core: the most essential
classes and their most essential connections (dependency,
association, inheritance)
 make sure to find this core and do it correctly
 Make sure your diagrams are consistent with each other
 functions on sequence diagrams should exist on the class
diagram
 each function on the class diagram should appear on at least
one sequence diagram
 If the class diagram is too large, split it into multiple pages
 Each sequence diagram must fit to a single page and must
be readable
 you can modularize sequence diagrams by drawing the
sequence of a function on a separate diagram

Dr. Balázs Simon, BME, IIT 6

Avoid serious mistakes on Class diagrams
 The core classes or their connections missing
 The class diagram is not a single graph
 if the classes don’t know each other, your model does not work
 Using attributes instead of associations
 Not an object-oriented solution
 responsibilities not distributed evenly
 a single class does everything
 classes with only attributes and getter-setter methods
 type checking:
 type cast, instanceof, is, etc.
 type encoded as int, enum, etc.
 capability functions: is...(), can...()
 Empty descendant classes of concrete classes
 Syntactically incorrect diagram
 e.g. incorrect inheritance, dependency, association, composition, etc.
 Controller, threads, graphics, coordinates, etc. in the model
Dr. Balázs Simon, BME, IIT 7
 Common serious
mistakes on Sequence
diagrams

Dr. Balázs Simon, BME, IIT 8

Q1. Problem I.

Problem: a finished function calls another function

Dr. Balázs Simon, BME, IIT 9

Q1. Problem II.

Problem: a function calls two functions at the same time

Dr. Balázs Simon, BME, IIT 10

Q1. Synchronous function calls must be properly nested
 Problems if violated:
 inconsistent diagrams
 functions cannot be implemented
 Rules:
 function calls must be properly nested
 nesting follows the execution stack
 see call stack in programming languages (e.g. debugger or exception
stack trace)
 Exceptions:
 sequence diagram for a multi-threaded execution
 but function calls must still be properly nested per thread

Dr. Balázs Simon, BME, IIT 11

 Problems:
Q2. Problem an inactive lifeline calls a function
sequence starts from two different points

Dr. Balázs Simon, BME, IIT 12

Q2. Only active lifelines can make a function call
 Problems if violated:
 inconsistent diagram
 functionality cannot be implemented
 Rules:
 only a running function can make a function call
 sequence diagrams have only a single entry point
 unless there are multiple threads
 Exceptions:
 the UML tool may not support execution specification:
 for the first lifeline
 for another thread
 (but: the rule still stands, even if the execution specification is
not visible in the diagram)

Dr. Balázs Simon, BME, IIT 13

Q3. Problem

Problem: an interface calls a function

Dr. Balázs Simon, BME, IIT 14

Q3. Only concrete functions can make function calls
 Problems if violated:
 the diagram shows implementation for an abstract method or
an interface
 Rules:
 interfaces/abstract method cannot call other functions
 only concrete methods can make function calls
 don’t display polymorphic behavior in an interface/abstract class

Dr. Balázs Simon, BME, IIT 15

Q3. Solution

Diagram is cut here,

no implementation.

Dr. Balázs Simon, BME, IIT 16

Q4. Problem

Problems:
- type check
- polymorphic behavior displayed as alt

Dr. Balázs Simon, BME, IIT 17

Q4. Create separate diagrams for polymorphic behavior
 Problems if violated:
 complex diagrams
 polymorphic behavior shown as alt means type checking:
violation of OCP
 this is actually the internal implementation of the programming
language, it should not be displayed explicitly
 Rules:
 end the call in a polymorphic (virtual) call
 even if it is a call to an interface or abstract method
 draw separate diagrams for all descendant types starting from
the overridden method

Dr. Balázs Simon, BME, IIT 18

Q4. Solution

Dr. Balázs Simon, BME, IIT 19

Q5. Problem

Problem: separate objects have a common lifeline

Dr. Balázs Simon, BME, IIT 20
Q5. Different objects of the same type should have different lifelines

 Problems if violated:
 method calls running to the same lifeline cannot be separated
for different objects
 behavior is ill-defined
 Rules:
 model different objects of the same type with different lifelines
 use different names for them

Dr. Balázs Simon, BME, IIT 21

Q5. Solution

Dr. Balázs Simon, BME, IIT 22

 Problem: different behavior of the same function
Q6. Problem

Dr. Balázs Simon, BME, IIT 23

Q6. Functions should be consistent across diagrams
 Problems if violated:
 the sequence cannot be implemented
 the same method cannot have multiple different behaviors
 Rules:
 make sure that the same method has the same behavior in all
diagrams
 Exceptions:
 the same function can display different but similar behavior in
different diagrams based on the object’s internal state or based
on different conditions
 but these behaviors should not contradict each other

Dr. Balázs Simon, BME, IIT 24

Q7. Problem

Problem: calling a function on an object we do not know

Dr. Balázs Simon, BME, IIT 25

Q7. Make sure the client knows the server
 Problems if violated:
 the sequence cannot be implemented
 Rules:
 make sure the caller knows the target object
 either through an association
 or gets to know it by (dependency):
 passed as a parameter
 returned from a previous call
 created by the caller

Dr. Balázs Simon, BME, IIT 26

Q7. Solution

Dr. Balázs Simon, BME, IIT 27

Q8. Problem
Field Thing

+Accept(t: Thing) +Meet(t: Thing)

Pacman Monster

+Die() +Meet(t: Thing)

static type of parameter t is Thing

dynamic type of parameter t is Pacman

Problem:
calling a method inaccessible through
the known static type

Dr. Balázs Simon, BME, IIT 28

Q8. Make sure the client makes calls through the server’s known static type

 Problems if violated:
 the sequence cannot be implemented
 downcast results in a violation of LSP and OCP
 Rules:
 make sure the method called is available through the known
static type of the server

Dr. Balázs Simon, BME, IIT 29

Q8. Solution
Field Thing

+Accept(t: Thing) +Meet(t: Thing)

+MeetPacman(p: Pacman)
+MeetMonster(m: Monster)

Pacman Monster

+Meet(t: Thing) +Meet(t: Thing)

+Die() +MeetPacman(p: Pacman)

Dr. Balázs Simon, BME, IIT 30

Q9. Problem
Problem: violation of TDA

Dr. Balázs Simon, BME, IIT 31

Q9. Tell, Don’t Ask (TDA)
 Problems if violated:
 checking the condition may be forgotten in some places
 violation of DRY
 if checking for type: violation of OCP
 The violation of TDA means that the responsibilities are
not at the right place
 Rules:
 do not check the type of the target object
 do not check the state of the target object
 let the target object behave based on its own type and own
internal state
 Exceptions:
 checking the pre-conditions before calling a method
 e.g. prevent an exception when popping from an empty stack

Dr. Balázs Simon, BME, IIT 32

Q10. Problem
Problem: “Christmas tree”
a single object does everything

Dr. Balázs Simon, BME, IIT 33

Q10. Distribute responsibilities evenly
 Problems if violated:
 god class
 responsibilities not at the right place
 Rules:
 distribute responsibilities evenly
 avoid god classes
 Exceptions:
 sequence diagrams can look like this “Christmas tree”, if the
trunk of the tree is not always the same
 since if all diagrams are put together there is no single trunk

Dr. Balázs Simon, BME, IIT 34

Q11. Problem

Here the violation of the LoD and TDA

is OK, since Pacman steps by itself, it is
not pulled by the next Field

Problem: “Christmas tree”

Here the violation of LoD is bad,
because the world does not work
like this.

Dr. Balázs Simon, BME, IIT 35

Q11. Law of Demeter
 Problems if violated:
 “Christmas tree” sequence diagram: chaining method calls means
dependency on all the items of the chain
 even if the chain is split to multiple pieces: internal links of the chain are
saved in local variables
 Rules:
 don’t talk to strangers
 a method of an object should only invoke methods of:
 itself
 its parameters
 its members
 objects it creates
 provide a method in each object of the chain to delegate the call to
the next object
 model the real world
 Exceptions:
 if it would lead to the combinatorial explosion of methods
 if the world behaves differently

Dr. Balázs Simon, BME, IIT 36

Q11. Solution

Field f2 delegates the call: Pacman does not know the Pellet directly

Dr. Balázs Simon, BME, IIT 37

Summary
 Object-oriented design is expected
 Think it through thoroughly
 Putting together the sequence diagrams like LEGO bricks,
the complete behavior should be able to be derived

Dr. Balázs Simon, BME, IIT 38