1

SCOOI (Scenario and Collection based object oriented interaction) model and specifications for this model to be implemented for developing SCOOI languages. (BY Satish Duvvur B.Tech (electrical engineering), (MS (Electrical engineering))) E-mail: satish7d@yahoo.co.in Telephone: 0091-877-2238044 Personal Quote: Understanding can bring change. Deeper the understanding better the change. Contents Objective Conception of this model Guide to understanding this document

Advantages of SCOOI language Specifications for SCOOI language 0) Scenario 1) State class 2) Classes in a scenario 3) Collections 4) Scenario functions 5) Enumerations 6) Some Additional Features of SCOOI Applications with reference to object oriented Applications. Notes Assumptions Illustrations Status of this document Future Research About the Author Feedback to the author

Objective: Development of a model for system level functionality reuse and extension and to discuss features and specifications for such model for development of SCOOI language. Conception of this model: Few months ago I felt that if a code can be encapsulated and reused at object level why not at system level? Since a system comprises of objects and their interaction, for code to be reused and extended at system level there has to be a model for encapsulating object interaction and reuse of object interaction. First step in designing the model is to define a scenario that encapsulates the objects definition of system and collecting the functions that operate on objects and put them together in the scenario. But this is not sufficient in extending system behavior because most of the system functionality is interaction of objects in various scenarios. To implement this I have come up with an idea of generalized collections for the system functionality to be reused. Collection in this context is defined a set of objects and their interaction implemented as row functions and collection functions. Collections can be cascaded and inherited for object interaction reuse and extension. I have developed specifications for this model to be used for development of SCOOI programming languages. Guide to understanding this document Understanding the following concepts or procedures discussed in this document are key to understanding the implications of this model and specifications. Meaning of object interaction Scenario behavior Collection behavior as described How collection implements object interaction thereby is providing for system functionality encapsulation and reuse. Scenario inheritance, collection inheritance and collection cascading Why rules for collection inheritance are made How code reuse can be made through collection inheritance The above concepts when implemented provide for system level functionality encapsulation and system level functionality reuse through scenario and collection inheritance. The following concepts or procedures make SCOOI language much more powerful by adding new dimensions to inheritance and polymorphism. To understand the power of SCOOI model you have know the implications of this concepts or procedures. * Collections defined in a super scenario when referred through sub scenario uses overridden scenario functions of sub scenario. Scenario polymorphism Collection polymorphism * One interesting feature is sub objects can be added to collections providing for a polmorphic feature that will be very useful.

3 *Collection cascading provides for reuse of object interaction code for cross functionality purpose between the objects being cascaded. Event Driven programming - See specifications.collections.collection types *Note: any one who is interested can coin a term for this concepts or procedures. Any one who want to understand the features provided by this model and implications of this model has read all of the following. 0) Scenario 3) Collections Basis of SCOOI Model: Scenario A scenario is an object that encapsulates object definition and their interaction. The members of scenario are classes or objects, collections, state class and scenario functions. Collection is defined as a collection of snapshots of object interaction. Operations in snapshot can implemented as row functions and operations on the collection of snapshot can be implemented as collection functions. If an existing system implemented has to be extended it can be done by scenario inheritance. Inherited scenario can contain a new classes and/or inheritance definitions and/or inclusion of scenarios. Scenario also defines scenario functions that can be used by collections in the scenario and they can also use collections. Functions of SCOOI language can take collections as arguments and can return them. Scenario functions Scenario functions are defined in the scope of a scenario and can be over ridden in inherited scenario. They can also be declared to be polymorphic. Collections in a scenario can use the scenario functions of that scenario. Suppose if a collection uses a scenario function which implements an operation between the objects of collection and it is overridden in sub scenario then if the collection is declared as qualified by sub scenario uses this overridden method preserving all other operations thereby this object interaction is changed without changing the collection. Collections Collection is defined to be collection of set of objects (can be classes or another collection) and operations on them are defined as row functions and collection functions of the collection. Collections have row functions which operate on each row that is each set of objects (can be classes or another collection) defined in collection. Row functions take objects by the row referenced as implicit arguments. Collection functions of collection take whole collection as implicit argument. Collections can be inherited from another collection or can be cascaded. Cascading is a feature provided to reuse the existing functionality for cross functionality purpose. It will be clear after reading the specifications. Collections can also be of type interface which can be used to implement collection polymorphism. Advantages of SCOOI language:

