Methodology
Unified Modeling Language
The UML captures information aboutthe static structure and dynamic behavior of a system. A
system is modeled as a collection of discrete objects that interact to
perform work that ultimately benefits an out side user.The Static Structure defines
the kinds of objects important to a system and to its implementation, as well as the
relationshipps among the objects.The dynamic behavior defines the history of objects over
time and the communications among objects to accomplish goals. Modeling a
system from several seperate but related view points permits it to be
understood for different purposes.
The UML also contains organisational constucts for arranging models into packages
that permit software teams to partition alrge systems into workable pieces, to undersatand
and control dependencies among the packages,and to manage the versioning of model units in
a complex development environment.It contains constucts for representing implementation
decisions amd for organising run-time elements into components.
UML is not a programming language.Tools can provide code generators from UML into a
variety of programming languages,as well as construct reverse engineering models from
existing programs.The UML is not a highly formal language intended for theorem proving
.There are a number of such languages ,butthey are not easy to understand or to use for
more purposes.The UMLIs a general purpose modeling language.For specialized domains, such
as GUI layout,VLSI cicuit design, or rulebased artificial intelligence,a more specialized
tool with a special languahe might be appropriate.UML ia a discrete modeling language.It
is not intended to model continuous systems such as those found in engineering and
physics.UML is intended to be a universal general-purpose modeling language for dicrete
systems such as those made of software ,firmware ,or digital logic.
The documentation should be maintained over the design using the particular
standards , so that it will be easy to maintain the code ,to
design the code, & to implement the design of a particular projects.
This documenattion includes Requirement collection the primary step to project which
contains Client Interaction developing use cases, Client review Specifications & then
developing Technical Dictionary & any other miscellaneous requirements.
Design Documentation
1. Requirements Analysis
2. List of use cases and scenarios
3. Use case Specifications
4. Technical Dictionary
This section contains brief description of all the terms whose meaning may not be clear to
a common man but are
used in describing the use cases. The terms are numbered and sorted alphabetically for
quick reference.
For
example:
- Event: Important activities of the college such as functions,
examinations, visit by some professor, visit of AICTE team can be categorized as an event.
- Event category: Events can be put into various categories such as
Functions, Disciplinary meetings, Semester, etc.
- Maintain event details: Description of the detailed process to be
carried out while entering details about an event.
- Operator: Any user of the system who has been given access either to
enter details about a particular event or retrieve details of a past event, or both.
- Probable date of event: The "From date" and "To
date" in which the past event is expected to have occurred.
- Retrieve event details: Description of the sequence of events to be
carried out when one wants to retrieve details of a past event.
- Search criteria: Search criteria can be any event category, or any
search text, or probable date for the event, or both event category and probable date for
the event, or search text and probable date for the event.
5. Use Case Implementations
6. List of Classes
List of all Classes that are to be used in the module in the following format:
Class # [Serial Number]/[Name]
All the classes should be followed by a brief description about the purpose of the class.
For example:
Class # 1.a/clsPaymentDetails
Class # 1.b/clsPaymentDetailsSet
Class # 1.c/clsPaymentDetailsManager
7 Class
Definitions
8. List of Forms
List of all forms as discussed in the various scenarios in the following format:
[F# [Serial Number]/[Name]]
All forms should be numbered as shown above. All the forms should be followed by a brief
description about the
purpose of the form.
For example:
[F# 1/frmPaymentDetails]
This form is used to enter payment details received from a client. This will have the
details like the date of payment,
the customer number, the amount, particulars of the payment, etc.
9. List of Reports
List of all reports that are referred in the various scenarios in the following format:
[R# [Serial Number]/[Name]]
All the reports should be followed by a brief description of the purpose of the report.
For example:
[R# 1/rptPaymentDetails]
This report shows the details of a particular payment.
10. Interface Navigation Chart
This section shows the details of navigation of the
various forms and reports of the module in a diagrammatic form. This helps the designer in
representing the client’s imagination of the GUI in better form. The various
constructs to be used for the same are as follows:
For Example:
11. Persistence Design
12. Error Code Design
In this section, the anticipated errors and the
accompanying messages are listed in a tabular form.
Error # |
Error Description |
1 |
Invalid password.
Please try again. |
2 |
Maximum number of
attempts exceeded. |
3 |
User ID no found.
Please enter a valid User ID. |
13. Form Design Details
14. Report Design Details
15. Help Design Details
16. Design of Test Cases
17. Integration and Deployment Architecture
All the MTS classes are stateless classes and they will be deployed on the server side.
All the forms and reports will go into the client side. While making deployment for all
modules, one has two make two deployments. One for the server side class deployment, i.e.,
the MTS classes and one for the deployment of client side EXEs. The ODBC connection has to
be made on the server side and it has to be SQL Server mode of authentication.
18. Estimated Metrics
|
