сд.01_пиэ_о_проектирование ИС_12310-2010_8_1. Образовательный стандарт учебной дисциплины Проектирование информационных систем
 Скачать 7.87 Mb.
|
|
Средства структурного анализа и их взаимосвязи Прежде чем подробно рассмотреть каждое из основных инструментальных средств структурного анализа, необходимо обсудить их в общем виде и продемонстрировать их взаимосвязи. Для целей моделирования систем вообще, и структурного анализа в частности, используются три группы средств, иллюстрирующих: - функции, которые система должна выполнять; - отношения между данными; - зависящее от времени поведение системы (аспекты реального времени). Среди всего многообразия средств решения данных задач в методологиях структурного анализа наиболее часто и эффективно применяемыми являются следующие: DFD (Data Flow Diagrams) — диаграммы потоков данных совместно со словарями данных и спецификациями процессов; ERD (Entity-Relationship Diagrams) — диаграммы "сущность-связь"; STD (State Transition Diagrams) — диаграммы переходов состояний. Все они содержат графические и текстовые средства моделирования: первые — для удобства демонстрирования основных компонентов модели, вторые — для обеспечения точного определения ее компонентов и связей. Логическая DFD показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицирует хранилища (накопители) данных, к которым осуществляется доступ. Структуры потоков данных и определения их компонентов хранятся и анализируются в словаре данных. Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня; когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции при помощи спецификации процесса (мини-спецификации). Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью ERD. В случае наличия реального времени DFD дополняется средствами описания зависящего от времени поведения системы, раскрывающимися с помощью STD. Эти связи показаны на рисунке А.4.6. Перечисленные средства дают полное описание системы независимо от того, является ли она существующей или разрабатываемой с нуля. Таким образом строится логическая функциональная спецификация — подробное описание того, что должна делать система, освобожденное насколько это возможно от рассмотрения путей реализации. Это дает проектировщику четкое представление о конечных результатах, которые следует достигать.  Рисунок А.4.6 - Компоненты логической модели Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. Для изображения DFD традиционно используются две различные нотации: Иодана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Далее при построении примеров будет использоваться нотация Иодана, все исключения будут предварительно оговариваться. Основные символы DFD Основные символы DFD изображены на рисунке А.4.7. Опишем их назначение. На диаграммах функциональные требования представляются с помощью процессов и хранилищ, связанных потоками данных. 1) Потоки данных (Flow) являются механизмами, использующимися для моделирования передачи информации (или даже физических компонентов) из одной части системы в другую. Потоки на диаграммах обычно изображаются именованными стрелками, ориентация которых указывает направление движения информации. Иногда информация может двигаться в одном направлении, обрабатываться и возвращаться назад в ее источник. Такая ситуация может моделироваться либо двумя различными потоками, либо одним - двунаправленным. 2) Назначение процесса (Process) состоит в преобразовании входных потоков в выходные в соответствии с действием, задаваемым именем процесса. Это имя должно содержать глагол в неопределенной форме с последующим дополнением (например, вычислить максимальную высоту). Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели. 3) Хранилище (накопитель, Store) данных позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет “срезы” потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения. Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, когда поток данных входит или выходит в/из хранилища, и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме. 4) Внешняя сущность (External entity) представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное, например, СКЛАД ТОВАРОВ. Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.  Рисунок А.4.7 - Основные символы диаграмм потоков данных Контекстная диаграмма и детализация процессов Декомпозиция DFD осуществляется на основе процессов: каждый процесс может раскрываться с помощью DFD нижнего уровня. Важную специфическую роль в модели играет специальный вид DFD — контекстная диаграмма, моделирующая систему наиболее общим образом. Контекстная диаграмма отражает интерфейс системы с внешним миром, а именно, информационные потоки между системой и внешними сущностями, с которыми она должна быть связана. Она идентифицирует эти внешние сущности, а также, как правило, единственный процесс, отражающий главную цель или природу системы насколько это возможно. Каждый проект должен иметь только одну контекстную диаграмму, при этом нет необходимости в нумерации ее единственного процесса. DFD первого уровня строится как декомпозиция процесса, который присутствует на контекстной диаграмме. Построенная диаграмма первого уровня также имеет множество процессов, которые в свою очередь могут быть декомпозированы в DFD нижнего уровня. Таким образом строится иерархия DFD с контекстной диаграммой в корне дерева. Этот процесс декомпозиции продолжается до тех пор, пока процессы могут быть эффективно описаны с помощью коротких (до одно страницы) миниспецификаций обработки (спецификаций процессов). При таком построении иерархии DFD каждый процесс более низкого уровня необходимо соотнести с процессом верхнего уровня. Обычно для этой цели используются структурированные номера процессов. Так, например, если мы детализируем процесс номер 2 на диаграмме первого уровня, раскрывая его с помощь DFD, содержащей три процесса, то их номера будут иметь следующий вид: 2.1, 2.2 и 2.3. При необходимости можно перейти на следующий уровень, т.е. для процесса 2.2 получим 2.2.1, 2.2.2 и т.д. Примеры DFD диаграммы представлены на рисунках А.4.8-4.10.  Рисунок А.4.8 – Пример 1 DFD диаграммы  Рисунок А.4.9 – Пример 2 DFD диаграммы  Рисунок А.4.10 – Пример DFD диаграммы для описания потоков данных при бухгалтерском учете на небольшом производственном предприятии А.5 Лабораторная работа 5 – 2ч. Разработка событийно-функиональных моделей бизнес-процессов предметной области ARIS А.5.1 Цель работы - изучение нотаций ARIS и их применение для построения моделей бизнес-процессов, потоков данных и организационных структур с использованием средств Case-систем MS Visio / ARIS. А.5.2 Предмет работы Предметом лабораторной работы является событийно-функциональное моделирование бизнес-процессов предметной области. А.5.3 Содержание лабораторной работы 1) Изучить нотации ARIS, а также возможности событийно-функционального моделирования бизнес-процессов в Case-системах MS Visio / ARIS. 2) Описать бизнес-процессы предметной области с помощью нотации ARIS eEPC (цепочки процесса, управляемого событиями). 3) Построить схему организационной структуры предприятия с помощью нотации ARIS Organizational Chart. 4) Построить схемы потоков данных между функциями бизнес-процессов с помощью нотации ARIS Information Flow. 5) Составить отчет по проделанной работе. 6) Защитить работу. А.5.4 Оборудование и технические средства Для выполнения работы необходимы технические и программные средства лаборатории «Электронный офис», доступ к сетевому серверу кафедры и Case-система MS Visio / ARIS. А.5.5 Порядок выполнение работы - Изучить нотации ARIS eEPC, ARIS Organizational Chart и ARIS Information Flow; - Изучить возможности Case-системы MS Visio / ARIS; - Построить модели бизнес-процессов предметной области, схемы потоков данных и схему организационной структуры предприятия (по теме индивидуального задания) с использованием Case-системы MS Visio / ARIS; - Оформить отчет и защитить работу. А.5.6 Требования к оформлению работы Отчет должен дополнять отчет о предыдущей работе и содержать разделы: 1) описание бизнес-процессов предметной области варианта задания. 2) построенные модели бизнес-процессов предметной области, схемы потоков данных и схему организационной структуры предприятия. А.5.7 Литература 1) Каменнова М.С., Громов А.И., Ферапонтов М.М., Шматалюк А.Е. Моделирование бизнеса. Методология ARIS А.5.8 Методические указания к выполнению работы Описание бизнес-процессов проводится с целью их дальнейшего анализа и реорганизации. Целью реорганизации может быть внедрение информационной системы, сокращение затрат на выпуск продукции, повышение качества обслуживания клиентов, создание должностных и рабочих инструкций при внедрении стандартов и т.д. Для каждой такой задачи существуют определенные параметры, определяющие набор критических знаний по бизнес-процессу. От задачи к задаче требования к описанию бизнес-процессов могут меняться. В общем случае модель бизнес-процесса должна давать ответы на следующие вопросы: 1. какие процедуры (функции, работы) необходимо выполнить для получения заданного конечного результата; 2. в какой последовательности выполняются эти процедуры; 3. какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес-процесса; 4. роли и ответственности - кто выполняет процедуры процесса; 5. какие входящие документы/информацию использует каждая процедура процесса; 6. какие исходящие документы/информацию генерирует процедура процесса; 7. какие ресурсы необходимы для выполнения каждой процедуры процесса; 8. какие документация/условия регламентируют выполнение процедуры; 9. какие параметры характеризуют выполнение процедур и процесса в целом; 10. существует ли последовательность процессов, минимизирующая затраты (в том числе стоимость, время и т.д.); 11. насколько процесс поддерживается/будет поддерживаться информационной системой. Описание бизнес-процесса формируется при помощи нотации и инструментальной среды, позволяющих отразить все указанные выше аспекты. Только в этом случае модель бизнес-процесса окажется полезной для предприятия, так как ее можно будет подвергнуть анализу и реорганизации. Нотация ARIS eEPC расшифровывается следующим образом: extended Event Driven Process Chain - расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В таблице А.5.1 приводятся основные используемые в рамках нотации объекты. Таблица А.5.1 – Основные объекты нотации eEPC
Помимо указанных в таблице А.5.1 основных объектов при построении диаграммы eEPC могут быть использованы многие другие объекты. Применение большого числа разных объектов, связанных различными типами связей, значительно увеличивает размер модели и делает ее плохо читаемой. Для понимания смысла нотации eEPC достаточно рассмотреть основные используемые типы объектов и связей. На рисунке А.5.1 представлена простейшая модель eEPC, описывающая фрагмент бизнес-процесса предприятия.  Рисунок А.5.1 – Пример модели в нотации eEPC На рисунке А.1 видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1, «активирует» или инициирует выполнение Функции 1. Функция 1 «создает» Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3. Нотация eEPC построена на определенных семантических правилах описания: 1. каждая функция должна быть инициирована событием и должна завершаться событием; 2. в каждую функцию не может входить более одной стрелки, «запускающей» выполнение функции, и выходить не более одной стрелки, описывающей завершение выполнения функции. На рисунке А.5.2 показано применение различных объектов ARIS при создании модели бизнес-процесса.  Рисунок А.5.2 - Пример применения объектов ARIS для описания бизнес-процессов Из рисунков А.5.1-А.5.2 видно, что бизнес-процесс в нотации eEPC представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длительность выполнения процедур в eEPC не может быть отражена визуально. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено одновременное выполнение двух задач. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например диаграммы Ганта в системе Microsoft Project. Таким образом, при помощи нотации eEPC ARIS можно описывать бизнес-процесс в виде потока последовательно выполняемых работ (процедур, функций). Примеры моделей, сформированных с использованием ARIS eEPC, показаны на рисунках А.5.3 и А.5.4.  Рисунок А.5.3 - Описание процесса обслуживания клиента процесса  Рисунок А.5.4 - Описание процесса анализа и согласования заявки клиента Нотация ARIS Organizational Chart является одной из основных нотаций ARIS и предназначена для построения схем организационной структуры предприятия. Как правило, эта модель строится в начале проекта по моделированию бизнес-процессов. В модели отражаются существующие подразделения предприятия в виде иерархической структуры, как показано на рисунке А.5.5.  Рисунок А.5.5 - Модель организационной структуры предприятия При построении сложных иерархических структур может быть использована декомпозиция, например структура подразделения может быть отражена на более детальной схеме. Нотация ARIS Information Flow является аналогом нотации DFD (см. ниже) и используется при построении схем потоков данных или документов между функциями бизнес-процессов предприятия, как показано на рисунке А.5.6.  Рисунок А.5.6 - Фрагмент диаграммы ARIS Information Flow В Таблице А.5.2 приведен краткий сравнительный анализ технологий IDEF и EPC с точки зрения их подходов к описанию бизнес-процессов. Таблица А.5.2 - Сравнительные характеристики технологий IDEF и EPC
Приведем пример одного конкретного процесса – «Выполнение заказа клиента», - описанного в форматах обеих технологий. На Рисунке А.5.7 представлена IDEF-диаграмма.  Рисунок А.5.7 - IDEF-диаграмма процесса «Выполнение заказа клиента» На Рисунке А.5.8 тот же самый процесс представлен в формате событийно-функциональной диаграммы EPC.  Рисунок А.5.8 - EPC-диаграмма процесса «Выполнение заказа клиента» Выделяют следующие виды моделей ARIS: 1) Функциональные модели (рисунок А.5.9). Процессы, преобразующие вход в выход, группируются в функциональную модель. Обозначения «функция», «процесс» и «операция» употребляются как синонимы. В связи с тем, что функции тесно связаны с целями поскольку они направлены на их достижение и подчиняются их управлению, цели также относят к функциональным моделям. В прикладных системах (ПС) описываются правила компьютерной обработки функции. Таким образом, ПС адекватно подходит под определение «функций»и также относится к функциональной модели.  Рисунок А.5.9 – Функциональная модель 2) Организационные модели (рисунок А.5.10). Класс организационных моделей служит для описания иерархической структуры организации. В организационных моделях группируются субъекты ответственности и средства, выполняющие работу над одним и тем же объектом. Именно поэтому сущность «человеческий ресурс», а также средства «компьютерная техника» относятся к организационной модели.  Рисунок А.5.10 – Организационная модель 3) Модель данных (рисунок А.5.11). Модели данных описывают информационный контекст (среду обработки данных), а также сообщения, активизирующие функции или активируемые ими. С именами данных можно также связать предварительные детали, касающиеся функции информационных систем как носителей данных. В моделях данных неявным образом фиксируются также объекты в виде информационных услуг. Однако в основном такие объекты описываются в моделях выходов.  Рисунок А.5.11 – Модель данных 4) Модели выходов (рисунок А.5.12). Модели выходов содержат все физические и нефизические входы и выходы, включая потоки денежных средств.  Рисунок А.5.12 – Модель выходов Приведем примеры (рисунки А.5.13-А.5.17).  Рисунок А.5.13 – Диаграмма взаимодействия в бизнес процессе «обработка заказа»  Рисунок А.5.14 – Поток функций в бизнес процессе «обработка заказа»  Рисунок А.5.15 – Поток выходов в бизнес процессе «обработка заказа»  Рисунок А.5.16 – Представление процесса «обработка заказа» в виде диаграммы действий и потоков объектов  Рисунок А.5.17 – Детальный фрагмент бизнес-процесса применительно к событию «изготовление изделия» |
