5. Лабораторная работа №1 “Изучение основных функций пакета bpwin”




Название5. Лабораторная работа №1 “Изучение основных функций пакета bpwin”
страница1/6
Дата23.09.2012
Размер0.76 Mb.
ТипЛабораторная работа
  1   2   3   4   5   6


Российский государственный университет нефти и газа им. И.М.Губкина


Сапунцов В.Д., Лысенко М.А., Султанов Ф.Я., Игнатов А.А.




Применение CASE-средств BPwin и ERwin для проектирования информационных систем

Компьютерный практикум




Москва 2000



Сапунцов В.Д., Лысенко М.А., Султанов Ф.Я., Игнатов А.А.


Применение CASE-средств BPwin и ERwin для проектирования информационных систем. Компьютерный практикум / Под ред. В.Д.Сапунцова. –М.: РГУ нефти и газа, 2000. –53 с.


Данный практикум посвящен важнейшей стадии разработки информационных систем – стадии проектирования.

В теоретической части рассматриваются содержание жизненного цикла разработки информационных систем, этапы стадии проектирования, а также современные средства автоматизации труда системотехника – CASE-системы. На примере использования CASE-средств BPwin и ERwin, разработанных фирмой Logic Works, изучается создание моделей информационной системы. Приводится словарь терминов данной области системотехники.

Практическая часть рассматривается на примере интегрированной информационно-управляющей системы РГУ нефти и газа им. И.М.Губкина.

Практикум предназначен для студентов специальности “Автоматизированные системы управления”, изучающих дисциплину “Проектирование АСУ”.


Рецензент: к.т.н., доцент Анохин А.Н.


© Сапунцов В.Д., Лысенко М.А.,

Султанов Ф.Я., Игнатов А.А., 2000


тел. (095)930-93-19

E-mail: kobbi@asu.saog.ac.ru

© РГУ нефти и газа им. И.М.Губкина




Содержание


1.Жизненный цикл информационных систем......................……………………...

3

2.Стадия проектирования информационных систем.................................…….....

4

3.CASE-технологии…………………………….………………………...................

7

4.Характеристика современных CASE-систем……………………………………

9

5.Лабораторная работа №1 “Изучение основных функций пакета BPwin”…….

14
6.Лабораторная работа №2 “Изучение объектов диаграмм функциональной модели”…………………………….………………………................……………...

17

7.Лабораторная работа №3 “Составление отчетов в пакете BPwin”........….……

24

8.Лабораторная работа №4 “Изучение объектов DFD-диаграмм”………………

27

9.Лабораторная работа №5 “Изучение основных функций пакета ERwin. Создание логической модели ”…………………………………………………….


30

10.Лабораторная работа №6 “Создание физической модели в ERwin“………....

39

11.Лабораторная работа №7 “Создание отчетов в пакете ERwin“………………

12.Словарь терминов……………………………………………………………….

13.Литература………………………….………………………................……….....

45

48

53



1.Жизненный цикл информационных систем


В современных условиях у руководства предприятий, если оно хочет видеть свою компанию современной и успешной, уже не возникает вопроса о необходимости автоматизации бизнес-процессов, внедрения информационной системы (ИС). Однако вследствие быстро меняющихся условий бизнеса наблюдается тенденция к сокращению жизненного цикла ИС. Это, в свою очередь, предъявляет жесткие требования к срокам разработки. Нередки случаи, когда из-за ошибок на ранних этапах создания приходится отодвигать на более позднее время сроки введения системы в эксплуатацию. Автоматизация ранних этапов разработки с помощью CASE-средств (Computer-Aided Software/System Engineering) позволяет ускорить эти этапы и, в то же время, уменьшить количество ошибок.

Существует несколько вариантов жизненных циклов (ЖЦ) информационных систем, подразделяемых на различные стадии, например:

  1. Предпроектная стадия. Здесь основными задачами являются: анализ первичных требований, предварительная экономическая оценка проекта, построение план-графика выполнения работ и т.п.

  2. Стадия проектирования. Об этой стадии подробно см. параграф 2.

Результатом стадии проектирования является системный проект, на основе которого происходит стадия разработки.

  1. Стадия разработки. В случае принятия решения об использования готовой системы одного из производителей, осуществляется ее настройка под конкретные бизнес-процессы компании.

