Project Deliverables - PowerPoint PPT Presentation

Loading...

PPT – Project Deliverables PowerPoint presentation | free to download - id: 27d92-ZTRjN



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Project Deliverables

Description:

When logging onto Rose, be sure to select RUP icon from the initial window. ... Use Rose (Use Case View) for your models. ... text for examples and use Rose. ... – PowerPoint PPT presentation

Number of Views:150
Avg rating:3.0/5.0
Slides: 52
Provided by: bob4
Learn more at: http://www.unf.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Project Deliverables


1
Project Deliverables
  • Version 5 04/12/2005
  • Note This document contains the deliverables
    from the first semester.
  • Do review these, as there are changes and some
    reorganization

2
Overview of Guidance
  • I shall try to upgrade / refine guidance for each
    deliverable as we progress.
  • Please view this file often as it will change.
  • Suggestions for clarity and/or consistency are
    always welcome.

3
Format of Deliverables
  • All Deliverables will be via CD.
  • Outside Surface of CD is to clearly indicate
    your course number and the team number, as
    CEN 6017 - Team 2 or CIS 4328 Team5.
    Also include the project title.
  • Inside Each deliverable will be in a separate
    folder on the same CD, so when I access the CD,
    all I should see are individual folders with
    labels such as Deliverable n, as in Deliverable
    4.

4
Contents of Folder
  • Folder is to contain four Word files plus a
    Folder.
  • Team Num file, with file name as follows (for
    example) Team3.TeamNumFile.Deliverable2.Date.
    09.27.04
  • In this file, you are to simply (may be a single
    Word file)
  • List the names of the team members
  • Indicate who is team leader with phone number.
  • List individual email accounts.
  • Iteration Plan with file name
    Team3.IterationPlan.Deliverable2.Date.09.27.04
  • ? Include for second semester deliverables only.
  • Note that the Iteration Plan will change for each
    deliverable, that is, it will be refined and
    extended. The current iteration and a skeletal
    version of the next iteration constitute the
    extensions. Each successive deliverable will
    contain a revised Iteration Plan.
  • First semester courses Executive Summary will
    suffice.

5
Continued
  • Executive Summary (in Word) with file name
    Team3.ExecutiveSummary.Deliverable2.Date.09.27.04
  • Single page document Summarizes the contents of
    this folder.
  • What activities were undertaken
  • What artifacts were changed and rationale
  • Note revising artifacts is the norm in an
    iterative approach to software development.
  • What new artifacts were produced
  • ? Must include signatures of EACH team member
    that he/she has reviewed and has bought off on
    the contents of this deliverable.
  • Vision Document (in Word)
  • Artifacts - a Folder
  • Goal Contains sub folders and single files as
    appropriate.
  • Example You should have a subfolder entitled
    Rose Models and perhaps another subfolder
    entitled Requisite Pro (Grad Students)
  • E.g. Should have a folder for Rose Models
    Folder for Use Cases Folder entitled Management
    Documents, which should contain simple Word files
    for, say, Risks List, Business Rules, etc You
    have some flexibility here. Clear organization
    is a must.
  • New artifacts or revisited artifacts from
    previous deliverables, - specific components of
    the deliverable should be found here, and a
    number of these should be in their own subfolder,
    such as the user interface prototype, Use Case
    diagrams, use case narratives, analysis model,
    sequence diagrams. We will discuss in class.

6
Guidance on the Rose Browser
  • Use Case Diagrams in Use Case Folder within Use
    Case Model in Rose
  • Each Use Case is to be a separate subfolder in
    the Use Case folder within Use Case Model (see
    the Rose Browser).
  • But Use Case Narratives are in Requisite Pro for
    Grad Students.
  • Actors in folder within Use Case Model in Rose

