Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лаб практ Бахтизин Вячеслав Вениаминович, Глухова Лилия Александровна, БГУИР 2007 (Лаб практикум).pdf
Скачиваний:
161
Добавлен:
15.06.2014
Размер:
2 Мб
Скачать
☆

ВВЕДЕНИЕ

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

Внастоящее время существует ряд методологий, специально

предназначенных для упрощения системного анализа

и моделирования

предметной области. Данные

методологии поддерживаются

специальными

инструментальными средствами автоматизированного анализа, моделирования

и

разработки

сложных

систем, получившими

название CASE-средств

(Computer-Aided Software/System Engineering – компьютерная

поддержка

проектирования программного обеспечения/систем).

 

 

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

анализа и

моделирования предметной

области

должно

являться

основой

начального

этапа разработки любой

сложной

системы, в

том числе

и

программной.

 

 

 

 

 

 

 

 

 

 

 

Одним из инструментов системного анализа являетсяCASE-средство

 

верхнего

уровня BРwin (Business Process for Windows) [4]. Термин Business

 

Process («бизнес-процесс») близок по смыслу к термину«предметная область»

 

и в настоящее время часто заменяет последний. BРwin разработан фирмой

 

LogicWorks. После слияния в 1998г. фирм LogicWorks и PLATINUM technology

 

данное CASE-средство выпускается под логотипом PLATINUM technology [4].

 

В данном учебном пособии описана одна из последних версий продукта

 

BРwin

–

версия BPwin

2.5,

превзошедшая

 

предыдущие

 

как

по

функциональности, так и по удобству пользовательского интерфейса.

 

 

 

Основными функциями BPwin являются, во-первых, рисование диаграмм,

 

представляющих

собой

средства

визуального

представления

отдельных

компонентов

 

моделируемой

предметной

 

области

различных

уровн

детализации,

во-вторых, проверка

целостности

и

согласованности

иерархической

модели, построенной

из

диаграмм

различных

уровней

детализации, в-третьих, генерация различного вида отчетов по построенной

 

модели. К

достоинствам BPwin

следует отнести

 

обеспечение

логической

 

четкости в определении и описании элементов диаграмм, проверку целостности связей между диаграммами, локализацию или коррекцию наиболее часто встречающихся ошибок при моделировании [4].

6

1.1. МЕТОДОЛОГИИ ПРОЕКТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ,

ПОДДЕРЖИВАЕМЫЕ BPWIN

2.1.1.Общие сведения

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

BРwin поддерживает три методологии структурного анализа моделирования систем - IDEF0, IDEF3 и DFD. В процессе создания модели бизнес-процесса на любой ветви модели можно переключиться на любую из методологий и создать смешанную модель [4].

В IDEF0-модели операция представляет собой процесс преобразования входных материалов или информации в некоторый результат на выходе с использованием ресурсов в виде механизма и при выполнении ,условий представленных в виде управления.

Методология DFD включает такие понятия, как внешняя ссылка и хранилище данных. Это делает её более удобной по сравнению IDEF0с для моделирования программного обеспечения и систем документооборота.

Методология IDEF3 включает элемент “перекрёсток”, что позволяет описать логику взаимодействия компонентов системы.

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

2.1.2. Методология функционального

моделирования IDEF0

Основные понятия IDEF0

При реализации программы интегрированной компьютеризаци производства (ICAM), которая финансировалась правительством и военными ведомствами США с середины70-х годов, были разработаны принципы повышения эффективности производства за счет внедрения компьютерных технологий. В соответствии с проектомICAM было разработано семейство методологий IDEF (ICAM DEFinition), состоящее из ряда самостоятельных

7

методологий

моделирования

различных

аспектов

функционирован

производственной среды или системы [3].

 

 

Одной

из данных методологий являетсяIDEF0 (Integrated

Definition

Function Modeling), принятая в настоящее время в качестве федерального стандарта США.

Методология функционального моделированияIDEF0 является подмножеством методологии структурного анализа и проектированияSADT (Structured Analysis And Design Technique), разработанной Дугласом Россом.

При полном SADT-моделировании используются взаимодополняющие модели двух типов [5]:

·функциональные модели, выделяющие события (функции, бизнеспроцессы) в системе;

·модели данных, выделяющие объекты (данные) системы.

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

Функциональный вариант SADT-методологии в стандартизированной версии правительства США получил название IDEF0.

Методология IDEF0 успешно применяется в самых различных отраслях как эффективное средство анализа, проектирования и представления деловых процессов.

Основной структурной единицейIDEF0-модели является диаграмма, представляющая собой графическое описание модели предметной области или

еечасти. Главными компонентами IDEF0-диаграммы являются блоки.

Блоки отображают

некоторые

работы, функции, процессы, задачи,

которые происходят или

выполняются

в течение определённого времени и

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

Каждая сторона функционального блока имеет различное назначение (рис.1.1).

Управление

Вход

Выход

Бизнес-функция

Механизм

Рис.1.1. Основная конструкция IDEF0-модели

8

Левая сторона блока предназначена для входа, правая – для выхода, верхняя – для управления, нижняя – для механизмов. Название блока соответствует его функции или выполняемой им работе.

Взаимодействие функций с внешним миром и между собой описывается с

помощью дуг (связей), представляемых на диаграммах

в виде линий со

стрелками (Arrow). В IDEF0 различают пять типов дуг.

 

Вход (Input) – материал или информация, которые

используются или

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

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

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

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

станки. Данный вид дуг поступает на нижнюю сторону блока.

 

 

 

Вызов

(Call)

–

специальная

дуга,

указывающая

на

другую

модель

предметной области. Данный вид дуги выходит из нижней стороны блока. Дуга

вызова не является компонентом собственно методологииSADT. Она является

расширением

IDEF0-методологии

и

 

предназначена

для

 

организаци

коллективной работы над моделью, разделения модели на независимые модели

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

 

 

Для

идентификации

граничных

 

дуг

 

используютсяICOM-коды

(аббревиатура из первых букв типов

связей– Input, Control, Output и

Mechanism).

Граничной

дугой

называется

дуга, выходящая за

пределы

диаграммы.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Код ICOM содержит префикс, соответствующий

типу дуги (I, C, O или

M), и порядковый номер, учитывающий положение данной дуги по отношению

к родительскому блоку (рис.1.2).

 

 

 

 

 

 

 

 

 

 

Основополагающими

понятиями IDEF0-методологии

являются

цель

моделирования, точка зрения и субъект моделирования.

 

 

 

 

Точка

зрения –

это

представление

о

системе

с

позиции

некоторого

участника

процесса (например,

при

 

моделировании

 

некоторого

производственного

процесса это

может

быть

точка

зрения

руководителя,

технолога, рабочего,

экономиста,

контролера

и

т..д). Точка

зрения

должна

соответствовать цели моделирования.

Цель моделирования определяет степень детализации разрабатываемой модели.

Субъект моделирования определяет границы моделируемой системы и окружающей ее внешней среды.

9