1. Project Deliverables CIS 4328 – Senior Project 2 And CEN Engineering of Software 2

2. Second Semester Deliverables (anticipated) Deliverable #6 – User Interface Design and Revisited Analysis Modeling Deliverable #7 – Layered Architectural Design Deliverable #8 – Detailed Design - Iteration Planning and Use Case Realizations – Context Diagrams only. Deliverable #9 – Subsystem Design – Interaction Diagrams (both) and VOPC diagrams. Deliverable #10 –Class Design and Implementation #1; First Functional Demonstration Deliverable #11 – Final Deliverable: Complete Implementation Model and Demonstration including client testing.

3. Deliverable 6 due: 1/23/2008 Start of class Two Key Components 1. Revisiting Analysis Model Use Case Specifications – Revisited Interaction Diagrams – Revisited 2. User Interface – Expanded and Revisited

4. General Details on Deliverable 6 Don’t forget hard copies of peer reviews to be brought to class. This is important. When I bring up your CD, I should see one folder named Deliverable 6. As we add deliverables, the number of folders on your CD will increase and include a folder on Deliverable 7, etc. as we have done last semester. Within this Deliverable folder (and others throughout the semester) I should see a Revisit Deliverable 5 folder (or other deliverable number as appropriate), a Management Folder, and an Artifacts Folder unless advised otherwise. The Revisited Deliverable5 Folder is to contain the revisited Use-Case Specifications and the Revisited Interaction Diagrams (that is, Rose Model) The Management Folder is to contain the TeamNumFile, Executive Summary, Statement of Work, a folder containing Individual Schedules, a Traceability Document, and a SQA Report. (The Traceability Matrices should appear in a separate document called Traceability). The Artifacts Folder is to contain the User Interface Prototype (details ahead)

5. 1. Details on Revisiting Analysis Model Use case specifications are to have hyperlinks to the Domain Model or to the definitions sections in your Glossary. These links are to be relative and must be accessible on my computer. Use case specifications are to provide a meaningful level of detail to support follow on design. If these specs are too high level and vague, they are unsatisfactory; too low level, and they constrain design. All Alternatives and Exceptions are to contain hot links as appropriate, a concluding action (return to Step n or Use-case terminates here), and the complete set of behaviors. There are to be no database references in your use-case specifications unless these refer to an external system. Interaction Diagrams – Sequence. Ensure these are correct. Additional example(s) may be found on my web page. The use-case specification text should be inserted down the left margin of your sequence diagrams approximately in line with the objects that realize the behaviors to the right. This effort supports traceability. Ensure control classes are indeed control (orchestrate) and entity classes provide core responsibilities and functionality. (Previous deliverables indicated that there was a real disconnect in understanding what these analysis class behaviors should be. In many cases, entity responsibilities were allocated to control classes.) Boundary classes are not to be expanded into ‘forms’ or ‘windows’ or anything resembling implementation. Remember, these will likely not morph into design classes. These are to appear in your Rose Model as appropriate in the Logical View folder.

6. 2. User Interface – Expanded and Revisited I should be able to access the your UI within your deliverable submitted to me and execute it successfully. I should be able to navigate from screen to screen to pursue some scenario from a use case. I should NOT have to hunt and peck and wonder… Recognize that some (a few) of the windows / displays will be / may be hard coded and that demonstrated functionality may not be totally backed up with implemented code or efficient algorithms. But the implied functionality must be clear. More should be implemented than in Deliverable 3.

7. User Interface - more This should be a significant refinement of your initial user interface prototype based on your increased knowledge and understanding of the requirements. This user interface should demonstrate the vast majority of key items of functionality as found in the use cases. In your classroom and field presentation, you are to demonstrate how your UI satisfies required functionality. Utility and Usability Principles as cited in the lecture slides and your text will be emphasized in evaluation. Verify your UI by running it against your use cases to ensure all functionality is captured.

8. Deliverable #7 – Layered Architecture due: Wed, February 15, 2006 Layers: You are to design a layered architectural prototype to accommodate your application requirements. The named layers are to consist of major subsystems and packages, their contents (other subsystems, packages, etc.). All component dependencies (coupling) are to be indicated via appropriate UML connectors. The main purpose and suggested contents of each of your layers must be spelled out in a text-accompanying document. (see lecture slides for examples) Your choice (decision) of architectural pattern should be fully discussed using the eleven design principles; that is, how does your choice support the design principles enumerated upon in the lecture slides and your textbook. (Word document, please)

