Logo GenDocs.ru

Поиск по сайту:  


Загрузка...

Сапунцов В.Д., Лысенко М.А. Применение CASE-средств BPwin и ERwin для проектирования информационных систем - файл 1.doc


Сапунцов В.Д., Лысенко М.А. Применение CASE-средств BPwin и ERwin для проектирования информационных систем
скачать (1530 kb.)

Доступные файлы (1):

1.doc1530kb.16.12.2011 08:51скачать

содержание
Загрузка...

1.doc

  1   2   3   4
Реклама MarketGid:
Загрузка...
Российский государственный университет нефти и газа им. И.М.Губкина

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




Применение 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-технологий.

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

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

Полный комплекс CASE-средств, обеспечивающий поддержку жизненного цикла ПО, содержит следующие компоненты:

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

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

  • средства разработки приложений, включая языки 4GL и генераторы кодов;

  • средства конфигурационного управления;

  • средства документирования;

  • средства тестирования;

  • средства управления проектом;

  • средства реинжиниринга.

Все современные CASE-средства могут быть классифицированы прежде всего по типам. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Помимо этого, CASE-средства можно классифицировать по следующим признакам:

  • применяемым методологиям и моделям систем и баз данных (БД);

  • степени интегрированности с системами управления базами данных (СУБД);

  • доступным платформам.

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

  • средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF, BPwin);

  • средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder, Designer/2000, Silverrun, PRO-IV, CASE.Аналитик). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

  • средства проектирования БД, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin, S-Designor и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

  • средства разработки приложений. К ним относятся средства 4GL (Uniface, JAM, PowerBuilder, Developer/2000, New Era, SQLWindows, Delphi и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично – в Silverrun;

  • средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose, Object Team).

Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:

  • Vantage Team Builder (Westmount I-CASE);

  • Designer/2000;

  • Silverrun;

  • ERwin+BPwin;

  • S-Designor;

  • CASE.Аналитик;

  • Rational Rose.

Кроме того, на рынке постоянно появляются как новые для отечественных пользователей системы, так и новые версии и модификации перечисленных систем.

^ CASE-средство Silverrun американской фирмы Computer Systems Advisers, Inc. (CSA) используется для анализа и проектирования ИС бизнес-класса и ориентировано в большей степени на спиральную модель ЖЦ. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм «сущность-связь»).

Система Silverrun реализована на трех платформах – MS Windows, Macintosh и OS/2 Presentation Manager – с возможностью обмена проектными данными между ними.

^ Vantage Team Builder представляет собой интегрированный программный продукт, ориентированный на реализацию каскадной модели ЖЦ ПО и поддержку полного ЖЦ ПО.

Vantage Team Builder обеспечивает выполнение следующих функций:

  • проектирование диаграмм потоков данных, «сущность-связь», структур данных, структурных схем программ и последовательностей экранных форм;

  • проектирование диаграмм архитектуры системы – SAD (проектирование состава и связи вычислительных средств, распределения задач системы между вычислительными средствами, моделирование отношений типа «клиент-сервер», анализ использования менеджеров транзакций и особенностей функционирования систем в реальном времени);

  • генерация кода программ на языке 4GL целевой СУБД с полным обеспечением программной среды и генерация SQL-кода для создания таблиц БД, индексов, ограничений целостности и хранимых процедур;

  • программирование на языке C со встроенным SQL;

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

  • многопользовательский доступ к репозиторию проекта;

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

  • экспорт и импорт данных проекта в формате CDIF (CASE Data Interchange Format).

Vantage Team Builder поставляется в различных конфигурациях в зависимости от используемых СУБД (ORACLE, Informix, Sybase или Ingres) или средств разработки приложений (Uniface). Конфигурация Vantage Team Builder for Uniface отличается от остальных некоторой степенью ориентации на спиральную модель ЖЦ ПО за счет возможностей быстрого прототипирования, предоставляемых Uniface.

Vantage Team Builder функционирует на всех основных UNIX-платформах (Solaris, SCO UNIX, AIX, HP-UX) и VMS.

^ CASE-средство Designer/2000 2.0 фирмы ORACLE является интегрированным CASE-средством, обеспечивающим в совокупности со средствами разработки приложений Developer/2000 поддержку полного ЖЦ ПО для систем, использующих СУБД ORACLE.

