- •Центр дистанционного образования
- •Раздел 1. Основы проектирования экономических информационных систем 7
- •Глава 4. Типовое проектирование эис 84
- •Раздел 1. Основы проектирования экономических информационных систем Глава 1. Теоретические вопросы проектирования экономических информационных систем
- •1.1. Понятие и классификация эис
- •1.2. Структура эис
- •1.3. Жизненный цикл эис
- •1.4. Этапы развития эис
- •1.5. Методология определения эффективности проектирования эис
- •1.6. Методология системного подхода к проектированию
- •Контрольные вопросы
- •Глава 2. Методологические основы проектирования эис.
- •2.1. Характеристика стадий и этапов проектирования эис.
- •2.2. Технология проектирования эис
- •2.3. Формализация процесса проектирования
- •2.3.1. Технологические операции проектирования
- •2.3.2. Технологическая сеть проектирования
- •2.4. Методы и средства проектирования эис
- •2.5. Состав проектной документации эис
- •Контрольные вопросы
- •Раздел 2. Проектирование с использованием различных методов Глава 3.Методология оригинального проектирования
- •3.1. Содержание работ на предпроектной стадии эис
- •3.1.1.Методология предпроектного обследования.
- •3.1.2. Исследование потоков информации
- •3.1.3. Технологическая сеть проектирования предпроектной стадии эис
- •3.2. Проектирование техно-рабочего проекта эис
- •3.2.1.Системы классификации информации.
- •3.2.2.Системы кодирования информации
- •3.2.3.Системы штрихового кодирования
- •3.2.4.Единая система классификации и кодирования (ескк).
- •3.2.5.Технолгия разработки нормативно-справочной информации.
- •3.2.6. Проектирование постановок задач
- •3.2.7.Проектирование входных и выходных документов
- •3.3. Проектирование технологических процессов обработки данных
- •Контрольные вопросы
- •Глава 4. Типовое проектирование эис
- •4.1. Проектирование с использованием пакетов прикладных программ
- •4.2. Методика выбора пакетов прикладных программ
- •4.3. Методология объектного проектирования
- •Контрольные вопросы
- •Глава 5. Проектирование корпоративных информационных систем.
- •5.1. Реинжиниринг бизнес-процессов корпоративных эис
- •5.2. Структура корпоративных эис
- •5.2.1.Расчёт экономической эффективности кИнС
- •5.3. Технология проектирования корпоративных эис
- •Контрольные вопросы
- •Глава 6. Автоматизированное проектирование эис
- •6.1.Проектирование эис средствами сапр на основе гипотетической модели
- •6.2. Анализ систем автоматизированного проектирования эис
- •6.2. Проектирование с использованиемCase-технологий
- •Контрольные вопросы
- •Раздел 3. Управление проектированием эис Глава 7. Организация проектирования эис
- •7.1.Организация процесса проектирования эис
- •7.2.Организационные формы управления проектированием эис
- •Контрольные вопросы
- •Глава 8. Управление процессом проектирования
- •8.1.Управление проектными работами
- •8.2. Методы управления проектными работами
- •Контрольные вопросы
- •Методические указания по выполнению курсового проекта
- •1. Задачи курсового проекта.
- •2. Выбор темы курсового проекта.
- •3. Подбор литературы и изучение информативных материалов.
- •4. Структура и содержание курсового проекта
- •Предлагаемые темы курсовых проектов
- •Словарь терминов.
- •Список сокращений
- •Список литературы
6.2. Анализ систем автоматизированного проектирования эис
В основу анализа САПР положены эксплуатационные характеристики систем с учетом требований как проектировщика, так и пользователя системы проектирования.
Рассмотрим следующие параметры: структурированность, функциональная полнота и степень автоматизации.
СтруктурированностьСАПР означает, что каждая функция проектирования реализуется автономным комплексом системы, который должен функционировать независимо от остальных. Кроме того, каждый комплекс должен быть снабжен необходимой эксплуатационной документацией, где четко оговариваются требования к форме представления входной информации и дается полное описание выходной. Этой характеристике трудно поставить в соответствие некоторый параметр, имеющий явное количественное значение.
Параметр функциональной полнотыСАПР (Пф) может быть определен следующим образом:
Пф = К1/К2 (6.1)
где K1— число операций канонической технологической сети проектирования системы проектирования, выполняемых с помощью САПР;K2—общее число операций канонической технологической сети проектирования системы.
Степень автоматизации процесса проектированиясистемы при использовании САПР будем определять по формуле:
А = (Т2 – Т1)/Т2 , (6.2)
где T1—суммарная трудоемкость выполнения технологических операций проектирования, входящих в ТСП системы проектирования, построенную с учетом использования САПР;Т2— суммарная трудоемкость выполнения технологических операций канонической ТСП.
В свою очередь Т1и Т2определяются так:
(6.3)
(6.4)
где ti – трудоёмкость выполненияi-й технологическойоперации ТСП в условиях использования системы САПР; I – число технологических операций ТСП ЭИС, построенной с учётом использования САПР;tj – трудоёмкость выполненияj–й технологической операции канонической ТСП ЭИС;J– число технологических операций канонической ТСП ЭИС.
6.2. Проектирование с использованиемCase-технологий
Аббревиатура CASE (Computer-Aided Software/System Engineering) используется в довольно широком смысле. Первоначальное использование термина CASE было ограничено вопросами автоматизации разработки только лишь программного обеспечения, а в настоящие время охватывает процесс разработки сложных ЭИС в целом.
Большинство существующих CASE-систем ориентировано на автоматизацию проектирования и основано на методологиях структурного или объектно-ориентированного проектирования и программирования, использующих спецификации в виде диаграмм или текстов для описания системных требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.
Рассмотрим методологические основы CASE-технологии.
Основой CASE-методологии является моделирование. CASE-технология — это модельный метод автоматизации проектирования системы.
CASE-технология основана на парадигме:
методология — метод — нотации — средства.
Методология определяет общие подходы к оценке и выбору варианта системы, последовательность стадий и этапов проектирования, подходы к выбору методов.
Метод конкретизирует порядок проектирования отдельных компонентов системы (например, известны методы проектирования потоков данных в системе, задания спецификаций (описаний) процессов, представления структур данных в хранилище и т.д.).
Нотации — это графические средства обозначения и правила, предназначенные для описания структуры системы, этапов обработки информации, структуры данных и т.д. Нотации включают графы, диаграммы, таблицы, блок-схемы, формальные и естественные языки.
Наконец, средства — это инструментарий, средства автоматизации проектирования в виде программных продуктов для обеспечения интерактивного режима проектирования (создание и редактирование графического проекта информационной системы) и кодогенерации программ (автоматического создания кодов программ системы).
Методология проектирования на основе компьютерной поддержки очевидно требует построения формализованного описания информационной системы в виде информационной модели. Построение CASE-модели системы предусматривает декомпозицию системы и иерархическое упорядочивание декомпозированных подсистем.
Модель системы должна отражать:
функциональную часть системы;
отношения между данными;
переходы состояний системы при работе в реальном времени.
Для моделирования информационной системы в трех указанных аспектах используются следующих разновидности графических средств с определенными нотациями:
Диаграмма бизнес-функций (функциональные спецификации) BFD (Business Flow Diagram).
SADT(StructuredAnalysisandDesignTechnique) – технология структурного анализа проектирования и ее подмножествоIDEF0
Диаграммы потоков данных — DFD (Data Flow Diagrams). Они используются совместно со словарями данных и спецификациями процессов.
Диаграммы „сущность-связь" — ERD (Entity Relationship Diagrams), показывающие отношения между данными.
Диаграммы переходов состояний — STD (State Transitign Diagrams) для отражения зависящего от времени поведения системы (в режиме реального времени).
BFD позволяет представить структуру ИС, отражающую взаимосвязь различных задач (процедур) в процессе получения требуемых результатов.
Основными объектами BFD являются:
Функция – некоторое действие информационной системы, необходимое для решения экономический задачи.
Декомпозиция функции – разбиение функции на множество подфункций.
Изображение объектов диаграммы иерархии функций представлено в табл. 6.1. в нотациях Гейна-Сарсона и Йордана.
Таблица 6.1.
Изображение объектов диаграммы иерархии функций
Объект |
Нотация Гейна-Сарсона |
Нотация Йордана |
Функция |
|
|
Декомпозиция функции |
Методология IDEFO.В методологииIDEF0 используются четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция и глоссарий.
Функциональный блокобозначает определенную функцию в рамках рассматриваемой системы и в графическом виде обозначается прямоугольником. Каждая из четырех сторон этого прямоугольника имеет свое значение: левая сторона - вход, верхняя сторона -управление, нижняя сторона - механизм и правая сторона - выход.
Интерфейсная дугаобозначает элемент системы, который обрабатывается функциональным блоком или оказывает некоторое влияние на выполнение блоком своей функции. Графически интерфейсная дуга изображается в виде однонаправленной стрелки. В зависимости от того, к какой из сторон блока примыкает интерфейсная дуга, она носит название входящей, исходящей, управляющей или дуги механизма. Началом и концом каждой дуги могут быть только функциональные блоки, при этом началом может быть только выходная сторона блока, а концом - любые другие. При построении моделей функционирования предприятия входящими и исходящими дугами могут обозначаться финансовые потоки, материальные потоки (товары, сырье и др.), потоки информации (документы, устные распоряжения и др.) и ресурсы (персонал, оборудование и др.). Управляющими дугами обозначаются только объекты, относящиеся к потокам информации, а дугами механизмов - только ресурсы.
Декомпозиция предполагаетразбиение сложного процесса на составные части. Уровень детализации процесса определяется непосредственно разработчиком модели. В результате общая модель процесса представляется в виде иерархической структуры отдельных диаграмм, что делает ее более обозримой. Модель IDEF0 всегда начинается с представления процесса как единого функционального блока с интерфейсными дугами, выходящими за пределы рассматриваемой области. Такая диаграмма называетсяконтекстной.В пояснительном тексте к контекстной диаграмме должно быть указано краткое описание цели построения диаграммы и определена так называемая точка зрения.
Цельопределяет те области деятельности предприятия, на которые необходимо обратить внимание в первую очередь. Например, модель, построенная с целью оптимизации процесса продаж, может существенно отличаться от модели, разработанной с целью повышения эффективности управления персоналом.
Точка зренияопределяет направленность и уровень детализации разрабатываемой модели. Ее четкая фиксация позволяет упростить модель, исключив детализацию элементов, не являющихся существенными в данном случае. Например, функциональные модели одного и того же предприятия с точки зрения коммерческого директора и, скажем, руководителя службы безопасности будут явно отличаться по направленности их детализации. В процессе декомпозиции функциональные блоки диаграммы верхнего уровня детализируются на диаграмме следующего уровня.
Глоссариемназывается набор определений, ключевых слов, повествовательных изложений и др., характеризующий объекты, отображенные на диаграмме. Глоссарий обеспечивает включение в диаграммы IDEF0 необходимой дополнительной информации. Например, для управляющей интерфейсной дуги «распоряжение об оплате» глоссарий может содержать перечень полей соответствующего Дуге документа, необходимый набор виз и т.д.
Пример структурной диаграммы IDEF0 приведен на рис. 6.1.
Ведущая роль в моделировании принадлежит DFD. DFD предназначена для отражения взаимосвязей источников и приемников данных (так называемых внешних сущностей по отношению к информационной системе), потоков данных, процессов обработки (вычислительных процессов, соответствующих функциям системы), хранилищ данных (накопителей).
Рис.6.1. Структурная диаграмма.
В качестве основных символов диаграмм потоков данных могут быть использованы следующие.
Как видно из обозначений DFD, эти диаграммы идентифицируют основные компоненты CASE-модели.
Графическое представление диаграммы потоков данных на экране дисплея обеспечивает наглядность моделирования и удобство корректировки основных компонентов модели в интерактивном режиме.
Поскольку графического представления недостаточно для точного определения компонентов DFD, используются текстовые описания и другие средства конкретизации процессов обработки и структуры данных.
Так, потоки данных конкретизируются в части их структуры в словарях данных. Каждый процесс (функция системы) может быть детализирована с помощью DFD нижнего уровня, где он разделяется на несколько процессов с одновременной детализацией потоков данных.
Таблица 6.2.
Основные символы диаграммы потоков данных
Символы DFD |
Нотация Гейна-Сарсона |
Нотация Йордона |
Поток данных | ||
Процесс обработки |
| |
Хранилище данных |
EMBED Word.Picture.8 |
|
Внешняя сущность |
|
|
Детализация процессов заканчивается, когда описание каждого детализированного процесса может быть сделано с помощью выбранного метода написания алгоритма процесса. Спецификация процесса содержит номер и имя процесса, списки имен входных и выходных данных из словаря данных и алгоритм процесса, трансформирующий входные потоки данных во входные. В CASE-технологии используются такие методы задания алгоритмов процессов, как:
текстовое описание;
естественный структурированный язык;
таблицы решений;
деревья решений;
визуальные языки;
языки программирования.
Структурированный естественный язык легко понимается не только проектировщиками и программистами, но и конечными пользователями. В этом его достоинство. Однако он не обеспечивает автоматической кодогенерации из-за наличия неоднозначностей.
Таблицы и деревья решений, наглядно отражая связь комбинации условий с необходимыми действиями, не обладают процедурными возможностями для кодогенерации программ.
Визуальные языки обеспечивают автоматическую кодогенерацию, но представленные с их помощью спецификации процессов сложно корректировать.
Содержимое каждого хранилища данных, представленного на диаграмме потока данных, описывается словарем данных и моделью данных ERD. В случае работы системы в реальном времени DFD дополняется STD.
Важным методологическим принципом CASE-технологии создания информационной системы является четкое разделение процесса создания системы на 4 стадии:
предпроектную (стадию анализа, прототипирования, и построения модели требований к системе);
проектную, предполагающую логическое проектирование системы (без программирования);
стадию программирования (включая проектирование физической базы данных);
послепроектную, включающую в себя ввод в действие, эксплуатацию и сопровождение системы.
На предпроектной стадии строится модель требований к системе, т. е. подробное описание того, что она должна делать, без указания путей реализации требований.
На проектной стадии происходит уточнение модели требований (разработка подробной иерархической модели на основе DFD и спецификаций процессов) и расширение ее до модели реализации на логическом уровне. В заключение этой стадии происходит тщательный контроль проекта на уровне логической модели реализации.
На следующей стадии (программирования) осуществляется физическое проектирование системы. Эта стадия предусматривает автоматическую кодогенерацию по спецификациям процессов программного обеспечения системы и физическое проектирование базы данных.
Заключительная послепроектная стадия начинается с приемосдаточных испытаний. Далее следуют ввод в постоянную эксплуатацию, сопровождение и развитие системы.
Классификация CASE-средств
Интегрированное CASE-средство (или комплекс средств, поддерживающих полный жизненный цикл ЭИС) содержит следующие компоненты;
репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD,ERDи др.), образующих модели ИС;
средства разработки приложений, включая языки 4GLи генераторы кодов;
средства конфигурационного управления;
средства документирования;
средства тестирования;
средства управления проектом;
средства реинжиниринга.
Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:
применяемым методологиям и моделям систем и БД;
степени интегрированности с СУБД;
доступным платформам.
Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:
средства анализа (UpperCASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF(MetaSoftware),BPwin(LogicWorks));
средства анализа и проектирования (MiddleCASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (VantageTeamBuilder(Cayenne),Designer/2000 (ORACLE),Silverrun(CSA),PRO-IV(McDonnellDouglas),CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средствVantageTeamBuilder, Designer/2000,Silverrunи PRO-IV;
средства разработки приложений. К ним относятся средства 4GL(Uniface(Compuware),JAM(JYACC),PowerBuilder(Sybase),Developer/2000 (ORACLE),NewEra(Informix),SQLWindows(Gupta),Delphi(Borland) и др.) и генераторы кодов, входящие в составVantageTeamBuilder,PRO-IV и частично - вSilvrrun;
средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERDвходят в составVantageTeamBuilder,PRO-IV,Silverrun,Designer/2000,ERwinиS-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке C++ (RationalRose(RationalSoftware),ObjectTeam(Cayenne)). Вспомогательные типы включают:
средства планирования и управления проектом (SECompanion,MicrosoftProjectи др.);
средства конфигурационного управления (PVCS(Intersolv));
средства тестирования (Quality Works (Segue Software));
средства документирования (SoDA(RationalSoftware)). На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:
Vantage Team Builder (Westmount I-CASE);
Designer/2000;
Silverrun;
ERwin
BPwin
S-Designor;
CASE-Аналитик.
Рассмотрим факторы эффективности CASE-технологии.
Следует отметить, что CASE-технология создает возможность и предусматривает перенос центра тяжести в трудоемкости создания системы на предпроектную и проектную стадии. Тщательная проработка этих стадий в интерактивном режиме с компьютерной поддержкой уменьшает число возможных ошибок в проектировании, исправлять которые на последующих стадиях затруднительно.
Доступная для понимания пользователей-непрограммистов графическая форма представления модели позволяет осуществить принцип пользовательского проектирования, предусматривающий участие пользователей в создании системы. CASE-модель позволяет достичь взаимопонимания между всеми участниками создания системы (заказчиками, пользователями, проектировщиками, программистами).
Наличие формализованной модели системы на предпроектной стадии создает возможность для многовариантного анализа с прото-типированием и ориентировочной оценкой эффективности вариантов. Анализ прототипа системы позволяет скорректировать будущую систему до того, как она будет реализована физически. Этот подход ускоряет и удешевляет создание системы.
Закрепление в формализированном виде требований к системе избавляет проектировщиков от необходимости многочисленных корректировок по новым требованиям пользователей.
Отделение проектирования системы от программирования создает устойчивость проектных решений для реализации на разных программно-технических платформах.
Наличие формализованной модели реализации системы и соответствующих средств автоматизации позволяет осуществить автоматическую кодогенерацию программного обеспечения системы и создать рациональную структуру базы данных.
На стадии эксплуатации системы появляется возможность внесения изменений на уровне модели, не обращаясь к текстам программ, возможно, силами специалистов отдела автоматизации фирмы.
Модель системы может использоваться не только как основа ее создания, но и в целях автоматизированного обучения персонала
с использованием диаграмм.
На основе модели действующей системы может выполняться бизнес-анализ для поддержки управленческих решений и бизнес-реинжиниринг при изменении направления деятельности фирмы.
Рассмотрим программные средства, обеспечивающие CASE-техно-логию. В зависимости от функционального назначения они подразделяются на следующие классификационные группировки, обеспечивающие:
анализ и проектирование информационной системы;
проектирование баз данных;
программирование;
сопровождение и реинжиниринг;
управление процессом проектирования.
Средства анализа и проектирования служат для построения CASE-модели как действующей, так и реализуемой системы управления. Они поддерживают графическое построение и контроль иерархической модели диаграмм потоков данных и описание ее компонентов. Эти средства позволяют аналитикам и проектировщикам получить доступ к базе данных проектируемой системы (репозитарию).
К таким средствам относятся: отечественный пакет CASE. Аналитик, Design/IDEF (Meta Software), The Developer (ASYST Technologies) и др.
Для согласования требований пользователей создаются прототипы пользовательских интерфейсов, включающих в себя меню, экранные формы и отчеты в виде таблиц или графиков. Примером программного средства создания пользовательского интерфейса является Developer/2000 (Oracle).
Средства проектирования баз данных обеспечивают логическое моделирование данных, автоматическое преобразование моделей данных в третью нормальную форму и генерацию схем баз данных. Примерами таких средств является Designer/2000 фирмы Oracle, ERWin (Logic Works) и др.
Средства програмирования поддерживают автоматическую кодогене-рацию из спецификаций процессов, тестирование и документирование программы. К их числу относятся Programmer/2000 (Oracle), DECASE (DEC), APS (Sage Software) и др.
Средства сопровождения и ренжиннрннга позволяют вносить изменения в систему на уровне моделей при меняющихся условиях бизнеса (Adpac CASE Tools фирмы Adpac и др.).
Средства управления процессом проектирования поддерживают планирование и контроль выполнения комплекса проектных работ, а также взаимодействие аналитиков, проектировщиков и программистов на основе общей базы данных проекта (например, Project Workbench фирмы Applied Business Technology). Очевидна актуальность создания интегрированного пакета инструментальных средств поддержки CASE-технологии на всех этапах жизненного цикла информационной системы.