4 To an extent the object interaction can be implemented in object oriented languages by using inner classes but it is too cumbersome. Languages used functions for structured programming and the next step is languages used objects for data encapsulation and objects reuse. SCOOI languages are step ahead of object oriented languages because they implement object interaction by using scenario and collections to encapsulate system functionality and for system functionality reuse. Most of the object oriented design parameters can be directly implemented. Functionality resulting from Associations can be decoupled so that the objects involved can be reused efficiently. Aggregation, containment, list can be directly implemented and can be extended easily. Collection Polymorphism is a powerful feature. Summary of Advantages of SCOOI languages 1) System functionality encapsulation and reuse 2) Direct implementation object oriented software design parameters. 3) Provides for loosely coupled and highly cohesive design of objects. 4) Decoupling of code resulting with associations. 5) Provision for reuse of object interaction functionality of super collections for cross functionality in a sub collection. 6) Collection polymorphism is a powerful feature which cannot be implemented in object oriented languages. 7) Easier to develop and extend frameworks. 8) If for a scenario the state class is implemented it will be useful for state driven applications. 9) Would be of great use in programming environments that does not use pointers. 10) Can directly implement list, containment, composition and extend them. Specifications for SCOOI language I have illustrated some of the specifications and I assume the syntax usage is self explanatory (Object oriented languages syntax). I described the syntax if it is not self-explanatory. 0) Scenario 0.1) Scenario behavior Scenario definition encapsulates the definitions of its members namely classes, collections, scenario functions, enumerations and state of a scenario that can be implemented as a class. A scenario can inherit scenarios and/or class inheritance definitions for classes defined in the scope of inheritance and/or additional classes. If scenario is inherited it can access the super scenario members and extend the definition of members if they are not restricted by their access. Scenario supports polymorphism. 0.2) Declaration Scenario can be declared within the scope of scenario inclusion. In the declaration the state of the scenario may be initialized if not initialized the state will be the initial state. 0.3) Assignment A scenario declared can be assigned to scenario declared with same scenario definition or its sub scenarios. 0.4) Scenario Inheritance Like class Scenario can be inherited publicly, privately and protectively. Same rules for accessibility of members that apply to class applies to scenario members.

5 0.5) Scenario members Scenario consists of following members 1) State class 2) Class definitions 3) Collections 4) Scenario functions 5) Enumerations Specifications for these members follow with illustrations whenever needed. 1) State class 1.1) Behavior State class is similar to all other classes except that can only be instantiated when a scenario is declared. An initial state can be assigned to each scenario thereby a scenario when declared by default the state class will be assigned initial state. Name of the state class is a key word for example it can be state. 1.2) Definition State class is defined within the scope of scenario like any other class in the scenario. 1.3) Instantiation State class is instantiated when a scenario is declared. Illustration (1) Declaring a scenario. Bankscenario B(state()) 1.4) Members Members of the state class are same as for a normal class in object oriented language. Functions can be qualified to be polymorphic. Members can be used by the collections and scenario functions of the scenario. 1.5) Inheritance The sub scenario state class should inherit state class of super scenario. 1.6) Assignment State class cannot be assigned directly to another state class. It will be assigned when assignment of the scenario takes place. Note: State implementation is not mandatory for SCOOI Programming model. 2) Classes in a scenario 2.1) Definition