В случае принятия решения о целесообразности собственной разработки системы, осуществляется самостоятельная разработка силами своих или приглашенных специалистов. Сейчас уже стало практически стандартом использование средств быстрой разработки с использованием объектно-ориентированного подхода и библиотек готовых компонент третьих фирм.

  1. Стадия внедрения. На этой стадии производится опытная эксплуатация системы, выявление и исправление ошибок, обучение пользователей (посредством руководств пользователя, обучающих курсов, деловых игр), внесение изменений согласно предложениям, внесенным пользователями.

  2. Стадия промышленной эксплуатации. Когда все подсистемы отлажены, опробованы на реальных данных, устранены все нарекания, система сдается в промышленную эксплуатацию, ради которой она, собственно, и разрабатывалась.

  3. Стадия модернизации. По прошествии некоторого времени, когда условия ведения бизнеса меняются, встает вопрос внесения изменений в эксплуатируемую систему. Если система была спроектирована с учетом последующих изменений, в нее были заложены соответствующие механизмы, то модернизация возможна в короткие сроки. В противном случае, всплывут все просчеты, допущенные на ранних этапах.

Как видно из вышесказанного, стадия проектирования является одной из самых ответственных во всем проекте.

Фактически разработчиками выполняется два вида работ:

  • прежде всего – это элементарное наведение порядка в организации, когда в результате обследования выявляются неэффективные процессы и структуры. Здесь предлагаются пути улучшения бизнеса компании, т.е. происходит реинжиниринг бизнес-процессов (BPR – Business Process Reengineering). В конечном итоге речь идет об автоматизации, поскольку в современном мире трудно придумать эффективные бизнес-процессы без применения информационных технологий;

  • системный анализ и проектирование. Выявление и согласование требований заказчика приводит к пониманию того, что же в действительности необходимо сделать. За этим следует проектирование или выбор готовой системы, в наибольшей степени удовлетворяющей требованиям заказчика.



2.Стадия проектирования информационных систем


На стадии проектирования выполняется ряд обязательных этапов.

1.Обследование деятельности предприятия. На этом этапе осуществляется:

  • определение организационно-штатной и топологической структур предприятия;

  • определение основных задач деятельности предприятия;

  • проведение опросов сотрудников с целью построения функциональной модели деятельности «как есть» и, в случае эксплуатации какой-либо ИС, модели логической организации данных.

Результатом являются модели функциональной деятельности каждого из подразделений, способы взаимодействия между этими подразделениями, информационные потоки (как электронные, так и на традиционных носителях) между ними и внутри них.

Длительность этапа зависит как от размеров предприятия, так и от количества системных аналитиков, участвующих в проекте, и на практике составляет 1-2 недели. В некоторых случаях обследование может длиться и несколько месяцев, это приемлемо для организаций, деятельность которых достаточно консервативна. Для динамичных организаций такие сроки чреваты тем, что к концу обследования аналитики будут обладать устаревшей информацией.

По окончании обследования строится и согласуется с заказчиком предварительный вариант функциональной модели предприятия с достаточной детализацией.

2.Разработка системного проекта. Предварительным этапом здесь является построение моделей деятельности «как должно быть». Существует несколько видов работ, рекомендуемых при построении моделей деятельности:

  • разработка структурной функциональной модели деятельности (методологии IDEF0, DFD – средства BPwin, Design/IDEF и др.);

  • разработка информационной модели предприятия (методологии IDEF1X, ERD – средства ERwin, Database Designer, Design/IDEF, S-Designеr);

  • разработка событийной модели предприятия (метод динамического функционального анализа на основе сетей Петри различного вида).

Построение модели «как должно быть» является изменением технологий и переосмыслением бизнес-процессов (BPR).

Создание системного проекта (модели требований к будущей системе) является первой фазой разработки собственно системы автоматизации и строится на основе модели «как должно быть» и результатов обследования предприятия в части выявления требований к будущей системе. Системный проект должен включать:

  • полную функциональную модель требований к будущей системе;

  • комментарии к функциональной модели (спецификации процессов нижнего уровня в текстовом виде);

  • пакет отчетов и документов по функциональной модели, включающий характеристику объекта моделирования, перечень подсистем, требования к способам и средствам связи для информационного обмена между компонентами, требования к характеристикам взаимосвязей системы со смежными системами, требования к функциям системы;

  • концептуальную модель интегрированной базы данных (пакет диаграмм);

  • архитектуру системы с привязкой к концептуальной модели;

  • предложения по штатной структуре для поддержки системы.

Системный проект позволяет:

  • увидеть и скорректировать будущую систему до того, как она будет реализована физически;

  • уменьшить затраты на разработку и внедрение системы;

  • оценить разработку по времени и результатам;

  • достичь взаимопонимания между всеми участниками работы (заказчиками, пользователями, разработчиками);

  • улучшить качество разрабатываемой системы.

Системный проект полностью независим и отделяем от конкретных разработчиков.

