Bridging the Gap Between Structured Requirements and ... - CiteSeerX

Proceedings of the 29th Annual Hawaii International Conference on SystemSciences- 1996

Bridging the Gap Between Structured Requirements and Object-Oriented Nina Katie Application Systems Analyst email: [email protected]

Analysis and Design

Boris Nevstrujev Application Systems Analyst email: [email protected]

Dr. Douglas Vogel Associate Professor email: [email protected] All affiliated with the MIS Department, College of Business and Public Administration, University of Arizona, Tucson, Arizona 85721. Phone : (520) 621-2748 Dr. Mark 0. Pendergast Asst. Professor Management and Systems Dept. Washington State University f 00 Sprout Rd Rich/and, WA 99352 email: MOP@BETA. TRICITY. WSU. EDU training, yet power@ enough to enable the participants to think through the model in an Object-Orientedfashion.

Abstract A very large part of the business world today still uses traditional structured approach to the requirements gathering. On the technology side, extensive development has been-done in the area of Object-Oriented technologies that provides for productivity and quality through reusability, encourages team work and adopts a modular approach. Since the quality of the Object-Oriented applications has proven to be superior to the structured applications, especially in the area of maintenance, there has been a large demand for Object-Oriented applications. This leads to the situation where the requirements are structured, and the application needs lo be Object-Oriented. Subject Matter Experts (SMEs), with their knowledge of rhe system modeled, and analysts, with their knowledge of Object-Oriented paradigm, need to work together and reorganize the information fom the requirements analysis in the Object-Oriented fashion. This paper proposes and develops a methodology for the @an&ion. Emphasis is placed on preserving the knowledge captured in the requirements specification. The proposed methodology extends the existing Classes-Responsibilities-Collaborators (CRC) method and is tailored to be simple and understandable to SMEs, requiring minimal amount of

1060-3425/96 $5.00 0 1996 IEEE

1. Introduction For many existing Information Systems, requirements analysis has been performed using structured methods. The goal of this project is to empower SMEs to work with analysts to represent the structured information they have in an Object-Oriented fashion. The advantages of g&g through this process with SMEs is that the knowledge captured is not distorted, because SMEs actively participate and monitor the validity of information represented as modeling progresses. This paper begins by giving background information about IDEF family of methods, which is the structured methodology of choice for this project. Then, the benefits of group modeling and past work in Object-Oriented Analysis (OOA) are reviewed. The difference between structured and Object-Oriented approach to analysis is explained. Some known problems in the transition from structured requirements to Object-Oriented analysis are highlighted. The CRC methodology is presented in the methodology section. This paper extends the original CXC Methodology by offering wider view of the entire process, including a transition stage to the formal Object-Oriented analysis. The

525

Proceedings of the 1996 Hawaii International Conference on System Sciences (HICSS-29) 1060-3425/96 $10.00 © 1996 IEEE

Proceedings of the 29th Annual Hawaii International Conference on System Sciences- 1996 proposed methodology Methodology.

is

named

Extended

CRC

2. The transition problem Many of the Object-Oriented methodologies evolved from variations of the structured approaches. Many of them offer a way to do the transition of the knowledge captured in the structured form to the Object-Oriented form. However, one large problem can arise in the process of transformation. When first modeling the problem domain, the analyst uses his knowledge to best represent the entities and processesin the structured manner. To do the Object-Oriented transition, other analysts will take the output of the structured analysis, already somewhat transformed, and regroup it according to the rules of the Object-Oriented analysis. This is the second major transformation of data since it came from the source, the SMEs. The risk is that information has been exposed to too many modifications on the way, and is starting to represent a different picture than the original. The post-modeling interviews that occur when analysts, without additional knowledge of the problem domain, try to “pack” entities and processesin the objects, can be very time consuming, difficult, and imprecise. Inconsistencies and vagueness can arise from this highly involved mental process and it is much harder to get SMEs involved again and have them focus on the problem days or weeks after the modeling sessionhad been finished. One way to addressthese problems is to change the roles of SMEs and analysts - empowered SMEs can be allowed to capture basic system requirements themselves, using appropriate techniques and tools. Analysts become facilitators of the early system requirements gathering process that assist SMEs in order to enable them to stay focused on the task. This approach greatly reduces the possibility of errors, inconsistencies, and vagueness in the system development process.

