Диаграммы дерева узлов и FEO. Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой

Методология RAD

Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:

·  небольшую команду программистов (от 2 до 10 человек);

·  короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

·  фаза анализа и планирования требований;

·  фаза проектирования;

·  фаза построения;

·  фаза внедрения.

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

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

Основные принципы RAD:

·  разработка приложений итерациями;

·  необязательность полного завершения работ на каждом из этапов жизненного цикла;

·  обязательное вовлечение пользователей в процесс разработки ИС;

·  необходимое применение CASE-средств, обеспечивающих целостность проекта;

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

·  необходимое использование генераторов кода;

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

·  тестирование и развитие проекта, осуществляемые одновременно с разработкой;

·  ведение разработки немногочисленной хорошо управляемой командой профессионалов;

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

Информационная система

Информационная система (ИС) масштаба корпорации представляет собой сложный мультимодельный объект проектирования. Компания "Системные Технологии" выделяет следующие компоненты типовой информационной системы:

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

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

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

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

архитектура системотехнической платформы
архитектура телекоммуникационной системы
архитектура прикладного программно-информационного обеспечения

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

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

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

Систеиные Технологии используют:

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

Выбор интеллектуальных систем в качестве средств динамического моделирования основан на последних практических достижениях в области инженерии знаний и искусственного интеллекта. Наиболее мощными инструментальными средствами такого типа являются: динамическая интеллектуальная система G2 фирмы Gensym (USA) и ее дочерняя моделирующая система ReThink. Эти средства позволяют преодолеть основные трудности, связанные с размерностью задач моделирования крупномасштабных организаций, и обеспечивают пользователю ряд важных преимуществ.

Вопрос № 27.

Case-технологии

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

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

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

подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;

широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования;

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

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

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

CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;

реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

Для успешного внедрения CASE-средств организация должна обладать следующими качествами:

Технология. Понимание ограниченности существующих возможностей и способность принять новую технологию;

Культура. Готовность к внедрению новых процессов и взаимоотношений между разработчиками и пользователями;

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

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

достоверная оценка отдачи от инвестиций в CASE-средства затруднительна ввиду отсутствия приемлемых метрик и данных по проектам и процессам разработки ПО;

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

отсутствие полного соответствия между теми процессами и методами, которые поддерживаются CASE-средствами, и теми, которые используются в данной организации, может привести к дополнительным трудностям;

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

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

негативное отношение персонала к внедрению новой CASE-технологии может быть главной причиной провала проекта.

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

Успешное внедрение CASE-средств должно обеспечить такие выгоды как:

высокий уровень технологической поддержки процессов разработки и сопровождения ПО;

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

приемлемый уровень отдачи от инвестиций в CASE-средства.

Вопрос №2

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

Система имеет следующие основные характеристики (рис.1.1):

Компоненты.
Отношения (связи, посредством которых осуществляется взаимодействие между компонентами).
Граница.
Цель.
Внешняя среда.
Вход, Выход.
Интерфейс.
Законы, правила, ограничения функционирования.

Системные характеристики можно описать следующим образом:

1. Компонент есть либо неделимая часть, либо агрегат, состоящий из частей и называемый подсистемой.

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

3. Система имеет границу, внутри которой содержатся все компоненты, и которая устанавливает пределы системы, отделяя ее от других систем.

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

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

6. Система имеет множество входных и выходных объектов.

7. Точка, в которой система взаимодействует со средой, называется интерфейсом.

8. Система имеет законы, правила, ограничения функционирования.

Сложные динамические системы обладают следующими системообразующими факторами [6]:

целостность и возможность декомпозиции на элементы O (объекты, подсистемы);
наличие стабильных связей (отношений) R между элементами O;
упорядоченность (организация) элементов в определенную структуру (Str);
наделение элементов параметрами (A_O);
наличие синергетических (интегративных) свойств Q, которыми не обладают ни один из элементов системы;
наличие множества законов, правил и операций Z с вышеперечисленными атрибутами системы;
наличие цели функционирования и развития (G).

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

Таким образом, система есть совокупность Syst ={ O (A_O), R, Str, Q, Z, G, S }.

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

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

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

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

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

