Written by:
- Michal Elisha
- Shlomit Ashkenazi
In this assignment, we extended the abilities and applications of UndoableStringBuilder (which we have built in the previous assignment):
- At the first part we implemented the Observer design as we learned in class
- At the second part we debuged and analysed our program using JVM
Rerquirements - IntelliJ enviorment
1.Download our project as ZIP file 2.extract it localy 3.open IntelliJ 3.on the top right press File->new->project from existing sources:
4.nevigate to the path to our project folder:
- press Next on the following:
- then finally the extraction will end:
you can see the project now. (should look like this):
Run&Debug: if you are not familiar with IntelliJ: DEBUG - https://www.jetbrains.com/help/idea/debugging-your-first-java-application.html RUN - https://www.jetbrains.com/help/idea/running-applications.html COMPILE - https://www.jetbrains.com/help/idea/compiling-applications.html
when you get in the Tests.java class, if you are interested to see the "behind the scences" of a test function , click on the left of the first row of the method and press "debug". in this example, we debugged the concreteMemberTest() method:
-
initialization of g - object of type groupAdmin
-
groupAdmin after registration on the first concrete member
-
assert the modify() and update() functions - checking the value of usb of the members
-
assert the modify() and update() functions and also the undo() function from UndoableStringBuilder class:
we have created a UML to explain how we implemented this part:
- as you can see the 'observer' == 'Member' an interface that's being implemented by ConcreteMember (and therefore the 'update' method is implemented at ConcreteMember - although we didn't state it explicitly in the UML).
- by this analogy, 'observable' == 'Sender' an interface that's being implemented by GroupAdmin (also here all methods mentioned at 'Sender' are actually being implemented at 'GroupAdmin').
the goal of JVM is to show us how much memory the data structures we use takes, so we can track it and try to optimize the code's efficiency.
the totalsize method on initialized concrete members and the groupAdmin class before the registration shows us the following data:
the Footprint method on the groupAdmin class before the registration shows us the following data:
the Footprint method on the concrete members after the update (modify() method in groupAdmin ) shows us the following data:
the Footprint method on the groupAdmin class after the update (modify() method in groupAdmin ) shows us the following data:
we can see that the list now contains the members, and so the memory allocated for the list and for groupAdmin has increased
*note: in order to use the JVM capabilities, we used Logger as Natan (the teacher) explained to us at his SHEUT KABALA (Link - https://ariel-ac-il.zoom.us/rec/play/DISm8hWeT72rigLJrvBO7qyvMXBhaZOoXEMBSOLd4jmxMoqpF1srWUnfS-MlHVGOznSDSOlv7aA9E44C.8yjo9No50jJwHQWW?continueMode=true&_x_zm_rtaid=2FfKobIHSwW9RPlxRtmiCA.1671577797488.a88248ea7530a8531db2fdeeb2f51028&_x_zm_rhtaid=569 )
main