Designer/2000 представляет собой семейство методологий и поддерживающих их программных продуктов. Базовая методология Designer/2000 (CASE*Method) – структурная методология проектирования систем, охватывающая полностью все этапы жизненного цикла ИС.

Генерация приложений, помимо продуктов ORACLE, выполняется также для Visual Basic.

Designer/2000 можно интегрировать с другими средствами, используя открытый интерфейс приложений API (Application Programming Interface). Кроме того, можно использовать средство ORACLE CASE Exchange для экспорта/импорта объектов репозитория с целью обмена информацией с другими CASE-средствами.

Среда функционирования Designer/2000 – Windows 3.x, Windows 95, Windows NT.

^ BPwin, ERwin – средства функционального и концептуального моделирования, реализующие методологии IDEF0 и IDEF1X соответственно. Об этих системах более подробная информация представлена ниже.

S-Designor 4.2 представляет собой CASE-средство для проектирования реляционных баз данных. По своим функциональным возможностям и стоимости он близок к CASE-средству Erwin, отличаясь внешне используемой на диаграммах нотацией. S-Designor реализует стандартную методологию моделирования данных и генерирует описание БД для таких СУБД, как ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server и др. Для существующих систем выполняется реинжиниринг БД.

S-Designor совместим с рядом средств разработки приложений (PowerBuilder, Uniface, TeamWindows и др.) и позволяет экспортировать описание БД в репозитории данных средств. Для PowerBuilder выполняется прямая генерация шаблонов приложений.

CASE.Аналитик 1.1 является практически единственным в настоящее время конкурентоспособным отечественным CASE-средством функционального моделирования . Его основные функции:

  • построение и редактирование диаграмм потоков данных DFD;

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

  • получение разнообразных отчетов по проекту;

  • генерация макетов документов в соответствии с требованиями ГОСТ 19.ХХХ и 34.ХХХ.

Среда функционирования: процессор – 386 и выше, основная память – 4 Мб, дисковая память – 5 Мб, MS Windows 3.x или Windows 95.

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

^ Rational Rose – CASE-средство фирмы Rational Software Corporation (США) – предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML – Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант – Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

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

Rational Rose функционирует на различных платформах: IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX).


^ 5. Лабораторная работа №1

Изучение основных функций пакета BPwin”
BPwin позволяет аналитику создавать сложные модели бизнес-процессов при минимальных усилиях. BPwin поддерживает три методологии – IDEF0, IDEF3 и DFD. Каждая из них призвана решать свои специфические задачи. Также можно строить смешанные модели.

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

Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в IDEF0 представлена совокупностью иерархически упорядоченных и логически связанных диаграмм. Каждая диаграмма располагается на отдельном листе. Можно выделить четыре типа диаграмм:

  • контекстную диаграмму А-0 (в каждой модели может быть только одна контекстная диаграмма);

  • диаграммы декомпозиции (в том числе диаграмма первого уровня декомпозиции А0, раскрывающая контекстную);

  • диаграммы дерева узлов;

  • диаграммы только для экспозиции (FEO).

Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой (как правило, здесь описывается основное назначение моделируемого объекта). После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы (получения диаграммы А0) проводится декомпозиция каждого блока диаграммы А0 на более мелкие фрагменты и так далее, до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы – эксперты предметной области (обычно это интервьюируемые аналитиками сотрудники предприятий) указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели.

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

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

^ Каркас диаграммы. На рис.1 показан пример контекстной диаграммы с граничными рамками, которые называются каркасом диаграммы. Каркас содержит заголовок (верхняя часть рамки, табл.3) и подвал (нижняя часть, табл.4). Заголовок каркаса используется для отслеживания диаграммы в процессе моделирования. Нижняя часть используется для идентификации и позиционирования в иерархии диаграмм. Значения полей каркаса задаются в диалоге Diagram Properties (в меню Edit/Diagram Properties).



Рис.1.Контекстная диаграмма
^ Поля заголовка каркаса (слева направо)

Табл. 3

Поле

Смысл

Used At

Используется для указания на родительскую работу в случае, если на текущую диаграмму ссылались посредством стрелки вызова.

Author, Date, Rev, Project

Имя создателя диаграммы, дата создания и имя проекта, в рамках которого была создана диаграмма. REV – дата последнего редактирования диаграммы.

Notes 1 2 3 4 5 6 7 8 9 10

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