3. Background 3.1 IDEF Family of Methods The IDEF family of methods represents a series of methods governing different aspects of systems modeling. It is widely used by the Department of Defense, in modeling of the existing and future information systems. IDEFO is the functional modeling technique. It is used for the structured, functional representation of the system. It is hierarchical in nature, and based on activity decomposition. IDEFlx is an extension of entity-relationship diagrams, the information model. It is used for data modeling, and primarily supports the relational technology of databases.

IDEF3 is the process model, process flow and events that happen to objects in the system. This technique has many of the aspects of the dynamic model that is an integral part of OOAD methodologies. IDEF4 is an Object-Oriented model that can be used for the design of the Object-Oriented systems. More details about IDEF metho& can be found in

rm llW1. 3.2 Benefits of Group Modeling A stream of research that has been performed at the University of Arizona, MIS Department over the course of several years has demonstrated that group modeling is far superior to individual’s modeling in terms of quality, as well as the advantages of the electronically supported versus manual processes [7][8][13][15]. Here are some of the reasons: First, group knowledge, especially when it comes from different functional areas of the organization, is much richerthan individual knowledge. Individual SMEs are very knowledgeable in their area of expertise. When the knowledge from different areas is combined, the chances for better model accuracy and completeness are much higher. The participants’ knowledge about the other parts of the system increasesthrough discussion and knowledge sharing. Groups are better at discovering modeling errors than individuals. Applying use-case scenarios is one very good way to notice errors through group discussions. Cooperative work and cross review by participants increases the quality of representation. Time spent discussing initial misunderstandings and deficiencies in requirements is well spent, because it ensuresthe better model and ultimately, the better system. Of course, there are cognitive difficulties that exist in the group modeling process. Different SMEs have different mental models of the system that vary not only in scope and details, but also in how well they represent the domain. This is when facilitator’s role becomes especially important in helping achieve the common understanding of the system modeled. In order to really benefit from the parallel work it is necessary to use the tools and processes that provide the group with ability to work together (editing of CRC cards, in our case), and to achieve the synergy through focused group discussions (of use-case scenarios developed on the public screen). This way, the modeling process is faster, more dynamic and captures more information. In addition to the previously mentioned advantages of the group versus individual modeling, there are also many advantages of electronic versus manual modeling. The University of Arizona has a long history of creating and applying electronic tools to support groups 1151. GroupSystems, the electronic meeting system (EMS), has

526


Proceedings of the 29th Annual Hawaii International Conference on SystemSciences- 1996 proven to be very successful in improving the quality of outcomes and the efficiency of complex tasks performed by large collaborative groups [lo]. EMS has been shown to improve the quality and quantity of ideas generated, reduce time spent in meeting by more than 50%, and cut project completion time by as much as 90% [3]. Subsequently, IDEFO modeling tools for groups were developed, that have shortened the modeling time to a third of the time spent in manual processes, and increased the quality of the models

