Methodology

Unified Modeling Language

                              The unified modeling language (UML) is a general-purpose visual modeling language that is used to Specify, visualize, constuct and document the artifacts of a software system.It captures decisions and understanding about the systems that must be constructed .It is used to understand, design, browse, cofigure, maintain and control information about such systems.it is intended to use with all development methods, life cycle stages,application domains and media. The madeling language is intended to unify past experience about modeling  techniques and to incorporate current software best practices into a standard approach.UML     inludes semantic concepts,notationand guidelines. It has static ,dynamic,environmental and organisational parts . It is intended to  be supported by interactive visual modeling tools that have code genetrators and report writers. the UML specification does not define a standard process but is intended to be useful with an iterative development process. It is initended to support most existing object oriented development processes.                 

                          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:

1. Event: Important activities of the college such as functions, examinations, visit by some professor, visit of AICTE team can be categorized as an event.
2. Event category: Events can be put into various categories such as Functions, Disciplinary meetings, Semester, etc.
3. Maintain event details: Description of the detailed process to be carried out while entering details about an event.
4. 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.
5. Probable date of event: The "From date" and "To date" in which the past event is expected to have occurred.
6. Retrieve event details: Description of the sequence of events to be carried out when one wants to retrieve details of a past event.
7. 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.

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

NIST ||  NISTinfo || Terms of Use || Site Map || Contact Us
Copyright © NTCS, Berhampur,2002