6 Class definition is same as in object oriented programming context. 2.2) Members Members of the class are same as the class in object oriented languages. Collections and scenario functions can only use public members of the class. 2.3) Instantiation Classes can be instantiated in the scope of scenario inclusion directly in SCOOI program without being qualified by scenario in which it contains if there is no name clashing. 2.4) Access Class definition in a scenario can have public or protected or private specifiers. Public: can be used in the scope of scenario inclusion and anywhere in the scenario definitions. Protected: can be used by scenario functions and collections in the scope of inheritance. Private: can only be used scenario functions and collections in the scope of scenario in which it is defined. Note: Only public classes can be used in definition of collections 2.5) Types Classes can be defined to be virtual or interface types. The definition is same as that used by object oriented programming context. 2.6) Assignment Same as in object oriented programming context. 3) Collections 3.1 Behavior A collection of set of objects (classes) and their interaction implemented as row functions and collection functions. Each set of objects is a row in collection and all the instances of rows is a collection of set of instances. Row functions of collection operate on each row (set of objects) and collection functions operate on the whole collection .To provide for efficient memory management and polymorphism all objects added to collection are passed by reference. Collections can be of type interfaces and listeners to provide polymorphism and event driven programming. Collections can either be inherited or cascaded or both Collection inheritance A collection could inherit another collection if objects (can be a collection or class) in sub collection inherits an object defined in super collection and/or additional objects are defined in sub collection and/or additional functions are defined in sub collection and/or functions are overridden in sub collection. Collection cascading Cascading is a mechanism of combining each row of the objects (can be a collection or class) to be defined to form a row of cascaded collection. Each object used in a collection is a sub collection of the cascaded collection. Provision of this mechanism is for code reuse for cross functionality.

7 Cascading and Inheritance If cascaded collections of the cascaded collection A are inherited. A sub cascaded collection of A can be defined as cascade of inherited collections of super cascaded collections of A. Illustration 3.1: If A is cascade collection of collection B and collection C. If collection B1 inherits collection B and collection C1 inherits C then Collection A1 can inherit collection A if the cascaded collections in definition are Collection B1 and Collection C1. 3.2 Objects in collection Objects defined in collection may be a class or another collection. Private, protected and public objects can be used in collection definition. Members not accessible in collection can be assigned NO INSTANCE value while adding to a row. In addition collection typing can be used to restrict the access. 3.3 Collection typing Collection can be defined to be typed to another collection if objects in the collection definition are restricted by access by the way objects are defined. Level of access in typing can be private, protected or public. Private objects are accessible within the scope of collection definition and by its functions. Protected objects are accessible within the scope of collection inheritance. Public objects are accessible globally wherever collection is accessible. Super and sub type collection: sub type collection of collection is the one which is typed from a collection. Collection that is being typed is super collection. Note: collection typing is necessary to restrict the member access and in inheritance reference 3.2 Definition A collection is defined to be set of objects, which are classes and operations on them, which are functions. Functions are of the type row functions and collection functions. Collection function also defines inheritance and cascading. The following rules should be observed in definition 1) The scenario implicitly qualifies objects defined in collection where it is defined. If this has to be overridden then the objects may be qualified by the scenario whose scope is within the scope of scenario inheritance in which the collection is defined. 2) Name clashing: There can be no more than one super collection or super class with the same name in the objects definition. In case if there arises of a situation in which super collection or super class has to repeated it has to be assigned a pseudo name. The following specifiers can be used to define the collection. 1 Inherits: specifies which collection or class is being inherited. 2) cascading: specifies cascading of different collections. can use a + sign for cascading (cascading explained in collection behavior)

