辅导Software Engineering 程序、讲解c、辅导C++程序
- 首页 >> C/C++编程SIT321 Software Engineering Methods
Purposes:
- To use Object-Oriented techniques to do the system analysis and design;
- To know how to develop various models when analyzing and designing a system.
Preamble:
This is an educational exercise, not a money making venture. We expect you to workthrough
the Object-Oriented methodology with care. You can start with a piece of the system and apply
the method to it. If you get stuck or just need to talk please contact your tutor or coordinator.
We suggest that you focus on the underlying object model before considering the interfaces.
This assignment is based on Assignment 1, especially the SRS document, and is a base of
the last assignment.
~~~~~~~~~~~~~~~~~~~~~ ♦ ~~~~~~~~~~~~~~~~~~~~~
Statement of Work:
In this assignment, you are required to do and submit the following work:
1. Static Model (class/object model) development for the system
2. Dynamic Model (behavioural model) development for the system
3. Class/object design
4. Data dictionary
5. Personal planning and summary
The requirements of each work above, as well as hints and the related information, are
detailed below.
Static Model Development:
The static model describes the classes/objects and their relationships in a system. The
purpose of the static model is to capture the structure of the system being modeled.
In the analysis phase, the static model is to capture relationships among classes/objects of a
system, and ensures that the model supports specifications in the Software Requirements
Specification (SRS) document.
Page 2 of 4
In the design phase, the static model may be modified to include parts/functions of the system
that are not explicitly indicated in the specification. You may also modify the previous model to
get a simpler or more general model which still meets the specifications.
You are expected to develop the static model through the following steps:
- identify use cases of the system from the OCD and SRS documents
- for each use case, prepare scenarios that describe typical interaction sequences
- identify classes/objects from scenarios
- identify associations between classes
- identify attributes of classes and associations
- (organize and simplify classes using inheritance)
- verify that access paths exist for likely queries
- (iterate and refine the model)
- (group classes into modules)
Note: A step within a pair of parentheses is optional.
Dynamic Model Development:
The dynamic model (sequence or collaboration diagrams) captures interaction sequences of
objects in a software system when the system receives operation requests from a user or
external entities. That is, it captures events, such as “Mouse button press”. In this model,
events are recognized as messages the system objects receive from the environment or other
objects, and interaction sequences among objects are described graphically showing how
events are dealt with by the system. The objects involved in the dynamic model come from
those classes in the system static model. We prefer using sequence diagrams to cater for
messages that are sent by one object to another.
You are expected to develop the dynamic model through the following steps:
- identify use cases of the system from the OCD and SRS documents
- for each use case, prepare scenarios that describe typical interaction sequences
- identify events (messages) between objects
- prepare an event trace (message sequence chart, such as a sequence diagram ) for
each scenario
- partition the chart into classes represented by the vertical bars. Identify any
preconditions (assumptions) and postconditions (guarantees) implied by the chart.
- (build state diagrams for objects if necessary)
- match events between objects to verify the consistency between the dynamic and
static models
Note: You are expected to use sequence diagrams to develop the dynamic model.
Class/object Design:
The steps are
Page 3 of 4
- Modify classes in the static model by adding attributes and operations/methods that
implement object interactions in the dynamic model.
- Verify the consistency among the class design, the static model and the dynamic
model
Data Dictionary:
The data dictionary gives definitions of data items used in the static model. The data items
include class names, class attributes and other related concepts you want to record for future
reference. You should write the data dictionary when you develop the static model.
Personal Planning and Summary:
Each group member is required to submit
- a plan and schedule of your own work;
- a diary,
- an estimate of your time (= effort);
- the actual time you spent on your work; and
- a summary – a paragraph or two identifying your experience with, and thoughts
and reactions to this assignment.
This provides you with an opportunity to assess and reflect on your own work. It also provides
us with a means of measuring what happens in the assignment and improving it in the future.
To know how your work will be assessed, please read “Assignment 2 Assessment
Guide” carefully.
~~~~~~~~~~~~~~~~~~~~~ ♦ ~~~~~~~~~~~~~~~~~~~~~
Submissions:
You or your group is required to submit the following documents for assessment:
- one document that contains the required static models, dynamic models, the
class/object design, and the data dictionary;
- each group member’s personal planning and summary.
For the group work, the Group Leader is responsible for submitting the assignment.
Suggestions:
1. Please use Unified Modelling Language (UML) notations for your analysis and
design.
2. Sort out the basic structure of the system.
3. Each group member is to select a part of the system to analyze and design. These
parts need to communicate with each other. For students working individually,
select a portion of your system to start the analysis and design.
Page 4 of 4
4. Define interfaces between parts. Again, focus on functions and routines provided
by a class to other classes, and pre-conditions and post-conditions to be satisfied.
Please note interfaces here do not mean user interfaces only, they also include the
communication between interior parts of the system.
5. Each group member is to develop his/her own piece of the system.
6. Integrate the analysis and design of sub-systems.
Resources:
- The basic OO design method is described in the textbook "Practical Object- Oriented
Design with UML" (M. Priestley, McGraw-Hill, 1st edition 2000 or 2nd edition, 2003).
- Example System Design (available in this assignment folder on CloudDeakin).
- Pressman’s textbook, chapters 8 and 9 (7th or 6th edition) or chapters 12 - 13 (8th
edition).
Miscellanea:
- For group work, by default it is assumed that each member made 100% contribution to the
assignment, unless the Group Leader indicated a different percentage of contribution in written
form and therefore the assignment mark for the member is calculated based on that
percentage.
- Your attention is drawn to the Plagiarism Statement (available on CloudDeakin). Although
all students or groups are doing assignments on the same project, different groups will be
doing the project differently. Anyone using cut-and-paste or copying other people’s work will
be easily detected, and the outcome is a disciplinary committee hearing.
- There are no word limitations on documents due to the nature of this assignment. But
unnecessary content should not be included. All content should be well organized and
documents should be well structured with proper fonts and sizes.
- The assignment must be submitted before or on the due date. Late submission will be subject
to a mark penalty or not be assessed (for more details, please read the Unit Guide on
CloudDeakin). Read submission instructions on CloudDeakin if you don’t know how to submit
your assignment.
- If you wish to apply for an extension, the application should be submitted to your coordinator
before the due date. Documentary evidence of the disadvantage causing this request, and an
ongoing assignment representing the work you have completed are expected to be submitted.
A judgement will be made by the coordinator as to whether an extension shall be granted.