NOTE :
This is for people who are involved directly or indirectly with
Object oriented software development. Please fill up the required information
and mail it to vbidarko@cs.ttu.edu.
Students and faculty are also welcome to reply.

Thanks in advance.

***************************************************************************




Questionnaire  on  requirements of  Object Oriented Analysis and Design Methodology

INTRODUCTION

 This survey is to obtain information from the real world
regarding the requirements of OOAD methodology. This is a part of
masters thesis research in the Computer Science department at the
Texas Tech University.
All the information will remain anonymous. The information from the
 questionnaires will be used to specify a set of practical requirements
 for an OOAD and also to evaluate the existing methodologies based on this.
 Completed questionnaires may be sent by post  or e-mail to:

 Vinod Bidarkoppa
 Department of Computer Science
 Texas Tech University
 Mail Stop 3104
 Lubbock, TX 79409

 E-mail : vbidarko@cs.ttu.edu
   bed85@ttacs1.ttu.edu

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

1. GENERAL INFORMATION

1.1 Organization

 a) Name  :
 b) Address :
 c) City :
 d) State :

1.2 Area(s) of Company business   ( Mention areas which use OO  )




1.3  Personal Information
 a) Name :
 b) Your role in the organization :

1.4  OO Methodologies used at present  in your organization
  ( e.g. Booch, Coad and Yourdon, Shlaer and Mellor,OMT, Wirfs-Brock) and
  in which projects / applications.
  e.g.  G. Booch (1994 ed.) Realtime Process Control




2. METHODOLOGY REQUIREMENTS
 ( Please rate  one of the categories from A to E.
  ( A= Extremely Important,  B= Important, C= Not so important,
   D= Unimportant, E= No comment)

2.1 Structural Concepts
2.1.1 Degree of  OO support
 1. The methodology should support the usual
 meaning of the terms object (instance) and class. ( )

 2. The class should be described in terms
 of its distinct parts: an interface and body.  ( )

 3. Encapsulation and information hiding
 should be supported by the methodology   ( )

 4. The methodology should support metaclasses  ( )

2.1.2 Relationships

 1. The methodology should support  :
 i) Single inheritance     ( )
 ii) Multiple inheritance    ( )
 iii) Aggregation (container )    ( )
 iv) Associative      ( )
 v) The associative relationships should include cardinalities ( )

 2. The methodology should include / distinguish
 subclassing ( inheritance implementation with
 redefinition and / or restriction as well as addition )
 and subtyping ( just addition).    ( )

2.2  Behavioral Concepts

2.2.1 Instances

 1. The methodology should provide facility for
 dynamically creating and destroying objects.  ( )

 2. The methodology should support
 i) Notion of object state.    ( )
 ii) Export Control / Visibility  e.g. Private, Protected, Public ( )
 iii) Persistent Objects     ( )
 iv) Concurrent objects     ( )
 v) Embedded Objects     ( )
 vi) Active ( instances executing in parallel) and passive
 (executing in serial with others) instances  ( )

2.2.2 Messages or events

 1. The methodology should facilitate message passing that involve :
 i) Static Binding     ( )
 ii) Dynamic Binding     ( )

 2. The methodology should support  the following kinds of polymorphism :
 i) Inclusion      ( )
 ii) Operational      ( )
 iii) Parametric      ( )

 3. The methodology should include the following modes of communication
 i) Synchronous      ( )
 ii) Asynchronous     ( )

 note : Synchronous is where the sender suspends execution till the
 receiver processes the message and asynchronous is where the sender
  continues processing.


2.3 Process
 1. The methodology should prescribe steps / guidelines for identifying :
 i) Semantic (Abstract) classes    ( )
 ii) Attributes       ( )
 iii) Methods      ( )
 iv) Allocating attributes and methods to classes ( )

 2. The methodology should specify guidelines for identifying the
 following relationships :
 i) Generalization     ( )
 ii) Aggregation      ( )
 iii) Association     ( )
 iv) Cardinalities     ( )

 3). The methodology should be able to specify dynamic behaviors
 through the following :
 i) Message connection     ( )
 ii) Instance connection     ( )
 iii) Object interaction diagrams   ( )
 iv) State machine     ( )
 v) Event and state generalization   ( )
 vi) Interactions within the state   ( )
 vii) Timing  diagrams     ( )
 viii) Formalization of abnormal behavior  ( )


 4). The methodology should prescribe guidelines  to identify and decompose :
 i) Structural complexity    ( )
 ii) Dynamic complexity     ( )

2.4 Design features

 1. The methodology should prescribe guidelines for the following :
 i) Specifying  system architecture   ( )
 ii) Specifying and integrating interface classes for
 human interaction     ( )
 iii) Specifying and allocating tasks / processes to processors ( )
 iv) Specifying and integrating classes for
 database management     ( )
 v) Data structures and pseudo code for
 the application classes     ( )
 vi) Refinement of overall analysis and design in
 scope of all the new classes added   ( )

 2. The methodology should prescribe OOSE features regarding :
 i) Release planning     ( )
 ii) Work products ( deliverables) review  ( )
 iii) Incremental development    ( )

2.5  Representation

2.5.1 Static Views

 1. Class and Object     ( )
 2. Attributes      ( )
 3. Methods      ( )
 4. Generalization     ( )
 5. Aggregation      ( )
 6. Cardinalities     ( )

2.5.2 Dynamic views

 1. Instance connection     ( )
 2. Visibility      ( )
 3. Message connection     ( )
 4. Control / timing     ( )
 5. Concurrency      ( )
 6. Object interaction diagrams    ( )
 7. State charts      ( )
 8. Nested states     ( )

2.5.3 Constraints

 1. On structure      ( )
 2. On behavior      ( )

2.5.4 Complexity

 1. Static structure     ( )
 2. Dynamic behavior     ( )

2.6 Miscellaneous

 The methodology should :

 1. Be Scaleable      ( )
 2. Have semantic and syntactic definitions  for all notations ( )
 3. Use same notations for analysis and design  ( )
 4. Provide deliverables at every stage   ( )
 5. Have case tool support for graphical layout  ( )
 6. Have case tool support for
  simulation / code generation   ( )
 7. Check for extensibility    ( )
 8. Check degree of coupling and cohesion  ( )
 9. Check for consistency    ( )
 10. Checks for completeness    ( )
 11. Prescribe performance evaluation   ( )
 12. Prescribe non-graphical specifications  for entities
 discovered at all stages    ( )

3.0  Comments and suggestions