8 2) Objects: specifies set of objects being used. 3) References: specifies which inheritance relationships between the objects of the collection and objects of sub collections. 4) Direct: can indicate how objects can be added directly (direct addition) to collection row 5) Singleton: specifies which objects are common for all rows of the collection. This can be over ridden in inheritance 6) Common: specifies the objects common in each row of the collection 7) Rowfunctions: specifies the row functions used in this collection 8) Collection functions: specifies the collection functions used in this collection. 9) Pseduoname: specifies an alternate name for a collection to avoid name clashing. 10 Uses type :Specifies the type of collections being used. Refer Rules for inheritance for more Illustration3.2: Suppose a scenario consists of employee, bank, customer, transaction, newemp inherits employee. Then the collections emp and cust can be defined as follows 1) If the collection is a set of objects employee, bank and each row has to be added has employee object and bank object common to collection and has join_employee and change_employeestatus() row functions it can be defined as follows. Collection emp objects(employee,bank) direct(employee,singleton(bank)) rowfunctions { join_employee(); change_employeestatus() } collectionfunctions { get_employees_details();}

2) similar to 1) the collection cust can be defined as follows. Collection objects (customer,bank) direct(customer,bank) rowfunctions { join_customer(); change_customer_status() } collectionfunctions { get_customer_details(); suppose if new collection cempnew is to defined as collection newemp and bank then it can be defined as collection cempnew inherits( emp) objects(newemp,bank) references(newemp:collection emp->emp) direct(newemp,bank) rowfunctions{.} collectionfunctions{} 3) Cascaded definition of collections Suppose if there is a collection cascading is needed for emp and cust collections and transaction object it may defined as Collection objects(ctransaction collection emp+ collection cust ,transaction ) direct(customer,employee,singleton(common(emp.bank,cust.bank)),transaction)

9 Rowfunctions { .};collectionfunctions{} 4) Non cascaded definition. If the collection ctransaction is defined as collection of collection emp,cascaded collection of cust and transaction.Then the collection can be defined as Collection ctransaction objects(collection emp, collection cust+transaction) Direct(collection emp,customer,singleton(bank),transaction) 5) Difference between cascaded and non cascaded collection uses 3) and 4) since in noncasded defintion collection emp is defined in each row. Each row should contain the whole collection emp rather than a row of emp.

3.3 Declaration Collection declared should be qualified with a scenario already declared. Collection referred anywhere is always associated with scenario. 3.4 Condition and Rules for inheritance Condition Any collection A can inherit any collection B If the objects (can be collection or class) defined in a collection B are inherited by some of the objects (can collection or class) defined in collection A and /or extra objects are added to definition of collection A and/or functions of collection B are overridden and/or Additional functions are defined in collection A and collection B is accessible in the scope of scenario in which A is being defined. Rules 1) There can only be one instance of super collection objects for each instance of objects in sub collection. Implication of this rule is that the super collection object Relation ships) can only be referred (reference of inheritance) once by sub collection objects. 2) The same super collection can be reused in inheritance relationship only if they are renamed using a pseudo name. This rule can be used to circumvent the problem arising from rule 1. 3) If collection consists of cascaded collections then the objects in cascaded collection may refer inheritance relationship across the sub cascaded collections. If rule 1) is not violated. 4) In referring the inheritance relationship the type of inheritance should be preserved for objects. This can be done with the aid of collection typing. Illustration3.3:

