Project Deliverables
CEN 6017 - 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/2012 Start of class
(present on 1/25)


Two Key Components
1. Revisiting Analysis Model



Use Case Specifications – Revisited
Interaction Diagrams – Revisited
2. User Interface
General Details on Deliverable 6




Don’t forget peer reviews. 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.
Peer reviews are due on the date of this deliverable.
I will be accessing your deliverable via RTC. More later. We are
updating licenses now.
Deliverable is to include:
 Executive Summary,
 Statement of Work, (who is tasked with what)
 Revisited Analysis Model – ‘final form’




Use Case Specs
Interaction Diagrams
Traceability statement (more later) via Traceability Matrices
User Interface Prototype (details ahead)
1. Details on Revisiting Analysis Model (1 of 2)



Ensure:
Use Case specifications are to have hyperlinks to the Domain Model or to the definitions
sections in your Glossary (domain model preferred). 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 some 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.
2. User Interface (1 of 2)

I should be able to access (run through the templates) the UI within your deliverable
submitted to me and ‘execute it’ successfully. (you will demo to the class)



You must demo the ability to navigate from screen to screen to pursue some scenario from
a use case. (I will select a scenario from your use case specs.)
A client 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 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
due: Wed, February 15, 2012




Deliverable 7 will require significant team work.
Management Component: Your package to me (please
provide a hard copy) should start off with an Executive Summary
and a Statement of Work. The Exec Summary is an overview of
the contents of the deliverable. Likely a few paragraphs will
suffice. The Statement of Work (SOW) should contain the
distribution of work and the estimated time in hours that each of
you spent on your tasking. The SOW may take a page of text to
properly capture. (Do not forget to deliver your Peer Evaluations
on the due date via email to me). Your designs will be presented.
Artifacts Component: The revisited User Interface hard copy
should be included in your deliverable. The layered architectural
design model described in the slides ahead should capture your
software architecture. This is the bulk of the deliverable.
Implementation: will follow in subsequent deliverables
Deliverable #7 – Layered Architecture


Caveat: If possible, we will include the aforementioned
work items in Team Concert.
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)
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 SmartDraw or other
graphical rendering. Supplement this layered model
separately as needed in Word.
Deliverable #7 – Layered Architecture




Please note that your architectural modeling
(layers and their components, etc.) should be
captured as your Logical View - Design Model,
<Layer-Name> Layer.
The <Layer-Name> 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:
Architectural Layers – the basic idea
Presentation Layer
Subsystem name
Subsystem name
Subsystem name
Package name
Subsystem name
…However many
Application Layer
Subsystem name
… However many
Middleware Layer
Subsystem name
Subsystem name
… additional layers as you decide.
Name each of your layers (probably four…), subsubsystems, packages,
classes, etc. etc.
Package name
…
However many
Components and Their Interfaces
You need to communicate the interface of each component by taking each component (subsystem) and
showing its responsibilities showing the interface. (Note the stereotype below)
You will need to show the arguments (as much as possible) that are part of the interface signature.
Please note that a package has no specific interface and thus the classes in a package needs to
explicitly show its public interface.
Maintain Database
(name interface)
<<interface>>
Addrec(xxxx, xx) bool
UpdateRec(xx, xx) int
DeleteREc(xxxxxx)
etc……
Design Elements in Each Component
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…
Maintain Database Subsystem
(name interface)
<<interface>>
…
Addrec(xxxx, xx) bool
UpdateRec(xx, xx) int
DeleteREc(xxxxxx)
etc……
1..2
Add properties, methods,
and anything else that
will assist in realizing
the interface.
*
…
…
XXXX Package
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.