CSE522-Assignmentd 5: Part 1 and 2 Solved

Part 1: Use-Case and Activity Diagrams using StarUML                   
 

You are to develop an ‘external view’ of an Online Forum application described briefly below. 


The Online Forum caters to three main categories of Users – Students, TAs, and Professor[1]– each with different privileges.  TAs and the Professor are collectively referred to as Staff.   The Online Forum supports three types of Posts:  a Q&A Post, a Poll Post, and a Resource Post.  Staff may make all three types of Posts, but Students may only make a Q&A Post and a Poll Post.   As the focus of this assignment is on the external view of the application, the internal details of these posts are not relevant in this assignment. 
 

All Users must login to use the Online Forum; they may logout at any time but must login back again in order to take any actions.  Initially, the Professor logs in and creates the class which includes enrolling the TAs and Students.  Only after the class is created may Students and TAs log i and activate their accounts – activation to be done only once, at the start of the semester. 
 

During the course of the semester, Students, TAs, and the Professor all operate concurrently relative to one another in taking their actions on the Online Forum.  However, each User operates sequentially in taking their individual actions.  Each User may make any number of Posts (of the permitted types) and in any order.   As noted above, a user may logout at any time, but must login back again before any further other action can be taken. 

 

Finally, the Online Forum maintains statistics on the usage of the online forum, such as average response time for queries, numbers of posts made by users, etc.   All activity in the Online Forum ends at the end of the semester. 

 

 

(a)  What to Represent in the Use-Case Diagram.   

 

(i)       The Users to be represented are: Student, TA, Professor, Staff, User, and OnlineForum.   

 

(ii)     The Actions to be represented are:  Login, Logout, Activate, Post, Q&A Post, Poll Post, Resource Post, Create Class, Enroll Students, Enroll Staff, and Maintain Statistics.  

 

(iii)   ‘Generalization’ arrows are to be used to depict relevant relations between different types of Users.  Similarly forActions.   Draw these arrows pointing upwards or slanted upwards. 

 

(iv)   ‘Directed Association’ arrows are to be used in relating Users with their Actions.  Draw these arrows pointing sideways or slanted upwards/downwards 

 

(v)     ‘<<includes>>’ arrows are to be used in relating Actions where appropriate. 
 

(b)  What to Represent in the Activity Diagram.   

 

(i)       Introduce three swim lanes, for Student, TA, and Professor respectively.    Within each swim lane, define the control flow for the permitted actions for that type of user.  

 

(ii)     The Actions to be represented are:  Login, Logout, Activate, Q&A Post, Poll Post, Resource 

Post, Create Class.  

 

(iii)   Introduce one initial node and one final node for the entire diagram. 


(iv)   Use Fork/Join nodes (in Professor) to initiate/terminate concurrent operation of all users.  Termination takes place at the end of the semester.   Note that each user takes their individual actions in a sequential manner. 

 

(v)     Use Decision and Merge nodes to construct an iterative flow of control within the Student, TA, and Professor swim lanes.   To the extent possible, use vertical and horizontal arrows in depicting flow of control.  Slanted arrows are permissible – StarUML also allows an arrow to have more than one segment (bend).   


(vi)   Show ‘end of semester’ as a constraint on the outgoing edge of appropriate decision nodes. 
 

Finally: 
 

Save your model as a file OnlineForum.mdj.  The suffix mdj is automatically added by StarUML. 

 
[1] Assume there is only one Professor for the course, although online forums such as Piazza allow more than one Professor.

Part 2:  Communicating State Charts 

 

Download and unzip A5_Part2.zip.  It has four files:  Circular_Buffer.mdj,

Circular_Buffer.java, Circular_Buffer.txt, and MessagePassing.jar.

 

File Circular_Buffer.mdj contains a StarUML State Chart (reproduced above) giving the outline of the controller for a circular buffer.  This buffer is accessed by two concurrent processes, Producer and Consumer, who communicate with the buffer controller using two channels, put and get.  The producer repeatedly does a put! and the consumer similarly does a get?, and the buffer controller performs the respective complementary operations.   

 

File Circular_Buffer.java contains the outline of a Java implementation of the above state chart using the Message Passing Library discussed in Lecture 15 – examples were posted in Sample Programs →  MessagePassingExamples.zip.   The file gives the main program (class Driver), the classes Producer and Consumer, and also the outline of class Circular_Buffer.

 

Class Circular_Buffer uses an integer array, data, of size n in order to hold its data.  It has a field count that gives, at any given time, the number of values that can be taken out of the buffer.  It also has two indices p and g to point, respectively, to the places in the array where the next value is to be put by the producer and taken out by the consumer.  These indices are incremented (modulo n) as put/get operations take place.   The actual insertion and retrieval of values are performed by two methods put() and get() respectively.

 

What you should do: 

 

1.      Complete the state chart Circular_Buffer.mdj  by providing suitable labels on the four transitions shown.   Each label is of the form event [ guard ] / action –   Lecture 26 includes a demo on how to construct StarUML State Charts.   These labels should collectively express the synchronization policy of the buffer controller, namely, that:  

 

(i) when the buffer is empty (count == 0) only a put operation is permitted; (ii) when the buffer is full (count == n) only a get operation is permitted; (iii) otherwise, both put and get are permitted - the selection is non-deterministic.

 

 

In specifying the transition labels in StarUML:

 

(i)                  each event is a channel send/receive, and is specified as a Trigger Event;  

(ii)                each guard is a boolean expression and specified in the Properties section; and  

(iii)              each action is a call on one of the methods put() or  get(), and specified as an Effect Behavior → OpaqueBehavior.   

 

2.      Complete the run() method in class Circular_Buffer providing an implementation of the above synchronization policy.   As the state chart specifies that the buffer controller operates in a repetitive cycle, the top level of the run() method should be a while(true) {…} loop.   

 

In Eclipse, right-click on the project, then select Build Path → Configure Build Path → Add External JAR → browse and select MessagePassing.jar. 

 

Run the completed program under JIVE after adding Scheduler.* to Debug Configurations → JIVE → Exclusion Filter.  Check that the Console output shows the strings Put 1, …, Put 50 as well as Get 1, …, Get 50.   The ‘Put’ and ‘Get’ strings will not be in strict alternation, but their respective values should be in ascending order – this property is to be checked as specified below.

 

Save the Execution Trace in a file, Circular_Buffer.csv, and load it into the Property Checker:

 

-  Add Driver.op and Driver.val to the Key Attributes.   

-  Enter Driver.op = op, Driver.val=val in the Abbreviations textbox.    

-  Choose Method Granularity – this is important.

-  Copy the contents of the file Circular_Buffer.txt into the Properties textbox. - Press Validate and check that all properties are satisfied; otherwise, the program has   an error which needs to be corrected.