10 Rule 2 If there is a class emp and newemp inherits emp . Collection twoemp objects(emp+emp) direct(emp,emp) is wrong violates rule 2 Correct definition would be Collection twoemp emp+emp pseduoname(anotheremp) direct(emp,emp) Rule 3 If there are collections A,B,C,D then the collection E Collection A+Collection B+Collection C+ Collection D then the object of E can reference a multiple inheritance Across collections A,B,C and D. If rule 1 is not violated. 3.5 Row Functions: Row functions are members of a collection and they can access scenario functions Arguments and return types: They take each row of the collection as implicit arguments And can have explicit arguments and they can return collections. Invocation: Can be invoked by using a collection qualifier which references a row index or key of row. This collection used for qualifying should have defined the row function. Member access: They can access the members of the row of collection by the object names. In Inheritance: They can be over ridden by the inherited collection and they can be specified to be polymorphic. There can be restriction specifier for polymorphic row functions only to use polymorphic functions as a precautionary measure. If they use scenario functions in a scenario and this scenario functions are overridden and the row functions of the collection qualified by super scenario uses overridden functions of super scenario. 3.6 Collection Functions Collection functions are members of a collection and they can access scenario functions. Arguments and return types: They take whole collection as implicit arguments and can have explicit arguments and they can return collections. Invocation: can be invoked by using a collection qualifier in which it is defined. Member access: They can access the rows of the collection of collection by the index or key if it is defined. In inheritance: They can be over ridden by the inherited collection and they can be polymorphic. There can be a restriction specifier for collection functions only to use polymorphic functions as a precautionary measure. If they use scenario functions in a scenario and this scenario functions are overridden and the row functions of the collection qualified by super scenario uses overridden functions of super scenario. 3.7 Access Collections access can be specified as private or public or protected. Private: can be accessed by all members of scenario except classes and cannot be used outside the scope of scenario. Protected: can be accessed by all members of the scenario in the scope of inheritance and cannot be accessed by classes.

11 Public: can be accessed by any scenario and in the application limited by the scope of scenario inclusion. 3.8 Types A collection can be defined to be of interface type and listener type. Interface type: Interface collection may or may not define objects in its definition. It defines Row functions and collection functions definitions. It can be used to implement functionality And to provide collection polymorphism which is a powerful feature. It can be used with implements specifier with another collection. It can be inherited. Listener type: Listener type collection defines the events that will be implemented for a collection. It can be used with listener specifier with another collection. This can be implemented in event driven programming environment. The listener collection can be inherited. 3.9 Assignment of collections: Definition of super collection and sub collection: The following conditions apply for definition of super collection and sub collection. 1) If any collection B inherits collection A. Then Collection A is said to be super collection of collection B and collection B is said to be the sub collection of B. All super collections of B are super collections of A. 2a) If collection A is a cascaded collection of collection B and C. Then B or C is said to be super collection of A. 2b) All super collections of B or C as defined either by 1 or 2a are super collections of A. Rules 1) Since collections are always qualified with scenarios A collection can only be assigned to another collection if assigned collection is declared qualified with the same scenario or a super scenario. 2) A sub collection can be assigned to a super collection. 3) If there is name clashing a collection should be assigned to a named collection. 4) A collection with a pseudo name can be assigned to a collection with different pseudo name if the collection assigned to be of the same definition or definition of super collection. 5) A row of one collection can be assigned to another collection or row of another collection if rule 1, 2, 3 & 4 are satisfied. 6) Any collection D can be assigned to interface collection that implements it and super collections of D if rule 1 is satisfied. 7) Rule 2 can be applied to interface collections. 8) A super type collection can be assigned to sub type(see collection typing). 3.10) Adding objects to a collection:

12 All the objects that are defined in objects specifier is a row in a collection. Objects defined can be added directly or indirectly in case of cascading as a row of collection. Direct addition: All objects that are defined in direct specifier of a collection can be added as a row to the collection. Indirect addition: All objects that are defined in cascading can be added to a row as defined cascading and conditions used by specifiers other than direct specifier should be satisfied. In both forms of addition objects or super objects not used in definition specified by objects specifier should be assigned NOINSTANCE value. Assignment of collection row to the row to be added can also used if collection assignment rules are satisfied. For both types of addition a sub object can be passed instead of the object. This feature is will be a bonus for polymorphism. A NOINSTANCE value specifier can be used to be passed while adding a row if the object defined in a row has no instance in that row. Singleton objects when added will be overwritten if added after adding the first row. A key value for the collection can be passed to collection while adding a row. Illustration3.4 If a collection emp is defined to be cascaded objects of employee and bank in bankscenario. bankScenario b(state()) collection b.emp //Adding a row to emp collection with key b.emp(new employee(),new bank(): key(first)) 3.11Referencing collection elements Each row in a collection can be referenced by an index or by key. The objects in the collection can be referenced by their name in the collection definition. 3.12 Removing elements A function to remove the row referenced either by key or index can be used to remove a row of the collection. 3.13 Modifying elements The objects defined in a row are passed to collection referred by index or key the row referenced will be over written.