7
Grammar and Wording
  • Under NO circumstances will poor grammar or
    ill-conceived sentences be considered acceptable
    work.
  • EACH portion of EACH deliverable should be
    reviewed and signed off by EACH team member.
    (See Executive Summary)
  • Poor adherence to this standard will impact
    EACH team member. So, check out your text BEFORE
    you submit it to me.
  • This is a TEAM responsibility!!
  • On the provided templates, there is room for
    signoff by the team / team members. Use this for
    verification
  • This is also required via the Executive Summary
    document.

8
Second Semester StudentsGo to Slide 29
  • You may skip over the five deliverables of the
    first semester. But there are changes within
    them that would make them better.
  • There needs to be a deliverable between
    deliverables 3 and 4 where the Façade-level use
    case is expanded to include the basic course of
    events (but not all alternatives and exceptions)
    and possibly the activity diagrams or at least
    identification (not expansion) of alternative /
    exceptional threads.
  • This will be added next iteration of this course

9
Deliverable 1 The Business CaseDue Wednesday
10/4
  • Purpose
  • To understand the structure and dynamics of the
    organization within which the application will
    operate
  • To ensure customers, end-users, and developers
    understand the organization
  • To derive requirements on systems to support the
    organization
  • To support these, a number of models and
    documents are needed.
  • Deliverable Artifacts
  • Business use case model
  • Use Cases and Actors - Modeled
  • Business object model
  • Use Cases realized with actors and entities
    for the modeling
  • Use Cases realized with actors for the Use
    Case Descriptions.
  • Additional Artifacts
  • Business Vision document - text
  • Business Glossary - text
  • Business Rules text
  • Business Risk List - text
  • Domain Model - model in Rational Rose (in next
    deliverable)

10
Guidance on Deliverable 1The Vision Document
  • Use the templates provided. (You may use
    Requisite Pro if desired. Take the Requisite Pro
    Quick Tour)
  • This is an essential document and should provide
    a list of features that the application to be
    developed should possess.
  • These features are not behavioral (like the Use
    Cases). These are text descriptions. Example of
    features
  • ClassicsCD.com Web Shop Secure payment
    method. Easy browsing for available
    titles. Ability to check the status of an
    order. Customer shall receive e-mail
    notification. The catalog shall be highly
    scaleable to include many titles and effective
    searching through those titles. Customer shall
    be able to customize the Web site. Customer
    shall be able to register as a user for future
    purchases without needing to re-enter
    personal information.

11
Guidance on Deliverable 1The Business Case
  • Use the appropriate forms available at
  • RUP document templates are located at the site
    http//jdbv.sourceforge.net/RUP.html. 
  • The link for the Business Rules template is
    incorrect (points to the Business Modeling
    Guidelines template), so there is another link to
    point to the Business Rules format.
  • There are also two former student examples on my
    web page to guide you. (Note I am not
    disclosing their grades, or how I graded them.)
    These are merely samples of what they submitted.

12
Guidance on Deliverable 1The Business Case
  • When logging onto Rose, be sure to select RUP
    icon from the initial window.
  • Be also certain to notice the tool mentors when
    you select a folder in the Rose Browser, a
    description often appears with invaluable
    information.
  • ? The Business Use Case Model should be found in
    the Use Case View
  • This is a single model of the key business
    processes of the organization.
  • ? Business Object Model in the Logical View.
  • All business object models and the business use
    case model are to be in a SINGLE copy of Rose.
  • (See examples on my web page.)
  • Put your Business Object Models within the
    Business Object Model folder within Logical View
    in Rose see examples on web page.
  • Business object models are realizations of each
    of the business use cases and contain business
    actors. (All domain-oriented)

13
Deliverable 2 Domain Modeland Statement of Work
Due October 13th
  • Develop the Domain Model
  • Iterate previous deliverable artifacts
  • This means address EACH component and
    fix/repair/enhance/improve, etc. and certify.
  • Dont make the same mistakes twice.
  • Add a Statement of Work (SOW), that is, what is
    your team plan who does what, what is your
    plan, etc. (See textbook)

