Experience on Developing an Information System
Using CASE Tools
Anne M. Welch, James W. Hong and Michael A. Bauer
Department of Computer Science
University of Western Ontario
London, Ontario, Canada
fwelch,jwkhong,bauer@csd.uwo.cag
June 10, 1994
Abstract
Computer Aided Software Engineering (CASE) tools were introduced commercially in the
early 1980's for assisting developers in the design and development of information systems.
Although most CASE tools' capabilities have improved considerably since then, they are still not
meeting the expectations that were initially anticipated. In this report, we provide an overview
of the project which involved the development of an information system using an integrated
CASE tool, namely the Information Engineering Facility (IEF) by Texas Instruments. We
present a brief overview of the information system that was developed. We also present a brief
overview of the IEF CASE tool and our evaluation of the specic pros and cons of the tool. Our
overall experience as well as the lessons learned on the project are also discussed.
This research work is supported by the Supply Services Canada and the Natural Sciences and Engineering
Research Council of Canada
Contents
1 Introduction
2 Project Overview
2.1
2.2
2.3
2.4
2.5
2.6
Information Strategy Planning : : : :
Business Area Analysis : : : : : : : : :
Business System and Technical Design
Construction and Testing : : : : : : :
Methodology : : : : : : : : : : : : : :
Evaluation Factors : : : : : : : : : : :
7
8
: : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : :
3 Overview of the Information System
3.1 Objective : : : : : :
3.2 Rationale : : : : : :
3.3 Information System
11
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
4 Overview of the IEF CASE tool
4.1
4.2
4.3
4.4
IEF Planning Toolset : :
IEF Analysis Toolset : : :
IEF Design Toolset : : : :
IEF Construction Toolset
12
12
12
13
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
5 Development of the Information System
5.1 Information Strategy Planning (ISP) : : : : :
5.1.1 IEF Planning Toolset Summary : : : :
5.1.2 IEF Planning Toolset Deliverables : :
5.2 Business Area Analysis (BAA) : : : : : : : :
5.2.1 IEF Analysis Toolset Summary : : : :
5.2.2 IEF Analysis Toolset Deliverables : :
5.3 Business System and Technical Design (BSD)
5.3.1 IEF Design Toolset Summary : : : : :
5.3.2 IEF Design Toolset Deliverables : : :
5.4 Construction and Testing : : : : : : : : : : :
5.4.1 IEF Construction Toolset Summary :
5.4.2 IEF Construction Toolset Deliverables
8
9
9
9
9
9
13
14
14
15
15
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : :
6 Experience
6.1 Summary of Good Features of the IEF Toolsets :
6.2 Summary of Poor Features of the IEF Toolsets :
6.3 Summary of Inconsistencies in the IEF Toolsets :
16
16
18
24
24
26
28
30
30
31
32
32
32
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
33
34
35
7 Project Summary
7.1 Goals : : : : : : : : : : : : : : : : : : : : :
7.1.1 Case Study : : : : : : : : : : : : : :
7.1.2 CASE Tool Review : : : : : : : : : :
7.2 Evaluation Factors : : : : : : : : : : : : : :
7.2.1 Diagramming Capabilities : : : : : :
7.2.2 Software Engineering Methodologies
7.2.3 Consistency Checking : : : : : : : :
7.2.4 Toolset Integration : : : : : : : : : :
7.2.5 Documentation : : : : : : : : : : : :
7.2.6 Database Generation : : : : : : : : :
7.2.7 Code Construction : : : : : : : : : :
7.2.8 Reengineering Support : : : : : : : :
7.2.9 Availability of Metrics : : : : : : : :
35
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : :
8 Conclusions and Future Work
8.1 Conclusions :
8.2 Future Work
38
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
A Distributed Project Management Information System
A.1 Introduction : : : : : : : : : : : : : : : : : : : : : : : : :
A.1.1 Objective : : : : : : : : : : : : : : : : : : : : : :
A.1.2 Information System : : : : : : : : : : : : : : : :
A.1.3 Rationale : : : : : : : : : : : : : : : : : : : : : :
A.2 Denition of Information System : : : : : : : : : : : : :
A.2.1 Update/Create Tool (Information Maintenance)
A.2.2 Retrieval/Browse Tool : : : : : : : : : : : : : : :
A.2.3 Entities, Attributes and Relationships : : : : : :
36
36
36
36
36
36
36
37
37
37
37
38
38
38
39
42
: : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : :
B IEF-Generated Entity Type Denition Report
C A Sample IEF-Generated C Code
D Evaluation of the IEF Toolsets
D.1 The IEF Planning Toolset : : : : : : : : : : : : : : : : : : : :
D.1.1 IEF Organizational Hierarchy Diagram (OHD) : : : :
D.1.2 IEF Data Model: Entity Relationship Diagram (ERD)
D.1.3 Activity Hierarchy Diagram (AHD) : : : : : : : : : :
D.1.4 Activity Dependency Diagram (ADD) : : : : : : : : :
D.1.5 Matrix Processor : : : : : : : : : : : : : : : : : : : : :
D.1.6 Summary : : : : : : : : : : : : : : : : : : : : : : : : :
D.2 The IEF Analysis Toolset : : : : : : : : : : : : : : : : : : : :
D.2.1 Data Model: Entity Relationship Diagram (ERD) : :
D.2.2 Data Model List (DML) : : : : : : : : : : : : : : : : :
42
42
42
42
43
43
44
45
52
59
66
: : : : : : : : : : : : :
: : : : : : : : : : : : :
: : : : : : : : : : : : :
: : : : : : : : : : : : :
: : : : : : : : : : : : :
: : : : : : : : : : : : :
: : : : : : : : : : : : :
: : : : : : : : : : : : :
: : : : : : : : : : : : :
: : : : : : : : : : : : :
66
66
68
70
71
72
73
73
74
74
D.2.3 Activity Hierarchy Diagram (AHD) : : : : : : : :
D.2.4 Activity Dependency Diagram (ADD) : : : : : : :
D.2.5 Action Diagram - Process Action Diagram (PAD)
D.2.6 Action Block Usage : : : : : : : : : : : : : : : : :
D.2.7 Matrices : : : : : : : : : : : : : : : : : : : : : : : :
D.2.8 Business System Denition : : : : : : : : : : : : :
D.2.9 Summary : : : : : : : : : : : : : : : : : : : : : : :
D.3 The IEF Design Toolset : : : : : : : : : : : : : : : : : : :
D.3.1 Business System Defaults : : : : : : : : : : : : : :
D.3.2 Dialog Design : : : : : : : : : : : : : : : : : : : : :
D.3.3 Screen Design : : : : : : : : : : : : : : : : : : : : :
D.3.4 Action Diagram : : : : : : : : : : : : : : : : : : :
D.3.5 Work Set List : : : : : : : : : : : : : : : : : : : : :
D.3.6 Structure Chart : : : : : : : : : : : : : : : : : : :
D.3.7 Action Block Usage : : : : : : : : : : : : : : : : :
D.3.8 Data Structure List and Data Store List : : : : : :
D.3.9 Transformation : : : : : : : : : : : : : : : : : : : :
D.3.10 Retransformation : : : : : : : : : : : : : : : : : : :
D.3.11 Referential Integrity : : : : : : : : : : : : : : : : :
D.3.12 Reports : : : : : : : : : : : : : : : : : : : : : : : :
D.3.13 Consistency Checks : : : : : : : : : : : : : : : : :
D.3.14 Summary : : : : : : : : : : : : : : : : : : : : : : :
D.4 The IEF Construction Toolset : : : : : : : : : : : : : : : :
D.4.1 Environment : : : : : : : : : : : : : : : : : : : : :
D.4.2 Packaging : : : : : : : : : : : : : : : : : : : : : : :
D.4.3 Generation : : : : : : : : : : : : : : : : : : : : : :
D.4.4 Application Environment Facility (AEF) : : : : : :
D.4.5 Summary : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
: : : : : : : : : : : : : : :
E TI IEF Tutorials
E.1 Introduction : : : : : : : : : : : : : : : :
E.2 Information Engineering Facility (IEF) :
E.3 IEF Toolsets : : : : : : : : : : : : : : :
E.3.1 Planning Toolset : : : : : : : : :
E.3.2 Analysis Toolset : : : : : : : : :
E.3.3 Design Toolset : : : : : : : : : :
E.3.4 Construction Toolset : : : : : : :
E.4 IEF Tools and Features : : : : : : : : :
E.4.1 Chain : : : : : : : : : : : : : : :
E.4.2 Edit : : : : : : : : : : : : : : : :
E.4.3 View : : : : : : : : : : : : : : : :
E.4.4 Redraw : : : : : : : : : : : : : :
E.4.5 Consistency Checks : : : : : : :
E.4.6 Help : : : : : : : : : : : : : : : :
75
75
76
79
79
80
80
81
81
82
84
85
86
86
87
87
87
88
88
88
89
89
90
90
91
91
92
93
94
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : : : : : :
94
94
94
94
95
96
96
97
97
97
97
97
97
98
E.4.7 Reports : : : : : : : : : : : : : : : : : :
E.5 Tutorial 1 - Organizational Hierarchy Diagram
E.6 Tutorial 2 - Entity-Relationship Diagram : : :
E.6.1 Entities, Attributes and Relationships :
E.7 Tutorial 3 - Activity Hierarchy Diagram : : : :
E.7.1 Function and Process Descriptions : : :
E.7.2 IEF Activity Hierarchy Report : : : : :
E.8 Tutorial 4 - Activity Dependency Diagram : : :
E.8.1 Process Dependencies : : : : : : : : : :
E.9 Tutorial 5 - Process Action Diagrams : : : : : :
E.9.1 Sample IEF Process Action Diagrams :
E.10 Tutorial 6 - Business System Defaults : : : : :
E.11 Tutorial 7 - Dialog Flow Diagram : : : : : : : :
E.12 Tutorial 8 - Procedure Action Diagrams : : : :
E.13 Tutorial 9 - Screen Design : : : : : : : : : : : :
E.14 Tutorial 10 - Construction : : : : : : : : : : : :
E.15 Tutorial 11 - Testing : : : : : : : : : : : : : : :
E.15.1 Testing using the Installation Monitor :
E.15.2 Testing using the AEF : : : : : : : : : :
98
: 100
: 102
: 104
: 108
: 110
: 114
: 115
: 117
: 118
: 119
: 123
: 125
: 128
: 130
: 132
: 134
: 134
: 134
: : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : :
List of Figures
1
2
3
4
5
6
7
8
9
10
Organizational Hierarchy Diagram : : : : : :
Consistency Check Report : : : : : : : : : : :
Entity Relationship Diagram (ERD) : : : : :
Entity Relationship Diagram (Project Entity)
Activity Dependency Diagram (ADD) : : : :
Activity Hierarchy Diagram (AHD) : : : : : :
A Sample Action Block Diagram : : : : : : :
Structure Chart Diagram : : : : : : : : : : :
A Sample User Interface Screen : : : : : : : :
Dialog Flow Diagram (DFD) : : : : : : : : :
17
:
19
:
20
:
21
:
22
:
23
:
25
:
27
:
29
: 127
: : : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : : : : : : : : : :
1 Introduction
Computer Aided Software Engineering (CASE) tools were introduced commercially in the early
1980's. CASE was developed to facilitate the use of a structured and consistent methodology
for software/systems development, particularly within an organization. The use of a structured
development methodology and specically a CASE tool which would enforce the consistency of
methods in an organization was seen as a solution to the diculty of maintaining a consistent
methodology and quality of product.
Although some organizations have adopted the use of CASE tools 1], in some instances these
tools are simply not used after purchase 15]. Reasons which have been cited for the lack of
acceptance include the length of the learning curve involved in adapting to the CASE tool and
simply the adjustment to structured development methodology in an environment where this has
not been followed previously. CASE tools are purported to decrease development time and increase
productivity, however, the learning phase must be completed and the technology accepted, before
changes in productivity can accurately be assessed.
CASE tools fall into three categories depending on the phase of the development life cycle the
tool supports. Upper CASE tools support the planning and analysis phases of system development
with some support of the design phase. Lower CASE tools support the design and construction
phases of development. Integrated CASE tools (I-CASE) support all the phases of development and
provide support as well for reengineering. Advancements in the CASE tools available have resulted
in the growth of the integrated CASE tools category which take the developer or development
teams through the entire process from planning to construction and testing.
This project was undertaken to study the development of an information system using an
integrated CASE tool. The goals of the project were:
To develop a case study for possible use in class environments (such as software engineering,
systems analysis and design).
To assess the reason(s) CASE tools have not achieved the level of acceptance that was initially
anticipated.
{ Is the learning curve excessively long?
{ If so, why is the learning curve so long?
{ Is the learning curve worth the eort?
The integrated CASE tool that was selected was Texas Instruments' (TI) Information Engineering Facility (IEF), Version 5.1. This CASE tool consists of four toolsets: 1) Planning, 2)
Analysis, 3) Design and 4) Construction. These allow the developer(s) to evolve the application
under development through the entire process from planning to implementation.
The same information system that was developed for this case study was also developed in the
department without the use of a CASE tool which provided insight into the development process
without the introduction of CASE technology.
The rest of this report is organized as follows. Section 2 provides an overview of the project,
including the methodology followed for the project. A number of factors were identied prior to
7
the start of the project which would provide a basis for the evaluation of the CASE tool. These
are detailed in the overview of the project.
Section 3 provides a brief overview of the information system that was developed for this project
and the rationale for the selection of this information system. Complete details of the information
system can be found in Appendix A.
Section 4 provides an overview of the IEF toolsets and the tools available in each toolset. A
detailed evaluation of the IEF toolsets is given in Appendix D. A set of tutorials that can be used
for learning the IEF CASE tool is also included in Appendix E.
Section 5 provides details of the development of the information system. This section is divided
into subsections, one for each of the four development phases and each subsection also includes a
brief summary of the evaluation of the applicable IEF tools and toolset.
Section 6 provides a discussion of the experience in the use of the IEF. This section highlights
some of the good features and poor features of the IEF, some of which may be applicable to I-CASE
tools in general.
Section 7 provides a summary of the project. This section also includes comments regarding
the evaluation factors stated in Section 2 and provides answers to the questions raised for these
factors.
Section 8 provides the conclusions reached at the end of this project. The questions raised
in the goals of the project are answered, or at the very least the author's opinions regarding the
answers to those questions are provided. This section also provides plans or suggestions for future
work in this area.
2 Project Overview
This project involved a case study using the Information Engineering Facility (IEF) by Texas
Instruments (TI). The software development methodology followed was determined by the IEF
tool which uses the Information Engineering structured methodology dened by James Martin
9, 13, 18]. The project involved four distinct phases: 1) Information Strategy Planning, 2) Business
Area Analysis, 3) Business System and Technical Design, and 4) Construction and Testing.
2.1 Information Strategy Planning
Information Strategy Planning (ISP) involves the denition of broad information requirements for
a business system as well as a plan for the development of the information system. This includes
a denition of the organization and the entire set of business processes for a business system. This
project analyzed a specic business process and designed and implemented an information system
for that process rather than an entire business system.
The plan established for this project was a Systems Project Management Plan (SPMP) 17].
Microsoft Project, Version 3.0 was also used to detail the project plan. The IEF Planning Toolset,
does not support documentation of a project plan.
8
2.2 Business Area Analysis
Business Area Analysis (BAA) involves the analysis of a specic business area. BAA further denes
the data and activity requirements of a business process as well as the dependencies and interactions
between data and activities. The IEF Analysis Toolset supports the activities of the BAA phase
of development.
2.3 Business System and Technical Design
Business System and Technical Design (BSD/TD) involve the detailed development of the elementary processes and activities in a business process and identication of the target environment for
the completed information system. The IEF Design Toolset supports the activities of the BSD/TD
phase of development.
2.4 Construction and Testing
Construction involves the generation and installation of the database and the code for the information system. The IEF Construction Toolset for OS/2 supports the construction activities and
provides testing facilities to debug the installed information system.
2.5 Methodology
The goals of this project required adherence to the Information Engineering methodology and use
of all IEF toolsets. The lack of an organizational structure to analyze in this project required the
use of unrelated information to fully review the IEF Planning Toolset. The information used for
this purpose is dened in the pertinent sections of this document.
The information system selected for development was the Distributed Project Management
Information System (DPMIS). The DPMIS provides a set of applications to support the information
requirements necessary to track the progress, status and descriptive details of projects spanning
multiple sites. Details of the information system are included in the section, \Overview of the
Information System".
The DPMIS developed was saved at the completion of each development phase to provide
a complete case study for future reference. The process of developing this system was detailed
and documented with a view to providing documentation of the CASE development process and
information on the functionality of the selected CASE tool. In addition, a set of tutorials has been
developed for possible use in future courses, to assist individuals in gaining experience with the
IEF toolsets.
2.6 Evaluation Factors
The following aspects of the CASE tool's performance and functionality were taken into consideration and the associated questions answered in order to complete the evaluation. The factors
considered in this study have been dened through a combination of the author's CASE tool experience and a review of the available literature 1, 15].
Diagraming Capabilities
9
{ Quality of Diagrams
Are diagram labels readable?
Can diagram objects be resized?
Can diagram lines be redrawn?
{ Flexibility of Diagraming Tools
Is it possible to transfer between levels of a diagram?
Is it possible to transfer between related diagrams?
{ Quality of Printout of Diagrams
Is diagram printout legible?
Can diagram fonts be adjusted?
Can diagram headings be changed?
Software Engineering Methodologies
{ Methodologies Supported
Does the tool support a single methodology?
Are multiple methodologies supported?
What methodologies are supported?
{ Adherence to Specic Methodologies
Are there specic omissions that can be identied related to the methodology?
Consistency Checking
{ Flexibility of Consistency Checking
Are consistency checks run automatically by the CASE tool?
Can the user initiate consistency checks?
Can the user specify the level of the consistency check?
{ Completeness of Consistency Checks
Are there errors in the development process that are not identied in consistency
checks and become evident at a later phase of development?
Toolset Integration
{ Level of Integration
Are all of the toolsets for the CASE tool integrated?
Is a common repository accessible by all tools?
Is all of the information entered in the planning phase toolset available to the analysis
phase toolset?
Do details of the information system need to be reentered?
Documentation
10
{ Completeness of Documentation
Are there omissions of detail regarding the information system that can be identied
in the documentation produced?
Is the documentation produced useful to individuals not familiar with the specic
CASE tool?
Are all details regarding a process or object presented in the documentation and
reports available?
{ Readability of Documentation
Do documents include a description of processes or objects that allows the reader
to understand the purpose of the object or process with respect to the information
system?
Are headings included that identify the report or document?
Database Generation
{ What databases types can be generated?
Code Construction
{ Programming Languages
What languages can be generated?
{ Quality of Code Generated
Does the code generated compile without errors?
If not, how many errors are encountered per module?
Are changes/additions necessary to the nal code?
How many changes/additions are required?
Reengineering Support
{ Are changes made in earlier development phases integrated into the latter phases (specifically related to reengineering)?
Availability of Metrics
{ Management Metrics
Are management metrics available?
{ Quality Metrics
Are quality metrics available?
3 Overview of the Information System
The information system selected for development was the Distributed Project Management Information System (DPMIS). This section provides essential details of the DPMIS. A complete
description of the DPMIS is appended to this document (Appendix A).
11
3.1 Objective
The DPMIS supports the tracking of the progress, status and descriptive details of projects spanning
multiple sites, including:
Denition of Projects which are local to sites or span multiple sites.
Permit the creation, update and deletion of Projects by Project Leaders.
Permit any Project Member to Browse and/or Retrieve information about any Project or
related entities.
3.2 Rationale
The information system oers a number of attractions for use in the case study:
We have experience with a distributed project, namely CORDS, 10] which can provide a set
of needs and for which such an information system would have been very useful.
It oers local update and yet requires a browsing capability which entails multi-site queries.
Interfaces for the two tools, one for information maintenance and one for information retrieval,
should be kept simple.
It is easy to explain the scenario and need for such an information system to non-technical
users (e.g. managers and executives).
It is easy to dene additional tools for generating reports, extracting data for PERT or Gantt
Charts, extracting e-mail lists, etc.
3.3 Information System
The information system consists of two (initial) components:
1. Information Maintenance Tool
The Information Maintenance Tool allows the creation, update and deletion of all entities
dened in the information system.
2. Information Retrieval Tool
The Information Retrieval Tool allows the retrieval of information regarding all current
Projects and the related entities dened in the information system.
Each tool will run local to a Site. The Information Maintenance Tool will update a local
database (or designate) while the Information Retrieval Tool will permit information to be collected
from the multiple sites.
The entities dened in the information system are as follows:
Projects are research projects being conducted by organizations at various sites in Canada, the
United States and Europe.
12
Sites are organizations in Canada, the United States and Europe where Projects are undertaken.
Sites can be maintained on the database without currently active projects.
Members are sta, students and faculty at the sites who are currently involved with projects
which are being monitored using the DPMIS.
Milestones represent signicant development events that exist for each project.
Deliverables represent specic documents, prototypes and presentations and their respective delivery dates that exist for each project.
Documents represent information about the current projects.
4 Overview of the IEF CASE tool
The IEF products utilized in this project were the IEF Version 5.1 for use in the DOS/Windows
Version 3.1 environment and the IEF Version 5.1 for use in the OS/2 environment. The initial
development of the DPMIS was done using the Planning, Analysis and Design Toolsets of the
IEF for Windows because the OS/2 operating system and Extended Services for OS/2 were not
available at the start of this project. The IEF Construction Toolset requires either a mainframe
environment or the OS/2 operating system with Extended Services for OS/2. The IEF DPMIS
model was transferred to the IEF for OS/2 when this became available. This section of the document
details the IEF toolsets and the tools available in each toolset. The IEF Planning, Analysis and
Design toolsets are nearly identical for both environments, however, dierences that do exist in the
toolsets are noted.
4.1 IEF Planning Toolset
The Planning Toolset of the IEF was used during information strategy planning in the development
of the business information system. The Planning Toolset of the IEF has the following options
available.
Data Model facilitates the creation of an entity relationship diagram (ERD) for the information system under development.
Data Model List provides an alternative method of constructing the ERD and provides the
entity relationship details in a list format.
Activity Hierarchy facilitates the creation of an activity hierarchy diagram (AHD) for the
information system under development.
Activity Dependency facilitates the creation of an activity dependency diagram (ADD). This
is developed automatically by the IEF as the user develops the AHD.
Organizational Hierarchy accesses the organizational hierarchy diagraming tool to enable the
construction of the organizational hierarchy diagram.
13
Matrices are automatically generated by the IEF and are utilized to perform analysis of the
system.
Check initiates a Consistency Check.
4.2 IEF Analysis Toolset
The Analysis Toolset of the IEF is used during business area analysis of the information system
under development. The Analysis Toolset of the IEF has the following options available 1 .
Data Model.
Data Model List.
Activity Hierarchy.
Activity Dependency.
Action Diagram facilitates the creation of action diagrams (algorithms) for processes dened
in the activity hierarchy.
Work Set List provides a list of the work sets available for the system. Work sets are used
for items such as counters, user input that is not entity related (e.g., menu selections).
Structure Chart which displays the action block hierarchy diagram.
Action Block Usage which displays the usage of action blocks by procedures and procedure
steps.
Matrices.
Business System De nition facilitates the denition of a business system for use in the Design
Toolset.
Check.
4.3 IEF Design Toolset
The Design Toolset of the IEF is used during business system design and technical design of the
information system under development. The Design Toolset of the IEF has the following options
available.
Business System Defaults allows the setting of system defaults such as screen video properties
and function key assignments.
Dialog Design allows the development of the dialog ow diagram.
Screen Design allows the design of the user interface.
1
Options that are not described here possess the same meaning as given previously.
14
Action Diagram.
Work Set List.
Structure Chart.
Action Block Usage.
Prototyping allows the review of the design of the user interface.
Dialect De nition allows the user to dene objects for use in the model. The IEF has a default
dialect.
Check.
Data Structure Defaults allows the user to set the defaults for data structures.
Data Structure List presents a list of the physical data model.
Data Store List provides a list of the data stores, tablespaces and records.
Transformation is the transformation of the data model objects to data model structures.
Retransformation is used to perform transformation again when changes have been made to
the data model.
Referential Integrity Process checks the integrity of the data model relationships.
4.4 IEF Construction Toolset
The Construction Toolset of the IEF was used to generate and install the database tables and the
code for the DPMIS. The code generated was C although generation of COBOL source code is also
available. The Construction Toolset of the IEF has the following options available.
Environment is the tool used to dene the environment the application will be used in following
development. The environment parameters that are dened here include the target operating
system, database management system and language.
Packaging allows the user to specify the type of load modules: Online, Batch, or Window
and the number of load modules or objects will be required for the business system.
Generation is the nal tool used in this toolset. This tool allows the user to generate and install
the database and code. Installation includes compilation and linking of the load modules and
results in the production of executable modules.
5 Development of the Information System
The development of the DPMIS followed the Information Engineering methodology used by the
IEF CASE tool. The following sections describe the activities and IEF tools used in each phase of
development. The reference materials available for the IEF 2, 3, 4, 5, 6, 7, 8] were reviewed prior
to the initiation of the DPMIS development.
15
5.1 Information Strategy Planning (ISP)
The IEF Planning Toolset was used throughout this phase of the project. The IEF Planning Toolset
does not support project management plan documentation, therefore, a SPMP 17] was developed.
The basic information requirements and functional requirements of the DPMIS had been outlined prior to the initiation of the use of the IEF. The denitions of the DPMIS and the entities for
this system were claried prior to the development of an entity relationship diagram (ERD). The
entity relationship diagram was developed in detail during the planning phase although this is not
necessary in the ISP phase of development. Generally the details of entities and entity relationships
for an information system would be entered in the Business Area Analysis (BAA) phase with the
use of the Data Model tool. The Data Model tool is accessible in both the Planning Toolset and
the Analysis Toolset.
The consistency check feature provided by the IEF was used throughout the planning phase
and was the nal step undertaken before moving on to the analysis phase to ensure the information
contained in the IEF model of the DPMIS was correct and complete (see Figure 2).
The reports available from the IEF, including the consistency check reports, were reviewed and
used to conrm the correctness and completeness of the planning phase development throughout
this phase of the project.
In addition to the development of the DPMIS with the IEF Planning toolset additional examples
were used and tests were undertaken to ensure the utilization of all of the features of the Planning
toolset. In particular, the IEF Organizational Hierarchy diagraming tool was utilized to develop
an organizational hierarchy diagram (OHD) (Figure 1).
The details of the good features, poor features and inconsistencies that were encountered in the
use of the IEF Planning Toolset are included in the \Evaluation of the IEF Toolsets" document
(Appendix D). A summary of these comments is included here.
5.1.1 IEF Planning Toolset Summary
The IEF Planning Toolset is, overall a straight forward tool to learn to use. The on-line Help
facility is very good and detailed. Methods for developing the diagrams are consistent throughout
the various diagramming tools. The IEF does not oer the exibility or diagram quality that would
be required to develop presentation quality diagrams. The diagrams produced are more appropriate
for information only. For example, the information contained in the diagrams could be useful to
an analysis team for the next phase of development.
The following short comments provide a brief outline of notable good features, poor features
and inconsistencies. Details of these features and other features can be found in Appendix D.
Chaining allows the developer to move quickly between sections of a diagram and between
diagrams.
Chaining does not allow the display of dierent sections of a diagram in dierent windows
at the same time.
Subordinate units in an organizational hierarchy diagram (OHD) cannot have two parents.
Names of organizational units cannot exceed 32 characters in length.
16
Model :UNIVERSITY OF WESTERN ONTARIO
Subset:ALL
Date: Jun. 06, 1994
Time: 09:14
CHANC>
PRESIDE>
INSTITUTI> LIBRARIES VICE-PR> DEAN A> DEAN A> DEAN B> DEAN D> DEAN E> D
Figure 1: Organizational Hierarchy Diagram
17
Printing of diagrams produces poor quality print outs.
Help is very good in the Planning Toolset. There are instances where the information
provided was inadequate.
Reports are useful and provide good detail regarding the information system that is being
developed.
Automatic population of related diagrams and matrices by the IEF is a great time saver.
Consistency checks are the primary error checking method used throughout development.
The reports provided are useful (See Figure 2). Consistency checks can be initiated by the
developer.
Release Notes provided in the Reports menu are useful, particularly, since the documentation available was for Version 4.1.
5.1.2 IEF Planning Toolset Deliverables
The IEF deliverables for the ISP phase were produced. Examples of the diagrams and reports
produced are included to provide a view of the type of documentation produced by the IEF Planning
Toolset. The entire set of deliverables for this phase is not included because of the length of some
of the reports.
1.
2.
3.
4.
5.
6.
7.
8.
9.
Organizational Hierarchy Diagram (Figure 1)
Data Model (Entity-Relationship Diagram) (Figure 3)
Entity Hierarchy Report
Data Model List
Entity Type Denition
Attribute Denition Report
Process (Activity) Hierarchy Diagram (Figure 6)
Activity Hierarchy Report
Process (Activity) Dependency Diagram (Figure 5)
18
Model : DISTRIBUTED PROJECT MANAGEMENT
Subset: ALL
Mar. 20, 1994
09:43
page 1
Consistency Check
______________________________________________________________________________________________
Level: TD
---------Model/Subset
---------Process ADD_PROJECT
WARNING
: ICCPF10W Dependencies of elementary processes and external objects should be
associated with information views.
Business System DISTRIBUTED_PROJECT_MANAGEMENT
WARNING
: ICCBS02W All processes scoped in a business system should be implemented.
Screen for Procedure Step MAINTAIN_PROJECT
WARNING
: ICCSC10W Each mandatory input predicate view should be input by a screen
variable or provided by a dialog flow.
Link from Procedure Step MAINTAIN_PROJECT to Procedure Step MAINTAIN_PROJECT
WARNING
: ICCDV11W The view provided as import should have all the attribute views
needed by the receiving action block.
Link from Procedure Step MAINTAIN_PROJECT to Procedure Step MAINTAIN_MEMBER
WARNING
: ICCDV11W The view provided as import should have all the attribute views
needed by the receiving action block.
Screen for Procedure Step MAINTAIN_MEMBER
WARNING
: ICCSC10W Each mandatory input predicate view should be input by a screen
variable or provided by a dialog flow.
Link from Procedure Step MAINTAIN_DELIVERABLE to Procedure Step MAINTAIN_MEMBER
WARNING
: ICCDV11W The view provided as import should have all the attribute views
needed by the receiving action block.
Link from Procedure Step MAINTAIN_DELIVERABLE to Procedure Step MAINTAIN_DELIVERABLE
WARNING
: ICCDV11W The view provided as import should have all the attribute views
needed by the receiving action block.
External Object DISTRIBUTED_PROJECT_MANAGEMENT
WARNING
: ICCEX02W An external object should be associated with at least one activity.
Number of ERRORS: 0, number of WARNINGS: 9.
-End of Report-
Figure 2: Consistency Check Report
19
Model :DISTRIBUTED PROJECT MANAGEMENT
Subset:ALL
Date: Mar. 20, 1994
Time: 09:40
DISTRIBUTED PROJECT MANAGEME>
HAS RELATION TO
IS RELATED TO
HAS DELIVERABLES
IS DESCRIBED BY DOCUMENT
IS COORDINATED BY
PROJECT
SUPERVISES
IS SUPERVISED BY
COORDINATES PROJECT
HAS MILESTONE
HAS MEMBER
IS MEMBER OF PROJECT
IS AT
IS AT PRIMARY
IS PRINCIPAL>
MEMBER
HAS PRIMARY AFF>
IS RESPONSIBLE FOR
ALSO WORKS AT
WORKS ON
IS AUTHOR OF
IS CONTACT FOR
MANAGES
HAS MEMBER
IS PRIMARY AFFILIATION FOR
HAS PROJECT
IS PRIMARY LOCATION FOR
HAS CONTACT
SITE
CAN FTP DOCUMENT
IS MILESTONE OF
Figure 3: Entity Relationship Diagram (ERD)
20
IS MANAGED BY
Model :DISTRIBUTED PROJECT MANAGEMENT
Subset:ALL
Date: Mar. 20, 1994
Time: 09:43
DISTRIBUTED PROJECT MANAGEMENT
HAS RELATION TO
IS RELATED TO
HAS DELIVERABLES
IS DESCRIBED BY DOCUMENT
IS COORDINATED BY
PROJECT
HAS MILESTONE
HAS MEMBER
IS AT
IS AT PRIMARY
H
IS PRIMARY AFFIL
HA
IS PRIMARY LOC
Figure 4: Entity Relationship Diagram (Project Entity)
21
Model :DISTRIBUTED PROJECT MANAGEMENT
Subset:ALL
PROJECT INFORMATION EXISTS
MILESTONE
INFORMAT>
PROJECT MANAGEMENT
DATABASE INFO
INFORMATION
EXISTS
SITE INFORMATION
RETRIEVAL
MEMBER INFORMATION>
I>
SITE
DOCUMENT INFORMATION EXISTS
DELIVERABLE
Date: Mar. 30, 1994
Time: 21:06
MEMBER INFORMATION
RETRIEVAL
Figure 5: Activity Dependency Diagram (ADD)
22
Model :DISTRIBUTED PROJECT MANAGEMENT
Subset:ALL
Date: Mar. 30, 1994
Time: 21:04
DISTRIBUTED PROJECT MANAGEME>
INFORMATION MAINTENANCE
PROJECT MAINTENANCE
SITE MAINTENANCE
MEMBER MAINTENANCE
MILESTONE MAINTENANCE
DELIVERABLE MAINTENANCE
DOCUMENT MAINTENANCE
INFORMATION RETRIEVAL
PROJECT INFORMATION RETRIEVAL
SITE INFORMATION RETRIEVAL
MEMBER INFORMATION RETRIEVAL
MILESTONE INFORMATION RETRIE>
DELIVERABLE INFORMATION RETR>
DOCUMENT INFORMATION RETRIEV>
Figure 6: Activity Hierarchy Diagram (AHD)
23
5.2 Business Area Analysis (BAA)
The Analysis toolset of the IEF was used to continue development of the DPMIS in the business
area analysis phase. The Activity Hierarchy Diagram (AHD) had been developed to the Process
Hierarchy Diagram (PHD) level rather than the Function Hierarchy Diagram (FHD) level and
details such as expected eects had been included in the initial phase of the project. The analysis
phase of the project, therefore, consisted of a review of the information developed during the
planning phase and adjustments and corrections to this information as well as to the denition of
the DPMIS.
The entity-relationship diagram (ERD) that had been constructed in the planning phase was
reviewed and necessary changes were made. An alternative ERD was constructed to review the
partitioning and entity subtype features of the IEF data model tool. Partitioning and entity
subtypes were not used in the DPMIS because these were not applicable.
The use of the Data Model List tool of the IEF toolset was reviewed. This tool can be utilized to
build the ERD as an alternative to the Data Model diagraming tool that was used for this project.
The Data Model List tool was not used to build an ERD. It was used to implement some of the
changes necessary.
The Matrix Processor of the IEF toolsets was reviewed and used to review the relationships of
function, processes and entities and the expected eects of functions and processes on the entities
in the data model.
The Action Diagram tool of the Analysis toolset was used to develop action diagrams for the
elementary processes dened in the analysis and planning phases of development. Ultimately, the
action block synthesis tool of the IEF toolset was used to produce the process action diagrams and
further review and development of these diagrams was reserved for the design phase of the project.
Figure 7 shows a sample action block diagram developed by the IEF Action Diagram tool.
A nal consistency check was completed for the analysis phase and the Business System Denition completed to provide a business system denition to utilize in the design phase of the project.
The reports available in the IEF Analysis toolset were reviewed and utilized where appropriate
throughout the business area analysis phase of the project. An example of a report generated by
the IEF is appended to this document (Appendix B).
The details of the good features, poor features and inconsistencies that were encountered in the
use of the IEF Analysis Toolset are included in the \Evaluation of the IEF Toolsets" document
(Appendix D). A summary of these comments is included here.
5.2.1 IEF Analysis Toolset Summary
The Analysis Toolset usage followed very closely to that of the Planning Toolset and since the
mechanical procedures for the use of IEF tools had been learned in the Planning Toolset the
development was on the most part smoother and faster.
The following short comments provide a brief outline of notable good features, poor features
and inconsistencies. Details of these features and other features can be found in Appendix D.
Chaining is useful again for moving to sections of a diagram and between diagrams.
Consistency Checks are still very helpful. The checks that are initiated by the IEF are
unobtrusive and essential.
24
Model : DISTRIBUTED PROJECT MANAGEMENT
Subset: ALL
Mar. 20, 1994 12:31
Page:
1
Process: ADD_MEMBER
___________________________________________________________________________
Process Description:
Add Member is an elementary process in the Member Maintenance process hierarchy.
Action Block Description:
ADD_MEMBER
IMPORTS: ...
EXPORTS: ...
LOCALS:
ENTITY ACTIONS: ...
1
1
1
1
2
3
4
5
6
7
8
9
10
11
12
3
13
3
14
3
15
3
16
17
17
17
17
17
17
18
19
19
20
21
21
21
21
21
21
22
23
23
21
24
21
20
17
25
17
16
1
26
1
READ stored site
WHERE DESIRED stored site organization IS EQUAL TO import_1 site
organization
WHEN successful
MOVE stored site TO export_1 site
CREATE stored member
SET surname TO import member surname
SET first_name TO import member first_name
SET project_position TO import member project_position
SET email TO import member email
SET telephone TO import member telephone
SET fax TO import member fax
SET job_type TO import member job_type
SET password TO import member surname
ASSOCIATE WITH stored site WHICH is_primary_affiliation_for IT
WHEN successful
MOVE stored member TO export member
WHEN already exists
EXIT STATE IS member_ae WITH ROLLBACK
WHEN permitted value violation
EXIT STATE IS member_pv WITH ROLLBACK
IF EXITSTATE IS EQUAL TO ok
READ stored_manager member
WHERE DESIRED stored_manager member surname IS EQUAL TO
manager_in member surname
AND DESIRED stored_manager member first_name IS EQUAL TO
manager_in member first_name
WHEN successful
MOVE stored_manager member TO manager_out member
ASSOCIATE stored_manager member
WITH stored member WHICH is_managed_by IT
IF import member project_position IS EQUAL TO "student"
READ stored_supervisor member
WHERE DESIRED stored_supervisor member surname
IS EQUAL TO supervisor_in member surname
AND DESIRED stored_supervisor member first_name
IS EQUAL TO supervisor_in member first_name
WHEN successful
MOVE stored_supervisor member TO supervisor_out member
ASSOCIATE stored_supervisor member
WITH stored member WHICH is_supervised_by IT
WHEN not found
EXIT STATE IS supervisor_nf
WHEN not found
EXIT STATE IS manager_nf
WHEN not found
EXIT STATE IS site_nf WITH ROLLBACK
Figure 7: A Sample Action Block Diagram
25
This process will facilitate cr
Help was again, on the whole, very good. There were diculties in locating some information
on topics such as View Maintenance.
Printing again presents a problem because generating readable print outs is dicult, if not
impossible.
Data Model List provides a simple alternative tool for development of the ERD.
Consistency Check was successful despite the omission of an identier for an entity subtype.
An identier is essential in the development of an Action Diagram that eects this entity
subtype.
Action Block Synthesis and Expand Expected Eects are tools that provide automatic
generation of portions of the action diagrams. These can save a great deal of time and should
be utilized.
Stereotype is another tool for automatic generation. Stereotype action diagrams can be
automatically generated for diagrams such as menus. This is a useful tool, however, it is
dicult to locate from the the information in the documentation provided.
5.2.2 IEF Analysis Toolset Deliverables
The IEF deliverables for the BAA phase were produced. Examples of the diagrams and reports
produced are included to provide a view of the type of documentation produced by the IEF Analysis
Toolset. The entire set of deliverables for this phase is not included because of the length of some
of the reports.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Data Model (Entity-Relationship Diagram)
Entity Hierarchy Report
Data Model List
Entity Type Denition
Attribute Denition Report
Process (Activity) Hierarchy Diagram
Activity Hierarchy Report
Process (Activity) Dependency Diagram
Activity Denition Report
Process Action Diagrams
Structure Chart (action block hierarchy) Diagram (Figure 8)
26
Model :DISTRIBUTED PROJECT MANAGEMENT
Subset:ALL
Date: Mar. 30, 1994
Time: 21:11
DELETE DOC>
UPDATE DO>
ADD DOCU>
MAINTAIN D>
UPDATE DO>
ADD AUTHOR
ADD AUTHOR
Figure 8: Structure Chart Diagram
27
5.3 Business System and Technical Design (BSD)
The IEF Design toolset was used to complete the business system and technical design for the
DPMIS. The design of the DPMIS information maintenance tool was completed rst, followed
by the design of the DPMIS information retrieval tool. Design of both tools followed the format
detailed below.
Procedures and procedure steps which used the elementary processes dened in the analysis and
planning phases of development were dened and created in the design phase. The ows between
procedures and procedure steps were detailed with the Dialog Design tool of the IEF producing
the dialog ow diagram. Action diagrams for the procedures and procedure steps dened were
constructed in the design phase. Design also involved the user interface (screen) design.
The initial step in the system design was to review the Business System Defaults dened in the
IEF Design toolset such as, screen video properties and function key assignments.
The next step in design was the identication of essential ows between procedures such as
the ows from the menu procedures to the procedures for maintenance and retrieval of database
information. All ows identied throughout the design phase were included in the IEF dialog ow
diagram.
Initial construction of procedure and procedure step action diagrams was undertaken with the
use of the IEF Stereotype tool. This tool automatically generates action diagrams which t the
stereotype selected. For example, the basic outline of an action diagram for a menu can be generated
by selecting the menu stereotype. The action diagrams generated with this tool were reviewed and
utilized where appropriate. Procedure and procedure step action diagrams were also constructed
with the use of the Edit feature in the action diagraming tool.
Screen design for each of the procedures and procedure steps identied was completed with the
use of the IEF screen design tool. The IEF screen design tool provides an auto layout feature for
screen design. This feature was used to determine its usefulness, however, ultimately the screen
design was done without the use of the auto layout feature. The Prototype tool provided by the
IEF was utilized to review the screens designed. Figure 9 is a sample screen developed for the
DPMIS using the IEF screen design tool.
The IEF Design toolset for OS/2 includes a Window Design tool. The use of this tool was
reviewed briey by redeveloping some of the user interface in a Windows design, however, the
Windows design was not implemented for the DPMIS.
Consistency checks were performed at the business system design level following which technical
design was undertaken with the use of the IEF transformation, referential integrity and retransformation features available in the Design toolset.
Transformation of the data model objects into data structure objects was completed successfully.
The IEF automatically performs both consistency and referential integrity checks before allowing
the transformation to proceed.
The reports available from the IEF, including the consistency check reports, were reviewed and
used to conrm the correctness and completeness of the system development throughout the design
phase.
The details of the good features, poor features and inconsistencies that were encountered in
the use of the IEF Design Toolset are included in the \Evaluation of the IEF Toolsets" document
(Appendix D). A summary of these comments is included here.
28
Model :DISTRIBUTED PROJECT MANAGEMENT
Subset:ALL
TRANCODE
Date: Mar. 20, 1994
Time: 12:33
PROJECT MAINTENANCE
YY-MM-DD
HH:MM:SS
PROJECT DETAIL
Project Name XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Status XXXXXXXXXX
Start Date YY-MM-DD
Completion Date YY-MM-DD
Description XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXX
SITE
Organization
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
PROJECT LEADER
Surname
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
First Name
XXXXXXXXXXXXXXXXXXXX
MILESTONE Milestone Name XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
DELIVERABLE
Deliverable NameXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Command
XXXXXXXXXXXXXXXXXXXX
<<< PFK >>> <<< PFK >>> <<< PFK >>> <<< PFK >>> <<< PFK >>> <<< PFK >>> <<< PFK
<<< ERR >>> <<< ERR >>> <<< ERR >>> <<< ERR >>> <<< ERR >>> <<< ERR >>> <<< ERR
Figure 9: A Sample User Interface Screen
29
5.3.1 IEF Design Toolset Summary
The Design toolset followed very closely in usage to both the Planning and Analysis toolsets in
the mechanics of development of IEF diagrams. The consistency in methods of editing diagrams is
helpful in the continued use of the IEF toolsets.
The information provided in on-line Help and in the reference material available is primarily
limited to \how-to" instructions. It would be benecial to have a better explanation of the concepts
involved in the design phase.
The reports available that are relevant to the Design Toolset are useful. These reports provide
lists and denitions of items such as procedures, procedure steps, commands and exit states.
The following short comemnts provide a brief outline of notable good features, poor features
and inconsistencies. Details of these features and other features can be found in Appendix D.
Consistency Check reports at times poorly identify problems. Notication of a problem is
provided but it is sometimes dicult to determine which entity or action was associated with
the error.
Help is less helpful in this phase because of the extent of gaps in information on topics such
as Exit States.
Prototyping is a tool that allows the designer to view prototypes of the screens designed
using the IEF tool. This was not useful for this project.
Chaining is extremely useful in this phase. It is possible to chain between screens, action
diagrams, prototyping and the structure chart.
Printing of a screen design does not include the function key assignments in the printout.
Auto Layout of screens is available. This generates the screen design when import and
export views have been dened. This was not useful for this project, however, the layouts
generated in testing were reasonable.
Help presents information on \how-to" develop action diagrams but is lacking in explanations
of the concepts and ow within the action diagrams.
Descriptions of procedure steps can be entered, however, the description does not print
correctly when the action diagram is printed.
5.3.2 IEF Design Toolset Deliverables
The IEF deliverables for the BSD phase were produced. Examples of the diagrams and reports
produced are included to provide a view of the type of documentation produced by the IEF Design
Toolset. The entire set of deliverables for this phase is not included because of the length of some
of the reports.
1. Structure Chart
2. Action Block Usage
30
3.
4.
5.
6.
7.
8.
9.
10.
11.
Procedure Action Diagram
Procedure and Procedure Step Screens
Procedure Step Denition Report
Dialog Flow Diagram
Exit State List
Exit State Usage Report
Data Structure List
Data Store List
DSD Implementation List
5.4 Construction and Testing
This phase of the project involved the generation of the code and setting up the database for the
DPMIS. This phase used the IEF Construction Toolset and the Extended Services for OS/2. OS/2
and the Extended Services were not available prior to the Construction phase of the project and
the IEF for the Windows environment does not include the Construction Toolset. Therefore, the
DPMIS \model" was transferred from the DOS version of the IEF to the OS/2 version of the IEF.
This was simply a matter of copying the les for the DPMIS model in the models directory for the
OS/2 version of the IEF.
The environment specied for the application was the OS/2 operating system and all other
environment parameters were set to those specied in the Workstation Construction guide 9].
Packaging of the load modules for the business system oers two options: one load module or
multiple load modules. The DPMIS business system was packaged using multiple load modules.
The load modules specied in packaging will each become executable les. It is recommended in the
Workstation Construction guide 9] that a single load module be specied for the OS/2 environment.
The single load module is recommended to eliminate of loading of multiple executable les during
testing. Multiple load modules were selected for the DPMIS based on the tutorial information that
is provided for the IEF Installation Model which is packaged in multiple load modules.
The next step in the construction of the DPMIS was to generate and install the database and
the code with the IEF Construction toolset. All modules were generated with the trace option
selected. This option allows for testing of the action diagrams and enables the user to debug the
diagrams, stepping through each diagram and moving between diagrams. The IEF automatically
runs a consistency check when generation is requested.
The information system was tested using the testing facilities provided in the IEF. Testing
was done with the Application Environment Facility (AEF) and also from the IEF Installation
Monitor. Testing in the IEF environment is done on the Action Diagrams rather than the C code,
when the code has been generated with the trace option. The IEF Installation Monitor becomes
active during generation and installation and the option to test can be selected when it is active.
31
The AEF testing facility was used when the IEF Installation Monitor was not active. These two
methods of testing were used and both methods worked in identical fashion once activated.
The details of the good features, poor features and inconsistencies that were encountered in the
use of the IEF Construction Toolset are included in the \Evaluation of the IEF Toolsets" document
(Appendix D). A summary of these comments is included here.
5.4.1 IEF Construction Toolset Summary
The IEF Construction Toolset is fully integrated with the other toolsets. It is fully automated and
the user is really only required to enter environment information and select the appropriate menu
selections to initiate the generation and installation of the DDL and source code.
The following short comments provide a brief outline of notable good features, poor features
and inconsistencies. Details of this features and other features can be found in Appendix D.
Generation and installation of the load modules cannot be halted with the STOP button
in the generation dialog box. The button was simply not functional.
Install All Changes saves a great deal of time since only the code for those sections of the
information system that were changed would be regenerated and installed.
Testing or debugging is done on the action diagrams. This is highly desirable over debugging
the source code. The testing methods are simple.
Testing was delayed by the omission of necessary instructions from the manuals.
Install All Changes worked successfully on the initial use of this function. A second attempt
to use the function was unsuccessful and a fatal error encountered. It was necessary to exit
and then restart the IEF to use Install All Changes again.
5.4.2 IEF Construction Toolset Deliverables
The IEF deliverables for the ISP phase were produced. Examples of the diagrams and reports
produced are included to provide a view of the type of documentation produced by the IEF Construction Toolset. The entire set of deliverables for this phase is not included because of the length
of some of the reports. A sample IEF-generated C source code is given in Appendix C.
1. C Source Code
2. Database Denition Language
3. DPMIS Executable Load Modules
6 Experience
The case study undertaken was overall a good and very interesting experience. As stated previously,
the initial development was done in the DOS/Windows version of the IEF. The IEF for OS/2 was
not available at the beginning of this project and the IEF Construction Toolset requires the OS/2
32
environment. Therefore the DPMIS model was transferred to the IEF for the OS/2 environment for
the Construction and Testing phase of development. The transfer was a simple matter of copying
the model les to the OS/2 IEF directory.
The IEF toolsets utilized during this project proved to be well integrated and the functionality
of the tools was consistent throughout the toolsets. The IEF is designed to span the entire systems
development process and does this very well. The feature that may disappoint users of upper CASE
tools is the quality of printouts available from the diagraming tools, such as the Organizational
Hierarchy Diagram tool, which do not produce diagrams of a quality that would be appropriate for
presentations.
The IEF version for OS/2 would be the preferred environment for the development of future
information systems. It is anticipated that the learning curve would have been faster with the
use of the OS/2 version since the generation and testing of some modules would make up for
some of the lack of documentation of the IEF procedures. Incomplete documentation or outdated
documentation presented the major diculty in learning the proper use of the IEF CASE tool.
Summaries of good features and inconsistencies, as well as, poor features encountered are outlined
in the following sections of this document.
6.1 Summary of Good Features of the IEF Toolsets
Procedures for creating and editing diagrams were very consistent from toolset to toolset. There
were some dierences in functionality of some tools which did not present a problem in the use of
the tools. The consistency of the diagraming tools speeded the development of further diagrams
once one IEF diagram had been constructed.
Diagrams and matrices were automatically populated by the IEF during the construction of
related diagrams which also helps to speed the system development process.
Alternative methods of developing diagrams are available such as the Data Model List which
provides an alternative method of developing the entity-relationship diagram and some users may
nd the list style easier to work with than the diagram style.
The IEF eciently maintains the data for the DPMIS during the development process. Details
regarding the information system which were entered during the use of one toolset were consistently
available when progressing to the next toolset and phase of development.
The reports available from the IEF toolsets provide a good reference for the IEF users as well
as information on the system for project members not involved in the use of the IEF toolsets.
The IEF Chaining tool allows you to transfer quickly to other diagrams or other sections of the
current diagram. For example, it is possible to chain from the activity hierarchy diagram to the
activity dependency diagram.
Consistency Checks are available at each development level and for the most part these are
initiated by the user. The few Consistency Checks that are automatically run by the IEF are
essential and unobtrusive.
Generation and installation of the Database Denition Language (DDL) and the load modules
is handled completely by the IEF. The IEF runs a consistency check prior to the generation and
installation. Error reports are provided for each module which clearly identify the errors encountered.
33
The source code produced by the IEF is dicult, if not impossible, to follow. Therefore, testing
is done by stepping through the action diagrams. The testing procedures are identical in the AEF
and from the IEF Installation Monitor and once the user is familiar with the way to use the testing
facilities it works very well and testing proceeds very smoothly.
Necessary changes that are identied through the testing of action diagrams can easily be
changed in the action diagrams, dialog ow or view mapping in the screen design can be implemented with the use of the appropriate tool. The IEF tools provide the option to generate code
for a specic action diagram or screen and the construction toolset allows the user to select the
option to \Install All Changes" which saves a great deal of time over complete regeneration and
installation of the entire application.
6.2 Summary of Poor Features of the IEF Toolsets
The poor features encountered in the use of the IEF toolsets centered mainly around the exibility
of the diagraming tools and the quality of the printouts available from the diagraming tools. Specic
diculties encountered are detailed in the evaluations of the individual toolsets.
The IEF diagraming tools did not allow the user to generate a good quality printout. It was
not possible to change the label on the diagrams printed to provide simple identication of the
diagram, for example, process activity hierarchy versus function activity diagrams.
To produce a reasonable quality print out of the diagrams, in particular, the larger diagrams, it
was necessary to perform a great deal of tedious moving of boxes and lines. Fonts were adjustable in
the IEF diagrams with the Options selection of the IEF, however the fonts on the printed diagrams
were not adjustable by the user.
The IEF provides documentation of the information system, however, it is not mandatory to
complete many of the descriptions, such as the descriptions of procedures and procedure steps. The
entry of this information would be essential for using the IEF in the team environment where the
development phases were completed by separate teams or individuals.
The IEF Help facility was, on the whole, useful. The most notable drawback was the fact
that, particularly in the Design toolset, was that the information available on a topic stressed the
\how-to" and did not always provide a satisfactory explanation of the purpose and downstream
eects of a topic referenced.
The generation and complete installation of the entire information system, DDL and code
required approximately three (3) hours and the \STOP" button in the generation dialog box did
not work. This button should halt the generation process once it has been initiated. This presents
a problem, particularly, in the learning phase of using the IEF since once the generation has been
started, the user has only two options, reboot the machine or wait until the generation has nished.
The benets noted regarding generation of specic modules and installation of the changes only
presented a diculty when utilized. The user was allowed to use this option once successfully,
however, a second attempt to use this function without exiting the IEF resulted in an internal error
and any changes that had been made were lost.
The testing facilities available in the IEF, as mentioned above are quite good, however, the
documentation available for the AEF did not instruct the user that it was necessary to set \aetest"
to on in order to use the trace facility. This omission delayed the testing of the information system.
The instruction was eventually located in the IEF Rapid Development Tutorial 12].
34
6.3 Summary of Inconsistencies in the IEF Toolsets
The IEF toolsets did not present the user with many inconsistency problems. Some minor diculties
that were encountered are detailed in the evaluations of the individual toolsets.
The most notable inconsistency was the fact that a consistency check run on a sample model
developed to experiment with the use of entity subtypes was successful despite the fact that an
identier had not been included for an entity subtype. This presents a problem when the user
attempts to select an identier for the entity subtype in action block synthesis.
One inconsistency that became apparent in the construction toolset was the fact that changes
made to view mapping in screens were not consistently reected with simply generation and reinstallation of that screen module. It was necessary in one instance to regenerate the entire application
code, despite the fact that the error corrected was identical to that which occurred in another
screen. A user error could not be identied as the reason for this inconsistency.
7 Project Summary
This project developed a case study of the use of an integrated CASE tool, specically the IEF by TI,
for the development of an information system. The development process has been documented to
provide general information on the use of a CASE tool. This documentation details the functionality
of the IEF CASE tool.
The information system selected was the Distributed Project Management Information System
(DPMIS) which was designed to support the tracking of the progress, status and descriptive details of projects spanning multiples sites. This information system was selected because we have
experience with a distributed project and this information system would have been very useful in
that project.
The development of the DPMIS followed the structured methodology embedded in the IEF
CASE tool. The CASE tool and the consistency check feature, in particular, enforce the adherence
of the user to the methodology dened within the CASE tool and, therefore, the order in which
the toolsets are used.
The integration of the toolsets enables the development of the information system to ow easily
from toolset to toolset. The information engineering methodology embedded in the IEF coupled
with the integration of the toolsets, is geared to the team environment where the system under
development would be passed from the planning team to the analysis team, design team and nally
to the construction team. The level of integration of the IEF toolsets make this a clearly feasible
development method. The only drawback that should be mentioned with respect to this is that the
IEF does not enforce the completion of descriptions of many elements of the information system such
as procedures or procedure steps. This information is required by each team as the development
progresses.
This experience was an extremely benecial one and hopefully the documentation of this experience will be of benet to others who are interested in implementing the use of integrated CASE
tools, specically the IEF and also to the CASE tool developers.
35
7.1 Goals
7.1.1 Case Study
The study of development using a CASE tool was completed successfully. A set of tutorials for
possible use in future courses has been developed and documentation of the development process
has been maintained for future reference.
7.1.2 CASE Tool Review
The second goal of this project was to assess the reasons CASE tools have not achieved the level of
acceptance that was initially anticipated. In particular, is the length of the learning curve actually
a problem and if so, why? In addition, are the results achieved from a CASE tool worth the time
investment required?
This project utilized all toolsets of the IEF and the tools in each toolset. Some tools were only
briey reviewed since they were not applicable to the development of the DPMIS. This has been
noted in the discussion of each toolset included in the development section of this paper.
7.2 Evaluation Factors
The evaluation factors and questions raised in the introduction to this document are discussed here
and the questions answered.
7.2.1 Diagramming Capabilities
The diagraming capabilities of the IEF toolsets can only be described as adequate. The objects can
be resized and diagram lines can be redrawn. The methods for developing diagrams are consistent
throughout the toolsets and the methods are simple and easy to learn. The Chain tool which is
available in each of the toolsets enables the user to transfer between levels of a diagram and also
between related diagrams. The printouts produced for diagrams such as the ERD are not of good
quality and this could not be adjusted. The fonts in the diagrams could not be adjusted and no
method of changing headings on diagrams could be found.
7.2.2 Software Engineering Methodologies
The IEF supports one methodology, James Martin's Information Engineering methodology. This
did not present a problem, although experience with other I-CASE tools or further use of the IEF
may provide insight into the benets of supporting multiple methodologies. Certainly this may be
a drawback for users who have already adopted a dierent methodology. The IEF Planning toolset
does not support project management planning. Therefore, it was necessary to develop external
documentation of the project plan.
7.2.3 Consistency Checking
The IEF consistency checks are run both automatically by the CASE tool and at the request of
the user. The level of consistency checks can be specied by the user. The level can be set to
correspond to the appropriate development phase for the project.
36
Only one error that aected future development and was not identied by the consistency check
was found. This error involved a temporary model that was developed to review the use of entity
subtypes in the ERD. An entity subtype was created without dening an identifying attribute.
This omission was allowed to pass consistency checking and presented a problem when Action
Block Synthesis was attempted. There was no identier to select for this entity subtype.
7.2.4 Toolset Integration
The IEF toolsets are completely integrated. The repository is accessible for all the tools in each
toolset. Information entered in the Planning toolset is not all available to the Analysis toolset but
the information that is not available is not required to fully develop the information system. For
example, the OHD is only accessible from the Planning toolset but it is not required to develop
the information system. It was not necessary at any stage of development, to reenter details of the
information system.
7.2.5 Documentation
The reports available in the IEF toolsets provide the essential details required for the information
system. These would prove useful in a team environment. One drawback to the documentation of
the IEF toolsets is that a developer can simply choose not to enter some details such as descriptions of processes and objects. This could present a problem in the team environment since the
omission of this information could result in a misunderstanding by subsequent development teams
or individuals. In addition, some of the descriptions were not printed completely in the reports,
leaving gaps in information. For the most part the documentation identies the report or document, however, diagrams headings could not be altered. In some instances, such as the ERD the
diagram headings were not adequate to identify the diagram. The reports generated by the IEF
do not produce presentation quality information, which necessitates the development of additional
documentation when this type of information is required.
7.2.6 Database Generation
The IEF supports DBM and INGRES. The OS/2 environment supports DBM. No changes were
required in the database tables following generation, therefore, the retransformation facility was
not utilized for essential retransformation of the data model.
7.2.7 Code Construction
The IEF supports the generation of COBOL and C. The source code generated for this project was
C. The code compiled without errors. The source code les generated are very large. Comments
are included automatically by the IEF to aid the user in identifying the purpose of sections of
the code, however, the code itself is dicult to follow. Changes to the code were achieved by
making changes in the action diagrams and regenerating the code. It was not necessary to actually
work in the source code les at all. Code is generated at a rate of approximately 3,000 lines per
minute although this does vary. A sample of code is appended to this document with a copy of
37
the associated action diagram. Changes to the actual source code les were not attempted. The
length and style of the source code made this an unattractive prospect.
7.2.8 Reengineering Support
Reengineering of the ERD was not required. This is supported by the IEF through retransformation.
The changes made to the action diagrams were implemented through regeneration of the code for
the diagrams that were changed. Reengineering of an information system following implementation,
of course, will necessitate the use of the IEF.
7.2.9 Availability of Metrics
Metrics are not available in the IEF CASE tool with the exception of the speed of code production
and the number of lines of code generated for the load modules.
8 Conclusions and Future Work
8.1 Conclusions
CASE technology was developed to facilitate the use of a structured and consistent methodology
for software/systems development. Although CASE tools have achieved some acceptance, the level
of acceptance has not been as high as was anticipated. The primary diculty which has been cited
for the lack of acceptance has been the length of the learning curve. Companies do not see the
increase in productivity that is given as a reason for adopting this technology and in some instances
the tools are abandoned 1, 15]. The goals of this project were to develop a case study for possible
use in future courses and to study the use of an integrated CASE tool. It was anticipated that
this project might provide some insight into the reasons CASE tools have not achieved the level of
acceptance that was initially expected.
A case study using the IEF CASE tool has been completed. Tutorials have been developed which
can provide assistance to future users of the IEF. The case study coupled with these tutorials will
ll in some of the gaps present in the documentation available for the IEF CASE tool.
The learning curve for the IEF was long. If the length of time for development were the only
concern, in comparison to the development of the same information system without the use of a
CASE tool the time involved in developing the DPMIS with the CASE tool would be prohibitive.
The stumbling block in learning, however, was consistently the lack of adequate documentation.
In particular, the Help facility of the IEF as well as the manuals do not provide enough background
explanation of the item for which the user has requested help. The manuals and the Help facility
provide, for most selections, detailed \how-to" instructions which help the user learn to perform
a task. What is missing are details of the \downstream eects" of some development activities or
items.
There were also omissions from the manuals and/or Help facility that resulted in delays in
development. While the omissions did result in delays it was the lack of adequate background
information that resulted in greater delays. The help for this type of tool which is designed to be
used by software/systems developers should perhaps concentrate more on explaining the concepts
38
and \downstream eects" of development activities then the \how-to" explanations that are quite
detailed overall.
These diculties are the reasons that were identied for the feelings of frustration and the length
of the learning curve. The toolsets were easy to use and well integrated. Essential details of the
information system were accessible throughout the tools and toolsets of the IEF. The diagraming
capabilities of the IEF do not match those of Upper CASE tools if presentation quality diagrams is
what the user requires. The level of integration and the construction capabilities of the IEF make
up for this deciency.
The remaining question raised in the goals of this project can be answered positively. Yes, the
learning curve is worth the eort. There are certainly problems present in the IEF and lack of
support for some aspects of the development life cycle. There are good features as well. The IEF
CASE tool enforces the methodology it supports and features such as the Consistency Check aid
the user in avoiding errors in the ISP, BAA and BSD/TD phases of development.
The most frequently asked question that was encountered while working on this project was,
\What is the code like that it generates?" People appear very skeptical which coincides with
what the literature states. Certainly the code is not well commented or easy to follow but with
the testing facilities in the IEF the debugging is done at the action diagram level. Further work,
specically with the source code generated would be required to fully answer the question. Since
action diagrams are roughly equivalent to algorithms they are actually easier to follow than trying
to interpret another individual's code. Once the user is familiar with the style of the \algorithms"
developed in the IEF the style of the code seems less signicant, however, this would necessitate
the use of the IEF for future maintenance of the DPMIS.
8.2 Future Work
The plan for future work is to repeat the development of the DPMIS using a dierent integrated
CASE tool and perform a comparison of the tools. It would also be benecial to use the IEF
in a team environment to assess its eectiveness for that environment. The team size would be
dependent on the information system project undertaken.
The reengineering capabilities of the IEF were not adequately tested. It would be worthwhile
to implement changes in the DPMIS using the IEF to assess these capabilities. It would also be
benecial to attempt to implement some changes directly to the C source code produced.
Additional experience with this tool would provide evidence that it is worth the time investment
to learn the use of a CASE tool. It would also be interesting also to have a new user learn the
IEF using the OS/2 version. This would provide the opportunity to completely develop small
sections of an information system and rapidly develop these through the IEF toolsets including the
Construction toolset.
Acknowledgments
We would like to thank Doug Jones and Cathy Parkinson of Supply and Services Canada, Baiba
St. John, Brett Martensen and Bernie Hodson of the Federal Institute for Informatics, and Palle
Johnson of Texas Instruments Canada Limited for their cooperations during this project.
39
References
1] Yourdon, E., Decline & Fall of the American Programmer, Yourdon Press, PTR Prentice Hall,
Englewood Clis, NJ, 1992.
2] Texas Instruments, A Guide to Information Engineering Using the IEF: Computer-Aided Planning, Analysis and Design, TI 2739756-0001, 2nd Edition, January 1990.
3] Texas Instruments, IEF Technical Description, Methodology and Technology Overview, TI
2739900-8120 August 1992, Texas Instruments.
4] Texas Instruments, IEF Basics (Information Engineering Facility, TI 2739759-0001, December
1989, Texas Instruments.
5] Texas Instruments, IEF Planning Toolset Guide, TI 2739753-0001-V41A, 2nd Edition, December, 1989, Update August 1990.
6] Texas Instruments, IEF Analysis Toolset Guide, TI 2739751-0001-V41A, 4th Edition, December 1989, Update August 1990.
7] Texas Instruments, IEF Design Toolset Guide, TI 2739751-0001-V41A, 4th Edition, December
1989, Update August 1990.
8] Texas Instruments, IEF Construction Toolset Guide, TI 2739780-0001, 1st Edition, August
1990.
9] Texas Instruments, Workstation Construction, TI 2578279-0001, 2nd Edition, December 1991.
10] Slonim, J., Bauer, M., et al., Towards a New Distributed Programming Environment, Proc. of
the 1991 CAS Conference, Toronto, Canada, October 1991.
11] Texas Instruments, Rapid Development Using the IEF, TI 2739779-0002, 2nd Edition, July
1991.
12] Texas Instruments, IEF Development Tutorial, TI 2739776-0002, 2nd Edition, July 1991.
13] Martin, J., Information Engineering, Vols. 1-3, Englewood Clis, NJ: Prentice Hall, 1990.
14] Pressman, R., Software Engineering: A Practitioner's Approach 3rd Edition, McGraw-Hill,
Inc. 1992.
15] McGrath, F., \Checklist for Buyers of ICASE Products", IEEE Software, November 1993.
16] Norman, R.J. and M. Chen, \Working Together to Integrate CASE", IEEE Software, March
1992.
17] IEEE IEEE Standard for Systems Project Management Plans, Std. P1058, unapproved nal
draft, September 1986.
18] Harmon, P., \Texas Instruments' Information Engineering Facility: A Brief History of CASE"
American Programmer, Vol. 6, No.9.
40
APPENDICES
41
A Distributed Project Management Information System
A.1 Introduction
A.1.1 Objective
The Distributed Project Management Information System (DPMIS) will support the tracking of
the progress, status and descriptive details of projects spanning multiple sites, including:
Denition of Projects which span multiple sites.
Denition of Projects which are local to sites.
Permit the creation, update and deletion of Projects by Project Leaders.
Permit any Project Member to Browse and/or Retrieve information about any Project or
related entities.
A.1.2 Information System
The information system will consist of two (initial) components:
Update/Create Tool
Retrieval/Browse Tool
Each tool would run local to a Site. The Update/Create Tool would update a local database (or
designate) while the Retrieval/Browse Tool would permit information to be collected from the
multiple databases.
A.1.3 Rationale
The information system oers a number of attractions:
We have experience with a distributed project, namely CORDS, which can provide a set of
needs and for which such an information system would have been very useful.
It oers local update and yet requires a browsing capability which entails multi-database
queries.
Interfaces for the two tools should be kept simple.
It is easy to explain the scenario and need for such an information system to non-technical
users (e.g. managers and executives).
It is easy to dene additional tools for generating reports, extracting data for PERT or Gantt
Charts, for extracting e-mail lists, etc.
42
A.2 Denition of Information System
The information system requires:
1. Identication of the information to be kept about projects, i.e., entities, attributes and relationships.
2. Identication of the functionality of each tool.
Update/Create Tool (Information Maintenance)
Retrieval/Browse Tool (Information Retrieval)
The DPMIS will provide the user with the option to select either the Update/Create Tool or
the Retrieval/Browse Tool and, of course, the option to exit the DPMIS.
A.2.1 Update/Create Tool (Information Maintenance)
The Update/Create Tool will allow the creation, update and deletion of all entities described
in the section \Entities, Attributes and Relationships". Selection of the Update/Create Tool
will then allow the further specic selection of the type of entity to be maintained followed by
the selection of the option to Create, Update or Delete. Access to the database will be controlled
through the maintenance of the current Member information.
A.2.1.1 Create
The creation of Projects and related entities will only be allowed by those Members identied as
Project Leaders. The user's name will be checked against the current Members in the database to
determine both if the user is a Member and if they are authorized to create the requested entity as
in the case of Projects. If the user is authorized for this function the user will then be prompted
for the necessary mandatory and optional information to enter the specied entity in the database.
Failure to satisfy the authorization requirements or failure to enter mandatory information will
terminate access.
Sites and Projects are the only entities that can be created without a parent Project. Selection
of the option to create any other entities will result in the display of a list of current Projects for
user selection. The user will not be allowed to continue in creation without rst selecting a parent
Project.
A.2.1.2 Update
The Project Leader is the only Member authorized to update current Projects, Sites, Members and
Milestones. Members who are responsible for a specic Deliverable or Document will be authorized
to update these entities. As in the create function the user will be required to select the specic
Project related to the entity selected for update. As stated above the selection to update the
information regarding Sites will not result in the display of a list of current Projects since Sites
may exist without current Projects.
43
A.2.1.3 Delete
The deletion of Projects and related entities will also be allowed only by Project Leaders. As in
the create and update functions the user will be required to select the specic Project related to
the entity selected for deletion.
A.2.2 Retrieval/Browse Tool
Access to the Retrieval/Browse Tool will be restricted only to current Members of all Projects. It
will allow Members to retrieve information regarding all current Projects and the related entities.
Information included for each entity type, eg. Member, will not be of a sensitive or condential
nature, therefore, the only security required is to conrm that the user is a current Member in the
database. Information retrieval will be allowed, by each of the entities described in the section,
\Entities, Attributes and Relationships" (Project, Site, Member, Milestone, Deliverable and Document). Examples of retrieval requirements are outlined below and will be detailed further as the
project progresses.
A.2.2.1 Project
Retrieve attribute information for a specic Project by Project Name.
Retrieve a list of all Projects by a specic attribute value, eg. Status = on-time or a relationship IS RELATED TO Project.
Retrieve a list of all related entities, eg. Milestones where the relationship IS PROJECT MILESTONE
is satised for this Project. The user will then be allowed to select a specic Milestone and
retrieve information regarding this specic Milestone.
A.2.2.2 Site
Retrieve attribute information regarding a specic Site.
Retrieve a list of all Sites by a specic attribute value, eg. City = London or relationship
HAS PROJECT.
Retrieve list of related entities, eg. all Members who have PRIMARY AFFILIATION WITH
the Site.
The user then will be allowed to select a specic Member and retrieve information regarding
this related entity.
A.2.2.3 Member
Retrieve attribute information regarding a specic Member.
Retrieve a list of all Members by a specic attribute value, eg. Project Leader or relationship
ALSO WORKS AT Site.
44
Retrieve a list of related entities, eg. all Deliverables the specic Member IS RESPONSIBLE FOR.
The user then will be allowed to select a specic Deliverable and retrieve information regarding
this related entity.
A.2.2.4 Milestone
Retrieve attribute information regarding a specic Milestone.
Retrieve a list of all Milestones by a specic attribute value, eg. Type = Deliverable or
relationship IS PROJECT MILESTONE.
Retrieve related entity, eg. Deliverable this Milestone represents. The user then will be
allowed to retrieve information regarding this related entity.
A.2.2.5 Deliverable
Retrieve attribute information regarding a specic Deliverable.
Retrieve a list of Deliverables by a specic attribute, eg. Expected Delivery Date or relationship IS DOCUMENT.
Retrieve a list of related entities, eg. Members who are working on this Document. The
user then will be allowed to select a specic Member and retrieve information regarding this
related entity.
A.2.2.6 Document
Retrieve attribute information regarding a specic Document.
Retrieve a list of Documents by a specic attribute, eg. Type = Project Report or relationship
DESCRIBES Project.
Retrieve related entity, eg. Deliverable this Document represents. The user is then allowed
to retrieve information regarding this specic Deliverable.
A.2.3 Entities, Attributes and Relationships
Mandatory attributes and relationships will be displayed in bold print and mandatory relationships
will be described as \Always" present.
A.2.3.1 Project
Projects are research projects being conducted by organizations at various Sites in Canada, the
United States and Europe. Projects will be identied in the Information System by the following
attributes and the following relationships will apply.
45
Attributes
Project Name (identifying attribute)
Description (max length allowed 254 characters)
Start Date
Completion Date
Status (Values: on-time, suspended, behind, completed) (Default value: on-time)
Relationships
Always HAS MEMBER (one or more) Member.
Always HAS MILESTONE (one or more) Milestone.
Always HAS DELIVERABLES (one or more) Deliverables.
Always IS AT PRIMARY (one) Site.
Always IS AT (one or more) Site.
Sometimes IS COORDINATED BY (one or more) Member.
Sometimes IS DESCRIBED BY DOCUMENT (one or more) Document.
Sometimes HAS RELATION TO (one or more) Project.
Sometimes IS RELATED TO (one or more) Project.
The estimated number of projects monitored by the DPMIS is as follows:
Minimum 1
Average 10
Maximum 99
The estimated growth rate of number of projects is ve percent per year.
A.2.3.2 Site
Sites are organizations in Canada, the United States and Europe where Projects are undertaken.
Sites can be maintained on the database without currently running Projects. Sites will be identied
in the Information System by the following attributes and the following relationships will apply.
46
Attributes
Organization (identifying attribute)
Internet Address
FTP Address
Street Address
City
Province State
Country
Postal ZIP Code
Relationships
Sometimes IS PRIMARY AFFILIATION FOR (one or more) Member.
Sometimes HAS MEMBER (one or more) Member.
Sometimes CAN FTP DOCUMENT (one or more) Document.
Sometimes IS PRIMARY LOCATION FOR (one or more) Project.
Sometimes HAS PROJECT (one or more) Project.
Sometimes HAS CONTACT (one) Member.
The estimated number of Sites to be monitored by the DPMIS is as follows:
Minimum 1
Average 5
Maximum 10
The estimated growth rate of Sites is ve percent per year.
A.2.3.3 Member
Members are sta, students and faculty at the Sites who are currently involved with Projects which
are being monitored using the DPMIS. Members will be identied in the Information System by
the following attributes and the following relationships will apply.
47
Attributes
Surname (identifying attribute)
First Name (identifying attribute)
Email
Telephone
Fax
Project Position (Values: Programmer, Postdoc, Researcher, Professor, Student and Other)
(Default value: Researcher)
Job Type (Values: Project Leader, Sta) (Default value: Sta)
Relationships
Always HAS PRIMARY AFFILIATION WITH (one) Site.
Sometimes IS MEMBER OF PROJECT (one or more) Project.
Sometimes ALSO WORKS AT (one or more) Site.
Sometimes WORKS ON (one or more) Deliverable.
Sometimes IS CONTACT FOR (one) Site.
Sometimes IS PRINCIPAL AUTHOR (one or more) Document.
Sometimes IS AUTHOR OF (one or more) Document.
Sometimes COORDINATES PROJECT (one) Project.
Sometimes IS RESPONSIBLE FOR (one or more) Deliverable.
Sometimes IS SUPERVISED BY (one) Member.
Sometimes SUPERVISES (one or more) Member.
Sometimes IS MANAGED BY (one) Member.
Sometimes MANAGES (one or more) Member.
The estimated number of Members to be monitored by the DPMIS is as follows:
Minimum 1
Average 30
Maximum 99
The estimated growth rate of Members is three percent per year and the estimated rate of change
of Members is ve percent per year.
48
A.2.3.4 Milestone
Milestones representing signicant development events exist for each Project. Milestones will be
identied in the Information System by the following attributes and the following relationships will
apply.
Attributes
Name (identifying attribute)
Expected Delivery Date
Actual Delivery Date
Type (Values: Hiring, Documentation, Demonstration, Meeting, Deliverable and Other)
Description (max length allowed 254 characters)
Relationships
Always IS MILESTONE OF PROJECT (one) Project.
Sometimes IS DELIVERABLE (one) Deliverable.
Sometimes IS A DOCUMENT (one) Document.
The estimated number of Milestones per Project to be monitored by the DPMIS is as follows:
Minimum 1
Average 30
Maximum 99
The estimated growth rate of number of Milestones is two percent per year.
A.2.3.5 Deliverable
Deliverables representing specic Documents, Prototypes and Presentations and their respective
delivery dates exist for each Project. Deliverables will be identied in the Information System by
the following attributes and the following relationships will apply.
Attributes
Name (identifying attribute)
Expected Delivery Date
Actual Delivery Date
49
Description (max length 254 characters)
Comments (max length 254 characters)
Type (Values: Document, Prototype, Presentation)
Relationship
Always IS MILESTONE (one) Milestone.
Always IS WORKED ON BY (one or more) Member.
Always IS RESPONSIBILITY OF (one or more) Member.
Always IS DELIVERABLE OF (one) Project.
Sometimes DEPENDS ON (one or more) Deliverable.
Sometimes ESSENTIAL FOR (one or more) Deliverable.
Sometimes IS DOCUMENT (one) Document.
The estimated number of Deliverables per Project which will be monitored by the DPMIS is as
follows:
Minimum 1
Average 6
Maximum 99
The estimated growth rate of number of Deliverables is one to two percent per year, although it is
very likely that this number will remain static.
A.2.3.6 Document
Documents will represent information about the current Projects. Documents will be identied in
the Information System by the following attributes and the following relationships will apply.
Attributes
Title (identifying attribute)
Creation Date
Abstract (max length 254 characters)
Keywords (1 through 5)
Keywords (6 through 10)
Type (Values: Project Report, Component Documentation, Journal Publication, Conference
Publication, Working Paper, Technical Report, Minutes, Proposal, Manual) (Default value:
Project Report)
50
Relationships
Always HAS PRINCIPAL AUTHOR (one) Member.
Always IS AUTHORED BY (one or more) Member.
Always DESCRIBES PROJECT (one) Project.
Sometimes CAN BE FTPD FROM (one) Site.
Sometimes IS DELIVERABLE (one) Deliverable.
Sometimes IS MILESTONE (one) Milestone.
The estimated number of Documents per Project monitored by the DPMIS is as follows:
Minimum 1
Average 100
Maximum 1000
The estimated growth rate of number of Documents is one percent per year.
51
B IEF-Generated Entity Type Denition Report
Model : DISTRIBUTED PROJECT MANAGEMENT
Subset: ALL
Jun. 06, 1994
09:18
page 1
Entity Definition
__________________________________________________________________________
Entity:
DELIVERABLE
Description:
Deliverables represent specific Documents, Prototypes
and Presentations and their respective delivery dates
for Projects and must exist for each Project.
Each
Deliverable will also be a Milestone in the Project and
all Deliverables will have a Member who is responsible
for the Deliverable. The responsible Member will be
authorized to update Deliverable information.
Subject area:
DISTRIBUTED_PROJECT_MANAGEMENT
Properties:
Min Occ:
Max Occ:
Attributes:
TYPE
DELIVERABLE_NAME
EXPECTED_DELIVERY_DATE
ACTUAL_DELIVERY_DATE
DESCRIPTION
COMMENTS
1 Avg Occ:
1000 Growth Rate:
Relationships:
Always IS_RESPONSIBILITY_OF one MEMBER
can transfer.
Always IS_WORKED_ON_BY many MEMBER
Cardinality Min: 1 (est) Max: 5 (est) Avg: 3
cannot transfer.
Sometimes (50%) ESSENTIAL_FOR many DELIVERABLE
Cardinality Min: 0 (est) Max: 5 (est) Avg: 2
cannot transfer.
Sometimes (50%) DEPENDS_ON many DELIVERABLE
Cardinality Min: 0 (est) Max: 5 (est) Avg: 1
cannot transfer.
Always IS_MILESTONE one MILESTONE
52
60
2% per year
can transfer.
Sometimes (95%) IS_DOCUMENT one DOCUMENT
can transfer.
Always IS_DELIVERABLE_OF one PROJECT
can transfer.
Identifiers:
NAME (Primary)
DELIVERABLE_NAME
Entity:
DOCUMENT
Description:
Documents represent descriptive information about
Projects and range in type from Minutes of meetings to
Journal Publications. Documents must be authored by a
Member and must always describe a Project.
Subject area:
DISTRIBUTED_PROJECT_MANAGEMENT
Properties:
Min Occ:
Max Occ:
Attributes:
TITLE
DATE
ABSTRACT
TYPE
KEYWORD_1
KEYWORD_2
KEYWORD_3
KEYWORD_4
KEYWORD_5
KEYWORD_6
KEYWORD_7
KEYWORD_8
KEYWORD_9
KEYWORD_10
1 Avg Occ:
5000 Growth Rate:
1000
1% per year
Relationships:
Always HAS_PRINCIPAL_AUTHOR one MEMBER
can transfer.
Always IS_AUTHORED_BY many MEMBER
Cardinality Min: 1 (est) Max: 5 (est) Avg: 2
cannot transfer.
53
Sometimes (95%) IS_DELIVERABLE one DELIVERABLE
can transfer.
Sometimes (95%) DOCUMENT_CAN_BE_FTPD_FROM one SITE
can transfer.
Sometimes (75%) IS_MILESTONE one MILESTONE
can transfer.
Always DESCRIBES_PROJECT one PROJECT
can transfer.
Identifiers:
TITLE (Primary)
TITLE
Entity:
MEMBER
Description:
Members are staff, students and faculty working at
Sites on Projects. Members must have an affiliation
with a current Site to be included in the DPMIS
database, however, it is not necessary for each Member
to be currently assigned to a Project.
Subject area:
DISTRIBUTED_PROJECT_MANAGEMENT
Properties:
Min Occ:
Max Occ:
Attributes:
PASSWORD
SURNAME
FIRST_NAME
PROJECT_POSITION
EMAIL
TELEPHONE
FAX
JOB_TYPE
1 Avg Occ:
1000 Growth Rate:
300
3% per year
Relationships:
Sometimes (25%) IS_CONTACT_FOR one SITE
can transfer.
Sometimes (25%) IS_PRINCIPAL_AUTHOR one DOCUMENT
cannot transfer.
Sometimes (50%) IS_RESPONSIBLE_FOR many DELIVERABLE
Cardinality Min: 1 (est) Max: 5 (est) Avg: 3
cannot transfer.
Sometimes (50%) IS_MEMBER_OF_PROJECT many PROJECT
54
Cardinality Min: 1 (est) Max: 3 (est) Avg: 2
cannot transfer.
Always HAS_PRIMARY_AFFILIATION_WITH one SITE
can transfer.
Sometimes (25%) ALSO_WORKS_AT many SITE
Cardinality Min: 1 (est) Max: 3 (est) Avg: 2
cannot transfer.
Sometimes (25%) WORKS_ON many DELIVERABLE
Cardinality Min: 1 (est) Max: 5 (est) Avg: 3
cannot transfer.
Sometimes (25%) IS_AUTHOR_OF many DOCUMENT
Cardinality Min: 1 (est) Max: 5 (est) Avg: 2
cannot transfer.
Sometimes (25%) COORDINATES_PROJECT one PROJECT
can transfer.
Sometimes (25%) IS_SUPERVISED_BY one MEMBER
can transfer.
Sometimes (50%) SUPERVISES many MEMBER
Cardinality Min: 1 (est) Max: 5 (est) Avg: 2
cannot transfer.
Sometimes (75%) IS_MANAGED_BY one MEMBER
can transfer.
Sometimes (25%) MANAGES many MEMBER
Cardinality Min: 1 (est) Max: 99 (est) Avg: 30
cannot transfer.
Identifiers:
NAME
FIRST_NAME
SURNAME
SURNAME (Primary)
SURNAME
Entity:
MILESTONE
Description:
Milestones represent significant development events for
a Project and must exist for each Project.
Update of
Milestones will be the responsibililty of the Project
Leader.
Subject area:
DISTRIBUTED_PROJECT_MANAGEMENT
55
Properties:
Min Occ:
Max Occ:
1 Avg Occ:
99 Growth Rate:
Attributes:
MILESTONE_NAME
EXPECTED_DELIVERY_DATE
ACTUAL_DELIVERY_DATE
TYPE
DESCRIPTION
30
2% per year
Relationships:
Sometimes (95%) IS_DELIVERABLE one DELIVERABLE
can transfer.
Sometimes (70%) IS_A_DOCUMENT one DOCUMENT
can transfer.
Always IS_MILESTONE_OF_PROJECT one PROJECT
can transfer.
Identifiers:
NAME (Primary)
MILESTONE_NAME
Entity:
PROJECT
Description:
Projects are research projects being conducted by
organizations at various Sites in Canada, the United
States and Europe.
Projects will require mandatory
relationships with Member, Site, Milestone and
Deliverable entities. Project Leaders will be assigned
and they will be responsible for the creation, update
and deletion of Projects.
Subject area:
DISTRIBUTED_PROJECT_MANAGEMENT
Properties:
Min Occ:
Max Occ:
Attributes:
START_DATE
PROJECT_NAME
COMPLETION_DATE
STATUS
DESCRIPTION
1 Avg Occ:
99 Growth Rate:
Relationships:
Always IS_AT_PRIMARY one SITE
56
10
5% per year
can transfer.
Always IS_AT many SITE
Cardinality Min: 1 (est) Max: 3 (est) Avg: 2
cannot transfer.
Always HAS_MEMBER many MEMBER
Cardinality Min: 1 (est) Max: 99 (est) Avg: 10
cannot transfer.
Sometimes (95%) IS_COORDINATED_BY one MEMBER
can transfer.
Sometimes (10%) HAS_RELATION_TO many PROJECT
Cardinality Min: 0 (est) Max: 5 (est) Avg: 1
cannot transfer.
Sometimes (10%) IS_RELATED_TO one PROJECT
can transfer.
Always HAS_MILESTONE many MILESTONE
Cardinality Min: 1 (est) Max: 99 (est) Avg: 30
cannot transfer.
Sometimes (95%) IS_DESCRIBED_BY_DOCUMENT many DOCUMENT
Cardinality Min: 1 (est) Max: 100 (est) Avg: 100
cannot transfer.
Always HAS_DELIVERABLES many DELIVERABLE
Cardinality Min: 1 (est) Max: 99 (est) Avg: 6
cannot transfer.
Identifiers:
NAME (Primary)
PROJECT_NAME
Entity:
SITE
Description:
Sites are specific organizations such as the University
of Western Ontario and will be identified by the
organization name.
Projects will be conducted at
Sites, however, Sites may exist in the DPMIS database
without any relationships to Projects, Members, etc.
Subject area:
DISTRIBUTED_PROJECT_MANAGEMENT
Properties:
Min Occ:
Max Occ:
Attributes:
INTERNET_ADDRESS
1 Avg Occ:
99 Growth Rate:
57
5
5% per year
FTP_ADDRESS
ORGANIZATION
STREET_ADDRESS
CITY
PROVINCE_STATE
COUNTRY
POSTAL_ZIP_CODE
Relationships:
Sometimes (95%) HAS_CONTACT one MEMBER
can transfer.
Sometimes (95%) IS_PRIMARY_LOCATION_FOR many PROJECT
Cardinality Min: 1 (est) Max: 3 (est) Avg: 2
cannot transfer.
Sometimes (95%) HAS_PROJECT many PROJECT
Cardinality Min: 1 (est) Max: 5 (est) Avg: 2
cannot transfer.
Sometimes (95%) IS_PRIMARY_AFFILIATION_FOR many MEMBER
Cardinality Min: 1 (est) Max: 99 (est) Avg: 30
cannot transfer.
Sometimes (95%) HAS_MEMBER many MEMBER
Cardinality Min: 1 (est) Max: 20 (est) Avg: 6
cannot transfer.
Sometimes (95%) CAN_FTP_DOCUMENT many DOCUMENT
Cardinality Min: 1 (est) Max: 10 (est) Avg: 5
cannot transfer.
Identifiers:
ORGANIZ (Primary)
ORGANIZATION
-End of Report-
58
C A Sample IEF-Generated C Code
*
*
Source Code Generated by
*
Information Engineering Facility (tm)
*
Texas Instruments Inc.
*
Copyright (c) Texas Instruments, Inc. 1994
*
*
Target OS: OS2
DBMS: DBM
*
*
Module Name: RETRIEVS
Date: 94/02/19
*
Time: 17:43:48
*
*
Screen: RETRIEVAL_MENU
*
*
*
*
Environment: IEFAE / BYPASS
*
*
*
TIRXXX FUNCTIONS CALLED
*
TIRIBUF = identify input message
*
TIROBUF = open an output buffer
*
TIRCBUF = close an output buffer
*
TIREDI = extract data from an edited field
*
TIREDO = edit data into a displayable field
*
TIRGFLD = find a field in the input stream
*
TIRPFLD = add a field to the output stream
*
including attribute processing
*
TIRPBUF = write a buffer to the screen or printer
*
**************************************************************/
#include <string.h>
#include <ctype.h>
#include <stdio.h>
#include <stdlib.h>
typedef int Boolean
#ifndef FALSE
#define FALSE 0
#endif
59
#ifndef TRUE
#define TRUE 1
#endif
#define CMD_LEN 8
/**********************************************************************
Data Declarations
*********************************************************************/
static char * ti_copyright = "Copyright(c) Texas Instruments Inc. 1994"
static char * module_name = "RETRIEVS"
static char * mp_version = "5.0.A1"
char * ief_runtime_parm1
char * ief_runtime_parm2
char * environment_list
struct al
{
char dm_version8]
char curr_lmod8]
short max_seg_line
char for_mod_input_sw
#define FOR_MOD_INPUT 'Y'
/* This message is the result of MFS FOR modname input */
char unformatted_data_sw
#define UNFORMATTED_DATA 'Y'
/* Clear screen with input other than trancode and
not known-dialog-action
*/
char clr_scr_sw
#define CLR_SCREEN 'Y'
/* Non-formatted screen input */
char msg_got_sw
#define MSG_GOT 'Y'
#define NO_MSG_GOT 'N'
char help_request_sw
#define HELP_REQUESTED_HELP 'H'
#define HELP_REQUESTED_PROMPT 'P'
#define HELP_RESTART_DISP 'D'
#define HELP_RESTART_EXEC 'E'
60
char restartable_flag
#define RESTARTABLE_APPLICATION 'Y'
/* A restartable application always updates the profile
A non-restartable application updates the profile
only when necessary to support links or when screen
output requires the profile
*/
char screen_profile_flag
#define SCREEN_REQUIRES_PROFILE 'Y'
/* Screen requires profile support if it contains
DM hidden or scrollable repeating group views
mapped to import views.
If not SCREEN-REQUIRES-PROFILE and not
RESTARTABLE-APLLICATION output each data field with
a preset modified data tag.
*/
char screen_return_loc
#define SCREEN_DFLT_TOP 'T'
/* Upon return form link, redisplay repeating groups
starting with top(1st) occurance.
*/
char scrolling_amt_sw
#define SCROLL_PAGE 'P'
#define SCROLL_HALF 'H'
#define SCROLL_CURSOR 'C'
#define SCROLL_LOC 'L'
#define SCROLL_MAX 'M'
#define INVALID_SCROLL_AMT 'I'
/* The following values are known values for scroll_amount_set
and scroll_num. If the keyword scroll_amount_set or scroll_num
is used in the procedural logic a function by the same name
will be generated to test the true or false condition similiar
to COBOL 88 levels.
scroll_amt_set values 'P','H','C',
'L','M','I',
'0' THRU '9'.
scroll_num
value '0' THRU '9'
*/
char scrolling_control
#define SCREEN_UPDT_PAST_DISPLAY 'Y'
char cics_xctl_sw
#define CICS_XCTL_FLOW 'Y'
char cics_handle_sw
#define CICS_HANDLE_ABEND 'Y'
char cics_conv_sw
#define CICS_PSEUDO_CONV 'Y'
char set_all_mdts_on_sw
#define SET_ALL_MDTS_ON 'Y'
61
}
bf NOTE: A large portion of this code has been removed to conserve space since the original
code is approximately 95 pages long.
static struct al * application_list
struct scmgr
{
char scmgr_request8]
#define SCMGR_ROLB "ROLB
"
#define SCMGR_SWITCH "SWITCH "
#define SCMGR_IDENTIFY_MAP "IMAP
"
#define SCMGR_PARSE_MAP "PMAP
"
#define SCMGR_PARSE_UNFORMATTED_INPUT "PUNFINP "
#define SCMGR_GET_MSG "GURB
"
#define SCMGR_HELP_REQUEST "HELP
"
#define SCMGR_PROMPT_REQUEST "PROMPT "
#define SCMGR_HELP_RESTART_D "$#HRSD#$"
#define SCMGR_HELP_RESTART_E "$#HRSE#$"
#define SCMGR_INPUT_TO_OUTPUT "MAPITOO "
#define SCMGR_OUTPUT_TO_INPUT "MAPOTOI "
#define SCMGR_OUTPUT_SCREEN "ISBP
"
#define SCMGR_OUTPUT_PRINTER "IPBP
"
#define SCMGR_VERIFY_SCREEN "VERSCRN "
#define SCMGR_GET_SCREEN_PROPS "GETSCRNP"
char scmgr_return_code2]
#define SCMGR_OK " "
#define SCMGR_NO_MSG "QC"
#define SCMGR_VERERR "ZW"
#define SCMGR_EDIT_INVALID "ZE"
#define SCMGR_UNFERR "ZU"
#define SCMGR_WARNINGS_ZW "ZW"
#define SCMGR_WARNINGS_ZE "ZE"
#define SCMGR_WARNINGS_ZU "ZU"
#define SCMGR_SWITCH_FAILED "SF"
#define SCMGR_TERM_WITHOUT_HELP_MSG "NM"
/* Dialog manager will terminate without redisplay
of screen assuming tirhelp handled help display. */
#define SCMGR_TERM_WITH_HELP_MSG "WM"
/* Dialog manager will redisplay screen with
tirhelp message and terminate normally.
*/
62
static Boolean scroll_num()
{
Boolean rc = FALSE
int
i
for (i = 0 i < SCRLNUM_TBL i++)
{
if (application_list->scrolling_amt_sw == scrolling_numberi])
{
rc = TRUE
break
}
}
return rc
}
static Boolean comparetospaces(s, l)
char * s
int
l
{
Boolean rc = TRUE
int
i
for ( i = 0 i < l i++)
{
if (si] != ' ')
{
rc = FALSE
break
}
}
return rc
}
static int natoi (astr, n)
char *astr
int n
{
int result
char tmp1
63
char tmp2
char *s_end
char negative = 0
/*** make zero terminated string ***/
s_end = astr + n
tmp1 = *(s_end - 1)
tmp2 = *s_end
*s_end = '\0'
/* character at end of field */
/* make zero terminated string */
/*** save sign from last byte of field ***/
if (*(s_end-1) & 0x40)
{
*(s_end-1) &= 0x3f
/* clear sign bit */
negative = 1
}
/*** convert to integer ***/
result = atoi (astr)
*(s_end - 1) = tmp1
*s_end = tmp2
/* convert */
/* restore character containing sign */
/* restore character following field */
/*** make negative if minus was indicated ***/
if (negative)
result = -result
return (result)
}
static long natol (astr, n)
char *astr
int n
{
long
char
char
char
char
result
tmp1
tmp2
*s_end
negative = 0
/*** make zero terminated string ***/
64
s_end = astr + n
tmp1 = *(s_end - 1)
tmp2 = *s_end
*s_end = '\0'
/* character at end of field */
/* make zero terminated string */
/*** save sign from last byte of field ***/
if (*(s_end-1) & 0x40)
{
*(s_end-1) &= 0x3f
/* clear sign bit */
negative = 1
}
/*** convert to integer ***/
result = atol (astr)
*(s_end - 1) = tmp1
*s_end = tmp2
/* convert */
/* restore character containing sign */
/* restore character following field */
/*** make negative if minus was indicated ***/
if (negative)
result = -result
return (result)
}
* application_list
struct scmgr
{
tmp2 = *s_end
/*** save sign from last byte of field ***/
{
*(s_end-1) &= 0x3f
negative = 1
/* clear sign bit */
}
65
D Evaluation of the IEF Toolsets
This appendix contains the evaluation of the four IEF toolsets.
D.1 The IEF Planning Toolset
The Planning Toolset of Texas Instruments' (TI) Information Engineering Facility (IEF) Version
5.1 was used to initiate development of the Distributed Project Management Information System
(DPMIS).2 In addition, to the development of this system other partial IEF planning models were
developed to facilitate review of the Toolset.
The following sections of this document will describe the good features, poor features and inconsistencies encountered in the use of the IEF Planning Toolset. These will be described separately
for each diagraming facility utilized.
D.1.1 IEF Organizational Hierarchy Diagram (OHD)
The Distributed Project Management Information System does not necessitate the development
of an OHD, therefore, as an experiment in the use of this facility the organizational chart for the
University of Western Ontario was reproduced. The OHD proved to be a simple task using the
IEF facility.
Good Features
Multiple Additions (adds) to the OHD
Once a root (parent) has been selected to add subordinates to, the addition of multiple subordinates
is a simple matter of entering the new departments name and pressing enter. The Multiple Adds
option can be easily selected from the Options menu in the IEF.
Chaining of OHD
Chaining in IEF allows you to select a root in the diagram, either the OHD root or a root of a
subtree and chain to that portion of the organizational hierarchy in order to view just that section
of the diagram. The section presented on the screen includes the title of the organizational unit
chained from. This is useful when the OHD becomes too large to view the entire diagram in one
screen.
Redraw of OHD
Selecting the option to redraw the OHD allows you to select the size of the boxes and style of the
tree (vertical, indented or horizontal). This enables you to display the OHD in a style that will
display more of the OHD.
The individual responsible for the use of the IEF CASE tool and author of this document has no formal training
in the use of the IEF. Please see the Reference Material section included in this document for a list of manuals and
documentation which are being used to assist in the use of the IEF.
2
66
Poor Features
Chaining of OHD
It is not possible to display dierent chained sections of the OHD in dierent windows at the same
time.
Length of Names for Organizational Units
The names allowed in the IEF OHD facility are limited to 32 characters in length. This can present
a problem in large organizations such as the University of Western Ontario where names may be
similar and therefore lengthy in order to distinguish organizational units.
Redraw of OHD
The drawback to this option in the IEF is that you cannot redraw just a section of the OHD, even
when you have chained to a subtree of the OHD. IEF will allow you to redraw that section but once
you return to the full OHD the diagram is displayed in the style selected in the root diagram. The
OHD facility is not exible in how it will allow the user to design the diagram layout.
Subordinates with Two Parents
The OHD facility in IEF will not allow a subordinate organizational unit in the OHD to have a link
to more than one parent. It is possible to achieve<eve a representation of this instance by chaining
from the parents and entering a subordinate with slightly dierent names in the chained section for
each root. IEF will not allow you to enter the same name twice in an OHD. The chained subtrees
can then be printed separately to demonstrate the joint custody, however, it is not possible to
display the separate sections in windows at the same time.
Inconsistencies
Disallowed Characters
The IEF manuals state that special characters, such as `-' and `&' are not allowed in names of
organizational units. This fact itself is a drawback, however, in some instances it was possible to
enter these characters into a name successfully. Unfortunately there was no identiable consistency
to when this was allowable.
Printing of OHD
Numerous attempts were made to adjust the printing3 of the OHD with no success. In order to
print the entire OHD it was necessary to redraw the diagram in indented format with small boxes.
Adjusting the fonts represented in the IEF screen view had no eect on the nal printed output.
In addition, the names of organizational units were truncated in the printed copy so that even the
32 characters allowable were not displayed.
3
Hewlett Packard DeskJet 500 Printer was used.
67
D.1.2 IEF Data Model: Entity Relationship Diagram (ERD)
The entities and their relationships detailed in the \Distributed Project Management Information
System: Denition of Information System" document for the DPMIS were created in an ERD.
Subject Areas as dened in the IEF Planning Toolset are not essential for the development of the
DPMIS and therefore were not included, except where IEF denes the model name as a subject
area.
Good Features
Help for ERD
The Help facility in IEF was extremely good in its use of examples to demonstrate concepts and
procedures. The information gained here, particularly in the procedures for developing the diagram
was useful in other areas of the IEF, for example the Activity Dependency Diagrams.
Consistency Checks
The Consistency Check facility which allows you to check either the entire ERD or a single entity
for consistency is good. This facility assists the user in ensuring that the required information has
been entered in order to allow continuation of the development process. The information in the
reports generated is clear and extremely helpful.
Entity Type Denition Report
These reports are essential and the information contained in these includes almost all of the basic
information entered regarding entities and their relationships (see Poor Features below).
View
The View menu of the IEF oers a good selection of View options which make viewing sections
of a diagram and moving around to dierent areas simple. The Home option returns you to the
default view of the diagram. The other selections in the View menu are useful and in general,
self-explanatory.
Poor Features
Contracted Relationship Lines
During the development of the diagram, some of the relationship lines entered were automatically
contracted into their respective entities by IEF. The information provided indicates that entities
with fewer than ten relationships will have all relationship lines drawn (when this option is selected) and that any more than this number will be contracted. I could not locate any information
explaining why the lines were represented in a contracted manner when an entity had fewer than
ten relationships present. Ultimately redrawing the entire diagram replaced the contracted lines
with expanded lines, however, this is not evident until redraw has been selected.
68
Entity Subtypes
Entity subtypes can be dened. Although it is clear from the Entity Type Denition Reports as
well as in the IEF documentation that attributes are inherited from the Entity Type, the same is
not evident for relationships. Redrawing the ERD contracts the subtypes into the entity type which
gives the impression, graphically, that the relationships are inherited. Help states \A subtype is a
collection of entities of the same type to which a narrower denition and additional attributes and
relationships apply." This implies that the relationships are inherited. The textbook, \A Guide to
Information Engineering Using the IEF: Computer-Aided Planning, Analysis and Design" indicates
that the relationships are inherited. It would be helpful if inherited relationships were indicated on
the Entity Type Denition Reports as well.
Entity Type Denition Reports
The only information I felt was obviously missing and missed from these reports was a list of
allowable values for attributes. It would be convenient to have these listed here although these are
detailed in the Attribute Denition Report.
Printing of ERD
As in the printing of the OHD it is dicult to get a reasonable quality print out of the diagram.
The print fonts cannot be changed and again, the names of relationships are truncated. The best
print out manageable was achieved by:
Zooming out to capture the entire diagram on the screen.
Relocating the entities to the outer corners of the screen, while keeping the basic diagram
layout.
Move
The place of attachment of a relationship line to an entity can be moved using the Move option in
the Edit menu. This facility was used in the situation where a single entity type participated in a
relationship. Since the relationship line drawn by IEF in this circumstance is too small to allow
display of the relationship name, moving the points of attachment extends the line and allows the
name to be displayed. Unfortunately, if the entity is then moved itself the relationship lines are
redrawn in the standard IEF manner.
Redraw Diagram
The Redraw Diagram facility redraws the entire diagram but it was not clear that the redrawn
diagram was the best design possible. Also, it appears that the option to redraw the entire diagram
is only available when you are in the Home view of the diagram. This is not clear from the
information provided.
69
Inconsistencies
Relationship Properties: Deletion Rule
The IEF facility allows the following deletion rules:
Delete each occurrence of related entity type.
Disassociate each occurrence of related entity type.
Disallow deletion of current entity type if there is one (or more) occurrence of related entity
type.
The IEF allows you to select from either all three of these options or just two of these options
(when a relationship is mandatory). It would be helpful if the Help provided on-line for the deletion
rule explained the eect the other entity's participation in the relationship has in the selection of
options available and the default settings. The user's selection is automatically set to the required
default dependent on the related entity type's participation in the relationship.
D.1.3 Activity Hierarchy Diagram (AHD)
The Function Hierarchy Diagram (FHD) which is used to represent business functions is not applicable to the DPMIS. Therefore, the Process Hierarchy Diagram (PHD) was developed and will be
expanded and detailed further in the Analysis stage of development using the IEF Analysis Toolset.
In addition, the Activity Hierarchy Diagram tool, in conjunction with the Activity Dependency Diagram tool, was used to attempt a representation of a number of physical data ow diagrams. The
procedure to produce a PHD is simple and, in general, the good features outlined in the OHD and
ERD sections are present here as well.
Good Features
Chaining of AHD
Chaining again allows you to select a root in the diagram and then chain to that portion of the
diagram. It also allows you to select to chain to that portion of the Activity Dependency Diagram
(ADD) and back again.
Multiple additions (adds) to the AHD
This option functions identically in all IEF diagrams that have been constructed at this point.
Redraw of AHD
Redrawing in the AHD allows the same options as the OHD. Box size can be changed as well as
orientation of the diagram (vertical, horizontal or indented).
70
Reuse of Processes
It is possible to reuse processes in the AHD, which also carries the duplicates into the ADD. The
IEF asks you if you wish to reuse the process. This would prevent the inadvertent duplication of
process names. It is not possible to reuse functions or duplicate function names.
Poor Features
Deletion of Processes in AHD
The deletion of a process in the Activity Hierarchy Diagram also removes it from the Activity
Dependency Diagram which is logical. The diculty arises, however, when the process is reentered
in the AHD. It does not automatically reappear in the ADD and it is not clear how to retrieve
it. The solution is to select Place Unplaced Boxes from the View menu, however, this was not
indicated, it was just a guess.
Modify AHD
The selection Modify in the Diagram menu allows you to change the children of a root activity to
Processes from Functions or the reverse. It is not possible, however, to do this when processes have
been designated as elementary. Although logical when considered, it is not clear initially why this
selection is not available for some root functions in the diagram.
D.1.4 Activity Dependency Diagram (ADD)
The Activity Dependency Diagram (ADD) was used to represent process dependencies which will
be further detailed in the Analysis stage of development. The tool is simple to use and the good
features and poor features of the procedure are essentially the same as the other diagraming tools.
The ADD was also used to attempt a representation of a physical data ow diagram. It is not
possible to represent data stores in the ADD and therefore not possible to accurately represent
data ow diagrams using this tool. The Data Structure Diagram which was present in earlier
versions (4.x) of the IEF has been replaced by the Data Structure List and the Data Store List.
Good Features
Chaining in ADD and from AHD
It is possible to chain in and out of a section of the ADD by selecting a root function or process.
It is also possible to chain into the AHD directly from the ADD and back again into the ADD.
External Objects
External Objects can be reused in dierent chained sections of an ADD.
71
Poor Features
Dependency Properties
It is my understanding the Dependency Properties window was automatically presented when
processes were joined in earlier versions of the IEF system. This must be selected from the Detail
menu in the current version. I am not aware of the reason this was changed but it does entail an
extra step for the user and does not follow consistently with the other diagram procedures.
External Objects
External Objects cannot be reused in the same section of an ADD. The reason for reuse would be
to enable a clearer design of the diagram by eliminating cluttering with dependency relationships
all connecting to one copy of the external object.
Parallel or Mutually Exclusive Dependencies
Parallel and Mutually Exclusive dependencies can only be created for subordinate processes (a
process with a parent/root). This creates a problem when processes are only dependent on their
mutual root as the root will not be present in the chained section of the diagram.
Chaining in ADD and AHD
Chaining in the diagrams will not allow you to view two chained sections of the diagram at one
time. One window can display the root you are chaining from and another window will display the
chained section. It is possible to display a chained section of the ADD and a dierent section of
the AHD at the same time.
D.1.5 Matrix Processor
The development of the DPMIS did not necessitate the use of the Matrix Processor tool available
in the IEF. This tool was briey reviewed using a sample model and will be reviewed further as
the project progresses.
Good Features
The Matrix Processor was found to be easy to use and the information provided in the documentation available explained the types and uses of the matrices well. The columns and rows are
automatically populated by the IEF after selection of the appropriate axes.
Poor Features
No poor features were encountered in the use of the Matrix Processor.
72
D.1.6 Summary
The IEF Planning Toolset is, overall a straight forward tool to learn to use and the on-line Help
facility is very good and detailed.
Consistency Checks
Consistency Checks in the IEF models are the primary error checking method available. Some
error message are displayed while building the models, eg. if an entity name is being duplicated.
It is essential to run the Consistency Check facility before continuing on to the next stage of
development.
Diagram Design
Options in the IEF menus allow you to adjust layout and size of boxes and fonts in the diagrams
with the restrictions mentioned above. In addition, there is no option to centre or relocate the
names entered for diagram units within the boxes.
Help
The On-line Help is, on the whole, very good. There are very few instances encountered, such as
the information provided regarding entity subtypes, where the information provided is too sparse.
Printing
The Organizational Hierarchy Diagram is not essential to the use of IEF for systems development,
therefore, the purpose of including this diagram would appear to be to obtain a print out of the
diagram for documentation. However, the print facilities are not good, in particular, the truncation
of names in the diagrams is a disadvantage as well as the lack of ability to adjust fonts in the print
out.
Release Notes
The IEF Release Notes found in the Reports menu are useful in explaining some dierences between
the information in the manuals we have available (which are for Version 4.1) and the current version,
Version 5.1.
D.2 The IEF Analysis Toolset
The Analysis Toolset of Texas Instruments' (TI) Information Engineering Facility (IEF) Version
5.1 was used to continue development of the Distributed Project Management Information System
(DPMIS).4
4
The individual responsible for the use of the IEF CASE tool, A. M. Welch, has no formal training in the use of
the IEF. Please see the Reference Material section included in this document for a list of manuals and documentation
which are being used to assist in the use of the IEF.
73
The following sections of this document will describe the good features, poor features and
inconsistencies encountered in the use of the IEF Analysis Toolset.
Procedures for creating and editing diagrams in the IEF Analysis toolset are consistent with
those in the IEF Planning toolset. Comments made in regard to these tools are not repeated here.
Examples of the IEF generated diagrams and reports are included in the document, Distributed
Project Management Information System: The Analysis Phase Document.
D.2.1 Data Model: Entity Relationship Diagram (ERD)
The ERD had been completed in the Planning Toolset and was reviewed in the Analysis Toolset.
The individual entities created were reviewed and the only change was the removal of the entity
\Subprojects" and its associated relationships.
Good Features
View - Search
The Search option in the View menu is extremely useful when working in a diagram that is too
large to be presented in a reasonable representation on one screen. For example, to Join entities it
is possible to select one entity, Search for the next and then control-select the next entity and then
select Edit/Join.
Deletion of an Entity Type
Deletion of the entity type Subprojects was simple and, of course, deleted the associated relationships as well. The entity type denition reports enabled simple reproduction of the necessary
relationships with the entities remaining. (eg Project is at Site).
Inconsistencies
Consistency Check
An alternative ERD was developed for the DPMIS using entity subtypes. It was possible to
successfully run a consistency check on the ERD without an identier for an entity subtype, Project
Leader. This leaves you with no identier to select from in the Action Block Synthesis (See Action
Diagram).
D.2.2 Data Model List (DML)
The Data Model List, when contracted, simply provides the user with a list of the current entity
types, grouped by subject area. When the DML is expanded it displays the entity relationships as
well. The DML was not used in the development of the ERD initially, however, I have experimented
with it since to determine its functionality. The DML is an enhancement TI added to Version 5.0
of the IEF.
74
Good Features
The entity and relationship listing provided by the DML is simple and concise and an excellent
reference to keep on hand (printed copy) while developing a project.
It is possible to develop the ERD in the DML tool and is actually a nice way to do it. It is
necessary to access View/Place Unplaced Box(es) in the Data Model tool to have the entities appear
in the diagram but this displays the entities and their relationships as well.
D.2.3 Activity Hierarchy Diagram (AHD)
The Process Hierarchy Diagram developed in the Planning Toolset was reviewed in the Analysis
Toolset. The processes associated with the Subproject entity were removed.
Good Features
View Maintenance
Views are easy to include by selecting the View Maintenance option which is available in the
Planning, Analysis and Design Toolsets. The ability to access View Maintenance from various
menus and submenus makes actual maintenance of these convenient, since whenever you encounter
a necessary addition or change to a view set View Maintenance can be accessed directly and the
changes made.
Expected Eects
Expected Eects of the functions and processes in the AHD were detailed during Analysis. This
is a simple, straightforward activity with the IEF. In addition, Expected Eects can be accessed
in the Activity Dependency Diagramming tool as well which makes maintenance of these eects
convenient.
Poor Features
View Maintenance
Accessing View Maintenance in the earlier stages of Analysis, such as through the Activity Hierarchy
Diagram may result in the user missing the option to use stereotyping in Action Block Synthesis
which will generate Import, Export and Entity Action Views automatically. Although these views
will require adjustments in the Design phase it is worthwhile to allow the IEF to generate them
and review the results.
D.2.4 Activity Dependency Diagram (ADD)
The ADD developed in the Planning Toolset was reviewed in the Analysis Toolset. Processes
associated with the Subproject entity were removed in the AHD tool and this automatically removes
them from the ADD.
75
Good Features
External Objects
Including External Objects in the PDD is a simple task and a Consistency Check run on the diagram
will warn the user if they have neglected to included Associated Views for the External Objects.
Events
Events can easily be added to a PDD and can provide valuable information to the Design team.
Events were not used extensively in the DPMIS as it does not appear to aect the continued
development process.
Poor Features
Consistency Check
Consistency check performed on the Activity Dependency Diagram does not produce a warning
if dependencies have not been named. Although, obviously not essential for continued systems
development, notication of the lack of dependency naming would be useful for the Analysis team
in ensuring that the documentation passed on to the Design team is complete.
Dependency Reports
The dependencies of processes can be displayed on screen by selecting Detail/Dependencies but
there does not appear to be a report to provide a print out of the process dependencies. The
Activity De nition report indicates what processes the current process is a subordinate of but does
not provide a list of subordinate processes of the current process.
Redraw
The selection to Redraw the PDD diagram does not provide the selection to resize the boxes.
Default box sizes are set by accessing the Options menu in the main IEF window when entering
the program. Unfortunately the selection of large box sizes did not improve the print out of the
nal diagram.
Placement of Lines
The Move tool works well in the movement of the point of attachment of lines in the dependency
diagrams, however, on saving the model and retrieving it the lines are returned to their previous
placement. This results in the need to move lines again to generate a more legible print out.
D.2.5 Action Diagram - Process Action Diagram (PAD)
The Action Diagram tool presents the process actions in algorithm format with listings of import,
export, local and entity action views.
76
The IEF textbook recommends three levels of Analysis that can be carried out dependent on
how much you choose to leave to the Design team. Since the Analysis team and the Design team
are one and the same in this circumstance the middle of the road approach was selected. Therefore,
the IEF generated Action Blocks (see Action Block Synthesis) were left as is and will be expanded
and corrected in the Design phase.
Good Features
Action Block Synthesis
Import, Export and Entity Action Views can be automatically generated by using the Chain
option from the AHD into the Action Diagram and selecting Action Block Synthesis. This option
automatically generates stereotyped Action Blocks for the elementary processes.
Consistency Check is automatically run on the model during Action Block Synthesis. This is a
nice feature since it prevents the user from continuing on when there is a consistency problem.
For example, the ERD created for DPMIS had been checked for consistency previously but I
neglected to rerun the Consistency Check after removing the Subproject entity and IEF informed
me of the failure to pass Consistency Check when I tried to generate Action Blocks. You are
presented with the options:
Review Report
Continue
Cancel
Help
Action Block Synthesis is benecial because it gives the user a feel for the production of Action
Blocks in the IEF toolsets, however, if the Action Blocks are left at this stage it does transfer the
work of renement of view sets and action blocks to the Design phase. In the DPMIS development
the further development of the Action Diagram will be done during the Design phase.
Expand Expected Eects
The option to Expand Expected Eects was utilized in the development of DPMIS, to review the
procedure and use of this tool. This option is available also in the Design toolset and will be further
reviewed at that stage.
Expand Expected Eects allow the user to expand the expected Eects provided in the Expected
Eects denition in the AHD tool. Attempting to expand the expected eects allows you to generate
action blocks in the action diagram.
The IEF steps the user through this process easily. The selections oered are clear and assist
in the development of action blocks. It is a benet to review the IEF action block design generated
by Action Block Synthesis.
77
Poor Features
Action Block Development
There is a substantial amount of transfer and linkage between processes in the DPMIS and the
ability to use other process Action Blocks in the Action Diagram is necessitated. It is not possible
to use other process action blocks until the design stage.
The alternative would be to create action blocks within the Process Action Blocks which does
not appear to be a benet at this stage. For example, creating an action block for Create Milestone
while there is an Add Milestone Process Action Block.
Expand Expected Eects
In the use of Expand Expected Eects the following error was encountered:
IEF Internal Fatal Error Missing mandatory association 88, from obj type 23, obj recnum 22.
This error was encountered several times and the Help facility does not provide information
regarding this type of error. It is necessary to contact TI to determine the cause of the error.
Stereotyping in Action Block Synthesis
Stereotype5 is mentioned in IEF on-line help as well as the IEF text and manuals. In particular,
on-line help states, \To specify the type of stereotype that procedure synthesis uses to generate the
Procedure Action Diagram, select Stereotype."
Stereotyping itself is an advantage in the Analysis Toolset, however, it was dicult to locate
Stereotype in the toolsets. Although Action Block Synthesis is a form of Stereotyping the Help
facility is not helpful in determining this. Stereotyping as a menu selection is actually found in the
Design Toolset by selecting Dialog Flow Diagram/Detail/Procedure Synthesis/Edit. The actual
selection Stereotype appears on the Edit submenu.
Inconsistencies
Consistency Check
An alternative ERD was developed for the DPMIS using entity subtypes. It was possible to
successfully run a consistency check on the ERD without an identier for an entity subtype, Project
Leader. This leaves you with no identier to select from in the Action Block Synthesis.
Structure Chart
The Structure Chart displays the hierarchy of action blocks (Elementary process action blocks and
action blocks in the Analysis Toolset and procedure action blocks in the Design Toolset.). Since the
Analysis conducted for the DPMIS concentrated on processes and their action blocks the Structure
Chart tool was not utilized at this stage of development.
5
Stereotype is dened by IEF Help as \A typical pattern or style of procedure step design."
78
To test the functionality of the tool temporary action blocks were added in some elementary
process Action Block Usage diagrams. These were easily added.
Poor Features
Deletion of Action Blocks in the Structure Chart is not dicult but determining how to perform
this procedure is dicult. Ultimately a note in the IEF Analysis Toolset manual was encountered
which states, \NOTE: Once you add an action block, you cannot delete it using the SC or ABU
Tool. To delete an action block, use the Action Diagramming Tool."
It is necessary to enter the Action Diagramming Tool, select the action block you wish to delete
and once you are in the Action Diagram for this action block select Diagram/Delete.
D.2.6 Action Block Usage
The Action Block Usage diagram displays the action blocks for elementary processes and action
blocks created in the Analysis stage of development. As with the Structure Chart only elementary
process action blocks are currently represented for the DPMIS. If permanent action blocks had
been added during the Analysis stage these could be represented as well.
To test the functionality of the tool temporary action blocks were added in some elementary
processes Action Block Usage diagrams. These are easily added.
Poor Features
Deletion of action blocks that have been added in the Planning or Analysis stages is described in
the section on the Structure Chart tool.
D.2.7 Matrices
Matrices recommended in the IEF text were reviewed. The Cost Benet Matrix was not applicable
for this development project.
Good Features
The matrices provided by IEF provide a good opportunity to review the relationships of functions,
processes and entities and the expected eects of functions and processes on entities in the data
model. Matrices are automatically populated by IEF and the editing features available are similar
to those in the other IEF tools. In addition, the user has the option to select colours for matrix
sections which has not been an option in the diagramming tools.
Business Function/Entity Type Usage Matrix
The IEF automatically populates this matrix and Clustering of this matrix automatically populates
the Entity Type/Entity Type Anity matrix. Clustering groups functions together based on their
usage of entities.
79
Elementary Process/Entity Type Usage Matrix
Elementary Process/Entity Type Usage Matrix is the Analysis Toolset matrix which is applicable
in the DPMIS development. The matrix is automatically populated by the IEF and provides a
concise view of the Entity Type Usage for the Elementary Processes.
Clustering of this matrix automatically populates the Elementary Process/ Elementary Process
anity matrix.
Entity Type/Entity Type Anity Matrix
The Entity Type/Entity Type Anity matrix can be populated through the clustering of the
Business Function/Entity Type Usage matrix or the Elementary Process/Entity Type Usage and
provides the user with values of 1 through 9 for the level of anity of entity types to one another.
D.2.8 Business System Denition
Generation of a Business System Denition is not dicult. Providing the name of the root function
for the Distributed Project Management automatically imported the process hierarchy diagram.
Elementary processes which are included in the Business System Denition are shown in yellow
outlined boxes (removed ones are shown in blue). Processes included in other business systems
denitions are outlined in white, however, this is not applicable for DPMIS.
Inconsistencies
Business System Denition Diagram
The diagramming of included processes dierently from those not included in a business system
appears to be inconsistent with other diagramming tools in the IEF. My rst thought is, if a process
is included, why make it look dierent than the other processes. Why not make the Removed
processes look dierent?
D.2.9 Summary
The Analysis Toolset usage followed very closely to that of the Planning Toolset and since the
mechanical procedures for the use of IEF tools had been learned in the Planning Toolset the
development was on the most part smoother and faster.
Consistency Checks
Consistency Checks are still very helpful and when they are done automatically by the IEF are
unobtrusive and are a denite benet to the user.
Help
The on-line Help facility was again, on the whole, very good. The most notable disadvantage was
that when using the Search option to look for information on some topics, such as Views, searching
80
under Views ultimately provides you with instructions on how to use the View option in the IEF
menu. You must look up View Maintenance or a specic type of View.
Inconsistencies
Procedure De nition which is listed in the Search section of the Help facility cannot be accessed.
A double click on Procedure Denition results in Procedure Denition Report being selected.
Printing
It is dicult to generate readable print outs. Numerous attempts were made to produce diagrams
that provided a clear layout and readable characters6. In order to produce a print out of Process
Dependency Diagrams that was legible it was necessary to compress the diagram symbols into
a small area to enlarge the print. For example, in diagrams that contained Events and External
Objects it was not possible to locate Events in one area of the diagram, External Objects in another
and Process blocks in another. Truncation of dependency and entity relationship names is still a
problem.
Examples of the IEF generated diagrams and reports are included in the document, Distributed
Project Management Information System: The Analysis Phase Document.
D.3 The IEF Design Toolset
The Design Toolset of Texas Instruments' (TI) Information Engineering Facility (IEF) Version 5.1
was used to continue development of the Distributed Project Management Information System
(DPMIS). 7
The following sections of this document will describe the good features, poor features and
inconsistencies encountered in the use of the IEF Design Toolset.
Procedures for creating and editing diagrams, including action diagrams in the IEF Design
toolset are consistent with those in the IEF Planning and Analysis toolsets. Comments made in
regard to these tools are not repeated here.
Examples of the IEF generated diagrams and reports are included in the document, Distributed
Project Management Information System: The Design Phase Document.
D.3.1 Business System Defaults
The selection Business System Defaults/Detail provides the user with the following editing options.
Properties allows the designer to enter a description of the business system currently being
designed.
Screen Video Properties allows the designer to select the characteristics of the various
items in the screens designed, such as error messages and prompts.
A Hewlett Packard DeskJet 500 printer was used.
The individual responsible for the use of the IEF CASE tool, A. M. Welch, has no formal training in the use of
the IEF. Please see the Reference Material section included in this document for a list of manuals and documentation
which are being used to assist in the use of the IEF.
6
7
81
Commands allows the designer to dene and edit commands selected for the business system.
Exit States allows the designer to dene and edit Exit States used for the business system.
Function Keys allows the designer to dene and edit the commands associated with function
keys for the business system.
Special Edit Patterns allows the designer to dene and edit the patterns for the IEFsupplied special elds.
Field Edit Patterns allows the designer to dene and edit the patterns for elds used in
the business system.
Delimiters allows the designer to dene and edit parameter delimiters and string separators
used in the business system.
Good Features
The availability of editing of all of the above in one submenu is a good feature, particularly for
standardizing the characteristics of these items for the business system design.
Poor Features
Commands
An attempt to delete a Command from the command list for the DPMIS was not allowed and no
explanation was given. Ultimately it became clear that it was impossible to delete the command
because it was utilized in an action diagram. This is logical, however, it would be useful if IEF
informed the user that this is the reason the deletion cannot be accomplished.
D.3.2 Dialog Design
Dialog Design allows the designer to dene the procedures and procedure steps for the business
system as well as any transfers or linkages between the steps in a Dialog Flow Diagram. It is
possible to edit a number of features detailed in the Business System Defaults through the Dialog
Design tool.
Good Features
Edit
The construction and editing of the Dialog Flow diagram is very similar to that of diagrams constructed in the other development toolsets. This fact is extremely benecial to the user as it speeds
the process of constructing the diagram.
Adding procedures and procedure steps are simple jobs in the Dialog Flow diagram. Joining
procedure steps works the same in this diagram as it does in the in the other diagraming tool, eg.
the Data Model diagraming tool.
82
View
The View feature again is very similar to the View in other diagrams with the additional option
to view Neighbors of a procedure. This feature is useful when the Dialog Flow diagram gets large
as it allows the designer to select a procedure and View/Neighbors which results in the display of
that procedure and only the procedures that are joined to it.
Clear Screen Input
Clear Screen Input allows the designer to construct the business system to allow users of the system
to input information to a blank screen to save displaying the screen associated with a procedure or
procedure step. This IEF feature was not utilized in the development of the DPMIS, however, it
was tested in a copy of the DPMIS to evaluate its function. It is easy to use and would certainly
be a good option to provide the users of the nalized system.
Flow Maintenance
Flow Maintenance was extremely useful, as it enables the designer to view the ows from a procedure, the associated exit states and commands, all at one time. Otherwise, each ow would have
to be selected and the associated information viewed separately.
Chain
Chain is available in the Design toolset and is again very useful, enabling the user to chain between
the following areas.
Screen
Action Diagram
Prototyping
Structure Chart
Poor Features
Prototyping
The Prototyping tool allows the designer to view the screens designed with the function key assignments, however, it is not possible to print from this tool so it is not possible to obtain a print out
of the screens with the associated function keys.
Deletion of a Procedure Step
It was not possible to move a ow from a procedure step to another procedure step in the same
procedure or to the procedure itself. This would be useful when a procedure step is selected for
deletion so that the ows would not have to be recreated.
83
D.3.3 Screen Design
Screen Design allows the designer to design the layout of the screen for each procedure and procedure
step. Overall the Screen Design tool was simple to use.
Good Features
Templates
Templates can be created for use in screens. These are useful and save time in the creation and
editing of screens. For example, a template was created for retrieval by each entity type. The
templates could be then utilized in each procedure step screen for that entity retrieval. In addition,
changes made to the template will result in the changes being reected in each screen that uses the
template.
Detail
The submenu Detail allows the designer access to the following tools, which is benecial because it
allows the designer to make changes to things like import and export views at this point.
Screen Properties
View Maintenance
PF KeyCommands
Generate/Auto Layout
The Auto Layout tool in the Generate submenu performs automatic layout of the screen, once
import and export views have been dened. This tool was tested but ultimately the screens were
designed manually. The tool, when used did provide a reasonable layout and a good basic outline
for screen design.
Inconsistencies
Field Mapping
Consistency Checks revealed the following warning.
WARNING ICCSV01W A non-hidden eld must either be mapped or dened as \none".
The eld referenced by the above warning was dened as \none" on checking the properties
dialog box the rst time but a second check revealed the eld to be dened as \not yet mapped".
The setting appeared to toggle between \none" and \not yet mapped". The eld was ultimately
mapped to an import view which solved this problem.
Printing of Screens
The screen for Document Retrieval printed twice (consecutively) with only the title and border and
no screen content despite the fact that elds had been included on the screen. A third printing was
successful. The printer was checked for problems and none were found.
84
Prompts
The IEF text states that the IEF will issue a reminder that a specic prompt has been utilized
previously if the designer attempts to use an alternative prompt for the same entity attribute.
This does not occur in the IEF Design toolset used to develop the DPMIS. This may be a change
instituted after publication of the text, however, it would be a nice check to have available.
D.3.4 Action Diagram
The Action Diagram tool allows the user to build the action blocks for the procedures and procedure
steps. The \how-to" information for the use of the Action Diagram detailed in the on-line help was
correct and helpful. The building of the Action Diagram is more dicult and a slower process than
the other diagrams in the IEF toolsets.
Good Features
Add Statement
Statements were easy to add to the action diagrams. The IEF steps the designer nicely through
the construction of more complex statements and View Maintenance is accessible from the Add
Statement dialog box if the designer encounter the situation where a view must be added to continue
to build a complex statement.
Stereotype
Stereotype is available in the Procedure Synthesis. It is easy to utilize and provides a quick outline
for the procedures and procedure steps.
Xcopy
Xcopy allows the designer to copy sections of an action diagram to another diagram and is a useful
tool. The on-line help provides a good description of the mechanics of using Xcopy.
Poor Features
Help
The on-line help provided by IEF explains the mechanics of building the diagrams but does not
explain the concepts and ow within the diagrams which is an area that should be better detailed
in the reference material. Determining how to construct the diagrams is well explained and by
following the help becomes a fairly easy task but determining what happens when control returns
to a procedure following a link to another procedure is not clear and not well explained.
Contract
Contract is more dicult to utilize in the action diagrams because it is not clear which statements
can be contracted or exactly how to contract them. For example, to contract an \IF" statement
85
selecting the rst line and then Contract will contract the statement but for a \READ" statement
the \when successful" line should be selected and then Contract.
Copy with Substitution
This feature would be useful, however, it only allows copying of action diagrams with exactly one
entity view. This necessitates the creation of almost identical action diagrams by building the
diagram from scratch or with the use of Xcopy where possible.
Delete Statement
Use of the Delete Statement function resulted in an IEF fatal error and termination of the program
a number of times. Ultimately it was possible to determine that the fatal error was resulting from
the attempt to delete a case from a case statement before removing all statements, including blank
lines, from the case. It would have been helpful if the IEF had provided information stating that
the case could not be deleted until all statements within it were removed. The result of the fatal
error was that a number of changes were lost when the program exited abnormally.
Description
The option to enter a description of the procedure step is frustrating because it does not allow the
entry of a new line character and when printing the action diagram, the description does not print
entirely on the page.
Exit States
Information concerning Exit States, their uses and eects is very sparse in the on-line help. A lot of
time was, therefore, spent searching for information about the eect of an Exit State that did not
invoke a ow to another procedure. Ultimately an adequate explanation was located in the rapid
development tutorial manual provided 8. When the end of the action diagram is reached and the
Exit State does not allow for a ow to another procedure, control will be returned to the beginning
of the current procedure.
When setting up the Exit States for the business system it would be benecial if the default
property for message display was informational rather than none once a message has been entered
for an Exit State.
D.3.5 Work Set List
Work Set List provides the user with a list of the work sets used in the business system, their
attributes, properties and where they are used in the system. Work sets include the IEF supplied
work set which has an attribute for Command.
D.3.6 Structure Chart
The Structure Chart displays the hierarchy of action blocks (procedures, procedure steps, elementary processes and additional action blocks). The development of this diagram is automatic as
86
the designer develop the action blocks for procedures and procedure steps. Editing this diagram is
similar to the editing of all other diagrams in the IEF toolsets and is quite simple.
Good Features
The Structure Chart provides the designer with a quick view of the hierarchy of a procedure or
procedure step in the business system and enables the designer to quickly review which action blocks
and processes are utilized in a specic procedure or procedure step. Procedures and procedures
steps, elementary processes and action blocks are shown in dierent colours which aids in quick
identication.
Poor Features
The printing of the Structure Chart, as with the other IEF diagrams does not provide a good print
out as names are truncated. In addition, if a process or action block is utilized twice in the action
diagram this will be displayed in the print out of the Structure Chart. Although this is logical it
could be confusing for other designers reviewing the diagrams.
D.3.7 Action Block Usage
The Action Block Usage diagram, when a specic action block has been selected, displays the
procedures and processes that use the action block. Editing this diagram is similar to the editing of
all other diagrams in the IEF toolsets and is quite simple. This diagram is automatically developed
by the IEF as the procedure action diagrams are developed utilizing the action blocks.
Good Features
The Action Block Usage provides the designer with exactly what the name implies a diagram of
where action blocks are used once a specic action block has been selected.
Poor Features
The poor features of printing the Action Block Usage diagrams are identical to those of the Structure
Chart.
D.3.8 Data Structure List and Data Store List
The Data Structure List provides a listing of the data structures and the Data Store List provides a
listing of the data stores which have resulted through the transformation of the data model dened
during the Planning and Analysis phases of the system development.
D.3.9 Transformation
Transformation automatically transforms the data model objects into data structure objects. Transformation automatically performs a consistency check and processes referential integrity. The pro-
87
cess is automatic and therefore, simple to use. The designer is responsible for setting Data Structure
Defaults prior to Transformation and the on-line help is helpful in detailing these.
D.3.10 Retransformation
Retransformation is utilized if changes are made to the data model following Transformation. It is
also automatic and the designer again is responsible for setting Data Structure Defaults.
D.3.11 Referential Integrity
Referential Integrity checks the integrity of data relationships. This is performed automatically
during Transformation and Retransformation but the designer has the option to select this feature
in order to verify the integrity of data relationships.
D.3.12 Reports
The Reports available throughout the IEF toolsets are very helpful. and this is also true for the
reports relevant to the Design toolset which are listed below.
Procedure Denition provides a denition of procedures including a description of each, a
list of subordinate procedure steps and processes implemented.
Procedure Step Denition provides a denition of procedure steps including a description
of each, a list of function key denitions, details of dialog ows and all views utilized in the
procedure step.
Command List provides a listing of the commands used in the business system.
Command Uses provides a listing of the commands and where they are used in the business
system.
Exit State List provides a listing of the exit states used in the business system.
Exit State Uses provides a listing of the exit states and where they are used in the business
system.
Field Denition provides a detailed report of the eld denitions implemented following
Transformation.
Implemented Data List provides a report of the data objects implemented in Transformation.
DDL Statements provides a detailed report of all data denitions following Transformation.
88
Good Features
The Procedure Step De nition report was particularly useful as it provided detailed information
concerning dialog ows to and from a selected procedure step. This provides the designer a good
reference to ensure dialog ows are complete and accurate.
The Implemented Data List provides a useful check of the implementation of the data following
transformation.
D.3.13 Consistency Checks
Good Features
The Consistency Checks are again very useful in the use of the IEF toolset and assist the designer in
the completion of the business system design. The option to select the level of Consistency Check,
Analysis, Business System Design and Technical Design is a good feature as the designer can then
be sure the system has passed Consistency Check at the correct level.
Consistency Checks on the whole, are performed at the designer's request rather than automatically. The Transformation and Retransformation tools perform Consistency Checks automatically
but this is unobtrusive.
Poor Features
The faults found in the Consistency Check reports were poor identication of the problem. For
example,
Process UPDATE DELIVERABLE WARNING The READ entity action should correspond
with expected eects of the process.
It would be helpful if this identied the entity that the READ action applied to.
D.3.14 Summary
The Design toolset followed very closely in usage to both the Planning and Analysis toolsets in
the mechanics of development of IEF diagrams. The consistency in methods of editing diagrams is
helpful in the continued use of the IEF toolsets.
Prototyping
Prototyping is available in the Chain tool of the IEF in the Design toolset. This tool allows the
designer to view prototypes of the screens designed using the IEF tool. The IEF documentation
describes this as a useful tool to ensure the screens designed and the order of ow between screens is
correct. Autoows must be assigned to the ows in the Dialog Flow diagram to utilize this feature
in that manner. I found it was not benecial for this project and felt the inclusion of the autoows
in initial development proved confusing.
89
Help
The major diculty in the design phase lay in the help information available for action diagraming.
The documentation available (see Reference Material) combined with the on-line help still leave
gaps in the explanations for some things such as the eect of Exit States on the ow of control
within procedures and procedure steps.
D.4 The IEF Construction Toolset
The following sections provide details of the good features, poor features and inconsistencies encountered in the use of the IEF Construction Toolset. The activities in this toolset are performed
automatically by the IEF once the user selects the activity. A summary of these comments is
included immediately following the detailed sections.
D.4.1 Environment
The Environment selection allows the user to specify the target environment for the information
system being developed.
The Environment settings were specied as follows.
Operating System: OS/2
DBMS: DBM
Language: C
TP Monitor: IEFAE
Prole Manager: SQL
Screen Type: Bypass
Clear Screen Default: Reset
Max Seg Size (IMS): 0
Restartable Application
Extended Attribute Support
Good Features
Environment Parameters
The appropriate settings for the OS/2 environment parameters are provided in the Workstation
Construction guide 9]. No diculties were encountered in the use of this option.
90
D.4.2 Packaging
The Packaging selection allows the user to specify the load module packaging for the information
system. Once the selection of either one module or multiple modules has been made the IEF
completes the packaging automatically.
Good Features
Load Module Packaging
The documentation provides an adequate explanation of the reasons for selecting multiple modules
or a single module. The documentation also provides the suggestion that a single module be selected
for applications in the OS/2 environment.
D.4.3 Generation
The Generation tool allows the user to specify, Code, Code and Install or Install All Changes for
either the database denition language (DDL) or the source code. Once the appropriate selection
has been made the generation of the DDL, source code, compilation and linking of the load modules
was performed completely by the IEF.
The Generation Defaults for the target environment were specied as follows.
Operating System: OS/2
DBMS: DBM
Language: C
TP Monitor: IEFAE
Type of Installation: Local
DBMS Drive for Local Installation: D
Run Consistency Check for each item generated
Generate source code with trace
Good Features
Installation Monitor
The IEF Installation Monitor provides error reports when a module is not successfully installed.
These reports are clear and provide the detail required for the suer to correct the problem.
Application Environment Facility
The AEF provides an alternative method of testing/debugging the action diagrams. This can be
sued for testing when the Installation Monitor is not active. Testing/debugging is done at the
action diagrams level rather than the code level and the procedures are the same as in the sue of
the Installation Monitor testing facility.
91
Chain
Chain allows the user to access the Dialog Design, Action Diagram, Screen Design, Window Design
and Data Structure List tools from the Construction toolset.
Install All Changes
Action diagram and screen design tools for the IEF include a generation selection which allows
the user to generate code for specic action diagrams or screen designs. This is extremely useful
in conjunction with the Install All Changes option in the generation tool which allows the user
to install only those modules that have been changed rather than regenerating and installing the
entire set of load modules. This saves a great deal of times since generating and installing the entire
set of load modules requires approximately three hours.
Poor Features
STOPing Generation
The dialog box that becomes active during generation has a STOP push button that simply did not
work. This should cancel the generation and/or installation of the load modules. The generation
and installation of the entire set of load modules for the DPMIS took approximately three hours.
The inability to stop the installation using the expected methods requires that the user either
reboot the machine or wait until the installation is complete.
D.4.4 Application Environment Facility (AEF)
The IEF manuals that were available were missing instructions related to testing procedures. Testing of the action diagrams with trace active can be done from the Application Environment Facility
(AEF) or the IEF Installation Monitor (IM). The IEF Installation Monitor (IM) is only active following generation of a load module. If the IM has been closed testing should be done from the
AEF. The manuals available for the IEF did not include the instruction that informed the user they
must enter the following command, SET AETEST = ON prior to starting the AEF to activate the
trace during testing. This command was eventually located in one of the tutorial documents 11]
for the IEF, however, this omission delayed testing of the DPMIS.
Inconsistencies
Install All Changes
The advantage noted above regarding the use of the Install All Changes option in the generation
tool presented one notable diculty when utilized. The user was allowed to use this option once
successfully, however, a second attempt to to use this function without exiting the IEF resulted
in an internal error and any changes that had been made were lost. It was necessary to save the
model, exit the IEF completely and restart the IEF if the user wanted to use this option more than
once.
92
Dialog Flow
Problems identied during testing required changes to the action diagrams. The changes made to
the action diagrams then required regeneration of the code and installation of only those regenerated
modules. In some instances, changes to dialog ow properties required complete regeneration and
installation of the code.
D.4.5 Summary
The IEF Construction Toolset is fully integrated with the other toolsets. It is fully automated and
the user is really only required to enter environment information and select the appropriate menu
selection to initiate the generation and installation of the DDL and source code.
Generation
The most notable problem associated with the IEF Construction Toolset was the fact that the
STOP button in the generation dialog box was not functional.
Install All Changes
This function saves a great deal of time since without this option, all of the code for the information
system would need to be regenerated and installed after changes were made. Using this option code
was generated at approximately 847 lines per minute.
Testing
The AEF and IEF Installation Monitor enable the user to test/debug the action diagrams. This is
highly desirable over debugging the source code. Debugging of the source code was not attempted.
The testing methods are simple. The omission of necessary instructions from the manuals were the
source of the delay in completely this phase of the project.
93
E TI IEF Tutorials
E.1 Introduction
The tutorials included in this package were developed to provide an introduction to the use of
the various tools available in the toolsets of the Information Engineering Facility (IEF) Version
5.1 by Texas Instrument's (TI). The IEF consists of four toolsets Planning, Analysis, Design and
Construction.
The information system project used in the tutorials is the Distributed Project Management
Information System (DPMIS). The purpose of the DPMIS is to provide a set of applications to
support the information requirements necessary to track the progress, status and descriptive details
of projects spanning multiple sites. Details of the purpose and function of the DPMIS are included
in the document, \Distributed Project Management Information System: Denition of Information
System, Version 4.0". The information necessary to complete the tutorials is included with each
tutorial.
In order to provide an opportunity to utilize the Organizational Hierarchy diagraming tool of
the IEF toolset a portion of the organizational chart for the University of Western Ontario will be
replicated.
E.2 Information Engineering Facility (IEF)
The initial IEF window presents the user with a number of selections which include access to the
Planning, Analysis and Design toolsets. Selections which are \greyed-out" are not accessible at
this point. For example, an IEF model must be opened through the Model selection to make the
toolsets accessible.
The Model selection allows the creation, opening, copying and deletion of models. Once a model
has been created, selection of the appropriate toolset will allow you to continue system development.
The Model selection also provides the option to select Reports which allows the user to request the
generation of the reports provided by the IEF. The reports available from the IEF are listed in the
Reports section of this document.
The Options selection allows the user to set defaults such as, diagram fonts, box fonts, box size
and consistency check levels.
E.3 IEF Toolsets
This section of the document provides an outline of the tools available in the IEF toolsets.
E.3.1 Planning Toolset
The Planning Toolset of the IEF is used during information strategy planning in the development
of the business information system. The Planning Toolset of the IEF has the following options
available.
Data Model which facilitates the creation of an entity relationship diagram (ERD) for the
information system under development.
94
Data Model List which provides an alternative method of constructing the ERD and provides
the entity relationship details in a list format.
Activity Hierarchy facilitates the creation of an activity hierarchy diagram (AHD) for the
information system under development.
Activity Dependency is developed automatically by the IEF as the user develops the AHD.
Organizational Hierarchy accesses the organizational hierarchy diagraming tool to enable the
construction of the organizational hierarchy diagram.
Matrices are automatically generated by the IEF and are utilized to perform analysis of the
system.
Check initiates a Consistency Check.
E.3.2 Analysis Toolset
The Analysis Toolset of the IEF is used during business area analysis of the information system
under development. The Analysis Toolset of the IEF has the following options available.
Data Model.
Data Model List.
Activity Hierarchy.
Activity Dependency.
Action Diagram.
Work Set List which provides a list of the work sets available for the system. Work sets are
used for items such as counters, user input that is not entity related (menu selections).
Structure Chart which displays the action block hierarchy diagram.
Action Block Usage which displays the usage of action blocks by procedures and procedure
steps.
Matrices.
Business System De nition.
Check.
95
E.3.3 Design Toolset
The Design Toolset of the IEF is used during business system design and technical design of the
information system under development. The Design Toolset of the IEF has the following options
available.
Business System Defaults which allows the setting of system defaults such as screen video
properties and function key assignments.
Dialog Design which allows the development of the dialog ow diagram.
Screen Design which allows the design of the user interface.
Action Diagram.
Work Set List.
Structure Chart.
Action Block Usage.
Prototyping allows the review of the user interface designed.
Dialect De nition allows the user to dene objects for use in the model. The IEF has a default
dialect.
Check.
Data Structure Defaults which allows the user to set the defaults for data structures.
Data Structure List which presents a list of the physical data model.
Data Store List which provides a list of the data stores, tablespaces and records.
Transformation is the transformation of the data model objects to data model structures.
Retransformation is used to perform transformation again when changes have been made to
the data model.
Referential Integrity Process checks the integrity of the data model relationships.
E.3.4 Construction Toolset
The Construction Toolset of the IEF is used during construction and testing of the information
system under development. The Construction Toolset has the following options available.
Environment which allows the setting of environment parameters of the target environment
for the information system.
Packaging which allows the user to specify the type and number of load modules for the
information system.
Generation which allows the user to generate and install the database and code.
96
E.4 IEF Tools and Features
The following is a brief introduction to some of the IEF tools and features, in particular, those
which are utilized throughout the dierent IEF toolsets. The use of many features is the same for
the dierent diagraming tools in the IEF toolsets.
E.4.1 Chain
Chaining in the IEF toolsets allows you to change the view to another level of a diagram or to
change to another diagram. Selection of a root in the Organizational Hierarchy Diagram then
Diagram/Chain will display the organizational unit hierarchy subordinate to the root selected.
Selection of a process in the Activity Hierarchy Diagram followed by the selection Diagram/Chain
will display the options to chain to the Hierarchy Diagram, Action Diagram, Dependency Diagram,
Structure Chart and Action Block Usage diagrams.
E.4.2 Edit
The Edit option in the IEF toolsets allows the user to create the diagrams and includes selections
such as, Add and Delete to facilitate the creation of the diagram.
Prior to selecting Edit in the development of a diagram it is often advisable to select Options/Multiple Adds if the user is adding a number of units/boxes to the diagram.
E.4.3 View
The selection View provides the user with a number of view options including Redraw, Zoom
In/Out, Search and Home. Home returns the user to the original view and position in the diagram
they are currently working on. Search is an ecient way of moving around in the diagram.
E.4.4 Redraw
The Redraw option available in the View IEF diagram tool functions in two ways. In some diagrams
it allows the user to select a box size and a diagram orientation while in others the selection of
Redraw initiates redrawing of the diagram by the IEF automatically. A similar option available in
some diagrams are Redraw Lines which initiates the automatic redrawing of diagram lines by the
IEF.
E.4.5 Consistency Checks
Consistency Checks are provided throughout the IEF toolsets. In most circumstances the user is
responsible for running the checks, however, these are run automatically by the IEF prior to Action
Block Synthesis and Transformation. The Consistency Checks run automatically by the IEF are
done on the entire model.
To perform a user requested Consistency Check a portion of the diagram or the entire diagram
can be selected by the user. For example, in the entity relationship diagram if only one entity is
selected the Consistency Check performed will check only the selected entity and its relationships.
97
E.4.6 Help
Help is available throughout the IEF toolsets. When working in a specic diagram it is most useful
to select the Extended Help option. This provides an overview of the diagraming tool currently
accessed and access to more detailed information.
E.4.7 Reports
Reports are available throughout the IEF toolsets. The reports can prove extremely helpful in
reviewing the system under development. In addition the Consistency Check feature also produces
a report of warnings and errors if the model does not successfully pass the check.
The following reports are available from the IEF selection Model/Reports.
Release Notes
Entity Type Hierarchy
Entity Type Denition
Entity Type Uses
Relationship Uses
Attribute Cross Reference
Attribute Denition
Attribute Uses
Activity Hierarchy
Activity Denition
Procedure Denition
Procedure Step Denition
Command List
Command Uses
Exit State List
Exit State Uses
Field Denition
Implemented Data List
DDL Statements
98
Planning Objects
Planning Objects Uses
Information Needs Map
99
E.5 Tutorial 1 - Organizational Hierarchy Diagram
The Organizational Hierarchy tool of the IEF Planning Toolset allows you to create organizational
hierarchy diagrams (OHD). The OHD developed in this tutorial is not applicable to the Distributed
Project Management Information System (DPMIS) which is developed in the rest of the tutorial
series. This tutorial is simply an exercise to review the Organizational Hierarchy tool of the IEF.
1. Select Model/New.
2. Enter the model name, \Distributed Project Management Information System" and the local
name, \DPMIS".
3. Select Planning/Organizational Hierarchy. A dialog box will be opened in which the information for the organizational unit can be entered. Enter the organizational root unit name,
Chancellor. A description of this unit can be entered by clicking on Desc... , however, a
description is not necessary. Click OK .
4. Select the organizational root created, then Edit/Add. Enter the name of the organizational
unit President Vice Chancellor.
5. Enter the organizational unit Provost and VP Academic subordinate to the unit, President Vice Chancellor.
6. Select Options/Multiple Adds. This will allow you to make multiple additions to the organizational hierarchy diagram immediately subordinate to the root you have just created. The
Options submenu allows you to return to Single Add and to select the Fonts for the diagram.
7. Select the organizational unit, Provost and VP Academic created and then Edit/Add. The
dialog box to enter the organizational unit information will continue to reappear until you
select Cancel . Enter the following organizational units as subordinates of Provost and VP
Academic: Libraries, Vice-Provost Student Health Services and Dean Medicine.
Add an organizational unit called Temp to your diagram. After the addition of Temp click
on Cancel to exit the add option.
8. Select the organizational unit Temp and Edit/Delete. The IEF will display your selection
for deletion. Click on Delete and then Yes . Temp will be removed from your diagram.
9. Select an organizational unit in your OHD and Detail/Properties. This redisplays the dialog
box to enter the properties of the organizational unit selected. Changes to all properties can
be made in this option.
10. Select the organizational unit Libraries and Edit/Move. Click on the unit Vice-Provost
Health Sciences. The Libraries unit will be moved to the right of Vice-Provost Health
Sciences.
11. With the organizational unit Libraries selected, select Edit/Change Parent. Click on the
unit Vice-Provost Health Sciences. The Libraries unit will now be a subordinate unit
of the Vice-Provost Health Sciences.
100
12. Select the organizational root and View/Contract. The diagram will be contracted into the
root and its rst subordinate President and Vice-Chancellor. The President and ViceChancellor unit will be displayed with ellipses in the box.
13. Select View/Expand to expand the diagram to its previous view.
14. Select View/Search. A dialog box to allow the entry of the search criteria will appear. Enter
the unit name Dean Medicine and select Search . Once the search has been successful
select Close .
15. Select View/Home. The IEF will return you to the top of your OHD.
16. Click on your OHD above the organizational root and drag the frame box to include the rst
subordinate. Select View/Frame. The IEF will display the framed area to the full size of the
screen.
17. Select View/Redraw. The dialog box for Redraw will appear. The box size and diagram
orientation can be changed in this option.
18. Select the organizational unit Provost and Vice-Chancellor and Diagram/Chain. The
IEF will change the view of the diagram to the level subordinate to the unit selected.
19. SelectionDiagram/Print to print the OHD. The print options dialog box presents options such
as printing the entire diagram or just the portion appearing on the screen.
20. Select Diagram/Reports and the IEF automatically generates the Information Strategy Planning
report. This report can be printed through the File/Print selection in the Reports window.
21. Select Diagram/Exit which returns you to the main IEF window where you can select Diagram/Save Model to save your model.
22. Select Diagram/Exit to exit the IEF.
101
E.6 Tutorial 2 - Entity-Relationship Diagram
The Data Model tool of the IEF allows you to construct entity relationship diagrams (ERD). It is
accessible from both the Planning and Analysis toolsets and the functionality is identical in both
toolsets. This tutorial will assist you in building a basic ERD.
1. Select Model/Open.
2. Select the model, \Distributed Project Management Information System", then Open .
3. Select Planning/Data Model
4. Select Edit/Add Entity Type. A dialog box for entry of entity information will be displayed.
Enter the information provided in Section E.6.1 for the entity Project. Select Desc... to
enter the description of the entity. Select OK when complete.
5. Select Detail/Attributes. The window for attributes will appear.
6. Select Options/Multiple Adds. Select entity Project Edit/Add and the dialog box for entering
attribute information will appear. Enter the following information:
Attribute name: project name
Category: Basic
Domain: Text
Length: 20
Select Varying Length. The attribute description can be entered by selecting Desc... . Select
OK .
7. Values and aliases for attributes can be entered by selecting Detail/Values or Detail/Aliases.
Select the attribute \status" and Detail/Values. Select Add . Enter the value \on-time" and
select Value is default. Select OK . Enter the alternative values. Select OK .
8. Select Diagram/Exit to return to the Data Model tool. Select Detail/Identi er and select the
attribute \project name" for the primary identier.
9. Select Diagram/Save Model to ensure your changes have been saved.
10. Enter the entity Document using the information detailed in Section E.6.1.
11. Enter the entity Deliverable using the information detailed in Section E.6.1.
12. The next entity to enter is Milestone. When you have added the Milestone entity select
Detail/Attributes. Select the entity name Milestone then Edit/Copy. Select the entity to
copy from, Deliverable, select the attribute Expected Delivery Date and select OK . The
Edit selection Transfer allows you to transfer attributes from another entity to the entity you
are currently editing.
102
13. To establish a relationship between two entities return to the Data Model tool and select
View/Home. Select the Project entity. Select View/Search and enter Document as the
search criteria. Select Search . When the search has been successful select Close .
While holding the control key, select the Document entity. Select Edit/Join. The dialog
box for the relationship information will appear. Input the \is described by" and \describes
project" relationship information (see below) and select OK .
Note - it is not necessary to use the Search tool, this makes it easier when the
entities are not displayed on the screen at the same time.
14. Select Src Prop and enter the cardinality provided in Section E.6.1.
15. Select Dst Prop and enter the information provided.
16. Follow the same procedure for the rest of entities and relationships in the DPMIS entity
information in Section E.6.1.
17. Relationship lines can be moved to change their shape and position to enable the relationship
name to be more legible both on the screen and on the printed output. Select a relationship
line in your ERD and then select Edit/Move. Click on the new place of attachment for the
relationship line.
Note - this cannot be used to transfer relationships between entities.
18. After you have completed the Data Model click on the background of the ERD then select
Diagram/Check. The IEF will create a consistency check report. Review this report and
correct the data model until it passes the Consistency Check.
19. Redraw Diagram or Redraw Lines in the Data Model automatically redraw the diagram or
lines. If you have been working in the diagram select View/Deselect All, otherwise the option
to Redraw Diagram will not be accessible. Select View/Redraw and the IEF will automatically
redraw the diagram.
Note - changes made to lines in the ERD will be lost when you select Redraw
Diagram.
103
E.6.1 Entities, Attributes and Relationships
Deliverable
Description
Deliverables representing specic Documents, Prototypes and Presentations and their respective
delivery dates exist for each Project.
Expected Number of Occurrences
Minimum 1
Average 6
Maximum 99
Expected Growth
1 - 2 % per year
Attributes
Name (identifying attribute), Mandatory Basic Text, Length: 50
Expected Delivery Date, Optional Basic Date, Length: 8
Actual Delivery Date, Optional Basic Date, Length: 8
Description, Optional Basic Text, Length: 254
Comments, Optional Basic Text, Length: 254
Type, Optional Basic Text, Length: 18 Values: Document (default), Prototype, Presentation
Relationships
Always IS MILESTONE (one) Milestone.
Always IS DELIVERABLE OF (one) Project. can transfer.
Sometimes (50 %) DEPENDS ON (one or more) Deliverable Cardinality Min: 0 (est) Max:
5 (est) Avg: 1 cannot transfer.
Sometimes (50 %) ESSENTIAL FOR (one or more) Deliverable Cardinality Min: 0 (est)
Max: 5 (est) Avg: 2 cannot transfer.
Sometimes(95 %) IS DOCUMENT (one) Document. can transfer.
104
Document
Description
Documents will represent information about the current Projects.
Expected Number of Occurrences
Minimum 1
Average 100
Maximum 1000
Expected Growth
1 % per year
Attributes
Title (identifying attribute), Mandatory Basic Text, Length: 50
Date, Optional Basic Date, Length: 8
Abstract, Optional Basic Text, Length: 254
Keywords (1 through 5), Mandatory Basic Text, Length: 20
Keywords (6 through 10), Optional Basic Text, Length: 20
Type, Optional Basic Text, Length: 25 Values: Project Report, Component Documentation, Journal Publication, Conference Publication, Working Paper, Technical Report, Minutes, Proposal, Manual
Relationships
Always DESCRIBES PROJECT (one) Project. cannot transfer.
Sometimes (95 %) IS DELIVERABLE (one) Deliverable. can transfer.
Sometimes (75 %) IS MILESTONE (one) Milestone. can transfer.
Milestone
Description
Milestones representing signicant development events exist for each Project.
Expected Number of Occurrences
Minimum 1
Average 30
105
Maximum 99
Expected Growth
2 % per year
Attributes
Name (identifying attribute), Mandatory Basic Text, Length: 30
Expected Delivery Date, Optional Basic Date, Length: 8
Actual Delivery Date, Optional Basic Date, Length: 8
Type, Optional Basic Text, Length: 15 Values: Hiring, Documentation, Demonstration,Meeting,
Deliverable and Other)
Description, Optional Basic Text, Length: 254
Relationships
Always IS MILESTONE OF PROJECT (one) Project. cannot transfer.
Sometimes (95 %) IS DELIVERABLE (one) Deliverable. cannot transfer.
Sometimes (70 %) IS A DOCUMENT (one) Document. cannot transfer.
Project
Description
Projects are research projects being conducted by organizations at various Sites in Canada, the
United States and Europe.
Expected Number of Occurrences
Minimum 1
Average 10
Maximum 99
Expected Growth
5 % per year
Attributes
Project Name (identifying attribute), Mandatory Basic Text, Length: 30
Description, Optional Basic Text, Length: 254
106
Start Date, Optional Basic Date, Length: 8
Completion Date, Optional Basic Date, Length: 8
Status, Mandatory Basic Text, Length: 10 Values: on-time, suspended, behind, completed
Relationships
Always HAS MILESTONE (one or more) Milestone. Cardinality Min: 1 (est) Max:
99 (est) Avg: 30) cannot transfer.
Always HAS DELIVERABLES (one or more) Deliverables. Cardinality Min: 1 (est)
Max: 99 (est) Avg: 6 cannot transfer.
Sometimes (95 %) IS DESCRIBED BY DOCUMENT (one or more) Document Cardinality
Min: 1 (est) Max: 100 (est) Avg: 100 cannot transfer.
Sometimes (10 %) HAS RELATION TO (one or more) Project Cardinality Min: 1 0 (est)
Max: 5 (est) Avg: 1 cannot transfer.
Sometimes (10 %) IS RELATED TO (one) Project can transfer.
107
E.7 Tutorial 3 - Activity Hierarchy Diagram
The Activity Hierarchy tool allows you to create an activity hierarchy diagram (AHD) which displays
the function and process hierarchy for the system under development. The following rules apply to
the creation of the AHD.
Functions in an IEF AHD may have subordinate functions or processes.
Processes in an IEF AHD may only have subordinate processes or elementary processes.
Elementary Processes in an IEF AHD may not have any subordinates.
1. Select Planning/Activity Hierarchy. The dialog box to enter the root function information
will appear. Enter the root name, Distributed Project Management and the description from
Section E.7.1.
2. Select Options/Multiple Adds.
3. Select the root function then Edit/Add Process. Enter the process name, \Information Maintenance" in the dialog box. The process should be entered as on-line, not elementary and
not repetitive. A description of the process can be entered by clicking on Desc... . Enter the
process \Information Retrieval".
4. Select the process, Information Maintenance and the next level of processes as indicated
in the IEF Activity Hierarchy Report included as Section E.7.2. Repeat this for the Information Retrieval hierarchy.
5. Select the process, Project Maintenance and enter the elementary processes for project
maintenance as indicated in the IEF Activity Hierarchy Report included as Section E.7.2.
Remember to select elementary in the dialog box.
6. Select the root function for the Activity Hierarchy Diagram, then Diagram/Chain/Dependency
Diagram. A window for the Activity Dependency Diagram will appear. The diagram has been
automatically populated by the IEF. Select Diagram/Exit to return to the Activity Hierarchy
Diagram.
7. Select the root function, then Edit/Modify. The processes immediately subordinate, \Information Maintenance" and \Information Retrieval" will be changed to functions. Select
Edit/Modify again to return these functions to processes. Modify will only work when the
activity selected is a function and elementary processes cannot be changed.
8. Expected Eects of the functions and processes detailed in the AHD can be specied at
this point, however, if you utilize the IEF action block synthesis the expected eects will
be set by the IEF. To detail expected eects select the Add Project elementary process,
Detail/Expected Eects. Select the entity Project in the lower box and select it again in
the upper box when it appears there. Select Chg Read , Chg Create . The other expected
eects of the process Add Project, as listed in Section E.7.1, can be entered at this point.
Select Close .
108
9. View Maintenance can be started at this point as well but it can also be left for the IEF to
detail during action block synthesis. View Maintenance is reviewed in the tutorial for Screen
Design.
10. Select Diagram/Save Model and Diagram/Exit.
109
E.7.1 Function and Process Descriptions
Distributed Project Management
A set of applications to support the information requirements necessary to track the progress,
status and descriptive details of Projects spanning multiple Sites, including: denition of Projects
which span multiple Sites, denition of Projects which are local to Sites permit the update of
Projects, Sites, Milestones and Members by Project leaders, permit the update of Documents and
Deliverables by Members responsible for each, and permit any Project member to browse and/or
retrieve information about any project and its related entities.
Information Maintenance
Information Maintenance is a process in the Distributed Project Management function hierarchy
which, with the support of its subordinate processes enables the creation, update and deletion of
all entities identied in the Data Model.
Project Maintenance
Project Maintenance is a process in the Information Maintenance process hierarchy which, with
the support of its subordinate elementary processes enables the creation, update and deletion of
Projects in the DPMIS database.
Add Project is an elementary process in the Project Maintenance process hierarchy. This process
enables the creation of new projects in the DPMIS database. Expected Eects Project: create,
update Site: update, read Milestone: create, update, read Member: update, read Deliverable:
create, update, read
Update Project is an elementary process in the Project Maintenance process hierarchy. This
process enables the update of projects in the DPMIS database.
Delete Project is an elementary process in the Project Maintenance process hierarchy. This
process enables the deletion of projects from the DPMIS database.
Site Maintenance
Site Maintenance is a process in the Information Maintenance process hierarchy which, with the
support of its subordinate elementary processes enables the creation, update and deletion of Sites
in the DPMIS database.
Add Site is an elementary process in the Site Maintenance process hierarchy. This process enables
the creation of Sites in the DPMIS database.
Update Site is an elementary process in the Site Maintenance process hierarchy. This process
enables the update of Sites currently included in the DPMIS database.
Delete Site is an elementary process in the Site Maintenance process hierarchy. This process
enables the deletion of Sites from the DPMIS database.
110
Member Maintenance
Member Maintenance is a process in the Information Maintenance process hierarchy which, with
the support of its subordinate elementary process enables the creation, update and deletion of
Members in the DPMIS database.
Add Member is an elementary process in the Member Maintenance process hierarchy which
enables the creation of Members in the DPMIS database.
Update Member is an elementary process in the Member Maintenance process hierarchy which
enables the update of Members currently in the DPMIS database.
Delete Member is an elementary process in the Member Maintenance process hierarchy which
enables the deletion of Members from the DPMIS database.
Milestone Maintenance
Milestone Maintenance is a process in the Information Maintenance process hierarchy which, with
the support of its subordinate elementary processes enables the creation, update and deletion of
Milestones in the DPMIS database.
Add Milestone is an elementary process in the Milestone Maintenance process hierarchy which
enables the creation of Milestones in the DPMIS database.
Update Milestone is an elementary process in the Milestone Maintenance process hierarchy
which enables the update of Milestones in the DPMIS database.
Delete Milestone is an elementary process in the Milestone Maintenance process hierarchy which
enables the deletion of Milestones in the DPMIS database.
Deliverable Maintenance
Deliverable Maintenance is a process in the Information Maintenance process hierarchy which, with
the support of its subordinate elementary processes enables the creation, update and deletion of
Deliverables in the DPMIS database.
Add Deliverable is an elementary process in the Deliverable Maintenance process hierarchy
which enables the creation of Milestones in the DPMIS database.
Update Deliverable is an elementary process in the Deliverable Maintenance process hierarchy
which enables the update of Milestones in the DPMIS database.
Delete Deliverable is an elementary process in the Deliverable Maintenance process hierarchy
which enables the deletion of Milestones in the DPMIS database.
111
Document Maintenance
Document Maintenance is a process in the Information Maintenance process hierarchy which, with
the support of its subordinate elementary processes enables the creation, update and deletion of
Documents in the DPMIS database.
Add Document is an elementary process in the Document Maintenance process hierarchy which
enables the creation of Documents in the DPMIS database.
Update Document is an elementary process in the Document Maintenance process hierarchy
which enables the update of Documents in the DPMIS database.
Delete Document is an elementary process in the Document Maintenance process hierarchy
which enables the deletion of Documents in the DPMIS database.
Information Retrieval
The Information Retrieval is a process in the Distributed Project Management function hierarchy.
Information Retrieval enables retrieval of information regarding all current Projects and related
entities.
Project Information Retrieval
Project Information Retrieval is an elementary process in the Information Retrieval process hierarchy which enables the retrieval of information regarding Projects currently entered in the DPMIS
database.
Site Information Retrieval
Site Information Retrieval is an elementary process in the Information Retrieval process hierarchy
which enables the retrieval of information regarding Sites currently included in the DPMIS database.
Member Information Retrieval
Member Information Retrieval is an elementary process in the Information Retrieval function hierarchy which enables the retrieval of information for Members currently included in the DPMIS
database.
Milestone Information Retrieval
Milestone Information Retrieval is an elementary process in the Information Retrieval function
hierarchy which enables retrieval of information for Milestones currently included in the DPMIS
database.
112
Deliverable Information Retrieval
Deliverable Information Retrieval is an elementary process in the Information Retrieval hierarchy which enables the retrieval of information for Deliverables currently included in the DPMIS
database.
Document Information Retrieval
Document Information Retrieval is an elementary process in the Information Retrieval process
hierarchy which enables the retrieval of information for Documents currently included in the DPMIS
database.
113
E.7.2 IEF Activity Hierarchy Report
Activity Hierarchy
Model : DISTRIBUTED PROJECT MANAGEMENT
Subset: ALL
Jun. 07, 1994 10:40
Function 1
DISTRIBUTED_PROJECT_MANAGEMENT
Process
2
1 INFORMATION_MAINTENANCE
Process
3
1.1 PROJECT_MAINTENANCE
Elem Proc 4
1.1.1 ADD_PROJECT
Elem Proc 4
1.1.2 UPDATE_PROJECT
Elem Proc 4
1.1.3 DELETE_PROJECT
Process
3
1.2 SITE_MAINTENANCE
Elem Proc 4
1.2.1 ADD_SITE
Elem Proc 4
1.2.2 UPDATE_SITE
Elem Proc 4
1.2.3 DELETE_SITE
Process
3
1.3 MEMBER_MAINTENANCE
Elem Proc 4
1.3.1 ADD_MEMBER
Elem Proc 4
1.3.2 UPDATE_MEMBER
Elem Proc 4
1.3.3 DELETE_MEMBER
Process
3
1.4 MILESTONE_MAINTENANCE
Elem Proc 4
1.4.1 ADD_MILESTONE
Elem Proc 4
1.4.2 UPDATE_MILESTONE
Elem Proc 4
1.4.3 DELETE_MILESTONE
Process
3
1.5 DELIVERABLE_MAINTENANCE
Elem Proc 4
1.5.1 ADD_DELIVERABLE
Elem Proc 4
1.5.2 UPDATE_DELIVERABLE
Elem Proc 4
1.5.3 DELETE_DELIVERABLE
Process
3
1.6 DOCUMENT_MAINTENANCE
Elem Proc 4
1.6.1 ADD_DOCUMENT
Elem Proc 4
1.6.2 UPDATE_DOCUMENT
Elem Proc 4
1.6.3 DELETE_DOCUMENT
Process
2
2 INFORMATION_RETRIEVAL
2.1 PROJECT_INFORMATION_RETRIEVAL
Elem Proc 3
Elem Proc 3
2.2 SITE_INFORMATION_RETRIEVAL
Elem Proc 3
2.3 MEMBER_INFORMATION_RETRIEVAL
Elem Proc 3
2.4 MILESTONE_INFORMATION_RETRIEVAL
Elem Proc 3
2.5 DELIVERABLE_INFORMATION_RETRIEVAL
Elem Proc 3
2.6 DOCUMENT_INFORMATION_RETRIEVAL
-End of Report-
114
E.8 Tutorial 4 - Activity Dependency Diagram
The Activity Dependency Diagram (ADD) is accessible from both the Planning and Analysis toolsets
and can be accessed by chaining from the Activity Hierarchy Diagram (AHD).
The ADD will have been automatically populated by the IEF during construction of the Activity
Hierarchy Diagram (AHD). The tasks necessary to complete this diagram are inserting process
dependencies and the addition of any Events and External Objects required for the ADD.
1. Select Analysis/Activity Dependency. The rst level of processes will be displayed in the
ADD, Information Maintenance and Information Retrieval.
2. Select the Information Maintenance process, then control-select the Information Retrieval process. Select Edit/Join and the IEF will insert a dependency line from Information
Maintenance to Information Retrieval.
3. Select the dependency you have just created and Detail/Properties. Enter the dependency
name \Database information available". Enter the description, \The database information
must exist to allow retrieval of the information."
4. Select Diagram/Save Model to save the changes you have made to the ADD.
5. To complete the dependency diagram select Information Maintenance, then Diagram/Chain/Dependency
Diagram. The IEF will display the rst process level subordinate to Information Maintenance. Enter the process dependencies listed in Section E.8.1.
6. Select Diagram/Save Model to save the changes you have made.
7. Select Member Maintenance, then Diagram/Chain/Dependency Diagram. The IEF will
now display the elementary processes subordinate to Member Maintenance.
8. Update Member and Delete Member are dependent in parallel on Add Member. To
add the parallel dependency rst join the Add Member and Update Member processes
as above. Select the dependency line created then control-select Delete Member followed
by Edit/Join Parallel and the parallel dependency line will be displayed.
9. The dependencies can be created for the other processes and elementary processes in the
AHD created.
10. With the selection Redraw Diagram in the ADD the IEF automatically redraws the diagram.
11. Return to the rst process level of the AHD and select Information Retrieval. Select Diagram/Chain/Dependency Diagram. Select the background of the diagram. Select
Edit/External Object. Select Add in the dialog box that appears. Enter the external object name \Project Management Database Info". Select OK . Select \Project Management
Database Info" followed by Select . A double red box will appear on your ADD. Establish
the dependencies from the external object to the ADD processes.
115
12. Select a spot on the ADD background and then Edit/Add Event. Enter the event name as
\temp". Select OK . A large red arrow will be displayed on the ADD. Select Edit/Delete,
OK , Yes to remove this from your diagram.
13. Select Diagram/Save Model.
116
E.8.1 Process Dependencies
The following are the dependencies which should be included in the Activity Dependency Diagrams
(ADD) for the DPMIS. The dependency name is given followed by the the name of process which
precedes the dependent process.
Information Maintenance
Deliverable Maintenance
Respective project exists (Project Maintenance)
Responsible member exists (Member Maintenance) Respective milestone exists (Milestone Maintenance)
Document Maintenance
Member author exists (Member Maintenance) Described project exists (Project Maintenance)
Member Maintenance
Site available for aliation (Site Maintenance)
Milestone Maintenance
Project exists (Project Maintenance)
Project Maintenance
Deliverable exists (Deliverable Maintenance) Site available (Site Maintenance) Milestone exists
(Milestone Maintenance) Member available (Member Maintenance)
Site Maintenance
No dependencies are present for Site Maintenance.
Elementary Processes
The elementary processes in the Information Hierarchy all follow the same dependency patterns.
In all situations the Update and Delete processes are dependent, in parallel on the Add process.
For each group of elementary processes the dependency name should be: \entity name has been
created".
Information Retrieval
All elementary processes in the Information Retrieval hierarchy are dependent on the External
Object \Project Management Database Info". For each processes the dependency name should be:
\entity name info exists".
117
E.9 Tutorial 5 - Process Action Diagrams
The Action Diagram tool in the IEF Analysis toolset enables the creation of action diagrams for the
elementary processes you have identied. These can be created statement by statement or by use
of the action block synthesis available in the IEF. This tutorial will utilize the action block synthesis
to create the elementary processes for the DPMIS. The use of this synthesis will automatically
identify expected eects and views for the processes.
1. Select Analysis/Activity Hierarchy. Select Project Maintenance, then View/Expand All.
When IEF has expanded the Project Maintenance hierarchy select the elementary process
Add Project. Select Diagram/Chain/Action Diagram.
2. Select Edit/Action Block Synthesis. Ensure the Mode option is set at Create. Select Entity
Type PROJECT then OK .
The IEF will present a dialog box for Create of: PROJECT that contains a list of related
entity types and their relationships with the Project entity type. The expected eects of
Create and Read can be adjusted here if necessary. Select OK .
The IEF will display another dialog box for Identi er Selection. Select the primary identier,
then OK .
The IEF will display further Create of: and Identi er Selection dialog boxes. Select OK as
these are displayed.
The IEF will generate an action diagram for the elementary process Add Project. Views
and expected eects are identied by the IEF when you utilize the Action Block Synthesis.
3. Use Action Block Synthesis to generate the action diagrams for Update Project and Delete
Project. Ensure the correct Mode is selected before continuing with the synthesis. An examples of the process action diagram for the elementary processes, Add Project is included in
Section E.9.1.
4. Use Action Block Synthesis to generate an action diagram for an additional action block
Display Project. Ensure the Mode option is set at Read.
5. Action Block Synthesis can be utilized to create PAD's for all the elementary processes included in the AHD.
6. Expand Expected Eects can be utilized to create portions of the PAD if expected eects have
been detailed in the Activity Hierarchy tool. If expected eects have not been detailed an
IEF fatal error will result, followed by an abnormal exit from the IEF and all of your changes
will be lost.
118
E.9.1 Sample IEF Process Action Diagrams
Model : DISTRIBUTED PROJECT MANAGEMENT
Subset: ALL
Jun. 07, 1994
10:39
Process: ADD_PROJECT
___________________________________________________________________________
Process Description:
Add Project is an elementary process in the Project Maintenance process hierarchy.
facilitate creation of a new project in the DPMIS database.
Usage of this process is estimated at: min 1, avg 10, max 99 per year,
with an estimated yearly growth rate of 5%.
Action Block Description:
1
2
2
2
2
3
2
4
5
5
5
5
5
5
6
7
7
7
7
8
9
+|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ADD_PROJECT
IMPORTS: ...
EXPORTS: ...
LOCALS:
ENTITY ACTIONS: ...
+- IF current_user_in member surname IS EQUAL TO leader member surname
|
AND current_user_in member first_name IS EQUAL TO leader member
|
first_name
|
OR leader member surname IS EQUAL TO SPACES
| MOVE current_user_in member TO leader member
+-+- IF leader member surname IS NOT EQUAL TO SPACES
| +- READ stored_leader member
| |
WHERE DESIRED stored_leader member surname IS EQUAL TO
| |
leader member surname
| |
AND DESIRED stored_leader member first_name IS EQUAL TO
| |
leader member first_name
| +- WHEN successful
| | +- IF import site organization IS NOT EQUAL TO SPACES
| | | +- READ stored site
| | | |
WHERE DESIRED stored site organization IS EQUAL TO
| | | |
import site organization
| | | +- WHEN successful
| | | | +- CREATE stored project
| | | | | SET start_date TO import project start_date
119
This proces
10
11
12
13
14
15
16
16
17
17
8
18
19
19
19
19
20
21
21
22
22
22
22
22
23
24
24
25
25
22
26
27
27
28
28
29
29
30
31
26
32
26
33
26
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
+|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SET project_name TO import project project_name
SET completion_date TO import project completion_date
SET status TO import project status
SET description TO import project description
ASSOCIATE WITH stored site WHICH has_project IT
ASSOCIATE WITH stored site WHICH is_primary_location_for IT
ASSOCIATE WITH stored_leader member
WHICH is_member_of_project IT
ASSOCIATE WITH stored_leader member
WHICH coordinates_project IT
WHEN successful
MOVE stored project TO export project
+- READ stored milestone
|
WHERE DESIRED stored milestone milestone_name
|
IS EQUAL TO import milestone milestone_name
+- WHEN successful
| MOVE stored milestone TO export milestone
| ASSOCIATE stored milestone
|
WITH stored project WHICH has_milestone IT
| +- READ stored deliverable
| |
WHERE DESIRED stored deliverable
| |
deliverable_name IS EQUAL TO
| |
import deliverable deliverable_name
| +- WHEN successful
| | MOVE stored deliverable TO export deliverable
| | ASSOCIATE stored deliverable
| |
WITH stored milestone WHICH is_deliverable IT
| | ASSOCIATE stored deliverable
| |
WITH stored project WHICH has_deliverables IT
| +- WHEN not found
| | +- CREATE stored deliverable
| | | SET deliverable_name TO import deliverable
| | |
deliverable_name
| | | ASSOCIATE WITH stored_leader member
| | |
WHICH is_responsible_for IT
| | | ASSOCIATE WITH stored_leader member
| | |
WHICH works_on IT
| | | ASSOCIATE WITH stored milestone WHICH is_deliverable IT
| | | ASSOCIATE WITH stored project WHICH has_deliverables IT
| | +- WHEN successful
| | | MOVE stored deliverable TO export deliverable
| | +- WHEN already exists
| | | EXIT STATE IS deliverable_ae WITH ROLLBACK
| | +- WHEN permitted value violation
120
34
26
22
19
35
36
37
35
38
39
39
39
39
39
40
41
41
42
42
39
43
44
44
45
46
47
48
43
49
43
50
43
51
43
39
35
52
35
53
35
19
8
54
8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
+|
+-
| | | EXIT STATE IS deliverable_pv WITH ROLLBACK
| | +-| +-+- WHEN not found
| +- CREATE stored milestone
| | SET milestone_name TO import milestone milestone_name
| | ASSOCIATE WITH stored project WHICH has_milestone IT
| +- WHEN successful
| | MOVE stored milestone TO export milestone
| | +- READ stored deliverable
| | |
WHERE DESIRED stored deliverable
| | |
deliverable_name IS EQUAL TO
| | |
import deliverable deliverable_name
| | +- WHEN successful
| | | MOVE stored deliverable TO export deliverable
| | | ASSOCIATE stored deliverable
| | |
WITH stored milestone WHICH is_deliverable IT
| | | ASSOCIATE stored deliverable
| | |
WITH stored project WHICH has_deliverables IT
| | +- WHEN not found
| | | +- CREATE stored deliverable
| | | | SET deliverable_name TO import deliverable
| | | |
deliverable_name
| | | | ASSOCIATE WITH stored_leader member WHICH is_responsible_fo
| | | | ASSOCIATE WITH stored_leader member WHICH works_on IT
| | | | ASSOCIATE WITH stored milestone WHICH is_deliverable IT
| | | | ASSOCIATE WITH stored project WHICH has_deliverables IT
| | | +- WHEN successful
| | | | MOVE stored deliverable TO export deliverable
| | | +- WHEN already exists
| | | | EXIT STATE IS deliverable_ae WITH ROLLBACK
| | | +- WHEN permitted value violation
| | | | EXIT STATE IS deliverable_pv WITH ROLLBACK
| | | +-| | +-| +- WHEN already exists
| | EXIT STATE IS milestone_ae WITH ROLLBACK
| +- WHEN permitted value violation
| | EXIT STATE IS milestone_pv WITH ROLLBACK
| +-+-WHEN already exists
EXIT STATE IS project_ae WITH ROLLBACK
WHEN permitted value violation
121
55
8
7
56
7
6
57
6
5
58
5
4
59
4
| | | | | | EXIT STATE IS project_pv WITH ROLLBACK
| | | | | +-| | | | +- WHEN not found
| | | | | EXIT STATE IS site_nf WITH ROLLBACK
| | | | +-| | | +- ELSE
| | | | EXIT STATE IS site_nf WITH ROLLBACK
| | | +-| | +- WHEN not found
| | | EXIT STATE IS member_nf WITH ROLLBACK
| | +-| +- ELSE
| | EXIT STATE IS member_nf WITH ROLLBACK
| +-+--
122
E.10 Tutorial 6 - Business System Defaults
Business System Defaults allows the user to set up defaults for the business system under denition.
1. Select Analysis/Business System De nition. The IEF will automatically perform a consistency check and the business system process hierarchy will be displayed. Select Diagram/Save
Model, then Diagram/Exit.
2. Select Design/Business System Defaults.
3. Select Options/Multiple Adds.
4. Select ** Business System DISTRIBUTED.
5. Select Detail/Commands and then Add . Enter the commands, ADD, CANCEL, DELETE,
DISPLAY, HELP, UPDATE, and RETURN in the box displayed. Select Cancel to exit the
add dialog box.
6. Select Detail/Exit States. Select <Global Exit States> and then select Expand/Cntrct.
Select Add . Add the exit state \link to information maintenance" leaving the default settings, click OK . Ensure the exit states listed below are all included in the global exit states.
Select Close . Exit states will have been automatically added by the IEF during process or
action block synthesis.
Link to Deliverable Maintenance
Link to Deliverable Retrieval
Link to Document Maintenance
Link to Document Retrieval
Link to Maintenance
Link to Member Maintenance
Link to Member Retrieval
Link to Milestone Maintenance
Link to Milestone Retrieval
Link to Project Maintenance
Link to Project Retrieval
Link to Site Maintenance
Link to Site Retrieval
Link to Retrieval
7. Select Detail/Function Keys. Select key number one (1). Select Prop.. . Select the command
HELP from the list displayed. Select \Default" as the type and select Display on PFKey line.
Select OK . Select Close .
123
8. Enter the default function key assignments listed below. ENTER ENTER
F1 HELP
F2 ADD
F3 UPDATE
F4 DELETE
F5 LIST
F6 DISPLAY
F11 CANCEL
F12 RETURN
9. Select Detail/Special Edit Patterns. Select SYSDATE Date MM-DD-YY, then Prop... . Change
the edit pattern to \YY-MM-DD". Select OK then Close .
10. Select Detail/Field Edit Patterns. Change the DATE edit pattern to \YY-MM-DD". Select
OK , then Close .
11. Parameter Delimiters and String Separators can be selected in the option Detail/Delimiters.
The settings can be left at the default settings.
124
E.11 Tutorial 7 - Dialog Flow Diagram
Dialog Design allows you to identify the procedures and procedure steps in the business system
under development and to detail the ow of control and data between procedures and procedures
steps.
Procedures and procedure steps implement the processes identied during the Analysis phase
of development.
1. Select Design/Dialog Design.
2. Select Edit/Add Procedure. Enter the procedure name Maintain Project and a description
of the procedure.
3. Select OK . The procedure will appear as a blue line on the screen. Select Options/Multiple
Adds and add the following procedures to the diagram.
Maintain Site
Maintain Member
Maintain Milestone
Maintain Deliverable
Maintain Document
Site Information Retrieval
Member Information Retrieval
Milestone Information Retrieval
Deliverable Information Retrieval
Document Information Retrieval
Project Information Retrieval
To quit the add procedure select Cancel .
4. Select the procedure Menu and then Edit/Move. Move this procedure to the top of the
screen.
5. Select Edit/Add Procedure Step and add the procedure steps Maintenance Menu and Retrieval Menu.
6. Select Maintenance Menu and then control-select the procedure step Maintain Project.
Select Edit/Join. A dialog box will appear to enter the information for a dialog ow between
the two procedures. Enter the dialog ow as a link. The Set Command and Return Command
options can be left as is for this ow, however, these may be selected to set a command for
the ow to the other procedure or procedure step and on return from the procedure step.
The selections for Execute First and Display First can be left at Execute First for this link.
Select OK .
125
7. Select the dialog ow you have just created and then Detail/Flows On. Click on Exit State .
The Exit States options will be displayed. Click on global exit states then Expand/Contract .
Click on global exit states then Add . Enter the Exit State name \link to information maintenance". Select Select .
8. Detail/Flow Maintenance allows you to add and edit ows connecting procedures and procedures steps. Select the procedure step Maintenance Menu then select Detail/Flow Maintenance. Select Edit/Add Flow Out. A dialog box to Select Procedure Step will be displayed.
Select the business system Distributed Project Management and the procedure Maintain Member. The IEF dialog box to enter ow information will be displayed. Enter this
ow as a link, owing on exit state, \link to member maintenance" and returning on \return".
The other options in this box can be left at the default settings.
9. Enter the other ows detailed in the Dialog Flow Diagram (Figure 10) using either of the
above methods. All ows can be entered as links with exit states of the form \link to project
maintenance".
10. Select the procedure Menu then View/Contract. The procedure steps in the menu procedure
will be contracted into the procedure and will no longer appear on the diagram.
11. Select the procedure Maintain Milestone then View/Neighbors. The IEF will display only
the Maintain Milestone procedure and those procedures and procedure steps with ows
connecting them to Maintain Milestone. Select View/Show All to return to the original
view of the dialog ow diagram.
12. Select the ow from Main Menu to Maintenance Menu. Select Detail/Flows On. Select
the exit state \link to maintenance", select Autoow . Select the command MAINTAIN.
Select OK . Select Close . Set the Returns On autoow to the command RETURN.
13. Select the dialog ow from Main Menu to Retrieval Menu and set the Flows On autoow
to the command RETRIEVE and the Returns On autoow to RETURN.
Autoows can be included for all ows between procedures and procedure steps, however, for
this tutorial these are the only Autoows to be included. These Autoows will be utilized to
demonstrate the functionality of the IEF Prototyping tool.
14. External Flow In and External Flow Out which can be accessed in the Detail submenu are
used to create ows to and from procedures which are not included in the current business
system. These are not applicable to the DPMIS.
126
MENU
MAIN MENU
MAINTENANCE ME>
RETRIEVAL MENU
MAINTAIN PROJE>
MAINTAIN SITE
MAINTAIN MEMBER
MAINTAIN MILES>
MAINTAIN DELIV>
MAINTAIN DOCUM>
SITE INFO RETR>
SITE RETRIEVAL
SITE LIST
MEMBER INFO RE>
MEMBER RETRIEV>
MEMBER LIST
MILESTONE RETR>
MILESTONE RETR>
MILESTONE LIST
DELIVERABLE IN>
DELIVERABLE RE>
DELIVERABLE LI>
DOCUMENT INFO >
DOCUMENT RETRI>
DOCUMENT LIST
PROJECT INFO R>
PROJECT RETRIE>
PROJECT LIST
Figure 10: Dialog Flow Diagram (DFD)
127
E.12 Tutorial 8 - Procedure Action Diagrams
1.
2.
3.
4.
5.
6.
7.
Select Design/Dialog Flow.
Select the procedure Maintain Project.
Select Detail/Procedure Synthesis.
Select Edit/Stereotype.
Select Entity Maintenance.
In the window that appears for stereotype select the Action Block Display.
Select Edit/Select. The listing of action blocks will be displayed. Select the action block
Display Project.
8. Select the action blocks for create, update and delete as follows:
Create : Add Project
Update : Update Project
Delete : Delete Project
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
Select the Screen Identi er Attribute View.
Select Edit/Select and select the IMPORT Project Project Name view.
Select Edit/Options and review the options available. These can be left at the default settings.
Select Edit/Apply and the IEF automatically generates the stereotype.
Select the rst when successful line in the action diagram, then View/Contract. The IEF will
contract all the statements within the when successful.
Select the three ellipses which will then represent the contracted statements. Select Edit/Move
and select the statement EXIT STATE IS member nf. The contracted statements will
be moved and expanded to this location.
Select Edit/Move and return the statements to their original position.
Select the statement MOVE member TO export member, then select Edit/Add Blank
Line. The IEF will insert a blank line following the selected statement.
FOR and IF statements can be contracted by selecting the FOR or IF lines of the statements.
Select the blank line above the rst statement of the action diagram, then select Edit/Add
Statement. Select Read. Select member from the entity list displayed then select Qualify ,
select attribute view, select DESIRED persistent view, select IS EQUAL TO, select
character view, select transient view, select import member. Finally select Add . The
IEF will include the read statement in the action diagram.
128
19. Select the read statement that has been added. The entire statement must be selected,
including the when successful and when not found lines. Select Edit/Delete Statement and
then YES .
20. Select Diagram/Save Model, then select Diagram/Exit.
129
E.13 Tutorial 9 - Screen Design
Screen Design allows you to create the user interface for the business system. Screens can be
designed for procedures and procedure steps.
1. Select Design/Screen Design. Select Cancel in the dialog box that appears. Select Diagram/New. The dialog box for template creation appears. Enter the template name DPMIS.
2. Select Edit/Add Special. Select the special eld Transaction Code and place this in the upper
left corner of the screen. Transaction codes are necessary for the IEF Construction tool and
must precede all other elds on the screen.
3. Select Edit/Add Literal. Enter the literal, \Distributed Project Management Information
System". Video properties can be set for the literal by selecting Prop... but the default
settings are acceptable for this screen. Select OK . Place this literal at the top of the screen.
4. Select the literal just entered and then Edit/Center. The IEF will center the literal on the
line.
5. Enter the special elds Current Time and Current Date in the upper right corner of the screen.
6. Enter the special eld System Error Message on the bottom line of the eld and the special
eld Program Function Keys immediately above it.
7. Select Diagram/Save Model. Select Diagram/Exit. This template can be utilized for the menu
screens you will be creating.
8. Select Design/Screen Design and select the Menu procedure.
9. Select Detail/Uses and select the template DPMIS. This template will be displayed on the
screen by the IEF and further construction of this screen can continue.
10. Enter the literals: \Main Menu", \1. Maintenance Menu", \2. Retrieval Menu", \3. Exit
DPMIS".
11. Select Detail/View Maintenance. Select Import Views. Select Edit/Add Work View. Enter the
name Import and leave the \is Sometimes used as input" set as it is. Select IEF Supplied
and Action Entry. Select OK .
12. Select the import view you have just added then Edit/Copy. Select Export Views. Select
Diagram/Exit.
13. Select Edit/Add Field. Select the export eld IEF Supplied. In the Field De nition dialog box
that appears enter the prompt \ENTER SELECTION:" in the prompt denition area. Set
Display Length to one (1). All the other default settings can be left as is. Select OK .
The IEF will allow you to position rst the prompt and then the input eld. Leave a blank
line above the \PFKey" line and position these in the lower left corner of the screen.
130
14. Function key assignments can be made for each screen that are local to that screen. Select
Detail/PFK/Commands. Select function key ve (5) and assign it the command MAINTAIN. Select function key six (6) and assign it the command RETRIEVE. For each of
these assignment properties select display on PFKey line.
15. Select Diagram/Save Model. Select Diagram/Chain/Prototyping and the IEF will display the
prototype of the screen.
16. Complete the screen design for the procedure steps Information Maintenance and Information Retrieval.
17. When the menu procedure steps have been dened select Diagram/Exit.
18. Select Diagram/Dialog Design and select the Menu procedure. Select Diagram/Chain/Prototyping.
When the prototype for the Main Menu screen appears press the function key F5 to transfer
to the Information Maintenance Menu screen and then F11 to return to the Main Menu
screen. F6 will access the Information Retrieval Menu. Utilized this way prototyping
can help you ensure that the order of screens is correctly designed.
131
E.14 Tutorial 10 - Construction
The IEF Construction Toolset for the OS/2 version of the IEF generates and installs the data
denition language (DDL) and the code for the information system.
1. Select User Pro le Management Services and Logon.
2. Enter USERID and PASSWORD for the user id and password.
3. Select Model/Open from the IEF menu bar.
4. Select the model, \Distributed Project Management Information System", then Open .
5. Select Construction/Environment.
6. Enter the following settings for the environment parameters.
Operating System: OS/2
DBMS: DBM
Language: C
TP Monitor: IEFAE
Prole Manager: SQL
Screen Type: Bypass
Clear Screen Default: Reset
Max Seg Size (IMS): 0
Restartable Application
Extended Attribute Support
7. Select OK
8. Select Construction/Packaging.
9. Select the Business System - Distributed Project Management then Edit/Complete.
10. Select the One Module option and then OK .
11. Select Construction/Generation/Generation Defaults and enter the following settings for the
defaults.
Operating System: OS/2
DBMS: DBM
Language: C
TP Monitor: IEFAE
Type of Installation: Local
132
DBMS Drive for Local Installation: D
Run Consistency Check for each item generated
Generate source code with trace
12. Select Generation/DDL, All and Install.
13. Select Generation/Code, All and Install.
133
E.15 Tutorial 11 - Testing
Testing of the load modules can be done directly from the Installation Monitor (IM) or through
the use of the Application Execution Facility (AEF). The testing of the load modules is done in the
procedure action diagrams. The IM is only active following installation of the modules. Therefore,
the AEF can be used when this is not active.
E.15.1 Testing using the Installation Monitor
1. Press Control-Esc to access the window list and then select the Installation Monitor.
2. Select the load module to be tested and select Test.
E.15.2 Testing using the AEF
1. Select User Pro le Management Services and Logon.
2. Enter USERID and PASSWORD for the user id and password.
3. Select Database Manager followed by DBM Command Line Interface. At the command line
enter DBM start using database iefdb.
4. Access the OS/2 full screen and move to the directory where the executable les are located.
5. Enter SET AETEST=ON at the prompt.
6. Enter AEF at the prompt.
7. The top left corner of the AEF screen allows for the entry of a transcode. Enter mainmenu
and press the Enter key on the number pad of the keyboard.
The following instructions apply to testing with either the IM or the AEF.
1. At the rst screen tab to the entry elds and enter the appropriate information. Press the
Enter key on the number pad of the keyboard.
2. The IEF testing facilities will then display the action diagram for the screen. Pressing F3
steps through the action diagram one line at a time.
3. The view information can be accessed by typing Display import or the appropriate view name
at the Command line.
4. The view information can be changed by tabbing to the left column opposite the view you
want to change. Enter an M in this column and enter the new information in the right column
opposite the view. Press F3 to return to the action diagram.
5. F3 exits the testing facility.
6. If testing is being done using the AEF return to the DBM Command Line Interface and
enter DBM stop using database.
134