Рассмотрим практическую деятельность человека, т. е. его активное и целенаправленное воздействие на окружающую среду. Покажем, что человеческая практика системна. Отметим очевидные и обязательные признаки системности: структурированность системы, взаимосвязанность составляющих ее частей, подчиненность организации всей системы определенной цели. По отношению к человеческой деятельности эти признаки очевидны. Всякое осознанное действие преследует определенную цель. Во всяком действии достаточно просто увидеть его составные части, более мелкие действия. При этом легко убедиться, что эти составные части должны выполняться не в произвольном порядке, а в определенной их последовательности. Это и есть та самая определенная, подчиненная цели взаимосвязанность составных частей, которая и является признаком системности. Название для такого построения деятельности - алгоритмичностъ. Понятие алгоритма возникло сначала в математике и означало задание точно определенной последовательности однозначно понимаемых операций над числами или другими математическими объектами. В настоящее время понятие алгоритма применяется к различным отраслям деятельности. Так говорят не только об алгоритмах принятия управленческих решений, об алгоритмах обучения, алгоритмах написания программ, но и об алгоритмах изобретательства [2]. Алгоритмизуются такие виды деятельности как игра в шахматы, доказательство теорем и т. п. При этом делается отход от математического понимания алгоритма. Важно сознавать, что в алгоритме должна сохраняться логическая последовательность действий. При этом допускается, что в алгоритме определенного вида деятельности могут присутствовать неформализованные виды действия. Важно лишь, чтобы определенные этапы алгоритма успешно, хотя бы и неосознанно, выполнялись человеком.

Примеры систем.

1) Самолет - это летательный аппарат тяжелее воздуха с аэродинамическим принципом полета.
При полете используются:

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

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

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

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

2) Вычислительная сеть – сложная система, которая состоит из вычислительных машин и сети передачи данных (сети связи).

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

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

Приведенные примеры систем иллюстрируют наличие таких факторов системности, как целостность и возможность декомпозиции на элементы O (в вычислительной сети это вычислительные машины, средства связи и др.); наличие стабильных связей (отношений) R между элементами O; упорядоченность (организация) элементов в определенную структуру (Str); наделение элементов параметрами (A_O); наличие синергетических (интегративных) свойств Q, которыми не обладают ни один из элементов системы (взаимодействие удаленных пользователей, Web-услуги, электронная коммерция); наличие множества законов, правил и операций Z с вышеперечисленными атрибутами системы; наличие цели функционирования и развития (G).

Классификация систем

Подходы к классификации системы могут быть самыми разными:

• по виду отображаемого объекта-технические, биологические, социальные и т. п.;

• по характеру поведения - детерминированные, вероятностные, игровые;

• по типу целеустремленности - открытые и закрытые;

• по сложности структуры и поведения - простые и сложные;

• по виду научного направления, используемого для их моделирования - математические, физические, химические и др.;

• по степени организованности - хорошо организованные, плохо организованные и самоорганизующиеся.

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

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

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

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

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

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

Классификация по признаку организованности систем впервые была предложена В.В. Налимовым [2]. Под хорошо организованной системой понимается система, у которой определены все элементы, их взаимосвязь, правила объединения в более крупные компоненты, связи между всеми компонентами и целями системы, ради достижения которых создается или функционирует система. При этом подразумевается, что все элементы системы с их взаимосвязями между собой, а также с целями системы можно отобразить в виде аналитических зависимостей. При формулировании задачи принятия решения для хорошо организованной системы проблемная ситуация описывается в виде математического выражения, критерия эффективности, критерия функционирования системы, который может быть представлен сложным уравнением, системой уравнений, сложными математическими моделями, включающими в себя и уравнения, и неравенства, и т. п. Важно, что решение задачи при представлении ее в виде хорошо организованной системы осуществляется аналитическими методами с использованием моделей формализованного представления системы. Примером хорошо организованной системы может служить сложное электронное устройство. Описание его работы производят с помощью системы уравнений, учитывающих условия функционирования, в том числе наличие шумов, нестабильность электропитания и т.д.

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

Вопрос № 8

Проектирование это деятельность по переработки информации о потребности в информации о новом средстве удовлетворение потребности.

Системное проектирование – это метод исследования генезиса технических объектов основанных на построении и изучение процессов выявления и формализации потребности и создание информационной модели будущего объекта.

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

Вход процесса проектирования есть осознанная потребность в техническом объекте, выраженная текстом.

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

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

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

Документирование — получение известного результата известными средствами. Фиксация информации о целях и средствах в виде текстов, чертежей, формул в вербальном, графическом, цифровом виде на основе фиксированных правил и информационных массивов (инструкций, ТУ, стандартов и т.п.).

Вопрос № 24

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

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

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

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

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

- SADT-технологии – это технологии структурного анализа и проектируемое ее подмножество.

- IDEF0 – это нотация для моделирования функций.

- IDEF 3 – это методология описания потоков работ.

- DFD – диаграммы потоков данных.

- ERD – диаграммы «сущность-связь».

- STD – диаграммы переходов состояний.

При описании БП на верхнем уровне в обязательном порядке должны быть определенны:

1. название БП,

2. входы БП,

3. выходы БП,

4. исполнитель – структурное подразделение, отдельные рабочие, внешний исполнитель,

5. управляющие входы БП – нормативные и организационно-распределительные.

Описание БП должно сопровождаться разработкой ряда документов, например:

- положения, должностные и рабочие инструкции,

- спецификация операций (описание),

- спецификация входов и выходов,

- спецификация на ресурсы,

- графические схемы БП и их текстовое описание,

- показатели БП,

- глоссарий (расшифровка терминов),

- перечень документов БП,

- альбом документов БП.

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

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

- хорошей структурированностью (при помощи небольшого числа типов структурных элементов);

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

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

Для структурных методов характерны различные способы «борьбы» со сложностью самой модели, например:

- ограничение числа элементов на каждом из уровней (обычно от 3 до 7);

- ограничение контекста, включающего лишь существенные на каждом уровне детали;

- использование строгих формальных правил записи.

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

Практически во всех методах структурного анализа используются три группы средств моделирования:

1) диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между ними; чаще всего используются DFD (Data Flow Diagrams) - диаграммы потоков данных и иногда диаграммы SADT (IDEF0) или диаграммы Росса;

2) диаграммы, моделирующие данные и их взаимосвязи; фактическим стандартом здесь стали ERD (Entity-Relationship Diagrams) – диаграммы «сущность-связь»;

3) диаграммы, моделирующие поведение системы, зависящее от времени (аспекты реального времени); наиболее часто аспекты поведения системы во времени моделируются при помощи STD (State Transition Diagrams) – диаграмм переходов состояний.

Таким образом, наиболее существенное различие между разновидностями структурного анализа заключается в методах и средствах функционального моделирования. С этой точки зрения все разновидности структурного анализа можно разбить на две группы – применяющие методы, нотацию и технологию DFD и использующие SADT-методологию. К первой группе (условно DFD-методологии) относятся методологии Yourdon, Gane – Sarson, SSADM и др. Ко второй группе (условно SADT-методологии) относятся собственно методология SADT и набор стандартов IDEF. На рисунке показано соотношение применения методологий в CASE-средствах. Представляется очевидным, что соотношение того же порядка справедливо и для цифр распространенности рассматриваемых методологий на практике.

Сравнительный анализ двух методологий мы проведем по следующим параметрам:

- адекватность средств рассматриваемой проблеме;

- согласованность с другими средствами структурного анализа;

- интеграция с последующими фазами проектирования системы

Вопрос № 26 Моделирование бизнес-процессов средствами BPwin

[AD] Моделирование деловых процессов, как правило, выполняется с помощью case-средств. К таким средствам относятся BPwin (PLATINUM technology), Silverrun (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) и др. Функциональные возможности инструментальных средств структурного моделирования деловых процессов будут рассмотрены на примере case-средства BPwin. BPwin поддерживает три методологии моделирования: функциональное моделирование (IDEF0); описание бизнес-процессов (IDEF3); диаграммы потоков данных (DFD). Инструментальная среда BPwin BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя. При запуске BPwin по умолчанию появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели — Model Explorer (рис. 7.1). При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново или она будет открыта из файла либо из репозитория ModelMart, затем внести имя модели и выбрать методологию, в которой будет построена модель (рис. 7.2). Как было указано выше, BPwin поддерживает три методологии — IDEF0, IDEF3 и DFD, каждая из которых решает свои специфические задачи. В BPwin возможно построение смешанных моделей, т. е. модель может содержать одновременно диаграммы как IDEF0, так и IDEF3 и DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую.

Рис. 7.1. Интегрированная среда разработки модели BPwin

Рис. 7.2. Диалог создания модели Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные — в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта. Построение модели IDEF0 На начальных этапах создания ИС необходимо понять, как работает организация, которую собираются автоматизировать. Руководитель хорошо знает работу в целом, но не в состоянии вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник хорошо знает, что творится на его рабочем месте, но может не знать, как работают коллеги. Поэтому для описания работы предприятия необходимо построить модель, которая будет адекватна предметной области и содержать в себе знания всех участников бизнес-процессов организации. Наиболее удобным языком моделирования бизнес-процессов является IDEF0, где система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной — функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации. Процесс моделирования системы в IDEF0 начинается с создания контекстной диаграммы — диаграммы наиболее абстрактного уровня описания системы в целом, содержащей определение субъекта моделирования, цели и точки зрения на модель. Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, определить, что будет в дальнейшем рассматриваться как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будут существенно влиять позиция, с которой рассматривается система, и цель моделирования — вопросы, на которые построенная модель должна дать ответ. Другими словами, в начале необходимо определить область моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в ходе моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет направление моделирования. При формулировании области необходимо учитывать два компонента — широту и глубину. Широта подразумевает определение границ модели — что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо помнить об ограничениях времени — трудоемкость построения модели растет в геометрической прогрессии с увеличением глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему. Цель моделирования Цель моделирования определяется из ответов на следующие вопросы: · Почему этот процесс должен быть смоделирован? · Что должна показывать модель? · Что может получить клиент? Точка зрения (Viewpoint). Под точкой зрения понимается перспектива, с которой наблюдалась система при построении модели. Хотя при построении модели учитываются мнения различных людей, все они должны придерживаться единой точки зрения на модель. Точка зрения должна соответствовать цели и границам моделирования. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом. IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Model/Model Properties, вызывающий диалог Model Properties (рис. 7.3). В закладке Purpose следует внести цель и точку зрения, а в закладку Definition — определение модели и описание области.