14
Guidance on Deliverable 2 - Domain Model
  • In addition to standard items, this deliverable
    requires a complete Domain Model. The Domain
    Model is essential to understanding the
    environment within which the application to be
    developed will function. Include also a
    Statement of Work.
  • Turn in CD that contains all models and has
    links to text descriptions.
  • Purpose
  • Construct Domain Model (precursor activity to Use
    Case development)
  • Is an essential activity to facilitate good use
    case development that contains glossary items and
    objects from the problem space (domain).
  • Deliverable Artifacts for Deliverable 2
  • Domain Model taking into consideration
    additional attributes, multiplicities,
    associations, etc. The Domain Model should be
    captured as a separate folder under the Logical
    View in your Rose Browser.
  • Statement of Work - a Word Document. See
    textbook and/or templates for format
  • Other artifacts from Deliverable 1 to be
    revisited.
  • (Exec Summary will cite what changes you have
    done to each artifact)
  • Business use case model
  • Use Cases and Actors - Modeled
  • Business object model
  • Business Vision document - text
  • Business Glossary - text
  • Business Rules - text

15
Guidance on Deliverable 2 Domain Model
  • Be certain to see example link on my web page and
    study carefully the slides in the appropriate two
    lectures.
  • Be certain to fully consider my grading notes to
    you for Deliverable 1 prior to submission of
    Deliverable 2.
  • For first deliverable or two, the Iteration Plan
    may be more descriptive that is, may contain
    textual descriptions. For subsequent iterations,
    plan will be more cryptic, perhaps bulleted,
    perhaps tabular.
  • Not much verbiage. Activities undertaken,
    schedule, developers, results