9. Deliverable #7 – Layered Architecture Subsystems / Packages. For each subsystem, you should provide a single sentence citing the purpose of the subsystem (that is, how it ‘coheres’). You should provide a rationale explaining exactly why specific subsystems / packages were placed in their respective layers; that is, a record of your design decisions. (Cohesion) The detailed contents of the subsystems / packages (subsystems, packages, classes and their associations / dependencies) of each design element should be supplied at this time (cohesion). This means that classes, for example, constituting a subsystem or package, must have their properties named and methods (responsibilities) cited – as much as possible. You should NOT INCLUDE the detailed description of properties (that is, float, char, integer, String, etc.) nor the number and types of parameters for the methods nor the algorithms, etc. used by the methods. Only named methods / return items. These models should be realized in Rose. Supplement this layered model separately as needed in Word.

10. Deliverable #7 – Layered Architecture Please note that your architectural modeling (layers and their components, etc.) should be captured in Rose: Logical View, Design Model, Layer. The Layer has subfolders for packages, subsystems, etc., which you will like (I hope). There are mechanisms for, say, a subsystem, to name the subsystem and site the dependencies and interfaces related to this subsystem. Approximately what I’d like your deliverable to look like:

11. … … … Presentation Layer Application Layer Middleware Layer Name each of your layers (probably four…), subsubsystems, packages, classes, etc. etc. See next page. Subsystem name Package name Subsystem name However many Architectural Layers – the basic idea … additional layers as you decide.

12. You will communicate the interface of each component by taking each component (subsystem) and showing the responsibilities of the subsystem by showing the interface class. (Note the stereotype below) You will need to show the arguments that are part of the signature. Please note that a package has no specific interface and thus the classes in a package needs to explicitly show its public interface. (name interface) > Maintain Database Addrec(xxxx, xx) bool UpdateRec(xx, xx) int DeleteREc(xxxxxx) etc…… Components and Their Interfaces

13. You may combine this drawing with the previous drawing; otherwise, make this separate. For each component, you should also – as much as possible - include the classes and their properties/methods that are needed to ‘realize’ the interface. Recognize those signatures in the interface must be accommodated by the classes or other components (along with other dependencies ‘they’ might have) in the subsystem. You may also show any dependencies these objects will experience with realizing the interface… (name interface) > Maintain Database Addrec(xxxx, xx) bool UpdateRec(xx, xx) int DeleteREc(xxxxxx) etc…… … …… Design Elements in Each Component 1..2 * Add properties, methods, and anything else that will assist in realizing the interface. Showing a dependency between this object (in sub) and an object in another design element (package, here) We are saying that the interface is realized by this combination of objects and dependencies. XXXX Package

14. Deliverable #8: Detailed Design - Overview due: Monday, 6 March 2006 0. Folder with Deliverable #8 on CD. Executive Summary, as usual. (Also, send Self and Peer Reviews) 1. Iteration Plan. Carefully constructed. This continues to be an essential part of your deliverable, because it really contains your schedule and your development ‘plan.’ Ensure you have time boxes and equally shared responsibilities for contributions. (SQA person primarily with team leader inputs and team buy-in!!) Be CERTAIN to check each other’s work. Do not just parcel tasks out and batch them up for delivery. Verify!!! 2. Sequence diagram and a communications diagram for the basic course of events and at least one alternative or exception scenario for each of your use cases is required. Do yourselves a favor. Don’t select the easiest alternative path. Also for alternative paths for CRUD considerations, these may not need full expansion. Simple notes may be sufficient. Address those issues that require a good number of object collaborations so that you are certain responsibilities will be met.

15. Deliverable #8: Detailed Design - Overview due: Monday, 6 March 2006 3. Traceability Update – Trace your design model entities to layers and subsystems / packages if possible. (accommodated by SQA guru) Because analysis entities do not necessarily morph cleanly to design components, this may be tough. But try to bridge this chasm between the analysis model and the design realization. 4. Prepare to Present – Nothing formal. Perhaps two team members should present. Date: to be decided. Should be able to cover easily within our 75 minutes. 5. Technology assessment. See slide ahead. Should be accommodated by team leader. 5. No need to interface with VIM people for this.

16. More Notes on Interaction Diagrams The sequence diagram is to be fully annotated, as shown in lecture slides. Include the communications diagram too (use the F5 toggle) Clearly use Rose. This is a design-level sequence diagram, so it should include the entire flow. Where there is a reference to a subsystem, that subsystem represented by its interface will suffice. (lectures upcoming) For packages, however, the public interfaces for each of the key classes in the package must be shown. (No implementation, but clear responsibilities via anticipated signatures is needed.) Don’t forget to include any persistency, security, etc. packages in their appropriate layers. Note that the subsystem interfaces do not require showing the ‘insides’ of the subsystem. The detailed responsibilities will be presented in Deliverable #9. But the responsibilities of the classes within packages (via their individual interfaces) must be shown.

