CmpE 297A – Advanced Object-Oriented Analysis & Design
Team Project #1 Specifications
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 Nine different modeling techniques to describe
their system in the most appropriate manner. We will use just six or seven of these (use case
diagrams and use cases, CRC cards, class diagram, two behavior models).
Use your team problem statement for assignments to answer the following questions:
1. Use Abbott’s Approach to identify classes, and their attributes, operations, and
relationships (associations, aggregations, inheritance).
2. Select the right classes, attributes, and relationships by showing how to use the
elimination heuristics
3. Test all your classes by using uniformity test, more than a name test, or test, and
more than list test.
4. Document all your classes in CRC cards. You must show the responsibility and
collaborations (client and server sides) of each class.
5. Rewrite your problem statement.
6. Explain the value of OO design heuristics in performing this assignment with
examples.
The previous questions are designed to get you up to speed and to put you on the right
thinking process. It also helps you to prepare a better write up of your problem
statement.
Rose is a CASE tool developed by Rational Inc. that provides computational support for creating
UML diagrams. In each of the diagrams, the following is required:
1. (Point 1) Use Case Diagrams and Use Cases. Use one or more diagrams to describe all the
actors in your system and how they will interact with the Use Cases of your system. Provide
Flow of Events for all of your Use Cases. Use associations, aggregations, and generalization
in the use case diagram(s) and don’t forget to use multiplicities. Use case diagram(s) textual
description is a must. Use the following template to document your use cases.
1.
2.
3.
4.
5.
6.
7.
8.
Use Case Id.
Use Case Title
Actors & Corresponding Roles
Classes
Corresponding Attributes
Corresponding Interfaces
Use Case Description
Alternatives
1
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. (Point 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 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.
4. (Point 4) Use Case Diagrams and Use Cases. Update #1. A full description of each of the
use case diagrams should be included with the final submission. Use the following
template to document your use cases.
1.
2.
3.
4.
5.
6.
7.
8.
9.
Use Case Id.
Use Case Title
Actors & Corresponding Roles
Classes
Corresponding Attributes
Corresponding Interfaces
Class Classification: EBTs, BOs, IOs
Use Case Description
Alternatives
5. (Point 5) Create or/and update all the CRC cards for all the (classes) classes in 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)
2
Servers
6. (Point 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. (Point 7) Behavior Models. Create two or more of the following behavior models
with stability in mind:

Sequence diagrams. 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.

State Transition diagrams (STD). STD shows a sequence of state an object can assume
during its lifetime, together with the stimuli that cause changes of states. STD will be
used to generate the behavior of classes. The entire application and two or more classes
should be described through an STDs. A full description of each of the STDs should be
included with the final submission.

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.

Object-Interaction Diagram (OIDs) or Collaboration Diagram. OIDs or
Collaboration diagrams show a set of interactions between selected objects in a specific,
limited situation or context, focusing on the relations between the objects and their
topography. A full description of each of the OIDs or collaboration diagram should be
included with the final submission.
8. (Point 8) 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.
3
9. (Point 9) Prepare a rewrite of your problem statement.
Final Submission: A final report must be submitted.

The final report must be written with a theme or two in mind. A theme or two must be
selected per team. Contact me to select your themes. The following are a list of themes:
1. Complexity vs. Simplicity
2. Map the software stability concepts into the entire lifecycle
3. Use software stability concepts as a way to activate/ deactivate capabilities
4. Use software stability concepts as a way to add/ delete/ modify capabilities
5. Use software stability concepts as meta-language to describe and/or develop system
software and other software domain
6. Use the stability model (SM) as an accessibility model using roles
7. Definitions (Simplification): EBTs, Bos, Ios
8. Design/ analysis/ process patterns vs SM
9. Aspects vs SM
10. KRs in AI vs SM
11. More Stability patterns
12. The modeling of SM with different modeling language such as UML, formal
methods, OMT, fusion, RA/SA
13. Measurement of SM within the software
14. The impact of SM on Scalability
15. The impact of SM on Layering/ categorizing
16. SM framework
17. In SM, where are the hooks and at what level should be?
18. The impact of SM on Prevention and security
19. The impact of SM on Multiple view
20. The impact of SM on the cost and expending of your system or your operation.
21. Criteria for SW stability in Analysis
22. Criteria for SW stability in Design
23. Criteria for SW stability in Coding and Debugging
24. Criteria for SW stability in Testing
25. SM and representation adequacies, such as:
Descriptive Adequacy
Descriptive adequacy refers to the ability to visualize objects in the models. Every defined
object should be browse-able, allowing the user to view the structure of an object and its state at a
particular point in time. This requires understanding and extracting meta-data about objects that
will be used to build a visual model of objects and their configurations. This visual model is
domain dependent -- that is, based on domain data and objects’ meta-data. Descriptive adequacy
requires that all of the knowledge representation is visual, as follows:





Visual models are structured to reflect natural structure of objects and their configurations
All the visual knowledge (data & operations) in the visual model is localized
Relationships among objects in the visual model are well-defined
Interactions among objects in the visual model are limited and concise
The visual model must transcend objects, and instead highlight crosscutting aspects.
4
Logical Adequacy
Logical adequacy refers to the representation tools that describe the framework components’
behavior, roles and responsibilities.
Synthesis Adequacy
Synthesis adequacy refers to an integrated problem resolution methodology, or built in
trouble-shooting tools. Built-in trouble-shooting tools are very important in managing complex
distributed systems, because there are typically many potential points of failure.
Analysis adequacy
Analysis adequacy refers to integrated validation and verification tools. With built in
validation and verification, the process of maintenance and regression testing can be streamlined
and the cost of validation and verification is minimized.
Blueprint Adequacy
Blueprint adequacy refers to the modeling features that provide for integrated system
specifications. Integrated system specifications are important because they facilitate the
extensibility of the system. An integrated blueprint for an enterprise framework should clearly
identify the hot-spots and frozen-spots in the framework.
Epistemological Adequacy
Epistemological adequacy refers to tools for representing objects in the real world. There are
two ways to view the world based on simplicity: (1) Perfect but simple view – the world is
represented in this view as an ideal environment and (2) As-is, but complex and detailed view –
the world is represented as an ultimate reality. There are also two ways to view an organization:
1) Flat and single view and 2) layered and multiple views. It is very obvious that most of
modeling techniques, such as unified modeling language (UML) and object-modeling technique
(OMT) model the world as an ideal environment and flat or single view of itself. Nevertheless,
successful enterprise frameworks have made great leaps in representing objects in the real world
and in providing the necessary tools to alter these objects as required by the business.
Notational Adequacy
Notational adequacy refers to the presentation constructs the impact the presentation tools
have on the operation of the system as well as the ease of modification.
Procedural Adequacy
Procedural adequacy refers to recognition, and search capabilities.
Contractual Adequacy
Contractual adequacy refers to the client tools for representing the system behavior.
Scalable Adequacy
Scalable adequacy relates to the constructs and tools supporting partitioning, composition,
security, and access control.
Administrative adequacy
Administrative adequacy refers to the tools for modeling the deployed system’s performance,
reliability and administrative characteristics and to the actual tools for administering the system.
Administrative adequacy also considers the availability of install set builders, start and stop
5
procedures or scripts, integrated database management capabilities, archiving, fail-over
mechanisms, etc.
Team Name
Analysis & Design Patterns or Selected Theme(s)
----------------------------------------------------------------------------------------------------- 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
Use Case Model:
Use Case Diagrams (with descriptions) -- (Point 4)
Use Cases using the attached template or
any other template that you select -- (Point 4)
CRC Cards (Point 5)
Class Diagram – Traditional (with descriptions) – (Point 3)
Class Diagram – Stability (with descriptions) – (Point 6)
Compare & evaluate traditional and stability diagrams (Points 3 & 6) & (Points 1 & 4)
Behavior Model-1 (with descriptions) (Point 7)
Behavior Model-2 (with descriptions) (Point 7)
OO Design Heuristics (Point 8)
Lesson Learned (Optional)
Conclusions
References
Appendix A: Rewrite of the Team Project Requirements (Point 9)
------------------------------------------------------------------------------------------------------
6
Project:
As stated on the syllabus, the project is worth 35% 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) & Final Report
20%
Theme focus in your report
5%
In addition to:
Item
% of Grade
Requirements Document “Complete Team Problem Statement” – Check the
team project problem statement)
5%
Team Presentation (Check the representation requirements and schedule)
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.
7