Report UML
-
Upload
leandro-tome-martins -
Category
Documents
-
view
217 -
download
0
Transcript of Report UML
-
7/27/2019 Report UML
1/14
UML DIAGRAMS FOR A BOAT LIFT SYSTEM
Names: Leandro Martins and Tim Bargmann
Course: UML Systementwurf - SysE
Lecturer: Professor Dr.-Ing. Gert Bikker
June, 2013.
-
7/27/2019 Report UML
2/14
Introduction:
The diagrams are very easy way to understand complex system behaviors. The
elements of a system are like components which can be associated in different ways to
make a complete UML diagram. These diagrams have a better impact on our
understanding. This paper introduces An Autonomous River Lock system.
An Autonomous River Lock is a system to improve the traffic in a river. It works
like a boat lift used to elevate a boat from a lower level to a higher level in the river.
The boat lift is composed by one lock door in each level of the river, light barrier
sensors, traffic signals and a pump station.
If any light barrier sensor be broken and then reestablished, it means that a
boat passed the lock door. The traffic light shows if the boat lift is available to be used.
In case that there is a boat or the water is in an incorrect level for the boat witchintend to get in the lift, the traffic signal switches to red.
When the water level is incorrect for any boat, it has to send a radio signal to
the controller and the pump station starts its operation to pump in or out water the
system to get the level in desired one.
Use-Case Diagram:
In the beginning, an Use-Case diagram (UCD) was modeled considering the
milestone 1, i.e. It was considered the initial situation where the boat had to be
elevated from the lower to higher level, in this situation the lower lock door was
opened and the lower traffic light was green. Thus, considering the boat as an actor,
the use cases for this milestone depict since the boat drives in to the boat drives out
the lift. For this, there is a sequence, like breaking light barrier sensors, closing the lock
door, switching the traffic light to red, pumping water in the system, stopping pump
station, opening the higher lock door, and breaking the higher light barrier sensor to
the boat drives out.
Then, in the Milestone 2, the UCD was implemented considering that the boat
sends a radio signal before getting in the system, and it also forecasts an emergency
button. Now, in this milestone, it was increased some use cases regarding the radio
signal, which means that the system has to verify and correct the water level
automatically. It includes verify where the radio signal comes from and correct the
water level pumping in or out water of the system. It was also modeled the emergency
button that stops all the process when activated and restart the process bringing all
modules to safety mode.
-
7/27/2019 Report UML
3/14
Finally, for the Milestone 3, the light barriers sensor was considered more
complex and considered to be able to identify which direction boats break it and if
boats really passed it. As the following picture, we can see the final UCD regarding the
3 milestones.
Figure 1: Use-case diagram.
Sequence Diagrams:
In the Sequence Diagrams (SD) were considered the communication between
the objects and the controller. In the first milestone, all the objects communicate
directly with the controller and the sequence since a boat passes the lower lock door
until crosses the higher lock door were modeled. In this diagram are showed mainly
the sequence in which the objects communicate with the controller in more detailsthan the UCD. We can see also the time of the doors take to close and to open after
the light barrier sensor gets broken.
Regarding the milestone 2, it was implemented the SD for the radio signal and
emergency button. In the radio signal SD, when the radio signal is sent, the controller
checks if the traffic light is set green in the lower level or higher level. So, depending on
which traffic signal is green, it supposes that the boat comes from the counter level. So
the sequence shows the signal switching to red and the system working to correct the
water level to ability the boat gets in. The emergency SD shows the situation when the
emergency button is pressed. Thus, whatever the system are processing, all the
-
7/27/2019 Report UML
4/14
processes stop until this button be pressed again. That means the problem was solved
and the system returns to initial situation.
For the milestone 3, the light barrier sensor was simply replaced by a new
technology sensor, thus the SD shows the implementation of this new sensor working
in the same way that was depicted before. The following figures show the SD for the
main function of the boat lift, the function of the radio signal and the function of
emergency button.
Figure 2: Sequence diagram for Boat Lift.
-
7/27/2019 Report UML
5/14
Figure 3: Sequence diagram for Radio Signal.
Figure 4: Sequence diagram for Emergency Button.
-
7/27/2019 Report UML
6/14
State chart Diagram:
The State Chart Diagram (SCD) in the milestone 1 depicts the behavior of the
controller. The sub-state chart diagram LiftTheBoat shows the function of the system.
In this case it was considered the boat coming from the lower level and going to the
higher level. So basically the controller controls the lower door to close after a time
passed when the light barrier was broken, initiates the pump station and stops it when
the desired level is reached and controls the opening and closing of the upper door
regarding a time. After that the controller generates an event boat outside and the
system returns to the initial position.
In the milestone 2 the SCD for the controller was remodeled regarding the
radio signal and emergency button. If an event radio signal is generated, the controller
first checks the currently level of water by water level sensors. So if the water level
sensor is equal to 0 the currently water level is low, and considering that a radio signal
was sent, it means the signal came from the higher level. So the controller has to
follow a sequence to correct water level, controlling the doors and the pumping
station until it reaches the final state where the system are ready to start its operation
to elevate the boat. When the water level is set as 2, it means that the water level is
high, and if a radio signal was received by the controller, it has to correct the water
level to the lower level following similar sequence of the previously condition. Still
inside the controller SCD, there is other sub-state chart regarding the emergency
button. If the controller receives a signal indicating that the emergency button was
pressed the system enter in a state described by the emergency button state chart.
All the other components which the controller communicates with were also
modeled in milestone 2. The SCD for the doors shows the communication between this
object and controller when the controller generates the events open and close the
door. It shows also if the emergency button is pressed, the doors stop and an
emergency state is requested until the problem be solved and the button be pressed
again. Then, it was modeled the state chart for the pump station. When an event to
initiate to pump is requested the pump station start to pump water in or out
depending on the water level sensor, and when the desired level is reached, the
controller sends a message to stop to pump. Again, if the emergency is pressed, a
special state is requested and the pump station stops its operation. The state chart for
water level sensor shows the states when the water level is high or low and in each
state the controller sets the water level condition (0 or 2). The state chart for the
traffic signal shows the states for green and red signals and how they change the
states. Finally, the state charts for light barrier sensors show the states for them. There
are um state for initialization, one for when the light barrier is broken and one for
when the light barrier is established.
-
7/27/2019 Report UML
7/14
The milestone 3 is about the replacement of the light barrier sensors by
complex ones. So, after one sensor is initialized, it has to decide if the light barrier was
broken by the boat coming outside or inside the lock door. Then the states changes
until the final state, where the boat is completely outside or inside the lock doors,
otherwise, if the sensors were not reestablished correctly, it means that the boat didnot pass completely the lock doors. The following figures show all the state charts for
better comprehension.
Figure 5: State chart diagram for Controller.
-
7/27/2019 Report UML
8/14
Figure 6: Sub-state chart diagram for controller regarding Boat Lift.
Figure 7: Sub-state chart diagram for controller regarding the Radio Signal.
-
7/27/2019 Report UML
9/14
Figure 8: State chart diagram for the function of the Doors.
Figure 9: State chart diagram for Emergency Button function.
-
7/27/2019 Report UML
10/14
Figure 10: State chart diagram for Light Barrier Sensors function.
Figure 11: State chart diagram for Light Barrier Sensors New Technology.
-
7/27/2019 Report UML
11/14
Figure 12: State chart diagram for Pump Station function.
-
7/27/2019 Report UML
12/14
Figure 13: State chart diagram for Traffic Signal function.
Figure 14: State chart diagram for Water Level Sensor Function.
Class Diagram:
This Class Diagram (CD) was initially modeled in milestone 1 in order to give an
overview about the interaction between the classes that compose the system. The
main class is the controller and the secondary ones are pump station, door, light
barrier and traffic signal. In the milestone 2 was implemented the class diagram, since
the system started to check the water level and corrected it. So, in addition to existent
classes, the water level sensor class and emergency button were created. In the
controller class is possible to see the attributes for that, very important for the
function of the system. In milestone 3, the only modification in class diagram was the
inclusion of the Light Barrier new technology sensor. The following figure shows the
final class diagram.
-
7/27/2019 Report UML
13/14
Figure 15: Class diagram.
Object Diagram:
The Object Diagram (ODO was modeled in order to represent the correlation
between the instances of the classes. For the first milestone, considering the initial
situation when the water level is low, the lower traffic signal is green and the boat
comes from the lower level, the some objects were implemented considering the
existents classes. So, for example, in this milestone it was used two instances of the
class door, i.e. lower lock door and upper lock door, one instance for pump station
class, two instances of traffic signal class, i.e. lower traffic signal and upper traffic
signal, two instances of light barrier sensor, i.e. lower light barrier and upper light
barrier, and one instance of the controller. The diagram shows the attributes for each
object.
In the milestone 2, the OD was remodeled including the instance of water level
sensor and one instance for emergency button class. The following figure shows the
final OD.
-
7/27/2019 Report UML
14/14
Figure 16: Object diagram.