System Modelling. Lecture

Size: px

Start display at page:

Download "System Modelling. Lecture"

Cornelius Holt
5 years ago
Views:

1 System Modelling Lecture

2 Lecture Objectives Storyboards as a base Objects to Classes GUI design with Story-Driven Modelling Intro to the project: 25pts

3 Story-Driven Modeling 1. Concrete behavior steps described by the client and captured in a scenario (working with client to make it concrete) 2. Modeling system "snapshots" with Object Diagrams for each scenario step and producing a Storyboard as a result 3. Modeling UML class diagram based on the Storyboard (still depends on experience) First step to abstraction (UML class diagram model only the static structure of program) Common mistake to use it for behavior design discussions 4. GUI Design and Initialization methods 3/59

4 Objects to Classes

5 Modeling UML class Diagram Going abstract Start assigning types to objects and keep an eye on the class diagram to avoid introducing of similar class twice Next, for each property of an object, we introduce an attribute declaration in the corresponding class Associations between classes and multiplicities based on the observed object diagrams 5/59

6 Modeling UML class Diagram? 6/59

7 Modeling UML class Diagram Simple Solution, but stresses the amount of logic needed to handle the special case of Exam room Restriction: nearly always bad idea, need to check initialization 7/59

8 Changes in plan? What if courses may move to the other rooms when student is studying? Hint: courses have some behavior and becoming mobile 8/59

9 Changes in plan? 9/59

10 Changes in plan? 10/59

11 Inheritance vs Association If there is some attribute/behavior that belongs to many classes

12 Inheritance vs Association ExamRoom Room Student 12/59 Student can be associated with objects of different class Capture this behavior in one place, like Space class

13 Modeling UML class Diagram A little more complicated and flexible solution if we expect changes in the plan 13/59 Example: If we introduce more kind of rooms (prerequisition to take the course)

14 Danger of Inheritance Hierarchy > 7 can explode the number of methods, confusing, poorly maintainable, overburdened local namespace Depth > 3 overridden methods that call each other and jumping around in the hierarchy are very difficult and error-prone to implement The derived class does not in practice, usually only specializes things, but often you have to overwrite methods in order to "generalize" behavior of the upper class, which contradicts the concept 14/59

15 Use of Inheritance Inheritance is usually used only in cases of fulfilling design pattern Don't use inheritance if you are unsure Maintanability, readibility become harder The bigger the project the more dangerous is inheritance Learn more in the Design Pattern course 15/59

16 Modeling UML class Diagram 16/59

17 Multiplicities and Associations Multiplicities and bounds Put bounds only when it is important for application Lower bounds: hardly ever Upper bound: seldom Try to introduce new object and keep logic for associations in one place 17/59

18 Classes to Code 18/59