4) Scenario functions 4.1) Behavior A scenario function is same as the function in object oriented languages except that it can also take collections as arguments and also can return them. They can be declared polymorphic also. 4.2) Access

13 Scenario functions in a scenario can have public or protected or private specifiers. Public: can be used in the scope of scenario inclusion and by the scenario functions and collections. Protected: can be used by scenario functions and collections in the scope of inheritance. Private: can only be used scenario functions and collections in the scope of scenario in which it is defined. 4.3) Invocation Can be called similar like a function in object oriented language but should be qualified with a scenario declared. 4.4) Behavior in scenario inheritance The scenario functions can be overridden in scenario inheritance and can be polymorphic. 5) Enumerations Same as in object oriented languages. 6) Some Additional Features of SCOOI Applications with reference to object oriented Applications. 6.1 Scenario inclusion A Scenario should be included in application if its members are to be used. Scenario and its members can be used in the scope of inclusion. 6.2 Functions Functions in the application can take collections as arguments and return collections. 6.3 Polymorphism Polymorphism Definition: If a super object is assigned to sub object then invocation of functions specified to be polymorphic in inheritance or implements relationship of super object invokes the functions of the sub object. Object: Object used in the above definition can be scenario, collection or class. Sub and super objects: Any Object A inherited from definition B, then B is super object of A and A is sub object of B. SCOOI language should provide for the polymorphism as defined as above. Note: 1) For Super collection and sub collection definition refer assignment of collections. 2) Polymorphism defined by collection polymorphism provides for overloaded polymorphism because functions of collections take collection as implicit argument.

14 Notes: 1) If state class is not implemented scenario declaration may not be necessary. In this case it can be used as a qualifier for its members. 2) Tokens and syntax used in illustrations are only for illustrating the specifications. 3) Terminology that is widely recognized has been used without definition. 4) Specifications discuss only the additional features other than object oriented programming features that should be implemented for SCOOI languages. Assumptions: 1) May have assumed standard object oriented programming principles. 2) Syntax and tokens used in illustrations is self explanatory. Illustrations: Note: For the following illustrations C++ synatx is used and assumes that they are self explanatory. Illustration 1) Bank example A scenario bank consists of the classes ( not enclosed by dashed lines.)

BANK

DEPT

DEPOSIT

has
CUSTOMER

Pays

THRIFT

BANK DEPOSIT

CUSTOMER DEPOSIT

May have a loan

One of the customers

CUSTOMERS

LOAN

HBL

GL

Scenario bank consists of the following definitions of scenario functions and collections. Classes in scenario bank are the ones, which has enclosed, in dashed lines are not

15

Polymorphic IssueLoan() Polymorphic PayDividend() Polymorphic debittocustomer() Collection CustAndBank objects(customer+bank+database) direct(customer,singleton(bank),singleton(database) ) Rowfunctions { AppliesForLoan(); AppliesForShare(); GetcustomerDetails(..) } collectionfunctions { GetCustomersDetails() } Collection EmpAndBank objects(Employee+bank+database) direct(employee,singleton(bank),singleton(database) ) Rowfunctions { GetEmployeeStatus(); ChangeEmployeeStatus(); } collectionfunctions { GetEmployeesDetails() } Collection transaction objects(CustAndBank+EmpAndBank+Customerdeposit+thrift+loan) direct(common(singleCustAndBank.bank,EmpAndBank.bank)++thrift+customerdeposit+loan) Rowfunctions { Polymorphic dotransaction(transactiontype) { If transactiontype = 1 then CustAndBank.Getcustomerdetails(..) AND EmpAndBank.GetEmployeeStatus then issueloan() } } Collectionfunctions { GetStatistics() {} }