3.Разработка предложений по автоматизации предприятия. На основании системного проекта осуществляется:

  • составление перечня автоматизированных рабочих мест предприятия и способов взаимодействия между ними;

  • анализ применимости существующих систем управления предприятиями для решения требуемых задач и формирование рекомендаций по выбору такой системы;

  • совместное с заказчиком принятие решения о выборе конкретной системы управления предприятием или разработке собственной системы;

  • разработка требований к техническим средствам;

  • разработка требований к программным средствам;

  • разработка предложений по этапам и срокам реализации.

4.Разработка технического проекта. На данном этапе на основе системного проекта и принятых решений по автоматизации осуществляется проектирование системы. Фактически здесь дается ответ на вопрос: «Как мы будем строить систему, чтобы она удовлетворяла предъявленным к ней требованиям?». Этот этап разделяется на:

  • проектирование архитектуры системы, включающее разработку структуры и интерфейсов ее компонент (автоматизированных рабочих мест), согласование функций и технических требований к компонентам, определение информационных потоков между основными компонентами, связей между ними и внешними объектами;

  • детальное проектирование, включающее разработку спецификаций каждой компоненты, разработку требований к тестам и плана интеграции компонент, а также построение моделей иерархии программных модулей и межмодульных взаимодействий и проектирование внутренней структуры модулей.

При этом происходит расширение системного проекта:

  • за счет его уточнения;

  • за счет построения моделей автоматизированных рабочих мест, включающих подсхемы информационной модели и функциональные модели, ориентированные на эти подсхемы вплоть до идентификации конкретных сущностей информационной модели;

  • за счет построения моделей межмодульных и внутримодульных взаимодействий с использованием техники структурных карт.



3.CASE-технологии


CASE-технология представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем и поддерживается комплексом взаимоувязанных средств автоматизации. CASE-технология – это инструментарий для системных аналитиков, разработчиков и программистов, заменяющий бумагу и карандаш компьютером, автоматизируя процесс проектирования и разработки ПО.

При использовании методологий структурного анализа появился ряд ограничений (сложность понимания, большая трудоемкость и стоимость использования, неудобство внесения изменений в проектные спецификации и т.д.) С самого начала CASE-технологии и развивались с целью преодоления этих ограничений путем автоматизации процессов анализа и интеграции поддерживающих средств. Они обладают достоинствами и возможностями, перечисленными ниже.

Единый графический язык. CASE-технологии обеспечивают всех участников проекта, включая заказчиков, единым строгим, наглядным и интуитивно понятным графическим языком, позволяющим получать обозримые компоненты с простой и ясной структурой. При этом программы представляются двумерными схемами (которые проще в использовании, чем многостраничные описания), позволяющими заказчику участвовать в процессе разработки, а разработчикам – общаться с экспертами предметной области, разделять деятельность системных аналитиков, проектировщиков и программистов, облегчая им защиту проекта перед руководством, а также обеспечивая легкость сопровождения и внесения изменений в систему.

Единая БД проекта. Основа CASE-технологии – использование базы данных проекта (репозитория) для хранения всей информации о проекте, которая может разделяться между разработчиками в соответствии с их правами доступа. Содержимое репозитория включает не только информационные объекты различных типов, но и отношения между их компонентами, а также правила использования или обработки этих компонентов. Репозиторий может хранить свыше 100 типов объектов: структурные диаграммы, определения экранов и меню, проекты отчетов, описания данных, логика обработки, модели данных, их организации и обработки, исходные коды, элементы данных и т. п.

Интеграция средств. На основе репозитория осуществляется интеграция CASE-средств и разделение системной информации между разработчиками. При этом возможности репозитория обеспечивают несколько уровней интеграции: общий пользовательский интерфейс по всем средствам, передачу данных между средствами, интеграцию этапов разработки через единую систему представления фаз жизненного цикла, передачу данных и средств между различными платформами.

Поддержка коллективной разработки и управления проектом. CASE-технология поддерживает групповую работу над проектом, обеспечивая возможность работы в сети, экспорт-импорт любых фрагментов проекта для их развития и/или модификации, а также планирование, контроль, руководство и взаимодействие, т. е. Функции, необходимые в процессе разработки и сопровождения проектов. Эти функции также реализуются на основе репозитория. В частности, через репозиторий может осуществляться контроль безопасности (ограничения и привилегии доступа), контроль версий и изменений и др.

Макетирование. CASE-технология дает возможность быстро строить макеты (прототипы) будущей системы, что позволяет заказчику на ранних этапах разработки оценить, насколько она приемлема для будущих пользователей и устраивает его.