16
Deliverable 3 - Use Case - Façade Iteration plus
Initial User Interface Prototype due
Monday 10/25
  • Executive Summary (overviews new artifacts and
    ALL changes/revisions to existing artifacts, such
    as the revised Iteration Plan, etc. as required.
  • Specific Work
  • Revisit the Business Case (Deliverables 1 and 2)
    including artifacts listed below and update them.
    (Risks Lists Business Rules Domain Model
    Statement of Work, etc.)
  • Include an index (numbered) for Use Cases that
    follow. (discussed in class and via slides)
  • Use Case Index is to contain a number, Use Case
    name, short description, and other high level
    items you consider important. Construct this in
    tabular form using a table in Word. See power
    point slides for detailed attributes needed

17
Guidance on Façade Iteration
  • Develop an overall Use Case Model (all
    application Use Cases and Actors). Similar to
    Business Use Case Model.
  • Develop Façade Use Case Descriptions and
    associated Use Case Diagrams for each Use Case.
  • Use Rose (Use Case View) for your models. Link
    the Use Case Description text and ensure these
    descriptions are on the CD you turn in for
    grading.
  • CEN 6016 students must use Requisite Pro
  • Model your Façade Use Cases using the Kulak and
    Guiney book. Again, see power point lectures for
    required attributes.
  • Additional information Visual Modeling book and
    Rose Basics (see power point lecture slides for
    examples on including your Use Cases in your Rose
    Model in the Use Case View.)

18
Guidance on Facade Iteration
  • Remember that the Façade iteration names the use
    case, identifies actors, provides a short
    description, frequently includes pre- and post
    conditions, triggers, etc. But it does NOT
    include the detailed actor-system interactions.
  • See lecture notes for required attributes.
  • Must include all Use Cases.
  • Include your single Use Case Model in the Use
    Case View (in Rose) in the folder provided by
    Rose. Note this is NOT the Business Use Case
    Model, which has been completed more, the icons
    are different for the actors and use cases. Be
    sure to note the differences.

19
Guidance on User Interface Prototype
  • Develop User Interface Prototypeneeded for
    requirements capture!!! Iterate this a as
    needed. (Should be done in conjunction with the
    Façade Use Case and will (together with Domain
    Model) greatly assist you for Deliverable 4,
    your full-blown Use Case Descriptions with
    alternate and exception paths.
  • You may use any prototyping tool you wish VB,
    Java, etc. Your prototype should include
    storyboarding.
  • Most teams use static html some use Front Page
    some contain Javascript, etc.
  • Recommend testing your interface with someone
    from a different group. If you link up with me,
    I will be glad to assist.
  • To accompany the Façade Use Cases, user interface
    prototype needs to be total complete. While we
    are not including actor application
    interchanges, these are essential for the next
    deliverable.
  • See examples of initial user interface prototypes
    on my web page.
  • See also (ahead) lecture slides on User Interface
    Design

20
Deliverable 4Full Use Cases Model Activity
Diagramsdue 11/8
  • Executive Summary
  • Develop Focused and Filled Use Case Descriptions
    and associated Use Case Diagrams for each Use
    Case.
  • Use Rose (Use Case View) and Requisite Pro
  • Kulak and Guiney book (Use Cases) Visual
    Modeling book and Rose Basics (see power point
    lecture slides for examples.)
  • Each Use Case is to be accompanied by an Activity
    Diagram that should indicate flow for all paths
    in the Use Case
  • CEN 6016 Students only
  • (Recognize that Use Cases are really never
    finished.)
  • Your Use Case Diagrams will likely be
    supplemented with Included or Extended Use Cases,
    as appropriate. Redo your Use Case Model for the
    Application.

21
Guidance on Deliverable 4 Complete Use Case
Model
  • Executive Summary as usual All on CD.
  • Complete Use Case Model and Use Case Diagrams for
    each Use Case This is a major assignment.
    Consider alternative, exception flows, and
    sub-flows, using extension points as
    appropriate.
  • Reflect any use cases you feel are included or
    extending.
  • Activity Diagrams one per Use Case (should
    include all alternate paths) (Include as package
    in Rose Model)
  • Put Use Cases into groups packages that seem
    to go together functionally, like the GUI or
    those that address business activities.
  • (These will help in our architecture as these
    will become likely subsystems).
  • ? Iterate on the Use Case Model and/or your User
    Interface Prototype (and any other documents)
    from Deliverable 3 as appropriate

22
Guidance on Deliverable 4 Complete Use Case
Model
  • Allocate functional requirements to use cases via
    the stories of interchange. (and domain objects)
    This is a painstaking and long task! It will
    underpin your entire design. Spend time here!!!!
    Recognize that Use Cases are NOT functional
    requirements rather, they are stories of
    actor-application interactions which contain the
    required functionality.
  • Requirements with extension points to address
    alternate and exception flows. see class
    notes.
  • All customer functionality should be accounted
    for here. Be certain to use your Domain Model
    and italicize or bold all references to entities
    in the domain model.
  • Ensure everything the customer desires is
    accounted for!

23
  • Keep the alternatives /exceptions WITH the use
    case. They should be included with the use case
    and not made separate. See examples on web page.
  • Use the User-Interface to ensure all
    functionality is captured.
  • Develop Activity Diagrams one per Use Case
    that captures all paths (scenarios) in a Use
    Case. See Visual Modeling text for examples and
    use Rose.
  • Activity Diagrams should be placed in the Use
    Case View under Use Case Models in a Folder
    entitled Activity Diagrams

24
Deliverable 5 - Developing the Analysis Model
and Non-Functional Requirements - due 12/01
  • Analysis Model (Preliminary Design)
  • Contains communicating boundary, control, entity
    objects with relationships, etc.
  • ? Will flow from your use case narratives and
    prototype
  • Supports Interaction Modeling and much more
  • Designed to lead ultimately to the class model
    (static)
  • Sources Use your prototype (boundary) again,
    domain model (entities), and use case
    descriptions (control) in earnest. They are not
    enough, but will help. See also your Vision
    Document.
  • See Visual Modeling Book RUP Logical View on
    Rose

25
Guidance on Deliverable 5 Analysis Model
  • Include boundary classes together, control
    classes together, and entity classes together all
    without associations to other classes. (a
    one-page drawing) This should partition all the
    classes by type. Include all attributes /
    methods with each class, but not connectivity.
  • Follow this with a fully connected model for
    each use case. Use those analysis classes
    appropriate to the use case and associate the
    classes.
  • Be sure to study textbook and lectures on
    boundary, control, and entity models
  • Class structure may be realized with the standard
    stereotyped classes or the RUP icons

26
Guidance on Deliverable 5 Analysis Model
  • Remember, the validity of the model is simply can
    I look at any path through a use case and see
    where/which objects will accommodate all the
    functionality captured in a scenario? Can it be
    traced (with your finger...) through the objects
    as you read through the path description?
  • This is the check to make! Verify Traceability!!!
  • Try to cite as many attributes and methods
    (responsibilities) as possible in the respective
    class-names boundary, control, and entity.
  • Yes, I am after associations, dependencies, etc.
    among the classes as much as practical.

27
Guidance on Deliverable 5 Analysis Model
  • For boundary to control classes, the association
    line is sufficient, because it cannot be
    determined what method in control class will be
    invoked from the boundary class unless we
    consider a specific scenario. Better, though, is
    a series of boundary classes constituting the
    interface. See lecture slides for example.
  • Associations among entity classes should have the
    multiplicities, aggregations, dependencies, etc.
    cited, as usual. They are appropriate here and
    may come from your domain model, which will VERY
    likely need upgrading after/during your exercise.
  • BE CERTAIN to look at the slides on my web site
    which supplement your readings! There are many
    examples of the format you will need for the
    classes.

28
For next time
  • This Analysis Model assignment should include a
    sequence diagram using the analysis classes for
    each use case.
  • Did not require this in the past should have.
  • Note 2/9/05

29
Guidance Deliverable 5 Non-Functional
Requirements
  • See Use Case Textbook for tables
  • Small systems
  • functionality performance
  • Large systems
  • Portability Maintainability Scalability
    Reliability Security
  • How about
  • Persistence?
  • Will discuss more in class Remember the
    Supplementary Specifications for Non-Functional
    Requirements.
  • Thus the Supplementary Specifications Document
    should be a Word document containing the
    non-functional tables.

30
Second Semester Deliverables(anticipated)
  • Deliverable 6 User Interface Design
  • 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.

31
Deliverable 6 - User Interface Designdue
Wednesday, 26 January 2005
  • Purpose To design a user interface that
    reflects application functionality.
  • This should be a refinement of your initial user
    interface prototype based on your further
    learning about your application.
  • This user interface should demonstrate all
    required functionality as found in the use cases.
  • In your presentation, you are to demonstrate how
    your UI satisfies all Usability Principles as
    cited in the lecture slides and your text.
  • Verify your UI by running it against your use
    cases to ensure all functionality is captured.

32
Deliverable 6 - User Interface Design
  • I should be able to access the Deliverable 6
    folder on your CD and bring up the UI and execute
    it successfully.
  • Recognize that some of the windows / displays
    will be / may be hard coded and that demonstrated
    functionality may not be backed up with
    implemented code or efficient algorithms. But
    the implied functionality must be evident.
  • Text caveats in the UI are appropriate.

33
Deliverable 7 Layered Architecture due Wed,
February 9, 2005
  • 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)

34
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.
  • Deliverable 7 should have the Rose model in a
    folder with your other Rose models. Of course,
    this is merely a significant extension of what
    you already have. So, there should be a Rose
    folder.
  • Also, all supporting new documents for
    Deliverable 7 that are associated with this
    deliverable need to be in a folder entitled
    Architectural Support Documents, and reside in
    the Deliverable 7 parent folder.
  • Other documents, such as an executive summary,
    etc. should be separate as usual.

35
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 Id like your deliverable to
    look like

36
Architectural Layers the basic idea
Presentation Layer

Subsystem name
Package Name
Subsystem name
However many
Application Layer

Package name
However many
Package name
Subsystem name
Middleware Layer

However many
Subsystem name
Package name
Subsystem name
additional layers as you decide.
Name each of your layers (probably four),
subsubsystems, packages, classes, etc. etc.
See next page.
37
Components and Their Interfaces
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.
Maintain Database
(name interface)
Addrec(xxxx, xx) bool UpdateRec(xx, xx)
int DeleteREc(xxxxxx) etc
38
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
Add properties, methods, and anything else that
will assist in realizing the interface.
(name interface)

1..2
Addrec(xxxx, xx) bool UpdateRec(xx, xx)
int DeleteREc(xxxxxx) etc



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
39
Deliverable 8 Detailed Design - Overview due
Wednesday, 2 March 2005
  • 0. Folder with Deliverable 8 on CD. Executive
    Summary, as usual.
  • 1. A carefully constructed Iteration Plan. This
    now becomes an essential part of your
    deliverable, as we are about to go into the
    Construction phase.
  • 2. A sequence diagram and a communications
    diagrams for the basic course of events for each
    of your use cases.
  • The sequence diagram is to be fully annotated, as
    shown in lecture slides.
  • This is a design-level sequence diagram, so it
    should include subsystems via their interfaces
    also the persistency mechanism.

40
Deliverable 8 Detail Design Iteration Plan
  • Iteration Plan
  • You should 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 out into 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). Use
    Word or Excel. 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
    anything not quite right, finalize it before
    you start this one and map out a pretty good
    idea for the third iteration. Iterate.

