CmpE 202 – Software Systems Engineering
Team Project #2 Specifications
Due Date:
Tuesday April 25, 2006 – Section 1
Friday, April 28, 2006 – Section 5
The requirements analysis and design specifications part of the projects will be specified using
the Unified Modeling Language (UML) on Rational Rose or any other suitable modeling tool,
such as Visio or Together. UML is a standard for creating visual abstractions for software
systems. Software developers can choose from (9) Nine different modeling techniques to
describe their system in the most appropriate manner. We will use just five of these (use cases,
CRC cards, class diagram, sequence diagrams, and activity Diagrams).
Rose is a CASE tool developed by IBM that provides computational support for creating UML
diagrams.
Part 1: Traditional Model
1. Use Cases. Use the following template to document at least 3-4 of your use cases.
1. Use Case Id.
2. Use Case Title
3. Actors & Corresponding Roles
4. Classes
5. Corresponding Attributes
6. Corresponding Interfaces
7. Use Case Description
8. Alternatives
2. Document all the CRC cards for all the (classes) classes in your team project (CRC stands
for Class Responsibility and Collaborations)
Class Name (Role)
Collaborations
Responsibility
Clients (Role)
Servers
3. Class diagram (Traditional Model). Create a Class diagram of your team problem
based on the Traditional Model – Describe your traditional model. Class descriptions
should include all attributes and methods for the class. All class relationships
(associations, aggregations, dependencies, and specializations) should be included in
1
the class diagram. Association’s classes, interface classes, constraints, interfaces,
tagged values and/or stereotypes, and notes must be included in the class diagram. A
full description of this class diagram should be included with the final submission.
Part 2: Stability Models
4. Fill 3-4 use case templates with software stability in mind. Use the following template to
document your use cases.
1. Use Case Id.
2. Use Case Title
3. Actors & Corresponding Roles
4. Classes
5. Corresponding Attributes
6. Corresponding Interfaces
7. Class Classification: EBTs, BOs, IOs
8. Use Case Description
9. Alternatives
5. Create or/and update all the CRC cards for all the (EBTs, BOs, Roles) in your stability
model of your team project (CRC stands for Class Responsibility and Collaborations). A
full description of the CRC cards should be included with the final submission.
Class Name (Role)
Collaborations
Responsibility
Clients (Role)
Servers
6. Class diagram (Stability Model). Create a new Class diagram of your team problem
based on the EBTs, BOs, and IOs – Describe your stability model. Class descriptions
should include all attributes and methods for the class. All class relationships
(associations, aggregations, dependencies, and specializations) should be included in
the class diagram. association classes, interface classes, constraints, interfaces, tagged
values and/or stereotypes, and notes must be included in the class diagram. A full
description of this class diagram should be included with the final submission.
7. Sequence Diagrams. Create sequence diagrams for the use cases in (4) with stability
in mind. Sequence diagrams will be used to "realize" Use Cases. All Use cases
should be described through sequence diagrams. The sequence diagrams can describe
the same Use Cases that a flow of events was created for in the Use Case portion of
the assignment. A full description of each of the sequence diagrams should be
included with the final submission.
2
8. Activity Diagram. Activity diagram is similar to procedural flow charts except that
all activities are uniquely associated with objects. Activity diagrams support the
description of parallel activities. Activity diagrams: (a) Describes how activities are
coordinated; (b) Is particularly useful when you know that an operation has to achieve
a number of different things, and you want to model what the essential dependencies
between them are, before you decide in what order to do them; (c) Records the
dependencies between activities, such as which things can happen in parallel and
what must be finished before something else can start; and (4) Represents the
workflow of the process. Activities, transitions, decision diamond, constraints,
synchronization and splitting bars, boundaries, and start & stop markers must be
included in the class diagram. A full description of the activity diagrams should be
included with the final submission.
9. OO Heuristics: Explain the value of OO design heuristics in performing this team
project with examples. Please feel free to come up with your own heuristics.
10. Prepare a rewrite of your problem statement.
----------------------------------------------------------------------------------------------------- The final product of this project is a report with the following outline.
Remember this report should be written with stability in mind:
Title:
Authors Names
Short Abstract
Introduction
Traditional Model: (1, 2, and 3)
Use Cases using the attached template
CRC Cards
Class Diagram – Traditional (with descriptions)
Stability Model: (4, 5, 6, 7, 8)
Use Cases using the attached template
CRC Cards
Class Diagram – Stability (with descriptions)
Compare & evaluate traditional and stability diagrams
Sequence Diagrams (with descriptions)
Activity Diagrams (with descriptions)
Your OO Design Heuristics (9)
Lesson Learned (Optional)
Conclusions
References
Appendix A: Rewrite of the Team Project Requirements
------------------------------------------------------------------------------------------------------
3
Project:
As stated on the syllabus, this project is worth 30% of the total grade. The project breakdown will
be as follows (the % of Grade is the overall course grade):
Item
% of Grade
Specification Models (Diagrams)
18%
Final Report
7%
In addition to:
Item
% of Grade
Requirements Document “Complete Team Problem Statement” – Check the
team project problem statement)
2.5%
Team Presentation
2.5%
Grading Criteria for the final submission (the final report without the team problem
statement and the team presentation)
Item
% of Grade
Illustrations and diagrams
30%
Completeness and accuracy
30%
The writing quality, readability, and organization
20%
Creativity, innovation, patterns and/or theme focus
20%
1. Illustrations and diagrams: This refers to any illustrated models, such as all diagrams,
that provide clear and accurate models, such as object models, behavior models, etc.
Make sure all models and their requirements are illustrated.
2. Completeness and accuracy: This refers to how completely the group has described the
user context, different abstractions, and different models. Make sure all models and their
requirements are complete and accurate.
3. The writing quality, readability, and organization: This refers to the quality of the
report and how readable is it. It should be easy to understand. This also refers to how
well-organized and readable the document is. If the document is written poorly, it will be
downgraded.
4. Creativity, innovation, patterns and/or theme focus: Creativity and innovation will be
rewarded. Try to come up with some good ideas that fit the innovative. This also refers to
coming up with and documenting analysis and design patterns in your model and/or how
will the select theme(s) are illustrated and elaborated in the entire document.
4