Project Deliverables CIS 4328 – Senior Project 2 And CEN Engineering of Software 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.

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

General Details on Deliverable 6 (1 of 2) Don’t forget hard copies of peer reviews to be brought to class. This is important. If you cannot be present on the date of the deliverable, give your review (in a sealed envelope) to a team member or physically drop it off in my office prior to class date/time. Remember: hardcopy – no on this one. 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.

General Details on Deliverable 6 (2 of 2) 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 a files called TeamNumFile, Executive Summary, Statement of Work, Traceability Document, SQA Report, a folder containing Individual Schedules. Traceability Matrices are to be appended, prepended, or included in the Traceability Document. The Artifacts Folder is to contain the User Interface Prototype (details ahead) Organization. Organizing the deliverable (not the contents of each document) is the responsibility of the SQA role. The SQA’s grade will be slightly adjusted from the team grade relative to the organization of this deliverable. Content. The team leader’s grade will be slightly adjusted from the team grade relative to the content of this deliverable.

1. Details on Revisiting Analysis Model (1 of 2) 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 and will not support an effective design; 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.

1. Details on Revisiting Analysis Model (2 of 2) Interaction Diagrams – Sequence. Ensure these are correct. Additional example(s) may be found on my web page. (I have eliminated ambiguous examples and have inserted better examples) 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.

2. User Interface – Expanded and Revisited I should be able to access (run through the templates) the 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. This design should contain much more implied functionality than in Deliverable 3.

2. User Interface – (2 of 2) 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 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.

Deliverable #7 – Layered Architecture due: Monday, February 11, 2008 Layers: You are to design a layered architectural prototype to accommodate your application requirements. Each of 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. (See samples on my web page) 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. (This discussion is included in the SQA Report document, please)

Deliverable #7 – Layered Architecture Subsystems / Packages. For each subsystem, your accompanying narrative must provide a single sentence citing the purpose of the subsystem (that is, how it ‘coheres’). You must also 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 must be supplied at this time (cohesion). This means that classes, for example, constituting a subsystem or package, must have their properties named (no data typing info is needed) and methods (responsibilities) cited (parameters not required, but may be helpful); similarly, returned ‘types’ may be cited, but not required. These UML models must be realized in Rose. Supplement this layered model separately as needed in a Word document(s) as previously described.

Deliverable #7 – Layered Architecture Your architectural modeling (layers and their components, etc.) is to be captured in Rose: Logical View, Design Model, Layer components. The Layer has subfolders for packages, subsystems, etc., which you will like (I hope). Approximately your deliverable should appear as:

… … … Presentation Layer Application Layer Business Domain 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 – Basic Rendering … additional layers as you decide, such as a Tech Services Layer or other Support Layer.

You must communicate the interface of each component by taking each component (subsystem) and showing its responsibilities (the interface class). (Note the stereotype below) You will need to show the arguments that are part of the signature in each element of the interface. Please note that a package has no specific interface and thus the classes in a package need to explicitly include its public interface. (name interface) > Maintain Database Addrec(xxxx, xx) bool UpdateRec(xx, xx) int DeleteREc(xxxxxx) etc…… Components and Their Interfaces Need to see the signatures (hence component responsibilities to client components). Note the ‘realization’ arrow. This means that the contents of the subsystem ‘realizes’ the interface. You may include subsystem (or package) components if you wish; but these are not required at this time.

You may combine this drawing with the previous drawing; otherwise, make this separate. For each component, you must also – as much as possible - include the classes and their properties/methods needed to ‘realize’ the interface. Recognize signatures in the subsystem interface must be accommodated by the classes or other components (along with other dependencies ‘they’ might have) in the subsystem. There will likely be additional methods within each class that are not part of the signature of the subsystem, but are needed within the subsystem itself to realize a specific signature of the subsystem interface. Also include dependencies objects will experience with realizing the interface…(hence the need of good class diagrams). (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) The interface is realized by the components along with dependencies ‘they’ might have to realize one or more signatures in the subsystem interface. XXXX Package