REGULATORY AND METHODOLOGICAL SUPPORT OF AIS CREATION.
Basic concepts of AIS design
In general, AIS includes: user (consumer), information resources, information carriers, means of collecting, storing, processing information, means of transmitting information.
AIS design is based on two interrelated components:
Design standards;
Design methodology.
The basic concepts, approaches and definitions of AIS design are regulated by three types of design and software documentation:
- unified system of design documentation (ESKD);
- unified system of program documentation (ESPD);
- a set of guidelines for AIS.
The composition of the project documentation is a set of standards and guidelines for AIS GOST 24.104-85, GOST 34.003-90, GOST 34.201-90 includes guidelines for information technology and automated systems, as well as requirements for the content of documents.
The goal of design is to identify a relatively simple internal structure, called the architecture of the system.
AIS is being developed as a project. Many features of project management and project development phases (life cycle phases) are common, independent not only of the subject area, but also of the nature of the project. The concept of a project is a complex concept and it is difficult to find an unambiguous formulation for it.
Project- this is a time-limited purposeful change of a separate system with initially clearly defined goals, the achievement of which determines the completion of the project, as well as with established requirements for deadlines, results, risk, spending funds and resources, and organizational structure.
For economic systems under the EIS project we will understand the design and technological documentation, which describes the design solutions for the creation and operation of the EIS in a specific software and hardware environment.
Under EIS design refers to the process of converting input information about the design object, design methods and experience in designing objects of a similar purpose in accordance with GOST into an EIS project. From this point of view, EIS design is reduced to a consistent formalization of design decisions at various stages of the EIS life cycle: planning and analysis of requirements, technical and detailed design, implementation and operation of EIS.
Design objects EIS are individual elements or their complexes of functional and supporting parts. Thus, the functional elements in accordance with the traditional decomposition are tasks, task complexes and management functions. As part of the supporting part of the EIS, the design objects are the elements and their complexes of information, software and technical support of the system.
as a subject designing EIS are teams of specialists who carry out project activities, as a rule, as part of a specialized (design) organization, and a customer organization for which it is necessary to develop an EIS. The scale of the systems being developed determines the composition and number of participants in the design process. With a large volume and tight deadlines for the implementation of design work, several design teams (developing organizations) can take part in the development of the system. In this case, a parent organization is allocated, which coordinates the activities of all co-executing organizations.
The form of participation of co-executors in the development of the system project may be different. The most common is the form in which each collaborator performs design work from start to finish for some part of the system being developed. Usually it is a functional subsystem or an interconnected set of management tasks. Less common is the form of participation of co-executors, in which individual co-executors perform work at certain stages of the design process. A variant is possible in which the functions of the customer and the developer are combined, that is, the EIS is designed on its own.
The implementation of the EIS design involves the use by designers of a certain design technology that corresponds to the scale and features of the project being developed.
EIS design technology- this is a set of methodology and design tools for EIS, as well as methods and tools for organizing design (managing the process of creating and modernizing an EIS project)
Methodology (concept + method)
Tools Organization
design engineering
The design technology is based on a technological process that determines the actions, their sequence, the composition of the performers, the means and resources required to perform these actions.
Thus, the technological process of designing an EIS as a whole is divided into a set of series-parallel, connected and subordinate chains of actions, each of which can have its own subject. The actions that are performed during the design of the EIS can be defined as indivisible technological operations or as sub-processes of technological operations. All actions can be actually design actions that form or modify the design results, and evaluation actions that are developed according to the established criteria for evaluating the design results.
Thus, the design technology is set by a regulated sequence of technological operations performed in the process of creating a project based on a particular method, as a result of which it would become clear not only WHAT should be done to create a project, but also HOW, TO WHOM and in WHAT SEQUENCE it should be done.
The subject of any chosen design technology should be the reflection of interrelated design processes at all stages of the EIS life cycle.
The main requirements for the selected design technology include the following:
The project created using this technology must meet the requirements of the customer;
The selected technology should maximally reflect all stages of the project life cycle;
The chosen technology should provide minimum labor and cost costs for design and project maintenance;
Technology should be the basis of communication between design and project maintenance;
The technology should contribute to the growth of the designer's labor productivity;
The technology must ensure the reliability of the design and operation of the project;
The technology should facilitate the simple maintenance of project documentation.
The basis of EIS design technology is a methodology that defines the essence, the main distinctive technological features.
Design Methodology implies the presence of some concept, design principles, implemented by a set of design methods, which, in turn, must be supported by some design tools.
The design organization involves the definition of methods for the interaction of designers with each other and with the customer in the process of creating an EIS project, which can also be supported by a set of specific tools.
EIS design methods can be classified according to the degree of use of automation tools, standard design solutions, and adaptability to expected changes.
Yes, according to the degree automation design methods are divided into methods:
manual design, in which the design of EIS components is carried out without the use of special software tools, and programming is carried out in algorithmic languages;
computer design, which produces the generation or configuration (setting) of design solutions based on the use of special software tools.
According to the degree of use of standard design solutions, the following design methods are distinguished:
Original (individual) design, when design solutions are developed "from scratch" in accordance with the requirements for EIS;
Typical design, which involves the configuration of the EIS from ready-made standard design solutions (software modules).
The original (individual) design of EIS is characterized by the fact that all types of design work are focused on the creation of individual projects for each object, which reflect all its features to the maximum extent.
Typical design is carried out on the basis of experience gained in the development of individual projects. Typical projects as a generalization of experience for certain groups of organizational and economic systems or types of work in each case are associated with many specific features and differ in the degree of coverage of management functions, the work performed and the developed project documentation.
According to the degree of adaptability of design solutions, design methods are classified into methods:
Reconstructions, when the adaptation of design solutions is carried out by processing the corresponding components (reprogramming of software modules);
Parameterization, when design solutions are adjusted (regenerated) in accordance with the changing parameters;
Model restructuring, when the model of the problem area changes, on the basis of which design solutions are automatically regenerated.
The combination of various features of the classification of design methods determines the nature of the EIS design technology used, among which two main ones stand out.
class: canonical and industrial technologies (Table 2.1). Industrial design technology, in turn, is divided into two subclasses: automated (use of CASE technologies) and typical (parametric-oriented or model-oriented) design. The use of industrial design technologies does not exclude the use of canonical technology in some cases.
Table 2.1 Characteristics of design technology classes
For specific types of design technologies, it is common to use certain EIS development tools that support the implementation of both individual design work, stages, and their combinations. Therefore, EIS developers, as a rule, are faced with the task of choosing design tools that, in terms of their characteristics, best meet the requirements of a particular enterprise.
Design tools should be:
In their class, they are invariant to the design object;
Cover in aggregate all stages of the EIS life cycle;
Technically, software and information compatible;
Easy to learn and use;
Economically feasible.
EIS design tools can be divided into two classes: without the use of a computer and with the use of a computer.
Design tools without the use of a computer are used at all stages and stages of designing an EIS. As a rule, these are means of organizational and methodological support for design operations and, first of all, various standards that regulate the system design process. This also includes a unified information classification and coding system, a unified documentation system, models for describing and analyzing information flows, etc.
Computer-assisted design tools can be used both at individual and at all stages and stages of the EIS design process and, accordingly, support the development of system design elements, system design sections, and the system design as a whole. The whole set of design tools using computers is divided into four subclasses.
The first subclass includes operational tools that support the design of information processing operations. This subclass of tools includes algorithmic languages, libraries of standard subroutines and object classes, macrogenerators, program generators for typical data processing operations, etc., as well as tools for extending the functions of operating systems (utilities). This class also includes such simple design tools as tools for testing and debugging programs, supporting the project documentation process, etc. The peculiarity of the latest programs is that they increase the productivity of designers, but do not develop a complete design solution.
Thus, the tools of this subclass support individual EIS design operations and can be used independently of each other.
The second subclass includes tools that support the design of individual components of the EIS project. This subclass includes system-wide tools:
Database management systems (DBMS);
Method-oriented packages of applied programs (solving problems of discrete programming, mathematical statistics, etc.)
Table processors;
Statistical RFP;
Shells of expert systems;
Graphic editor;
Text editors;
Integrated PPP (an interactive environment with built-in dialog capabilities that allows you to integrate the above software).
The listed design tools are characterized by their use for the development of technological subsystems of EIS: information input, organization of storage and access to data, calculations, analysis and display of data, decision making.
The third subclass includes tools that support design of EIS project sections. In this subclass allocate functional design tools.
Functional tools are aimed at the development of automated systems that implement functions, task complexes and control tasks. A variety of subject areas generates a variety of tools of this subclass, focused on the type of organizational system (industrial, non-industrial areas), management level (for example, enterprise, shop, department, site, workplace), management function (planning, accounting, etc.).
The functional design tools for information processing systems include standard design solutions, functional packages of applied programs, standard projects.
The fourth subclass of EIS design tools includes tools that support the development of the project at the stages and stages of the design process. This class includes a subclass of EIS design automation tools (CASE-tools).
Modern CASE tools, in turn, are classified mainly according to two criteria:
1) by the covered stages of the EIS development process;
2) according to the degree of integration: separate local tools (tools), a set of non-integrated tools covering most of the development stages of EIS (toolkit) and fully integrated tools linked by a common design database - a repository (workbench).
AIS design is a creative process. Each project goes through certain states in its development: from the state when “there is no project yet” to the state when “the project no longer exists”. The set of stages of development from the emergence of an idea to the completion of the project is usually divided into stages (phases, stages). There are some differences in determining the number of stages (phases) and their content, but nevertheless, the essence of the content of the AIS development life cycle in different approaches is the same.
Stages of development of CASE-systems
Over the past decade, a new direction in the design of information systems has emerged - computer-aided design using CASE-tools. The term CASE (Computer Aided System/Software Engineering) originally referred only to software development automation; it now covers the development of complex AIS in general.
Initially, CASE technologies were developed in order to overcome the shortcomings of the structural design methodology (complexity of understanding, high labor intensity and cost of use, difficulty in making changes to design specifications, etc.) through automation and integration of supporting tools.
CASE-technologies do not exist by themselves, they are not independent. They automate and optimize the use of the relevant methodology, and make it possible to increase the efficiency of its application.
In other words, CASE technologies are a set of methodologies for the analysis, design, development and maintenance of complex software systems, supported by a set of interrelated automation tools that allow you to visually model the subject area, analyze this model at all stages of development and maintenance of AIS and develop applications in accordance with the information needs of users.
Modern CASE tools cover a wide range of support for numerous AIS design technologies - from simple analysis and documentation tools to full-scale automation tools covering the entire AIS life cycle. The greatest need for the use of CASE-systems is experienced at the initial stages of development - at the stages of analysis and specification of requirements for AIS. The mistakes made here are almost fatal, their cost far exceeds the cost of errors in the later stages of development.
The main objectives of CASE tools are to separate the initial stages (analysis and design) from the subsequent ones and not burden developers with the details of the development environment and system operation.
Most modern CASE systems use methodologies structural and/or object-oriented analysis And design, based on the use of visual diagrams, graphs, tables and diagrams.
With proper use of CASE-tools, a significant increase in labor productivity is achieved, which (according to estimates of foreign companies using CASE technologies) is from 100 to 600%, depending on the volume, complexity of work and experience with CASE. At the same time, all phases of the AIS life cycle change, but the greatest changes relate to the analysis and design phases (Tables 2.5, 2.6) .
Table 2.5. Estimates of labor costs by phases of the AIS life cycle
Table 2.6. Comparison of using CASE and traditional development
The use of CASE-tools not only automates the structural methodology and makes it possible to use modern methods of system and software engineering, but also provides other advantages (Fig. 2.22), in particular:
1. improves the quality of the software being developed by means of automatic generation and control;
2. allows to reduce the time of creating an AIS prototype, which makes it possible to assess the quality and effectiveness of the project at an early stage;
3. accelerates the design and development process;
4. allows you to reuse the developed components;
5. supports AIS tracking;
6. frees from the routine work of documenting the project, as it uses the built-in documenter;
7. Facilitates teamwork on a project.
Rice. 2.22. Advantages of AIS development using CASE-technologies: A- coefficient of project cost reduction; b - development time reduction factor
Most CASE tools are based on four main concepts: methodology, method, notation, tool [ 11,15, 16].
Methodology defines guidelines for the evaluation and selection of solutions in the design and development of AIS, stages of work, their sequence, rules for the distribution and assignment of methods.
Methods - procedures for generating components and their descriptions.
Notations are intended to describe the general structure of the system, data elements, processing steps, may include graphs, diagrams, tables, flowcharts, formal and natural languages.
Facilities- tools to support and enhance methods; supports the work of users when creating and editing a project in an interactive mode, helps to organize the project in the form of a hierarchy of abstraction levels, checks the conformity of components.
Classification of CASE tools
Until now, there is no stable classification of CASE-tools, only approaches to classification depending on various classification features have been defined. Below are some of them.
Orientation to the technological stages and processes of the AIS life cycle:
1. means of analysis and design. Used to create system specifications and design. They support well-known design methodologies;
2. database design tools. Provide logical data modeling, generation of database structures;
3. requirements management tools;
4. software configuration management tools. Support programming, testing, automatic generation of software from specifications;
5. means of documentation;
6. testing tools;
7. project management tools. Support planning, control, interaction;
8. reverse engineering tools designed to transfer an existing system to a new environment.
Supported design methodologies[ 11, 12, 15, 16]:
1. functionally oriented (structurally oriented);
2. object-oriented;
3. complex-oriented (a set of design methodologies).
Supported graphical charting notations:
1. with fixed notation;
2. with separate notations;
3. with the most common notations.
Degree of integration:
1. auxiliary programs (Tools), independently solving an autonomous task;
2. development packages (Toolkit), which are a set of tools that provide assistance for one of the classes of software tasks;
3. sets of integrated tools linked by a common design database - a repository, automating all or part of the work of different stages of creating AIS (Workbench).
Collective development of the project:
1. without the support of collective development;
2. focused on the development of the project in real time;
3. focused on the mode of combining subprojects.
Types of CASE tools:
1. analysis tools (Upper CASE); among specialists are called means of computer planning. With the help of these CASE-tools, a model is built that reflects all the existing specifics. It is aimed at understanding the general and particular mechanisms of functioning, available opportunities, resources, project goals in accordance with the purpose of the company. These tools allow you to analyze various scenarios, accumulating information for making optimal decisions;
2. analysis and design tools (Middle CASE); are considered to support the requirements analysis and design phases of AIS specifications and structure. The main result of using a medium CASE tool is a significant simplification of system design, as the design becomes an iterative process of working with AIS requirements. In addition, medium CASE tools provide fast documentation of requirements;
3. software development tools (Lower); support AIS software development systems. They contain system dictionaries and graphical tools that eliminate the need to develop physical specifications - there are system specifications that are directly translated into program codes of the system being developed (up to 80% of codes are automatically generated). The main advantages of the lower CASE-tools are a significant reduction in development time, facilitation of modifications, support for the ability to work with prototypes.
CASE tools also classify by type and architecture of computer technology, and by operating system type.
Currently, the software products market is represented by a wide variety of software, including CASE-tools of almost any of the listed classes.
Characteristics of CASE tools
silver run. The Silverrun CASE tool of the American company Computer Systems Advisers, Inc. (CSA) is used for the analysis and design of business class AIS and is focused more on the spiral life cycle model. It is applicable to support any methodology based on the separate construction of functional and information models (data flow diagrams and entity-relationship diagrams).
Tuning to a specific methodology is provided by choosing the required graphical notation of models and a set of rules for checking design specifications. The system has ready-made settings for the most common methodologies: DATARUN (the main methodology supported by Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information Engineering. For each concept introduced in the project, it is possible to add your own descriptors. The Silverrun architecture allows you to grow your development environment as needed.
Silverrun has modular structure and consists of four modules, each of which is an independent product and can be purchased and used separately.
1. Module for building business process models in the form of data flow diagrams, Business Process Modeler (BPM) allows you to model the functioning of an automated organization or an AIS being created. The ability to work with models of great complexity is provided by the functions of automatic renumbering, working with the process tree (including visual dragging of branches), detaching and attaching parts of the model for collective development. Charts can be drawn in several predefined notations, including Yourdon/DeMarco and Gane/Sarson. It is also possible to create your own notations, for example, add user-defined fields to the number of descriptors displayed on the diagram.
2. Conceptual data modeling module Entity-Relationship eXpert (ERX) enables the construction of entity-relationship data models that are not implementation-specific. The built-in expert system allows you to create a correct normalized data model by answering meaningful questions about the relationship of data. Automatic construction of a data model from descriptions of data structures is provided. Analysis of the functional dependencies of attributes makes it possible to check the compliance of the model with the requirements of the third normal form and ensure their implementation. The validated model is passed to the Relational Data Modeler module.
3. Relational Modeling Module Relational Data Modeler (RDM) allows you to create detailed entity-relationship models designed to be implemented in a relational database. This module documents all the structures related to building a database: indexes, triggers, stored procedures, etc. The flexible notation and extensibility of the repository allow you to work on any methodology. The ability to create subschemas is consistent with the ANSI SPARC approach to representing a database schema. In the language of subcircuits, both distributed processing nodes and user views are modeled. This module provides design and complete documentation of relational databases.
4. Workgroup Repository Manager Workgroup Repository Manager (WRM) is used as a data dictionary for storing information common to all models, and also provides integration of Silverrun modules into a single design environment.
The advantage of the Silverrun CASE tool is its high flexibility and variety of visual tools for building models, and the disadvantage is the lack of strict mutual control between the components of different models (for example, the possibility of automatic propagation of changes between DFDs of different decomposition levels). It should be noted, however, that this shortcoming can be significant only if the cascade life cycle model is used.
Tools included in Silverrun:
1. automatic generation of database schemas for the most common DBMS: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase;
2. data transfer to application development tools: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi.
Thus, it is possible to completely define the database engine using all the features of a particular DBMS: triggers, stored procedures, referential integrity constraints. When building an application, the data migrated from the Silverrun repository is used either to automatically generate interface objects or to quickly create them manually.
To exchange data with other design automation tools, create specialized procedures for analyzing and verifying design specifications, and compiling specialized reports in accordance with various standards, Silverrun provides three ways to issue design information to external files.
1. Reporting system. Reports are output to text files.
2. Export/import system. Not only the contents of the export file are set, but also the delimiters of records, fields in records, markers of the beginning and end of text fields. Such export files can be generated and uploaded to the repository. This makes it possible to exchange data with various systems: other CASE tools, DBMS, text editors and spreadsheets.
3. Storing the repository in external files with access using ODBC drivers. To access repository data from the most common DBMS, it is possible to store all project information directly in the format of these DBMS.
Silverrun supports two ways to group work:
1) in the standard single-user version there is a mechanism for controlled separation and merging of models. The model can be divided into parts and distributed among several developers. After a detailed study, the parts are again assembled into a single model;
2) the network version of Silverrun allows parallel group work with models stored in a network repository based on Oracle, Sybase or Informix DBMS. At the same time, several developers can work with the same model, since the blocking of objects occurs at the level of individual elements of the model.
JAM. The JYACC's Application Manager (JAM) application development tool is a product of JYACC. The main feature is compliance with the RAD methodology, since JAM allows you to quickly implement the application development cycle, which consists in generating the next version of the application prototype, taking into account the requirements identified in the previous step, and present it to the user.
JAM has a modular structure and consists of the following components:
1. system core;
2. JAM/DBi - specialized DBMS interface modules (JAM/DBi-Oracle, JAM/DBi-Informix, JAM/DBi-ODBC, etc.);
3. JAM/RW - report generator module;
4. JAM/CASEi - specialized interface modules for CASE tools (JAM/CASE-TeamWork, JAM/CASE-Inno-vator, etc.);
5. JAM/TPi - specialized interface modules for transaction managers (for example, JAM/TPi-Server TUXEDO, etc.);
6. Jterm - a specialized X-terminal emulator.
The core of the system is a finished product and can be independently used for application development. All other modules are optional and cannot be used independently.
The core of the system includes the following main components:
1. screen editor. The screen editor includes a screen development environment, a visual object repository, its own JAM DBMS - JDB, a transaction manager, a debugger, a style editor;
2. menu editor;
3. a set of auxiliary utilities;
4. means of manufacturing an industrial version of the application.
When using JAM, the development of the external interface of an application is a visual design and comes down to creating screen forms by placing interface structures on them and defining on-screen information input / output fields. Interface design in JAM is done using screen editor. Applications developed in JAM have a multi-window interface. The development of the screen consists in placing interface elements on it, grouping them, setting the values of their properties.
Menu editor allows you to develop and debug menu systems. Implemented the ability to build pictographic menus. Assigning menu items to application objects is done in the screen editor.
The JAM kernel has a JDB single-user relational DBMS built into it. The main purpose of JDB is to prototype applications in cases where working with a standard DBMS is impossible or impractical. JDB implements the necessary minimum of relational DBMS capabilities, which does not include indexes, stored procedures, triggers, and views. Using JDB, you can build a database that is identical to the target database (up to the features missing in JDB) and develop a significant part of the application.
The debugger allows you to carry out complex debugging of the developed application. All events that occur during application execution are traced.
Utilities JAM includes three groups:
1) Converters of JAM screen files to text. JAM saves screens as binary files of its own format;
2) configuring I/O devices. JAM and applications built with it do not work directly with I/O devices. Instead, JAM accesses logical I/O devices (keyboard, terminal, report);
3) maintenance of screen libraries.
One of the optional JAM modules is report generator. The layout of the report is carried out in the JAM screen editor. Description of the report is carried out using a special language. The report generator allows you to define the data to be output to the report, the grouping of output information, output formatting, etc.
Applications developed using JAM can be made into executable modules. To do this, developers must have a C compiler and a linker.
JAM contains built-in programming language JPL (JAM Procedural Language), with which, if necessary, modules that implement specific actions can be written. This language is interpreted. It is possible to exchange information between the visually built application environment and such modules. In addition, JAM implements the ability to connect external modules written in languages that are compatible in function calls with the C language.
Jam is event driven system consisting of a set of events - opening and closing windows, pressing a keyboard key, triggering a system timer, receiving and transferring control over each element of the screen. The developer implements the application logic by defining a handler for each event.
event handlers JAM can have both built-in JAM functions and functions written by the developer in C or JPL. The set of built-in functions includes more than 200 functions for various purposes; they are available for calls from functions written in both JPL and C.
Industrial version of the application, developed with JAM, consists of the following components:
1. executable module of the application interpreter;
2. screens that make up the application (delivered as separate files, as part of screen libraries, or built into the body of the interpreter);
3. external JPL modules (supplied as text files or precompiled; precompiled
4. external JPL-modules - as separate files and as part of screen libraries);
5. application configuration files - keyboard and terminal configuration files, system messages file, general configuration file.
Direct interaction with the DBMS is implemented by the JAM/DBi (Database interface) modules. Ways to implement interaction in JAM are divided into two classes: manual and automatic.
At manual way the developer independently writes SQL queries, in which the sources and destinations for receiving the results of the query execution can be both interface elements of a visually designed external level, and internal variables invisible to the end user.
Auto mode implemented by the JAM transaction manager. It is feasible for typical common types of database operations, the so-called QBE (Query By Example), taking into account rather complex relationships between database tables and automatic control of the attributes of I / O screen fields, depending on the type of transaction (reading, writing, etc.) in which the generated query participates.
JAM allows you to build applications to work with more than 20 DBMS: ORACLE, Informix, Sybase, Ingres, InterBase, NetWare SQL Server, Rdb, DB2, ODBC-compatible DBMS, etc.
A distinctive feature of JAM is a high level of application portability between different platforms (MS DOS/MS Windows, SunOS, Solaris (i80x86, SPARC), HP-UX, AIX, VMS/Open VMS, etc.); perhaps a requirement to "redraw" static text fields on screens with Russian text when porting between DOS-Windows-UNIX environments. In addition, portability is facilitated by the fact that in JAM, applications are developed for virtual I/O devices rather than physical ones. Thus, when porting an application from platform to platform, it is usually only necessary to determine the correspondence between physical I/O devices and their logical representations for the application.
Using SQL as a means of interfacing with the DBMS also helps ensure portability between DBMSs. In the case of a database structure transfer, applications may not require any modification, except for session initialization. This is possible if the application did not use DBMS-specific SQL extensions.
With an increase in the load on the system and the complexity of the tasks being solved (distribution and heterogeneity of the resources used, the number of simultaneously connected users, the complexity of the application logic), three-tier architecture model"client - server" using transaction managers. The JAM/TPi-Client and JAM/TPi-Server components make it quite easy to switch to a three-tier model. At the same time, the JAM/TPi-Server module plays a key role, since the main difficulty in implementing the three-tier model lies in the implementation of application logic in transaction manager services.
The JAM/CASE interface allows information to be exchanged between the JAM object repository and the CASE tool repository. The exchange is similar to how the database structure is imported into the JAM repository directly from the database. The difference is that the exchange between repositories is bidirectional.
In addition to the JAM / CASEi modules, there is also the JAM / CASEi Developer "s Kit module. Using this module, you can independently develop an interface (i.e. a specialized JAM / CASEi module) for a specific CASE tool if there is no ready-made JAM / CASEi module for it.
There is an interface that implements the interaction between the Silverrun CASE tool and JAM. It transfers the database schema and application screen forms between the Silverrun-RDM CASE tool and JAM version 7.0; has two modes of operation:
1) direct mode (Silverrun-RDM->JAM) is designed to create CASE dictionary objects and JAM repository elements based on schema representation in Silverrun-RDM. Based on the representation of interface data models in Silverrun-RDM, screens and elements of the JAM repository are generated. The bridge converts the RDM relational schema tables and relationships into a sequence of JAM objects of the appropriate types. The technique for building interface data models in Silverrun-RDM involves the use of a subscheme mechanism for prototyping application screens. Based on the description of each of the RDM subcircuits, the bridge generates a JAM screen;
2) the reverse mode (JAM->Silverrun-RDM) is designed to transfer modifications of CASE-dictionary objects to the Silverrun-RDM relational model.
The reengineering mode allows you to transfer modifications of all properties of JAM screens previously imported from RDM to the Silvcrrun schema. To control the integrity of the database, schema changes in the form of adding or deleting tables and table fields are not allowed.
The JAM kernel has a built-in interface to configuration management tools (PVCS on the Windows platform and SCCS on the UNIX platform). Screen libraries and/or repositories are transferred under the control of these systems. In the absence of such systems, JAM independently implements some of the functions to support team development.
On the MS-Windows platform, JAM has a built-in interface to PVCS and the fetch/revert actions are done directly from the JAM environment.
Vantage Team Builder (Westmount I-CASE). Vantage Team Builder is an integrated implementation-oriented software product with full support for the Waterfall Life Cycle Model.
Vantage Team Builder provides the following features:
1. designing data flow diagrams, entity-relationship diagrams, data structures, block diagrams of programs and sequences of screen forms;
2. designing system architecture diagrams - SAD (designing the composition and connection of computing facilities, distributing system tasks between computing facilities, modeling client-server relationships, analyzing the use of transaction managers and real-time system functioning features);
3. generation of program code in the language of the target DBMS with full software environment and generation of SQL code for creating database tables, indexes, integrity constraints and stored procedures;
4. programming in C with embedded SQL;
5. versioning and project configuration management;
6. multi-user access to the project repository;
7. generation of project documentation according to standard and individual templates;
8. export and import of project data in CDIF format (CASE Data Interchange Format).
Vantage Team Builder comes in various configurations depending on the database management system (ORACLE, Informix, Sybase, or Ingres) or application development tools (Uniface) used. The configuration of Vantage Team Builder for Uniface differs from the rest by partially focusing on a spiral life cycle model due to rapid prototyping capabilities. A large set of diagrams is used to describe the AIS project.
When constructing all types of diagrams, control is provided for the conformity of models to the syntax of the methods used, as well as control for the correspondence of elements of the same name and their types for various types of diagrams.
When constructing diagrams of DFD data flows, control over the conformity of diagrams of different levels of decomposition is provided. The top-level DFD is validated using the ELM event list matrix. To control the decomposition of composite data streams, several options for their description are used: in the form data structure diagrams DSD or in notations BNF (form of Backus - Naur).
To build SAD, an extended DFD notation is used, which makes it possible to introduce the concepts of processors, tasks, and peripheral devices, which provides clarity of design decisions.
When building a data model in the form of an ERD, it is normalized and the definition of the physical names of data elements and tables is introduced, which will be used in the process of generating the physical data schema of a particular DBMS. It provides the ability to determine alternative keys of entities and fields that make up additional entry points to the table (fields of indexes), and the cardinality of relationships between entities.
The presence of a universal code generation system based on the specified means of access to the project repository makes it possible to maintain a high level of execution of the project discipline by developers: a strict procedure for generating models; rigid structure and content of the documentation; automatic generation of program source codes, etc.; all this ensures an increase in the quality and reliability of the developed IS.
Publishing systems such as FrameMaker, Interleaf or Word Perfect can be used to prepare project documentation. The structure and composition of project documentation are configured in accordance with the specified standards. Adjustment is carried out without changing the design decisions.
When developing large AIS, the entire system as a whole corresponds to one project as a category of Vantage Team Builder. The project can be decomposed into a number of systems, each of which corresponds to some relatively autonomous AIS subsystem and is developed independently of the others. In the future, project systems can be integrated.
The AIS design process using Vantage Team Builder is implemented in the form of four consecutive phases (stages) - analysis, architecture, design And implementation, at the same time, the completed results of each stage are fully or partially transferred (imported) to the next phase. All diagrams, except for ERD, are converted to another type or change their appearance in accordance with the features of the current phase. Thus, DFDs are converted in the architecture phase to SAD, DSDs to DTDs. After the import is completed, the logical connection with the previous phase is broken, i.e., all necessary changes can be made to the diagrams.
The Vantage Team Builder for Uniface configuration provides for the sharing of two systems within a single technological design environment, while the database schemas (SQL models) are transferred to the Uniface repository, and vice versa, application models generated by Uniface tools can be transferred to the Vantage Team Builder repository. Possible discrepancies between the repositories of the two systems are eliminated using a special utility. Development of screen forms in the Uniface environment is performed on the basis of FSD form sequence diagrams after importing the SQL model. The AIS development technology based on this configuration is shown in fig. 2.23.
The structure of the repository stored in the target DBMS and the Vantage Team Builder interfaces are open, which in principle allows integration with any other tools.
Uniface. The Compuware product is a development environment for large-scale applications in the "client-server" architecture and has the following component architecture:
1. Application Objects Repository (repository of application objects) contains metadata automatically used by all other components throughout the life cycle of AIS (application models, data descriptions, business rules, screen forms, global objects and templates). The repository can be stored in any of the databases supported by Uniface;
Rice. 2.23. Interaction between Vantage Team Builder and Uniface
2. Application Model Manager supports application models (E-R models), each of which is a subset of the overall database schema from the point of view of this application, and includes a corresponding graphical editor;
3. Rapid Application Builder - a tool for quickly creating screen forms and reports based on objects of the applied model. Includes a graphical form editor, prototyping, debugging, testing and documentation tools. Implemented an interface with various types of window controls Open Widget Interface for existing graphical interfaces - MS Windows (including VBX), Motif, OS/2. The Universal Presentation Interface allows you to use the same version of the application in the environment of different graphical interfaces without changing the program code;
4. Developer Services (developer services) are used to support large projects and implement version control (Uniface Version Control System), access rights (separation of powers), global modifications, etc. This provides developers with the means of parallel design, input and output control, search, viewing, maintaining and reporting on version control system data;
5. Deployment Manager (application distribution management) - tools that allow you to prepare the created application for distribution, install and maintain it (the user's platform may differ from the developer's platform). They include network and DBMS drivers, application server (polyserver), application distribution and database management tools. Uniface supports interface with almost all known hardware and software platforms, DBMS, CASE-tools, network protocols and transaction managers;
6. Personal Series (personal tools) are used to create complex queries and reports in graphical form (Personal Query and Personal Access - PQ / PA), as well as to transfer data to systems such as WinWord and Excel;
7. Distributed Computing Manager - integration tool with Tuxedo, Encina, CICS, OSF DCE transaction managers.
Uniface 7 version fully supports distributed computing model and three-tier client-server architecture (with the ability to change the application decomposition scheme at runtime). Applications created using Uniface 7 can be executed in heterogeneous operating environments using various network protocols, simultaneously on several heterogeneous platforms (including the Internet).
Uniface 7 components include:
1. Uniface Application Server - application server for distributed systems;
2. WebEnabler - server software for operating applications on the Internet and intranet;
3. Name Server - server software that ensures the use of distributed application resources;
4. PolyServer - a means of accessing data and integrating various systems.
Supported DBMS include DB2, VSAM, and IMS; PolyServer also provides interoperability with the MVS OS.
Designer/2000 + Developer/2000. ORACLE's Designer/2000 2.0 is an integrated CASE tool that, in conjunction with the Developer/2000 application development tools, provides full software lifecycle support for systems using the ORACLE DBMS.
Designer/2000 is a family of methodologies and their supporting software products. Basic methodology Designer/2000 (CASE*Method) is a structural system design methodology that fully covers all stages of the AIS life cycle. At the planning stage, the goals of creating the system, priorities and limitations are determined, the system architecture and the AIS development plan are developed. In the process of analysis, the following are built: an information needs model (an entity-relationship diagram), a functional hierarchy diagram (based on the AIS functional decomposition), a cross-reference matrix and a data flow diagram.
At the design stage, a detailed AIS architecture is developed, a relational database schema and program modules are designed, cross-references are established between AIS components to analyze their mutual influence and control changes.
At the implementation stage, a database is created, application systems are built, they are tested, quality checked, and compliance with user requirements is checked. Created system documentation, training materials and user manuals. At the stages of operation and maintenance, the performance and integrity of the system are analyzed, support and, if necessary, modification of the AIS is performed.
Designer/2000 provides a graphical interface for developing various domain models (diagrams). In the process of building models, information about them is entered into the repository. Designer/2000 includes the following components.
Compliance with the above principles is necessary when performing work at all stages of the creation and operation of AIS and AIT, i.e. throughout their entire life cycle.
Life cycle(LC) - the period of creation and use of AIS (AIT), starting from the moment the need for this automated system arises and ending with the moment it is no longer in use.
The life cycle of AIS and AIT allows us to distinguish four main stages, each design stage is divided into a number of stages and provides for the corresponding work:
I stage - pre-project inspection:
1st stage - formation of requirements, study of the design object, development and selection of a variant of the system concept;
2nd stage - analysis of materials and formation of documentation - creation and approval of a feasibility study and terms of reference for the design of the system based on the analysis of survey materials collected at the first stage.
II stage - design:
1st stage - technical design, where the search for the most rational design solutions for all aspects of development is conducted, all components of the system are created and described, and the results of the work are reflected in the technical design;
2nd stage - working design, during which the development and fine-tuning of programs, the adjustment of database structures, the creation of documentation for the supply, the installation of technical means and instructions for their operation, the preparation of job descriptions for each user are carried out. Technical and working projects can be combined into a single document - a technical working project.
III stage - system input into action:
1st stage - preparation for implementation- installation and commissioning of technical means, database loading and trial operation of programs, personnel training;
2nd stage - pilot testing all components of the system before being put into commercial operation, personnel training;
3rd stage (the final stage of the creation of AIS and AIT) - commissioning; issued by acts of acceptance and delivery of works.
IV stage - industrial operation - in addition to daily functioning, it includes maintenance of software tools and the entire project, operational maintenance and database administration.
5. Methods of conducting design work
The creation of automated information systems and technologies can be carried out in two ways. The first option assumes that specialized firms with professional experience in preparing software products of a specific orientation are engaged in this work. According to the second option, the design and creation of developments are carried out by designers-programmers who are in the staff of enterprises where new information technologies and systems are created.
In the process of developing automated systems, workplaces and technologies, designers face a number of interrelated problems:
It is difficult for a designer to obtain comprehensive information to assess the requirements formulated by the customer (user) for a new system or technology.
The customer often does not have sufficient knowledge about the problems of automation to judge the possibility of implementing certain innovations. At the same time, the designer is faced with an excessive amount of detailed information about the problem area, which causes difficulties in modeling and formalized description of information processes and solving functional problems.
Due to the large volume and technical terms, the specification of the system being designed is often incomprehensible to the customer, and its excessive simplification cannot satisfy the specialists who create the system.
With the help of well-known analytical methods, it is possible to solve some of these problems, but only modern structural methods provide a radical solution, among which the methodology of structural analysis occupies a central place.
structural analysis called the method of studying the system, which begins with its general overview and then details, acquiring a hierarchical structure with an increasing number of levels.
Structural analysis involves dividing the system into levels of abstraction with a limited number of elements at each of the levels (usually from 3 to 6-7). At each level, only the details that are essential for the system are highlighted.
The methodology of structural analysis is based on the principles of decomposition and the principle of hierarchical ordering.
Decomposition principle involves solving difficult problems by breaking them down into tasks that are easy to understand and solve.
Principle of hierarchical ordering declares that the system can be understood and built on levels, each of which adds new details.
On pre-project stage a study and analysis of all the features of the design object is carried out in order to clarify the requirements of the customer. In particular, a set of conditions is identified under which the future system is supposed to be operated (hardware and software resources; external conditions for its operation; the composition of people and works related to it and participating in information and management processes), a description is made of the functions performed by the system, etc.
At this stage, the following are determined:
System architecture, its functions, external conditions, distribution of functions between hardware and software;
Interfaces and distribution of functions between a person and a system;
Requirements for software and information components of the system, necessary hardware resources, database requirements, physical characteristics of the system components, their interfaces.
The quality of further design depends decisively on the correct choice of analysis methods and the formulated requirements for the newly created technology.
The methods used at the pre-project survey stage are divided into:
- Methods for studying and analyzing the actual state of an object or technology. These methods make it possible to identify bottlenecks in the processes under study and include: oral or written survey; written survey; observation, measurement and evaluation; group discussion; task analysis; analysis of production and management processes.
In general, the methods of studying and analyzing the actual state of management activities and the existing technology for solving problems are designed to collect the necessary materials and form the basis for the design of AIS and AIT.
- Methods for forming a given state. They are based on the justification of all the components of the AIS based on the goals, requirements and conditions of the customer. These methods, which are the working tools of designers, include methods: modeling the control process; structural design; decomposition; analysis of the information process.
- Method of modeling the management process. In the process of studying the design object, economic-organizational and information-logical models are built. They reflect economic and managerial relations, as well as the information flows associated with them.
- Structural design method allows you to divide the entire complex of tasks into visible and analyzable subcomplexes (modules).
- Decomposition method modules provides for further division of subsets of tasks into separate tasks, indicators.
- Analysis of information processes is designed to identify and present the relationship between the result, the processing process and data entry. It is also used to analyze and form information links between the workplaces of management employees, specialists, technical personnel and information technology. For this purpose, the input and output information, as well as the algorithm for processing information in relation to each workplace, are described.
- Methods for graphical representation of the actual and specified states provide for the use of a visual representation of information processing processes. The most famous of them include the flowchart method, the methods of arrow diagrams, network diagrams, tables of the sequence of operations of the processes.
If at the pre-design stage the requirements for the creation of AIS and AIT should be formulated in the terms of reference, then the design should answer the question: “How will the system meet the requirements for it?”.
As a result of the design stages, a system design should be obtained within the budget of the allocated resources.
Design stages include the following main works:
Development of goals and organizational principles of AIS;
Formation of a variant of AIS and AIT;
Debugging programs;
Trial operation;
Delivery of the AIS and AIT project.
In the process of organizing the design, various decisions are made that affect the dynamics and quality of work. Therefore, for each design stage, the following are determined: expected results and documents; personal functions of the head; decisions made by the leader; functions of the customer and developer of AIS and AIT.
The design and as-built documentation includes: workflow instructions, programs for workplaces, instructions for paperwork, recommendations on the use of information, methods, decision tables, etc.
In modern conditions, AIS, AIT and AWP, as a rule, are not created from scratch. The need for timely, high-quality, operational information and its assessment as the most important resource in management processes, as well as the latest achievements in scientific and technological progress, necessitate the restructuring of functioning AIS and the creation of AIS and AIT on a new technical and technological basis.
AIS design
Detailed development system design containing a complete set of its organizational, design, technological and operational documentation. In accordance with GOST 34.601-90. the design of automated systems involves the implementation of a number of stages, including: the formation of requirements for the AU, the development of the concept of the AU, the development of technical specifications, preliminary design, technical design and development of working documentation. The stages of creating the AU, in addition to designing, also include: commissioning and maintenance of the AU. Each stage is subdivided into stages. The annexes to this standard also define:
· List of types of organizations involved in the work.
Depending on the nature of the design object and its specific conditions, GOST 34.601-90 allows the exclusion of individual stages, as well as their combination. Taking into account the long-term practice that has developed in Russia when creating automated information systems (" AIS”), the following stages of design are usually carried out: pre-project survey, conceptual design, preliminary design, technical design and detailed design. Other state standards governing various aspects of NPP design:
· GOST 34.602-89 Set of standards for automated systems. Terms of reference for the creation of an automated system. Entered.01.01.90.
· Standard 34.603-92 Information technology. Types of AS tests.
· Standards 34. (971, 972.973, 974, 981) - 91 Information technology. The relationship of open systems.
· Standard 34.91. Information technology. Local area networks, etc.
Pre-project survey- Collection and processing of information about the organization and functioning of the automation object, including data on its interaction with the external environment and other objects, as well as the implementation system analysis, development of a feasibility study for the feasibility of automation and the development of general requirements for the development of an automated system. The content of work during the pre-project survey of the automation object corresponds to the stage “Formation of requirements for the AU” GOST 34.601-90, stages: “Inspection of the object and justification for the need to create an AU”, “Formation of user requirements for the AU”, “Formation of a report on the work performed and an application for the development of the AU - tactical and technical assignment”.
Conceptual design- Corresponds to the design stages in accordance with GOST 34.601-90 - “Development of the AU concept” (stages: “Development of variants of the AU concept and selection of a variant of the AU concept that satisfies the user”, “Drawing up a report on the work performed”) and “Development of terms of reference”. The types of final documents of work at this stage are preliminary project(also used names - “ Conceptual project ”, “Pilot project") or Program creating a system that includes:
Brief description of the initial state of the automation object and the environment in which it operates;
Indication of the main goals and a list of automation tasks;
· Description of the enlarged organizational and functional structure of the selected option (or options) for building the system being created;
· Feasibility study;
· An enlarged description and basic requirements for the means of information and linguistic support;
· General requirements for software and hardware;
· A list and an enlarged description of the stages of creating the system, the timing of their implementation, the composition of the performers and the expected results of their implementation;
· Initial assessment of cost indicators of work performance;
· Terms of reference for the system as a whole and/or its main components (subsystems, software and hardware systems and tools, individual tasks, etc.), approved by the customer.
Preliminary design- Development of preliminary design solutions for the system and its parts. The final document of the work at this design stage is preliminary design, which contains the fundamental design and circuit solutions of the development object, as well as data that determine its purpose and main parameters (when designing software system, the draft design must contain a complete specification developed programs).
Engineering design - NPP design stage, which includes:
· Development of design solutions for the system and its parts;
· Development of documentation for the AU and its parts;
· Development and execution of documentation for the supply of products for the acquisition of nuclear power plants and / or technical requirements (technical specifications) for their development;
· Development of tasks for designing in adjacent parts of the project of the automation object.
The final document of this design stage is technical project containing, in addition to the listed materials, electrical circuit diagrams and design documentation of the development object and its components, a list of selected ready-made tools software and hardware(including computers, operating system, application programs etc.), as well as algorithms solving problems for the development of new software tools, etc.
Working design- Final stage design, which, in addition to the development of working documentation for the system and its parts required by GOST 34.601-90, generally provides for the refinement and detailing of the results of previous stages, the creation and testing of an experimental and / or pilot prototype of an automation object, the development and testing of software products, technological and operational documentation. The results are presented in working or technical working project. In modern design practice automated information systems(For example, ABIS, ASNTI, ACS etc.) it is the initial stage of their implementation in the work of a firm, organization or service that is the customer of the project, or the head in a number of other automated firms, organizations, services, etc.
Development cycle (design) software - Set of development stages software starting from system analysis and development of initial requirements before its implementation.
AIS design principles- A set of rules or requirements fixed by many years of and versatile experience in the creation and operation of AIS. The most common ones are:
· Identity- the development of a new one, the improvement of an existing one, or the introduction of an externally obtained AIS are scientific and technical problems similar in content, differing from one another only in the content of a number of stages and time parameters;
· Manufacturability: automated technology means the development of a new technology or the modernization of an existing one in the conditions of AIS and does not allow the simple use of the developed software and hardware in the conditions of old traditional technologies;
· Continuity, phasing and succession of development and development: AIS - systems constantly developing on their basis; each innovation serves as a development of the basic system principles and already achieved quality;
· adaptability: AIS components should have properties that ensure rapid adaptation of these components to changes in the external environment and new tools;
· Modular principle of building software and hardware: assumes that the composition of these tools consists of blocks (“modules”) that provide the possibility of their replacement or change in order to improve the functioning of the AIS or its adaptation to new conditions;
· Technological (including - network) integration: implies unity for the entire system of technology for creating, updating, preserving and using information resources and, in particular, single processing of documents and data, as well as their multiple and multi-purpose use;
· Full normalization of processes and their monitoring: multi-purpose use of AIS information requires high reliability of data in the system. To do this, at various stages of processing and entering information documents, it is necessary to use various forms of information control, the requirements for which can be formed from the composition of the tasks being solved and the data being processed. constant monitoring is also necessary to obtain qualitative and quantitative characteristics of the functioning of AIS based on built-in and specially developed tools of intellectual statistics;
· Regulation: AIS are focused on functioning in the industrial mode, providing mass streaming processing of information documents; this processing is regulated by standards, route and operational technologies, standards for resource and time indicators, and a developed dispatching service.
· Economic expediency: the creation of AIS should include the choice of such design solutions (including software, technical, organizational and technological), which, subject to the achievement of the goals and objectives, ensure the minimization of the cost of financial, material and labor resources.
· Typification of design solutions: the development and development of AIS and their networks is carried out with a focus on interlibrary cooperation, and cooperation, as well as in accordance with the rules and protocols of international information exchange;
· Maximum use of ready-made solutions: to reduce the cost and time of development and implementation of AIS, as well as to reduce design errors of both the system as a whole and its individual components, it is recommended to use ready-made solutions and tools as much as possible. In this plan, when creating a new system, a significant amount of work is associated with the analysis of alternative options for possible solutions, the choice of the most appropriate for the automation object and its adaptation to new conditions of use;
· corporatism: when designing an automated system that is part of a higher-level system (cities, departments, republics, etc.), its hardware, software, linguistic and information compatibility with other participants in the system and / or AIS network should be provided. Corporate requirements may conflict with requirements or decisions dictated by other principles, for example, the continuity of design solutions;
· Orientation to the first persons of the automation object: successful implementation of work on the creation of AIS, its development and operation is possible only if they are unconditionally supported by the first person of the automation object (for example, the director of a library or information body) and the direct responsibility for their implementation is assigned by order of the organization to the head at the level of at least the deputy director