19 Class Diagram to Code Trivial task that can be automatically performed using code generators class class Student Student {{ 19/59

20 Class Diagram to Code class class Student Student {{ private private String String name; name; void void setname setname (String (String name){ name){ this.name this.name = = name; name; String String getname getname ((){){ return return name name ;; 20/59

21 Class Diagram to Code class class Student Student { { private private String String name name ; ; void void setname setname (String (String name){ name){ if if (name (name == == null) null) { { throw throw new new IllegalArgumentException("Student.name IllegalArgumentException("Student.name must must not not be be null!"); null!"); this.name this.name = = name; name; /59

22 class class Student Student {{ private private University University university; university; void void setuniversity setuniversity (University (University university) university) {{ this.university this.university = = university; university; University University getuniversity() getuniversity() {{ return return university; university; /59

23 import import java.util.hashset; java.util.hashset; class class Course Course { { private private HashSet<Student> HashSet<Student> students students = = new new HashSet<Student>( HashSet<Student>( ); ); void void addstudent addstudent (Student (Student student){ student){ students.add students.add (student) (student) ; ; void void removestudent removestudent (Student (Student student) student) { { students.remove students.remove (student) (student) ; ; HashSet<Student> HashSet<Student> getstudents getstudents ( ( ){ ){ return return students; students; 23/59

24 UML to Code: Directed Association import java.util.hashset; class Course { private HashSet<Student> students = new HashSet<Student>( ); void addstudent (Student student){ students.add (student) ; void removestudent (Student student) { students.remove (student) ; HashSet<Student> getstudents ( ){ return students; 24/59 Although the accessor methods aim for protecting the container object from arbitrary outside modications, this goal isn't reached. Possible callers can still do the following: mycourse.getstudents().clear();

25 Courses Courses course course =....; ; course.getstudents course.getstudents (().clear ).clear( () ); ; course.getstudents course.getstudents (().add ).add(new EvilStudent EvilStudent (() )); ; // // now now all all student student references references are are gone gone // // possible possible parameter parameter check check of of addstudent addstudent (()) is is skipped! skipped! 25/59

26 import import java.util.collections; java.util.collections; import import java.util.hashset; java.util.hashset; import import java.util.set; java.util.set; class class Course{ Course{ private private Set<Student> Set<Student> students students = = new new HashSet<Student> HashSet<Student> ( ( ); ); boolean boolean addstudent addstudent (Student (Student student){ student){ return return students.add students.add (student); (student); boolean boolean removestudent removestudent (Student (Student student){ student){ return return students.remove students.remove (student) (student) ; ; Set<Student> Set<Student> getstudents getstudents ( ( ){ ){ // don't expose the concrete container class // don't expose the concrete container class return return Collections.unmodifiableSet Collections.unmodifiableSet (students) (students) ; ; int int sizeofstudents sizeofstudents ( ( ){ ){ return return students.size students.size ( ( ); ); 26/59

27 UML to Code: Bidirectional Associations Because both these references belong to the same association, we have to ensure that they're pointing to the opposite object (integrity). It would be an inconsistent implementation state, when a course refers lecture hall, but this lecture hall instance refers a completely different course instance! Let's add some code that manages the references to match. 27/59

28 class class LectureHall LectureHall { { private private Course Course course; course; void void setcourse setcourse (Course (Course course){ course){ if if (this.course (this.course!=!= course course ){ ){ Course Course oldvalue oldvalue = = this.course; this.course; this.course this.course = = course; course; if if (oldvalue (oldvalue!=!= null) null) { { oldvalue.setlecturehall(null); oldvalue.setlecturehall(null); if if (course (course!=!= null) null) { { course.setlecturehall(this); course.setlecturehall(this); /59

29 Same for the Course class class class Course Course { { private private LectureHall LectureHall lecturehall; lecturehall; void void setlecturehall setlecturehall (LectureHall (LectureHall lecturehall){ lecturehall){ if if (this.lecturehall (this.lecturehall!=!= lecturehall lecturehall ){ ){ LectureHall LectureHall oldvalue oldvalue = = this.lecturehall; this.lecturehall; this.lecturehall this.lecturehall = = lecturehall; lecturehall; if if (oldvalue (oldvalue!=!= null) null) { { oldvalue.setcourse(null); oldvalue.setcourse(null); if if (lecturehall (lecturehall!=!= null) null) { { lecturehall.setcourse(this); lecturehall.setcourse(this); /59

30 Methods and Initialization UML describes the static class structure Also class attributes and encapsulation Moving towards capturing behavior we introduce methods to initialize the dynamic objects structure from classes Starting from the static main method and continuing in the class constructors We again use the Storyboard as a base 30/59

31 Example A good start could be: class University { University ( ) { // more code or method calls goes here static void main ( String [ ] args ) { University uni = new University() ; // init rooms/lectures Uni.loadStudents(); // init students... 31/59

32 Example 32/59

33 Methods and Initialization Very straightforward Basically it is just a recreation of the structure shown on the object diagrams 33/59

34 Algorithm Design The most challenging task How application should solve the problem? Deriving general rules how things work Example: Newton derived the physical laws of gravitation from recognizing an apple falling from a tree Algorithm Design is not a modeling task 34/59

35 Algorithm Design However, the Storyboard can help you out: Get a common algorithm skeleton: developer needs to follow the behavior captured in the Storyboard starting from the initialization and divide each step to the sequence of simple subtasks simulating the computer's view Important to keep an eye on the initialized and reachable objects Use that skeleton to derive general rules: whether this operation (set of operations) works only for the given situation or whether it is a general operation that works in many/all situations

36 Example 1.The student Karli wants to achieve a degree at the Study- Right University. For a degree we need at the moment 214 credit points and Karli starts with 0 credit points and 214 motivation points. Karli is outside of the university and now enters the university into the math class. 2. Karli attends the math lecture and automatically earns 17 credit points for it and loses at the same time 17 motivation points. Karli has now 17 credit points and 197 motivation points. 3. Karli attends the modeling lecture and receives 29 credit points and loses 29 motivation points. Karli has now studied math and modeling and therefor has now 46 credit points and 168 motivation points /59

37 Example 1.Enter the university (get to the first room, initialization) 2.Execute room activity 3.Choose the next room 4.Enter the room 5.Execute room activity 6... Main logic here 37/59

38 Amending Storyboard Let storyboard be a center of the modeling process Add comments to the scenario steps to highlight general behavior Add comments to point to the specific cases Add comments to clarify behavior with the customer 38/59

39 Story-Driven Modeling Method Overview Customer Interaction Scenarios Object Diagrams Customer Interaction Storyboards UML Class Diagram Classes Attributes Initialization Methods Algorithm Design * C O D E * C O D E * C O D E * C O D E *

40 Interaction with Customer and Tests Interaction with customer is continuous and aimed to concretize the application behavior Continuous improvement of the Storyboard Storyboards can very easily be adapted to tests Story-Driven Modeling is very close to the Test-Driven Modeling *

41 GUI Design with SDM

42 Example Application Imagine a party/social where participants would like to split the bill very exactly. this behavior is strangely referred to as going dutch in English Imagine that only several people have time to go and really buy something. Usually this ends up with one person who takes on the task of creating a register of all stuff brought, how much people spent on it, and computing and redistributing the money to even it out. Therefore, we will call our application the Group register. 42/59

43 Wireframes or Mockups 43/59

44 Wireframes or Mockups Often created manually on paper For customer it is difficult to differentiate GUI elements of editor from the designed application Often GUI is refined together with customer who is often missing design app. skills Designers vs Developers Usability vs code complexity 44/59

45 1. Karli, Bobby, and Olga agree to have a pot luck barbeque, but want to share the cost evenly. On the day of the barbeque, Karli brings his notebook running the Group Register application. He assumes that Bobby and Olga will bring enough for them all, so he does not bring any food items. After starting the application it shows the initial screen of the application with no entries. This step mentions that we have an application with an initial screen

46 2. Karli adds himself, Bobby, and Olga to the list of participants This step mentions a list of participants. Therefore we need a list showing the names of the participants. But how we will actually get the participants into the list? 46/59

47 A B C

48 a) Just editing the table *This requires complex handling of a single dummy line in the end of the table and might pose some difficulties in programming b) Having some fields and an add button underneath to enter one person at a time c) An add button on top which creates an empty line, which is editable * Combined idea from a) and b) but still needs more programming than b) Lets say that customer agreed decision b) 48/59

49 3. Bobby shows up and brings some beer for 12 EUR. Karli enters that Bobby brought beer for 12 EUR into the system. Olga brings bread for 4.50 EUR and salad for 3.00 EUR. Karli enters the items for Bobby and Karli to the system. From this step, we can derive that we need something to store bought items, the person who bought it, and the price of each. This also suggests to use some kind of table with the columns person name, item description, and price. Also here, we could discuss different options to fill in the values like in the last step, but also here we will settle on the option of adding some entry fields and an add button. This could be done in a different window, but we will put it in the same to make all information visible at all 49/59

50 50/59

51 4. The food items sum up to EUR. Therefore, the share of each participants equals to 6.50 EUR. As Karli has not spent any money for food items, he has to pay the full share of 6.50 EUR. As Bobby has already spent 12 EUR, he has to receive back 5.50 EUR. Olga has spent 7.50, so she has to receive 1 EUR back. So far we have not taken into account that we want to also see the amounts of the balance each participant has to pay to the register. We could now either add a button to compute the balance and show a different window with the results or we could also show the balance all the time in the participant's list. Let us assume that our potential customer prefers the version seeing the balance all the time. We therefore add a column Amounts.

52 52/59

53 Refining the Storyboard Further playing with these wireframes might lead to some further requirements and ideas Will it be possible to remove items from the list? How exactly? Will it be possible to edit the names of the participants? Client might discover that he needs to be able to adjust the price of the food items /59

54 Choosing the Right Container Class java.util.set java.util.hashset java.util.treeset 54/59

55 Choosing the Right Container Class java.util.set java.util.hashset java.util.treeset java.util.list java.util.arraylist java.util.linkedlist java.util.vector 55/59

56 Choosing the Right Container Class java.util.set java.util.hashset java.util.treeset java.util.list java.util.arraylist java.util.linkedlist java.util.vector java.util.map 56/59

57 Course Project Develop a desktop multiplayer version of the game Backgammon using Story-Driven Modelling method You can see an example implementation Wikipedia has a compact description Taken from: 57/59

58 Project Documentation The project report you will have to hand in has to consist of: A guide through your project (and repository) Code + compiled executable Your project plan (scheduler, requirements, aims..) Project log (progress) Class Diagram (+explanations of your decisions) Storyboard (as detailed as reasonable) Also simulate customer discussion, try to find/think out 3-5 additional features 58/59

59 Project Presentation The deadline for the assignment is (23:59) Submit as zip file on the website Course project presentations (10-15 min) on 16.10,17.10,18.10 (lab sessions) Talk about solved/not solved problems How you organized the work Some notes about the SDM method Application demo 59/59

System Modelling. Lecture

System Modelling. Lecture System Modelling Lecture 25.10.2011 Lecture Objectives GUI design with Story-Driven Modelling Class Diagram to Code (revistited) Automatic Code Generation Intro to project Mancala game: 35pts Wireframes