Рис. 7.3. Диалог задания свойств модели В закладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). В закладке Source описываются источники информации для построения модели (например, "Опрос экспертов предметной области и анализ документации"). Закладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели — AS-IS и ТО-ВЕ. Модели AS-IS и ТО-ВЕ. Обычно сначала строится модель существующей организации работы — AS-IS (как есть). Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) — модели новой организации бизнес-процессов. Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, то есть создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС. Иногда текущая AS-IS и будущая ТО-ВЕ модели различаются очень сильно, так что переход от начального к конечному состоянию становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состоянию системы, поскольку такой переход — это тоже бизнес-процесс. Результат описания модели можно получить в отчете Model Report. Диалог настройки отчета по модели вызывается из пункта меню Tools/Reports/Model Report. В диалоге настройки следует выбрать необходимые поля, при этом автоматически отображается очередность вывода информации в отчет (рис. 7.4).

Рис. 7.4. Диалоговое окно для формирования отчета по модели На рис. 7.5 представлен отчет, сформированный по вышеуказанным полям.

Рис. 7.5. Предварительный просмотр отчета

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

Модель может содержать четыре типа диаграмм:

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

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

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

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

Работы (Activity) обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников. Все работы должны быть названы и определены. Имя работы должно быть выражено отглагольным существительным, обозначающим действие (например, "Деятельность компании", "Прием заказа" и т.д.). Работа "Деятельность компании" может иметь, например, следующее определение: "Это учебная модель, описывающая деятельность компании". При создании новой модели (меню File/New) автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом (рис. 7.6).

Рис. 7.6. Пример контекстной диаграммы

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

Рис. 7.7. Редактор задания свойств работы

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

на панели инструментов.

Возникает диалог Activity Box Count (рис. 7.8), в котором следует указать нотацию новой диаграммы и количество работ на ней. Остановимся пока на нотации IDEF0 и щелкнем на ОК. Появляется диаграмма декомпозиции (рис. 7.9). Допустимый интервал числа работ — 2-8. Декомпозировать работу на одну работу не имеет смысла: диаграммы с количеством работ более восьми получаются перенасыщенными и плохо читаются. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от трех до шести блоков на одной диаграмме.

Рис. 7.8. Диалог Activity Box Count

Рис. 7.9. Пример диаграммы декомпозиции

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

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

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

Каждая из работ на диаграмме декомпозиции может быть в свою очередь декомпозирована. На диаграмме декомпозиции работы нумеруются автоматически слева направо. Номер работы показывается в правом нижнем углу. В левом верхнем углу изображается небольшая диагональная черта, которая показывает, что данная работа не была декомпозирована. Так, на рис. 7.9 все работы еще не были декомпозированы.

Стрелки(Arrow) описывают взаимодействие работ и представляют собой некую информацию, выраженную существительными.(Например, "Звонки клиентов", "Правила и процедуры", "Бухгалтерская система".). В IDEF0 различают пять типов стрелок:

Вход (Input) — материал или информация, которые используются или преобразуются работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был придуман IDEF0) не возникает проблем определения входов. Действительно, "Звонки клиентов" на рис. 7.6 — это нечто, что перерабатывается в процессе "Деятельность компании" для получения результата. При моделировании ИС, когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при "Приеме пациента" карта пациента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе — "Заполненная карта пациента"). Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может служить информация о том, перерабатываются/изменяются ли данные в работе или нет. Если изменяются, то, скорее всего, это вход, если нет — управление.

Управление (Control) — правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рис. 7.6 стрелка "Правила и процедуры" — управление для работы "Деятельность компании". Управление влияет на работу, но не преобразуется работой. Если цель работы — изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или вход) рекомендуется рисовать стрелку управления.

Выход (Output) — материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. На рис. 7.6 стрелки "Маркетинговые материалы" и "Проданные продукты" являются выходом для работы "Деятельность компании".

Механизм (Mechanism) — ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы. На рис. 7.6 стрелка "Бухгалтерская система" является механизмом для работы "Деятельность компании". По усмотрению аналитика стрелки механизма могут не изображаться в модели.

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

Рис. 7.10. Стрелка вызова, появляющаяся при расщеплении модели

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

Для внесения граничной стрелки входа следует:

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