Status

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

Working

Новая диаграмма, кардинально обновленная диаграмма или новый автор диаграммы.

Draft

Диаграмма прошла первичную экспертизу и готова к дальнейшему обсуждению.

Recommended

Диаграмма и все ее сопровождающие документы прошли экспертизу. Новых изменений не ожидается.

Publication

Диаграмма готова к окончательной печати и публикации.

Reader

Имя читателя (эксперта).

Date

Дата прочтения (экспертизы).

Context

Схема расположения работ в диаграмме верхнего уровня. Работа, являющаяся родительской, показана темным прямоугольником, остальные – светлым. На контекстной диаграмме (А-0) показывается надпись TOP. В левом нижнем углу показывается номер по узлу родительской диаграммы.


^ Поля подвала каркаса (слева направо)

Табл. 4

Поле

Смысл

Node

Номер узла диаграммы (номер родительской работы)

Title

Имя диаграммы. По умолчанию – имя родительской работы

Number

C-Number, уникальный номер версии диаграммы

Page

Номер страницы, может использоваться как номер страницы при формировании папки


Задание. На основе резюме, описывающих функционирование конкретного отдела РГУ нефти и газа им. И.М.Губкина, создать контекстную диаграмму А-0. Выделить основные его функции и создать диаграмму А0. Разбить каждую функцию на подфункции и диаграммы третьего уровня. Предоставить иерархию диаграмм.

Вопросы.

1.Каковы стадии жизненного цикла информационных систем, их основное содержание?

2.Что такое реинжиниринг бизнес-процессов?

3.Какие виды работ рекомендуется выполнить при построении моделей деятельности, какие средства и методологии при этом используются?

4.Каковы основные функции CASE-средства BPwin?

5.Как представляется функциональная модель деятельности в методологии IDEF0?

^ 6.Лабораторная работа №2

Изучение объектов диаграмм функциональной модели”
Работы (Activity). Работы обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников (блоков). Все работы должны быть названы и определены. Имя работы должно быть в глагольной или отглагольной форме (например, «Принять заказ», «Изготовление детали» и т.д.). Работу можно добавить, щелкнув по кнопке



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

Рис.2.Диаграмма декомпозиции

Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню пункт Name Editor и в появившемся диалоге внести имя работы (рис.3).

Р
ис.3.Внесение имени работы

Для создания диаграммы декомпозиции следует щелкнуть по кнопке





и выбрать на диаграмме работу, которую необходимо декомпозировать.

В
озникает диалог Activity Box Count (рис.4), в котором следует указать нотацию новой диаграммы. Надо выбрать IDEF0 и надавить ОК.
Рис.4.Выбор нотации диаграммы
На диаграмме декомпозиции работы нумеруются автоматически слева направо. Номер работы показывается в правом нижнем углу. В левом верхнем углу изображается небольшая диагональная черта, которая показывает, что данная работа не была декомпозирована.

^ Стрелки (Arrows). Взаимодействие работ с внешним миром описывается в виде стрелок. Стрелки представляют собой некую информацию и именуются существительными (например, «Заготовка», «Изделие», «Заказ»).

В IDEF0 различают пять типов стрелок.

  • Вход (Input) – материал или информация, которая используется или преобразуется работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне блока или выходит из нее. Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может служить то, перерабатываются/изменяются ли данные в работе или нет. Если изменяются, то скорее всего это вход, если нет – управление.

  • Управление (Control) – правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Управление влияет на работу, но не преобразуется ей. Если цель работы – изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом.

  • Выход (Output) – материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода.

  • Механизм (Mechanism) – ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т.д.

  • Вызов (Call) – специальная стрелка, указывающая на другую модель работы. Рисуется как исходящая из нижней грани работы. Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы. Используются в механизме слияния и разделения моделей.

Каждый тип стрелок подходит к определенной стороне блока или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. Стрелка управления рисуется как входящая в верхнюю грань. Выход рисуется как исходящая стрелка из правой грани. Механизм – входит в нижнюю.

^ Граничные стрелки. Стрелки на контекстной диаграмме служат для описания взаимодействия системы с окружающим миром. Они могут начинаться у границы диаграммы и заканчиваться у работы или наоборот. Такие стрелки называются граничными. Для внесения граничной стрелки надо:

  • щелкнуть по кнопке с символом стрелки