Scenario bankextension inherits scenario bank in which a Dept class and inheritance of loan is included and has following scenario functions and collection definitions. This included classes are shown in dotted rectangles in the diagram. Polymorphic issueloan() //overrides issueloan in bank scenario

16 Polymorphic issueGL() Polymorphic isssueHBL(..) Assumming the dept inclusion affects CustAndBank and EmpAndBank collection New collections CustAndBankAnd Dept and EmpAndBankAndDept will inherit CustAndBank and EmpAndBank respectively. Collections TransactionGL and TransactionHBL will inherit from collection Transaction can be defined as follows Collection TransactionGL collection inherits( transaction) objects( CustAndBankAndDept + EmpAndBankAndDept + Thrift +GL+CustomerDeposit) references(CustAndBankAndDept>CustAndBank ++GL->transaction->Loan) direct() Rowfunctions { Polymorphic dotransaction(transactiontype) { If transactiontype = 1 then CustAndBankAndDept.Getcustomerdetails(..) AND EmpAndBankAndDept.GetEmployeeStatus then issueGL() } } Collectionfunctions { GetStatistics() {} } Collection TransactionHBL collection inherits( transaction) objects (CustAndBankAndDept + EmpAndBankAndDept + Thrift +HBL+CustomerDeposit) references(CustAndBankAndDept>CustAndBank ++HBL->transaction->Loan) direct() Rowfunctions { Polymorphic dotransaction(transactiontype) { If transactiontype = 1 then CustAndBankAndDept.Getcustomerdetails(..) AND EmpAndBankAndDept.GetEmployeeStatus then issueHBL() } } Collectionfunctions { GetStatistics() {} } Note: Variables are not declared collections and scenarios are directly referred. Example of scenario overriding Bankextension.transaction.dotransaction(1) will use the overridden method issueloan in the dotransaction.

17

Example of scenario polymorphism Scenario bank = bankextension Bank.issueloan() will call the superscenario method Example of collection polmorphism Bankextension.Transaction = TransactionHBL Bankextension.Transaction.dotransaction(..) will call the method of TransactionHBL. Status of this document This Model has been sent to document disclosure program. This document is unpublished and only author knows the content of this document. Future Research 1) Analogy Database Model: Analogy databases model extends relational database model. I want to develop analogy database model and specifications for developing this model. This model when developed can be used as a database server for any general expert system application. Analogy Database model will be based on artificial intelligence concepts. I use the term Analogy because I believe that basic human learning stems from analogies. Principle of deduction equivalence I have found can be used to build a feasible model. 2) BrainMemory Model I have thought a lot about how humans recollect and think. I have found out in thought process every thought is related to the thought that follows. I want to develop a model that reflects this relationship and apply it to computer software systems development arena. Most likely a new data structure or a new algorithm may result in applying this model. 2) Analogy Programming Model This is a programming model in which classes, functions, comparisons are modeled as noun analogy, Verb analogy and adjective analogy. In addition to this analogies there will be a rule analogy. To implement this model compiler should have program synthesis capability. Feasible program synthesis (AI Feature) adds a dimension to programming languages. Note: Authors primary interest is to build feasible Analogy Database model.

18 About the Author Has discontinued MS electrical engineering program at Florida Atlantic University and joined IBM as a contractor and consultant for Keane Inc and CDI. Now freelancing as a Visual Basic programmer in a small town in India. Knows Visual C++, Java and ASP. Right now thinking of relocating to a city in India or to abroad. Long-term objective is to design and develop neural processor and neural programming model. Feedback to the author Can contact author at E-mail: satish7d@yahoo.co.in. If the author does not respond in two days you can call at 0091-877-2238044 between 7.30AM-9.00AM and 9.30PM-11.30PM Indian standard time.