Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Extending the object-oriented enterprise modeling case tool from analysis to logical design Lu, Jingxi 2000

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_2000-0097.pdf [ 4.98MB ]
Metadata
JSON: 831-1.0099488.json
JSON-LD: 831-1.0099488-ld.json
RDF/XML (Pretty): 831-1.0099488-rdf.xml
RDF/JSON: 831-1.0099488-rdf.json
Turtle: 831-1.0099488-turtle.txt
N-Triples: 831-1.0099488-rdf-ntriples.txt
Original Record: 831-1.0099488-source.json
Full Text
831-1.0099488-fulltext.txt
Citation
831-1.0099488.ris

Full Text

EXTENDING THE OBJECT-ORIENTED ENTERPRISE M O D E L I N G C A S E TOOL F R O M A N A L Y S I S TO L O G I C A L DESIGN by JINGXI L U Ph.D., The University of British Columbia, 1997 A THESIS SUBMITTED IN PARTIAL F U L F I L L M E N T OF THE REQUIREMENTS FOR THE DEGREE OF M A S T E R OF SCIENCE IN BUSINESS ADMINISTRATION in THE F A C U L T Y OF G R A D U A T E STUDIES (Faculty of Commerce and Business Administration) We accept this thesis as conforming to the required standard THE UNIVERSITY OF BRITISH C O L U M B I A September 1999 © Jingxi Lu, 1999 In presenting this thesis in partial fulfilment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Department of Cm W tft <W B>U$iuUJ AJ^>sir^01n The University of British Columbia Vancouver, Canada Date fct? ^ , -6 (2/88) Abstract Object-Oriented Enterprise Modeling (OOEM) is a newly developed methodology for object-oriented analysis and design based on ontological theories. This study develops a new version of Computer-Aided Software Engineering (CASE) tool to support O O E M analysis, design, and redesign that aggregates information system components. The good features of previous O O E M C A S E tools have been applied to this new tool. A structured database is designed to support different modeling functionality required by analysis, design, and redesign activities. Features that are common in different modeling activities are shared, while features specific to individual modeling activities are separated. The tool implemented O O E M decomposition to which design and redesign features can be added, supported visualization of O O E M design and redesign, and automated modeling transition from design to redesign. Semantics checks are extended from analysis to design and redesign in order to ensure model integrity and consistency. An empirical study is conducted to compare this new C A S E tool with traditional pen and paper method. The tool is found to be successful in terms of system usefulness, user friendliness and modeling/design capability. The remaining problems associated with the tool and the corresponding remedies are discussed. Table of Contents Abstract i i List of Figure viii List of Tables x Acknowledgement xi 1 Introduction 1 1.1 Object-Oriented Enterprise Modeling Methodology 1 1.2 Computer-Aided Software Engineering (CASE) tool 3 1.3 Motivation and objectives 8 1.4 Thesis outline 9 2 Object-Oriented Enterprise Modeling (OOEM) 10 2.1 The O O E M fundamentals 10 2.1.1 Basic Concepts 10 2.1.2 Modeling principles 10 2.1.3 O O E M modeling constructs 11 2.1.3.1 Attributes and services 11 2.1.3.2 Objects 12 2.1.3.3 Requests 14 2.2 Building analysis model 15 2.2.1 O O E M rules 15 2.2.2 Model representation 15 iii 2.3 Decomposition 18 2.3.1 Decomposition Fundamentals 18 2.3.2 Object decomposition rules 19 2.4 Design 23 2.4.1 Delegation and delegation rules 24 2.4.2 Static object and static object rule 26 2.5 Redesign 27 2.6 Conclusion 28 3 Requirements Analysis 29 3.1 System development guideline 29 3.2 System requirements 30 3.2.1 System usefulness 31 3.2.1.1 Modeling transition 31 3.2.1.2 Vusualization 31 3.2.1.2.1 Object recognition 32 3.2.1.2.2 Request and request propagation 33 3.2.1.3 S emabtics checks and error report 3 3 3.2.1.4 Modeling and design capability 34 3.2.1.4.1 Modeling capability 34 3.2.1.4.2 Design capability 36 3.2.1.5 Model managament 37 3.3 Summary 38 iv 4 System design 40 4.1 The system 40 4.2 The database engine 42 4.3 The system generator and mode controller 43 4.4 The graphics generator 43 4.5 The object relation generator 45 4.6 The subsystems generator 49 4.6.1 Object exclusion 49 4.6.2 Request elimination 50 4.7 The perspectives generator 51 4.8 The semantics reporter 51 4.9 The document processor 52 4.10 The view controller 52 4.11 Summary 53 5 System implementation 54 5.1 Introduction 54 5.2 O O E M procedural flow 54 5.3 Database architecture 58 5.4 Algorithms 59 5.4.1 Algorithm for decomposing an object 60 5.4.2 Algorithm for identifying and linking objects needed in the redesign 64 5.5 Summary 69 v 6 Empirical Study 71 6.1 Method 71 6.2 Experiment 73 6.3 Subject Background 76 6.4 Results Analysis 76 6.4.1 System Usefulness 77 6.4.2 User friendliness 81 6.4.3 Modeling/Design capability 82 6.5 Discussion 83 7 Summary and Conclusion 86 7.1 Contributions 88 7.2 Future Research 90 7.3 Suggestions for Improvements 91 References 94 Appendix A . O O E M Rules and Metamodel 97 Appendix B. Custom Aircraft Corporation 101 Appendix C. The Northwind Case 103 vi Appendix D. Questionnaire for Empirical Study 109 Appendix E. Subject Background Questionnair 113 Appendix F. Consent Form 115 Appendix G. Post Study Interview Record 117 Appendix H . Algorithms for Graphics Generator and Semantics Reporter 118 vii List of Figure Figure 2.1 A Generic O O E M Object Communication Diagram (OCD) 16 Figure 2.2 A Generic Decomposed View 20 Figure 2.3 Types of decomposition 22 Figure 2.4 O O E M Delegation Patterns 25 Figure 4.1 Working Chart of O O E M C A S E tool 41 Figure 4.2 First Layer OCD of C A C Analysis (case 1) 44 Figure 4.3a Object Relation Generator 46 Figure 4.3b Object Relation Generator 47 Figure 4.3c Object Relation Generator 48 Figure 5.1 Simplified Flow Chart of System Implementation 55 Figure 5.2 ER Diagram for O O E M Database Design 58 Figure 5.3 Decomposition of the Financial Office of the C A C Case 63 Figure 5.4 Algorithm for identifying and linking objects needed for redesign 64 Figure 5.5 Different Dicomposition Patterns in Two Decomposed views 66 Figure 5.6 Design of Financial Office of the C A C Case 67 Figure 5.7 Design of Salesman of the C A C Case 68 Figure 5.8 Redesign of the C A C Case 69 Figure A A n O O E M metamodel 100 Figure C. 1 First Layer of North Wind 105 Figure C.2 Design of the Order Office 106 Figure C.3 Design of the Warehouse 107 viii Figure C.4 Redesign of North Wind 108 Figure H . 1 Redesign of North Wind 118 i ix List of Tables Table 2.1 A Generic O O E M Object Tempplate for Internal Object (top) and External Object (bottom) 17 Table 4.1 A Summary of System Component Changes 53 Table 6.1a Summary for questions on system usefulness 78 Table 6.1b Summary for questions on system usefulness 80 Table 6.1c Summary for questions on system usefulness 80 Table 6.2 Summary of questions on user friendliness 81 Table 6.3 Summary of questions on modeling/design capabilities 82 x Acknowledgement I sincerely thank Yair Wand and Carson Woo, my supervisors, for their guidance, encouragement, and support during my graduate studies in the Management Information Systems Division at U B C . Special thanks go to X u Zhang at ISM-BC for providing me the O O E M C A S E tool protocol from which the current study starts and to Andrew Gemino at SFU for reviewing my empirical study plan and cases. Without their help, this work could not have been done. I am grateful to all the participants in the empirical study. xi 1 INTRODUCTION 1.1 Object-oriented enterprise modeling methodology The object-oriented approach is a fast growing paradigm with its origin in the object-oriented (00) programming paradigm that is formed largely due to the needs of good programming practice. The 0 0 programming paradigm later developed towards encompassing system design and analysis, driven by the needs of building information systems. However, the analysis is mainly for specifying requirements for designing information systems. Embley et al. (1995) said, "Many so called analysis methods are really preliminary design methods.... [Many] of their features are more appropriate for design than analysis"(p.l9). Information processing is part of enterprise activities. Ideally, the information system should support optimally enterprise business activities. From this point of view, modeling enterprise systems, including both information processing and enterprise business activities is a good starting point for building information systems. The notion behind beginning with an enterprise model is that the global model (business overview) influences the enterprise model, which in turn influences the business plan, which impacts the analysis, design, and implementation of the individual software system (Yourdon 1992, p. 276). This argument is supported by the fact that information systems tend to change slowly. They also fail to meet fast changing business needs or 1 reorganization because there are no good enterprise models linking enterprise activities to their information processing. There is growing interest in enterprise modeling where the emphasis is on modeling the problem domain. Most existing object-oriented modeling methods are inappropriate for enterprise modeling for two reasons: (1) They are preliminary design methods (Embley, 1995); (2) They do not provide basic principles and rules to guide how to think about a problem domain from the perspective of an enterprise (Jung, 1997, Tan, 1997). Unified Modeling Language (UML) is a notion that has been used in enterprise modeling, system design, and software development. Its core is the unification of three modeling methodologies proposed by Booch (1993), Rumbaugh (1991),and Jacobson (1992), respectively. Booch's Object Modeling Technology is a notion of graphical symbols representing various aspects of a model. Rumbaugh's Object Management Technology is an OO system analysis and design method focusing on real-world system components. Jacobson's Object-Oriented Business Engineering Technique consists of interrelated use cases and object models. The use cases are narrative descriptions of domain processes in a structured prose format. The object models clarify the inner workings of a company's processes, products, services, resources, and their relationships. The technique can proceed to a logical design and to development of an information system model. However, U M L does not guide a developer in how to do OO analysis and design, or what development process to follow (Larman, 1998). 2 To meet the need for a sound enterprise modeling methodology, Wand and Woo (1993) initiated an object-oriented enterprise modeling methodology (OOEM) that took an ontological approach to provide the basic principles and rules for formalizing the object-oriented analysis. Zhao (1995) formed the framework for O O E M analysis in which the O O E M model representation (object communication diagram and object temperate) and the request propagation were proposed. Most 0 0 methods are geared towards design. As mentioned above, these methods do not have a good foundation for enterprise modeling. O O E M with a theoretical (ontological) foundation has lacked a method for generating an IS design. Jung has dealt with this issue by proposing a method to generate an IS design from an enterprise model (Jung, 1997). To that end, he has introduced two main concepts: object delegation (which is a special form of decomposition) and the notion of static objects. 1.2 Computer-Aided Software Engineering (CASE) tool Computer-Aided Software Engineering (CASE) tool has been widely used in 0 0 analysis and design. In this section, I briefly review some C A S E tools to show why they cannot be used to do our work, and why developing our own O O E M C A S E tool will make additional contributions to the C A S E tools literature. Some of the existing C A S E tools are actually graphic tools (Boggs, 1999). These C A S E tools only provide various graphic symbols for 0 0 modeling. Typically, they are not 3 developed based on an OO method and do not have a database to store data for further applications (e.g., design or code generation). One example of this kind of tool is the silverrun, which can be used to draw various graphics (www.silverrun.com/product). Graphic tools do not work for our purpose because they are not designed to support the 0 0 modeling from enterprise level down to system design and implementation with an underlying 0 0 method. Some other C A S E tools mainly support software development. One example is the Oracle Designer 2000. It allows users to model an existing database and then convert the model to a relational database design (www.oracle.com /tool). These C A S E tools do not serve our purpose either, because they focus on low-level system analysis and design. Rational Rose is one of the C A S E tools capable of doing OO modeling from the top down. It is an integrated object-oriented development environment encompassing 0 0 process analysis, 0 0 component analysis and design, and code generation. The new version of Rational Rose 98i has the following main features (www.rational.com /products/rose/reviews): o Business Process Modeling - Rational Rose provides an integrated approach to modeling by integrating business process modeling into its application modeling environment. With full support for the Unified Modeling Language (UML) 1.3 specification for Activity Diagrams, Rose allows analysts to model the workflow of business processes and activities and incorporate this information into the 4 application model. Developers then use the same model to derive system requirements, design the application and generate code. The ability of multiple members of a development team to work collaboratively from a single design model allows them to build higher quality software more quickly and effectively. o Data Access - This functionality, available in the Enterprise version of Rose 98i for Windows, allows Visual Basic developers to map business objects to physical database tables and automatically create runtime data components to access the database. Existing database schemas developed by a database administrator can be reused by mapping to the application code for generation of the data access layer of an application. o Parallel Development - A new integration between Rational Rose and Rational ClearCase delivers the most open and scalable solution available today for software teams to conduct parallel model development. The new integration allows developers to work in parallel on a shared model, stored in ClearCase, and has fine grain control of model changes. To support this large-scale parallel development, Rational Rose includes the Model Integrator to improve collaboration of multi-user development teams. Together with Rational ClearCase, the Model Integrator allows multiple developers to work concurrently on the same model elements, and automatically integrates changes into a common model to ensure that the entire development team is working on a consistent model. This allows development teams to truly work in parallel, removing the obstacle of one developer having to wait for other developers on the team to 5 finalize their changes. In addition to ClearCase, Rational Rose also supports Visual SourceSafe and other Source Code Control (SCC) -compliant tools. o Application Modeling - Rational Rose 98i provides tight integration with the leading Integrated Development Environments (IDEs) on Windows and UNIX platforms to provide seamless interchange between the application model and code. For Microsoft Visual Studio 6.0 developers, Rational Rose supports full markerless code generation and reverse engineering for Visual Basic 6.0 and Visual C++ 6.0, provides code generation and reverse engineering of Microsoft Foundation Classes (MFC) applications, and tight integration with the Visual J++ 6.0 environment. For UNIX developers, Rational Rose provides code generation and reverse engineering for C++, Java, Ada 83 and Ada 95. For multi-platform Java development, Rose supports JDK 1.2, 100% Pure Java, Java Bean property generation, nested classes and components such as jars, zips and cabs. In addition, Rational Rose can automatically generate Java source code and reverse engineer Java source and byte code. Rational Rose also supports C O R B A 2.2 including full round-trip engineering of IDL and support for other CORBA-specific features such as Constants, Enums, Exceptions, Interfaces, Structs, Typedefs and Unions. Although Rational Rose supports many modeling activities ranged from business process modeling to code generation, it has some weaknesses related to U M L : (1) U M L does not provide rules and principles to guide modeling (i.e., how to create use cases and object 6 models); (2) U M L does not support object decomposition. Instead, it uses different levels of use cases (i.e., high level format and expanded format) and different rankings of use cases (i.e., primary, secondary, and optional use cases) to describe domain processes. It then uses "includes" relation and "extends" relation to relate multiple use cases (Larman, 1998). However, this approach does not provide guideline on how to do so; (3) For U M L , logical design involves identifying business objects that will use an IS. In other word, the IS does not result from a separation of business activities and information processing. As opposed to U M L , O O E M design starts from a high-level enterprise model including both information processes and enterprise business activities. Decomposition plays an important role in decomposing composite objects and separating business activities from information processes that will be captured by O O E M design. These modeling activities will be guided by O O E M principles and rules. Obviously, Rational Rose does not serve our purpose. It will therefore be an important contribution i f this study can develop an OOEM C A S E tool capable of supporting O O E M design. The O O E M C A S E tool development is a continuation of two previous studies. Tan (Tan, 1997) made the first move by proposing a meta-model that allowed the O O E M rules to be programmed and implemented in a CASE tool (OOEMCT). With this meta-model, model correctness can be checked semantically by a computer. Zhang (1998) continued the effort by developing a C A S E tool (OOEM C A S E tool) that fully supported the OOEM model representation (e.g., the O O E M object communication diagram and object template) and the successful semantics check feature of OOEMCT. 7 1.3 Motivation and objectives This study is motivated by the need to develop the existing O O E M C A S E tool further down to supporting the O O E M design proposed by Jung (1997). This system has to be useful and user friendly, and can increase the efficiency and effectiveness of O O E M design of information systems. Accordingly, the objectives of this study are to build a new system on top of the O O E M CASE tool by Zhang (1998) that should be capable of doing O O E M design and ensuring integrity of the transition between analysis and design. The new system should be empirically tested to see whether it achieves the design objectives. This study will answer the following questions: (1) What are the requirements for the O O E M C A S E tool to support both O O E M analysis and design? (2) Given the requirements, how do we design and develop the system that meets the requirements? (3) What are the potential and remaining problems of putting the system in real use? 8 1.4 Thesis outline The thesis is organized as follows: Chapter 2 briefly describes the O O E M methodology with emphasis on the O O E M fundamentals, modeling principles and rules for system analysis and design. Chapter 3 studies the system requirements. Chapter 4 and 5 present the design and implementation of the system. Chapter 6 presents the results from an empirical study on the system. A summary and conclusion are given in Chapter 7. 9 2 OBJECT-ORIENTED ENTERPRISE MODELING (OOEM) Object-oriented analysis and design are essentially modeling activities. Analysis examines existing systems, and design involves prescribing or planning for future systems (Olle et al. 1991, P.2). The O O E M analysis and design are modeling activities guided by the O O E M methodology consisting of a set of fundamental principles and rules originated from ontological theories (Wand and Woo, 1993). 2.1 The OOEM fundamentals 2.1.1 Basic Concepts In OOEM, a system is defined as a group of interacting components that are performing certain tasks in response to triggers from its environment. In particular, O O E M applies to enterprise systems with regular business activities and information processing. A model is an abstract representation of a system based on a modeling method, subject to an analyst's or designer's (hereafter called "modeler") understanding of the method and the system, and subject to the modeler's modeling rationale. Analysis studies the system to explore its inner working processes triggered by its environment. Design lays out plans for information systems development based on the outcome of the analysis. 2.1.2 Modeling principles For a model to be good, the modeling method must be theoretically sound and should provide rules to guide model construction without restricting a modeler's imagination and 10 creativity. The modeling rules are necessary for the modeling activities to be consistent and reliable. An O O E M model simulates an enterprise system, possibly supported by information systems. Only relevant aspects of the system are modeled. These aspects are determined by a set of requests from outside the system. The model components therefore include both external components (business clients and suppliers) and system components (enterprise units), all of which are modeled as objects. The system's components communicate only to fulfil the tasks activated by the external stimuli (requests) sent by the external components that form the environment of the system. 2.1.3 OOEM modeling constructs 2.1.3.1 Attributes and services Ontologically, a thing has properties that are modeled by the state and state transformation laws of an object. These, in turn, are modeled by the attributes and services. The attributes determining the state, therefore, represent the properties of the thing, with the internal attributes representing its intrinsic properties and the interface attributes representing its shared (or mutual) properties. For example, in case 1, the "sales request" is an interface attribute because it can be changed directly by the Salesman object, while the "customer credit" attribute is internal to the Financial Office object because it cannot be accessed directly by the Salesman. The state transformation laws are modeled as services of the object. They are the possible actions the object can take to 11 change the internal attributes as a result of object interactions. In ontology, object interaction has its equivalence called coupling. 2.1.3.2 Object An object models a thing in the problem domain, with a changeable state determined by state variables called attributes. An object might have two types of attributes. Interface attributes are those accessible and changeable directly by other objects; internal attributes are those accessible and changeable only through the services of the object itself. A n object can change its state and respond to requests by other objects via its services. The attributes and services of the object constitute the properties of the object. Objects with the same properties, equivalent to things with the same functionality in the real world, belong to the same class. Object classes represent roles that are played in an organization. An object is a composite object i f it is an aggregate of several objects and has emergent properties, that is, properties in addition to the attributes and the services of its component objects. For example, the Financial Office in case 1 of the two business cases used in this study (Appendix B) is a composite object that has two component objects: the Financial Accountant and the Payroll Accountant. It possesses all their properties including attributes (sales requests, shipment info., etc ...) and services (process sales and complete sales) (Fig. 4.2 and Fig. 5.3) and its emergent property (not shown). One example of emergent property is the "processing power" of a computer that emerges at 12 the composite (computer) level and is not a property of any its components. It can be modeled as an attribute of the computer. This thesis does not study emergent property. Objects communicate by changing the interface attributes of each other. Changing interface attributes due to object communications is conceptualized as being made through requests. The stimuli sent from external objects into the system are called external requests. Other requests made inside the system while it responds to the external requests are called internal requests. Ontologically, a thing has properties that are modeled by the state and state transformation laws of an object. These, in turn, are modeled by the attributes and services. The attributes determining the state, therefore, represent the properties of the thing, with the internal attributes representing its intrinsic properties and the interface attributes representing its shared (or mutual) properties. For example, in case 1, the "sales request" is an interface attribute because it can be changed directly by the Salesman object, while the "customer credit" attribute is internal to the Financial Office object because it cannot be accessed directly by the Salesman. The state transformation laws are modeled as services of the object. They are the possible actions the object can take to change the internal attributes as a result of object interactions. In ontology, object interaction has its equivalence called coupling. 13 2.1.3.3 Requests Requests model the interactions among objects. A n object interacts with other objects by sending requests that cause state-changes among the objects directly and possibly through state transformations of the receiving objects. State changes of objects are events. Requests have two types: internal requests and external requests. External requests are those events that originate with external objects. Internal requests are those events that originate inside the modeled system. A request from an external object determines the relevance and the boundary of the system to the request. The request causes change in the interface attribute and, thus, state-change in the receiving object. This change can activate a service that might cause further state transformations of the object. The state transformations might need further information from other objects. This can be done via requests to other objects, which result in request propagation through the system. The boundary of the model is set by the extent of the propagation of requests. The above discussion indicates that the O O E M modeling constructs have their ontological basis. Since an enterprise model should capture information about organizational concerns, such as products and customers, ontology that provides people with concepts on how to reason about the real world can be a foundation for enterprise modeling. 14 2.2 Building analysis model The O O E M analysis provides a systematic way to reason about a problem domain. The result of an O O E M analysis is called an analysis (enterprise) model. 2.2.1 OOEM rules O O E M rules provide the core principles for using the object-oriented constructs discussed in enterprise analysis. When starting modeling, a modeler might have the following difficulties: (1) What is the scope of the system (and its environment); (2) How to identify a thing in an organization as an object of the system; (3) What is the appropriate level of detail to stop representing things as objects; (4) How to classify an object in the system; (5) what are the attributes, services, and requests associated with events triggered by the system environment. The O O E M rules guide modelers in defining modeling scope, object identification, object composition, classification, and interactions. In Appendix A , these rules are discussed. 2.2.2 Model representation With the O O E M rules, an O O E M model proposed by Zhao (1995) can be represented by an object communication diagram (OCD). This diagram contains external objects, internal objects, and requests, attributes, and services for the internal objects. Fig.2.1 is a generic object communication diagram where the external object has only a name and is 15 represented by a square box. An internal object is represented by a rounded-square box. It has a name, attributes, and services. A solid arrow represents a request that might have a "Request" and a "Response" or only a "Request". The "Request" and "Response" constitutes a request-response pair. External Object Request Internal Object v J System scope Legend NameO Request Request' Name 1 Attributes Services Request Response Name 2 Attributes Services V J Request Name 3 Attributes Services Figure 2.1 A Generic OOEM Object Communication Diagram (OCD). The Object Template (OT) provides more detailed information about an object in a table format that allows an easier semantic check concerning relationships among services, attributes, and requests by using the OOEM rules. Table 2.1 is a generic OOEM OT. In an OT, the object name is input as the header. Other key characteristics of the object are 16 input according to columns. For an internal object, the requesting object column identifies the client objects which request services from the object. The service column records the object's corresponding services invoked by the client objects. Interface attributes and internal attributes are input to reflect the state change of the object due to the requests from its clients. The access mode specifies how the attributes are accessed by the service (i.e., used or modified). The last two columns are used to record the requests spawned by the object because further information or service is required from other objects and the recipient objects that provide the information or services. Object Name Requesting Objects Services Interface Attributes Internal Attributes Request Generated Receiving Objects Object 1 service 1 incoming interface attributes Internal Attributes to support service 1 Access Mode Request generated from service 1 Object 2 Object 3 returning interface attributes Request generated from service 1 Object Name Requesting Objects Requests to system Receiving Objects request 1 Internal Object 1 request 2 Internal Object 2 Services Interface Attributes Internal Object 1 Service 1 Interface attributes of Service 1 Internal Object 2 Service 2 Interface attributes of Service 2 Table 2.1 Generic O O E M Object Templates for internal object (top) and external object (bottom). O O E M is concerned with a subset of characteristics of an external object (i.e., the requests sent by the external object and the services it provides to the system). Hence, a 17 different OT is used, that is, only requests made to a system and received from the system and the internal objects receiving the requests and the interface attributes and services of the internal object corresponding to the requests are included. 2.3 Decomposition Decomposition is fundamental for both system analysis and design. So far, no dominant methodology has emerged, though several methodologies have been proposed (Wand and Weber, 1989). In analysis, decomposition is used to break down an existing complex system into its component parts for further analysis. As discussed in next section, it is used to identify delegate objects and derive static objects in design. 2.3.1 Decomposition fundamentals In OOEM, decomposition will be done based on the following fundamentals (Wand and Weber, 1991): 1. A thing or system is viewed as: • A whole thing — an object • A composite made of other things — an object composed of other objects 18 2. A good decomposition reflects the dynamics of the system — component objects, as a whole, preserve the services of the aggregate object (e.g., no services are lost). 3. The decomposition of an information system should reflect a decomposed view of the system. 4. General principles (Wand and Weber, 1991): • A good decomposition is defined with respect to behavior under a given set of external events • A good decomposition is related to things that are "well-behaved" and "well carved out" of their environment. A well-behaved thing responds to each external event in a predictable way. A well-carved out thing has some state variables that are determined by the thing only - encapsulation of internal state. • A good decomposition is an approximation that must be evaluated with respect to a particular transformation. A decomposition might be good in the context of one transformation but poor in the context of another transformation (Wand and Weber, 1989). The same principles above are used for decomposing a system and for viewing it as separated from its environment. 2.3.2 Object decomposition rules The O O E M assumptions about the system make decomposition a process of breaking down a composite object. A system is the highest-level composite object. A composite 19 object binds its components together through requests they send to each other when the system carries out a request made to it. The composite object itself is a component object of its upper level composite object. The decomposition rules enforce the idea that for each request made to a composite object there must be at least a component object that acts as an interface to begin the initial processing of the request by providing a service. The initial object may spawn other requests to other component objects for services. Object decomposition results in the decomposition of attributes and services of the composite object. (a) Reql/Resl Req2 A B C w w Figure 2.2 A generic decomposed view where (a) shows the whole object view of object B before decomposition and (b) shows the decomposed view (inside dash box) of B after decomposition. In this case, the request-response pair (Reql/Resl) has been split in the decomposed view. 20 The decomposition rules maintain the integrity of an object when one switches from the whole object view of the object to its decomposed object view. That is, there are no requests in the whole object view that are not transferred to the decomposed object view (Fig2.2). Jung (1997) generalized four types of decomposition when breaking down an object (Fig.2.3), where (a) is the simplest decomposition that divides both the attributes and the services; (b) shows a service decomposition since the service accesses two attributes in the composite object; (c) presents an attribute decomposition since it is used by two services in the composite object; (d) depicts a decomposition of both attribute and service. If a request-response pair made to a composite object is split, such as object B in Fig. 2.2, the components ( B l and B2) will both be interface objects. A n interface object is a component object receiving a request from or sending a request to an upper level object in the decomposed view. 21 Object A Attribute 1 Attribute 2 Service 1 Service 2 (a) Basic decomposition Object A.l Attribute 1 Service 1 Object A.2 Attribute 2 Service 2 (b) Service decomposition Object B Attribute 1 Attribute 2 Service 1 Object B.l Attribute 1 Service 1.1 Object B..2 Attribute 2 Service 1.2 (c) Attribute decomposition Object C Attribute 1 Service 1 Service 2 Object C.l Attribute 1.1 Service 1 Object C.2 Attribute 1.2 Service 2 (d) Attribute and service decompositions Object D Attribute 1 Service 1 Object D.l Attribute 1.1 Service 1.1 Object D.2 Attribute 1.2 Service 1.2 Figure 2.3 Decomposition types. Arrow represents decomposition (Jung, 1997, p35). 2.4 Design OOEM design is high level logical design. The whole idea of O O E M design is based on the fact that attributes of an object can include both the state of the object and the knowledge of other objects that can be separated from the object for automation and sharing. O O E M design consists of two mechanisms: the object delegation and static object derivation. These will be discussed in the next two sections. Decomposition is an important step towards O O E M design because: (1) for the sake of simplicity it is not necessary to show all object properties in the upper layer of a model, and very often modelers do not know some properties of an object before investigating it further. Under these circumstances, delegating objects or creating static objects could result in an incomplete or incorrect design model. For example, since delegate attributes are internal and represent the state of static objects, one cannot delegate them and create static objects if they are absent at a high level; (2) Even i f you solve the problem in (1) by requiring users to identify detailed properties of high-level objects, delegating objects or creating static objects at the upper level is not a good practice because it will leave a question unanswered: what are the components of the high level delegate objects and how can one use them to design IS? (3) When an object is decomposed, one has a clearer idea of what static objects can be derived and what knowledge can be delegated from its component objects. This clarity will also ensure that the identified delegate and static objects correspond better to the detailed operations of the business. 23 As a consistent approach, O O E M OCD and OT still apply in O O E M design. The resultant model from an O O E M design is called a design (enterprise) model. It includes both organizational and information processing components. When an enterprise model is designed, a (further) design is needed to separate the business activities from the information processing parts and aggregates the information processing parts to form information system(s). This will be discussed in section 2.5. 2.4.1 Delegation and delegation rules A delegation is a role transference in which an object (delegator) transfers some roles to a delegate object. O O E M delegation is a mechanism that enables one to automate non-human components. It involves reallocating or moving attributes and their corresponding services from the delegator to the delegate object. Delegation is therefore a specific decomposition where attributes and services are delegated from human objects to non-human objects1. The O O E M modeling principles and the decomposition principles are applicable to object delegation. In particular, encapsulation (attribute custodian rule) of object states should not be violated. Jung (1997, p.39) proposed the following rules to ensure encapsulation of object states: 1. Delegation of an attribute should be accompanied by services that use the attribute. 2. Delegation of a service should be accompanied by attributes that are used by the 1 Though there is no restriction on delegators, in many situations where a system has been decomposed to certain levels of detail, a delegator is a human being. 24 service. 3. Delegation of both attributes and services that are related. O O E M delegation rules guide the transition from the enterprise model to the design model of an information system. Based on the rules, object delegation can separate organizational activities from information processing without violating O O E M rules and principles. Each delegate object in the resultant (design) model can be a candidate component for the logical design of an information system. Delegate A (b) Object A Object B w (a) Object A Object B W Object A Delegate A (c) Object B Delegate B Object A Object B Object A Object B r / T r r Delegate A Delegate B Delegate A w Delegate B W (d) (e) Figure 2.4 O O E M Delegate Patterns (Jung, 1997, p41). 25 The OCD of a design model therefore reflects degrees of automation of the design. Jung (1997) proposed four basic patterns of communication in a design model (Fig.2.4). Pattern (a) is the scenario before delegation. Patterns (b-d) reflect different degrees of automation. For example, pattern (b) presents a low level of automation. The delegate object is used to store and retrieve information; Pattern (e) shows a high level of automation where the original communication has been fully automated. Pattern (d), where a non-human delegate object makes a request of a delegator, might indicate that objects A and B cannot communicate with each other for certain reasons (For example, work in different time), they then need delegate A as a mediator in order to communicate. 2.4.2 Static object and static rule When modeling a system, certain things may possess knowledge about the state of other, non-active things. For example, an inventory clerk will know the state of inventory items. Static objects represent things that do not participate in the activities within a system. However, these are things which dynamic objects know about and might change the state of. At enterprise model level, information about these things and the action that changes their states are represented by attributes and processes of dynamic objects. In O O E M design, the information can be delegated to delegate objects. Therefore, static objects can be included to replace attributes of original or delegate objects in order to show the objects about which the system will have information. Accordingly, the actions that apply to the state of static objects (use or modification) wil l be represented by requests from the original or delegate objects to the static objects. The decision what to delegate is actually 26 a decision what will be done by the information system (as opposed to the original, organizational objects). When the delegate objects become components of an information system design, the state changes of static objects caused by an event are then reflected as information changes in the information system. Static objects possess only state and provide no services. A request might be used to highlight the manipulation of the state, though no corresponding service is attached to it. Therefore, the static objects must be shown with the objects that either read or change the state. Jung (1997, p.42) proposed the following static rule: static objects that do not undergo state changes are not modeled, since they provide no additional information. This is in accordance with the O O E M principle of minimality that requires that no redundant state variables be allowed in a model of a system. 2.5 Redesign Object delegation and static object derivation of O O E M design are mainly for reasoning about what services of individual objects can be automated. Hence this stage of design might not be involved in reasoning about designing information system for the enterprise as a whole. Consequently, objects delegated or derived based on the information of individual objects under consideration might be changed (addition/deletion) when one starts designing information systems for the whole enterprise. Redesign is part of O O E M design that allows one to design (an) information system(s) for an enterprise. In this thesis, the resulting model is called a redesign (enterprise) model. 27 Redesign is a part of O O E M design, aiding in the aggregation of all or part of the delegate objects and static objects in order to form an information system design for the enterprise or part of it. It involves organizational changes enabled by the information system(s). Some objects might be eliminated and some might be added to the enterprise because of the introduction of the information system(s). The communication patterns among objects in a design might be changed after introducing the information system(s) in a redesign. Jung (1997, p.80) demonstrated such a case. Redesign is high-level design and no specific rules for redesign activities have been formalized in O O E M . 2.6 Conclusion The O O E M analysis and design are modeling activities guided by a set of fundamental principles and rules originated from ontological theories. Built on top of an enterprise model, O O E M design that lays out plans to automate some of its components also applies the principles and rules for analysis. Whether or not to delegate objects is largely a subjective decision. Though Jung (1997) provided some good guidelines for this, they cannot be computerized. After finishing defining delegate objects and deriving static objects, one can in the redesign stage further reason about creating information system(s) based on those delegate objects in the design model. Again, the O O E M modeling principles and rules are applicable to this redesign activity. 28 3 REQUIREMENTS ANALYSIS Requirement analysis is critical for every successful system development. The requirement analysis in this chapter answers the first research question listed in section 1.1. 3.1 System development guideline The principal guideline for building the O O E M C A S E tool is building the system to be useful and user-friendly. Building a useful and user-friendly system is the most important goal of system development. "It is not our job to produce clever computer applications that reduce productivity" (Landauer 1995, p. 663). For the O O E M C A S E tool to be useful and user-friendly, four criteria are set when designing the tool: (1) The system must fully implement the O O E M model representation, the principles, and the rules for both analysis and design in an integrated fashion. Integrity means that both analysis and design use the same modeling representation and the common principles and rules. It also means that any design activities based on the analysis model should not change the analysis model, while any changes made in the analysis model must be reflected in the design model. 29 (2) Changing modeling activities from analysis to design or from design to analysis, whenever necessary, must be easy. It is important for the system to be able to change from one model to another easily because it can be expected that there exist frequent changes of modeling activities with the tool. (3) The tool should have well-designed Graphic User Interfaces (GUIs), sufficient hints for interface icons and buttons, and necessary messages guiding modeling activities. (4) The system must make modeling activities effective and efficient. System effectiveness measures how well the system helps modelers to model important facts in a problem domain. A direct measure of effective modeling is the correctness of its resulting model. Whether or not the system provides modelers with cognitive advantages in understanding, structuring, and modeling the problem domain is another measure. Cognitive advantages are subtle and hard to measure. In this study, a construct called modeling/design capability (section 6.5) is used to measure it in the empirical study. System efficiency measures the resources required to be able to model the problem domain (Wand 1993, p.2). The direct measure of system efficiency is the speed and easiness with which a modeling task is completed. 3.2 System requirements The purpose of the research project is mainly to enhance the previous system with object-oriented design capability (Zhang, 1998). The successful features found in the previous 30 tool should be inherited by the new one. Therefore, this requirement analysis focuses on finding the successful features in the previous system and the new requirements for the new tool, based on the empirical studies conducted by Zhang (1998), user feedback and the specific and common characteristics of O O E M analysis and O O E M design discussed in chapter 2. 3.2.1 System usefulness This sub-section addresses the requirements associated with system usefulness. 3.2.1.1 Modeling transition The system will support three modeling activities (analysis, design, and redesign) with commonality and difference. It wil l also support a transition mechanism that allows the modeler to switch among the three. Features common to the three modeling activities will be shared, while features specific to individual modeling activities wil l be separated. 3.2.1.2 Visualization One major success of the previous system is its full support of the O O E M Object Communication Diagram (OCD). A model can be constructed on a GUI. Visualization enables modelers to directly manipulate graphical objects on the GUI and thus reduce 31 their mental processing operations . Visualization offers them cognitive advantages during the course of extracting, processing, understanding, and responding to more relevant information of the model. The current system is therefore required to support the GUI in design and redesign. 3.2.1.2.1 Object recognition One key requirement for visualizing model construction and representation for the new tool is to find a way to distinguish two more types of objects (i.e., delegate object and static object) from others, because O O E M OCD uses only two graphics (square and rounded square) to represent external and internal objects, respectively. Object changes from one object type to another object type at any stage of model construction is also required because system environment is set by a modeler whose understanding of the problem domain and modeling interest might be different from others or might be changed over time. Options for object type change enable modelers to decide object type until they are ready. Two more options for the delegate and static objects are needed. "Mental processing operations include requirements for the user to learn complex commands and syntax, memorize encrypted codes and abbreviations, or translate data into other units or formats before they can be applied to the problem at hand" (Brown 1988, p.4). 3 The human ability to extract information from visual scenes is much more fundamental than ability to manipulate data verbally or arithmetically (Schwartz and Howell 1985). 32 3.2.1.2.2 Request and request propagation Request is another important component in O O E M OCD. As I have discussed in Chapter 2, a single arrow is used to represent a request from a requesting object to a receiving object. Request propagation reflects the business processes associated with an external request. It must be presented completely and correctly. One-direction propagation without response can show request propagation through the problem domain and business structure, but not through the full interactions between requesting and receiving objects. There is a need to represent the response from the receiving object to the requesting object clearly, because when the requested object is decomposed, the request and response can be received and sent by different component objects in its decomposed view. In this case, the response becomes a request sent to an upper level object in the decomposed view (see sections 3.2.1.4.1 and 5.4.2 for further discussion). Furthermore, since a static object does not provide service, the object from which a static object is derived may or may not be able to make a request to the static object. The tool should be able to represent static objects for both cases. 3.2.1.3 Semantics checks and error report The semantics checks introduced by Tan (Tan 1997) in his OOEMCT were successful, but with some weaknesses in reporting errors found. Zhang's study indicated that his tool has fixed these weaknesses by using a new reporter (Zhang, 1998). As discussed in Chapter 2, the O O E M rules are still in effect in O O E M logical design including redesign, 33 except for static object because it does not provide service. Therefore the new system is required to extend the new reporter designed by Zhang to the logical design. 3.2.1.4 Modeling and design capability Modeling/design capacity is an overall measure of the tool. Here, it represents several important aspects of system usefulness. 3.2.1.4.1 Modeling capability The system should be useful for idea structuring4. To achieve this, a sound GUI that fully implements O O E M Object Template (OOEM OT) is required. Zhang (1998) designed such a GUI that allows one to fill object details and establishes the relationships among all the object details according to the O O E M rules. With this GUI, it is expected that the course of completing an OT would invoke mental processes that help one to structure idea. The GUI must be modified, however, to support logical design where static objects do not have services and requests. The semantics checks can play two roles - mistake correction and next round of idea restructuring. If semantic inconsistencies appear in a model, one possibility would be that one makes mistakes in constructing the model, which would be corrected by filling additional information. Another possibility would be that the problem domain has not 4 The process of gathering information of organization activities, discovering and collecting ideas, structuring them, and finally putting them together into a 34 been analyzed correctly, which necessitates a restructuring of the entire model. Both roles are expected to provide some cognitive advantages in the modeling process. Supporting object decomposition (in particular, supporting the scenarios shown in Fig. 2.3) is fundamental for O O E M analysis. A well-decomposed system is required by the OOEM design. A n enterprise system can therefore be modeled typically in several layers of activities. The layer without decomposed objects is the first layer of the model. Every time an object is decomposed, its component objects appear in one level down; for example, in the second level and so on. The component objects along with the upper level objects (external to the components) which communicate with the component objects form a decomposed view of the object. There is one scenario that is worthwhile to mention here. O O E M uses a solid arrow to represent a request/response pair. When sending a request with a response from an object to another with the tool, there is no attribute specified by the user for the response in the requesting object. The only information stored in the database is the name of the response. However, when an object is decomposed a request and its response in the upper level can be sent to and received from different component objects in the lower level (Fig.2.2). In this case, one has to use an arrow and a "request" name to represent the upper level response. The response now must have an attribute associated with it in the receiving object because a request must change the state of the receiving object. It is inconsistent with O O E M rules because a response will always be a response no matter what it is in the upper level or in the lower comprehensible model, according to Card and Moran, is called idea structuring (Card and Moran, 1995). 35 level. One way to solve this inconsistency is to force users to use "/response" as the request name with an arrow in the lower level. This measure is anticipated to reduce confusion between the request and the response. In section 5.4.2, this issue wil l be further discussed. 3.2.1.4.2 Design capability Once business activities are fully captured and represented by an analysis model, the tool is further required to support object delegation and static object derivation. Forming delegate objects and deriving static objects are allowed only under the decomposed view because: (1) Delegate objects and static objects will be meaningful only when objects are decomposed into finer details. Users can better understand what services can be delegated for automation after further investigating individual business units (see section 2.4). (2) A system often has many objects so that it is not easy to display all of them along with their delegate objects and static objects. By displaying delegate objects and static objects in the lower level, the number of objects will be greatly reduced. When an object has no component objects, forming delegate objects and deriving static objects are still required to be completed in its decomposed vie w. It does not violate the 36 O O E M Composite Rule because delegation and static object derivation are decomposition activities in design. Since object delegation and static object derivation are allowed only in the decomposed view of a design model, the system must be able to bring them up to the first layer so that users can do their information system design. Once the component objects are brought up, the original first layer objects of the design model must be deleted, and their communications become the communications among their component objects. Deleting the first layer objects does not affect the design model because redesign starts from an independent copy of the design model. To avoid making any mistakes when completing the above tasks, the system should support both activities automatically. 3.2.1.5 Model management An enterprise model probably has tens or hundreds of objects, which causes a problem of how to display them. Though decomposition feature of the system developed mainly for dissecting complex system has played a role in alleviating this problem, there is a need to add a subsystem feature allowing one to partition a system into several subsystems. One emphasis is that no requests and responses will be lost in the subsystems so that the whole system can be recovered completely when combining the requests and responses together. This feature which has been developed in the previous system, wil l be extended to design and redesign in the new tool. 37 The tool should also allow one to suspend model construction at any stage and resume it at a later time. No information should be lost in any of these iterations. 3.3 Summary The above analysis is summarized as follows: (1) The new tool should extend the GUIs for implementing O O E M OCD and OT from analysis to design with some necessary modifications to meet the specific needs in design such as more object types, more object type changes, and handling static objects without services and requests. (2) The O O E M semantics checks for analysis should be extended through necessary modifications for static objects in design. (3) The system should support three modeling activities (analysis, design, and redesign) as well as the transition mechanism among them. Features, which are common to the three modeling activities, will be shared while features specific to individual modeling activity should be separated. (4) The new GUIs and any changes made to the GUIs adopted from the previous version should be well designed, being able to provide sufficient hints for interface icons and buttons and to provide necessary messages for modeling activities. 38 (5) This thesis work is required to give an overall assessment of the tool, especially on its efficiency, effectiveness and user-friendliness. The first three requirements are to meet the first two criteria in the guideline for system development. The fourth requirement is to meet the third criterion. The fifth requirement is to meet the fourth criterion of the system design requirement. It is my research interest to see whether the system is able to increase modeling effectiveness by providing users with cognitive knowledge in reasoning problem domain and idea-structuring through visualizing model construction and representation, semantics checking, and O O E M rules. It is also my research interest to explore whether the decomposition and modeling transition features can make modeling more efficient. 39 4 SYSTEM DESIGN This chapter introduces system design and major system components newly developed or modified from the previous version for supporting the system requirements discussed in chapter 3. 4.1 The system The system is a graphic tool supported by a database engine. Seven drivers and two controllers interact with the database and users (Fig.4.1). In Fig.4.1, the octagon represents the database and the rectangles represent the system components that can be a module or a combination of several modules. Five components of the system can access the database engine and update it as well (shown as double arrows). Some attributes of the database can be updated by the five components through data input interfaces. For example, a relationship between two objects can be established and ended using the object relation generator, which generates an object detail form for entering and changing data (Fig.4.3a). The other four components can only access the database (illustrated by single arrows). Accessing the database means that a module can input data, output data, or do both. Components that only have access to the database cannot be used to change data. For example, the mode controller is able to input and read data, while the semantic reporter can read data only. The nine components are discussed in the following sections, respectively. 40 The layer structure of the database shown in Fig.4.1 represents the three working states of the system (i.e., analysis, design, and redesign states). The mode controller controls the working state of the database. The outward arrow from the database engine highlights the direction of system state changes forced by the system. The tool requires that users first build an analysis model, then build a design model on top of the analysis model, and finally build an information system on top of the two (see section 5.2 for details). The view controller enables the system to reverse freely the modeling order and revisit any models that are built at different stages. Graphics Object Relation Generator Subsystem l/t \ j Generator N n System Generator View Controller Perspective Generator Document Processor Semantic Reporter Mode Controller Figure 4.1 Working Chart of O O E M C A S E tool 41 4.2 The database engine The database engine is modified from the previous engine to implement the layer structure shown in Fig. 4.1. This section briefly introduces the modifications. The architecture of the database and the implementation of the system are described in chapter 5. The information stored in the database can be categorized into three types: system information, object information, and graphics information. The system information includes system types and system names for different models. It is stored in a table called subsystem, which originally stores the subsystem information of an analysis model. System information plays the role of structuring the database. SystemType is a new attribute that determines the analysis, design, or redesign system functionality, while SystemID, SubsystemID, and ParentSystemID are new attributes that identify different models and their relationship (e.g., the relationship between a full system and a subsystem). The object information is stored in object, request, service, and attribute tables. The information includes names, types, and other information for all objects and their requests, services, and attributes in a model. The object and request tables are modified to include the system information for layering different models. ParentRequestID is a new attribute added into the request table for supporting decomposition and automating the transition from design to redesign (see the algorithm in section 5.4). Graphics information includes the positions and sizes of all graphics in a model. 42 The database is a relational database built with the P A R A D O X driver accompanied with Borland's Delphi. 4.3 The system generator and mode controller The system generator and mode controller are new modules designed to work together to tune the system functionality. Before building a model, one has to select a mode based on the type of the model to be built. The mode controller is an interface controlled by the mode button in Fig.4.2. It allows users to select a system type that wil l be stored in the subsystem table. The system generator is also an interface that can be activated by the NewSystem button in Fig.4.2. It allows users to enter the system name. A corresponding SystemID is generated and stored with the system name in the subsystem table at the same time. 4.4 The graphics generator The graphics generator is a GUI with a series of icons and buttons and a canvas designed to fully implement the O O E M OCD (Fig. 4.2). Each icon or button on the GUI controls a module to be activated. For example, the object icon can be activated to drag objects on the canvas. The modified generator can now construct and display models of different types. The drag-drop features for creating objects and requests are retained to make model construction easier. 43 j$ Object Oiiented Enterprise Modeling - Analysis Mode Fije £dit View Help | i l n | x | ^ ° o $ JACACAnaly:, H Mode I NewS t - I .Mew I NewSubSystem Remove Rename Warehouse Person shipment inlo. j process sales complete sales sales request Customer order process order Salesman order (customer detial & credit) Fnancial Office sales request (customer detail & credit] (customer accounts) (sales commission) shipment info. verified order" Inventory Control ""\lrtegrglcd Diagrdm/ jhajull analytical OOEM, with decomposition" tSemantical Status. % Figure 4.2 First layer OCD of C A C Analysis (case 1) With this generator, the object and graphics information created can be stored in a layer structure in the database, depending on what system mode and system name are selected by users. In the analysis stage, analysis and decomposition are supported. The decomposition algorithm is given in section 5.4.1. In the design stage, decomposition is supported and delegate objects and static objects can be created only in the decomposed view of a composite object. In the redesign stage, this generator can display the model 44 created automatically by the redesign algorithm (see the algorithm in section 5.4.2). Fig.4.2 shows the first layer OCD of the analysis model for case 1 of this study (Appendix B). 4.5 The object relation generator The object relation generator is a GUI designed to fully support the O O E M OT. Fig. 4.3a-c show the GUIs with the object details for the Salesman object of case 1 of this study (Appendix B). This GUI includes three interfaces (attribute, request, interface) that can be selected by clicking the three corresponding buttons on top of the GUI. For each interface, there are several windows that allow one to input and change information and to establish the relationship among attributes, services, and requests. The name window allows one to change the object name. Fig.4.3a is the attribute interface activated by clicking the attribute button. It is for establishing the relationships between attributes and services. From the left window and the right window, a modeler can input, edit, and delete services and attributes, respectively. A dash line separates interface attribute (order) and internal attribute (customer detail and credit). The middle windows are used to establish the relationships among the services, and attributes of a selected object. By moving attributes into the middle windows using the leftward arrows from the right window, the relationship that the service in the left window will access the attributes in the right window is established 45 Object Details Object Name j Salesman Services •] process order Edil New Attributes j Requests | interface ] Interface Attributes 1 order i Internal Attributes Delete I (customer detial & credit) Al Attributes of the Object (customer detial & credit) Edit | New | Delete | OK Apply Help Figure 4.3a Object Relation Generator in the database engine. This interface provides flexibility for modelers to move the attributes back to the right window in order to end the relationship. It is convenient when delegating attributes to another object in the design stage where one has to end some relationship. Fig.4.3b shows the request interface that is used to establish the relationships between incoming requests, invoked services and the requests generated by the invoked service to complete the service. It can be done by using the left arrows to move the requests (input 46 from the graphics generator) from the right windows to the middle windows. Flexibility is provided to end the relationship by using the right arrows to move the requests out of the middle windows. Figure 4.3b Object Relation Generator Finally, Fig.4.3c is the interface designed to establish and end the relationship between an incoming request and its interface attribute that triggers a service. The design of these GUIs requires the user to find services, attributes and requests and to establish their relationships, which is a course of ideas structuring. 47 Figure 4.3c Object Relation Generator The object relation generator is modified to function as the following. In the analysis stage, every attribute must have its corresponding request and service. In the design and the redesign stages, a warning message and an object type confirmation interface will be given to users who try to establish a object relation for an attribute without corresponding request and service. If the users confirm that this is an attribute of a static object, the object relation generator will allow users to create a specific relation for the attribute, i.e., no service is needed but a " / " must be specified as a "request". The " / " is used to represent the manipulation to the state of the static object. 48 4.6 The subsystems generator A subsystem is a system whose components are subsets of the components of another system (Wand 1996). The tool is designed to be able to divide a full (analysis, design or redesign) system into as many subsystems as wanted. The full system is the parent system of the subsystems. The generator is an interface controlled by the Newsubsystem button in Fig. 4.2. The interface is for entering the subsystem name. The corresponding SubsystemID, along with the ParentSystemID that is the SystemID of the full system are created and saved with the subsystem name in the database by the generator. Once the subsystem name is specified, the generator allows one to create the subsystem from the full system on the screen using two modules - an object exclusion module and a request elimination module. The excluded objects and eliminated requests are respectively stored in an exclusion table and a removal table so that they can be taken out from the full system whenever users want to display only the subsystem. These two modules were developed by Zhang (1998) for analysis. The new tool incorporates the subsystem generator with the mode controller for creating subsystems for all full models. 4.6.1 Object exclusion The object exclusion module excludes an internal object from a system by performing the following operations: • It changes its object type from internal to external. 49 • It removes any requests between this object and any other external objects because the external object that accepts external requests in a model violates O O E M rule #1. • It removes the external objects that only have communication with this excluded object. The purpose of this operation is to exclude an object from a subsystem or an information system so that it becomes an external object of the system. 4.6.2 Request elimination The request elimination module removes either an external or an internal request from the system. It causes the following changes: • It removes the selected request from the system. Following the request propagation, it removes those services, attributes and spawned requests that solely exist for the selected request. • It removes those objects that no longer communicate with the system after removing the request. This operation is usually done in concert with object exclusion or object deletion, for the purpose of generating a subsystem or an information system. Since O O E M Rule # 1 requires that only relevant objects be modeled, some irrelevant objects must be deleted or 50 excluded from the subsystem or the information system (Appendix A). Before deleting or excluding an object, the requests made by this object must be eliminated. 4.7 The perspective generator The perspective generator was developed by Zhang (1997). It provides another method for model construction and visualization. O O E M defines a perspective as, "The aspects of the system necessary to describe the organizational activities invoked as a consequence of the requests of one external thing (client)" (Wand and Woo 1993). The entire O O E M model (view) is the union of perspectives for a set of given clients. Different perspectives can include different objects or different properties of the same object. A view will include all objects in the contained perspectives. 4.8 The semantics reporter The semantics of OOEM, capturing the dynamic behaviors of a problem domain, are governed by the seven highly condensed modeling rules (Appendix A). A semantically consistent model is in compliance with the ontological principles governing O O E M . The semantics is built into a semantic engine based on the meta-model proposed by Tan (1997). The semantics reporter has been developed in order to check the semantics of a model and report any semantic inconsistencies with detailed information on where the 51 inconsistencies exist and the possible reasons for them so that users can isolate the mistakes that have been made. This module has been modified so that O O E M semantics is checked not only in O O E M analysis but also in O O E M design and redesign. For static objects, only three modeling violations (2, 6, and 9) are checked (Appendix H2). 4.9 The document processor The document processor is a module developed by Zhang (1998) to handle data exchange between a database system and a file system. When one chooses to stop a modeling activity for whatever reason, this module will read all the data in the database and then write it to a user-specified file in text format. When one decides to resume modeling, the module will recover the data to refill the database. The text format is used to store data in order to ensure portability. 4.10 The view controller View is a modified module controlled by the view button (Fig.4.2). It allows one to load and display different models from the database. This module finds objects based on SystemID, SubsystemID and SystemType. When a model name and a type are chosen by a user, the objects (and other information) of the model are displayed. If the model is a subsystem, view displays its parent (full) system and then "excludes" those objects not belonging to the subsystem. After displaying the model, one can continue model construction from it. Therefore, view provides a mechanism to reverse the system-forced 52 order of model construction. The previous view module can only apply to one analysis model and its subsystems. 4.11 Summary The system is designed to work around a database engine modified from the previous O O E M C A S E tool that can build only an analysis model and its subsystems each time. A layer structure is introduced into the database to support three modeling activities. A new attribute SystemType is designed to determine system functionality and model type. Three new attributes (i.e., SystemID, SubsystemID and ParentSystemID) play the role of identifying different models and their subsystems. Among the nine major components working with the database, the mode controller and system generator are new components and the graphics, object relation and subsystem generators, the view controller, and the semantic reporter are modified components. Table 1 summarizes the changes made to the components. Modules, components Change Descriptions of modifications Section Database Yes Add new attributes 4.2 Mode controller New 4.3 System generator New 4.3 Graphics generator Yes Can create delegate and static objects 4.4 Object relation generator Yes Can establish relationship for static objects 4.5 Subsystem generator Yes Apply to all models 4.6 Object exclusion Yes Apply to redesign 4.6.1 Request elimination Yes Apply to redesign 4.6.2 Semantics reporter Yes Apply to all models 4.8, H2 View Controller Yes Apply to all models 4.10 Table 4.1 A summary of system component changes 53 5 System implementation This chapter discusses the system implementation. Two algorithms for the decomposition and automation of redesign are provided. 5.1 Introduction This system is developed on Windows 95/NT platform, using Borland Delphi 3.0 and Paradox database. Delphi is an application development tool for object-oriented Pascal, providing a comprehensive set of visual interfaces and controls. Paradox is a simple yet efficient relational database driver accompanying Delphi. The features of this package make it ideal for this system development because this system mainly uses database, visual interfaces, and controls such as buttons and forms. 5.2 OOEM procedural flow Fig.5.1 is a simplified procedural chart of the system implementation. Enterprise modeling starts with a new file to distinguish it from other enterprises. When a file is chosen for the enterprise, the system disables Save, View, and Newsubsystem controls because they are not needed, while Mode and Newsystem controls are enabled. Mode and Newsystem controls are discussed in section 4.3. A n analysis mode must be chosen before choosing a new system. After analysis mode and a system name are input, both controls are disabled so that neither can change during model construction. The graphics generator and the object relation generator now have the analysis functionality (see 54 New file Disable all controls Enable mode & newsystem If Mode = Analysis & Newsystem = True then Disable view NewSys. Save Enable Close Save analysis system info. To Close Graphics Generator & Object Relation Generator Object & request deletion Object exclusion Save redesign system info If Close =True then Enable all controls / Ifl J Th y En Mode=Redesign, Newsys. =True _w| en Disable view NewSys. Save nable Close, & redesign operation ( If Newsubsystem=True Disable View, Newsys. Save / If Mode=design & Newsy. =True | Disable view NewSys. Save Enable Close, & design operation Subsystem generator Save design system info Graphics Generator & Object Relation Generator To close To close Fig. 5.1 Simplified Procedural Chart of System Implementation sections 4.4 and 4.5). When one decides to close modeling, five main choices can be made: save (model), view (system), check semantic correctness, newsubsystem, or move to system design. Save is a procedure allowing you to call the document generator to transfer your database information into a file without closing the modeling activity (i.e. after saving the model, one can continue the modeling). If there are no objects on the screen, or i f all objects on the screen are not linked to requests, the system does not create a file for the model. Otherwise, the system saves the linked objects to a file and omits the unlinked objects because they are not part of the system. View allows one to activate the view controller. The view controller works only when both system and system type are correctly selected (see section 4.10). Semantic correctness can be checked any time during the model construction. However, it is better to do so after a version of the model is completed because an incomplete model will result in many semantic errors. A new subsystem can be constructed by activating the NewSubsystem button which controls the subsystem generator. During subsystem creation, no object deletions or additions are allowed. Viewing and creating new systems are also disallowed. 56 System design can be based on a full analysis model or its subsystem(s). After selecting the design mode and giving the design system a name, the analysis model on the screen (and in computer memory) becomes independent of the analysis in the database. A ParentSystemID is used in the database to specify that the original analysis in the database has become the parent system of the design model on the screen. The design functionality of the graphics generator and object relation generator is activated. There are five options after choosing to close design: save, semantic checks, view, newsubsystem, and redesign. Save allows one to save models. For static objects, the semantic checks only check three violations (Appendix H2). The system does not prevent one from creating subsystem(s) in the design stage. View allows revisiting the analysis and its subsystems at this stage. After finishing the formation of delegate objects and derivation of static objects, one can start designing an information system based on the delegate and static objects in the Redesign stage. After selecting a Redesign mode and filling in a model name, the design model in the memory becomes independent of the model in the database. The ParentSystemID specifies that the original design model in the database has become the parent system of the model automatically generated by the redesign module. The Redesign module can automatically bring together all the low-level objects of the design model in the memory and automatically links them. The algorithm for the module is given in section 5.4.2. Object deletion, and exclusion and request elimination are allowed in the creation of an information system. 57 Legend: Ent i ty ^ R e l a t i o n ^ A ttrib u tes S y s tcm D cterm ine CED m S ub system ( 1 in i c ^ E x c l u d e ^ ^ S t a r t w ith ^ ^ p " o sit ion " " ~ ~ * ^ O b j e c t CA ttrib u te ^"""N. T y p e J P e r s p e c t i v e G en I f^ *^3 o f C o m p o n e n t ^ R e c e i v e ^ I n te r fac e 3 R e q u e s t i ^ Invoke ^ A c c e s s e d by 3 1 m S e r v i c e ) Figure 5.2 The Entity Relation Diagram for the database of O O E M C A S E Tool 5.3 Database architecture The database engine is a relational database based on the ER diagram in Fig. 5.2. The main difference between this engine and the previous one (Zhang, 1998, p.52) is that it includes the System and Mode entities and corresponding new attributes (SystemID, 58 SystemType, ParentSystemID, and SubsystemID). As described in chapter 4 and in the previous section, the system information is incorporated into object information to structure the database and layer the modeling activities. For example, the objects of an analysis model will carry an analysis system type and a name of the model. When the model is displayed, a query will find those objects with the specified system type and name. The analysis model is the parent system of a design model whose objects wil l carry a design system type and name. The objects of the design also carry a ParentSystemID which is the SystemID of the analysis. Object information (object, request, service, and attribute) includes two new object types (delegate and static) in design. Analysis cannot create delegate and static objects by using the tool. For a design or a redesign model, delegate and static objects can be created and displayed with colors only when a correct SystemType is specified through the Mode control. ParentRequestID is new object information that is added to search the request and response of an upper level request/response pair i f the pair is split in the lower level. It is an important attribute for the redesign module and for decomposing a request (see next section). 5.4 Algorithms This version of O O E M C A S E tool is built on top of the previous version. Most of algorithms have been introduced by Zhang (1998). Two major modules (the graphics generator and the semantics reporter) modified in this tool are discussed in Appendix H since they are not the main research results of this study. In this section, two algorithms, 59 the decomposition and redesign, are provided. Decomposition was originally developed by Zhang (1998) and was further completed by this study. The following section wil l also address the redesign algorithm which is the main result of this study. 5.4.1 Algorithm for decomposing an object Decomposition, controlled by clicking the object to be decomposed, is an operation that allows users to decompose the object as several component objects in its decomposed view. The essence of design of this operation is that all the objects communicating with this object in the upper level should appear, in its decomposed view, as external objects communicating with its component objects. No objects or requests from the upper level should be lost in the lower level. The attributes and the services of the object can be input manually to its individual component objects in the lower level. There are two reasons for designing the tool this way: (1) It is easier to code the tool i f the services and attributes are input into individual component objects by users; (2) If the upper level requests can be brought to a lower level as discussed below, the integrity among services, attributes, and requests will not be broken by the manual entries of the services and attributes. The algorithm includes two steps: (1) From the database, the tool looks for all the objects that communicate with the decomposed object and stores them as new objects in the database. Objects that communicate with the decomposed object are treated as external 60 objects in the decomposed view. They may change types in the lower level and so are created as new objects. The tool then looks for all the requests that the object receives and sends, and then saves the requests in an array. (2) The tool then displays the stored objects as external objects (no services and attributes) in the decomposed view with their header colored. Users can now create those component objects of the decomposed object using the graphics generator. When creating requests, the upper level requests stored in the array are provided in a request-input form for linking those external objects with those newly created component objects. Users can split the upper level request-response pairs into two separate requests by using the request-input form as well. The selected requests linking the external objects and the component objects are stored in the database as new requests. The upper level requests in the array, once used to create the new requests, will become parent requests of the new requests and wil l not appear in the request-input form. This design ensures integrity because no request can be lost or added. No attributes and services can be lost because no requests are lost. Otherwise the semantics check reporter will report errors. These features were developed by Zhang (1998). In the new tool, several features were added: (1) In the previous version, the semantics reporter checks both the external objects and the component objects in the lower level. Since the external objects have no attributes and services in the decomposed view, errors always exist for them. In the new tool, these upper level objects are identified from the database and are not checked by the semantics reporter; (2) A new attribute called ParentRequest is introduced. When the new requests linking the external objects and the 61 component objects are established, their ParentRequest IDs are set to be the IDs of the upper level requests in the database. This allows the system to find the lower level requests based on their upper level requests in the redesign module (see next section); (3) The delegate objects and static objects can be created only in the decomposed view. The decomposition algorithm manages the composite object and its component objects as follows: (1) After decomposing a selected object, it becomes a composite object and carries an Is of Composite index (true) in run time. A dash line box is added to the outside of its original box (see the Financial Office object in Fig.4.2). A l l objects in the lower level will carry an Is Component of index in the database. This index is the decomposed object's object ID. If an object is not a composite object, this index is given a special value (i.e., -1) in the database. (2) When the tool displays a model, the Is of Composite index of all composite objects will be given a value (e.g. true) in run time. Users can visit a composite object's decomposed view any time by clicking it. The filter technique provided by the Paradox driver enables the tool to filter out objects belonging to the composite object (external and component objects) from the database and display them. The filter criteria is the Is Component of index in the database. Fig. 5.3 shows the low level objects of the Financial Office object where Financial Accountant, Payroll Accountant, Warehouse Person and Salesman all hold the Financial Office's object ID as their Is Component of index. 62 (3) An aggregation control button is activated after entering a decomposed view so that users can go back to the upper level. The algorithm checks whether the current object ID is a special value (i.e., -1) so that it can determine whether or not the button should be activated. When in a decomposed view, the current object ID is the decomposed object's ID. Thus, the button is activated. ^'Object Oiiented Enterprise Modeling - Analysis Mode £ile Edit V.iew Help - n * a ll Mode | J^PwSy^em j _ Vjew | Ne^uhSy^ipm ] Rejnovgt| Rename |: Warehouse Person \ f Financial Accountant ^ \ shipment info. process sales complete sales sales request [customer detail St credit) [customer accounts) shipment info. f Payroll Accountant^ | commission notice fc commission request-*, process commission grant commission commission request | commission notice (sales commission) j "Xlntegraiedbiagram/" - , . -I fin a full analytical OOEM with decomposition j Semantical Status: „ ^ Figure 5.3 Decomposition of the Financial Office of the C A C Case (4) For those component objects in a decomposed view, users can decompose them further. However, those external objects from the upper level cannot be decomposed 63 again. For example, the Financial Accountant in Fig. 5.3 can be decomposed further, but the Salesman cannot. Salesman in the financial office view is an upper layer object. 5.4.2 Algorithm for identifying and linking objects needed in the redesign Redesign algorithm (Fig. 5.4) involves identifying composite objects and their component objects. This is because the delegate and static objects can be created only in the decomposed view of composite objects. The algorithm also involves identifying the requests made between component objects and external objects (from the upper level) in the decomposed views of the composite object found. It also involves bringing up the component objects and linking them in a new model for information system design. find all composite objects in a design model; for each composite object found do find all the requests sent from the object; end delete all objects on screen; draw all component objects for found composite objects; //including upper level objects as shown in Fig.5.5 for each request found do finds senders' and the receivers' IDs; //there are one or two senders and receivers depending on types in Fig.5.5 remember them; end if the request meets one decomposition type (b-e) make new request(s) from found senders to found receivers based on the selected request-response pair ; delete upper level objects and requests; end; Figure 5.4 Algorithm for identifying and linking objects needed for redesign 64 When an object is decomposed, a request/response pair to the original object might now be sent to or obtained by any of its components. This gives rise to four possible decomposition patterns (Fig. 5.5). Fig.5.5 shows how the component objects of object A communicate with object B in its decomposed view (left panel) and how the component objects of object B communicate with object A in its decomposed view (right panel): (a) presents the original situation where A makes a request R of B and receives a response Re from B. In their decomposed views, A and B are shown as external objects. When the component objects of A and B are created and linked by users in their decomposed views in the design model, the four possible outcomes are: (b) depicts the request-response pair (R/Re) as not being split in both decomposed views; (c) presents the situation where the request-response pair is split in both decomposed views. Type (d) and type (e) present that R/Re as being split in only one object. As long as users have specified the request (R/Re) as one of the four cases shown in Fig.5.5 in the lower level of A and B, the algorithm can automatically link the component objects in the two decomposed views and display them when the redesign module is called. When the component objects are brought together, for case (b), A l wil l make a request (R) of and receive a response (Re) from B I . For case (c), object A l wil l make a request (R) of B I , while A 2 will receive a request (Re) from B2. For case (d), A l will send R to BI but receive Re from B2. 65 a) A R/Re B w b) c) d) A l R/Re B e) A l R fcj w /Re B A2 A l R w B /Re A2 A l w B j A W j R/Re Bl R B l A w B2 /Re R B l w A /Re B2 A Bl w Figure 5.5 Different decomposition patterns in two decomposed views of object A (left panel) and object B (right panel), (a) represents A and B in upper level where R/Re is a request-response pair. A l , A2, B l and B2 are component objects. 66 Fig.5.6 and Fig.5.7 show the Salesman and Financial Office of the design model for case 1. Case 1 falls into the situation (b) discussed above because the "sales request" is not split in both the Financial Office object and the Salesman object. / * Object Oriented Enterprise Model ing - Des ign M o d e Fi'e Edt View Help - .V " - - - \ •:B & |D CAC Design ' ] Mode NeflSyslem View NewSubSys'em Rcmovo| Rename Warehouse Person request for completing sales-sales request-shipment info. Salesman Sa'es IS process sales complete sales process deposit deposit request sales request completion request (customer detail & credit) (customer accounts) commission notice commission request sales request Financial Accountant deposit request - U process sales complete sales sales request shipment info. ^jRecord-l^inelilig cheque shipment slip verified order commission notice Payioi,IS process commission request process commission notice record commission commission request commission notice JS commission Payroll Accountant process commission approval request for commission I ^ approving commission -request for commission approval-'""Vntegtated~Diagtam/7 iin. ^ M^^'^^MMjS'^^JS^ptis^ Semantical 5ta us ; / Figure 5.6 Design for the Financial Office of the C A C Case 67 u Object Oriented Enteiprise Modeling - Desiqn Mode MB File Eat View Help \ 0 s & # SI p-CAC-Design j] Mode | HewSyslem | View | Ne.sSubSys'em | Remove | Rename | Customei order ( Salesman N process order order ^ J verified order Inventory Control sales request IFjwwaj Office query detail and credit/detail %. credit r Customer IS process query customer detail & credit ~\lntegrated Diagram/" fin a full designed OOEM with delegations j Semantical Status: Figure 5.7 Design for the Salesman of the C A C Case Fig. 5.8 shows the component objects for case 1 after they are brought up from the lower level to a new model. The IS are linked to give an information system with three IS components (e.g., the Payroll system, the Sales system and the Customer system). Some objects, such as the Customer, the Inventory and Warehouse objects can be deleted from Fig.5.8 i f one wants to show only the information system and its environment. A " / " is used to represent a request for the static object (Record Cabinet). " / "indicates no request 68 and response for this object. When one needs to add a request, this " / " allows one to click on it to pop up an interface to input the request name. ^Object Oriented Enterprise Modeling - Redesign Mode File Edit View Help S V C |R-CAC Information System ^ | fS(5 dejj NewSyslem | View | NewSubSystem Remove | Rename | Customer •order- process order Salesman v_ verified order_ sales lequest order Inventory Contiol 1 .query detail and credit/detail & credit Warehouse Person shipment info. Financial Accountant ( Record Cabinet process sales complete sales sales request shipment info. h deposit request Customer IS process query process detail request customer detail & credit detail request -customer credil/credit-1 sales request customer detail/detail-commission notice-process sales (complete sales process deposit process credit lequest request for commission approval Payrolls. process commission request process commission notice record commission commission request commission notice sales commission r Sales IS deposit request sales request completion request (customer accounts] customer credit cheque shipment record verified order commission sheet U-request for completing sales commission request -approving commission-Payioll Accountant process commission approval request for commission "\lntegr"ated*Diagram/7" i In systenrrjRrCAC • Information System,. _ (Semantical Status . ; Figure 5.8 Redesign of C A C case 5.5 Summary The system is implemented around a database. The database design has enabled the whole system to complete the requirements discussed in Chapter 3 ~ the tool supports 69 three modeling activities, decomposition, modeling transition from analysis to design, automation of transition from design to redesign, and semantic checks. The mode controller and the system generator determine system functionality and modeling activities. The view controller allows one to visit any models built at different stages of modeling and modify them. The system retains the advantage of the previous version in modeling visualization and semantic integrity. Different colors are used to distinguish delegate objects, static objects, and external objects in decomposed view, from the usual internal objects and external objects. This helps modelers to visualize the modeling activities. The semantic checks for analysis are applied to decomposition, design, and redesign to ensure model correctness. The redesign feature of the system is developed in a way that a modeler need not link the lower lever objects of different composite objects manually. It is designed to ensure the integrity of transition from design to redesign of information system, to reduce the potential heavy workload for an enterprise model with many objects, and to be easy to use and user-friendly. The subsystem feature allows one to manage complex models, while the document processor is used to save models for later use. 70 6 EMPIRICAL STUDY One important step for prototyping a system is to obtain user feedback during the course of system development. A user study is very valuable in examining whether the system has met the objectives of system design. In addition, user study identifies system weaknesses for later developers to improve the system. 6.1 Method This study compared the system with the traditional pen and paper method by modeling two business cases. The relative strengths/weaknesses of each method were measured via a questionnaire (Appendix D). The previous study mainly tested the system features for OOEM analysis and graphics operations (Zhang, 1998), but this study was designed to measure the following new features developed for the new tool: (1) O O E M design (2) Decomposition (3) Modeling transition For each of these three features, a few hypotheses related to system usefulness (i.e., efficiency and effectiveness), user friendliness, and modeling/design capability were designed to test whether the system met the requirements discussed in chapter 3. This study also re-examined a few issues relating to O O E M analysis (i.e., 1-2), graphics operations (i.e., 11), and general perceptions of the tool (i.e., 7-8) because the new system included O O E M analysis and inherited the graphics operations from the previous system. 71 Besides the differences in features measured, a main difference between the two studies was that the second study could directly compare the system to pen and paper method. Comparison could provide a more accurate measurement for the above features, since testers now had a reference to justify their answers to the questionnaire. For example, when evaluating graphics operations (e.g., moving an object) the answer to Zhang's statement 6 (similar to the statement 11 of current study) might be biased because testers did not have a scale to measure how easy the operation was. By comparing with pen and paper method, now the testers could measure the relative ease of moving an object with the tool, because to move an object with the pen and paper method they had to erase the old object and draw a new one. The result from this study should therefore be more reliable. The models built with different approaches could also provide evidence to support the answers given by users. Due to limited resources available for this study, a small number of subjects were used. Consequently, this study sought important evidence about the system, not statistically significant results5. To achieve this goal, the questionnaire provided extra space for every question, allowing the subjects to make their comments, and an interview was given so that they could comment on other issues not covered in the questionnaire. Though it is anticipated that choosing small number of subjects might reduce the significance of the study, past research reveals that a pool of four to five subjects was adequate for identifying major issues (Egan, etc 1990), indicating the adquateness of this choice. 72 Subjects with similar knowledge about O O E M modeling were chosen in order to ensure internal validity. Since two cases (case 1 in Appendix B and case 2 in Appendix C) were used in the study (one for the system and the other for pen and paper method), the experiment was conducted in two groups with four subjects each. For the first group, case 1 was modeled by two participants with the tool and case 2 was modeled by the other two subjects with pen and paper. For the second group, case 1 was modeled by two subjects with pen and paper and case 2 was modeled by the other two subjects with the tool. The two groups received the same amount of training and followed the same experiment steps which will be described in the next section. This design was used to ensure external validity by minimizing the learning effect of the participants and the effect caused by the difference in case difficulty. 6.2 Experiment This experiment took about four hours and was conducted in a group of 8 M B A students who specialized in MIS and had taken a course on object-oriented enterprise modeling and other modeling methods. The questionnaire in Appendix E was emailed to these students to collect their other background information including familiarity of computer, comfort with windowing environments, and experience in using C A S E tools in conducting object-oriented analysis and design. 73 The following were the five consecutive steps for the experiment. Step One A l l subjects signed a Consent Form (Appendix F) in 1-2 minutes. Step Two The first half of this step took twenty five to thirty minutes to introduce the O O E M methodology, especially the ideas of delegate object and static object. It took another twenty five to thirty minutes to show the subjects a simple example using the tool. The tutorial introduced the graphic features provided by the system, including the creation of objects and requests and the manipulation of graphics such as resizing and moving. It emphasized how to decompose an object, change system modes among analysis, design and redesign modes, and finally do semantic checks. The purpose of this demonstration was to provide the subjects with basic understanding of the system so that they could use and evaluate the strengths and weakness of the system in the experiment. Step Three After the system demonstration, half of the 4 subjects modeled one business case (case 1 or 2 as described in last section) with the system, while the other half was asked to model the other business case with pen and paper. No question about the cases and the system 74 were answered at this stage. A description of features of the system was provided for quick reference. Paper and pen were provided for the subjects to write down whatever they wanted, which was to avoid that the subjects might forget some problems they found during the course of their modeling activities. The task was given one hour and fifteen minutes to complete. The exact time to finish the task was recorded for reference. The subjects were encouraged but not required completing the experiment. After finishing the experiment, the two groups shifted roles. Step Four After completing both cases, every subject filled the questionnaire in Appendix D about twenty minutes. Step Five A short interview was conducted for identifying more system problems beyond the questions asked and for seeking solutions to those problems from the subjects. Some general questions (Appendix G) were prepared in case that the subjects would narrow their findings to some specific areas of interest. This final step had no time limit. An incentive plan was used for the study. Every subject was paid $10 per hour as a research assistant. The testers finishing with the best solutions to the cases were given a bonus of $50 dollars each. 75 6.3 Subject Background On average, the eight subjects had 5.6 years of experience in Windows 3.1 and 2.1 years in Windows 95/NT. Every subject had more than three-year experience with windowing operation systems and at least one-year experience in Windows 95/NT. Al l subjects felt comfortable to use Windows. Six people did not think they needed assistance for using a computer and two felt neutral to the question implying that they might need some help sometimes. Every subject used graphic tools to draw graphics at least twice per year and in average six times per year. None of them had taken any course or training in systems analysis other than BAIT 506 which is course teaching OOEM and other modeling methods, neither had they worked as a systems analyst or similar role. In conclusion, the subjects had very similar background that met the need of the experiment. 6.4 Results Analysis Since one of the main purposes of this study is to test user's satisfaction with some major system features, the result analysis is grouped according to the system requirements 76 (usefulness and friendliness) listed in Chapter 3 with modeling/design capability being separated from the system usefulness. 6.4.1 System Usefulness The construct for measuring system usefulness can be divided into three parts. Part one includes questions 1-5 measuring the system efficiency and easiness. Table 6.1a summarizes the responses from the subjects to part 1 of the construct. In general, subjects agreed that the system was efficient comparing to paper and pen, especially in transforming model activities from one state to another. The system, however, had a few problems in building analysis model. The main concerns included its slowness, and inefficient graphic operations. The comments for question 1 and the post-study interviews confirmed the findings by Zhang (1998) that request layout by the system was week, that is: • The arrow bar of a request was changed to system default layout any time one move the objects sending or receiving the request. • Request line was too thin to move. • Request line could not connect to the top or bottom side of an object. • Request/Response name could not be separated into multiple lines i f it was too long. • Request/response name could not adhere to the request line. 77 • Request arrow bars were overlapped when there were more than one request. Font for request/response could not be changed Number Question Response 1 It was faster to build an enterprise model with the CASE tool than it was to build it I would with pen and paper Agree 3 Neutral 1 Disagree 4 3 It was faster to transform an enterprise model to a logical design of an information system with the CASE tool than I would with pen and paper Agree 6 Neutral 1 Disagree 1 5 It was faster to transform an enterprise model with delegate and static objects into a design of an information system with the CASE tool than I would with pen and paper Agree 7 Neutral 1 Disagree 0 2 It was easier to make changes to the enterprise model with the CASE tool than I would with pen and paper Agree 4 Neutral 0 Disagree 4 4 It was easier to make changes to a logical design of an information system with the CASE tool than I would with pen and paper Agree 4 Neutral 2 Disagree 2 Table 6.1a Summary for questions on system usefulness Since the transformations from analysis to design and then from design to redesign did not need to retype any text and re-draw the graphics, it made the modeling with the system faster than with paper and pen where everything needs to be redone. The subjects generally felt that making changes with the system was easy. Comments made on question 2 and 4 indicated that subjects disagreed to the statements because they felt that deleting a service or an attribute was not very easy after their relation had been established. It was particularly difficult to delete a request made to an object that had been decomposed. The first dissatisfaction seemed to be partially because of unfamiliarity with the system, which might be reduced when modelers become experienced. The second dissatisfaction was caused by the constraint of the O O E M rules incorporated into the system. A request appeared in different levels must be deleted from all levels i f one wants to delete it from the upper level. Though it is possible to delete it automatically from top down, so far the system does do support this operation. The following are some findings from the subjects' comments and interviews: 1. A copy feature and an undo feature are necessary for the system to be more efficient. Since text input is the heaviest work in the modeling, text copying can reduce workload. 2. When decomposing an object, retyping the services and attributes of the object in the lower level is inefficient. 3. A request text tends to be long. Putting a request and response pair together makes the text even longer. It is difficult to arrange it when a model has many objects. 4. The system should be able to automatically delete a request from upper level to lower level. Whether or not the system is easy to use for logical design is the key issue of this study. The second part of the construct seeks answers to this question (Table 6.1b). Obviously, the system is quite successful in this aspect. Among the reasons why the subjects held the positive attitude, visualization, interfaces, and object delegation have equal impacts, while the semantic check played more important role than the others did. The subjects felt that semantics check enabled them to find missing information or mistakes step by step from analysis to logical design. There were no comments on neutral attitudes toward 79 Number Question Response 6 Using the CASE tool, it was generally easy to design an information system from an enterprise model, because of Agree 7 Neutral 1 Disagree 0 6.1 visualization of business domain Agree 6 Neutral 2 Disagree 0 6.2 propagation of request Agree 3 Neutral 5 Disagree 0 6.3 semantic check Agree 7 Neutral 0 Disagree 1 6.4 Interfaces Agree 6 Neutral 2 Disagree 0 6.5 object delegation Agree 6 Neutral 2 Disagree 0 Table 6.1b Summary for questions on system usefulness request propagation. It might be because it became less impressive i f they had followed the object detail interface requirements to input information and used the semantics check to trace missing information, all of which resulted in less mistakes. Number Question Response 7 Using the CASE tool, I felt more confident in applying the object-oriented method to information system design than using pen and paper Agree 7 Neutral 1 Disagree 0 8 Using the CASE tool, I was able to build an enterprise model and design an information system of greater size and complexity than I might be able with just pen and paper Agree 7 Neutral 1 Disagree 0 Table 6.1c Summary for questions on system usefulness The last part of the construct tested the general feel about the system (Table 6.1c). After using the system, almost all subjects gained confidence from the tool either in analysis 80 and design with O O E M or in dealing with greater and more complicated problem. Note that though some subjects did not agree statement 1, but they did agree statement 8, reflecting the fact that the system is more useful for larger system. 6.4.2 User friendliness User friendliness is measured by question 9-15 (Table 6.2). The subjects generally felt that the hints and messages prompted were sufficient for them. No comments were made Number Question Response 9 The CASE tool provided sufficient hints for icons, buttons and so on that are essential to my design. Agree 4 Neutral 2 Disagree 2 10 The CASE tool provided sufficient information to correct inappropriate activities and incorrect inputs I made in design. Agree 8 Neutral 0 Disagree 0 11 The graphical operations provided by the CASE tool (e.g. resizing, moving) made my design activities generally more efficient and effective than with pen and paper. Agree 6 Neutral 0 Disagree 2 12 Using view, it was generally easy to review my modeling/design activities and to correct my mistake. Agree 6 Neutral 2 Disagree 0 13 It was generally easy to change among the three modes (analysis, design or redesign) to do modeling/design/redesign work. Agree 8 Neutral 0 Disagree 0 14 It was easy to create, specify and recognize a delegate object with the CASE tool. Agree 8 Neutral 0 Disagree 0 15 It was generally easy to create, specify and recognize a static object with the CASE tool. Agree 8 Neutral 0 Disagree 0 Table 6.2 Summary of questions on user friendliness on why the system did not provide sufficient hints for icons. Most of them agreed that the resizing and moving features provided them with greater flexibility for design. It was not a surprising outcome because information system design needed a lot of moving and resizing. With the tool, it became much easier. However, as mentioned above, some subjects felt that moving objects caused request lines and texts to either overlap or change shapes, which reduced the efficiency and effectiveness.of design. Model transitions of the system were easy, which allowed the subjects to visit different models back and forth and make modifications. Creating and specifying a delegate object or a static object were also easy. The objects colored differently from other objects made them easy to be recognized. 6.4.3 Modeling/Design capability The modeling/design capability construct included two subsets of questions. The first one (question 16) was devoted to the decomposition feature of the system because it is one of Number Question Response 16 The decomposition feature improved the CASE tool with capacity to model/design more complicated business activities, because Agree 8 Neutral 0 Disagree 0 16.1 it provided a systematic way of analyzing in-depth business activities Agree 6 Neutral 1 Disagree 1 16.2 it provided semantic check for correctness Agree 8 Neutral 0 Disagree 0 16.3 it was generally easy to go through and review different layers of business activities Agree 6 Neutral 0 Disagree 2 17 By supporting object delegation and static object derivation, the CASE tool provided a systematic way of conducting logical design of an information system. Agree 8 Neutral 0 Disagree 0 18 The CASE tool provided a systematic way of linking delegate objects to form an information system design Agree 8 Neutral 0 Disagree 0 Table 6.3 Summary of questions on modelling/design capabilities the most important functionality of the system. The second set of questions (question 17-82 18) was designed for object delegation and static object derivation, which are the core concepts of the O O E M logical design. A l l the subjects agreed that the decomposition that allowed them to analyze in-depth the businesses was successful. Semantics check helped them to find out missing inputs, especially when they were not familiar with the cases. They perceived that when a business was more complicated, this feature would play an even important role. Two subjects oppose statements 16.3 because it was slow to go back and forth in between two levels. Every subject felt that object delegation and static object derivation provided a systematic way of designing information systems. Some of them score these two questions lower scales because they felt that after delegating objects, changing the services, attributes, and requests of delegator could be time consuming. There must be a better way to deal with this problem. 6.5 Discussion To prove that the above results are meaningful, two things can be investigated: time used and the models built by the two methods. However, the resultant models might be affected by the two methods or the understanding of the O O E M methodology or even by O O E M itself. Resultant models can be assessed by completeness and correctness. Completeness means that subjects had gone through all modeling activities (analysis, 83 design and redesign) and that all the system features that were measured in the questionnaire have been used though their models are less perfect. Though correctness is a good measure, especially for evaluating how well were the resultant models built by using the system, it is difficult to do. Though testers can stop modeling at any stage of this experiment, no one stopped until time was up. For modeling with paper and pen, all subjects used about a half-hour more than the time planed. Two of them did not complete redesign. But they did reason about the information system design and highlighted the information system components in the design model. It implied that more time was required i f they were willing to or forced to redesign the information system. One subject (not in the above two subjects) used some shortcuts like "the attributes here are the same as those in the analysis model". More time was required i f complete attribute inputs were entered. Since all of them have thought and gone through the model activities, their modeling is complete and their answers were valuable. Because of time limit, the resulting paper and pen models were not neat. Some of them were hard to read. In contrast, everyone using the system could finish modeling in the designed time period. In conclusion, using the system was found to be more efficient and effective than using paper and pen method. This conclusion is consistent with the findings in section 6.4. As to correctness, two types of mistakes were found in the resultant models. One was missing information (e.g., service, attribute, or request). This happened in every model built with pen and paper. But it did not happen in the models built with the system 84 because of semantic checks. However, a missing object (e.g., Warehouse Person in case 1) was found in models built with both the system and the paper and pen methods. The request made from the Warehouse Person to the Financial Office to send the shipment slip to complete a sales request was found to be made from the Financial Office to the Warehouse Person in the models built with both methods. As mentioned above, these problems resulted from the misunderstanding of the case and O O E M and not from the tool. Correctness checks also provided evidence that the comparison method has provided more accurate and reliable results. For example, without the comparison, it was difficult to justify the reliability of the answers to the statements 6.3 and 16.2 about semantics checks. Now, since there was missing information in the models built with the pen and paper method and there were not similar errors in the models built with the tool, the favorable answers to the feature of semantics checks of the tool were reliable. No significant differences were found when comparing the resulting models started from different methods and different cases. It indicated that the learning effect was small and the effect associated with case difficulty was small for the experiment. Therefore, the results of this experiment were reliable. 85 7 Summary and Conclusion This thesis is a new effort in the direction of developing an Object-Oriented Enterprise Modeling (OOEM) methodology. The objective is to develop an enhanced O O E M C A S E tool with the capability for O O E M logical design of information systems. The new system should support O O E M design, including O O E M redesign and the transition among modeling activities (i.e., analysis, design, and redesign), without losing the merits of the previous system. The system built must be useful, user-friendly, and capable of implementing the underlying methodology. To achieve the above requirements, the system was designed based on the idea that the system features for O O E M analysis should be retained in the analysis stage. If the features for analysis are common to all modeling activities, they were shared by design and redesign. The new features specific to design and redesign were added to the system by modifying the original system modules and did not appear in the analysis. To do so, the original database engine was modified by introducing a layer structure supported by four new attributes (i.e. SystemID, SystemType, SubsystemID, and ParentSystemID). The SystemType attribute determined the different functionality of the system in different modeling stages. The ParentSystemID and SystemID attributes played the role of layering different models along the direction from analysis to design and then to redesign, while the ParentSystemID and SubsystemID attributes determined the relation between a full model and its subsystem(s). A new attribute (ParentRequestID) was used to identify 86 the upper and lower layer requests so as to automate the transition from design to redesign. Two components, the mode controller and system generator, were newly developed by this study in order to implement the layer structure of the database and the different functionality of the system. With the support of the modified database, five components (i.e., the graphics generator, the object relation generator, the subsystem generator, the semantic reporter, and the view controller) were modified from the previous system by adding new features to support O O E M design and redesign. The layer structure of the database also ensured that different modeling activities and transition between activities were implemented in an integrated fashion; no information should be lost when changing from analysis to design or vice versa; the design activity should not affect the analysis result and the redesign activity should not affect the design result. This research raised an open O O E M question, i.e., when an upper layer request/response pair was split in the lower layer; the response could become a request that demanded an interface attribute that did not exist in the upper level. This research further investigated different possible splitting of a request/response pair and developed an algorithm to automate the transition from design to redesign. A comparison study was conducted to examine the system usefulness (e.g., efficiency and effectiveness), user friendliness, and the modeling/design capability of the new system for supporting O O E M design, redesign, decomposition, and modeling transition. 87 Eight testers used this system to successfully model two business cases and compared the system with the pen and paper method. This comparison provided a direct and more accurate way to test the new system. For example, the feedback from the testers indicated that this tool was more useful for modeling big and complicated business enterprises than the pen and paper method. The resultant models from both methods also provided information to verify the findings from the tester's feedback. Through this empirical study a list of questions was compiled for future research (section 7.2). Some suggestions for improving the tool were provided in section 7.3. 7.1 Contributions This research has achieved its purpose of building an O O E M C A S E tool with the capability of doing high-level O O E M design of information systems. The new system has proven by empirical study to be useful and user friendly. It is helpful for users to gain confidence in applying O O E M analysis and design methodology to model a system with greater size and complexity. The system also provides a systematic way of analyzing in-depth business activities through decomposition, and a systematic way of doing design and redesign of information system through object delegation and derivation of static objects. The system is user-friendly because it provides hints and messages to guide users in how to use the tool and to correct errors in the course of modeling. The system increases the efficiency and effectiveness of O O E M design of information systems in several ways. Efficiency is realized by visualizing model construction and 88 problem domain, and by extending semantics checks to design; it is also achieved by easing modeling activities including graphic operations, model review and modifications, and transition between different modeling activities. A l l of these reduce the resources required for design. Effectiveness is realized by extending the semantic checks of the O O E M rules to O O E M design and redesign of information systems. With this tool, the modeling transition from design to redesign is automated, which reduces the chance of making mistakes in O O E M design of information systems. This study successfully conducted an empirical study that gave a more complete picture of the tool, which will be helpful for further development of O O E M C A S E tool either by enhancing the current tool or by redeveloping it. The successful development of the CASE tool is a move towards achieving information system development from top down. This success indicates that further effort put forth in the same direction will be promising and that the C A S E tool possesses great potential for practical use. The modified database engine presents the opportunity for new developers to further develop the tool towards implementation phase such as code generation, since it has linked three modeling activities together. 89 7.2 Future Research Though the new system is quite successful, some problems are quite obvious and are of immediate interest of research as well: 1) System slowness - it is caused by many factors, for example, • Heavy database querying to ensure referential integrity • Need to frequently repaint O O E M OCDs 2) Request layout is a graphical problem that reduces the efficiency and effectiveness of the system. Current study confirms this problem found by Zhang (1998). 3) Repeated typing for lower level attributes and services should be eliminated because this will increase efficiency and effectiveness. A n algorithm is needed to delete upper level request that has been carried to the lower level. 4) More standard features such as 'undo' and 'copy' should be developed so that greater efficiency can be achieved. 5) When a request/response pair appears at lower level of a decomposed view, a response can become a request made to an upper level object or from an upper level object to a component object (Fig. 5.5). It requires that we input an attribute that does not exist in the 90 upper level. For example, in Fig.5.5 (c), A2 needs to have an attribute for response IB which does not exist in the upper level. This is not entirely consistent. So far, a modeler needs to realize this difference, i.e., a response at upper level is stored in database but it is not an attribute. However, at the lower level, this response might become a request, which needs to have an attribute for the receiving object. There is a close linkage between the response information and the new attribute in the database. The current system cannot handle this, as it is an open question about OOEM. Further study of O O E M is needed. 6) More comprehensive empirical study is important before further development. In particular, it is important to get feedback from programmer who can provide information about how to improve the system technical point of view (e.g., system and GUI design) and about what they will need from the system for implementation such as code generation, database design and development, group work, and communication between different systems. 7.3 Suggestions for Improvements Here are some suggestions to each of the questions (1-4) in section 7.2 to improve the tool: (1) The two problems in future research question (1) (e.g., heavy querying and repainting) call for redesigning the system architecture. Though current approach that 91 all modules communicate with the database eases system coding, it sacrifices speed of the system because the I/Os needed for the modules to access data are usually much slower than other processes. Since an enterprise system needs not to take much space to store information, using memory instead of disk to store frequently used data is possible. The problem of repainting CODs can be overcome by using multiple-forms technique (i.e., several forms can be used to display several models) and concurrent processes. Techniques such as multi-threads, tree, and linked list are required to do so. Other factors causing system slowness are the recursive algorithm and semantics check. These two problems are less critical than the first two because they slow down the system less frequently. Zhang (1998) proposed to find a non-recursive algorithm for solving the first problem. If the system use the structure proposed above, these two problems can be resolved together with the first two problems because recursion can be avoided. (2) There are many possible solutions to research question (2) (that is, graphic layout); one solution is to modify the current code. Since half of the code (about 7500 lines) is devoted to graphics operations, it is worth thinking of other choice - rather than developing graphics for the system, the system can be built on top of some packages with well-developed graphics options that need little programming to use. (3) Future research question (3) (that is repeated typing) is relative easy to solve because this problem is caused by the decision on how to build the tool. Since searching for attributes and services for a composite object is easy, they can be put into object 92 detail form for decomposition. When users create a component object, they can be all input in its detailed form so that users can delete those not belonging to it. Deletion is much easier than retyping all of them. (4) If the system architecture is changed to use memory, question (4) (adding undo and copy features) may be easier to resolve. 93 References Boggs W. and Boggs M . (1999). Mastering U M L with Rational Rose. S Y B E X . Booch, G. (1993). Object-Oriented Analysis and Design with Applications (2n ed.). Redwood City, C A : Benjamin/Cummings. Brown, M . (1988). Human-Computer Interface Design Guidelines. Ablex Publishing Corporation. Card, S., Moran T. (1995). User Technology: From Pointing to Pondering. Readings in Human Computer Interaction: Toward The Year 2000. 2nd ed. Morgan Kaufman Publishers, Inc., pp. 587-602. Egan, D.E., Remde, J.R., Gomez, L . M . , Landauer, T.K., Eberhardt, J., Lochbaum, C D . (1990). Formative design-evaluation of Superbook. A C M Transactions on Information Systems 7, pp. 30-57. Embley, D.W., Jackson, R.B. and Woodfield S.N. (1995). OO Systems Analysis: Is It or Isn't it? IEEE Software, Vo l 12(4), pp. 19-32. Hall, V . J. and Mosevich, J. W. (1988). Information Systems Analysis with A n Introduction to Fourth Generation Technologies. Prentice-Hall, pp417. Jacobson, I., Christerson, M . , Jonsson, P., and Overgaar, G. (1992). Object-Oriented Software Engineering: A Use Case Driven approach. Don Mills , Ontario: Addison-Wesley. Jung, D, (1995). Object-Oriented Modeling: From Analysis to Logical Design. M.Sc. Diss. The University of British Columbia. 94 Larman, G. (1998). Applying U M L and patterns: A n introduction to object-oriented analysis and design. Prentice Hall RPT, Upper Saddle River, New Jersey. Landauer, T.K. (1995). Let's Get Real: A Position Paper on the Role of Cognitive Psychology in the Design of Humanly Useful and Usable System. Readings in Human Computer Interaction: Toward The Year 2000. (2nd ed.) Morgan Kaufman Publishers, Inc., pp. 659-665. Rumbaugh, J., Blaha, M . , Premerlini, W., Eddy, F., and Lorenson, W. (1991). Object-Oriented Modeling and Design. Englewood Cliffs: Prentice-Hall. Schwartz, D.R., Howell, W.C. (1985) Optional stopping performance under graphic and numeric CRT formatting. Human Factors, 27(4), pp433-444. Tan, W. (1997). A Rule-Based Object-Oriented C A S E Tool for Enterprise Modeling. M.Sc. Diss. The University of British Columbia. Wand, Y . and Weber, R. (1989, December). A Model of Systems Decomposition. Proceedings of the Tenth International Conference on Information Systems. Boston, Mass., pp. 41-51. Wand, Y . and Weber, R. (1991). A Unified Model of Software and Data Decomposition. Proceedings of the Twelfth International Conference on Information Systems, New York, pp. 101-110. Wand, Y . and Woo, C. (1993). Object Oriented Analysis: Is it Really that Simple. Proceedings of the Workshop on Information Technology and Systems, Orlando, Florida, pp. 186-195. Wand, Y . and Weber, R. (1995). On The Deep Structure of Information Systems. Journal of Information Systems. 5, pp. 203-223. Wand, Y . and Woo, C. (1996). Rules for Object-Oriented Enterprise Modelling. Tutorial Notes. University of British Columbia. 95 r Yourdon, E. (1992). Decline & Fall of the American Programmer. Englewood Cliffs: Yourdon Press/Prentice Hall. Zhang X . (1998). Visualization of Enterprise Modeling. Msc. Diss. The Univerisity of British Columbia. Zhao, H . (1995). Object-Oriented Enterprise Modelling. M.Sc. Diss. The University of British Columbia. 96 Appendix A. OOEM Rules and Meta-model O O E M rules are the most important semantics needed to be incorporated into the O O E M CASE tool (Wand and Woo, 1996). They become programmable with Tan's meta-model (Tan, 1997, p25). Here show the O O E M rules and the meta-model for your references (Fig. A). Rule #1: The Scope of Identification Rule This rule defines the boundary of interest in the candidate model. It emphasizes the separation of activities and events between those within the sphere of interest and influence (the enterprise) and those without (the environment). Objects outside the system are said to generate Requests to the system. The system then becomes unstable until the requests are satisfied by the evens that take place within the system. The metamodel encapsulates this rule by requiring that objects be assigned to either Internal or External (object) roles. Once assigned roles, objects are obligated to assume their common and specialized roles as defined in the metamodel. Rule #2: The Object Identification Rule This rule specifies that each object must Provide or Request a service as part of system activities to be included. It states that an object is included i f and only i f it provides at 97 least one service, or makes at least one request to the system. A n internal object is part of the system and provides at least one service. An external object is part of the environment that interacts with the system. Rule #3: The Service Inclusion Rule The rule states that a Service is included in the system i f and only i f it is directly invoked by at least one Request. This rule does not prevent a service to be invoked by multiple requests. In the metamodel, this rule is enforced by the relationship Invoke and its cardinal specification. Rule #4: The Attribute Inclusion Rule The rule determines which attributes should be included in a model. To be necessarily included, an attribute must be either used or affected by at least one service, or known to at least one other object. An internal attribute distinguishes from an interface attribute by its invisibility from outside. In the metamodel, the relationship Access and its cardinal specification ensures that Internal attributes within an objects must be accessed by at least one Service belonging to that object. 98 Rule #5: The Attribute Ownership Rule The rule determines which object is responsible for an attribute value. It states that an attribute belongs to one and only one object. This object is known as the custodian of the attribute. The value of every attribute can only be modified or obtained by the services of its custodian object. In the metamodel, a particular Attribute must be uniquely Own-ed by an object. This same object also Provides one or more Services that Access-es that attribute. Rule #6: The Composite Object Rule This rule determines when to include composites or component objects in the model. Here the term composite is used to refer to an aggregate object that can be decomposed into component objects in the problem domain. The Composite Object Rule states that a composite may only be included i f it provides services that are not provided by any of its component objects. Only the emergent properties may be included in a composite object. Rule #7: The Sub-Classification Rule 99 This rule determines when to create a general object class. This general object class (super-class) has the common services that are provided by two or more objects (sub-classes). A l l common services provided by the super-class should be eliminated from the sub-classes. Alternatively, one can form a sub-class only i f it includes new services and attributes with respect to the super-class. The Sub-Classification Rule represents the model's generalization and specialization structure. Generation/Specialization - (G/S) External Obj. Is Object -G/S-0+ Object Encapsulated by .G/SJTL G/S 0+ Generate 1+ • 0+ Sent to 1 < Request 0,1 0+ 1 I r / Interface Attr. I s is Attribute '0+ 4o,i Is of Composite • f t Internal Attr. is Attribute Invokes Spawns Offered by 1+ 0+ 0+ Accesses 1+ Provides 0,1 Figure A A n O O E M Metamodel (Tan, 1997, p25). 100 Appendix B. Custom Aircraft Corporation Case 1 for empirical study6 Adapted from Information Systems Analysis (V. J. Hall and J. W. Mosevich, p396-404, 1988). Custom Aircraft Corporation (CAC) produces aircraft-related products for a number of aircraft manufacturers. At the present time, the processing of order information involving the sales department, inventory control department, finance department and the warehouse are handled manually. The order process begins when customer places an order to the salesman, accompanying with a 25% deposit required. The C A C salesman verifies the order by referring to the customer file with customer's detail (name, address, phone number) and credit. Any changes to the customer details can be updated at this time. If the customer is creditable, a sales commission notice, two verified order slips are created. The C A C salesman makes the sale by sending the customer's deposit, the sales commission notice, and a verified order slip to the financial office, and sending the other verified order slip to the inventory control department which determines i f the order can be filled from the current stock in the warehouse or must wait for manufacturing. 6 Example solutions for this case are in Fig.4.2, Fig.5.3, and Fig.5.5-5.8. 1 0 1 Financial accountants in the financial office are responsible for recording customer's deposit, updating customer details, and charging customer accounts for the remaining 75%, by referring to a customer file with customer detail, account information, and the shipment slips delivered from the warehouse. The accountant notifies the payroll accountants when the shipment slip of the order from warehouse is received. The accountant will inform the salesman of the customer's credit earned after the 75% on account is paid. The payroll accountant updates the sales commission file after receiving the sales commission notice from the financial accountant. The commission amount due to each salesperson is finalized after verifying the file with the notice received from the financial accountant. Now C A C wants to automate its order process and you are hired first to analyze the original process and then design an information system that can automate the process so that inefficiency can be avoided. C A C has decided that it will keep its original organizational structure and your design should reflect this requirement. 102 Appendix C. The Northwind Case Case 2 for empirical study7 Adapted from Beginning Object with Visual Basic 5 (Wright, pg. 220-223, 1998). Northwind, a product distributor, distributes a catalogue of products sold by its suppliers, to its customers. NorthWind's sales are made exclusively through telephone, from its order office. Products are distributed to customers from its warehouse. To be a Northwind customer, a consumer must register with and accepted by Northwind. A customer phones a sales representative to place an order. The rep processes the order by first checking the stock sheets and the client's detail file. If products are enough and the customer has good credit, a shipment slip is then passed to the warehouse for dispatch and the stocks are marked down. The rep also sends an acknowledgment to the customer and charges on the customer's account when the shipment slip is marked and returned from the warehouse. The customer earns credit when the account is paid. A consumer contacts the rep to subscribe as Northwind's customer. The rep fills out the customer details form with provided information and open an account. The customer wil l receive a "Welcome to Northwind" letter and a catalogue of products. Customers can 7 Example solutions are given in the end of Appendix C. 103 phone Northwind to make changes to their details (name, address, phone number) any time. Upon receiving the shipment slip, the warehouse person processes the order by finding, checking the condition of, packing, shipping the physical products, and then updating the stock sheets. The shipment slip is marked and then passed to the order office. If the remaining stock hits the reorder level, an order is sent to the suppliers to fill the stock vacancy. If the condition of a product is not good, the warehouse person wil l determine the cause of it. If it is a defect, the product will be shipped back to the supplier for an exchange. 104 Fi'e Ed I View Help nm ]' ID full-design Mode |S NewSystem |, View NewSubSy.em | Remove| Rename Customer customer registration/acceptance product order/oider approvals change customer detaBs_»' process customer registration process product older change customer details Order Office change detail request (customer account) product order (stock information) (re-order level) (customer details) Customer registration request process producl Warehouse product order product exchange/product product order/shipment notice product re-order/product Supplier ~\lntegrated Diagram/-! In aJulldesigned.OOEM with dejegatiora 1 Semantical Status: 21 Figure c.l First Layer of North Wind 105 / * ' Object Oriented Enterprise Modeling - Design Mode File Edit View Help j;| D-full-design Mode NewSystem View NewSubSyslem Remove Rename -Customer^ customer registration/acceptance product orderAjrder approvals product order/levels/info/Vshipment notice/levels/info r change customer details- Rep U I process customer registration process product order change customer details customer registration product order request for detail change -customer registration/success-" charge customer account -change customer detail -Customei Sys process detail change process account charge process registration change request charge request (customer account) (customer details) registration req ~\lntegrated Diagram/" In a full designed OOEM with delegations •[Semantical Status: ^ Figure c.2 Design of the Order Office for North Wind 106 /* Object Oriented Enterprise Modeling - Design Mode File Edit VJew Help-MSI NewSystem View Ne/.'SubSys'em Remove Rename 31 product order/shipment notice process product order Order Office Warehouse peison product order -product exchange/product-- product re-order/product-(Inventory inventory , Supplier -leg for levels and info/levels & info Inventory Sys ] > j query re-order levels & stock info. levels & stock info, req (re-order levels) (stock infomation) '" I^ntegratedDiagram/ -, In a full designed OOEM with delegations Serranitcal Statu; Figure c.3 Design of the Warehouse for North Wind 107 File Edit View Help R-fullinfo H Mode NewSy.tem View NewSubSysten I Remove Rename customei registration/acceptance product order/order approvals ni change customer details Warehouse person process product order product order product re-oider/product product exchange/product req for levels and info/levels & info Supplier product orders/shipment notice Rep process customer registiation process product order change customer details | query levels&stock info/levels&stock info' customer registration/success customei registration product order request foi detail change Inventory Sys query re-order levels & stock info. levels & stock info, leq (le-oider levels] (stock infomation) ^ Customer Sys charge customer account change customer detail process detail change process account charge process registration change tequest charge request (customer account) (customer details) r^egistration req ~\lntegrated Diagram I Figure c.4 Redesign of the North Wind 108 Appendix D. Questionnaire for Empirical Study Questirmaire #2 O O E M C A S E Tool Study Fall, 1998 In the questions below, please indicate the degree to which you agree with each statement. A rating of 7 indicates that you strongly agree with each statement. A rating of 1 means that you strongly disagree with the statement. A. System Usefulness 1. It was faster to build an enterprise model with the C A S E tool than it was to build it I would with pen and paper 1 2 3 4 5 6 7 Comment 2. It was easier to make changes to the enterprise model with the C A S E tool than I would with pen and paper 1 2 3 4 5 6 7 Comment 3. It was faster to transform an enterprise model to a logical design of an information system with the C A S E tool than I would with pen and paper 1 2 3 4 5 6 7 Comment • 4. It was easier to make changes to a logical design of an information system with the C A S E tool than I would with pen and paper Comment 5. It was faster to transform an enterprise model with delegate and static objects into a design of an information system with the C A S E tool than I would with pen and paper 1 2 3 4 5 6 7 Comment 6. Using the C A S E tool, it was generally easy to design an information system from an enterprise model 109 1 2 3 4 5 6 7 because of visualization of business domain 1 2 3 4 5 6 7 Comment 6.2 propagation of request 1 2 3 4 5 6 Comment 7 6.3 semantic check 1 2 3 4 5 6 Comment 7 6.4 interfaces 1 2 3 4 5 6 Comment 7 6.5 object delegation 1 2 3 4 5 6 7 Comment 6.6 please specify and rate any other reason -1 2 3 4 5 6 Comment 7 7. Using the C A S E tool, I felt more confident in applying the object-oriented method to information system design than using pen and paper. 1 2 3 4 5 6 Comment 7 8. Using the C A S E tool, I was able to build an enterprise model and design an information system of greater size and complexity than I might be able with just pen and paper. 1 2 3 4 5 6 7 Comment 110 B. User friendliness 9. The C A S E tool provided sufficient hints for icons, buttons and so on that are essential to my design. 1 2 3 4 5 6 7 Comment_ 10. The C A S E tool provided sufficient information to correct inappropriate activities and incorrect inputs I made in design. 1 2 3 4 5 6 7 Comment 11. The graphical operations provided by the C A S E tool (e.g. resizing, moving) made my design activities generally more efficient and effective than with pen and paper. 1 2 . 3 4 5 6 7 Comment 12. Using view, it was generally easy to review my modeling/design activities and to correct my mistake. 1 2 3 4 5 6 7 Comment 13. It was generally easy to change among the three modes (analysis, design or redesign) to do modeling/design/redesign work. 1 2 3 4 5 6 7 Comment 14. It was easy to create, specify and recognize a delegate object with the C A S E tool. 1 2 3 4 5 6 7 Comment 15. It was generally easy to create, specify and recognize a static object with the C A S E tool. 1 2 3 4 5 6 7 Comment 111 C. Modeling/Design Capability 16. The decomposition feature improved the C A S E tool with capacity to model/design more complicated business activities 1 2 3 4 5 6 7 Comment because 16.1 it provided a systematic way of analyzing in-depth business activities 1 2 3 4 5 6 7 Comment 16.2 it provided semantic check for correctness 1 2 3 4 5 6 7 Comment 16.3 it was generally easy to go through and review different layers of business activities 1 2 3 4 5 6 7 Comment 16.4 please specify and rate any other reason 1 2 3 4 5 6 7 Comment 17. By supporting object delegation and static object derivation, the CASE tool provided a systematic way of conducting logical design of an information system. 1 2 3 4 5 6 7 Comment 18. The CASE tool provided a systematic way of linking delegate objects to form an information system design 1 2 3 4 5 6 7 Comment 112 Appendix E. Subject Background Questionnaire Questionnaire #1 OOEM CASE Tool Study Fall, 1998 Name: (Please Print) Please circle your choice where appropriate. Have you ever used a windowing system e.g. Apple Macintosh, Microsoft Windows? Yes / No (if No, go directly to the next question) If yes, which one(s) and for how many years? (please circle and write length of use) MS Windows 3.x yrs MS Windows 95/NT yrs Apple Macintosh yrs X-Windows yrs Other / yrs How comfortable are you with using a windowing system? Very Uncomfortable Neutral Very Comfortable 1 2 3 4 5 6 7 I always need an experienced person to assist me when I use a computer. Strongly Disagree Neutral Strongly Agree 1 2 3 4 5 6 7 Have you used graphic tools (e.g. Microsoft Office Drawing, Apple Macintosh KaleidaGraph) to draw graphics? Yes / No (if No, go directly to the next question) If yes, for how often? (times/per yr) 113 Have you taken any course or training in systems analysis or related areas other than BAIT 506? Yes / No (if No, go directly to the next question) If yes, at what level (Undergraduate/Graduate/Professional/Other) ? How long was the course/training (months)? Did you use C A S E tools in the course/training? Yes / No (if No, go directly to the next question) If yes, please specify Have you ever worked as a systems analyst or similar role? Yes / No If yes, for how many years? yrs Did you use C A S E tools in your work? Yes / No If yes, please specify 114 Appendix F. Consent Form O O E M C A S E Tool Study Fall 1998 Thank you for participating in this study. We are seeking your help in evaluating O O E M C A S E Tool, an Enhanced Version of the Object-Oriented Enterprise Modeling Computer-Aided Software Engineering Tool developed in the Management Information Systems Division at U B C . O O E M C A S E tool is aimed at helping analysts to build enterprise models of target organizations and helping analyst/designers to automate part of the systems in a systematic and semantically consistent way. Your contribution lies in your participation in testing the system and providing your feedback that we collect for empirical study. The course of this study might be videotaped entirely or partially. Videotaping is solely for review purpose and wil l not be used for any other purposes without your prior consent in writing. The result of this study may play an important role in subsequent changes or improvements to the system. Please keep in mind that this study is to assess the system, not you. In fact, result of this study will be aggregated and your responses cannot be traced back to you. So we would appreciate your frank opinion. 115 Once the session is over, you are requested not to discuss the study with your friends and classmates. The estimated time for this study is four hours. Participation in this study is completely voluntary and you may discontinue your participation at any time during the session. Participant Acknowledgement I have read and understood the contents of above terms and conditions and agree to participate in the study. Name (Please Print) Signature Date 116 Appendix G . Post Study Interview Record O O E M C A S E Tool Study Fall 1998 Name: (Please Print) How do you feel about this modeling tool compared to other C A S E tools/graphic drawing tool that you can do system analysis and design? What are the strengths of this system? What are the weaknesses of this system? What are the specific areas that need to be improved immediately? Please include here any other comments that you want to make. Appendix H. Algorithms for graphics generator and semantics reporter HI. Algorithm for graphics generator The graphics generator developed mainly by Zhang (1998) and modified by this study, allows a modeler to build an OCD or display a model. It also provides a set of operations such as insertion, modification and deletion of model constructs. Figure HI is the pseudo-code for the graphics generator. The code has omitted some operations like insertion etc. The algorithm is executed when modeling starts or a view is called. After that, one can work directly on the GUI through operations such as moving the position of an existing object, adding new objects, or changing the name of an existing request, etc. These changes will be saved to the database before the model is closed. if view is selected then if mode is correctly selected then select all objects belong to a model from database; draw and link them end end if object button is selected then pop up object input interface with different type options depending on mode; input object type and name and save them to database; draw it with a default size; end if request button is selected then pop up a request interface for inputting request and response names and for specifying the sending and the receiving object names; draw a arrow from the sending object to the receiving object and display the request and response name; save the request name, response name, object names, position and lines; end Figure HI. Algorithm for graphics generator 118 H2. Algorithm for semantic check The semantics check reporter, based on the meta-model by Tan (1997), examines ten modeling errors violating four of the OOEM rules. Each of the errors is checked by querying the database with one SQL query and is reported through the semantic reporter as one of the ten errors listed below. The OOEM rule that each error violates is included in the parentheses for reference. These ten modeling errors have been applied to decomposition, design, and redesign in the new tool. 1. The request sent to an internal object does not invoke any service. (Rule #1) 2. The request sent to an internal object modifies no interface attribute. (Rule #1) 3. The request from an external object is sent to another external object. (Rule #1) 4. The request from an internal object is not spawned by any service. (Rule #1) 5. The service spawns the same request more than once. (Rule #1) 6. This object has no communication with any other object. (Rule #2) 7. The service is not invoked by any request. (Rule #3) 8. The interface attribute is not accessed by any service. (Rule #4) 9. The interface attribute is not modified by any request. (Rule #4) 10. The internal attribute is not accessed by any service. (Rule #4) The algorithm identifies which object should be checked and then check them for some or all of the ten errors. For static object, only 2, 6, and 9 are checked. There must be an 119 owner object for every error message whose nametag will be painted red if any of the checks are not passed. Semantic report is available for every problematic object. The Attribute Ownership Rule (Rule #5) is enforced by the database design. Since Rules #6 and #7 deal with the structure aspect of a model, they are not checked by the system. 120 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0099488/manifest

Comment

Related Items