41
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
    teams familiarities with these technologies.
  • Tell me who knows what and the extent of that
    knowledge.
  • See examples on my web page .

42
Deliverable 8 Detail Design Use Case
Realizations
  • Interaction Diagrams.
  • For each Use Case, you are to develop a Sequence
    Diagram 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.
  • Be certain to look at past examples of sequence
    diagrams in the lecture slides.
  • Use the toggle (F5) to generate the
    Communications Diagram.

43
Deliverable 8 Detail Design Use Case
Realizations
  • Class Diagram
  • For each sequence diagram, you are to produce in
    Rose the VOPC (View of Participating Classes) for
    that sequence diagram.
  • Be certain to include all the associations,
    multiplicities, etc. in this class diagram.
  • Some of the details of Deliverable 7 that might
    not have gotten finalized (the attributes and
    operations of some of the classes) will need to
    be finalized at this time.

44
Deliverable 9 Detail DesignSubsystem Design
and Realization due 16 March 2005
  • For each subsystem, you are to provide an
    interaction diagram of at least one
    responsibility accommodated by the subsystem from
    its interface. (lecture 32)
  • No more than one interaction diagram should
    address accommodating persistency. You should,
    however, include one that does this.
  • You should also present the corresponding
    communications (collaboration) diagram. Note the
    differences.
  • You are also to provide the internal structure of
    your subsystems, like slides 4 and 6 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 in this rendering. (see lectures on
    class design and persistency)

45
Deliverable 9 Detail DesignSubsystem 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.
    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.

46
Deliverable 9 - Questions
  • 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 kind of situation is 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.

47
Deliverable 10Class Design and Implementation
1 due 30 March
  • 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. Dont wimp
    out on this!
  • ? Ensure all methods in your Use Case
    Realizations have full signatures in their
    calling sequences.
  • ? 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.

48
Deliverable 10Class Design and Implementation
1 due 30 March
  • Document how your Use Cases drove your iteration
    plan and development.
  • Document how your architecture assisted (was
    central) in your development.
  • Demonstrate and Discuss your (first and) second
    Iteration in class (possibly)
  • (not formal 15 minutes per team)

49
Deliverable 10Class Design and Implementation
1 due 30 March
  • You are to include your source-level components.
    These need to be 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.

50
Deliverable 11 FinalTesting and 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.
  • There will NOT be a separate test plan document
    required, as originally planned.

51
Deliverable 11 FinalTesting and Demonstration
  • On the day you are demonstrating your projects,
    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.
  • 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!
About PowerShow.com