Генерация документации. Вся документация по проекту генерируется автоматически на базе репозитория (как правило, в соответствии с требованиями действующих стандартов). Несомненное достоинство CASE-технологии заключается в том, что документация всегда отвечает текущему состоянию дел, поскольку любые изменения в проекте автоматически отражаются в репозитории (известно, что при традиционных подходах к разработке ПО документация в лучшем случае запаздывает, а ряд модификаций вообще не находит в ней отражения).

Верификация проекта. CASE-технология обеспечивает автоматическую верификацию и контроль проекта на полноту и состоятельность на ранних этапах разработки, что влияет на успех разработки в целом – по статистическим данным анализа пяти крупных проектов фирмы TRW (США) ошибки проектирования и кодирования составляют соответственно 64% и 32% от общего числа ошибок, а ошибки проектирования в 100 раз труднее обнаружить на этапе сопровождения ПО, чем на этапе анализа требований.

Автоматическая генерация объектного кода. Генерация программ в машинном коде осуществляется на основе репозитория и позволяет автоматически построить до 85—90% объектного кода или текстов на языках высокого уровня.

Сопровождение и реинжиниринг. Сопровождение системы в рамках CASE-технологии характеризуется сопровождением проекта, а не программных кодов. Средства реинжиниринга и обратного инжиниринга позволяют создавать модель системы из ее кодов и интегрировать полученные модели в проект, автоматически обновлять документацию при изменении кодов и т. п.

Табл. 1

Традиционная технология разработки

Разработка с помощью CASE-технологий

Основные усилия – на кодирование и тестирование

Основные усилия – на анализ и проектирование

«Бумажные» спецификации

Быстрое итеративное макетирование

Ручное кодирование

Автоматическая генерация машинного кода

Тестирование ПО

Автоматический контроль проекта

Сопровождение программного кода

Сопровождение проекта

При использовании CASE-технологий изменяются все фазы жизненного цикла ИС, причем наибольшие изменения касаются фаз анализа и проектирования. В табл. 1 приведены основные изменения жизненного цикла ИС при использовании CASE-технологий по сравнению с традиционной технологией разработки.

Табл. 2

Анализ

Проектирование

Программирование

Тестирование

20%

15%

20%

45%

30%

30%

15%

25%

40%

40%

5%

15%

В табл. 2 приведены оценки трудозатрат по фазам жизненного цикла программного обеспечения (ПО). Первая строка таблицы соответствует традиционной технологии разработки, вторая – разработке с использованием структурных методологий вручную, третья – разработке с использованием CASE-технологий.

  1   2   3   4   5   6

Похожие:

5. Лабораторная работа №1 “Изучение основных функций пакета bpwin” iconЛабораторная работа Разработка в среде
Лабораторная работа Разработка в среде bpwin функциональной модели в нотации idef0
5. Лабораторная работа №1 “Изучение основных функций пакета bpwin” iconЛабораторная работа Методика моделирования предметной области. Моделирование бизнес-процессов средствами bpwin

5. Лабораторная работа №1 “Изучение основных функций пакета bpwin” iconЛабораторная работа №7
Изучение приложения siso design Tool пакета Control system системы matlab для моделирования, имитирования и анализа систем управления...
5. Лабораторная работа №1 “Изучение основных функций пакета bpwin” iconЛабораторная работа №1 Изучение автоматической телеграфной станции ат-пс-пд лабораторная работа №2 Изучение телеграфного коммутационного сервера «Вектор-2000»
Рецензент – зам начальника Гомельской дистанции сигнализации и связи Белорусской железной дороги В. И. Прокопюк
5. Лабораторная работа №1 “Изучение основных функций пакета bpwin” iconЛабораторная работа исследование основных свойств гироскопа
Целью лабораторной работы является изучение основных свойств и экспериментальное исследование наиболее важных характеристик гироскопа...
5. Лабораторная работа №1 “Изучение основных функций пакета bpwin” iconЛабораторная работа №1
Ознакомиться с основными командами программного пакета Optimization Toolbox в оптимизационных задачах
5. Лабораторная работа №1 “Изучение основных функций пакета bpwin” iconЛабораторная работа №2
Ознакомиться с примерами использования программного пакета Optimization Toolbox в оптимизационных задачах
5. Лабораторная работа №1 “Изучение основных функций пакета bpwin” iconЛабораторная работа №1
Ознакомиться с основными командами и примерами использования программного пакета Control System в расчетах систем управления
5. Лабораторная работа №1 “Изучение основных функций пакета bpwin” iconЛабораторная работа №4a
...
5. Лабораторная работа №1 “Изучение основных функций пакета bpwin” iconЛабораторная работа №2
...
Разместите кнопку на своём сайте:
Библиотека


База данных защищена авторским правом ©lib.znate.ru 2014
обратиться к администрации
Библиотека
Главная страница