17. Deliverable #8: Detail Design – Iteration Plan Sketch out what you feel will be the number of iterations that will be needed and the features (scenarios) that you will implement in each iteration. Remember! Jump on the scenarios / features that you feel present to your team the MOST RISK! Secondly, your most important core functionalities should be second. Map these to a number of iterations with short duration and stick to the plan. Include dates, scenarios, and responsible developers, expected outcomes, and room for your iteration assessment - shortcomings (a post mortem). Include span time dates of iteration! Your first iteration must be totally understood before you start it and you should have a ‘pretty good idea’ of the specifics of your second. As you finish the first, roll into the second one (or subsequent iteration) anything ‘not quite right.’ Finalize the next iteration (or any other one impacted by assessment of the first one) it before you continue. Iterate.

18. Deliverable #8: Detail Design – Iteration Plan Technology Assessment. Your iteration plan should include your preliminary assessment of the technologies that you plan to use, where (for what features) you plan to use them, sources of knowledge of these technologies and overall assessment of your team’s familiarities with these technologies. Tell me who knows what and the extent of that knowledge. See examples on my web page.

19. Deliverable #8: Detail Design – Use Case Realizations Static Component (Structural) Class Diagram For each sequence diagram you develop, you are to produce in Rose the VOPC (View of Participating Classes) for that sequence diagram. Be certain to include all the associations, dependencies, multiplicities, aggregations, etc. Some of the details of Deliverable #7 that might not have gotten ‘finalized’ (Try to include any clear attributes. Identification of methods that realize responsibilities will be very helpful indeed.) (No algorithms, etc.!)

20. Deliverable #8: Detail Design – Use Case Realizations Dynamic Component (Behavioral) Interaction Diagrams (Sequence and Communications). These should be captured in Rose These should be located in the Logical View, Design Package, etc. Check out Use Case Realizations. Sequence diagrams are to be fully annotated and should include subsystem interfaces, persistency references, etc. as appropriate. (See previous slides) Be certain to look at past examples of sequence diagrams in the lecture slides. Use the toggle (F5) to generate the Communications Diagram. Note: Professional Rose users almost all seem to imply that developing the communications diagram first results in a cleaner, less cluttered sequence diagram via the toggle rather than vice versa. What do you think?

21. Deliverable #9 – Detail Design, Traceability, and Iteration Plan Subsystem Design and Realization – due: 20 March 2006 For each subsystem, you are to provide an interaction diagram of at least two responsibilities accommodated by the subsystem from its interface. (lecture 32) and Deliverable #8. No more than one interaction diagram for one subsystem should address accommodating persistency. You should, however, include one that does this. This means that of all your subsystem realizations, you may only show one interaction diagram that addresses persistency. I am thus after you to show a number of realizations that your subsystems must accommodate. You should also present the corresponding communications (collaboration) diagram. Note the differences. For each subsystem, you are also to provide the internal structure of your subsystems, like appropriate slides in lecture 33. This is your VOPC. These are to be fully annotated (dependencies, communications, multiplicities, etc.) You are to annotate via stereotyping which objects are persistent in your modified VOPC as well as any other stereotyping you feel is necessary. (See lectures on class design and persistency)

22. Deliverable #9 – Detail Design Subsystem Design and Realization All messages in your sequence diagrams need to be numbered as shown in lecture 32 (numbers and their sub-parts). ALL of your design class model elements must have the package or subsystem they are associated with in with the class header as shown in lecture 33 (think: University Artifacts). Packages and Subsystems should have a stereotype indicating the layer in which they reside. Sequence Diagrams may require UML Notes to clarify interactions. Use them as necessary. Extra credit and VERY NICE Touch: Try to list the text of the Use Case Specification in the left margin (column?) of each sequence diagram.

23. Deliverable #9 - Traceability The second major part of this deliverable is to realize traceability of each function captured in Use Cases and in the Analysis Model here in the Design Model. Frankly, you are breaking new ground here. It one thing to have traceability from Use Cases to analysis classes. It is quite another thing to trace analysis class traceability into the Design Model, as realized in subsystems, packages, classes, and in layers. Please note that this is a major undertaking for this deliverable and will take time!