171. 3.3 Approaches to Object-Oriented Analysis and Design (OOAD) There are many different approaches to OOAD, but in essence,they all can be divided in two categories: static and dynamic. Due to the heavy influence of the previous data modeling research on OOAD there are many more static models. Models that are capable of capturing and representing dynamic behavior (event-handling, the sequence, timing and control of events and processes) are much more rare. Whether the approach is through functional modeling, data modeling, or dynamic modeling - the heuristics for translation to an object design are incomplete [ 141.What is most needed in OOAD research is a model that synthesizesstatic and dynamic features of systems at various levels of abstraction. There are three general approaches to OOAD, characterized by the manner and degree to which they incorporate other paradigms [ 141: The combinative approach - Use Object-Oriented, function-oriented, and/or dynamic oriented techniques to separately model structure, functionality and/or dynamic behavior and provide a method for integrating the different models. The problem with combinative approaches is that they deteriorate when they try to integrate the different views into an Object-Oriented design. Rumbaugh [16] and Shlaer and Mellor [ 171are in this category. The adaptive approach - Use existing techniques in a new (Object-Oriented) way, or extend existing techniques to include Object-Orientation. Traditional DFDs and ftmctionoriented representations can be used in a new context. This approach is used by Bailin [ 11,and several other scientists. The “pure” Object-Oriented approach - Use new techniques to model object structure, functionality and dynamic behavior. Each object has responsibilities, collaborators, and relationships with other objects in the system. These techniques do not require a translation process, but they need complexity management mechanisms.

3.4 Differences between structured and Object-Oriented paradigm Functional (structured) decomposition techniques are based on interpretation of the problem space and its translation to solution space as an interdependent set of functions or procedures. It is also a top-down analysis and design methodology. The biggest problem with this approach is that it does not encourage reusability. Much of the Object-Oriented programming is bottom-up and the differentiation between program design and coding is much less distinct than in procedural languages. Since one of the aims of an Object-Oriented implementation is the development of generic classes for reuse in other programs, an approach which considers both top-down analysis and bottom-up design simultaneously is likely to lead to the most robust software systems.[fi] Object-Oriented development practically inverts the previous function-oriented methodology (e.g. Yourdon or De Marco). In these methodologies, primary emphasis is placed on specifying and decomposing the system’s functionality. Such an approach might seem the most direct way of implementing a desired goal, but the resulting system can be fragile. If the requirements change, a system based on decomposed functionality may require massive restructuring [ 161. By contrast, the Object-Oriented approach focuses first on identifying objects from the application domain, then fitting procedures around them. Although this may seem more indirect, Object-Oriented software holds up better as requirements evolve, because it is based on the underlying framework of the application domain itself, rather than an ad-hoc functional requirements of a single problem. Traditional structured systems are usually created with a clearly defined boundary, that is very hard to extend. Object-Oriented systems are much more extensible and flexible. A direct analogy between objects in a ObjectOriented design and the objects in the problem domain results in systems that are easier to understand. Other advantage of the Object-Oriented approach is that it better integrates databaseswith programming code. One uniform paradigm, the object, can model both database and programming structure [ 161. 3.5 Selected approach to the analysis - CRC cards The original CRC methodology was proposed in 1989 by Beck and Cunningham [2]. It was meant to be used by programmers unfamiliar with Object-Oriented paradigm. However, while programmers and system analysts working with Object-Oriented tools are familiar with the Object-Oriented concepts, these ideas are not necessarily intuitive to SMEs with little or no software design experience. These individuals employ other, more 527


Proceedings of the 29th Annual Hawaii International Conference on SystemSciences- 1996 fundamental, object based paradigms to accurately describe real world situations.[ 1S]

Account Keeps balance and traffic.

Transaction Remote DB

Transaction

-

Validates and performs money transfer. Keeps audit info.

Card Reader Dispenser Remote DB Action Account

searching for more concise and powerful ways of saying what the object does. If it is not possible to shrink the information further, but the object is still too complex, they create a new object to assume some of the responsibilities. Working in teams helps because a concerned analyst can influence team members by suggesting scenarios aimed specifically at suspectedweaknessesor omissions. Cards can be very useful in explaining complex systems, because only a few minutes of introduction is sufficient to prepare an audience for a card based presentation. CRC cards give an SME who has never encountered objects a physical understanding of object-ness. CRC cards also give useful and convincing experience with objects to those who have learned the mechanisms of objects but do not yet see their value. Using the cards in programmer’s group settings it has been observed that even weaker programmers, without a deep understanding of objects, could contribute to object designs.

Figure 1. Sample CRC Cards - Illustration from Beck and Cunningham [2] The class name (C) of an object creates a vocabulary for discussing a design. Responsibilities (R) identify problems to be solved. A responsibility serves as a handle for discussing potential solutions. Collaborators(C) are objects to which the object sends messages in order to satisfy responsibilities. Collaboration is not necessarily a symmetric relation [2]. (Note: in some of the early papers, terms object and class were used interchangeably). An example of the use of CRC cards from the original Beck and Cunningham paper: (Card name on the top, responsibilities on the left side of the card, collaborators on the right side). Informal spatial groupings of the cards aid in comprehending a design. Parts, for example, can be arranged bellow a whole. Likewise, refinements of an abstraction can be collected and handled as a si-ogle pile of cards with the most abstract card on the top where it can represent the rest. The ability to quickly organize and spatially address index cards proves most valuable when a design is incomplete or poorly understood. Design with the cards tends to progress from knowns to unknowns, as opposed to top-down or bottom-up. The authors suggest driving a design toward completion with the aid of execution scenarios. They start iyith only one or two obvious cards and start playing “what-if’. If the situation calls for responsibility not already covered by one of the objects, SMEs add that responsibility to the existing list or create new objects to address that responsibility. If one of the objects becomes too cluttered during this process they copy the information from its card to a new card,

528


4. Extended CRC Analysis Methodology The Extended CRC Analysis Methodology is built on the foundation of the CRC methodology, with the goal to bridge the structured requirements and the Object-Oriented Analysis and Design. It is extended because it encompasses not only the Object-Oriented modeling, but also the process of pre-transition from requirements and post-transition to a commercial CASE 00 tool. 4.1 The transition from structured to Object-Oriented paradigm The data part of the existing structured requirements is usually transformable into the classes. True, not every entity f?om the IDEFlx model maps directly to a class, but some initial classes can be selected from the pool of entities, and then later regrouped, merged, divided into several classes etc. The real challenge begins when the behavior needs to be assigned to these classes. Usually, the structured requirements have some representation of the process flow, in the form of Data Flow Diagrams, IDEFO etc. The functions represented on the diagram need to be performed by the system modeled. In order to do that, the domain knowledge needs to be applied to the requirements, to help select which functions are natural responsibilities of which classesand to detect insufficiencies in the requirements. The Extended CRC Methodology enables SMEs to actively participate and help analysts solve this problem. Instead of having analysts try to decide which function belongs to which class, the valuable knowledge of the SMEs comes into play because they know exactly who performs what activity. It is extremely valuable to have SMEs

Proceedings of the 29th Annual Hawaii International Conference on SystemSciences- 1996

METHODOLOGY

IDEFlX I

Extcndcd CRC Modeling session

IDEFO

I

A0

> I

Al.1

Al -T;‘

Al .2

i

,

D

i I

;--

AZ.1

Exknded (and

CRC

tool

Figure 2. Extended CRC Process working with analysts when modeling the problem domain, while the solution domain should be in the custody of the system designers. Strong emphasis of the process and the SME’s efforts are directed towards extracting SME’s knowledge of the nature of the class’s behavior. The issue of how a behavior is performed is not relevant. This enables a more coherent link between Analysis, Design and Implementation, hence the model of the system is free of details of implementation (body of the methods).

The Extended CRC Methodology starts with the requirements that come in a structured form from the previous IDEFO and IDEFlx sessions, modeling the same system. The SMEs add their own knowledge of the system, describing what the typical uses of the system would be, and adding the parts that are potentially missing in the IDEFO and IDEFlx models. The extended CRC modeling process is iterative in nature, and it goes through discovery, description and definition phases for the classes, frequently referring to the initial sources of knowledge about the system.

4.2 The stages of the methodology The Extended CRC Analysis Methodology has several stages. The initial stages are performed by SMEs and analysts, working as a team. As the methodology approaches later stages, the role of analyst prevails and SMEs are gradually replaced by the team of analysts and designers. The significance of the first stages is the precious knowledge about the problem domain that SMEs have. They transfer their knowledge about problem domain in the form that is the most useful to Object-Oriented analysts and designers - list of classesand collaborations among them.

4.2.1 Define the scope of the system. If the requirements analysis process starts with CRC cards, and not with an IDEFO or IDEFlx model, then the scope of the system needs to be determined first. Otherwise, the preceding structured requirements sessions have already determined it. The common viewpoint also needs to be determined, if continuing from IDEF sessions, it needs to be consistent with their viewpoint. The scope and the viewpoint of the model help SMEs focus on the functions that the system needs to perform, and help analysts lead the participants In the sessionthrough the

529


Proceedings of the 29th Annual Hawaii International Conference on System Sciences- 1996

Extended CRC Meihodology

Figure 3 : Phasesof the Extended CRC Methodology process by asking questions within the boundaries of the system. 4.2.2 Identify functions the system should perform. If the IDEFO and/or IDEFlx models of the system already exist, then those models will naturally help quickly define functions of the system, or have already defined them. Otherwise, the participants need to go through this step before they start developing the cards. SMEs bring their own knowledge about the system to the session. They help find missing requirements in the structured models by developing use-case (execution) scenarios. Also, their practical knowledge of the functions that the system performs can be precious when the IDEFO model is on a very high level of abstraction and more details are needed for the extended CRC process. SMEs tend to think in terms of business functions performed, not data structures or classes. Still, the final outcome of the analysis has to be shaped in the 00 manner. It is therefore necessary to help the SMEs in the transition from their own view to the one required for the system design and implementation. The functions ought to be defined at the higher level of abstraction, such as “Manage the project budget”. Depending on the size and the scope of the project, the number of functions should be kept down at

530


a level that will enable subgroups of Sh4Es to address and model all the functions defined. Once the functions are identified, large group of SMEs should be broken down into several smaller ones. These subgroups are formed of people that are knowledgeable in the area covered by the particular function(s). The purpose of the functional decomposition is to help keep SMEs focused on the task and clearly define boundaries of the part of the system they are about to model. 4.2.3 Discover classes in the domain of the function being modeled. Once the business functions are defmed and subgroups of competent SMEs formed, the transition process begins. This critical step encompassesthe hardest task - change from Structured Analysis (SA) paradigm (Functionally oriented) to the OOA paradigm. This is where many of the projects that try to make use of both worlds fail - it is hard to map between functional and 00 analysis and come up with the sound blueprint for OOD. Instead of breaking away from one practice, developers tend to proceed with the analysis with only slightly adjusted perspective. The result is functionally oriented analysis with the 00 wrap around, in an attempt to group existing functionality to a yet non-existing classes.This reverse order of discovery and definition of classesand their functionality

Proceedings of the 29th Annual Hawaii International Conference on SystemSciences- 1996 (behavior) leads to a poorly designed classes that do not contain all the necessary attributes, and, in many cases, are vaguely or too broadly defined. Even in the case when 00 paradigm is used from the beginning, the design of classes tends to be incremental. It typically takes several iterations to come up with the right one. The transition process adds another layer of complexity and likely at least one more iteration on top of those already required. The problem is that this added iteration is performed first, when functions from SA are being assigned to classesthat are effectively created through the process of exhausting the pool of functions of the system. Hence, the design is biased and classes designed this way are always different from those that are product of pure OOA. In terms of quality, when already pressed with the limitations enforced by the search for the class that existing function belongs to, it is extremely hard to keep low coupling, high cohesion, sufficiency, completeness, and primitiveness in mind. In order to address this problem, it is suggested to break away from SA as soon as possible. Limiting functional analysis to functions at the high level of abstraction helps to design better classes. It is very important to properly teach the group how to go about creating the classes. [This stage is marked as stage 1 in the iterative Extended CRC Methodology diagram (Figure 3).] 4.2.4 Describe responsibilities (state and behavior of the classes). After defining the initial classes, the process continues by developing use-case scenarios. The responsibilities of each class are determined, and , if necessary, new responsibilities added. If a class has too many responsibilities, it is divided into several smaller classes. New classes are created if the need arises for the responsibilities that none of the existing classes can satisfy. The responsibilities can be decomposed further if they get too complex. The important thing to notice here is that this entire process is adjusted to be used by both analysts and SMEs. Therefore, the responsibilities are concise sentences in the domain language that enables SMEs to express themselves and capture the information without having to learn complex Object-Oriented constructs. At this level, it is important to capture just the description of the class’ behavior, e.g. “What’s”. Any attempt to answer “How’s” is not appropriate, hence the purpose of analysis is to understand the problem and capture that understanding in the clear, precise manner. [This stage is marked as stage 2 in the iterative Extended

CRC Methodology diagram (Figure 3).]

4.2.5 Define collaborator classes and describe the nature of collaboration. When describing a use-case scenarios, the first question to ask is what needs to be done by the system. If the starting class in the scenario has the knowledge to perform certain operation, that becomes it’s responsibility. Otherwise, it has to collaborate with other classes that posses the necessary knowledge. If the appropriate collaborator class does not exist, it is created as a new card. The classes that are identified to have the knowledge needed are listed on the card as collaborators. One of the extensions to the original CRC process that is added is the description of the collaboration. This information is known to SMEs at modeling time, and can be extremely valuable to analysts and designers in the later stagesof the modeling. The description of the collaboration contains the purpose and the nature of the service being requested. It is important to make sure that collaborator class, that either exist, or is newly created, has the service requested in it’s list of responsibilities. In order to speed up the process of checking whether all the services requested are defined as responsibilities, look-up of classes that list current class as their collaborator should be used. [This stage is marked as stage 3 in the iterative Extended CRC Methodology diagram (Figure 3).] 4.2.6 Go back to step “Discover Classes”, unless completed. This is how the cycle of the iterative approach is closed. Once the current cycle is closed, the process being modeled is revisited. Refinements and additional classescan be defined, if necessary. 4.3 The Extended CRC Tool The Extended CRC Methodology enhancesthe ability of the modeling group by providing the power of electronic group support. By supporting the semantic constraints and guidelines of the methodology the Extended CRC Tool embodies the semantic relationship between the objects and supports capture of information about those objects in a unified repository. The tool consists of the following main modules: Import module enables electronic import of the activity models in the IDEFO format, data models in the IDEFlx format and the EMS sessions in University of Arizona GroupSystems for Windows tools. This facilitates transfer of data to the Object-Oriented model. CRC card editor is used to create, edit and delete CRC cards. Once the card is created, new responsibilities and collaborators can be added, changed or removed. For every collaboration, collaboration description should be provided. When the card becomes cluttered, it can be split into two

531


Proceedings of the 29th Annual Hawaii Intern&rtional Conference on SystemSciences- 1996 requirements should have been completed in the structured modeling session, the duration of the Ye-modeling” sessions should be positively affected by that fact. The Extended CRC methodology gives the opportunity to SMEs to model their own system. Still, it would not be reasonable to expect SMEs to learn all the principles of OOAD, which can be extremely complex. Therefore, the CRC methodology is chosen as the simplest, and yet very powerful and clear way, to introduce novices to the ObjectOriented world, without introducing them to the technical terminology or complex Object-Oriented constructs. One of the very important facilitation aspects that is recommended in this project is to use the domain language and sample systems to introduce Object-Oriented paradigm to SMEs, so that they feel comfortable expressing and organizing their knowledge in the Object-Oriented form. Different additional forms of unstructured knowledge about the problem domain that never made it in the structured analysis can be added to the model as they are discovered. The SMEs will help analysts group natural formations together, point out which are the responsibilities of the same object or a class, and indicate if there is an

cards. Multiple cards can be merged into one, if necessary. Advanced options for card refinements are available. Graphical manipulation module enables placing of the cards on the desktop. This helps visualize all the cards involved in a given scenario. The cards can be laid out in any way that helps the scenario walk-through exercises. Repository manager is a shared relational database.It is being updated upon every transaction performed by participants, so that everyone has the most recent data to work with. Report generator creates textual listings of the cards or electronic export tile that can be imported to Rational Rose for Windows CASE tool. Unlike some other OOAD methodologies, the Extended CRC methodology does not throw the structured models away and then start the whole process from scratch. It is true that such an approach would maximize the “object-ness” of the model. However, it is not realistic to expect people to discard the models in which they have already invested a lot of their time and effort. The goal is to extract the knowledge from these models, maximizing the reuse of the knowledge captured. Since the discovery process in terms of system

” !-+~external identity Has numbers ,,

t_ii

Y

Sends external

identity

of subscriber

1

Disconnect dial tone Give dialong tone Mark subscriber busy I Recognize subscriber ‘Phone

Figure 4: The Extended CRC Tool (sample student session)

532


Proceedings of the 29th Annual Hawaii International Conference on SystemSciences- 1996 unnatural representation or spread of responsibilities across classes.

5. Case studies Initial experiences with groups of students using the methodology and the tool to perform 00 Analysis process for their group projects have given us a chance to learn more about the group Extended CRC process. We conducted ten sessionswith undergraduate and graduate MIS students. The sessionswere held in an electronic meeting room with 14 PC computers connected in a LAN. The software used was the Extended CRC group tool developed to support this methodology. Four sessions hosted approximately 13 students each, and others were with smaller groups, 2 to 4 students. The assignments given to the groups in the initial sessions were one page long textbook assignments, taken from Rumbaugh [ 161and Jacobson [ 131. Last four sessions were the class projects that were required for the grade in the 00 modeling class. Students were required to complete their design in the Rational Rose commercial 00 CASE tool, which was suitable, since Extended CRC tool has electronic export to Rational Rose. By facilitating these sessions, we learned about many valuable elements of group electronic modeling process in 00 paradigm. Here are some conclusions derived from the group sessions: 1. The teams need to be selected carefully. Imagination, creativity and communication skills are required. The team members should not be replaced during the sessions,or too much time will have to be spent making sure that everyone’s understanding of the system is consistent. The SMEs in the analysis team become the proponents of the model to their peers.[ 181 2. The initial training needs to be very brief and concise, but it’s role is crucial. The SMEs need to understand what all they can describe with the cards and how to do it properly. Without getting in the trap of trying to teach the SMEs Object-Oriented modeling, simple examples of systemsthat have been modeled using the cards in a stepby-step fashion work the best. If the use of a scenario narrative to guide the analytical process is planned, the scenario examples need to be shown, too. Same approach applies to potential use of the IDEF models - SMEs need to be shown how these models can be referenced in order to maximize the reuse of the knowledge. 3. Building on top of existing data models can be very advantageous and speed up the process. The sample models

that we dealt with the student groups were IDEFlx relational data models. Even though these models have relational

elements that can be redundant in the future Object-Oriented system (e.g. surrogate keys), they are an excellent starting point. When some of the cards get cluttered, SMEs split them in two, making a decision based on the semantic content of every responsibility I collaborator. Also, some of the cards that contained complementary information and did not represent something that stands naturally by itself were merged. 4. Use of the execution scenarios is very much compatible with the Extended CRC process. Several scenario narratives are needed to cover the entire problem domain. The narrative provides boundaries for the analysis effort. The scenario narratives need not be too detailed, since it’s just a starting point for more detailed discussion and definition of problem domain objects, SME actions and object connections which occur by using the card set. Depending on the size of the team, the scenarios can be discussed by the entire team or the team can be split in the smaller groups to work on different scenarios. In order to maximize parallelism of the team work every group should have all the cards available for editing with minimum delay. 5. Pure chauffeured mode is not a natural way to facilitate the team dynamics in the Extended CRC process. Namely, the facilitator becomes a bottleneck, and everyone has to wait for their turn to speak. All the power of parallel work and electronic communication is lost. Also, people are not as brave to speak up in front of others, and the communication is passive and directed only to facilitator. The best cards should be created based on the discussion of the scenarios done by the group, not the facilitator. If the physical resources are available for the group use of the tool, the pure chauffeured mode is not recommended. 6. Tbe role of facilitator/analyst is crucial. The person should be selected who will function as discussion mediator. The team leader has two primary responsibilities: keeping the analysis activities on track and insuring that both the SMEs and analysts are participating. One measure of communication is the number of questions being asked either by analysts (in the initial meeting trying to understand the semantic background of the cards), or by the SMEs (in the later analysis sessions, in reviewing story boarding concepts). 7. Experts from all business areas that participate in the model must be present in the session. In order to achieve the complete and accurate representation of the system modeled, every function of the system must be described by a knowledgeable person. Otherwise, the description of the functions may include vague, incomplete or even incorrect assumptions. 533


Proceedings of the 29th Annual Hawaii International Conference on SystemSciences- I996 1. Bailin, S. C. (1989). “An Object-Oriented Requirements Specification Method,” Communications of the ACM May 1989, ~32, n5, (pp 608-623) 2. Beck, K., Cunningham, W. (1989). A Laboratory for Teaching Object-Oriented Thinking. SIGPLAn notices, October 1989, 24( 10) 3. Boeing Computer Services. (1991). “TeamFocus Technology Evaluation Report,” October 10, 199 1. 4. Booth, G. (1994). Object-Oriented Analysis and Design with Applications, Second Edition. The Benjamin/Cummings Publishing Company, Inc. 5. Buhnan,D. (199 1). “Refining candidate objects,” Computer Language, Jan 1991 (pp 30-39) 6. Buschmann, F. (1993). “Rational architecture for object-oriented software systems,” Journal of ObjectOriented Programming, September 1993, (pp 30-41) 7. Dean, D., Orwig, R., Lee, J., Vogel, D. (1994). “Modeling with a Group Modeling Tool: Group Support, Model Quality, and Validation,” Proceedings of the 27th Annual HICSS, January 1993. 8. Dennis, A. R., George, J. F., Jessup, L. M., Nunamaker, J. F. Jr; Vogel, D. R. (1988). “Information Technology to Support Electronic Meetings,” MIS Quarterly December 1988. 9. Federal Information Processing Standards Publication 183. (1993).Spec@cation for Integration Definition for Function Modeling (IDEFO). 10. Grohowski, R., McGoff, D., Vogel D., Martz, B., Nunamaker, J. (1990). “Implementing Electronic Meeting Systems at IBM,” MIS Quarterly, December 1990. II. IDEFO Reference Manual, version 2.5 Presented by Paragon Systems. 12. IDEF - User’s group. (1994). Conference Proceedings. Richmond Virginia, May 23-26, 1994. 13. Jacobson, I. (1992). Object-Oriented Software Engineering : A use-case Driven Approach. Addison Wesley, ACM Press. 14. Monarchi, D. E., Puhr, G. I. (1992). “A Research Typology for Object-Oriented Analysis and Design,” Communications of the ACM, September 1992, ~35, n9, (pp 35-47) 15. Nunamaker, J. F., Dennis, A. R., Valacich, J. S., Vogel, D. R., George, J. F. (1991). “Electronic meeting systems to support group work,” Communications of the ACM, July 1991,34(7). 16. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W. (199 1). Object-oriented modeling and design. Prentice Hall, Englewood Cliffs. N.J.. 17. Shlaer, S., Mellor, S.J. (1988). Object-Oriented Systems Analysis: Modeling the world in Data. Prentice Hall. 18. Wangler, M. F., Hansen, P. (1992). Visuahzing Objects : Methods for Exploring Human Computer Interaction Concepts. OOPSLA ‘92, ~~146-153.

8. The cards do not substitute for more formal OOA/OOD methods. They are simply a source of inputs for the ‘identify objects’ step prevalent in today’s leading OOA/D/M methodologies. Card based analysis methods have a value as a means of facilitation our initial understanding of unfamiliar, seemingly complex problem domains. The cards enable us to create, examine and improve upon the preliminary cognitive models we use in acquiring knowledge in these environments. [ 181

6. Conclusion and further research This project has proposed a new methodology, based on the foundation of several existing methodologies and on the experience with collaborative work dynamics. However, it opens some questions at this point. The future research in this area will emphasize use of the methodology and the tool with groups and testing the group dynamics. Some of the questions that need to be answered in sessionswith groups: One of the issues that needs to be determined is how difficult it is for SMEs to accept the initial training in the process and tool. Another issue is finding the right approach to introducing the Object-Oriented paradigm only to the extent needed for the SMEs to properly participate in the session. There are several issues that deal with the import side of the process. In order to take advantage of the existing knowledge about the system, existing IDEF (or other existing) models of the system need to be imported. A question that can only be answered by practical application of the process is “what subset of the IDEFO activities from the model that need to be imported to the session, and how to determine it”. A similar question pertains to the IDEFO ICOMs. If the import data pools are not referenced frequently, what needs to be changed in the approach or facilitation procedures? The further we can refine responsibilities and collaborators with SMEs, the more we are sure that the right semantic knowledge has been captured in the system. The question is how far can we go without coming to a point of complexity where it is just not productive to have to involve the SMEs. How much is card manipulation and graphical interaction necessary in the electronic environment? Even though there is a great deal of literature that explores this issue, this particular methodology is strongly tied to the graphical interaction and this may affect the whole process. References

534


Geographic Information

Coordinators Brian E. Mennecke Martin D. Crossland


Systems