Консалтинг в области информационных технологий

Введение 1. Консалтинг в области информационных технологий [1] Консалтинг – это деятельность специалиста или целевой фирмы, занимающихся стратегическим планированием проекта, анализом и формализацией требований к информационной системе, созданием системного проекта, иногда – проектированием приложений(т.е. до этапа собственно программирования или настройки каких-то имеющихся комплексных систем управления предприятием, выбор которых и осуществляется на основе системного проекта). Консалтинг предваряет и регламентирует названные этапы; и не входит системная интеграция (бизнес-инжиниринг). Консультантом выполняется два вида работ. 1). Элементарное наведение порядка в организации (улучшение бизнес-процессов – бизнес-консалтинг): бизнес-анализ и реструктуризация (реинжинириг бизнес-процессов, BPR). Исследование деятельности предприятия (изучение функционирования организации). 2). Системный анализ и проектирование (совершенствование бизнес-процессов). Выявление и согласование требований заказчика; проектирование или выбор готовой системы для удовлетворения требований заказчика (инжиниринг бизнес-процессов, BPI). Важным элементом консалтинга – формирование и обучение рабочих групп. Участие рабочих групп в проекте с самого начала, передача им внутрифирменных технологий. По окончании работ рабочие группы способны анализировать и улучшать бизнес-процессы в рамках собственной отдельно взятой организации. Консалтинговые структуры характеризуются следующими пятью позициями: • знания и информация (информационная технология) – главный и единственный продукт (профессиональная информация); • опыт персонала, приобретаемый с годами и десятилетиями при работе над конкретными проектами (прикладные задачи); • наличие методологии выполнения консалтинговых проектов; • независимость; • объективность. Введение 2. Цели и этапы разработки консалтинговых проектов Основными целями разработки консалтинговых проектов являются: • представление деятельности предприятия и принятых в нем технологий в виде иерархии диаграмм, обеспечивающих наглядность и полноту их отображения; • формирование на основании анализа предложений по реорганизации организационно-управленческой структуры; • упорядочивание информационных потоков (в том числе документооборота) внутри предприятия; • выработка рекомендаций по построению рациональных технологий работы подразделений предприятия и его взаимодействию с внешним миром; • анализ требований и проектирование спецификаций корпоративных информационных систем; • рекомендации и предложения по применимости и внедрению существующих систем управления предприятиями (прежде всего классов MRP – manufacturing resource planning и ERP – enterprise resource planning). На рисунке 1 показана структура подхода к разработке консалтинговых проектов. Рассмотрим этапы работ более подробно. 1 этап. Анализ первичных требований и планирование работ. Данный этап предваряет (обосновывает) инициацию работ над проектом. Основными задачами этапа являются: анализ первичных бизнес-требований, предварительная экономическая оценка проекта, построение план-графика выполнения работ, создание и обучение совместной рабочей группы. Этап 2. Проведение обследования деятельности предприятия. В рамках данного этапа осуществляется: • предварительное выявление требований, предъявляемых к будущей системе; • определение оргштатной и топологической структур предприятия; • определение перечня целевых задач (функций) предприятия; • анализ распределения функций по подразделениям и сотрудникам; • определение перечня применяемых на предприятии средств автоматизации. При этом выявляются функциональные деятельности каждого из подразделений предприятия и функциональные взаимодействия между ними, информационные потоки внутри подразделений и между ними, внешние по отношению к предприятию объекты и внешние информационные взаимодействия. В качестве исходной информации при проведении обследования и выполнении дальнейших этапов служат: • данные по оргштатной структуре предприятия; • информация о принятых технологиях деятельности; • стратегические цели и перспективы развития; • результаты интервьюирования сотрудников (от руководителей до исполнителей нижнего звена); • предложения сотрудников по усовершенствованию бизнес-процессов предприятия; • нормативно-справочная документация; • опыт системных аналитиков в части наличия типовых решений. Рисунок 1. Структура подхода Длительность обследования составляет 1-2 недели. По окончании обследования строится и согласуется с заказчиком предварительный вариант функциональной модели предприятия, включающей идентификацию внешних объектов и информационных взаимодействий с ними, а также детализацию до уровня основных деятельностей предприятия и информационных связей между этими деятельностями. Этап 3. Построение моделей деятельности предприятия. На данном этапе осуществляется обработка результатов обследования и построение моделей деятельности предприятия следующих двух видов: • модели «как есть», представляющей собой отображение положения дел предприятии (оргштатная структура, взаимодействия подразделений, принятые технологии, автоматизированные и неавтоматизированные бизнес-процессы и т.д.) на момент обследования и позволяющей понять, что делает и как функционирует данное предприятие с позиций системного анализа, а также на основе автоматической верификации выявить ряд ошибок и узких мест и сформулировать ряд предложений по совершенствованию ситуации; • модели «как должно быть», интегрирующей перспективные предложения руководства и сотрудников предприятия, экспертов и системных аналитиков и позволяющей сформировать видение новых рациональных технологий работы предприятия. Каждая из моделей включает в себя 1) полную структурную функциональную модель деятельности (например, в виде иерархии диаграмм потоков данных с разработанными для всех процессов нижнего уровня подробными их спецификациями на структурированном естественном языке или в виде иерархии SADT-диаграмм); 2) информационную модель (например, в нотации «сущность-связь»); в случае необходимости, событийную (описывающую поведение) модель (с использованием диаграмм переходов состояний). Переход от модели «как есть» к модели «как должно быть» осуществляется следующими двумя способами. 1) Совершенствование технологий на основе оценки их эффективности. При этом критериями оценки являются стоимостные и временные затраты выполнения бизнес-процессов, дублирование и противоречивость выполнения отдельных задач бизнес-процесса, степень загруженности сотрудников (инжиниринг). 2) Радикальное изменение технологий и переосмысление бизнес-процессов (реинжиниринг). Например, улучшить бизнес-процесс проверки недобросовестности клиентов, а не кредитоспособности. Модели «как есть» и «как должно быть» являются а) реализацией начальных этапов разработки системы; б) техническим заданием на последующие этапы; в) самостоятельным отделяемым результатом, который имеет практическое значение, в частности: 1) Модель «как есть» включает в себя существующие неавтоматизированные технологии, работающие на предприятии. Формальный анализ этой модели позволит выявить узкие места в автоматизированных бизнес-процессах (сравнение технологий следует исключить) и предложить рекомендации по их улучшению (не зависимо от того, предполагается автоматизация или нет). 2) Модель позволяет осуществлять автоматизированное и быстрое обучение новых работников конкретному направлению деятельности предприятия (так как модель содержит технологию). 3) Ответ. С помощью модели можно осуществлять предварительное моделирование нового направления деятельности с целью выявления новых потоков данных, взаимодействующих подсистем и бизнес-процессов. Переход от выпуска продукции I сорта к выпуску продукции II сорта. Этап 4. Разработка системного проекта. Этап является первой фазой разработки системы автоматизации (фазой анализа системных требований к системе). Требования заказчика уточняются, формализуются и документируются. На этом этапе определяются: • архитектура системы, ее функции, внешние условия ее функционирования, распределение функций между аппаратной и программной частями; • интерфейсы и распределение функций между человеком и системой; • требования к программным и информационным компонентам системы, необходимые аппаратные ресурсы, требования к базе данных, физические характеристики компонент системы, их интерфейсы; • состав людей и работ, имеющих отношение к системе; • ограничения в процессе разработки (директивные сроки завершения отдельных этапов, имеющиеся ресурсы, организационные процедуры и мероприятия, обеспечивающие защиту информации). Консультант становится экспертом – меняется роль по завершении данного этапа. Системный проект строится на основе модели «как должно быть» и включает функциональную модель будущей системы в соответствии с одним из общеупотребительных стандартов (IDEF0 или IDEF3), информационную модель, например, в соответствии со стандартом IDEF1X, а также техническое задание на создание автоматизированной системы (ГОСТ 34.602-89). Системный проект позволяет улучшить качество разрабатываемой системы, а именно: создать оптимальную структуру интегрированной базы данных, выполнить функциональную декомпозицию типовых модулей. Этап 5. Разработка предложений по автоматизации предприятия На основании системного проекта осуществляется: • составление перечня автоматизированных рабочих мест предприятия и способов взаимодействия между ними; • анализ применимости существующих систем управления предприятиями для решения требуемых задач и формирование рекомендаций по выбору такой системы; • совместное с заказчиком принятие решения о выборе конкретной системы управления предприятием или разработке собственной системы; • разработка требований к техническим средствам; • разработка требований к программным средствам; • разработка предложений по этапам и срокам автоматизации. Этап 6. Разработка технического проекта На данном этапе на основе системного проекта и принятых решений по автоматизации осуществляется проектирование системы. Фактически здесь дается ответ на вопрос: «Как (каким образом) мы будем строить систему, чтобы она удовлетворяла предъявленным к ней требованиям?». Этот этап разделяется на два этапа: • проектирование архитектуры системы, включающее разработку структуры и интерфейсов ее компонент (автоматизированных рабочих мест), согласование функций и технических требований к компонентам, определение информационных потоков между основными компонентами, связей между ними и внешними объектами; • детальное проектирование, включающее разработку спецификаций каждой компоненты, разработку требований к тестам и плана интеграции компонент, а также построение моделей иерархии программных модулей и межмодульных взаимодействий и проектирование внутренней структуры модулей. При этом происходит расширение системного проекта: • за счет его уточнения; • за счет построения моделей автоматизированных рабочих мест, включающих подсхемы информационной модели и функциональные модели, ориентированные на эти подсхемы вплоть до идентификации конкретных сущностей информационной модели; • за счет построения моделей межмодульных и внутримодульных взаимодействий с использованием техники структурных карт. Этап 7. Последующие этапы В случае разработки собственной системы последующие этапы являются традиционными: по спецификациям технического проекта осуществляется программирование модулей, их тестирование и отладка и последующая комплексация в автоматизированные рабочие места и в систему в целом. При этом схема интегрированной базы данных, как правило генерируется автоматически на основании информационной модели. Настройка существующей системы MRP и ERP осуществляется по следующим этапам: • наполнение системы фактическими данными; • построение процедур их обработки; • интеграция процедур внутри автоматизированных рабочих мест; • интеграция автоматизированных рабочих мест в систему. Введение 3. CASE-технологии - методологическая и инструментальная база консалтинга Новым направлением в программотехнике (60-70-х годов) - CASE (Computer-Aided Software/System Engineering). CASE–технология представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения (ПО), поддержанную комплексом взаимоувязанных средств автоматизации. CASE – это инструментарий для системных аналитиков, разработчиков и программистов (узкие специалисты; профессия), заменяющий им бумагу и карандаш на компьютер (сложность понимания, большая трудоемкость и стоимость использования, трудности внесения изменений в проектные спецификации и т.д.) для автоматизации процесса проектирования и разработки ПО. Основными покупателями CASE-пакетов за рубежом являются военные организации, центры обработки данных и коммерческие фирмы по разработке ПО. Известная методология структурного системного анализа SADT (точнее её подмножество IDEF0) принята в качестве стандарта на разработку ПО Министерством обороны США. Диаграмма SADT применяется менеджерами и руководителями компьютерных фирм для обсуждения любых вопросов (постановка задачи). CASE позволяет не только создавать «правильные» (профессиональные) продукты, но и обеспечивать «правильный» (профессиональный) процесс их создания. Основная цель CASE состоит в том, чтобы отделить проектирование ПО от кодирования и последующих этапов разработки, а также скрыть от разработчиков все детали среды разработки и функционирования ПО, чем больше деятельности будет вынесено в проектирование из кодирования, тем лучше. При использовании CASE-технологий изменяются все этапы жизненного цикла программной системы, при этом наибольшие изменения касаются этапов анализа и проектирования. В большинстве современных CASE-систем применяются методологии структурного анализа и проектирования, основанные на наглядных диаграммных техниках, при этом для описания модели проектируемой системы используются графы, диаграммы, таблицы и схемы. Такие методологии обеспечивают строгое и наглядное описание проектируемой системы, которое начинается с ее общего обзора и затем детализируется, приобретая иерархическую структуру со все большим числом уровней. CASE-технологии успешно применяются для моделирования практически всех предметных областей, однако устойчивое положение они занимают в следующих областях: • бизнес-анализ (модели деятельности предприятий «как есть» и «как должно быть» строятся с применением методов структурного системного анализа и поддерживающих их CASE-средств); • системный анализ и проектирование (применяются CASE-технологии на этапах анализа и проектирования для повышения эффективности разработки программной системы). Правильное определение. Одним из ключевых признаков классификации программного продукта как CASE-средство является поддержка методологий структурного системного анализа и проектирования; возможность применения современных методов системной и программной инженерии. Иными слова, CASE-технологии не могут считаться самостоятельными методологиями, они только развивают структурные методологии и делают более эффективным их применение за счет автоматизации. Достоинства CASE: • улучшают качество создаваемого ПО за счет средств автоматического контроля (например, для контроля проекта); • позволяют за короткое время создавать прототип будущей системы, что позволяет на ранних этапах оценить ожидаемый результат; • ускоряют процесс проектирования и разработки; • освобождают разработчика от рутинной работы, позволяя ему целиком сосредоточиться на творческой части разработки; • поддерживают развитие и сопровождение разработки; • поддерживают технологии повторного использования компонент разработки. ГЛАВА 1. МЕТОДЫ И СРЕДСТВА СТРУКТУРНОГО СИСТЕМНОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ Этап «Анализ требований». Этап «Проектирование». Принципы структурного анализа №1 №10 Средства структурного анализа для целей моделирования систем и в том числе для структурного анализа в частности, используются три группы средств, иллюстрирующих: • функции, которые система должна выполнять; • отношения между данными; • зависящее от времени поведение системы (аспекты реального времени). В методологиях системного анализа в качестве средств наиболее эффективными являются: • DFD (Data Flow Diagrams) – диаграммы потоков данных, словари данных, спецификации процессов или миниспецификации; • ERD (Entity-Relationship Diagrams) – диаграммы «сущность-связь»; • STD (State Transition Diagrams) – диаграммы переходов состояний. DFD показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицирует хранилища (накопители) данных, к которым осуществляется доступ. Структуры потоков данных и определения их компонент хранятся и анализируются в словаре данных. Каждая логическая функция (процесс) может быть детализирована м помощью DFD нижнего уровня; когда дальнейшая детализация перестает быть полезной, переходят к выражению логии функции при помощи спецификации процесса (миниспецификации). Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью ERD. В случае наличия реального времени DFD описания зависящего от времени поведения системы, раскрывающимися с помощью SDT (рис. 2). Перечисленные средства дают полное описание системы независимо от того, является ли она существующей или разрабатываемой с нуля. Таким образом строится логическая функциональная спецификация – подробное описание того, что должна делать система, освобожденное насколько это возможно от рассмотрения путей реализации. Рисунок 2. Компоненты логической модели Глава 2. Диаграммы потоков данных Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. Для изображения DFD традиционно используются две различные нотации: Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Рассмотрим нотацию Йодана (в основных примерах). Глава 1.1 Основные символы нотаций Йодана и Гейна-Сарсона Основные символы DFD изображены в таблице 1. Опишем их назначение. На диаграммах функциональные требования представляются с помощью процессов и хранилищ, связанных потоками данных. Таблица 1 Основные символы диаграммы потоков данных компонента нотация Йодана нотация Гейна-Сарсона поток данных процесс хранилище внешняя сущность ПОТОКИ ДАННЫХ являются важными механизмами, использующимися для моделирования передачи информации (или даже физических компонент) из одной части системы в другую. Потоки на диаграммах обычно изображаются именованными стрелками, ориентация которых указывает направление движения информации. Иногда информация может двигаться в одном направлении, обрабатываться и возвращаться назад в ее источник. Такая ситуация может моделироваться либо двумя различными потоками, либо одним – двунаправленным. ПРОЦЕСС состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Это имя должно содержать глагол (КОМАНДУ) в неопределенной форме с последующим дополнением (например, «вычислить максимальную высоту»). Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. ХРАНИЛИЩЕ (НАКОПИТЕЛЬ) ДАННЫХ позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет «срезы» потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, когда поток данных входит или выходит в/из хранилища, и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме. ВНЕШНЯЯ СУЩНОСТЬ (или ТЕРМИНАТОР) представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное, например, СКЛАД ТОВАРОВ. Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке. Глава 1.2. Контекстная диаграмма и детализация процессов Декомпозиция DFD осуществляется на основе процессов: каждый процесс может раскрываться с помощью DFD нижнего уровня. Важную специфическую роль (модель системы - «черный ящик») в модели играет специальный вид DFD – контекстная диаграмма, моделирующая систему наиболее общим образом. Контекстная диаграмма отражает интерфейс системы с внешним миром, а именно, информационные потоки между системой и внешними сущностями, с которыми она должна быть связана. Она идентифицирует эти внешние сущности, а также, как правило, единственный процесс, отражающий главную цель или природу системы насколько это возможно. Контекстная диаграмма устанавливает границы анализируемой системы. Правило 1. Каждый проект должен иметь ровно одну контекстную диаграмму, при этом нет необходимости в нумерации единственного ее процесса. DFD первого уровня строится как декомпозиция процесса, который присутствует на контекстной диаграмме (см. правило 1; слияние моделей должно выполняться на первом уровне декомпозиции). Построенная диаграмма первого уровня также имеет множество процессов, которые в свою очередь могут быть декомпозированы в DFD нижнего уровня. Таким образом строится иерархия DFD с контекстной диаграммой в корне дерева. Этот процесс декомпозиции продолжается до тех пор, пока процессы могут быть эффективно описаны с помощью коротких (до одной страницы) миниспецификаций обработки (спецификаций процессов). При таком построении иерархии DFD каждый процесс более низкого уровня необходимо соотнести с процессом верхнего уровня. Обычно для этой цели используются структурированные номера процессов. Так, например, если детализируем процесс номер 2 на диаграмме первого уровня, раскрывая его с помощью DFD, содержащий три процесса, то их номера будут иметь следующий вид: 2.1, 2.2 и 2.3. При необходимости можно перейти на следующий уровень, т.е. для процесса 2.2 получим 221, 222 и т.д. Глава 1.3. Декомпозиция данных и соответствующие расширения диаграмм потоков данных Индивидуальные данные в системе часто являются независимыми. Однако иногда необходимо иметь дело с несколькими независимыми данными одновременно (переменные типа класса). Например, в системе имеются потоки ЯБЛОКИ, АПЕЛЬСИНЫ и ГРУШИ. Эти потоки могут быть сгруппированы с помощью введения нового потока ФРУКТЫ как состоящий из нескольких элементов-потоков. такое определение задается с помощью формы Бэкуса-Наура (БНФ) в словаре данных (см. главу 3). В свою очередь поток ФРУКТЫ сам может содержаться в потоке-предке (переменные типа класса меняют качественные свойства) ЕДА (поле_1) вместе с потоками ОВОЩИ (свойство_1), МЯСО (свойство_2) и др. Запрос_1: «Какие ФРУКТЫ являются МЯСОМ?». Запрос_2 (альтернативный): «Какие ФРУКТЫ подаются к (или готовятся с) МЯСУ (или МЯСОМ)?». Время: «когда менять повара?». Например, когда меняем ОВОЩИ на МЯСО, тогда меняем РЕЦЕПТ и ПОВАРА. На выходе модели образуется поток АРБУЗ (ЯГОДА, свойство_3; растет (рождается) на ЗЕМЛЕ, поле_2) или ВИШНЯ (ЯГОДА, свойство_3; растет (рождается) на ДЕРЕВЕ, поле_2). Новый поток какой? Например, сервирование стола (МЕСТО). Определение. Такие потоки, объединяющие несколько потоков, получили название групповых. Обратная операция, расщепление потоков на подпотоки, осуществляется с использованием группового узла (табл. 2), позволяющего расщепить поток на любое число подпотоков. При расщеплении также необходимо формально определить подпотоки в словаре данных (с помощью БНФ). Аналогичным образом осуществляется и декомпозиция потоков через границы диаграмм, позволяющая упростить детализирующую DFD. Пусть имеется поток ФРУКТЫ, входящий в детализируемый процесс. На детализирующей этот процесс диаграмме потока ФРУКТЫ может не быть вовсе, но вместо него могут быть потоки ЯБЛОКИ и АПЕЛЬСИНЫ (потоки переданы из детализируемого процесса (верхнего или нижнего уровня), определяемого соответственно при расщеплении или соединении моделей). В этом случае должно существовать БНФ-определение потока ФРУКТЫ, состоящего из подпотока ЯБЛОКИ и АПЕЛЬСИНЫ, для целей балансирования (стратегическая диаграмма ERD, содержащая описание сущностей (индексов), но не источников данных – «внешних сущностей»). Применение этих операций над данными позволяет обеспечить структуризацию данных, увеличивает наглядность и читабельность диаграмм. Таблица 2 Расширения диаграммы потоков данных название расширения - узла нотация Йодана групповой узел узел-предок неиспользуемый узел узел изменения имени Для обеспечения декомпозиции данных и некоторых других сервисных возможностей к DFD добавляются следующие типы объектов (табл. 2): 1) ГРУППОВОЙ УЗЕЛ. Предназначен для расщепления и объединения потоков. В некоторых случаях может отсутствовать (т.е. фактически вырождаться в точку соединения/расщепления потоков на диаграмме). 2) УЗЕЛ-ПРЕДОК. Позволяет увязывать входящие и выходящие потоки между детализируемым процессом и детализирующей DFD. 3) НЕИСПОЛЬЗУЕМЫЙ УЗЕЛ. Применяется в ситуации, когда декомпозиция данных производится в групповом узле, при этом требуются не все элементы входящего в узел потока. 4) УЗЕЛ ИЗМЕНЕНИЯ ИМЕНИ. Позволяет неоднозначно именовать потоки, при этом их содержимое эквивалентно. Например, если при проектировании разных частей системы один и тот же фрагмент данных получил различные имена, то эквивалентность соответствующих потоков данных обеспечивается узлом изменения имени. При этом один из потоков данных является входным для данного узла, а другой – выходным. 5) Текст в свободном формате в любом месте программы. Глава 1.4. Построение модели Главная цель построения иерархического множества DFD заключается в том, чтобы сделать требования ясными и понятными на каждом уровне детализации, а также разбить эти требования на части с точно определенными отношениями между ними. Для достижения этого целесообразно пользоваться следующими рекомендациями: 1) размещать на каждой диаграмме от 3 до 6-7 процессов; 2) не загромождать диаграммы несущественными на данном уровне деталями; 3) декомпозицию потоков данных (DFD) осуществлять параллельно с декомпозицией процессов (IDEF3); эти две работы должны выполняться одновременно, а не одна после завершения другой; 4) выбирать ясные, отражающие суть дела, имена процессов и потоков для улучшения понимаемости диаграмм, при этом стараться не использовать аббревиатуры; 5) однократно определять функционально идентичные процессы на самом верхнем уровне, где такой процесс необходим, и ссылаться к нему на нижних уровнях; 6) диаграммы IDEF0 реализуют последовательный граф (в случае отмены транзакции – выходной поток переходит на уровень детализирующего процесса) или граф ожиданий (стрелка вызова модуля - Call); диаграммы IDEF3 рекомендуется применять для описания более сложных объектов; 7) . отделять управляющие структуры от обрабатывающих структур (т.е. процессов), локализовать управляющие структуры; на диаграммах DFD отсутствуют управляющие потоки (но есть события, проходящие во времени). В соответствии с этими рекомендациями процесс построения модели разбивается на следующие этапы (только 1-10): 1) Расчленение множества требований и организация их в основные функциональные группы. 2) Идентификация внешних объектов (источников), с которыми система должна быть связана. 3) Идентификация основных видов информации (ИНДЕКСирование потоков; множественные запросы (multiset, портфель) – неупорядоченная коллекция, в которой допускается наличие дубликатов; на следующих этапах изменять индекс нельзя – см. «узел изменения имени» и п.11). 4) Предварительная разработка контекстной диаграммы, на которой основные функциональные группы представляются процессами, внешние объекты – внешними сущностями, основные виды информации – потоками данных между процессами и внешними сущностями. 5) Изучение предварительной контекстной диаграммы и внесение в нее изменений по результатам ответов на возникающие при этом изучении вопросы по всем ее частям. 6) Построение контекстной диаграммы путем объединения всех процессов предварительной диаграммы в один процесс, а также группирования потоков. 7) Формирование DFD первого уровня на базе процессов предварительной контекстной диаграммы. 8) Проверка основных требований по DFD первого уровня. 9) Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса (стратегическая ERD диаграмма). 10) Проверка основных требований по DFD соответствующего уровня. 11) Добавление определений новых потоков в словарь данных при каждом их появлении на диаграммах (признак неправильной постановки задачи). 12) Параллельное (с процессом декомпозиции) изучение требований (в том числе и вновь поступающих), разбиение их на элементарные и идентификация процессов или спецификаций процессов, соответствующих этим требованиям. 13) После построения двух-трех уровней проведения ревизии с целью проверки корректности и улучшения понимаемости модели. 14) Построение спецификации процесса (а не простейшей диаграммы) в случае, если некоторую функцию сложно или невозможно выразить комбинацией процессов. Пример 1. «банковская система». Рисунок 3. Контекстная диаграмма банковской задачи (нотация Йордана) Рисунок 4. Детализация процесса "Обслужить" Процесс 1.3 может быть детализирован с помощью DFD второго уровня (рис. 5). Рисунок 5. Детализация процесса "Обработать запрос на обслуживание" Глава 1.5. Расширения реального времени Расширения реального времени используются для дополнения модели функционирования данных (иерархии DFD) средствами описания управляющих аспектов в системах реального времени. Для этих целей применяются следующие символы (табл. 3). Таблица 3 Расширения реального времени компонента нотация Йодана нотация Гейна-Сарсона управляющий поток управляющий процесс управляющее хранилище 1) УПРАВЛЯЮЩИЙ ПРОЦЕСС. Представляет собой интерфейс между DFD и спецификациями управления, собственно моделирующими и документирующими аспекты реального времени. Его имя указывает на тип управляющей деятельности, вырабатываемой спецификацией. Фактически управляющий процесс представляет собой преобразователь входных управляющих потоков в выходные управляющие потоки; при этом точное описание этого преобразования должно задаваться в спецификации управления. 2) УПРАВЛЯЮЩЕЕ ХРАНИЛИЩЕ. Представляет «срез» управляющего потока во времени. Содержащаяся в нем управляющая информация может использоваться в любое время после ее занесения в хранилище, при этом соответствующие данные могут быть использованы в произвольном порядке. Имя управляющего хранилища должно идентифицировать его содержимое и быть существительным. Управляющее хранилище отличается от традиционного тем, что может содержать только управляющие потоки; все другие их характеристики идентичны. 3) Управляющий поток. Это сигнал (управляющая информация), представляющий состояние или вид операции (точность вычисления; случайный процесс для входного или выходного потоков). Его имя не должно содержать глаголов, а только существительные и прилагательные. Обычно управляющий поток имеет дискретное (распределение для случайного процесса; агрегированный сигнал), а не непрерывное значение. Логически управляющий процесс есть некий командный пункт, реагирующий на изменения внешних условий, передаваемые ему с помощью управляющих потоков, и продуцирующий в соответствии со своей внутренней логикой выполняемые процессами команды. При этом режим выполнения процесса зависит от типа управляющего потока. Имеются следующие типы управляющих потоков: a) T-поток (trigger flow). Является поток управления процессом, который может вызывать выполнение процесса. При этом процесс как бы включается одной короткой операцией. Это – аналог выключателя света, единственным нажатием которого «запускается» процесс горения лампы. b) A-поток (activator flow). Является потоком управления процессом, который может изменять выполнение отдельного процесса. Используется для обеспечения непрерывности выполнения процесса до тех пор, пока поток «включен» (т.е. течет непрерывно), с «выключением» потока выполнение процесса завершается. Это – аналог переключателя лампы, которая может быть как включена, так и выключена. c) E/D-поток (enable/disable flow). Является потоком управления процессом, который может переключать выполнение отдельного процесса. Течение по E-линии вызывает выполнение процесса, которое продолжается до тех пор, пока не возбуждается течение по D-линии. Это – аналог выключателя с двумя кнопками: одной – для включения света, другой – для его выключения. Отметим, что можно использовать 3 типа таких потоков: E-поток, D-поток, E/D-поток. Иногда возникает необходимость в представлении одного и того же фрагмента данных потоками различных типов. Например, поток данных «Скорость машины» в отдельных случаях может использоваться как управляющий для контроля критического значения. Для обеспечения этого используется УЗЕЛ ИЗМЕНЕНИЯ ТИПА (рис. 6): поток данных является входным для этого узла, а управляющий поток – выходным. Рисунок 6. Узел изменения типа Дополним модель предложенной в примере 1 «банковская система», введя в диаграммы управляющий процесс и управляющие потоки, позволяющие описать ее функционирование в реальном времени. После такого расширения DFD будут иметь вид. Управляющий процесс 1.5 («управление обслуживанием»), получив информацию о том, что кредитная карта введена (поток «введенная кредитная карта»), вызывает выполнение процесса 1.1 (поток A: «получить пароль»). Получив информацию о введенном пароле (поток «корректный пароль»), процесс 1.5 информирует процесс 1.4 о необходимости удаления кредитной карты (поток: «удаленная кредитная карта») и с помощью потока T: «обеспечить требуемое обслуживание» вызывает выполнение процесса 1.2, затем процесса 1.3 (поток «требуемое обслуживание»). Рисунок 7. Расширение диаграммы, детализирующей контекстный процесс Управляющий поток «требуемое обслуживание» на детализирующей процесс 1.3 диаграмме расчленяется на 4 подпотока, каждый из которых вызывает выполнение процессов 1.3.1 – 1.3.4 соответственно. Рисунок 8 Расширение диаграммы, детализирующей процесс 1.3 Примечание. На DFD отсутствуют управляющие потоки, но есть управляющие структуры (процессы) и обрабатывающие процессы (события) (источник 1, стр. 34). Глава 4. Методологии структурного системного анализа и проектирования (лекция №2) Глава 4.1. Классификация структурных методологий Методология структурного анализа и проектирования ПО определяет руководящие указания для оценки и выбора проекта разрабатываемого ПО, шаги работы, которые должны быть выполнены, их последовательность, правила распределения и назначения операций и методов. Наиболее распространены следующие методологии структурного анализа и проектирования: • методология SADT (Structured Analysis and Design Technique); • структурный системный анализ Гейна-Сарсона (Gane-Sarson); • структурный анализ и проектирование Йодана/Де Марко (Yourdon/DeMarko); • развитие систем Джексона (Jackson); • развитие структурных систем Варнье-Орра (Warnier-Orr); • анализа и проектирования систем реального времени Уорда-Меллора (Ward-Mellor) и Хатли (Hatley); • информационное моделирование Мартина (Martin). Используемые методы и диаграммные техники большинства методологий можно сгруппировать следующим образом: • диаграммы потоков данных в нотации Йодана/Де Марко или Гейна-Сарсона, обеспечивающие анализ требований и функциональное проектирование информационных систем; • расширения Хатли и Уорда-Меллора для проектирования систем реального времени, основанные на диаграммах переходов состояний, таблицах и деревьях решений, картах и схемах потоков управления; • диаграммы «сущность-связь» (в нотации Чена или Баркера) или скобочные диаграммы Варнье-Орра для проектирования структур данных, схем БД, форматов файлов как части всего проекта; • структурные карты Джексона и/или Константайна для проектирования межмодульных взаимодействий и внутренней структуры модулей, позволяющие развить модель анализа, построенную на базе вышеперечисленных средств, до модели реализации. Современные структурные методологии анализа и проектирования классифицируются по следующим признакам: • по отношению к школам – Software Engineering (SE) и Information Engineering (IE); • по порядку построения модели – процедурно-ориентированные, ориентированные на данные и информационно-ориентированные; • по типу целевых систем – для систем реального времени (CPB) и для информационные систем (ИС). SE является нисходящим поэтапным подходом к разработке ПО, начинающейся с общего взгляда на его функционирование. Затем производится декомпозиция на подфункции, и процесс повторяется для подфункций до тех пор, пока они не станут достаточно малы для их реализации кодированием. В результате образуется иерархическая, структурированная, модульная программа. SE является универсальной дисциплиной разработки ПО, успешно применяющейся как при разработке систем реального времени, так и при разработке информационных систем. IE более новая дисциплина. С одной стороны, она имеет более широкую область применения, чем SE: IE является дисциплиной построение систем вообще, а не только систем ПО, и включает этапы более высокого уровня (например, стратегическое планирование), однако на этапе проектирования систем ПО эти дисциплины аналогичны. С другой стороны, IE – более узкая дисциплина, чем SE, т.к. IE используется только для построения информационных систем, а SE – для всех типов систем. Разработка ПО основана на модели ВХОД-ОБРАБОТКА-ВЫХОД: данные входят в систему (спецификация процесса; процесс; поток данных), обрабатываются (STD; управляющий процесс) или преобразуются (словарь данных; поток данных; хранилище) и выходят из системы (ERD). Такая модель используется во всех структурных методологиях. При этом важен порядок построения модели. 1). Традиционный процедурно-ориентированный подход регламентирует первичность проектирования функциональных компонент по отношению к проектированию структур данных: требования к данным раскрываются через функциональные требования. 2). При подходе, ориентированном на данные, вход и выход являются наиболее важными – структуры данных определяются первыми, а процедурные компоненты являются производными от данных. 3). Информационно-ориентированный подход, как часть IE-дисциплины, отличается от подхода, ориентированного на данные, тем, что позволяет работать с неиерархическими структурами данных. Основная особенность систем реального времени заключается в том, что они контролируют и контролируются внешними событиями; реагирование на эти события во времени – основная и первоочередная функция таких систем. Главными отличиями информационных систем (ИС) и систем реального времени (СРВ) являются структурные методологии и средства поддержки этих особенностей. Таблица 4 Отличия ИС и СРВ Информационные системы Системы реального времени Управляемы данными Управляемы событиями Сложные структуры данных Простые структуры данных Большой объем входных данных Малое количество входных данных Интенсивный ввод/вывод Интенсивные вычисления Машинная независимость Машинная зависимость Для проектирования систем реального времени используются специальные типы структурных диаграмм: диаграммы потоков управления, диаграммы переходов состояний, контекстные графы, матрицы состояний/событий, таблицы решений и др. Таблица 5 Классификация методологий по признакам (данные по частоте использования получены на основе анализа информации по 127 CASE-пакетам) Название Частота использования, % Школа Порядок построения Тип целевых систем Йодан-Де Марко 36,5 SE процедурно-ориентированная ИС, СРВ Гейн-Сарсон 20,2 SE процедурно-ориентированная ИС, СРВ Констан-тайн 10,6 SE процедурно-ориентированная ИС, СРВ Джексон 7,7 SE ориентированная на данные ИС, СРВ Варнье-Орр 5,8 SE ориентированная на данные ИС Мартин 22,1 IE информационно-ориентированная ИС SADT 3,3 IE варианты использования: 1) процедурно-ориентированная; 2) ориентированная на данные ИС Stradis 1,9 IE процедурно-ориентированная ИС Методологии проектирования систем реального времени Хатли и Уорда-Меллора могут использоваться при проектировании информационных систем в виде диаграммных техник для расширения структурных диаграмм. Таблица 6 Методологии анализа и проектирования Название Процедуры Данные 1. Средства анализа - диаграммы потоков данных (DFD, SSADM (IDEF3) и др.) стр. 111-113. + - диаграммы потоков управления + - таблицы, деревья решений + - матрицы + + - диаграммы зависимости + - диаграммы декомпозиции + - SADT (IDEF0)-диаграммы + + 2. Средства проектирования - структурные карты + - диаграммы деятельности + - диаграммы Варнье-Орра + + - диаграммы переходов состояний + - языки проектирования спецификаций + - блок-схемы + - схемы экранов + - диаграммы «сущность-связь» + Глава 4.2.1. Методологии структурного анализа Йодана/Де Марко и Гейна-Сарсона Структурный анализ – это систематический пошаговый подход к анализу требований и проектированию спецификаций системы независимо от того, является ли она существующей или создается вновь. Методологии Гейна-Сарсона и Йодана/Де Марко, основанные на идее нисходящей иерархической организации, наиболее ярко демонстрируют этот подход. Целью рассматриваемых методологий является преобразование общих, неясных знаний о требованиях к системе в точные (насколько это возможно) определения. Обе методологии фокусируют внимание на потоках данных, их главное назначение - создание базированных на графике документов по функциональным требованиям. Методологии поддерживаются традиционными нисходящими методами проектирования спецификаций и обеспечивают один из лучших способов связи между аналитиками, разработчиками и пользователями системы за счет интеграции множества следующих средств: 1) DFD – диаграммы потоков данных. являются графическими иерархическими спецификациями, описывающими систему с позиций потоков данных. В состав DFD могут входить четыре графических символа, представляющих потоки данных (1-й символ), процессы преобразования входных потоков данных в выходные (2-й символ), внешние источники (3-й символ) и получатели данных, а также файлы и БД (4-й символ), требуемые процессами для своих операций. 2) Словари данных. Являются каталогами всех элементов данных, присутствующих в DFD, включая групповые и индивидуальные потоки данных, хранилища и процессы, а также все их атрибуты. 3) Миниспецификации обработки, описывающие DFD-процессы нижнего уровня и являющиеся базой для кодогенерации. Фактически миниспецификации представляют собой алгоритмы описания задач, выполняемых процессами: множество всех миниспецификаций является полной спецификацией системы. Миниспецификации содержат номер и/или имя процесса, списки входных и выходных данных и тело (описание) процесса, собственно и являющееся спецификацией алгоритма или операции, трансформирующей входные потоки данных в выходные. Известно большое число разнообразных методов, позволяющих задать тело процесса, соответствующий язык может варьироваться от структурированного естественного языка или псевдокода до визуальных языков проектирования (типа FLOW-форм и диаграмм Насси-Шнейдермана) и формальных компьютерных языков. DFD-диаграммы являются ключевой частью документа спецификации требований. Каждый узел – процесс в DFD может развертываться в диаграмму нижнего уровня, что позволяет на любом уровне абстрагироваться от деталей (отметим, что структурные методологии, ориентированные на потоки управления, не обладают этим свойством). Проектные спецификации строятся по DFD и их спецификациям автоматически. Наиболее часто для описания проектных спецификаций используется методика структурных карт Джексона, иллюстрирующая иерархию модулей, связи между ними и некоторую информацию об их исполнении (последовательность вызовов, итерацию). Существует ряд методов автоматического преобразования DFD в структурные карты, например, алгоритм Фишера [Fisher 1988]. DFD моделируют функции, которые система должна выполнять, но ничего не сообщают об отношениях между данными, а также о поведении системы в зависимости от времени – для этих целей методологии используют диаграммы «сущность-связь» и диаграммы переходов состояний, соответственно. Главной отличительной чертой методологии Гейна-Сарсона является наличие этапа моделирования данных, определяющего содержимое хранилищ данных (БД и файлов) в DFD в Третьей Нормальной форме. Этот этап включает построение списка элементов данных, располагающихся в хранилищах данных; анализ отношений между данными и построение соответствующей диаграммы связей между элементами данных; представление всей информации по модели в виде связанных нормализованных таблиц. Кроме того, методологии отличаются чисто синтаксическими аспектами, так, например, различны графические символы, представляющие компоненты DFD. Таким образом, рассмотренные методы в подходах помогают перейти к хорошо организованной модели системы. В основе используется концепция нисходящего поэтапного разбиения функций системы на подфункции. На первом этапе формируется контекстная диаграмма верхнего уровня, идентифицирующая границы системы и определяющая интерфейсы между системой и окружением. Затем, после интервьюирования эксперта предметной области, формируется список внешних событий, на которые система должна реагировать. Для каждого из таких событий строится пустой процесс в предположении, что его функция обеспечивает требуемую реакцию на это событие, которая в большинстве случаев включает генерацию выходных потоков и событий (но может также включать и занесение информации в хранилище данных для ее использования другими событиями и процессами). На следующем уровне детализации аналогичная деятельность осуществляется для каждого из пустых процессов. Рассмотрим пример (рис. 9). Показан верхний уровень функциональной модели компании, занимающейся распределением товаров по заказам. Заказы подвергаются входному контролю и сортировке. Если заказ не аннулирован, то определяется, имеется ли на складе соответствующий товар. В случае положительного ответа выписывается счет к оплате и предъявляется заказчику, при поступлении платежа товар отправляется заказчику. Если заказ не обеспечен складскими запасами, то отправляется заявка на товар производителю. После поступления требуемого товара на склад компании заказ становится обеспеченным и повторяет вышеописанный маршрут. При построении данной модели использована нотация Гейна-Сарсона. Рисунок 9. Пример 1 - диаграмма Гейна-Сарсона Глава 4.2.2. SADT-технология структурного анализа и проектирования SADT (Structured Analysis and Design Technique) – методология анализа и проектирования систем, введенная в 1973 г. Россом (Ross). SADT используется для решения следующих задач: программное обеспечение телефонных сетей, системная поддержка и диагностика, долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, конфигурация компьютерных систем, обучение персонала, встроенное ПО для оборонных систем, управление финансами и материально-техническая поддержка и др. С точки зрения SADT модель может основываться либо на функциях системы, либо на ее предметах (планах, данных, оборудовании, информации и т.д.). Такие модели принято называть активностными моделями и моделями данных соответственно. Активностная модель представляет с нужной степенью подробности систему активностей, которые в свою очередь отражают свои взаимоотношения через предметы системы. Модели данных дуальны к активностным моделям и представляют собой подробное описание предметов системы, связанных системными активностями. Полная методология SADT заключается в построении моделей обеих типов для более точного описания сложной системы. Методология SADT [2, стр. 84-94] содержит графический язык функционального моделирования систем – IDEF0 (Integration Definition for Function Modeling; 0). Основным рабочим элементом при моделировании является диаграмма. Модель SADT объединяет и организует диаграммы в иерархические древовидные структуры, при этом чем выше уровень диаграммы, тем она менее детализирована. В состав диаграммы входят блоки, изображающие активности моделируемой системы, и дуги, связывающие блоки вместе и изображающие взаимодействия и взаимосвязи между блоками. SADT требует, чтобы в диаграмме было 3 - 6 блоков: в этих пределах диаграммы и модели удобны для чтения, понимания и использования. Вместо одной громоздкой модели используются несколько небольших взаимосвязанных моделей, значения которых взаимодополняют друг друга, делая понятной структуризацию сложного объекта. Если присутствует ситуация равноправной деятельности в структурах, тогда SADT для ряда предметных областей допускает на одной диаграмме отобразить 15-20 блоков. Диаграммы SADT являются предписывающими диаграммами, описывающими как преобразования между ВХОДОМ и ВЫХОДОМ, так и предписывающие правила этих преобразований. Рисунок 10. Диаграмма IDEF0 (контекстный уровень) Блоки на диаграммах изображаются прямоугольниками и сопровождаются текстами на естественном языке, описывающими активности. В отличие от других методов структурного анализа в SADT каждая сторона имеет определенное назначение: левая сторона блока предназначена для Входов; верхняя – для Управления; правая – для Выходов; нижняя – для Исполнителей (порядок заполнения диаграммы SADT). Такое обозначение отражает определенные принципы активности: Входы преобразуются в Выходы; Управления ограничивают или предписывают условия выполнения; Исполнители описывают, за счет чего выполняются преобразования. Дуги в SADT представляют наборы предметов и маркируются (реализуется механизм транзакций) текстами на естественном языке. Предметы могут состоять с активностями в четырех возможных отношениях: Вход, Выход, Управление, Исполнитель. Каждое из этих отношений изображается дугой, связанной с определенной стороной блока – таким образом стороны блока чисто графически сортируют предметы, изображаемые блоками. Входные дуги изображают предметы, используемые и преобразуемые активностями. Управляющие дуги обычно изображают информацию, управляющую действиями активностей. Выходные дуги изображают предметы, в которые преобразуются входы. Исполнительские дуги отражают (по крайней мере частично) реализацию (алгоритм) активностей (рис. 11). Рисунок 11. Пример 2 - IDEF0-диаграммы (контекстный уровень) Блоки на диаграммах размещаются по «ступенчатой» схеме в соответствии с их доминированием, которое понимается как влияние, оказываемое одним блоком на другие. Кроме того, блоки должны быть пронумерованы, например, с их доминированием. Номера блоков служат однозначными идентификаторами для активностей и автоматически организуют эти активности в иерархию модели. Взаимовлияние блоков может выражаться либо в пересылке Выхода к другой активности для дальнейшего преобразования, либо в выработке управляющей информации, предписывающей, что именно должна делать другая активность. В SADT требуются только пять типов взаимосвязей между блоками для описания их отношений (рис. 12): • Управление (Выход_A1-Управление_A2); • Вход (Выход_A1-Вход_A2); • Управленческая Обратная Связь (Выход_A2-Управление_A1); • Входная Обратная Связь (Выход_A2-Вход_A1); • Выход – Исполнитель (A1_A2). Отношения Управления и Входа являются простейшими, так как отражают прямые воздействия. Отношение Управления возникает тогда, когда Выход одного блока непосредственно влияет на блок с меньшим доминированием. Отношение Входа возникает, когда Выход одного блока становится Входом для блока с меньшим доминированием. Обратные связи более сложны и отражают итерацию или рекурсию – Выходы из одной активности влияют на будущее выполнение других функций, что впоследствии влияет на исходную активность. Управленческая Обратная Связь возникает, когда Выход некоторого блока влияет на блок с большим доминированием, а отношение Входной Обратной Связи имеет место, когда Выход одного блока становится Входом другого блока с большим доминированием. Отношения Выход-Исполнитель отражают ситуацию, когда Выход одной активности становится средством достижения цели другой активности (рис. 12). Рисунок 12. Пять типов взаимосвязей между блоками для описания их отношений в модели SADT Дуги SADT, как правило, изображают наборы предметов, поэтому они могут разветвляться и соединяться вместе различным образом. Разветвления дуги означают, что часть ее содержимого (или весь набор предметов) может появиться в каждом ответвлении дуги. Дуга всегда помечается до разветвления, чтобы дать название всему набору. Каждая ветвь дуги может быть помечена в соответствии со следующими правилами: считается, что непомеченная ветвь содержит все предметы (или качественно не изменилась!), указанные в метке перед разветвлением; каждая метка ветви уточняет, что именно содержит эта ветвь. Слияние дуг указывает, что содержимое каждой ветви участвует в формировании после слияния объединенной дуги. После слияния дуга всегда помечается для указания нового набора, кроме того, каждая ветвь перед слиянием может помечаться в соответствии со следующими правилами: считается, что непомеченная ветви содержат все предметы, указанные в общей метке после слияния; каждая метка ветви уточняет, что именно содержит эта ветвь. Рисунок 13. Пример отношения Выход-Исполнитель Пример SADT-диаграммы, моделирующей деятельность компании, занимающейся распределением товаров по заказам (рис. 9) приведен на рисунке 14. Рисунок 14. Пример SADT-диаграммы (см. пример 1) Сравнительный анализ SADT-моделей и потоковых моделей Практически во всех методах структурного анализа используются три группы средств моделирования: • Диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между этими функциями – методологии DFD или SADT (IDEF 0). • Диаграммы, моделирующие данные и их взаимосвязи (ERD); • Диаграммы, моделирующие поведение системы (STD). … Название ERD STD Структурные карты DFD + + + SADT + - - Методология SSADM Методология SSADM (Structured Systems Analysis and Design Method) – методология, которая ориентирована на диаграммы потоков данных. Методология создана в начале 80-х годов и принята в 1993 году в качестве стандарта Великобритании для разработки информационных систем. Достоинством методологии является наличие взаимосвязанных методик, регламентирующих начальные этапы разработки системы, центральным из которых является этап итеративного определения требований. SSADM не распространяется на этапы, связанные с реализацией, внедрением и сопровождением системы. Для таких этапов разработчик должен обратиться к общедоступным методологиям, рекомендуемым британским государственным агентством по информатике и вычислительной технике. В SSADM применяется нисходящий подход к построению интегрированных функциональных, информационных и событийных моделей. 1). При моделировании функций используются классические DFD (включающие только базовые объекты: процесс, поток данных, хранилище данных, внешнюю сущность) с миниспецификациями на структурированном естественном языке. 2). Моделирование данных осуществляется с использованием нотации LDS (Logical Data Structured), являющейся диалектом ER-модели. 3). Для событийного моделирования используются диаграммы истории жизни сущностей ELN (Entity Life History), поддерживающие индикаторы состояний, события с привязанными к ним действиями, возможность задавать последовательные, параллельные и итеративные конструкции, а также конструкции выбора. Согласно SSADM определение системных требований включает следующие шесть основных этапов: 1) Оценка реализуемости. Данный этап предваряет инициацию работ по созданию системы, его основными процессами являются следующие: • Анализ первичных бизнес-требований (включая определение целевого назначения будущей системы, ее основных пользователей и т.п.). • Предварительная экономическая оценка проекта. • Построение план-графика выполнения основных работ. • Подготовка документов по оценке возможности создания системы. 2) Предпроектное обследование и моделирование требований. Результатом данного этапа должна являться функционально полная модель требований заказчика к будущей системе, а также оценки важности этих требований для будущего пользователя и оценки необходимых для реализации каждого требования ресурсов. SSADM рекомендует следующие шаги для достижения результата этапа: • Определение границ будущей системы. • Выявление основных требований. • Выявление процессов обработки информации. • Выявление обрабатываемых данных. • Построение информационно-логической модели требований. • Обобщение результатов и подготовка отчетов. 3) Выбора варианта автоматизации. На основании результатов (оценок) предшествующего этапа предлагаются несколько (от 3 до 6) вариантов автоматизации, из которых на основании выявленных ограничений совместно с заказчиком выбирается окончательный вариант. 4) Разработка логического проекта. На данном этапе осуществляется пересмотр выявленных требований с учетом выбранного варианта автоматизации с фиксацией неотраженных данным вариантом требований. При этом требования детализируются и уточняются, выявляются противоречия между ними, создается и оценивается прототип будущей системы. После завершения данного этапа SSADM запрещает добавление новых функциональных требований, допускается лишь их корректировка и уточнение. 5) Выбор варианта реализации. Этап включает проработку нескольких вариантов реализации, касающихся технической и программной среды, их оценку и совместный с заказчиком выбор варианта. 6) Физическое проектирование. • Разработка физической информационной модели. • Разработка спецификаций к программным компонентам. • Оптимизация информационной модели. • Уточнение спецификаций к программным компонентам. • Оформление документации. Отличительной чертой SSADM является четкое выделение и поддержка соответствующими методиками так называемых «нефункциональных требований». Нефункциональные требования специфицируют, с каким уровнем качества система должна выполнять свои функции. Примерами таких требований являются: • среднее время наработки на отказ; • время отклика; • ограничение доступа; • требования безопасности и т.п. ЗАДАНИЕ 1. Создать диаграмму детализации DFD уровня А-0 для ресурса (по вариантам) из проекта «Ремонт». Пример приведен на рисунке 16 для ресурса P1 – Водитель (вариант №1). Рисунок 15. DFD_NULL Здесь, внешние события (ВС) – это потоки данных; процессы (П) – внешние сущности. Рисунок 16. DFD_Ресурс_водитель Рисунок 17. Расширенная диаграмма потоков данных (детализирующая DFD_Ресурс_Водитель) Здесь, УП_1.Базовый_план_ проекта – узел-предок №1 - поток «Базовый план проекта» (Б); УП_2.Фактический_план_ проекта – узел-предок №2 - поток «Фактический план проекта» (Ф); ГУ_Б0 – групповой узел №0 для потока «Базовый план проекта» (Б); NU_Б0 – неиспользуемый узел №0 для потока «Базовый план проекта»; ГУ_Б1 – групповой узел №1 для потока, в который входят ресурс 1 – водитель, ресурс 4 – снабженец, ресурс 8 – подсобник и неосвоенный резерв базового плана проекта. ЗАДАНИЕ 2. Создать расширенную диаграмму детализации DFD уровня А-0 для ресурса (по вариантам) из проекта «Ремонт». Пример приведен на рисунке 17 для ресурса P1 – Водитель (вариант №1). Замечание. Если для задачи системного проекта «Ремонт» указан тип – фиксированная длительность (ФД), тогда необходимо добавить на диаграмме задачу «Отделка помещений» и потоки «ВС_2. Неосвоенный резерв» и «ВС_2. Освоенный резерв» (см. файл Проект1_Ремонт_Базовый_Детальный_Опт_2_Врв_Тип_2_Врв.csv и рис. 17). Глава 5. Диаграммы «Сущность-связь» Диаграммы «сущность-связь» (ERD) предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей). Данная нотация была введена Ченом (Chen) и получила дальнейшее развитие в работах Баркера (Barker). Нотация Чена предоставляет богатый набор средств моделирования данных, включая собственно ERD, а также диаграммы атрибутов и диаграммы декомпозиции. Эти диаграммные техники используются прежде всего для проектирования реляционных баз данных (но можно для моделирования сетевых и иерархических баз данных). Глава 5.1. Сущности, отношения и связи в нотации Чена Сущность представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, идей, предметов и т.п.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, АЭРОПОРТ, а не ВНУКОВО). Отношение в самом общем виде представляет собой связь между двумя и более сущностями. Именование отношения осуществляется с помощью грамматического оборота глагола (ИМЕЕТ, ОПРЕДЕЛЯЕТ, МОЖЕТ ВЛАДЕТЬ и т.п.) или команды (ИМЕТЬ, ОПРЕДЕЛЯТЬ, МОЖНО ВЛАДЕТЬ и т.п.). Другим словами, сущности представляют собой базовые типы информации, хранимой в базе данных, а отношения показывают, как эти типы данных взаимоувязаны друг с другом. Введение подобных отношений преследует две основополагающие цели: • обеспечение хранения информации в единственном месте (даже если она используется в различных комбинациях); • использование этой информации различными приложениями. На рисунке 18 (а) приведены символы ERD, соответствующие сущностям и отношениям. Символ ERD - сущность Символ ERD - отношение Рис. 18 (а). Символы ERD в нотации Чена Независимая сущность представляет независимые данные, которые всегда присутствуют в системе. При этом отношения с другими сущностями могут как существовать, так и отсутствовать. В свою очередь зависимая сущность представляет данные, зависящие от других сущностей в системе. Поэтому она должна иметь отношения с другими сущностями. Ассоциированная сущность представляет данные, которые ассоциируются с отношениями между двумя и более сущностями (рис. 18, а). Неограниченное (обязательное) отношение представляет собой безусловное отношение, которое всегда существует до тех пор, пока существуют относящиеся к делу сущности. Пример – отношение «может владеть». Ограниченное (необязательное) отношение представляет собой условное отношение между сущностями. Пример – отношение «имеет». Существенно-ограниченное отношение используется, когда соответствующие сущности взаимно-зависимы в системе. Пример – отношение «определяет» (термин1 – определение1; термин2 – определение1; термин3 – определение2; термин3 – определение3). Для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения, используются СВЯЗИ. Каждая связь соединяет сущность и отношение и может быть направлена только от отношения к сущности. ЗНАЧЕНИЕ связи характеризует ее тип и, как правило, выбирается из следующего множества: {«∅ или 1» или «О или 1» , «0 или более» , «1» , «1 или более» , «p:q»(диапазон) }. Пара значений связей, принадлежащих одному и тому же отношения, определяет тип этого отношения. Доказано на практике, что для большинства приложений достаточно использовать следующие типы отношений: 1) 1*1 (один-к-одному). Отношения данного типа используются, как правило, на верхних уровнях иерархии модели данных, а на нижних уровнях встречаются сравнительно редко. 2) 1*n (один-к-многим). Отношения данного типа являются наиболее часто используемыми. 3) n*m (многие-к-многим). Отношения данного типа обычно используются на ранних этапах проектирования с целью прояснения ситуации. В дальнейшем каждое из таких отношений должно быть преобразовано в комбинацию отношений 1 и 2 (возможно, с добавлением вспомогательных сущностей и с введением новых отношений). На рисунке 18 (б) приведена диаграмма «сущность-связь», демонстрирующая отношения между объектами банковской системы (см. п.5.2 – диаграммы атрибутов). Согласно этой диаграмме каждый БАНК ИМЕЕТ один или более БАНКОВСКИХ СЧЕТОВ. Кроме того, каждый КЛИЕНТ МОЖЕТ ВЛАДЕТЬ (одновременно) одной или более КРЕДИТНОЙ КАРТОЙ и одним или более БАНКОВСКИМ СЧЕТОМ, каждый из которых ОПРЕДЕЛЯЕТ в точности одну КРЕДИТНУЮ КАРТУ (отметим, что у клиента может и не быть ни счета, ни кредитной карты). Каждая КРЕДИТНАЯ КАРТА ИМЕЕТ ровно один зависимый от нее ПАРОЛЬ КАРТЫ, а каждый КЛИЕНТ ЗНАЕТ (но может и забыть) ПАРОЛЬ КАРТЫ. Рисунок 18 (б). ER-диаграмма в нотации Чена Глава 5.2. Диаграммы атрибутов Каждая сущность обладает одним или несколькими атрибутами, которые однозначно идентифицируют каждый экземпляр сущности. При этом любом атрибут может быть определен как ключевой. Детализация сущности осуществляется с использованием диаграмм атрибутов, которые раскрывают ассоциированные с сущностью атрибуты. Диаграмма атрибутов состоит из детализируемой сущности, соответствующих атрибутов и доменов, описывающих области значений атрибутов. На диаграмме каждый атрибут представляется в виде связи между сущностью и соответствующим доменом, являющимся графическим представлением множества возможных значений атрибута. Все атрибутные связи имеют значения на своем окончании. Для идентификации ключевого атрибута используется подчеркивание имени атрибута. Пример диаграммы атрибутов, детализирующей сущность КРЕДИТНАЯ КАРТА (см. рис. 18(б)) приведен на рисунке 19. Рисунок 19. Диаграмма атрибутов Глава 5.3. Категоризация сущностей Сущность может быть разделена и представлена в виде двух или более сущностей-категорий, каждая из которых имеет общие атрибуты и/или отношения, которые определяются однажды на верхнем уровне наследуются на нижнем. Сущности-категории могут иметь и свои собственные атрибуты и/или отношения, а также в свою очередь, могут быть декомпозированы своими сущностями-категориями на следующем уровне. Расщепляемая на категории сущность получила название общей сущности (отметим, что на промежуточных уровнях декомпозиции одна и та же сущность может быть как общей сущностью, так и сущностью-категорией). Для демонстрации декомпозиции сущности на категории используются диаграммы категоризации. Такая диаграмма содержит общую сущность, две и более сущности-категории и специальный узел-дискриминатор, который описывает способы декомпозиции сущностей (см. рис. 20). Рисунок 20. Диаграмма категоризации Существуют 4 возможных типа дискриминатора (рис. 21): 1) Полное и обязательное вхождение E/M (exclusive/mandatory) – сущность должна быть одной и только одной из следуемых категорий. Для примера на рисунке 20 это означает, что ПРЕПОДАВАТЕЛЕМ является ФИЗИК, или ХИМИК, или МАТЕМАТИК (рис. 21, а). 2) Полное и необязательное вхождение E/O (exclusive/optional) – сущность может быть одной или только одной из следующих категорий. Это означает, что ПРЕПОДАВАТЕЛЕМ является ФИЗИК, или ХИМИК, или МАТЕМАТИК, или преподаватель какой-либо другой дисциплины (например, ИСТОРИК) (рис. 21, б). 3) Неполное и обязательное вхождение I/M (inclusive/mandatory) – сущность должна быть по крайней мере оной из следуемых категорий. Это предполагает в дополнение к 1) задавать следующую ситуацию: ПРЕПОДАВАТЕЛЕМ является одновременно и ФИЗИК и ХИМИК. 4) Неполное и необязательное вхождение I/O (inclusive/optional) – сущность может быть по крайней мере одной из следуемых категорий. В дополнение к 2) ПРЕПОДАВАТЕЛЕМ является преподаватель какой-либо другой дисциплины (например, ИСТОРИК). Рисунок 21. Типы дискриминаторов Глава 5.4. Нотация Баркера Дальнейшее развитие ER-подход получил в работах Баркера, предложившего оригинальную нотацию, которая позволила на верхнем уровне интегрировать предложенные Ченом средства описания моделей. В нотации Баркера используется только один тип диаграмм – ERD. Сущность на ERD представляется прямоугольником любого размера, содержащим внутри себя имя сущности, список имен атрибутов (возможно неполный) и указатели ключевых атрибутов (знак «#» перед именем атрибута). Все связи являются бинарными и представляются линиями с двумя концами (соединяющими сущности), для которых должно быть определено имя, степень множественности (один или много объектов участвуют в связи) и степень обязательности (т.е. обязательная или необязательная связь между сущностями). Для множественной связи линия присоединяется к прямоугольнику сущности в трех точках, а для одиночной связи – в одной точке. При обязательной связи рисуется непрерывная линия до середины связи, при необязательной – пунктирная линия. На рисунке 22 приведен фрагмент ERD для банковской задачи в нотации Баркера. Рисунок 22. Нотация Баркера Читается связь отдельно для каждого конца, показывая, как сущность КЛИЕНТ связывается с сущностью КРЕДИТНАЯ КАРТА, и наоборот. При этом необходимо учитывать степень обязательности выбранного конца связи, для этой цели используются слова «должен (быть)» или «может (быть)». Так, диаграмма, приведенная на рисунке 22 читается следующим образом: «Каждый КЛИЕНТ может ВЛАДЕТЬ одной или более КРЕДИТНОЙ КАРТОЙ» или «Каждая КРЕДИТНАЯ КАРТА должна ПРИНАДЛЕЖАТЬ ровно одному КЛИЕНТУ». Понятия категория и общая сущность заменяются Баркером на эквивалентные понятия подтипа и супертипа, соответственно. Глава 5.5. Построение модели ERD Разработка ERD включает следующие основные этапы: 1) Идентификация сущностей, их атрибутов, а также первичных и альтернативных ключей. 2) Идентификация отношений между сущностями и указание типов отношений. 3) Разрешение неспецифических отношений (отношений n*m). Этап 1. Является определяющим при построении модели, его исходной информацией служит содержимое хранилищ данных, определяемое входящими и выходящими в/из него потоками данных. На рисунке 23 приведен фрагмент диаграмм потоков данных, моделирующей деятельность бухгалтерии предприятия. Его единственное хранилище ДАННЫЕ О ПЕРСОНАЛЕ должно содержать информацию о всех сотрудниках: их имена, адреса, должности, оклады и т.п. Рисунок 23. Деятельность бухгалтерии Первоначально осуществляется анализ хранилища, включающий сравнение содержимого входных и выходных потоков и создание на основе этого сравнения варианта схемы хранилища. Перечислим структуры данных, содержащиеся во входных и выходных потоках: ВХОДНЫЕ СТРУКТУРЫ ДАННЫХ ВЫХОДНЫЕ СТРУКТУРЫ ДАННЫХ вновь_нанятые адрес_служащего дата_найма фамилия фамилия адрес таб_номер адрес подробности_зарплаты должность фамилия начальная_зарплата таб_номер текущая_зарплата уволенные фамилия история_занятости таб_номер фамилия таб_номер изменение_адреса дата_найма фамилия история_карьеры* таб_номер должность старый_адрес дата_изменения новый_адрес история_зарплаты* зарплата изменение_зарплаты фамилия таб_номер старая_зарплата новая_зарплата дата_изменения Сравнивая входные и выходные структуры, отметим следующие моменты: 1) Поле АДРЕС хранит текущий адрес сотрудника, а структура ИЗМЕНЕНИЕ_АДРЕСА хранит и старый адрес, что не является необходимым, исходя из выходных потоков. 2) ИСТОРИЯ_ЗАРПЛАТЫ, наоборот, требует перечень всех окладов сотрудника, поэтому необходимо иметь набор, состоящий из пар (ЗАРПЛАТА, ДАТА), а не просто СТАРАЯ_ЗАРПЛАТА и НОВАЯ_ЗАРПЛАТА (как во входном потоке). 3) Аналогичная ситуация и с ИСТОРИЕЙ_КАРЬЕРЫ. Отметим, что на диаграмме вообще отсутствует поток, определяющий изменения в должности, то есть обнаружено серьезное упущение в функциональной модели. 4) Отметим, что изменение в ДОЛЖОСТИ обычно (но не всегда) соответствует изменению в ЗАРПЛАТЕ. С учетом моментов п.1-п.4 первый вариант схемы может выглядеть следующим образом: подробности_зарплаты фамилия таб_номер текущая_зарплата история_карьеры* должность дата_изменения история_зарплаты* зарплата дата_изменения Рисунок 24. Сущности модели Рисунок 25. Алгоритм приведения в 3НФ Этап 2 служит для выявления и определения отношений между сущностями, а также для идентификации типов отношений. На данном этапе некоторые отношения могут быть неспецифическими (n*m – многие-ко-многим). Такие отношения потребуют дальнейшей детализации на этапе 3. Этап 3 предназначен для разрешения неспецифических (многие ко многим) отношений. Для этого каждое неспецифическое отношение преобразуется в два специфических отношения с введением новых – ассоциативных – сущностей. Неспецифическое отношение на рисунке 26 указывает, что СТУДЕНТ может изучать много ПРЕДМЕТОВ, а ПРЕДМЕТ может изучаться многими СТУДЕНТАМИ. Далее введем новую ассоциативную сущность ИЗУЧЕНИЕ_ПРЕДМЕТА. Каждый экземпляр введенной сущности связан с одним СТУДЕНТОМ и с одним ПРЕДМЕТОМ. Таким образом, ассоциативные сущности по своей природе являются представлениями пар реальных объектов и обычно появляются на этапе 3. Рисунок 26. Разрешение неспецифического отношения Глава 6. Архитектура современных систем и методологий В центре любой методологии находится некоторая системная архитектура, и лишь затем совокупность стратегий и методов анализа и проектирования. Архитектура современных систем является трехслойной (рис. 27) и имеет следующие характеристики: • четко определенные слои, • формальные и явные интерфейсы между слоями, • скрытые и защищенные детали внутри каждого слоя. Рисунок 27. Архитектура современной системы Три слоя (база данных, правила бизнеса, документы) отражают возрастание уровня абстракции в рассматриваемой системной архитектуре. Наиболее детальным слоем является база данных, более высокий уровень абстракции – слой правил бизнеса, наивысший уровень абстракции – слой документов. В данной архитектуре слой правил бизнеса является относительно новой концепцией, соответствующей функциям руководителей среднего звена. Процессы данного слоя отражают: • выполнение требуемых задач, • принятие решений в соответствующей компетенции, • запуск других задач в слое правил бизнеса и других слоях. Независимость слоев трехслойной системной архитектуры обеспечивает следующие основные преимущества: • улучшение базы данных – отделение базы данных от изменений в технологиях, а следовательно, поддержка согласованности и осмысленности данных в течении длительного периода времени; • гибкость интерфейсов пользователя – изменение интерфейсов без влияния на бизнес-процессы и наоборот; • разделение усилий коллектива разработчиков. Трехслойная архитектура (а именно, выделение слоя бизнес-правил) требует модификации существующих методологий, в первую очередь, информационно-ориентированных методологий и методологий, ориентированных на данные. Такие методологии имеют следующие две характеристики, нуждающиеся в изменении: • информационная модель (и база данных) рассматриваются как центральные понятия при анализе и проектировании; • функциональная модель (а следовательно, и правила бизнеса) является некоторым дополнением к информационной модели. Согласно такому подходу, информационная модель является первичной, занимает центральное место и регламентирует весь процесс анализа и проектирования, что приводит к следующим ограничениям: • построенная на ее основе функциональная модель либо является слабо связанной с информационной моделью, либо неадекватно отражает существующие бизнес-процессы и правила; • сама по себе информационная модель является недостаточной (но важной) для решения задач консалтинга; • информационная модель плохо понимается неспециалистами, поэтому попытки вовлечь руководство в разработку обречены на неудачу. С другой стороны, руководств прекрасно ориентируется в технологиях и бизнес-процессах предприятия. Более того, функциональные модели (например, на базе диаграмм потоков данных) интуитивно понимаемы неспециалистами. Таким образом, в центре современного проекта лежат база данных и бизнес-процесс. При этом основным центром является бизнес-процесс и становится первичным и во многом определяет весь проект. Модель процесса является ценным средством для размышлений и совместной работы над перспективами развития предприятия и системной разработкой. Тем не менее информационная модель продолжает оставаться важной и соответствующим образом влиять на разрабатываемую функциональную модель. В таблице 7 представлена трехслойная системная архитектура в разрезе регламентируемых методологией этапов разработки (анализ требований, проектирование, реализация). Таблица 7 Слои Анализ Проектирование Реализация Документы Поток работ Поток форм Формы Правила бизнеса Поток процессов Модель компонентов Программы База данных Модель данных Схема базы данных Таблицы Анализ требований. В слое документа рассматриваются обобщенные потоки между подразделениями и конкретными сотрудниками предприятия без подробного описания каких-либо учетных форм и интерфейсов. На уровне базы данных строится концептуальная модель, увязанная с функциональной моделью требований на уровне укрупненных подсхем будущей информационной модели. Проектирование. На уровне документа макетируются последовательности форм. На уровне документа макетируются последовательности форм. На уровне бизнес-правил осуществляется детальное проектирование будущих рабочих мест с привязкой к конкретным сущностям информационной модели. На уровне базы данных концептуальная модель преобразуется в диаграмму «сущность-связь». Реализация. На данном этапе проект преобразуется в систему. Глава 7. Спецификации управления Спецификации управления предназначены для моделирования и документирования аспектов систем, зависящих от времени или реакции на событие (см. лекции «Модель вход-обработка-выход»). Они позволяют осуществлять декомпозицию управляющих процессов и описывают отношения между входными и выходными управляющими потоками на управляющем процессе-предке. Для этой цели обычно используются диаграммы переходов состояний (State Transition Diagrams). С помощью STD можно моделировать последующее функционирование системы на основе её предыдущего и текущего функционирования. Моделируемая система в любой заданный момент времени находится точно в одном из конечного множества состояний. С течением времени она может изменить свое состояние, при этом переходы между состояниями должны быть точно определены. STD состоит из следующих объектов: СОСТОЯНИЕ (ожидание, обработка, преобразование, переключение потоков управления процессом) – может рассматриваться как условие устойчивости для системы. Находясь в определенном состоянии, мы имеем достаточно информации о прошлой истории системы, чтобы определить очередное состояние в зависимости от текущих входных событий. Имя состояния должно отражать реальную ситуацию, в которой находится система, например, НАГРЕВАНИЕ, ОХЛАЖДЕНИЕ и т.п. НАЧАЛЬНЕ СОСТОЯНИЕ – узел STD, являющийся стартовой точкой для начального системного перехода. STD имеет ровно одно начальное состояние, соответствующее состоянию системы после её инсталляции, но перед началом её реальной обработки, а также любое (конечное) число завершающих состояний. ПЕРЕХОД определяет перемещение моделируемой системы из одного состояния в другое. При этом имя перехода идентифицирует событие, являющееся причиной перехода и управляющее им. Это событие обычно состоит из управляющего потока (сигнала), возникающего как во внешнем мире, так и внутри моделируемой системы при выполнении некоторого условия (например, СЧЕТЧИК=999 или КНОПКА НАЖАТА). Отметим, что не все события необходимо вызывают переходы из отдельных состояний. С другой стороны, одно и то же событие не всегда вызывает переход в то же самое состояние. Таким образом УСЛОВИЕ представляет собой событие (или события), вызывающее переход и идентифицируемое именем перехода. Если в условии участвует входной управляющий поток управляющего процесса-предка, то имя потока должно быть заключено в кавычки, например, «ПАРОЛЬ»=666, где ПАРОЛЬ – входной поток. Кроме условия с переходом может связываться действие или ряд действий, выполняющихся, когда переход имеет место. То есть ДЕЙСТВИЕ – это операция, которая может иметь место при выполнении перехода. Если действие необходимо для выбора выходного управляющего потока, то имя этого потока должно заключаться в кавычки, например: «ВВЕДЕННАЯ КАРТА» - TRUE, где ВВЕДЕННАЯ КАРТА – выходной поток. Кроме того, для спецификации A-, T-, E/D-потоков имя запускаемого или переключаемого процесса также должно заключаться в кавычки, например: A: «ПОЛУЧИТЬ ПАРОЛЬ» - активировать процесс ПОЛУЧИТЬ ПАРОЛЬ. Фактически условие есть некоторое внешнее или внутреннее событие, которое система способна обнаружить и на которое она должна отреагировать определенным образом, изменяя свое состояние. При изменении состояния система обычно выполняет одно или более действий (производит вывод, выдает сообщение на терминал, выполняет вычисления). Таким образом, действие представляет собой отклик, посылаемый во внешнее окружение, или вычисление, результаты которого запоминаются в системе (обычно в хранилищах данных на DFD), для того, чтобы обеспечить реакцию на некоторые из планируемых в будущем событий. Правило 1. На DFD отсутствуют управляющие потоки (это управляющие действия на STD), но есть управляющие структуры (процессы) и обрабатывающие процессы. На STD состояния представляются узлами, а переходы - дугами (рис. 28). Рисунок 28. Символы STD Условия (по-другому называемые стимулирующими событиями) идентифицируются именем перехода и возбуждают выполнение перехода. Действия или отклики на события привязываются к переходам и записываются под соответствующим условием. Начальное состояние на диаграмме должно иметь входной переход, изображаемый потоком из подразумеваемого стартового узла (иногда этот стартовый узел изображается небольшим квадратом и привязывается к входному состоянию). Рассмотрим следующий пример. Диаграмма переходов состояний для примера банковской задачи приведена на рисунке 29. Диаграмма содержит два состояния - ОЖИДАНИЕ и ОБРАБОТКА. Переход из состояния ОЖИДАНИЕ в состояние ОБРАБОТКА осуществляется при условии ввода кредитной карты (ВВЕДЕННАЯ КРЕДИТНАЯ КАРТА). При этом выполняется действие по запуску процесса 1 - ПОЛУЧИТЬ ПАРОЛЬ. Отметим, что для запуска используется A-поток, обеспечивающий непрерывность процесса 1, то есть возможность повторного ввода пароля. Переход из состояния ОБРАБОТКА в состояние ОЖИДАНИЕ осуществляется двумя различными способами. При условии трехкратного ввода неверного пароля (см. спецификацию процесса 1) кредитная карта удаляется из системы, при этом она переходит в режим ожидания очередного клиента. При условии КОРРЕКТНЫЙ ПАРОЛЬ выполняются действия по обеспечению требуемого сервиса (последовательное включение процессов 2 и 3) и удалению кредитной карты, и затем переход в режим ожидания очередного клиента. При первом запуске автомат находится в состоянии Ожидание. После выполнения события 1 автомат переходит в состояние Обработка. Все последующие вызовы автомата будут исполняться с состояния Ожидания (моделирование запускаемого процесса; рис. 29, A-поток; диаграмма для библиотечной функции). Рисунок 29. STD для банковской задачи Правило 2. Детализация STD – это результат соединения нескольких SD диаграмм в диаграмму переключаемого процесса STD. При построении STD рекомендуется следовать правилам перечисленным ниже: • строить STD на как можно более высоком уровне детализации DFD (пример – диаграмма DFD_NULL); • строить как можно более простые STD, которые можно уточнить таблицами и матрицами переходов состояний; • по возможности детализировать STD (создавать SD диаграммы (рис. 32-33) и соединять их в диаграмму STD, рис. 34); Правило 2. • использовать те же принципы именований событий, состояний и действий, что и при именовании процессов и потоков. Применяются два способа построения STD. Первый способ требует идентификации всех возможных состояний и дальнейшего исследования всех переходов между состояниями. По второму способу сначала строится начальное состояние, затем следующие за ним состояния и т.д. Определите запускаемый процесс и переключаемый процесс. Таким образом построенная стратегическая STD требует в дальнейшем контроля состоятельности. Пример – рис. 32-34. Для контроля состоятельности результатов STD проверяют: • Все ли состояния определены и имеют уникальное имя? • Все ли состояния достижимы? • Все ли состояния имеют выход? • Для каждого ли состояния требуется в системе учесть все условия, особенно недостижимые? Уточните выполнение правила1, которое исключает управляющие потоки, то есть действия. • Все ли входные (выходные) потоки управляющего процесса отражены в условиях (действиях) на STD? В ситуации, когда число состояний и/или переходов велико, для проектирования спецификаций управления могут использоваться таблицы и матрицы переходов состояний. Обе эти нотации позволяют зафиксировать ту же самую информацию, что и диаграммы переходов состояний, но в другом формате. В качестве примера таблицы переходов состояний приведена таблица 8 для примера банковской задачи. Первая колонка таблицы содержит список всех состояний проектируемой системы, во второй колонке для каждого состояния приведены все условия, вызывающие переходы в другие состояния, а в третьей колонке – совершаемые при этих переходах действия. Четвертая колонка содержит соответствующие имена состояний, в которые осуществляется переход из рассматриваемого состояния при выполнении определенного условия. Таблица 8 ТАБЛИЦА - Моделирование запускаемого процесса с помощью STD Текущее состояние Условие Действие Следующее состояние 1 начальное состояние активируется каждый раз - 2 ОЖИДАНИЕ 2 ОЖИДАНИЕ A: введенная кредитная карта получить пароль 3 или 4 ОБРАБОТКА 3 ОБРАБОТКА A: некорректный пароль удалить кредитную карты 2 ОЖИДАНИЕ 4 ОБРАБОТКА T: корректный пароль обеспечить требуемый сервис, удалить кредитную карту 2 ОЖИДАНИЕ Алгоритм1 (табл. 8): 1 начальное состояние⟶ 2 ОЖИДАНИЕ⟶ 4 ОБРАБОТКА Или Алгоритм2 (табл. 8): 1 начальное состояние⟶ 2 ОЖИДАНИЕ⟶ 3 ОБРАБОТКА Матрица переходов состояний содержит по вертикали перечень состояний системы, а по горизонтали список условий. Каждый элемент матрицы содержит список действий, а также имя состояния, в которое осуществляется переход. Используется и другой вариант данной нотации: по вертикали указываются состояния, из которых осуществляется переход, а по горизонтали – состояния, в которые осуществляется переход. При этом каждый элемент матрицы содержит соответствующие условия и действия, обеспечивающие переход из «вертикального» состояния в «горизонтальное». Построим матрицу переходов состояний для системного проекта Ремонт (рис. 35). Таблица 9 МАТРИЦА ПЕРЕХОДОВ СОСТОЯНИЙ – Моделирование переключаемого процесса для системного проекта Ремонт Список состояний Условие 1 Условие 2 Условие 3 Условие 4 Условие 5 Условие 6 Условие 7 Условие 8 Событие0: начало проекта Событие1: ресурс Водитель – Р1 Событие2: «фиксированная длительность» Событие3: Действие1 завершено Событие4: ресурс Р1, Действие1 завершено Событие5: ресурс Р1, Действие4 завершено Событие6: ресурс Р1, Действие5 завершено Событие7: неосвоенный резерв Состояние 1 - начальное состояние Ожидание1: обработка базового плана Состояние 2/Действие начало E-потока: подготовка к ремонту.У1 Ожидание1: обработка базового плана Ожидание2: обработка фактического плана Состояние 3/ Действие D-поток: освоение резерва начало D-потока: начать новую задачу начало E-потока: доставка инструмента.У2 начало E-потока: закупка материалов.У1 начало E-потока: отделка помещений.У1 Ожидание2: обработка фактического плана Ожидание1: обработка базового плана Ожидание3. «Распределение неосвоенного резерва для профиля ресурса «загрузка в конце» Ожидание1: обработка базового плана Ожидание1: обработка базового плана Ожидание1: обработка базового плана Состояние 4/ Действие D-поток: завершить проект Ожидание3. «Распределение неосвоенного резерва для профиля ресурса «загрузка в конце» Ожидание1: обработка базового плана ЗАДАНИЕ 4. Создать диаграмму STD для ресурса (по вариантам) из проекта «Ремонт». Пример приведен на рисунке 35. В нотации матрица переходов состояний выполните проектирование спецификации, используя другой вариант данной нотации. Пример первого варианта нотации показан в таблице 8. ПРИЛОЖЕНИЕ 1. Создание модели поведения системы при помощи диаграммы состояний State diagram в системе Microsoft Office Visio. Рисунок 30. Диаграмма State diagram: библиотечная функция, реализуемая T-потоком управления процессом Рисунок 31. Диаграмма State diagram: библиотечная функция, реализуемая A-потоком управления процессом Рисунок 32. Диаграмма State diagram: распределенная функция (часть 1), реализуемая E-потоком управления процессом Рисунок 33. Диаграмма State diagram: распределенная функция (часть 2), реализуемая D-потоком управления процессом ПРИЛОЖЕНИЕ 2. Создание модели переходов состояний системы при помощи диаграммы State Transition Diagrams в системе Microsoft Office Visio. Рисунок 34. Диаграмма STD: распределенная функция (часть 1 и часть 2), реализуемая E/D-потоком управления процессом При первом запуске автомат находится в состоянии Ожидание1. После выполнения события 1 автомат переходит в состояние Обработка. Все последующие вызовы автомата будут исполняться с состояния Обработка (моделирование переключаемого процесса; рис. 34, E-поток; диаграмма для распределенной функции). Рисунок 35. Диаграмма STD для ресурса Водитель – Р1 системного проекта «Ремонт» Здесь, Событие2: «Фиксированная длительность» - это входной управляющий поток (обрабатывающий процесс); Ожидание3. «Распределение неосвоенного резерва для профиля ресурса «загрузка в конце»» (преобразование информационных элементов) - это выходной управляющий поток (управляющие структуры, то есть процессы) для системного проекта. При первом запуске автомат выполняет событие 1 (табл. 9). После выполнения события 1 автомат переходит в ожидание 2. Все последующие вызовы автомата будут исполняться с ожидания 2 (моделирование переключаемого процесса; рис. 35, E-поток; диаграмма для распределенной функции). Глава 8. Особенности моделирования бизнес-процессов Глава 8.1. Модели бизнес-процессов Для моделирования бизнес-процессов кроме традиционных диаграмм (главы 1-7 и введение) применяются и специальные разработанные для этой цели нотации, а именно: • Карты Харрингтона (Harrington), демонстрирующие только структуру бизнес-процесса; • Карты процесса, базирующиеся на стандарте ANSI. Карты Харингтона BFD (Block Flow Diagrams) являются простейшим и наиболее распространенным типом потоковых карт (схем). Такие схемы легко читаемы, поскольку содержат только два типа объектов: активности, моделирующие функции и детализируемые с помощью BFD нижнего уровня, и управляющие потоки, организующие последовательность выполнения активностей на рассматриваемом уровне. Фактически BFD позволяет формализовать лишь следующие знания о бизнес-процессах: «Состоит из», «Является частью», «Следует за», «Предшествует». Пример BFD приведен на рисунке 36 – структура бизнес-процесса «Обработка заказа». Эквивалентом потоковой карты Харрингтона BFD – «Обработка заказа», которую будем называть образцом (рис. 36), является следующее описание в виде текста: ОПРЕДЕЛЕНИЕ ПРОЦЕССА Обработка заказа СОСТОИТ ИЗ Принять заказ, Проверить заказ, Произвести товар, Доставить товар, Выставить счет //---// ОПРЕДЕЛЕНИЕ ПРОЦЕССА Принять заказ ВХОДИТ В Обработка заказа ПРЕДШЕСТВУЕТ Проверить заказ //---// ОПРЕДЕЛЕНИЕ ПРОЦЕССА Проверить заказ ВХОДИТ В Обработка заказа ПРЕДШЕСТВУЕТ Произвести товар СЛЕДУЕТ ЗА Принять заказ //---// ОПРЕДЕЛЕНИЕ ПРОЦЕССА Произвести товар ВХОДИТ В Обработка заказа ПРЕДШЕСТВУЕТ Доставить товар СЛЕДУЕТ ЗА Проверить заказ //---// ОПРЕДЕЛЕНИЕ ПРОЦЕССА Доставить товар ВХОДИТ В Обработка заказа ПРЕДШЕСТВУЕТ Выставить счет СЛЕДУЕТ ЗА Произвести товар //---// ОПРЕДЕЛЕНИЕ ПРОЦЕССА Выставить счет ВХОДИТ В Обработка заказа СЛЕДУЕТ ЗА Доставить товар Рисунок 36. Образец карты Харингтона BFD – структура бизнес-процесса «Обработка заказа» Таблица 10 Структура бизнес-процесса «Обработка заказа» в виде детализации управляющих потоков Время, t Управляющий поток 1 – «Заказ» Управляющий поток 2 – «Товар» Управляющий поток 3 – «Счет» t1 Начало бизнес-процесса «Обработка заказа» t2 Начало управляющего потока 1 t3 Ф1. Принять заказ t4 Ф2. Проверить заказ t5 Начало управляющего потока 2 t6 Ф3. Произвести товар t7 Ф4. Доставить товар t8 Начало управляющего потока 3 t9 Ф5. Выставить счет t10 Конец управляющего потока 3 t11 Конец управляющего потока 2 t12 Конец управляющего потока 1 t13 Конец бизнес-процесса «Обработка заказа» Карта процесса в стандарте ANSI определяется как «схематичное или табличное представление последовательности всех относящихся к делу действий или событий – операций, транспортировок, инспекций, хранений, задержек и тому подобным – происходящих в течение выполнения процесса или процедуры». Карта процесса в стандарте ANSI – это расширенная модель бизнес-процессов BFD (так как включает объекты Хранение и Задержка). Основные объекты карты процесса приведены в таблице 11. Далее рассмотрим характеристики объектов карты процесса в стандарте ANSI. Таблица 11 Основные объекты кары процесса в стандарте ANSI Объекты карты процесса в стандарте ANSI Описание объектов операция транспортировка инспекция хранение задержка Операция – моделирует изменение любой из физических или химических характеристик объекта, прием/выдачу им порции информации, а также любые вычисления и планирования. Пример распределенной функции – распределение (определение) количества информации в компьютерной среде. Инспекция – моделирует проверку или верификацию качественных или количественных свойств объекта. Пример – согласованное включение нового объема информации и согласованное исключение старого объема информации в компьютерной среде. Транспортировка – моделирует перемещение объекта, за исключением случаев, когда такое движение является частью операции или инспекции. Пример сеансовой связи – создание заверенной копии объема информации на стороне отправителя, упаковка (выполнение обязательств при перемещении) информации и согласованное включение\исключение заверенной копии информации на стороне получателя. Хранение – моделирует хранение объекта и защиту от несанкционированного доступа. Пример СУБД – выполнение обязательств вида КДЦ (Конфиденциальность, Доступность, Целостность) со стороны СУБД. Использование постоянных объектов. Задержка – моделирует ситуацию, в которой определенные условия не позволяют немедленно выполнить очередной планируемый шаг. Пример коллекции – динамические структуры данных, файловые структуры данных. Литералы или константы могут быть одного из четырех видов: простые, наборы (множество, куча или мультимножество, список, массив, словарь), структуры и специальная величина null Использование непостоянных объектов (задачи восстановления копии информации). Алгоритм (рис. 37): 1) Восстановить копию информации-> 2) Определить объем информации-> 3) Включить\исключить новый\старый объем информации-> 4) Хранить постоянные объекты вида КДЦ-> 5) Создать копию объема информации-> 2) Определить объем информации. Далее - перейти к началу алгоритма (циклическое повторение). В стандарте ANSI четко определяется различие между горизонтальными линиями, определяющими требуемые процессом ресурсы и устанавливающими отношения типа Обладать, и вертикальными линиями, идентифицирующими хронологическую последовательность и устанавливающими отношения Следует за и Предшествует. Иерархия строится на базе объекта Операция и использует отношения Состоит из, Является частью. Каждый из ресурсов может иметь свою единицу измерения с использованием отношения Измеряется. Эквивалентом карты процесса в стандарте ANSI – «Управление доставкой mail», которую будем называть образцом, приведенной на рисунке 37 является следующий текст: ОПРЕДЕЛЕНИЕ ПРОЦЕССА Управление доставкой mail СОСТОИТ ИЗ Ожидание, Прием, Инспекция, Хранение, Транспортировка, Отправка //---// ОПРЕДЕЛЕНИЕ РЕСУРСА Трудозатраты на сортировку ОБЛАДАТЕЛЬ Прием ИЗМЕРЯЕТСЯ Человеко-час //---// ОПРЕДЕЛЕНИЕ ПРОЦЕССА Прием ВХОДИТ В Управление доставкой mail ПРЕДШЕСТВУЕТ Инспекция СЛЕДУЕТ ЗА Ожидание ОБЛАДАЕТ Машинное время, Трудозатраты на сортировку, Mail //---// ОПРЕДЕЛЕНИЕ ПРОЦЕССА Отправка ВХОДИТ В Управление доставкой mail ПРЕДШЕСТВУЕТ Ожидание СЛЕДУЕТ ЗА Транспортировка ГЕНЕРИРУЕТ Доставленные mail Рисунок 37. Карта процесса в стандарте ANSI - образец «Управление доставкой mail» Глава 8.2. Специфика инструментария Моделирование и анализ бизнес-процессов современного предприятия без интенсивного применения соответствующего инструментария требует огромных трудозатрат и редко приводит к приемлемым результатам. Такой инструментарий должен обеспечивать: • Регистрацию информации по бизнес-процессам. • Продуцирование высокоуровневых представлений бизнес-процессов. • Сопровождение депозитария (модель объектно-ориентированных систем управления базами данных ODMG). Депозитарий – это набор постоянных объектов предопределенных классов, и содержит метаобъекты, полностью описывающие определенные в базе данных интерфейсы и классы, то есть типы объектов, хранящиеся в базе данных. • Контроль синтаксиса описания бизнес-процесса. • Контроль полноты и состоятельности бизнес-процесса. • Анализ и верификацию описаний процессов и формирование соответствующих отчетов. • Продуцирование спецификаций бизнес-процессов. • Определение стандартов для представления информации по бизнес-процессам и тому подобным. Фактически речь идет о своеобразной CASE-среде для бизнес-процессов, отличающейся от соответствующей среды для ПО. В обеих случаях решаются задачи анализа и проектирования, принципиальное отличие заключается в задаче генерации (отслеживание объема информации в распределенной компьютерной среде), поскольку бизнес-процесс гораздо сложнее (ПО является лишь одним из его компонентов). И если для ПО можно, по крайней мере, поставить цель его автоматической кодогенерации, то для бизнес-процесса это невозможно по причинам невозможности автоматического создания оргструктуры или производственного процесса. Здесь может быть поставлена цель - автоматическая генерация спецификаций бизнес-процессов и контроль их полноты и состоятельности. И в дальнейшем на основе спецификаций - осуществление функционально-стоимостного анализа, статистического анализа, вычисление наиболее эффективных комбинаций ресурсов, динамического анализа и тому подобным. В основе такой CASE-среды (здесь рассматриваем целевое назначение Case-средств, которое не включает разработку новой ИС) лежит понятие ЦИКЛА инжиниринга бизнес-процесса, включающего следующие этапы: • Организационные мероприятия по проведению работ по СОВЕРШЕНСТВОВАНИЮ бизнес-процессов; • Изучение процесса, включая его понимание, анализ и выявление узких мест; • Анализ предложений по совершенствованию; • Выбор и аргументация приемлемого варианта; • Реализация совершенствования. Фактически CASE-среда проектирования бизнеса поддерживает лишь этапы изучения, анализа и выбора. По своей структуре CASE-среда похожа на соответствующую среду ПО (среда ПО включает репозитарий) и включает в себя депозитарий, средства ввода, средства анализа и средства вывода. Депозитарий строится на аналогичных традиционным CASE-средствам принципах и отличается лишь более широкой номенклатурой хранимых объектов. Средствами ввода также является традиционная совокупность графических контекстно-чувствительных редакторов, предназначенных для ввода и последующей корректировки различных типов моделей бизнес-процессов. Центр тяжести анализа моделей переносится от верификации (для бизнес-моделей не существует каких-либо специальных формальных методов верификации) к следующей функциональности: • Статистический анализ и соответствующая презентация результатов в наглядном виде. • Линейное программирование и вычисление наиболее эффективных комбинаций ресурсов. • Функционально-стоимостной анализ. • Динамическое моделирование, включая анимацию. На практике наиболее широко используются следующие четыре подхода к динамическому моделированию: 1) Событийный подход (диаграммы SD, STD), для которого первичным объектом моделирования является событие, влияющее на обрабатывающие сущности функции (например, приход клиента, завершение обслуживания, ввод кредитной карты). 2) Активностный подход (карты Харингтона BFD), требующий описания действия, которое активируется изменением состояния системы (например, события «приход клиента» и «завершение обслуживания» требуют спецификации по крайней мере трех активностей, описывающих начало, содержание и завершение обслуживания). 3) Подход взаимодействующих процессов (карты процесса в нотации ANSI), рассматривающий последовательность операций, по которым обрабатывается сущность в течение её жизненного цикла внутри системы. 4) Трехфазный подход, различающий синхронные и асинхронные события. Для построения динамических моделей необходима следующая информация: • данные по процессам, событиям и условиям их возникновения; • атрибуты входных, выходных и внутренних потоков между процессами; • характеристики состояний, которые достижимы каждым из процессов; • информация по допустимости переходов между состояниями; • рабочие характеристики процессов; • распределения интенсивности каждого из потоков; • характеристики очередей. Средства вывода CASE-среды для бизнес-процессов должны формировать пакет отчетов и документов в удобной для последующего использования в форме, включающий результаты аудита существующих бизнес-процессов и требований по их управлению (а именно, спецификации процессов, отчеты по их полноте и состоятельности, результаты статистического, функционально-стоимостного, динамического и т.д. анализа), спецификации требований к целевым бизнес-процессам (включая функциональные и нефункциональные требования, а также требования по управлению), планы и программы перехода от текущего состояния к целевому, оценки рисков. Все эти документы должны опираться на соответствующий комплекс стандартов, включающий: • стандарты на язык описания бизнес-процессов; • стандарты на спецификации требований и спецификации проектирования бизнес-процессов; • стандарты на методики оценки полноты и состоятельности, а также методы и средства анализа процессов; • метрики бизнес-процессов. ПРИЛОЖЕНИЕ 3. Создание модели структурного анализа и разработки техник при помощи диаграммы SADT в системе Microsoft Office Visio. Целевое назначение системного проекта «Ремонт» включает подцель «Распределение освоенного резерва» (рис. 38). Иными словами освоенный резерв ресурсами проекта утверждается не всегда. Часть всего освоенного резерва в виде фиксированного объема затрат переносится на «% завершено» для задач (при этом могут быть выделены дополнительные объемы ресурсов). И только после этого рассматривается вопрос о распределении резерва, которые был освоен на предыдущем этапе выполнения работ системного проекта «Ремонт» (рис. 39-40). Рисунок 38. SADT-блок для уровня диаграммы IDEF0 A-0 Таблица 12. Проектирование SADT-блока диаграммы IDEF0 уровня A0 Назначение элемента образца SADT-блока диаграммы IDEF0 уровня A0 (рис. 14) Постановка задачи для примера системного проекта «Ремонт», ресурс «Водитель» правила контроля и сортировки, Control A1 график ресурсов и сетевой график заказы, Input A1 базовый план аннулированные заказы, Output A1 превышение доступности ресурсов Входной контроль и сортировка, A1 Входной контроль выполнения базового плана и использование ресурсов, A1 необеспеченные заказы, Call A1 пиковые единицы ресурсов из графика ресурсов обеспеченные заказы, Call A1 выделено ресурсов, Output A1 правила доукомплектации, Control A2 смета (суммарная задача) и таблицы норм затрат (дата действия) товары, Input A2 фактический план платежи, Output A2 % завершено заявки на товары, Output A2 заявки на ресурсы Доукомплектация заказов, A2 Доукомплектация задач фактического плана товары, Call A2 новые ресурсы укомплектованные заказы, Call A2 укомплектованные задачи правила реализации, Input A3 тип задачи платежи, Input A3 % завершено товары, Output A3 отрезки плана к суммарной задаче счета к оплате, Output A3 освоенный резерв и неосвоенный резерв, ВС_2 (потоки могут одновременно менять знаки +, -) Реализация заказов, A3 Реализация задач системного проекта «Ремонт» Рисунок 39. SADT-блок для диаграммы IDEF0 уровня A0 (ресурс Р1 - Водитель) Рисунок 40. SADT-блок для диаграммы IDEF0 уровня A0 (ресурс Р1 – Водитель) с отношением вида «Выход - Исполнитель» Примечание. На диаграммах (рис. 39-40) указаны преобразования вида Выход «превышение доступности ресурсов», «выделено ресурсов», «% завершено», «заявки на ресурсы», которые решают задачу пограничного контроля и 1) образуются внутри системы, 2) показаны короткими стрелками и обозначают тем самым, что 3) эти выходные потоки являются частью главного входного потока – «базовый план» - (целевое назначение системы). Преобразования вида Call «пиковые единицы ресурсов из графика ресурсов», «укомплектованные задачи», «новые ресурсы» тоже являются частью главного входного потока «базовый план», но они задействованы в качестве закрепленных единиц плана и решают задачу сортировки. Поток данных «выделено ресурсов» (рис. 41 и 42) - это процесс управления для постановки задачи «Распределение освоенного резерва» (целевое назначение ресурса – максимальное количество единиц -, которое может остаться недостигнутым из-за перемещения освоенных данных не в задачу «запись в ресурс», а в задачу «запись в задачу РЕЗЕРВ»). Рисунок 41. SADT-блок для диаграммы IDEF0 уровня A3 (ресурс Р1 - Водитель) Рисунок 42. SADT-блок для диаграммы IDEF0 уровня A33 (ресурс Р1 - Водитель) ЗАДАНИЕ 7. Создать диаграмму SADT уровней A-0 и A0 для ресурса (по вариантам) из системного проекта «Ремонт» на основе образца – рисунок 14. Пример для ресурса «Водитель» приведен на рисунках 38-40. Создать диаграмму SADT уровня A3 для ресурса (по вариантам) из проекта «Ремонт» на основе образца – рисунок 13 и примера для ресурса «Водитель» – рисунок 41. Детализация работы A33 может быть рассмотрена как диаграмма DFD детализирующая (рис. 17). Глава 9. Методологии, ориентированные на данные С позиций ориентированных на данные методологий вход и выход модели являются наиболее важными, структуры данных (а не потоки данных) определяются первыми, а процедурные компоненты строятся как производные от структур данных. Фактически процесс проектирования заключается в определении структур данных, слиянии их в некий прообраз иерархической структуры программы и наполнении этой структуры детальной логикой обработки данных. Для поддержки такого подхода традиционно используются сетевые диаграммы для определения потоков, источников и приемников данных, древовидные структуры диаграммы для представления иерархии как структур данных, так и программных структур, а также диаграммы детализации логики процедур (обычно на базе структурного естественного языка). Глава 9.1. Структурное проектирование Джексона Классическим примером рассматриваемого подхода является структурное проектирование Джексона. Его базовая процедура проектирования предназначена для «простых» программ («сложная» программа разбивается на «простые» традиционными методами) и включает следующие 4 этапа: 1) Этап проектирования данных. a. Построение системной сетевой диаграммы, демонстрирующей все хранилища, источники и стоки данных в программе. b. Представление каждой входной и выходной структуры данных древовидной структурной диаграммой. 2) Этап проектирования программ. a. Формирование структуры программы комбинированием структур данных. b. Идентификация всех связей между компонентами структур данных. c. Верификация полученной структуры программы. 3) Этап проектирования операций. a. Построение списка операций, необходимых для продуцирования выходных структур данных из входных. b. Назначение операций компонентам структуры программы. 4) Этап проектирования текстов. a. Трансляция построенной модели программы в текстовый вид с добавлением ряда логических условий для управления выполнением циклов и выбором данных. Глава 9.2. Проектирование систем, ориентированных на данные – DSSD, предложенные Варнье-Орром Другим примером рассматриваемого подхода является DSSD (Data-Structured Systems Development), предложенная Варнье-Орром и ориентированная на разработку систем со структурными данными методология, использующая теорию множеств для описания проекта ПО. Также как и в математике, множество определяется перечислением его элементов. Так множество отделов компании может быть описано следующим образом: компания = {бухгалтерия, маркетинг, производство, распространение} DSSD использует аналогичную нотацию, а именно множественную скобку (рис. 43). Рисунок 43. Множественная скобка подхода DSSD Подобно методологии Джексона, в рассматриваемом подходе структура программы строится на базе структур данных, а главным отличием является то, что в методологи Джексона необходимо сливать все входные и выходные структуры данных для продуцирования структуры программы, а в DSSD входные данные и структура программы продуцируются из выходных структур. Таким образом, главная аксиома DSSD утверждает, что выходные структуры данных полно и точно определяют входные структуры, которые и определяют логику их обработки. При построении модели DSSD используются диаграммы сущностей (диалект DFD) для определения системного контекста и диаграммы Варнье-Орра (assembly-line diagrams) в качестве основного средства моделирования системы. Базовым элементом диаграммы Варнье-Орра является множественная скобка. Детализация элементов данных производится слева-направо, предполагаемая последовательность действий осуществляется слева-направо и сверху-вниз. Такая нотация удобна для представления композиции структур, определения структур данных, спецификации форматов файлов, и может быть использована для иллюстрирования структуры программы и иерархии модулей (заменой структур данных на модули или файлы, а на нижних уровнях – на подпрограммы, DO-циклы, условные и другие операторы), являясь в этом случае неким аналогом визуального языка проектирования типа FLOW-форм. Основные этапы методологии изображены на рисунке 44 с помощью диаграммы Варнье-Орра. Рисунок 44. Диаграмма Варнье-Орра Диаграмма Варнье-Орра использует 4 базовые конструкции: иерархии, последовательности, повторения и альтернативы. Значительно реже применяются конструкции параллелизма и рекурсии. Фундаментом диаграммы является иерархия, представляемая с помощью гнездующихся групп элементов, охваченных множественными скобками, непосредственно демонстрирующими уровни иерархии. Пример - методология = {планирование проекта, определение требований, проектирование} планирование проекта = {NULL} определение требований = {логические требования, физические требования} проектирование = {логическое проектирование, физическое проектирование} логические требования = {контекст приложения, функции приложения, результат приложения} физические требования = {задачи, альтернативные решения, ранжирование решений, выбор решения} логическое проектирование = {логическое проектирование БД, логическое проектирование процессов} физическое проектирование = {физические требования к задачам, альтернативные физические проекты, ранжирование физических проектов, выбор физического проекта} Последовательность – простейшая конструкция модели, перечисляющая компоненты уровня иерархии сверху вниз. Обе конструкции очевидны из рисунка 44, который может интерпретироваться следующим образом: «Методология содержит в качестве первого этапа – планирование проекта, в качестве второго этапа – определение требований, в качестве третьего этапа – проектирование…». Повторение является эквивалентом понятия цикла в классическом программировании и обозначается указанием нижней и верхней границ количества итераций (рис. 45). Рисунок 45. Повторение подхода DSSD Альтернатива или выбор отражает традиционный процесс принятия решения и определяет отношение между двумя и более подмножествами множества (рис. 46). Рисунок 46. Альтернатива или выбор подхода DSSD Параллелизм синтаксически отличается от альтернативы заменой символа «@» (Copyright) на символ «+» и используется, когда порядок исполнения не имеет значения. Данная конструкция, как правило, используется при проектировании ПО для моделирования параллельной обработки. Рекурсия используется для указания вхождения в качестве подмножества самого множества и обозначается двойной множественной скобкой. Классическим примером рекурсии является спецификация изделия, содержащего узлы и детали, при этом каждый узел, в свою очередь, может состоять из подузлов и деталей и т.д. (рис. 47). Рисунок 47. Рекурсия подхода DSSD Глава 10. Словарь данных Диаграммы потоков данных обеспечивают удобное описание функционирования компонент системы, но не снабжают аналитика средствами описания деталей этих компонент, а именно, какая информация преобразуется процессами и как она преобразуется. Для решения первой из перечисленных задач предназначены текстовые средства моделирования, служащие для описания структуры преобразуемой информации и получившие название словарей данных. Словарь данных представляет собой определенным образом организованный список всех элементов данных системы с их точными определениями, что дает возможность различным категориям пользователей (от системного аналитика до программиста) иметь общее понимание всех входных и выходных потоков и компонент хранилищ. Определения элементов данных в словаре осуществляются следующими видами описаний: • описанием значений потоков и хранилищ, изображенных на DFD; • описанием композиции агрегатов данных, движущихся вдоль потоков, т.е. комплексных данных, которые могут расчленяться на элементарные символы (например, АДРЕС ПОКУПАТЕЛЯ содержит ПОЧТОВЫЙ ИНДЕКС, ГОРОД, УЛИЦУ и т.д.); • описанием композиции групповых данных в хранилище; • специфицированием значений и областей действия элементарных фрагментов информации в потоках и хранилищах; • описанием деталей отношений между хранилищами. Глава 10.1. Содержимое словаря данных Для каждого потока данных в словаре необходимо хранить имя потока, его тип и атрибуты. Информация по каждому потоку состоит из ряда словарей статей, каждая из которых начинается с ключевого слова – заголовка соответствующей статьи, которому предшествует символ «@». По типу потока в словаре содержится информация, идентифицирующая: • простые (элементарны) или групповые (комплексные) потоки; • внутренние (существующие только внутри системы) или внешние (связывающие систему с другими системами) потоки; • потоки данных или потоки управления; • непрерывные (принимающие любые значения в пределах определенного диапазона) или дискретные (принимающие определенные значения) потоки. Атрибуты потока данных включают: • имена-синонимы потока данных в соответствии с узлами изменения имени; • БНФ-определение в случае группового потока (глава 10.2); • единицы измерения потока; • диапазон значений для непрерывного потока, типичное его значение и информацию по обработке экстремальных значений; • список значений и их смысл для дискретного потока; • список номеров диаграмм различных типов, в которых поток встречается; • список потоков, в которые данный поток входит (как элемент БНФ-определения); • комментарий, включающий дополнительную информацию (например о цели введения данного потока). Глава 10.2. БНФ-нотация БНФ-нотация позволяет формально описать расщепление/ объединение потоков. Поток может расщепляться на собственные отдельные ветви, на компоненты потока-предка или на то и другое одновременно. При расщеплении/ объединении потока существенно, чтобы каждый компонент потока-предка являлся именованным. Если поток расщепляется на подпотоки, необходимо, чтобы все подпотоки являлись компонентами потока-предка. И наоборот, при объединении потоков каждый компонент потока-предка должен по крайней мере однажды встречаться среди подпотоков. Отметим, что при объединении подпотоков нет необходимости осуществлять исключение общих компонент, а при расщеплении подпотоки могут иметь такие общие (одинаковые) компоненты. Важно понимать, что точные определение потоков содержаться в словаре данных, а не на диаграммах. Например, на диаграмме может иметься групповой узел с входным потоком X и выходными подпотоками Y и Z. Однако это вовсе не означает, что соответствующее определение в словаре данных обязательно должно быть X = Y +Z. Это определение может быть следующим: X = A+ B + C; Y = A + B; Z = B + C. Такие определения хранятся в словаре данных в так называемой БНФ-статье. БНФ-статья используется для описания компонент данных в потоках данных и в хранилищах. Ее синтаксис имеет вид: @БНФ = <простой оператор> ! <БНФ-выражение>, где <простой оператор> есть текстовое описание, заключенное в «/», а <БНФ-выражение> есть выражение в форме Бэкуса-Наура, допускающее следующие операции отношений: = - означает «композиция из», + - означает «И», [ ! ] – означает «ИЛИ», ( ) – означает, что компонент в скобках не обязателен, { } – означает итерацию компонента в скобках, « » - означает литерал. Итерационные скобки могут иметь нижний и верхний предел, например: 3{болт}7 – от 3 до 7 итераций 1{болт} – 1 и более итераций {шайба}3 – не более 3 итераций БНФ-выражение может содержать произвольные комбинации операций: @БНФ = [винт ! болт + 2{гайка}2 + (прокладка) ! клей] Ниже приведен пример описания потока данных с помощью БНФ: @ИМЯ = ВОСЬМЕРИЧНАЯ ЦИФРА @ТИП = дискретный поток @БНФ = [«0» ! «1» ! «2» ! «3» ! «4» ! «5» ! «6» ! «7»] Посмотрим, как некоторые потоки, присутствующие на вышеприведенных диаграммах потоков данных, представляются с помощью БНФ: @ИМЯ = ВВЕДЕННАЯ КРЕДИТНАЯ КАРТА @ТИП = управляющий поток @БНФ = /указывает, что кредитная карта введена/ @ИМЯ = ДАННЫЕ КРЕДИТНОЙ КАРТЫ @ТИП = дискретный поток @БНФ = ПАРОЛЬ + ДЕТАЛИ КЛИЕНТА + ЛИМИТ ДЕНЕГ @ИМЯ = ДАННЫЕ ПО БАЛЛАНСУ @ТИП = дискретный поток @БНФ = /текущий баланс счета клиента/ @ЕДИНИЦА ИЗМЕРЕНИЯ = доллар @ДИАПАЗОН = +/- 100000 @ТОЧНОСТЬ = .01 @ИМЯ = ДЕНЬГИ @ТИП = дискретный поток @БНФ = /деньги, выдаваемые клиенту/ @ЕДИНИЦА ИЗМЕРЕНИЯ = доллар @НОРМА = 5..1000 @КОММЕНТАРИЙ Сумма выдаваемых денег должна делиться на 5 @ИМЯ = ПРОТОКОЛ ОБСЛУЖИВАНИЯ @ТИП = дискретный поток @БНФ = (ОБРАБОТАННАЯ ДОКУМЕНТАЦИЯ) + (ДЕНЕЖНАЯ СУММА) + (ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА) ПРИЛОЖЕНИЕ 4. Создание диаграммы «сущность-связь» - ERD в нотации Chen (Чена) в системе Microsoft Office Visio. Рассмотрим диаграммы IDEF0 (SADT-блоки) на рисунках 38-42, которые включают следующие три потока/модели ВХОД-ОБРАБОТКА-ВЫХОД (табл. 13). Таблица 13. Содержимое словаря данных для примера системного проекта «Ремонт», ресурс Р1 – Водитель Уровень диаграммы IDEF0 Поток или модель ВХОД-ОБРАБОТКА-ВЫХОД для ресурса Р1 - Водитель A-0 Поток А план фактический→ неосвоенный резерв Поток Б начало проекта→ окончание проекта Поток В план базовый→ освоенный резерв (затраты на использование ресурса) A0 Поток А план фактический→ «% завершено» (контроль)→ сетевой график→ укомплектованные задачи (сортировка)→ неосвоенный резерв Поток Б начало проекта→ отрезки фактического плана с отслеживанием→ превышение доступности ресурсов→ смета (суммарная задача)→ заявки на ресурсы (контроль)→ график ресурсов→ пиковые единицы ресурса из графика ресурсов (сортировка)→ новые ресурсы→ отрезки плана к суммарной задаче→ окончание проекта Поток В план базовый→ выделено ресурсов→ таблицы норм затрат (дата действия)→ тип задачи→ профиль загрузки ресурса «загрузка в конце»→ исполнитель→ освоенный резерв (затраты на использование ресурса) A3 Поток А план фактический→ «% завершено» (контроль)→ сетевой график→ укомплектованные задачи (сортировка)→ ФЗ→ неосвоенный резерв Поток Б начало проекта→ отрезки фактического плана с отслеживанием→ превышение доступности ресурсов→ смета (суммарная задача)→ заявки на ресурсы (контроль)→ график ресурсов→ пиковые единицы ресурса из графика ресурсов (сортировка)→ ФО→ новые ресурсы→ отрезки плана к суммарной задаче→ окончание проекта Поток В план базовый→ Тип ограничения задачи→ выделено ресурсов→ неосвоенный резерв выделенными ресурсами→ ФД→ таблицы норм затрат (дата действия)→ тип задачи→ профиль загрузки ресурса «загрузка в конце»→ исполнитель Р1 - Водитель→ освоенный резерв (затраты на использование ресурса) A33 Поток В план базовый→ Тип ограничения задачи→ выделено ресурсов→ неосвоенный резерв выделенными ресурсами→ ФД→ таблицы норм затрат (дата действия)→ тип задачи→ профиль загрузки ресурса «загрузка в конце»→ исполнитель Р1 – Водитель→ ФЗ→ освоенный резерв на этапе системного проекта «Закупка материалов»→ ФЗ→ освоенный резерв на этапе системного проекта «Подготовка к ремонту»→ освоенный резерв на этапе системного проекта «Отделка помещений»→ освоенный резерв (затраты на использование ресурса) Рисунок 48. Диаграмма ERD стратегического уровня (поток В, уровень A33) в нотации Chen (Чена) Рисунок 49. Диаграмма атрибутов для сущности "ЗАДАЧА" За образец взяты диаграммы, приведенные на рисунках 18 и 19. ЗАДАНИЕ 8. Создать словарь данных и диаграмму «сущность-связь» - ERD в нотации Chen (Чена) стратегического уровня для ресурса (по вариантам). Уточните для диаграммы ERD (рис. 48) тип связи с учетом группового узла «Исполнитель» max = {дискриминатор, Р1, Р4, Р8, ВС_2}. Создать диаграмму атрибутов и диаграмму декомпозиции (диаграмму ERD) для ресурса (по вариантам). Уточните для диаграммы атрибутов (рис. 49) домен «типы задач» (фиксированный объем, фиксированная длительность, фиксированные затраты), включив в него дискриминатор «тип ограничения задачи» («как можно позже», «как можно раньше», «начало не позднее», «начало не ранее», «окончание не позднее», «окончание не ранее», «фиксированное начало», «фиксированное окончание»). Глава 11. Метод описания процессов IDEF3 На диаграммах IDEF0 явно не указываются последовательность выполнения действий и время [2]. Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота [3]. Однако для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая workflow diagramming - методологией моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Workflow diagramming могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа или события, которые необходимо обработать за конечное время. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции. IDEF3 – это метод, имеющий основной целью дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе. Техника описания набора данных IDEF3 является частью структурного анализа. IDEF3 может быть также использован как метод создания процессов. IDEF3 дополняет IDEF0 и содержит все необходимое для построения моделей, которые в дальнейшем могут быть использованы для имитационного анализа (модели типа «что – если?»). Каждая работа в IDEF3 описывает какой-либо сценарий бизнес-процесса и может являться составляющей другой работы. Поскольку сценарий описывает цель и рамки модели, важно, чтобы работы именовались отглагольным существительным, обозначающим процесс действия, или именным словосочетанием, содержащим такое существительное. Точка зрения на модель должна быть задокументирована. Обычно это точка зрения человека, ответственного за работу в целом. Также необходимо задокументировать цель модели – те вопросы, на которые призвана ответить модель. Диаграммы. Диаграмма является основной единицей описания в IDEF3. Можно предположить, что правильная диаграмма должна включать все типы стрелок, все типы перекрестков и все типы объектов ссылок (рис. 62). Единицы работы – Unit of Work (UOW). UOW, также называемые работами (activity), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе словосочетания, и номер (идентификатор); другое имя существительное в составе того же словосочетания, зависимое от отглагольного существительного, обычно отображает основной выход (результат) работы (например, «Изготовление изделия»). Часто имя существительное в имени работы меняется в процессе моделирования, поскольку модель может уточняться и редактироваться. Идентификатор работы присваивается при создании и не меняется никогда. Даже если работа будет удалена, ее идентификатор не будет вновь использоваться для других работ. Обычно номер работы состоит из номера родительской работы и порядкового номера на текущей диаграмме. Работа в IDEF3 требует более подробного описания, чем работа в IDEF0. Каждая единица работы – UOW – должна иметь ассоциированный документ, который включает текстовое описание компонентов работы: объектов (Objects) и фактов (Facts), связанных с работой, ограничений (Constraints), накладываемых на работу, и дополнительное описание работы (Description). Эта информация заносится во вкладку UOW диалога Activity Properties. Пример значений свойств UOW приведен в таблице 14. Таблица 14. Пример текстового описания компонентов UOW на примере системного проекта «Ремонт» (модель создания процессов, рис. 60) Тип Использование Name (название) Функция1. Проведение работ системного проекта «Ремонт» для распределения профиля загрузки ресурса Description (описание) Выполнение и закрытие задач по плану системного проекта «Ремонт» и распределение освоенного резерва ресурсами Objects (объекты) план; задача; ресурс; профиль загрузки ресурса; тип ограничения задачи Facts (факты) план базовый, план фактический; типы задач: фиксированная длительность, фиксированный объем работ, фиксированные затраты; профиль загрузки ресурса: плоский, загрузка в конце, загрузка в начале, двойной пик, ранний пик, поздний пик, колокол, черепаха; Constraints (ограничения) Перемещение задачи «РЕЗЕРВ» или дублирование этой задачи в плане системного проекта «Ремонт» потребует изменить детальное расписание проекта (график ресурсов) Таблица 15. Пример текстового описания компонентов UOW на примере системного проекта «Ремонт» (модель для описания объектов, участвующих в одном процессе, рис. 62 и рис. 63) Тип Использование Name (название) Работа-цель. Проведение работ системного проекта «Ремонт» для распределения профиля загрузки ресурса Description (описание) Выполнение задач по плану системного проекта «Ремонт» и прерывание задачи; и минимально возможное распределение освоенного резерва исполнителем Objects (объекты) план; задача; ресурс; профиль загрузки ресурса; тип ограничения задачи Facts (факты) план базовый, план фактический; типы задач: фиксированная длительность, фиксированный объем работ, фиксированные затраты; профиль загрузки ресурса: загрузка в конце; модель детального расписания проекта Constraints (ограничения) Изменение детального расписания проекта потребует изменить рейтинг ресурсов, чтобы правильно обеспечить для заказчика прерывание задачи при выполнении системного проекта «Ремонт» Связи. Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправленны и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо, характеризуя временной характер поведения системы. В IDEF3 различают три типа стрелок, изображающих связи (рис. 63), стиль которых устанавливается во вкладке Style диалога Arrow Properties приложения AllFusion Process Modeler 4.1 (BPwin 4.1) [3]. Связи отражаются стрелками трех типов и определяют: временное предшествование работ; потоки объектов; нечеткое отношение [2]. Старшая (Referent, Эталонная) стрелка – сплошная линия, связывающая единицы работ(UOW). Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется. Стрелка отношения (Relational Link, Узел отношения, технология) – пунктирная линия, использующаяся для изображения связей между единицами работ(UOW), а также между единицами работ и объектами ссылок. Потоки объектов (Object Flow) – стрелка с двумя наконечниками, применяется для описания того факта, что объект используется в двух или более единицах работы, например когда объект порождается в одной работе и используется в другой работе. Старшая связь или поток объектов (Precedence, Предшествование). Старшая связь показывает, что работа-источник заканчивается ранее, чем начинается работа-цель. Часто результатом работы-источника становится объект, необходимый для запуска работы-цели. В этом случае стрелку, обозначающую объект, изображают с двойным наконечником. Имя стрелки должно ясно идентифицировать отображаемый объект. Поток объектов имеет ту же семантику, что и старшая стрелка. Отношение показывает, что стрелка является альтернативой старшей стрелке или потоку объектов в смысле задания последовательности выполнения работ – работа-источник не обязательно должна закончиться прежде, чем работа-цель начнется. Более того, работа-цель может закончиться прежде, чем закончится работа-источник (рис. 50). Рисунок 50. Временная диаграмма выполнения работ Перекрестки (Junction). Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и разветвления. Для внесения перекрестка служит отдельная кнопка в палитре инструментов. Рассмотрим основные типы перекрестка (табл. 16). Таблица 16. Типы перекрестков Обозначение Наименование перекрестка Смысл в случае слияния стрелок (Fan-in Junction) Смысл в случае разветвления стрелок (Fan-out Junction) Асинхронное «И» (Asynchronous AND) Все предшествующие процессы должны быть завершены Все следующие процессы должны быть запущены Синхронное «И» (Synchronous AND) Все предшествующие процессы завершены одновременно Все следующие процессы запускаются одновременно Асинхронное «ИЛИ» (Asynchronous OR) Один или несколько предшествующих процессов должны быть завершены Один или несколько следующих процессов должны быть запущены Синхронное «ИЛИ» (Synchronous OR) Один или несколько предшествующих процессов завершены одновременно Один или несколько следующих процессов запускаются одновременно Исключающее «ИЛИ» XOR (Exclusive OR) Только один предшествующий процесс завершен Только один следующий процесс запускается Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Junction Properties (вызывается из контекстного меню). В отличие от IDEF3 стрелки могут сливаться и разветвляться только через перекрестки. Рассмотрим смысл перекрестка каждого типа. Рисунок 51. Перекрестки для слияния и разветвления типа синхронного "И". Здесь после завершения работы 1 одновременно запускаются работы 2 и 4. Для запуска работы 5 требуется одновременное завершение работ 3 и 4 Рисунок 52. Перекрестки для слияния и разветвления типа асинхронного "И". Здесь после завершения работы 1 запускаются работы 2 и 4 (не обязательно одновременно). Для запуска работы 5 требуется завершение работ 3 и 4 (не обязательно одновременное) Рисунок 53. Перекрестки для слияния и разветвления типа асинхронного "ИЛИ". Здесь после завершения работы 1 запускается либо работа 2, либо работа 3, либо работа 4, либо их сочетание (не обязательно одновременно). Для запуска работы 5 требуется завершение любой из работ 2, 3 и 4 или их сочетания (не обязательно одновременное) Рисунок 54. Перекрестки для слияния и разветвления типа синхронного "ИЛИ". Здесь после завершения работы 1 запускается либо работа 2, либо работа 3, либо работа 4, либо их сочетание. Если запускается более одной работы, требуется их одновременный запуск. Для запуска работы 5 требуется завершение любой из работ 2, 3 и 4 или их сочетание. Если завершается более чем одна работа, требуется их одновременное завершение Рисунок 55. Перекрестки для слияния и разветвления типа исключающего "ИЛИ". Здесь после завершения работы 1 запускается только одна работа - либо работа 3, либо работа 4. Для запуска работы 5 требуется завершение только одной из работ, 3 или 4 Правила создания перекрестков. На одной диаграмме IDEF3 может быть создано несколько перекрестков различных типов. Определенные сочетания перекрестков для слияния и разветвления могут приводить к логическим несоответствиям. Чтобы избежать конфликтов, необходимо соблюдать следующие правила: 1. Каждому перекрестку для слияния должен предшествовать перекресток для разветвления. 2. Перекресток для слияния «И» не может следовать за перекрестком для разветвления типа синхронного или асинхронного «ИЛИ» (рис. 56). Действительно, после работы 1 может запускаться только одна работа – 2 или 3, а для запуска работы 5 требуется окончание обеих работ – 3 и 4. Такой сценарий не может реализоваться. Рисунок 56. Неверное размещение перекрестков. Перекресток для слияния "И" не может следовать за перекрестком для разветвления "ИЛИ" 3. Перекресток для слияния «И» не может следовать за перекрестком для разветвления типа исключающего «ИЛИ» (рис. 57). Рисунок 57. Неверное размещение перекрестков. Перекресток для слияния "И" не может следовать за перекрестком для разветвления типа исключающего "ИЛИ" 4. Перекресток для слияния типа исключающего «ИЛИ» не может следовать за перекрестком для разветвления типа «И» (рис. 58). Здесь после завершения работы 1 запускаются обе работы – 2 и 3, а для запуска работы 4 требуется, чтобы завершилась одна и только одна работа – или 2, или 3. Рисунок 58. Неверное размещение перекрестков. Перекресток для слияния типа исключающего «ИЛИ» не может следовать за перекрестком для разветвления типа «И» 5. Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой стороне. Объект ссылки. Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой (рис. 59). Для внесения объекта ссылки служит специальная кнопка (Referent) в палитре инструментов. Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы. Рисунок 59. Объект ссылки - Referent Имя объекта ссылки задается в диалоге Referent Properties, в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок – безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). Например, BPwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объектов, не поддерживаются. При внесении объектов ссылок помимо имени следует указывать тип объекта ссылки (рис. 63). Типы объектов ссылок приведены в таблице 17 [3]. Таблица 17. Типы объектов ссылок Тип объекта ссылки Цель описания OBJECT Описывает участие важного объекта в работе GOTO Инструмент циклического перехода (в повторяющейся последовательности работ), возможно на текущей диаграмме, но не обязательно. Если все работы цикла присутствуют на текущей диаграмме, цикл может также изображаться стрелкой, возвращающейся на запуск. GOTO может ссылаться на перекресток UOB (Unit of behavior) Применяется, когда необходимо подчеркнуть множественное использование какой-либо работы, но без цикла. Например, работа «Контроль качества» может быть использована в процессе «Изготовления изделия» несколько раз, после каждой единичной операции. Обычно этот тип ссылки не используется для моделирования автоматически запускающихся работ NOTE Применяется для документирования важной информации, относящейся к каким-либо графическим объектам на диаграмме. NOTE является альтернативой внесению текстового объекта в диаграмму ELAB (Elaboration) Используется для усовершенствования графиков или их более детального описания. Обычно употребляется для детального описания разветвления и слияния стрелок на перекрестках Декомпозиция работ. В IDEF3 декомпозиция используется для детализации работ. Методология IDEF3 позволяет декомпозировать работу многократно, т.е. работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные потоки. Декомпозиция может быть описанием (уровень родительской модели) или сценарием (уровень декомпозиции родительской модели). Сценарий является частным случаем описания и иллюстрирует только один путь реализации процесса. По умолчанию при декомпозиции на диаграмму IDEF3 создается описание. Чтобы создать сценарий, необходимо перейти в меню Diagram/Add IDEF3 Scenario. Возможность множественной декомпозиции предъявляет дополнительные требования к нумерации работ. Так, номер работы состоит из номера родительской работы, номера декомпозиции родительской работы и собственного номера работы на текущей диаграмме (рис. 59). Для описания номер декомпозиции равен единице. Для сценария номер декомпозиции всегда больше единицы. При создании описания или сценария необходимо придерживаться дополнительных ограничений – в сценарии или декомпозиции может существовать только одна точка входа. За точкой входа следует работа или перекресток. Для декомпозиции может существовать только одна точка выхода. Сценарий, который не является декомпозицией, может иметь несколько точек выхода. Имитационное моделирование. Перед современными предприятиями часто встает задача оптимизации технологических процессов. Метод функционального моделирования позволяет обследовать существующие бизнес-процессы, выявить их недостатки и построить идеальную модель деятельности предприятия. Построение функциональной модели осуществляется от общего к частному – сначала описывается общая схема деятельности предприятия, затем шаг за шагом все боле и более подробно описываются конкретные технологические процессы. Такой подход весьма эффективен, однако на уровне наибольшей детализации, когда рассматриваются конкретные технологические операции, для оптимизации этих операций функциональной модели может оказаться недостаточно. В этом случае целесообразно использовать имитационное моделирование. Имитационное моделирование – это метод, позволяющий строить модели, учитывающие время выполнения функций. Полученную модель можно выполнять во времени и получить статистику происходящих процессов так, как это было бы в реальности. В имитационной модели изменения процессов и данных ассоциируются с событиями. Выполнение модели – это последовательный переход от одного события к другому. Одним из наиболее эффективны инструментов имитационного моделирования является система Arena фирмы System Modeling Corporation (http://www.sm.com). Имитационная модель Arena включает следующие основные элементы: источники и стоки (Create и Dispose), процессы (Process) и очереди (Queue). Источники – это элементы, от которых в модель поступает информация или объекты. Скорость поступления данных или объектов от источника обычно задается статистической функцией. Сток – это устройство для приема информации или объектов. Понятие очереди близко к понятию хранилища данных – это место, где объекты ожидают обработки. Времена обработки объектов (производительность) в разных процессах могут быть разными. В результате перед некоторыми процессами могут накапливаться объекты, ожидающие своей очереди. Часто целью имитационного моделирования является минимизация количества объектов в очередях. Тип очереди в имитационной модели может быть конкретизирован. Очередь может быть похожа на стек – пришедшие последними в очередь объекты первыми отправляются на дальнейшую обработку (LIFO: last-in-first-out). Альтернативой стеку может быть последовательная обработка, когда первыми на дальнейшую обработку отправляются объекты, пришедшие первыми (FIFO: first-in-first-out). Могут быть заданы и более сложные алгоритмы обработки очереди. Процессы – это аналог работ в функциональной модели. В имитационной модели может быть задана производительность процессов. Палитра инструментов Arena содержит модули типа Flowchart (Decide (сделать выбор), Create, Dispose и Process), модули типа Data (Queue, Entity и Resource). Часть этих объектов (Record, Assign, Separate, Batch и Simulate) включены в модель, представленную на рисунках 60 и 61. Таблица 18 Сопоставление модулей Arena и EPC Diagram Shapes Модуль Arena Модуль EPC Diagram Shapes (Microsoft Office Visio) Process Function Separate Process path Batch Process group Entity, Resource, Queue Information/Material Assign Component Record Organizational unit Decide Enterprise area, Event Simulate Main process ПРИЛОЖЕНИЕ 5. Построение диаграммы в графической нотации IDEF3 (рис. 60) как метод создания процессов (в системе Microsoft Office Visio, шаблон проекта Shapes→ Business Process→ EPC Diagram Shapes, Enterprise Petri Color). Рисунок 60. Метод создания процессов в графической нотации IDEF3 для описания сценариев последовательности процессов на примере системного проекта «Ремонт» Здесь, фигура Informational/ Material (Информация/ Материал) задает набор данных имитационной модели. Фигура Separate (Отделять) позволяет выполнить единицу работы отдельным объектом. Пример сценария – в плане отделяется задача, которая выполняется с помощью ресурса до её завершения исполнителем. Фигура Batch (Групповой процесс) позволяет получить объект ссылки (для этого используется принцип композиции объектов, т.е. контекстный уровень диаграммы IDEF3) и перейти к окончанию работы-цели. Пример сценария – завершить стрелку типа «Старшая связь и поток объектов» (Precedence). Фигура Organizational unit (Запись) позволяет получить версию для объекта модели Informational/ Material (Информация/ Материал). Пример – постепенное выполнение базового плана и переход к фактическому плану. Фигуры цвета Organizational unit (Запись) задают задачи-вехи для сетевой модели (например, плана). Примеры фигур цвета Organizational unit – это Enterprise area (Задание для принятия решения) и Main process (Главный процесс). Фигура Enterprise area (Задание для принятия решения) определяет обязательную проверку условия (прогнозирование результата) и переход к началу модели. Используется для организации параллельной обработки данных вычислительного процесса. Фигура Function (Функция) определяет работу-цель для имитационной модели. Фигура Event (Событие) задает условия (прогнозирование результата) для состояния объектов модели. Фигура Assign (Передавать) определяет работу-источник, которая предшествует окончанию работы-цели. Пример – рисунок 50 и рисунок 62, на котором работа-источник «Назначение ресурса к задачам» всегда предшествует работе-цели «Проведение работ системного проекта «Ремонт» для распределения профиля загрузки ресурса». Фигура Main process (Главный процесс) задает условия (прогнозирование результата) останова выполнения имитационной модели. Фигура Simulate (Моделировать с целью) содержит цель моделирования (Purpose) и точку зрения (Viewpoint) для описательной модели и модели декомпозиции. Отсутствие стрелок в модели означает, что началом модели может быть любой информационный или материальный объект, а также направление потоков данных можно организовать только в одном из направлений – это справа налево. Перемещение задачи «РЕЗЕРВ» в плане системного проекта «Ремонт» задает и возможное место прерывания выполнения проекта исполнителем. Пример – задача «Нанесение плиточных покрытий. Кухня» в плане системного проекта «Ремонт» имеет идентификатор 114 (на основе ассоциированного документа, импортируемого из приложения Microsoft Project) и реализуется высокооплачиваемым исполнителем-профессионалом – это плиточником. Предлагаем, включая эту задачу, завершить выполнение системного проекта «Ремонт» и считать проект успешно выполненным. В то же время момент завершения проекта (принятие такого решения на этапе задачи 114) должен начаться, только если плиточник примет задание к исполнению (не найдет нареканий к предыдущим исполнителям работ на объекте). Модель декомпозиции работы «Проведение работ системного проекта «Ремонт» для распределения профиля загрузки ресурса» построена по принципу профиля загрузки ресурса - «загрузка в конце» и по совокупности работ, выполняемых исполнителем P1 - «Водитель» (рис. 61). Здесь точкой входа является событие 1 – Фиксированные затраты. Точкой выхода является событие 3 – Неосвоенный резерв выделенными ресурсами. Рисунок 61. Декомпозиция работы «Проведение работ системного проекта «Ремонт» для распределения профиля загрузки ресурса» Построение диаграммы в графической нотации IDEF3 (рис. 62) как метод описания объектов, участвующих в одном процессе (в системе Microsoft Office Visio, шаблон проекта Shapes→ Business Process→ EPC Diagram Shapes и шаблон проекта Shapes→ Flowchart→ Basic Flowchart Shapes). Рисунок 62. Метод имитационного анализа в графической нотации IDEF3 для описания объектов, участвующих в одном процессе, для системного проекта «Ремонт» Начинаем освобождать ресурсы, начиная с задачи, после которой в плане установлен резерв для проекта. При этом для ресурса выполняем распределение профиля загрузки ресурса (пример - «загрузка в конце»), только если все предшествующие задачи завершены групповым потоком плана для этого ресурса (рис. 62). Рисунок 63. Диаграмма IDEF3, поясняющая образование стрелки типа «Отношение» (Relational Link), стрелки типа «Предшествование» (Precedence – «Старшая связь и поток объектов») и объекта ссылок типа «Переход» (GOTO) для стрелки типа «Старшая» (Referent – «Эталон»; например, «Ссылка «Групповой узел») в модели на рисунке 62 Рисунок 64. Декомпозиция работы-цели "Проведение работ системного проекта «Ремонт» для распределения профиля загрузки ресурса" (для ресурса P1 - Водитель) ЗАДАНИЕ 9. Создать модель по методу описания процессов в графической нотации IDEF3 для уровня декомпозиции работы-цели «Проведение работ системного проекта «Ремонт» для распределения профиля загрузки ресурса» по вариантам (ресурс, групповой узел). За образец рекомендуется взять диаграмму IDEF3 для ресурса P1 – Водитель, представленную на рисунке 64. Примечание. Автоматизация модели предполагает распознавание ресурса как исполнителя по совокупности завершенных задач системного проекта «Ремонт». Воссоздание ссылки «Групповой узел» позволяет определить момент времени распределения профиля загрузки ресурса, гарантируя тем самым минимальную величину освоенного резерва. СПИСОК ЛИТЕРАТУРЫ 1). Калянов Г.Н. CASE-технологии. Консалтинг при автоматизации бизнес-процессов. 2-е изд. перераб. и доп. – М. : Горячая линия – Телеком, 2000. – 320 с., ил. ISBN 5-93517-017-5 2). Алгазинов Э.К., Сирота А.А. Анализ и компьютерное моделирование информационных процессов и систем / Под общ. ред. д.т.н. А.А. Сироты. – М.: Диалог-МИФИ, 2009. – 416 с. ISBN 978-5-86404-233-5 3). Маклаков С.В. Создание информационных систем с AllFusion Modeling Suite. – М.: ДИАЛОГ-МИФИ, 2003 – 432 с. ISBN 5-86404-181-5