24. Deliverable #9 – Iteration Plan This is to be a comprehensive treatment of iterations particularly starting with the Construction Phase. This should be based on scenarios in Use Cases. It should not be supporting activities such as refining the database, developing stored procedures, etc. It is used to track the development of the application and is an essential tool used to determine if we are on schedule. You may use any reasonable format, but remember, each iteration has most of the core disciplines as activities! (requirements, analysis and design, testing, implementation, configuration, environment, program management, etc.) Again, lots of work…

25. Deliverable #9 - Questions These are questions whose answers are to accompany this deliverable. You may answer these in the Management Folder. STUDY these questions and answers. Ensure that they are complete, as you will see them again! What is a proxy class and what is its purpose? What do we mean by a dependency? What are the pros and cons of dependencies? Under what circumstances is the modeling of only a subsystem interface sufficient in a sequence diagram? In behavioral modeling, when must the interface be realized? How is it done? What kind of model(s) is/are used to capture the details of the inner workings of a subsystem? Why should dependencies on a subsystem be on the subsystem interface? Turn these in via a separate Word document.

26. Deliverable #10 Class Design and Implementation #1 due 3 April In addition to Executive Summary,  Update your Iteration Plan for remaining iterations based on your assessment of the previous iterations.  Document that assessment as part of the Iteration Plan (may use Word) This may likely be a few paragraphs. Don’t wimp out on this!  Ensure all methods in your Use Case Realizations have full signatures in their calling sequences.  Extend your Traceability to cover your current detail design  Testing: Document your test suites: catalog these via number, purpose, scope, results, and assessment of each test.  Using Rose, ensure your classes and attributes are all correct by revising your VOPCs ensuring that all connections are either associations or dependencies. This can be shown by clicking on objects across the top of sequence diagrams and filling in the window specifications.

27. Deliverable #10 Class Design and Implementation #1 Demonstrate and Discuss your (first and) second Iteration in class (possibly) Talk about the ‘good, bad, and ugly’ of your development, tests, etc. (not formal; 15 minutes per team)

28. Deliverable #10 Class Design and Implementation #1 Source Code: Your deliverable is to include your source- level components. organized ‘by design unit’ (that is, package, subsystem), ‘by component’ (within these higher level components). Read documentation section of Component View in Rose.  Please note: Your source code absolutely must be internally documented with meaningful, guiding comments. These will be reviewed very carefully!!! So, your organization should be Component View, Implementation Model, Package or Subsystem, and specific component within the owning package or subsystem.

29. Deliverable #11 Implementation #2 and Demo due 17 April This is a continuation / extension of Deliverable #10: In addition to Executive Summary and the accustomed documents,  Update your Iteration Plan for remaining iterations based on your assessment of the previous iterations.  Document your assessment as part of the Iteration Plan This may likely be a few paragraphs. Don’t wimp out on this!  Ensure all methods in your Use Case Realizations have full signatures in their calling sequences.  Extend your Traceability to cover your current detail design  Testing: Document your test suites: catalog these via number, purpose, scope, results, and assessment of each test.  Using Rose, ensure your classes and attributes are all correct by revising your VOPCs ensuring that all connections are either associations or dependencies. This can be shown by clicking on objects across the top of sequence diagrams and filling in the window specifications.

30. Deliverable #11 Implementation #2 and Demonstration Source Code: Your deliverable is to include your source-level components. organized ‘by design unit’ (that is, package, subsystem), ‘by component’ (within these higher level components). Read documentation section of Component View in Rose.  Please note: Your source code absolutely must be internally documented with meaningful, guiding comments. These will be reviewed very carefully!!! So, your organization should be Component View, Implementation Model, Package or Subsystem, and specific component within the owning package or subsystem.

31. Deliverable #11 Implementation #2; Demonstration This deliverable is a chance to finalize any shortcomings in your Iteration Plans, Rose Models, or any design models/artifacts you have undertaken. ALL code is to be fully documented and submitted in folders “by type,” that means jsp files together,.java files together, servlets, …etc.

32. Deliverable #11 Implementation #2 and and Demonstration On the day you are demonstrating your projects (April 17 th ), you are to provide to me a hardcopy of your use cases. I will arbitrarily select one or two for you to demonstrate during class. (I would like to meet with the team leader / designee, the SQA individual and, if available, one of your lead programmers in my office earlier on Monday, the 17 th, if that is feasible. Please email and we can discuss the best time for you.) You may also be asked some general questions. Your demonstration, etc. should not last beyond thirty minutes. If you need separate computer support, you should plan to go to class early to set up / connect to whatever you need. Good luck and have fun!