My Profile
Active Members
TodayLast 7 Days
more...
Awards & Gifts
Online Exams
Fresher Jobs
Our fresher job section is exclusively for fresh graduates! Find jobs for freshers in major Indian
cities including Bangalore, Chennai, Hyderabad, Pune or Kochi
Resources
Find educational articles, blogs, discussion threads and other resources.
Colleges
Find details about any college in India or search for courses.
Paid Surveys
|
rational rose
Posted Date: 19 May 2008 Resource Type: Articles/Knowledge Sharing Category: Computer & Technology
|
Posted By: sri phani kumari Member Level: Gold
Rating:  Points: 1
|
|
|
Rose Modelling Standards
Version: 0.4 Draft
Issue Date: 21/06/2000
Originator: Steve Hesketh
AMENDMENT HISTORY
Version Reason for Change Request for Change Ref.: Date of Issue
0.1 Initial draft. 10/05/00
0.2 Changes as a result of initial review. 20/05/00
0.3 Changes as a result of second review. 15/06/00
0.4 Changes resulting from issues highlighted during development of Service Coding Standards document. 21/06/00
CONTENTS
1 INTRODUCTION 0
1.1 Background 0
1.2 Purpose 0
1.3 Scope of Document. 0
1.4 References 0
2 MODEL STRUCTURE AND CONTROL 0
2.1 Master Model 0
2.2 Modelling Process 0
2.3 Model Structure 0
3 NAMING STANDARDS 0
3.1 Use Cases 0
3.2 Robustness 0
3.3 Interface Layer 0
3.4 Business Logic Layer 0
3.5 Common Object Layer 0
3.6 Data Control Layer 0
3.7 Source File Names 0
4 MODELLING RELATIONSHIPS 0
4.1 Associations 0
4.2 Aggregations 0
4.3 Dependencies 0
5 COMMON OBJECTS STANDARD METHODS 0
5.1 MemCreateClass 0
5.2 MemDestroyClass 0
5.3 ClassClear 0
5.4 ClassRetrieve 0
5.5 ClassStore 0
6 ERROR HANDLING 0
6.1 The Standard Error Object 0
6.2 Throwing Errors 0
6.3 Error Mapping 0
7 GENERAL OBJECTS 0
7.1 Standard Error 0
7.2 System Variable 0
StdDateTime 0
7.4 User 0
7.5 NullValue 0
8 LOCKING STANDARDS 0
9 TRANSACTION HANDLING 0
10 DATABASE ACCESS 0
1 INTRODUCTION
1.1 Background
Rational Rose is an OO based CASE tool for analysis and design. This tool has been chosen to design services based on Orange’s four tier architectural systems.
The application’s method recommends the use of static and dynamic views of a logical model and a physical model to capture the in-process products of object-oriented analysis and design. Using the notation, the application enables you to create and refine these views within an overall model representing your problem domain and software system.
1.2 Purpose
This document was developed from the standards used during development of the ‘Activation Service’ for the ‘Number Transfer’ project. The intention is that this document be used for discussion and as the base for the Service Delivery team’s general modelling standards.
1.3 Scope of Document.
This document outlines the standards used during development of the ‘Activation Service’. These standards will need to be refined as the team’s knowledge of Rose design improves.
The document covers standards to be applied during the design process using Rational Rose. It does not cover implementation standards.
1.4 References
Document: Service Coding Standards
Reference: R1
Version 0.4 Date: 21/06/00 Author: Steve Hesketh
2 MODEL STRUCTURE AND CONTROL
2.1 Master Model
A ‘Master Model’ will be stored under configuration control. This will be the main model for the JTI system and will contain all the classes for general use in service design. These classes will be structured into packages according to the Model Structure standard (see Section 2.2). Projects will be able to import these packages into their ‘Project Models’.
The packages will be stored as ‘cat’ files. (‘pal’ files are not handled by the visual differencing and merge tools.)
This model must be kept up to date with the live system. When projects are completed (released to live) any changes to the system should be reflected back into the main system model and committed to configuration control.
2.2 Model Structure
The model structure must match the Orange four tiered architecture. This will involve defining four packages within the Logical View to hold all the ‘real’ classes (as opposed to robustness classes or use cases):
• Interface Layer
• Business Logic Layer
• Common Object Layer
• Data Control Layer
These packages can be split into further packages where appropriate. This is described in Sections 2.2.1 to 2.2.4 below. Each package should be saved as a separate sub-unit for use in different models.
2.2.1 Interface Layer
Within the interface layer a single package will contain all the interface objects.
2.2.2 Business Logic Layer
Within the business logic layer a separate package should be created for specific functional areas. For example:
Product Activation Logic
Status Request Logic
2.2.3 Common Object Layer
Within the common object layer separate packages should be created for specific functional areas. These functional areas should correlate to those used in the data control layer. Each package will be dependent on the corresponding data control package. For example:
Product Common Objects (Product, Subscription Product, Network Feature, etc.)
Audit Common Objects (Subscription Audit, SubscriptionTransferAudit, etc.)
2.2.4 Data Control Layer
Within the data control layer separate packages should be created for specific functional areas. These functional areas should correlate to those used in the common object layer.
Product Data Control Objects (Product, Subscription Product, Network Feature, etc.)
Audit Data Control Objects (Subscription Audit, SubscriptionTransferAudit, etc.)
2.3 Modelling Process
To ensure that the ‘Master Model’ is kept up to date and is an accurate reflection of the live system every project must follow a standard process for handling configuration control and merging of the project and master models. This process is described below:
1. Master packages stored in source control as cat files or petal files.
2. Create new ‘Project Model’ and create new branches of the required packages from the ‘Master Model’. Import these packages into the ‘Project Model’.
3. Do Analysis
4. Do Design
5. Do Implementation
6. When project has completed check whether there have been any changes to the relevant main branch packages since the versions checked out for this project.
7. If no changes have occurred:
a) Use the visual differencing tool to highlight the differences between the ‘Master Packages’ and the ‘Project Packages’. These differences must be checked by the person / group responsible for the master model to ensure that they are suitable for reflection back in to the ‘Master’.
b) Merge the relevant packages and save the result as new versions. These new versions should be treated as the new master packages and stored on the main branch of the configuration control system.
8. If changes have occurred:
a) Use the model integrator tools with the following models tool to highlight the differences between the ‘Master’ and the ‘Project’ packages. The files to be used are as follows:
Base Package:
The earliest version of the ‘Master’ package common to both the other packages.
Package 1:
The most recent ‘Master’ package.
Package 2:
The ’Project’ package.
b) The differences in the ‘Project’ package must be checked by the person / group responsible for the master model to ensure that they are suitable for reflection back in to the ‘Master’.
c) The merge option will merge the ‘Project’ package to the most recent ‘Master’ package. Any conflicts will be highlighted and must be investigated. The final merged packages should be saved as new version. These new versions should be treated as the new master packages and stored on the main branch of the configuration control system.
2.4 Merging Models / Packages
2.4.1 Using The Visual Differencer
The visual differencer is a stand alone tool available with Rational Rose. It allows differences between two models or two packages to be compared and then merged. (NOT WORKING WITH PACKAGES AT PRESENT. THEY MUST FIRST BE IMPORTED INTO A SKELETON MODEL.)
It will normally be easiest to merge each package individually as follows.
1) Create a blank model and save as “Base”
2) Copy the “Base” model and save as “Reference”
3) Import the master package to be compared into the “Base” model.
4) Import the project package to be compared into the “Reference” model.
5) Start up the visual difference tool and load the above models.
6) Use the tool to compare the two packages.
7) If the only differences are new methods / attributes / classes in the project package the merge process will work automatically.
8) Where class properties (other than methods or attributes), individual methods or attributes have been changed to have new or updated meanings a manual merge will be required. [METHOD TO DO THIS HAS TO BE INVESTIGATED]
2.4.2 Using The Model Integrator
[THIS TOOL HAS VERY FEW OPTIONS TO CONTROL THE MERGE PROCESS. I AM NOT CONVINCED IT IS GOING TO BE OF USE FOR MERGING EXCEPT IN VERY SIMPLE SITUATIONS. (I.E. WHEN WE NEED IT PROBABLY WON’T WORK.) FURTHER INVESTIGATION WILL BE REQUIRED.]
The model integrator is an option available through Rational Rose tools menu. It allows differences between two models and a baseline model to be compared and then merged.
It will normally be easiest to merge each package individually as follows.
1) Create a blank model and save as “Base”
2) Copy the “Base” model and save as “New Master”
3) Copy the “Base” model and save as “Project”
4) Import the baseline master package to be compared into the “Base” model.
5) Import the new master package to be compared into the “New Base” model.
6) Import the project package to be compared into the “Project” model.
7) Start up the model integrator tool and load the above models.
8) Use the tool to compare the packages.
9) [MERGE PROCESS NEEDS INVESTIGATION]
3 NAMING STANDARDS
3.1 Use Cases
Item Standard Example
Use Case Verb Noun Validate Customer
Actor Noun Provisioning
3.2 Robustness
Item Standard Example
Interface rFromTo RjtiNms
Control rVerbNoun RvalidateCustomer
Entity rNoun Rcustomer
3.3 Interface Layer
Method names must be less than 30 characters in length.
Item Standard Example
Class From To JtiNms
Method Verb Noun Update Account
3.4 Business Logic Layer
Method names must be less than 30 characters in length.
Item Standard Example
Class VerbNounLogic UpdateAccountLogic
Method Verb Noun Update Account
3.5 Common Object Layer
Method names must be less than 30 characters in length.
Item Standard Example
Class Noun Account
Method ClassVerbNoun or Class Verb AccountGetAccountNo Account Retrieve
Constructor MemCreateNoun MemCreateAccount
Destructor MemDestroyNoun MemDestroyAccount
Attribute type_Noun where ‘type’ is as follows:
c – char
n – number (integer, long, float, etc.)
d – date
dt – datetime
p – pointer c_Surname
n_AccountId
3.6 Data Control Layer
Method names must be less than 30 characters in length.
Item Standard Example
Class ClassDataController AccountDataController
Method DBClassVerb or DBClassVerbNoun DBAccountRetrieve
DBAccountUpdateAccName
3.7 Source File Names
Source code file names must be less than 18 characters in length including the extension.
4 Modelling Relationships
4.1 Associations
Pointers. Both ways / one way only??
4.2 Aggregations
Contain object.
4.3 Dependencies
To allow configuration control and merge conflicts to be handled correctly all dependencies between classes and packages should be accurately modelled.
5 Common Objects Standard Methods
Every common object should contain a standard set of methods:
5.1 Constructor / Destructor
5.1.1 MemCreateClass
Class* p_ClassInstance MemCreateClass (StandardError* p_Error)
5.1.2 MemDestroyClass
Void MemDestroyClass (Class** p_ClassInstance)
No errors should be raised during destructions. The only methods not to be passed the standard error object.
5.2 Setting Data Within The Object
5.2.1 ClassInitialise
Void ClassRetrieve (Class* p_ClassInstance, StandardError* p_Error, into data, int data …)
Used to set up a class with the standard set of data.
5.2.2 ClassClear
Void ClassRetrieve (Class* p_ClassInstance, StandardError* p_Error)
Used to clear out an object and to destroy any associated objects.
5.3 Storing Or Retrieving From Persistant Storage
5.3.1 ClassRetrieve
Void ClassRetrieve (Class* p_ClassInstance, StandardError* p_Error)
Used to retrieve the object details from the database. The class passed to the method (using a pointer) will have attributes populated which can act as a primary key.
5.3.2 ClassRetrieveWithNoun
Void ClassRetrieve (Class* p_ClassInstance, Type Noun, StandardError* p_Error)
Used to retrieve the object details from the database. The class passed to the method (using a pointer) will be blank and the “Noun” supplied will be used to select the instance of the Class.
5.3.3 ClassStore
Void ClassStore (Class* p_ClassInstance, StandardError* p_Error)
Used to store the object details from the database. The class passed to the method (using a pointer) will have all mandatory attributes populated.
6 Error Handling
6.1 The Standard Error Object
A standard error object has been modelled. This object will be used to store any error raised within an object method and to pass the error to the calling logic / method.
Every service will create a standard error object and every method must contain a pointer to the standard error object in the argument list.
6.2 Throwing Errors
The method for throwing an error depends on the system. If the system has access to a database, which stores the error details, then the StandardErrorRetrieve method is used otherwise the StandardErrorSet is used.
6.2.1 StandardErrorRetrieve
Int StandardErrorRetrieve (StandardError* p_StandardError, integer n_ErrorNumber, char(20) c_ObjectName, char(300) c_AdditionalParameters, integer n_LineNumber, char(20) c_FileName, integer n_ProcessId)
When an error occurs on a system where error messages are stored in the DB the method / logic must call StandardErrorRetrieve passing the error number, the object name and a pointer to the standard error object. (ErrorNumber and ObjectName give a unique error.) The call can also include a string of comma separated additional attributes, a line number, a file name and a process ID.
The StandardErrorRetrieve method will retrieve the remaining error details from the database.
6.2.2 StandardErrorSet
Int StandardErrorSet (StandardError* p_StandardError, integer n_ErrorNumber, char(20) c_ObjectName, integer n_ErrorSeverity, char(120) c_StandardMessage, char(300) c_AdditionalParameters, integer n_LineNumber, char(20) c_FileName, integer n_ProcessId)
When an error occurs on a system where error messages are not stored in the DB the method must call StandardErrorSet passing the error details and a pointer to the standard error object. The standard fields to be populated will be n_ErrorNumber, n_ErrorSeverity, c_ObjectName, n_ActionCode and c_StandardMessage. The error number and the object name are the minimal requirements. (ErrorNumber and ObjectName give a unique error.)
6.3 Error Mapping
Whenever an exception occurs in a method an error should be thrown and, if appropriate reported, as described above. The method should then return to the calling method / logic.
After any call to a method the standard error object should be checked to see if an error has occurred using StandardErrorCheck. If this is the case the error has occurred and must be handled. Normally when an error has been raised this error will be passed back up to the highest level of business logic, where it will be mapped to an appropriate high level error. The mapping routines are described below:
6.3.1 StandardErrorRetrieveMapping
Int StandardErrorRetrieve (StandardError* p_StandardError, integer n_ErrorNumber, char(20) c_ObjectName, char(300) c_AdditionalParameters)
When an existing error, on a system where error messages are stored in the DB, is to be mapped to a higher level error the StandardErrorRetrieveMapping method should be called and passed the error number, the object name and a pointer to the standard error object. (ErrorNumber and ObjectName give a unique error.) The call can also include a string of comma separated additional attributes.
The StandardErrorRetrieveMapping method will retrieve the remaining error details from the database, and will move the existing error message and additional parameters to the detailed message and parameter fields.
6.3.2 StandardErrorSetMapping
Int StandardErrorSet (StandardError* p_StandardError, integer n_ErrorNumber, char(20) c_ObjectName, integer n_ErrorSeverity, char(120) c_StandardMessage, char(300) c_AdditionalParameters)
When an existing error, on a system where error messages are not stored in the DB, is to be mapped to a higher level error the StandardErrorSetMapping method should be called and passed the error number, the object name and a pointer to the standard error object. (ErrorNumber and ObjectName give a unique error.) The call can also include a string of comma separated additional attributes, and error severity and a new error message.
The StandardErrorSetMapping method will retrieve the remaining error details from the database, and will move the existing error message and additional parameters to the detailed message and parameter fields.
7 General Objects
In addition to the StandardError object, there are a number of other general objects, which are of use across all functional areas. These are described in the sections below.
7.1 Standard Error
See Section 6.1.
7.2 System Variable
This object is used to read system variables from the “system_var” table. It has a associated data-controller object.
7.3 StdDateTime
This object is used to handle Informix data/time values from within the c code.
7.4 User
This object is used to handle user_ids, user logins and user names.
7.5 NullValue
This object is used to set and check for NULL variables. This allows the definition of the NULL values to remain within a single object.
8 Locking Standards
See Bob Elliot’s document. (For discussion.)
9 Transaction Handling
10 Database Access
DB access generally on an object by object basis. In unusual circumstances data can be accessed through ‘broad’ data controllers. These broad data controllers will have access to all the tables relating to the objects in the area the data controller is to cover. The exact scope of each broad data controller will be defined and then strictly observed.
This means that in standard situations an object will only access methods belonging to the corresponding data control object. For example, an account object will access methods belonging to the account data control object. These methods will only be able to access the database tables which store details belonging to the account object (accounts and jt2_accounts).
In situations where performance or other restrictions mean that a multiple select statement is required an object will be able to access methods belonging to a broad data control object. The broad data control will be accessed by a number of objects and will be able to access all the database tables, which store details belonging to the objects lying in the data control area. For instance the product object will have access to methods in the productAreaDataControl object. The productAreaDataControl object will have access to all the tables in this area (product, prodFoundation, networkFeature).
|
Responses
|
| Author: sunilkumar 19 May 2008 | Member Level: Bronze Points : 2 | good material about uml
|
|
|