в
палитре инструментов. Дальше перенести курсор к левой стороне экрана, пока не появится начальная штриховая полоска;

  • щелкнуть один раз по полоске (откуда выходит стрелка) и еще раз в левой части работы со стороны входа (где заканчивается стрелка);

  • вернуться в палитру инструментов и выбрать редактирование стрелки





  • щелкнуть правой кнопкой мыши на линии стрелки, во всплывающем меню выбрать пункт Name Editor и добавить имя стрелки в закладке Name диалога IDEF0 Arrow Properties.

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

Имена вновь внесенных стрелок автоматически заносятся в словарь.

^ Словарь стрелок (Arrow Dictionary) редактируется при помощи специального редактора Arrow Dictionary Editor (рис.5), в котором определяется стрелка и вносится относящийся к ней комментарий.

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

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

Для рисования внутренней стрелки необходимо в режиме рисования стрелок щелкнуть по сегменту (например, выхода) одной работы и затем по сегменту (например, входа) другой. В IDEF0 различают пять типов связей работ:

  • связь по входу (output-input), когда стрелка выхода вышестоящей работы (далее – просто выход) направляется на вход нижестоящей;

  • связь по управлению (output-control), когда выход вышестоящей работы направляется на управление нижестоящей. Связь по входу показывает доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей;

  • обратная связь по входу (output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов;

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

  • связь выход-механизм (output-mechanism), когда выход одной работы направляется на механизм другой. Эта взаимосвязь используется реже остальных и показывает, что одна работа подготавливает ресурсы, необходимые для проведения другой работы.


^ Явные стрелки. Явная стрелка имеет источником одну-единственную работу и назначением тоже одну-единственную работу.
Разветвляющиеся и сливающиеся стрелки. Одни и те же данные или объекты, порожденные одной работой, могут использоваться сразу в нескольких других работах. С другой стороны, стрелки, порожденные в разных работах, могут представлять собой одинаковые или однородные данные или объекты, которые в дальнейшем используются или перерабатываются в одном месте. Для моделирования таких ситуаций IDEF0 используются разветвляющиеся и сливающиеся стрелки. Для разветвления стрелки нужно в режиме редактирования стрелки щелкнуть по фрагменту стрелки и по соответствующему сегменту работы. Для слияния двух стрелок выхода нужно в режиме редактирования стрелки сначала щелкнуть по сегменту выхода работы, а затем по соответствующему фрагменту стрелки.
^ Тоннелирование стрелок. Вновь внесенные граничные стрелки на диаграмме декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня. Для их «перетаскивания» наверх нужно сначала выбрать кнопку

н

а палитре инструментов и щелкнуть по квадратным скобкам граничной стрелки. Появится диалог Border Arrow Editor (рис.6).
Рис.6.Диалог для тоннелирования стрелок
Если щелкнуть по кнопке Resolve Border Arrow, стрелка мигрирует на диаграмму верхнего уровня, если по кнопке Change To Tunnel – стрелка будет затоннелирована и не попадет на другую диаграмму. Тоннельная стрелка изображается с круглыми скобками на конце.

Тоннелирование может быть применено для изображения малозначимых стрелок. Если на какой-либо диаграмме нижнего уровня необходимо изобразить малозначимые данные или объекты, которые не обрабатываются или не используются работами на текущем уровне, то их необходимо направить на вышестоящий уровень. Если эти данные не используются на родительской диаграмме, их нужно направить еще выше и т.д. В результате малозначимая стрелка будет изображена на всех уровнях и затруднит чтение всех диаграмм, на которых она присутствует. Выходом является тоннелирование стрелки на самом нижнем уровне. Такое тоннелирование называется «Не-в-родительской-диаграмме».

Другим примером тоннелирования может быть ситуация, когда стрелка механизма мигрирует с верхнего уровня на нижний, причем на нижнем уровне этот механизм используется одинаково во всех работах без исключения. В этом случае стрелка механизма на нижнем уровне может быть удалена, после чего на родительской диаграмме она может быть затоннелирована («Не-в-дочерней-работе»).
Задание. Исходя из результатов предыдущей лабораторной работы, создать все диаграммы в программе, расположить на них все блоки и дуги, описывающие заданный отдел. Получить законченную модель функционирования отдела.
  1   2   3   4



Скачать файл (1530 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации
Рейтинг@Mail.ru