1 CSE 460 Spring 2020 CSE 460 Software Analysis and Design (Spring 2020) Software Analysis and Design Project Assigned Date: April 06, 2020 Due Date: April 27, 2020 REVISION HISTORY Version Release Date Major Changes 1.0 4/06/2020 (Initial release) 1.1 4/08/2020 Clarified project requirements (design pattern and input/output), added required interfaces and an Astah file. 2.0 4/10/2020 Changed I/O requirements. Added support for JUnit testing. Additional information regarding submission will be made available by 4/13. Please ask early about any questions or concerns about this document and project itself – it not only helps you but all your fellow classmates! Description of a Supply-Demand Software System Supply-Demand software systems are important for producers to announce their products that can be purchased by retailers. Food companies manufacture products that are distributed via retailers to people. For example, Dole and General Mills companies produce food types including fruit, vegetables, and flour. Retailers such as Safeway and Target purchase food products. Supply-Demand software systems can be used by retailers and producers. Producers can publish their goods and retailers can subscribe to goods. Notifications of available products are relayed to retailers. Retailers can subscribe to product categories to receive notification events when any producers have published the availability of their products. Retailers can stop receiving notification events by unsubscribing to the said product types. Scope Design and implement a supply-demand software system. This system should support three types of events: “publish”, “subscribe”, or “unsubscribe”. Each subscribe event includes a retailer and the product category in which a subscriber is interested in. Similarly, unsubscribe event includes a retailer and a product category. Publish events include the producer names, brand names, and the category of product they are making available. When a producer publishes a product of certain type (note: the terms product type and product category are being used interchangeably here), all retailers that are currently subscribed to that type will receive a notification for that product. In this project this notification would be one or more lines of output (additional information on producing output can be found in Coding and Testing section). In addition, the name of producers, retailers, and product categories are not known prior to the execution and may differ from one execution to another. 2 CSE 460 Spring 2020 The subscribe, unsubscribe, and publish events are to be processed in a given sequential order. A retailer will not receive notifications for a given type of product unless they subscribe to it. Once a retailer unsubscribes from a category it will no longer receive any notifications for it, unless the retailer re- subscribes to the same category. Multiple subscribers to a product type are notified according to the order of subscriptions; this is required to have a fixed order of output events. Analysis and Design The design for the system must follow the publisher-subscriber design pattern. This pattern has a broker to manage the operations of the publishers and subscribers while ensuring they do not have any direct relationship to one another (i.e., all publishers and all subscribers are independent of each other). Every publisher is independent of all other publishers just as every subscriber is independent of all other subscribers. This means that both the structure of your system and the behavior of the components of your system match the publisher-subscriber design pattern. You need to develop specifications according to UML using the Astah tool prior to implementing them. You should include an appropriate number of class, use-case, and sequence diagrams and at least one state machine diagram. The producers should implement the provided interface, IPublisher, shown in Figure 1. Similarly, the retailers should implement ISubscriber, as in Figure 2. You may implement additional methods, but they will not be used in the testing process. Figure 1: Partial class diagram for the publisher in the Publish-Subscribe design pattern Figure 2: Partial class diagram for the subscriber in the Publish-Subscribe design pattern 3 CSE 460 Spring 2020 Coding and Testing You must use forward engineering to export your UML design specification to Java code. Then, you must complete the partially generated Java code by adding your own code to the stubs generated by Astah. Do not delete or change any of the Java code produced by Astah. If you need to change any line of code from Astah has generated, such as for a return statement, leave a commented out copy of the original line in the program. To facilitate testing and eliminate potential I/O issues, your program must implement the provided class, SupplyDemand, shown below. Figure 3: Provided SupplyDemand class skeleton Details for this class can be found in the provided Astah file. The following is a general testing procedure using this class for running a set of test scenarios. 1. A SupplyDemand object is instantiated. 2. The processInput() operation can be called sequentially multiple times, each time with a single input (see below). The three publish, subscribe, and unsubscribe inputs can be interleaved. All inputs are for the Supply-Demand software system. Note that not every processInput() operation may necessarily result in a notification sent to one or more subscribers. 3. The getAggregatedOutput() operation returns a list. This output list can have zero or more entries depending on the specific processInput() operations included test scenarios. This operation also acts as input for testing the Supply-Demand software system. The output lines in the returned value of this input must be sequentially ordered according to the order of the processInput() operations (see included test scenario). Do not add trailing newline characters (\n) to the output. 4. The result from the previous step will be compared against a reference answer. 5. Finally the reset() operation will be called to clean up all information in the system. After resetting, the system starts anew. The program should NOT carry over information from previous rounds to the next one. 6. Repeat from step 2. Each round of execution corresponds to one test case. The for input and output formats for the Supply-Demand software systems: Input: [command], • publish, [producer], [product category], [brand name] • subscribe, [retailer], [product category] • unsubscribe, [retailer], [product category] Output: [retailer] notified of [brand name] brand [product category] from [producer] Below is a possible scenario using this system: 4 CSE 460 Spring 2020 Retailer: Walmart; Product category: tomato sauce; Producer: General Mills; Brand name: Del Monte Sample input processInput(“subscribe, Walmart, tomato sauce”); processInput(“publish, General Mills, tomato sauce, Del Monte”); getAggregatedOutput(); Sample output (a String list with one entry) Walmart notified of Del Monte brand tomato sauce from General Mills Table 1: Sample input and output Retailer/producer names and product categories may contain any character except comma and leading/trailing spaces. It is your responsibility to handle the upper-case/lower-case names (i.e., treating them to be the same, such as “Tomato Sauce” and “tomato sauce”). You do not have to preserve the letter casing in your output. However, the characters should exactly match our output (no extra space, lines, or additional characters) as all programs will be tested automatically. Additional sample test cases are provided. PublicTestCases.java contains some test cases as well as a complete JUnit test setup similar to the one used in automated tests. To run it, you need to place the file in Tests folder under SupplyDemand and set up JUnit 4.12. These sample test cases, in addition to others,
will be used in the grading of the program. Your program should not produce any output other than notifications sent to retailers. Therefore, please do not include a welcome message or a menu in your output. Additionally, the program should NOT produce any error messages during the entire execution. For example, when an illegal command is entered or a retailer trying to unsubscribe from a category they are not subscribed to. Your program should not crash throughout the execution. Important! All classes must be in a package named SupplyDemand (i.e., all *.java files are in folder SupplyDemand). Figure 3 shows a possible directory structure (including the JUnit test) under this requirement. Note that this is for illustration only and does NOT imply you have to have this number of classes or that you must have a Utils sub-package. Failure to comply with this requirement will result in failure of compilation in the automated grading system. Figure 4: A possible directory structure under the guideline above. 5 CSE 460 Spring 2020 Some notes regarding the testing environment: • J2SE must be used — J2EE is not allowed. • Source code can be implemented only using the Java programming language. • We will execute your source code using JDK 11. No compiled code or third-party APIs are allowed. • Make sure your code compiles and matches the given interfaces. Rubric Parts Points Uses publisher-subscriber model 20 Use case diagrams 5 Class diagrams 15 Sequence diagrams 10 State machine diagrams 10 Design quality 5 Forward engineering (partial code is generated automatically) 15 Produces correct outputs 20 Code documentation and quality 5 Project Report: this is for the full project report which contains the class, sequence, and state machine specifications with their descriptions, a readme file, and any other supporting materials. A single PDF or Microsoft Word file must be used. A template for this document is posted. 5 Total 110 Note: 10 out of 110 points is bonus. Important note: be sure to check the Canvas Discussions for updates, questions, answers, and hints. You are responsible for knowing any posted requirements or guidelines. If you are not certain about some aspect of this programming assignment, it is very important to ask early, not a few days before the project due date.
