Методология SADT (Structured Analysis and Design Technique – методология структурного анализа и проектирования) представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели системы.
Начало разработки данной методологии было положено Дугласом Россом (США) в середине 60-х гг. ХХ в. С тех пор системные аналитики компании SofTech, Inc. улучшили SADT и использовали ее в решении широкого круга проблем. Программное обеспечение телефонных сетей, диагностика, долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, конфигурация компьютерных систем, обучение персонала, управление финансами и материально-техническим снабжением – вот некоторые из областей эффективного применения SADT. Широкий спектр областей указывает на универсальность и мощь методологии SADT. В программе «Интеграции компьютерных и промышленных технологий» (Integrated Computer Aided Manufacturing, ICAM) Министерства обороны США была признана полезность SADT. Это привело к публикации ее части в 1981 г., называемой IDEF0 (Icam DEFinition), в качестве федерального стандарта на разработку программного обеспечения. Под этим названием SADT стала применяться тысячами специалистов в военных и промышленных организациях . Последняя редакция стандарта IDEF0 была выпущена в декабре 1993г. Национальным институтом по стандартам и технологиям США (National Institute Standards and Technology, NIST).
Данная методология при описании функционального аспекта информационной системы конкурирует с методами, ориентированными на потоки данных (DFD). В отличие от них IDEF0 позволяет:
Описывать любые системы, а не только информационные (DFD предназначена для описания программного обеспечения);
Создать описание системы и ее внешнего окружения до определения окончательных требований к ней. Иными словами, с помощью данной методологии можно постепенно выстраивать и анализировать систему даже тогда, когда трудно еще представить ее воплощение.
Таким образом, IDEF0 может применяться на ранних этапах создания широкого круга систем. В то же время она может быть использована для анализа функций существующих систем и выработки решений по их улучшению.
Основу методологии IDEF0 составляет графический язык описания процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.
Модель (AS-IS, TO-BE или SHOULD-BE) может содержать 4 типа диаграмм [ , ]:
Контекстную диаграмму;
Диаграммы декомпозиции;
Диаграммы дерева узлов;
Диаграммы только для экспозиции (for exposition only, FEO).
Контекстная диаграмма (диаграмма верхнего уровня), являясь вершиной древовидной структуры диаграмм, показывает назначение системы (основную функцию) и ее взаимодействие с внешней средой. В каждой модели может быть только одна контекстная диаграмма. После описания основной функции выполняется функциональная декомпозиция, т. е. определяются функции, из которых состоит основная.
Далее функции делятся на подфункции и так до достижения требуемого уровня детализации исследуемой системы. Диаграммы, которые описывают каждый такой фрагмент системы, называются диаграммами декомпозиции . После каждого сеанса декомпозиции проводятся сеансы экспертизы – эксперты предметной области указывают на соответствие реальных процессов созданным диаграммам. Найденные несоответствия устраняются, после чего приступают к дальнейшей детализации процессов.
Диаграмма дерева узлов показывает иерархическую зависимость функций (работ), но не связи между ними. Их может быть несколько, поскольку дерево можно построить на произвольную глубину и с произвольного узла.
Диаграммы для экспозиции строятся для иллюстрации отдельных фрагментов модели с целью отображения альтернативной точки зрения на происходящие в системе процессы (например, с точки зрения руководства организации).
6.3. Элементы графической нотации IDEF0
Методология IDEF0 нашла широкое признание и применение, в первую очередь, благодаря простой графической нотации, используемой для построения модели. Главными компонентами модели являются диаграммы. На них отображаются функции системы в виде прямоугольников, а также связи между ними и внешней средой посредством стрелок. Использование всего лишь двух графических примитивов (прямоугольник и стрелка) позволяют быстро объяснить правила и принципы построения диаграмм IDEF0 людям, незнакомым с данной методологией. Это достоинство позволяет подключить и активизировать деятельность заказчика по описанию бизнес-процессов с использованием формального и наглядного графического языка.
На следующем рисунке показаны основные элементы графической нотации IDEF0 .
Рис. 6.1. Элементы графической нотации IDEF0
Прямоугольник представляет собой работу (процесс, деятельность, функцию или задачу) , которая имеет фиксированную цель и приводит к некоторому конечному результату. Имя работы должно выражать действие (например, «Изготовление детали», «Расчет допускаемых скоростей», «Формирование ведомости ЦДЛ № 3»).
Взаимодействие работ между собой и внешним миром описывается в виде стрелок. В IDEF0 различают 5 видов стрелок :
- вход (англ. input) – материал или информация, которые используются и преобразуются работой для получения результата (выхода). Вход отвечает на вопрос «Что подлежит обработке?». В качестве входа может быть как материальный объект (сырье, деталь, экзаменационный билет), так и не имеющий четких физических контуров (запрос к БД, вопрос преподавателя). Допускается, что работа может не иметь ни одной стрелки входа. Стрелки входа всегда рисуются входящими в левую грань работы;
- управление (англ. control) – управляющие, регламентирующие и нормативные данные, которыми руководствуется работа. Управление отвечает на вопрос «В соответствии с чем выполняется работа?». Управление влияет на работу, но не преобразуется ей, т.е. выступает в качестве ограничения. В качестве управления могут быть правила, стандарты, нормативы, расценки, устные указания. Стрелки управления рисуются входящими в верхнюю грань работы. Если при построении диаграммы возникает вопрос, как правильно нарисовать стрелку сверху или слева, то рекомендуется ее рисовать как вход (стрелка слева);
- выход (англ. output) – материал или информация, которые представляют результат выполнения работы. Выход отвечает на вопрос «Что является результатом работы?». В качестве выхода может быть как материальный объект (деталь, автомобиль, платежные документы, ведомость), так и нематериальный (выборка данных из БД, ответ на вопрос, устное указание). Стрелки выхода рисуются исходящими из правой грани работы;
- механизм (англ. mechanism) – ресурсы, которые выполняют работу. Механизм отвечает на вопрос «Кто выполняет работу или посредством чего?». В качестве механизма могут быть персонал предприятия, студент, станок, оборудование, программа. Стрелки механизма рисуются входящими в нижнюю грань работы;
- вызов (англ. call) – стрелка указывает, что некоторая часть работы выполняется за пределами рассматриваемого блока. Стрелки выхода рисуются исходящими из нижней грани работы.
6.4. Типы связей между работами
После определения состава функций и взаимосвязей между ними, возникает вопрос о правильной их композиции (объединении) в модули (подсистемы). При этом подразумевается, что каждая отдельная функция должна решать одну, строго определенную задачу. В противном случае необходима дальнейшая декомпозиция или разделение функций.
При объединении функций в подсистемы необходимо стремиться, чтобы внутренняя связность (между функциями внутри модуля) была как можно сильнее, а внешняя (между функциями, входящими в разные модули), как можно слабее. Опираясь на семантику связей методологии , введем классификацию связей между функциями (работами). Данная классификация является расширением . Типы связей приводятся в порядке уменьшения их значимости (силы связывания). В приводимых примерах утолщенными линиями выделяются функции, между которыми имеется рассматриваемый тип связи.
1. Иерархическая связь (связь «часть» – «целое») имеет место между функцией и подфункциями, из которых она состоит.
Рис. 6.2. Иерархическая связь
2. Регламентирующая (управляющая, подчиненная) связь отражает зависимость одной функции от другой, когда выход одной работы направляется на управление другой. Функцию, из которой выходит управление, следует считать регламентирующей или управляющей, а в которую входит – подчиненной. Различают прямую связь по управлению , когда управление передается с вышестоящей работы на нижестоящую (рис. 6.3), и обратную связь по управлению , когда управление передается от нижестоящей к вышестоящей (рис. 6.4).
3. Функциональная (технологическая) связь имеет место, когда выход одной функции служит входными данными для следующей функции. С точки зрения потока материальных объектов данная связь показывает технологию (последовательность работ) обработки этих объектов. Различают прямую связь по входу , когда выход передается с вышестоящей работы на нижестоящую (рис. 6.5), и обратную связь по входу , когда выход передается с нижестоящей к вышестоящей (рис.6.6).
 |
 |
| Рис. 6.5. Прямая связь по входу | Рис. 6.6. Обратная связь по входу |
4. Потребительская связь имеет место, когда выход одной функции служит механизмом для следующей функции. Таким образом, одна функция потребляет ресурсы, вырабатываемые другой.
Рис. 6.7. Потребительская связь
5. Логическая связь наблюдается между логически однородными функциями. Такие функции, как правило, выполняют одну и ту же работу, но разными (альтернативными) способами или, используя разные исходные данные (материалы).
Рис. 6.8. Логическая связь
6. Коллегиальная (методическая) связь имеет место между функциями, алгоритм работы которых определяется одним и тем же управлением. Аналогом такой связи является совместная работа сотрудников одного отдела (коллег), подчиняющихся начальнику, который отдает указания и приказы (управляющие сигналы). Такая связь также возникает, когда алгоритмы работы этих функций определяются одним и тем же методическим обеспечением (СНИП, ГОСТ, официальными нормативными материалами и т. д.), служащим в качестве управления.
Рис. 6.9. Методическая связь
7. Ресурсная связь возникает между функциями, использующими для своей работы одни и те же ресурсы. Ресурсно-зависимые функции, как правило, не могут выполняться одновременно.
Рис. 6.10. Ресурсная связь
8. Информационная связь имеет место между функциями, использующими в качестве входных данных одну и ту же информацию.
Рис. 6.11. Информационная связь
9. Временная связь возникает между функциями, которые должны выполняться одновременно до или одновременно после другой функции.
Кроме указанных на рисунке случаев, эта связь имеет место также между другими сочетаниями управления, входа и механизма, поступающими в одну функцию.
Рис. 6.12. Временная связь
10. Случайная связь возникает, когда конкретная связь между функциями мала или полностью отсутствует.
Рис. 6.13. Случайная связь
Из приведенных выше типов связей наиболее сильной является иерархическая связь, которая, по сути, и определяет объединение функций в модули (подсистемы). Несколько слабее являются регламентирующие, функциональные и потребительские связи. Функции с этими связями обычно реализуются в одной подсистеме. Логические, коллегиальные, ресурсные и информационные связи одни из самых слабых. Функции, обладающие ими, как правило, реализуют в разных подсистемах, за исключением логически однородных функций (функций, связанных логической связью). Временная связь свидетельствует о слабой зависимости функций друг от друга и требует их реализации в отдельных модулях.
Таким образом, при объединении функций в модули наиболее желательными являются первые пять видов связей. Функции, связанные последними пятью связями, лучше реализовывать в отдельных модулях.
В IDEF0 существуют соглашения (правила и рекомендации) по созданию диаграмм, которые призваны облегчить чтение и экспертизу модели [ , ]. Некоторые из этих правил CASE-средства поддерживают автоматически, выполнение других следует обеспечить вручную.
1. Перед построением модели необходимо определиться, какая модель (модели) системы будет построена. Это подразумевает определение ее типа AS-IS, TO-BE или SHOULD-BE, а также определения позиции, с точки зрения которой строится модель. «Точку зрения» лучше всего представлять себе как место (позицию) человека или объекта, в которое надо встать, чтобы увидеть систему в действии. Например, при построении модели работы продуктового магазина можно среди возможных претендентов, с точки зрения которых рассматривается система, выбрать продавца, кассира, бухгалтера или директора. Обычно выбирается одна точка зрения, наиболее полно охватывающая все нюансы работы системы, и при необходимости для некоторых диаграмм декомпозиции строятся диаграммы FEO, отображающие альтернативную точку зрения.
2. На контекстной диаграмме отображается один блок, показывающий назначение системы. Для него рекомендуется отображать по 2–4 стрелки, входящие и выходящие с каждой стороны.
3. Количество блоков на диаграммах декомпозиции рекомендуется в пределах 3–6. Если на диаграмме декомпозиции два блока, то она, как правило, не имеет смысла. При наличии большого количества блоков диаграмма становится перенасыщенной и трудно читаемой.
4. Блоки на диаграмме декомпозиции следует располагать слева направо и сверху вниз. Такое расположение позволяет более четко отразить логику и последовательность выполнения работ. Кроме этого маршруты стрелок будут менее запутанными и иметь минимальное количество пересечений.
5. Отсутствие у функции одновременно стрелок управления и входа не допускается. Это означает, что запуск данной функции не контролируется и может произойти в любой произвольный момент времени либо вообще никогда.
Рис. 6.14. Функция без управления и входа
Блок с наличием только управления можно рассматривать как вызов в программе функции (процедуры) без параметров. Если у блока имеется вход, то он эквивалентен вызову в программе функции с параметрами. Таким образом, блок без управления и входа эквивалентен функции, которая в программе ни разу не вызывается на исполнение.
На рис. 6.7–6.12, отображающих фрагменты диаграмм IDEF0, встречаются блоки без входа и управления. Это не стоит рассматривать как ошибку, так как подразумевается, что одна из этих стрелок должна быть.
6. У каждого блока должен быть как минимум один выход.
Рис. 6.15. Функция без выхода
Работы без результата не имеют смысла и не должны моделироваться. Исключение составляют работы, отображаемые в модели AS-IS. Их наличие свидетельствует о неэффективности и несовершенстве технологических процессов. В модели TO-BE эти работы должны отсутствовать.
7. При построении диаграмм следует минимизировать число пересечений, петель и поворотов стрелок.
8. Обратные связи и итерации (циклические действия) могут быть изображены с помощью обратных дуг. Обратные связи по входу рисуются «нижней» петлей, обратная связь по управлению – «верхней» (см. рис. 6.4 и 6.6).
9. Каждый блок и каждая стрелка на диаграммах должны обязательно иметь имя. Допускается использовать ветвление (декомпозицию) или слияние (композицию) стрелок. Это связано с тем, что одни и те же данные или объекты, порожденные одной работой, могут использоваться сразу в нескольких других работах. И наоборот, одинаковые или однородные данные и объекты, порожденные разными работами, могут использоваться в одном месте.
Рис. 6.16. Ветвление стрелок
При этом допускается задание различным ветвям стрелки уточняющих имен после разветвления (до слияния). Если какая-либо ветвь после ветвления не именована, то считается, что ее имя соответствует имени стрелки, записанному до ветвления.
Так, на рис. 6.16 управления, входящие в блоки «Изготовление деталей» и «Сборка изделия», имеют уточняющие значения и являются составной частью более общего управления «Чертежи». Для работы блока «Контроль качества» используются все чертежи.
На диаграмме не допускается рисовать стрелки, когда до и после ветвления они не именованы. На рис. 6.17 стрелка, входящая в блок «Формирование типовых ведомостей», не имеет имени до и после ветвления, что является ошибкой.
Рис. 6.17. Неправильное именование стрелок
10. При построении диаграмм для лучшей их читаемости может использоваться механизм туннелирования стрелок. Например, чтобы не загромождать лишними деталями диаграммы верхних уровней (родительские), на диаграммах декомпозиции начало дуги помещают в тоннель.
Рис. 6.18. Туннелирование стрелок
В данном примере при построении модели проведения новогоднего утренника механизм «два топора» не будет отображаться на диаграммах верхних уровней, при чтении которых может возникнуть справедливый вопрос: «А зачем нужны два топора на новогоднем утреннике?».
Аналогичным образом можно выполнять туннелирование с обратной целью – недопущения отображения стрелки на диаграммах низших уровней. В этом случае круглые скобки ставятся на конце стрелки. На контекстной диаграмме (см. рис. 6.21) затуннелирован механизм «Инженер службы пути», входящий в блок «Определение допускаемых скоростей». Такое решение принято, так как инженер непосредственно участвует во всех работах, отображенных на диаграмме декомпозиции этого блока (см. рис. 6.22). Чтобы не показывать эту связь и не загромождать диаграмму декомпозиции, стрелка была затуннелирована.
11. Все стрелки, входящие и выходящие из блока, при построении для него диаграммы декомпозиции должны быть отображены на ней. Исключение составляют затуннелированные стрелки. Имена стрелок, перенесенных на диаграмму декомпозиции, должны совпадать с именами, указанными на диаграмме верхнего уровня.
12. Если две стрелки проходят параллельно (начинаются из одной и той же грани одной работы и заканчиваются на одной и той же грани другой работы), то по возможности следует их объединить и называть единым термином.
Рис. 6.19. Объединение связей
13. Каждый блок на диаграммах должен иметь свой номер. Для того чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Блок на диаграмме верхнего уровня обозначается 0, блоки на диаграммах второго уровня – цифрами от 1 до 9 (1, 2, …, 9), блоки на третьем уровне – двумя цифрами, первая из которых указывает на номер детализируемого блока с родительской диаграммы, а вторая номер блока по порядку на текущей диаграмме (11, 12, 25, 63) и т. д. Контекстная диаграмма имеет обозначение «А – 0», диаграмма декомпозиции первого уровня – «А0», диаграммы декомпозиции следующих уровней – состоят из буквы «А», за которой следует номер декомпозируемого блока (например, «А11», «А12», «А25», «А63»). На рисунке показано типичное дерево диаграмм (диаграмма дерева узлов) с нумерацией.
Рис. 6.20. Иерархия диаграмм
В современных CASE-средствах механизмы нумерации работ поддерживается автоматически. CASE-средства обеспечивают также автоматическое построение диаграмм дерева узлов, которые содержат только иерархические связи. Вершиной такой диаграммы может быть любой узел (блок), и она может быть построена на любую глубину.
6.6. Пример построения модели IDEF0 для системы определения допускаемых скоростей
Расчет допускаемых скоростей движения поездов является трудоемкой инженерной задачей. При проходе поездом какого-либо участка фактическая скорость движения поезда не должна превышать предельно допускаемую. Эта предельно допускаемая скорость устанавливается исходя из опыта эксплуатации и специально проводимых испытаний по динамике движения и воздействию на путь подвижного состава. Непревышение этой скорости гарантирует безопасность движения поездов, комфортабельные условия езды пассажиров и т. п. Они определяются в зависимости от типа подвижного состава (марки локомотива и типа вагонов), параметров верхнего строения пути (типа рельсов, балласта, эпюры шпал) и плана (радиуса кривых, переходных кривых, возвышения наружного рельса и т. д.). Как правило, для установления допускаемых скоростей необходимо определить не менее двух (на прямых) и пяти (в кривых) скоростей, из которых и выбирается окончательная допускаемая скорость, как наименьшая из всех рассчитанных. Расчет этих скоростей регламентируются Приказом МПС России № 41 от 12 ноября 2001 г. «Нормы допускаемых скоростей движения подвижного состава по железнодорожным путям колеи 1520 (1524) мм Федерального железнодорожного транспорта».
Как было отмечено, построение модели IDEF0 начинается с представления всей системы в виде простейшей компоненты (контекстной диаграммы). Данная диаграмма отображает назначение (основную функцию) системы и необходимые входные и выходные данные, управляющую и регламентирующую информацию, а также механизмы.
Контекстная диаграмма для задачи определения допускаемых скоростей показана на рис.6.21. Для построения модели использовался продукт BPwin 4.0 фирмы Computer Associates.
Рис. 6.21. Контекстная диаграмма системы определения допускаемых скоростей (методология IDEF0)
В качестве исходной информации , на основе которой выполняется определение допускаемых скоростей, используются:
Данные проекта новой линии или проекта реконструкции (содержат всю необходимую информацию для реализации проекта, а именно километраж, оси раздельных пунктов, план линии и др.);
Подробный продольный профиль (содержит информацию, аналогичную рассмотренной выше);
Паспорт дистанции пути (содержит информацию, аналогичную рассмотренной выше, а также сведения о верхнем строении пути (ВСП));
Данные о результатах съемки плана пути вагоном-путеизмерителем;
Ведомость возвышений наружного рельса в кривых (содержит информацию о плане пути).
Часть исходной информации может быть взята из разных источников. В частности сведения о плане (параметрах кривых) могут быть взяты из проекта новой линии или проекта реконструкции, подробного продольного профиля, паспорта дистанции пути и т.д.
Управляющими данными являются:
Указание начальника службы пути дороги или Департамента пути и сооружений ОАО «РЖД» на расчет;
Приказ № 41, содержащий нормативно-справочную информацию, порядок и формулы определения допускаемых скоростей;
Сведения о текущем или планируемом поездопотоке (данные о марках обращающихся локомотивов и типах используемых вагонов);
Сведения о планируемых ремонтах пути, реконструкции и переустройстве сооружений и устройств.
Результатом работы системы должны быть:
Ведомости допускаемых скоростей, содержащие все типы рассчитанных скоростей и позволяющие установить причину их ограничения;
Ведомости Приказа начальника дороги об установлении допускаемых скоростей на перегонах и раздельных пунктах (Приказ «Н») согласно принятой на дороге форме. Утвержденный Приказ «Н» официально закрепляет допускаемые скорости движения поездов;
Типовые формы № 1, 1а и 2, содержащие планируемые допускаемые скорости для разработки графика движения поездов.
Скорости, содержащиеся в Приказе «Н» и типовых формах, могут отличаться от рассчитанных и показываемых в ведомостях допускаемых скоростей. Это связано с тем, что в них отражают ограничения скорости не только по конструкции подвижного состава, параметров ВСП и кривых, но и по состоянию устройств и сооружений (деформация земляного полотна, перекос опор контактной сети и т. д.). Кроме того, они корректируются с учетом планируемых ремонтов пути, реконструкции и переустройства сооружений и устройств и т.д.
После построения контекстная диаграмма детализируется с помощью диаграммы декомпозиции первого уровня. На этой диаграмме отображаются функции системы, которые должны быть реализованы в рамках основной функции. Диаграмма, для которой выполнена декомпозиция, по отношению к детализирующим ее диаграммам называется родительской . Диаграмма декомпозиции по отношению к родительской называется дочерней .
Диаграмма декомпозиции первого уровня для рассматриваемой задачи приведена на рис.6.22. Как правило, при построении диаграммы декомпозиции исходная функция (декомпозируемая) разбивается на 3–8 подфункций (блоков). При этом блоки на диаграмме декомпозиции рекомендуется располагать слева направо сверху вниз, чтобы лучше была видна последовательность и логика взаимодействия подфункций.
Рис. 6.22. Диаграмма декомпозиции первого уровня (методология IDEF0)
Очередность выполнения функций для решения рассматриваемой задачи следующая:
Ввод и корректировка нормативно-справочной информации и данных по участкам дороги (блоки 1 и 2);
Подготовка задания на расчет (блок 3). В нем указывается, для какого участка и пути, а также марки локомотива и типа вагонов следует выполнить расчет;
Расчет допускаемых скоростей в соответствии с порядком и формулами, указанными в Приказе № 41 (блок 4). В качестве исходной информации выступают данные по пути участка (план, верхнее строение пути и т. д.) и нормативы, выбираемые на основании задания на расчет;
Формирование ведомостей допускаемых скоростей (блок 5). На базе результатов расчета создаются несколько видов выходных документов, которые, с одной стороны, позволяют выявить причину ограничений скорости, с другой стороны, выступают в качестве основы для подготовки регламентированных документов;
Формирование и подготовка проекта Приказа «Н» и типовых ведомостей (блоки 6 и 7).
После построения диаграммы декомпозиции первого уровня для указанных на ней функций строятся отдельные диаграммы (диаграммы декомпозиции второго уровня). Затем процесс декомпозиции (построения диаграмм) продолжается до тех пор, пока дальнейшая детализация функций не теряет смысла. Для каждой атомарной функции, описывающей элементарную операцию (т. е. функции, не имеющей диаграмму декомпозиции), составляется подробная спецификация, определяющая ее особенности и алгоритм реализации. В качестве дополнения к спецификации могут использоваться блок-схемы алгоритмов. Таким образом, процесс функционального моделирования заключается в постепенном выстраивании иерархии функций.
6.7. ICOM-коды
Стрелки, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются теми же самыми, что и стрелки, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы (см. рис. и ). Как следствие этого, границы функции верхнего уровня – это то же самое, что и границы диаграммы декомпозиции.
ICOM-коды (аббревиатура от Input, Control, Output и Mechanism) предназначены для идентификации граничных стрелок. ICOM-код содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер (см. рис.).
3. Постановка задачи разработки информационной системы
4. Функциональная модель бизнес-процесса
4.1 Моделирование в IDEF0
4.2 Диаграммы информационной системы “Видеопрокат” в нотации IDEF0
4.3 Моделирование в DFD
4.4 Диаграммы информационной системы “Видеопрокат” в нотации DFD
5. Модели данных информационной системы
5.2 Концептуальная модель данных
5.3 Логическая модель данных
5.4 Физическая модель данных
6. Проектирование с использованием UML
6.1. Диаграмма последовательности действий
7. Заключение
8. Список литературы
1. Введение
В видеопрокате хранится огромное количество кассет, услугами видеопроката пользуются довольно много людей. Для обеспечения оперативности ведения информации о кассетах и клиентах необходима автоматизированная информационная система, основанная на функциональное моделирование, моделирование данных. Использование информационной системы для работы с базой данных существенно сократит время обслуживания клиентов и время работы с видеопрокатот по систематизации информации о кассетах, по сбору информации о клиентах и многие другие задачи.
В видеопрокате необходимо хранить разнообразную информацию о кассетах, чтобы оперативно можно было определить информацию о наличии в видеопрокате некоторой кассеты, дисков по определенному жанру. Необходимо учесть, что кассеты могут иметь одинаковое название, поэтому кассетам нужно присваивать некоторые уникальные шифры.
Информация о клиентах должна быть полной и достаточной для определения клиента, фамилия, имя, его место жительство и т.д. Необходимо учесть, что среди клиентов могут быть однофамильцы, поэтому у каждого клиента должен быть уникальный шифр, в данном случае в качестве шифра используется идентификационный номер (ID номер) клиента.
Целью данного курсового проекта является разработка информационной системы для автоматизации работы видеопроката. Внедрение этой информационный системы значительно облегчает и усовершенствует ведение данных об имеющихся фильмах и клиентах.
Задачами курсового проекта являются:
Разработка видеопроката в нотации IDEF0 инотации DFD
Моделирование данных видеопроката в IDEF1X
Проектирования с использованием UML
2. Инструменты разработки информационной системы
Для проведения анализа и реорганизации бизнес-процессов Logic Works предлагает CASE–средство верхнего уровня – BPwin, поддерживающее методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей – того, к чему нужно стремиться (модель TO-BE). Методология IDEF0 предписывает построение иерархической системы диаграмм – единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция – система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы, каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес-процессе. Такая технология создания модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования. Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, BPwin позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. Нотация DFD включает такие понятия, как внешняя ссылка и хранилище данных, что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота. Методология IDEF3 включает элемент "перекресток", что позволяет описать логику взаимодействия компонентов системы. Bpwin основан на методологии IDEF.
Для BPwin 4.0 нужно отметить существенно улучшенный интерфейс, если сравнивать с предыдущими версиями. Нет проблем со шрифтами, с изменением размеров объектов на диаграмме, что раньше в некоторых случаях могло привести к тому, что диаграмма “плыла”. Кроме проводника модели, улучшены также и словари объектов. Теперь все словарные объекты располагаются в радующих глаз аккуратных таблицах. Вид этих таблиц можно настраивать так, как удобно разработчику, содержание словарей можно печатать, экспортировать, импортировать, также можно генерировать отчеты по содержанию словарей. Можно поддерживать словари для следующих объектов: работы, стрелки, хранилища данных, внешние ссылки, перекрестки, объекты ссылок, атрибуты, центры затрат, сущности, ресурсы, роли, группы ролей, свойства, определяемые пользователем (UDP).
Данный продукт тесно интегрирован с инструментальным средством для моделирования БД – ERWin.
Благодаря интеграции и поддержке совместной работы над одними и теми же моделями, BPwin не имеет аналогов для реализации крупных проектов.
BPwin имеет мощный инструмент отчетов Report Template Builder, с помощью которого можно легко и быстро создавать различные отчеты о разработанной модели.
Официальная версия программы относительно недешева
Также есть ряд качеств, которые могут оказаться как преимуществом, так и недостатком инструмента моделирования.
Например, ограничение количества моделей на диаграмме, присущее BPWin, с одной стороны способствует наглядности модели, с другой – налагает неудобства при описании сложных процессов.
Пакет ERWin - средство, используемое при моделировании и создании баз данных произвольной сложности на основе диаграмм «сущность – связь». Продукт компании Computer Associates. ERWin это средство концептуального моделирования БД. Используется при моделировании и создании баз данных произвольной сложности на основе диаграмм «сущность − связь». В настоящее время ERWin является наиболее популярным пакетом моделирования данных благодаря поддержке широкого спектра СУБД самых различных классов.
Возможности ERWin:
поддерживает методологию структурного моделирования SADT и следующие нотации: стандартную нотацию IDEF1x для ER-диаграмм моделей данных, нотацию IE и специальную нотацию, предназначенную для проектирования хранилищ данных - Dimensional;
поддерживается прямое (создание БД на основе модели) и обратное (генерация модели по имеющейся базе данных) проектирование для 20 типов СУБД: настольные, реляционные и специализированные СУБД, предназначенные для создания хранилищ данных;
интегрирован линейкой продуктов Computer Associates для поддержки всех стадий разработки ИС, CASE-средствами Oracle Designer, Rational Rose, средствами разработки и др.;
позволяет повторно использовать компоненты созданных ранее моделей, а также использовать наработки других разработчиков;
возможна совместная работа группы проектировщиков с одними и теми же моделями (с помощью AllFusion Model Manager);
позволяет переносить структуру БД (не сами данные!) из СУБД одного типа СУБД в другой;
позволяет документировать структуру БД.
Достоинства:
распространенность;
техподдержка;
ошибки программы известны и описаны.
Недостатки:
нельзя создавать стандартные операции;
репрезентативные свойства низки;
отсутствие стандартных объектов для описания бизнес процессов;
довольно узкие возможности для проведения экономического анализа;
жесткая методология;
требуется дополнительное обучение в понимании самой методологии;
не очень удачные генераторы проектной документации;
официальная версия программы относительно недешева.
Цель - создание контекстной диаграммы функциональной модели деятельности автосалона с помощью All Fusion PM.
Технология работы
Рис. 1
Рис. 2 Отчет по модели автосалона
Цель - научиться создавать диаграммы декомпозиции функциональной модели деятельности салона в стандарте IDEF0 с помощью All Fusion PM 4.0.
В IDEF0 существуют соглашения по рисованию диаграмм, которые призваны облегчить чтение и экспертизу модели. Некоторые из этих правил All Fusion PM поддерживает автоматически, выполнение других следует обеспечить вручную.
Технология работы
1. Выберите кнопку перехода на нижний уровень в палитре инструментов и в окне Activity Box Count установите число работ на диаграмме нижнего уровня - 3 и нажмите ОК.
Автоматически будет создана диаграмма декомпозиции. Правой кнопкой мыши щелкните по работе, выберите Name и внесите имя работы. Повторите операцию для всех трех работ. Затем внесите определение, статус и источник для каждой работы.
Рис. 3 Диаграмма декомпозиции IDEF0 первого уровня
Жизненный цикл разработки информационной системы
В процессе создания информационная система проходит несколько стадий, начиная от ее задумки и заканчивая внедрением. В рамках курса «Базы данных и информационные технологии» наибольший интерес представляет первые два - проектирование и разработка. Давайте разберемся, что стоит за каждым из пунктов, перечисленных на слайде.
Стоит заметить, что разработка может затрагивать как весь продукт, так и происходить итеративно - добавляя с каждым этапом новые функции или модули к существующему ядру системы. При этом все этапы с первого по пятый повторяются для каждой из иттераций.
Одним из важных понятий при разработке программного обеспечения является «концептуальная модель».
Концептуальная модель - это абстрактная модель, определяющая структуру моделируемой системы, свойства её элементов и причинно-следственные связи, присущие системе и существенные для достижения цели моделирования.
При этом «концептуальная модель» это:
Одной из распространенных методологий построения концептуальных моделей является IDEF0.
Методология IDEF0 описывает процессы движения и обработки информации звеньями моделируемого объекта с точки зрения их функционального назначения. Например, отделами предприятия.
IDEF0 - это подмножество SADT (Structured Analisys and Design Technique). Методология SADT разрабатывалась Дугласом Т. Россом в 1969-1973 годах и изначально применялась для проектирования систем общего назначения. В данной методологии ключевым является в какую из сторон процесса направлен поток управления.
Поясним суть методологии IDEF0 на примере производства товара. Процесс производства условно изображен на слайде.
Здесь слева представлены ингредиенты, которые используют для производства товара, сверху - инструкции, регламентирующие процесс производства, внизу инструменты, которые используют в процессе производства, а справа - готовый товар.
В терминах IDEF0 моделируемое информационной системой производство представляется блоком и дугами, как показано на слайде.
В блоке отражена главная функция моделируемого информационной системой производства, дуги - множество объектов, участвующих и являющихся результатом производства: информация или действия. Место соединения дуги с блоком определяет тип интерфейса.
Правила интерпретации модели:
Каждый блок IDEF0-диаграммы может быть представлен несколькими блоками, соединенными интерфейсными дугами, на диаграмме следующего уровня. Эти блоки представляют подфункции (подмодули) исходной функции. Каждый из подмодулей может быть декомпозирован аналогичным образом. Число уровней не ограничивается, однако рекомендуют на одной диаграмме использовать от трех до шести блоков.
Анализ объекта на основе построения его IDEF0-модели является этапом, который должен предварять разработку информационной системы по целому ряду причин. Во-первых, при ознакомлении с объектом строят модель "КАК ЕСТЬ". Такая модель фиксирует бизнес процессы и используемые ими информационные потоки. Во-вторых, функциональная модель "КАК ЕСТЬ" позволяет увидеть информационно перегруженные бизнес процессы - "узкие" места обследуемого объекта. В-третьих, на основании модель "КАК ЕСТЬ" можно построить модель "КАК БУДЕТ". То есть предложить более совершенную структуру организации объекта. Но это уже вопросы реинжиниринга и мы их не будем касаться. Можно только отметить, что реинжиниринг подчеркивает важную роль информационных технологий в жизни общества. В-четвертых, в процессе построения модели "КАК ЕСТЬ" выявляются бизнес-правила - положения, которые регламентируют процесс функционирования моделируемого объекта. Например, представленный на слайде фрагмент функциональной модели должен быть зафиксирован бизнес-правилом: "служба снабжения обязана определять потребности в материалах для производства готовой продукции только на основании плана выпуска".
И последнее. Очевидно, что IDEF0-модель - это лучший способ совместно с заказчиком разработать модель функционирования его фирмы. Дело в том, что такая нотация (описание с помощью прямоугольников и стрелок) понятна и заказчику и исполнителю.
После этапа моделирования исследуемого объекта наступает этап физической реализации этой модели в виде информационной системы. И тут возникает естественный вопрос об адекватности отображения. Другими словами, как представить в информационной системе, например, управляющие потоки. Хотя понятно, например, что потоки данных в информационной системе будут реализованы как хранилища данных, то есть файлы.
Тот факт, что IDEF0-модель не разделяет потоки данных на материальные, информационные и управляющие приводит разработчиков к необходимости использовать диаграммы потоков данных (Data Flow Diagrams - DFD ). Это можно делать после составления IDEF0-модели, либо вместо этого в зависимости от сложности моделируемого объекта или предпочтений исполнителя.
Основы методологии построения диаграмм потоков данных DFD были описаны в 1979 году C. Gane и T. Sarson в книге "Structured Systems Analysis".
Ее назначение - ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда.
Методология DFD оперирует 4 типами объектов. Их графическое представление представлено на слайде. Обратите внимание, что существует несколько нотаций в рамках методологии DFD. Графическое представление элементов в них несколько отличается. Но внутренне содержание остается неизменным. Давайте разберемся с типами объектов, которые используются в рамках DFD.
Аналогично IDEF0, для удобства DF-диаграммы разделяют на уровни.
При этом на нулевом уровне отображаются только один процесс (который представляет всю моделируемую ИС), внешние сущности и потоки данных между ними. Задача этого уровня установить - какие потоки данных передаются в/из системы. Хранилища данных при этом не моделируются.
На 1 уровне выделяются основные компоненты системы. С 0-го уровня сюда переносятся все потоки данных. Диаграмма дополняется потоками данных внутри системы и хранилищами данных.
У каждого процесса, хранилища данных, внешней сущности и потока данных должно быть имя.
На DFD диаграмме не отображаются точки начала и окончания, решения(if) и циклы.
Внешние сущности не могут быть связаны потоками информации (это выходит за рамки моделируемой системы)
Внешние сущности не могут напрямую обращаться к хранилищам данных
Хранилище данных не может напрямую обращаться к другому хранилищу. Между ними должен быть процесс.
Избегайте хранилищ в которые только записывается или только читается информация. Нужна ли в системе информация, которая не используется?
На диаграмме не должно быть несоединенных объектов. Если такой объект появляется, то вы либо не учли все потоки данных, либо объект можно безболезненно удалить.
Избегайте процессов которые не имеют входящих потоков информации.
Избегайте процессов которые не имеют исходящих потоков информации.
Давайте построим DF-диаграмму для информационной системы риэлтерской конторы.
Фирма функционирует следующим образом:
Строя DF-диаграмму нулевого уровня необходимо отобразить все основные хранилища данных и все внешние сущности. Диаграмма должна быть построена так, чтобы она отвечала на основные вопросы: "Как работает моделируемый объект?", "Откуда поступают эти данные?", "Какой процесс использует эти данные?" и т.д.
При построении DFD-диаграмм нижних уровней необходимо соблюдать принцип "вертикального балансирования" - ввод или вывод данных не может быть произведен, если этого не делает родитель.
Приведем пример DFD-диаграммы некоторой риелтерской конторы, которая специализируется на заключении договоров аренды жилых помещений.
Диаграмма построена в предположении, что круг клиентов конторы относительно стабилен.
Как видно из контекстной диаграммы первого уровня внешние сущности - это потенциальные Арендатор и Владелец . Поскольку элементами контекстной диаграммы являются одноименные хранилища: Арендатор и Владелец , то можно усомниться в правильности определения внешних сущностей. Но, так как потенциальные Арендатор и Владелец могут быть арендатором и владельцем лишь после заключения договора, то конфликтов с определением здесь нет. Другими словами, это разные сущности.
Для составления договора используют данные хранилищ Арендатор и Владелец . Эти хранилища необходимы по причине того, что круг клиентов риэлтерской конторы относительно стабилен. Не подвержен значительным изменениям и перечень арендуемых объектов недвижимости, что отражает на контекстной диаграмме хранилище Недвижимость .
Наличие на диаграмме процесса "Подготовить договор аренды" - это следствие того, что "черновик" договора аренды готовит клерк, а менеджер принимает решение о заключении договора. Это повышает эффективность работы фирмы в целом.
В результате анализа моделируемого информационной системой объекта на основе построения IDEF0 и DFD-диаграмм:
Определяют главную функцию проектируемой системы. Например, "сопровождать аренду недвижимости".
Описывают происходящие в моделируемом объекте бизнес процессы.
Например, так:
Определяют обрабатываемые бизнес процессами информационными потоки . Например, так: "отправка договора менеджеру".
Разрабатывают концептуальную модель системы, которая представляет собой описание моделируемого объекта, присущих ему бизнес-правил и потоков и хранилищ данных .
Как видим назначение концептуальной модели объекта:
Подводя итог, можно отметить, что построение концептуальной модели системы в соответствии с IDEF0- или DFD-методологией позволяет прийти к общему с заказчиком представлению о проектируемой информационной системе.
Диаграмма прецедентов позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций .
Каждая такая диаграмма или, как ее обычно называют, каждый Use case - это описание сценария поведения, которому следуют действующие лица (Actors).
Данный тип диаграмм используется при описании бизнес процессов автоматизируемой предметной области, определении требований к будущей программной системе. Отражает объекты, как системы, так и предметной области и задачи, выполняемые ими.
Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть "железа", а не программ. В прямом переводе с английского Deployment означает "развертывание", но термин "топология" точнее отражает сущность этого типа диаграмм.
Для каждой модели создается только одна такая диаграмма, отображающая процессоры (Processor), устройства (Device) и их соединения.
Обычно этот тип диаграмм используется в самом начале проектирования системы для анализа аппаратных средств, на которых она будет эксплуатироваться .
State Maсhine diagram (диаграммы состояний)
Каждый объект системы, обладающий определенным поведением, может находиться в определенных состояниях, переходить из состояния в состояние, совершая определенные действия в процессе реализации сценария поведения объекта. Поведение большинства объектов реальных систем можно представить с точки зрения теории конечных автоматов, то есть поведение объекта отражается в его состояниях, и данный тип диаграмм позволяет отразить это графически. Для этого используется два вида диаграмм: Statechart diagram (диаграмма состояний) и Activity diagram (диаграмма активности)
Statechart diagram (диаграмма состояний)
Диаграмма состояний предназначена для отображения состояний объектов системы, имеющих сложную модель поведения . Это одна из двух диаграмм State Machine, доступ к которой осуществляется из одного пункта меню.
Activity diagram (диаграммы активности)
Это дальнейшее развитие диаграммы состояний. Фактически данный тип диаграмм может использоваться и для отражения состояний моделируемого объекта, однако, основное назначение Activity diagram в том, чтобы отражать бизнес-процессы объекта . Этот тип диаграмм позволяет показать не только последовательность процессов, но и ветвление и даже синхронизацию процессов.
Этот тип диаграмм позволяет проектировать алгоритмы поведения объектов любой сложности, в том числе может использоваться для составления блок-схем.
Interaction diagram (диаграммы взаимодействия)
Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.
Sequence diagram (диаграммы последовательностей действий)
Взаимодействие объектов в системе происходит посредством приема и передачи сообщений объектами-клиентами и обработки этих сообщений объектами-серверами. При этом в разных ситуациях одни и те же объекты могут выступать и в качестве клиентов, и в качестве серверов.
Данный тип диаграмм позволяет отразить последовательность передачи сообщений между объектами.
Этот тип диаграммы не акцентирует внимание на конкретном взаимодействии, главный акцент уделяется последовательности приема/передачи сообщений. Для того чтобы окинуть взглядом все взаимосвязи объектов, служит Collaboration diagram.
Collaboration diagram (диаграммы сотрудничества)
Этот тип диаграмм позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта и типы этих сообщений.
Class diagram (диаграммы классов)
Этот тип диаграмм позволяет создавать логическое представление системы, на основе которого создается исходный код описанных классов .
Значки диаграммы позволяют отображать сложную иерархию систем, взаимосвязи классов (Classes) и интерфейсов (Interfaces). Данный тип диаграмм противоположен по содержанию диаграмме Collaboration, на котором отображаются объекты системы. Классы имеют различные нотации. В нотации, предложенной Г. Бучем классы изображаются в виде чего-то нечеткого, похожего на облако. Таким образом Г.Буч пытается показать, что класс - это лишь шаблон, по которому в дальнейшем будет создан конкретный объект.
Component diagram (диаграммы компонентов)
Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы . Часто данный тип диаграмм называют диаграммами модулей.
При проектировании больших систем может оказаться, что система должна быть разложена на несколько сотен или даже тысяч компонентов, и этот тип диаграмм позволяет не потеряться в обилии модулей и их связей.
Лабораторная работа № 2. Разработка моделей IDEF0
Порядок выполнения лабораторной работы:
1. Изучите теоретические сведения.
2. Выполните следующие задания:
· Создание контекстной диаграммы.
· Создание диаграммы узлов.
· Создание FEO диаграммы.
· Расщепление и слияние моделей.
3. Выполните структурный анализ задачи, определенной в ТЗ (первая лабораторная работа).
4. Выполненный анализ задачи оформите в виде диаграмм IDEF0 (программные продукты MS Visio, BPwin).
Теоретическая часть
Методология функционального моделирования IDEF 0
Лекционный материал
Общая постановка задачи
Выполните структурный анализ задачи (первая лабораторная работа) и оформите результат данного анализа в виде диаграмм IDEF0.
Список индивидуальных данных
Продолжается работа над задачей, выбранной в первой лабораторной работе.
Пример выполнения работы
Как было определено в ТЗ, входной информацией системы является:
· бухгалтерская информация;
· информация о нажатой кнопке RTE;
· регистрационная информация;
· информация о считанном идентификаторе.
Выходной информацией системы является:
· управляющие воздействия на исполнительный механизм;
· отчеты.
Контекстная диаграмм (диаграмма А-0) разрабатываемой системы управления платной автостоянкой приведена на рис. 1.
Рис. 1. IDEF0-диаграмма А-0 - контекстная диаграмма системы управления платной автостоянкой
Детализация контекстной диаграммы А-0 представлена на рис. 2 (диаграмма А0). На данной диаграмме выделены три функциональных блока «Регистрация клиентов и корректировка информации о клиентах», «Пропуск клиента» и «Формирование отчетов».
Рис. 2. IDEF0-диаграмма А0 – детализация контекстной диаграммы
Клиентами в данном случае являются арендаторы машиномест автостоянки. При регистрации клиентов вводится ФИО клиента, уникальный идентификатор клиента, срок действия идентификатора. В качестве идентификатора клиента могут выступать магнитные карты, пропуска со штрих-кодом, радио-брелки. Срок действия идентификатора определяется исходя из бухгалтерской информации (оплата машиноместа, договор).
При пропуске клиента на автостоянку его идентификация осуществляется на основании информации о считанном идентификаторе. Если срок идентификатора закончен, то блок, отвечающий за пропуск клиента, формирует управляющее воздействие на блок регистрации. Пропуск клиента может осуществляться вручную при нажатии кнопки RTE. Выходом блока, отвечающего за пропуск клиента, является управляющее воздействие на исполнительный механизм ворот или другого устройства, контролирующего проезд на автостоянку, и информация о выполненном действии.
Все выполненные действия фиксируются и используются при формировании отчетов, которые являются выходом блока, отвечающего за их формирование.
Детализация блока «Регистрация клиентов и корректировка информации о клиентах» представлена на рис. 3. Как видно из диаграммы, перед регистрацией клиента и изменением информации о клиенте осуществляется проверка соответствующих прав сотрудника автостоянки (права администратора). Права определяются на основании введенного пароля.
Владелец" href="/text/category/vladeletc/" rel="bookmark">владельце идентификатора не осуществляется. Информация о нажатии данной кнопки сразу поступает на блок формирования управляющих воздействий.
Выходом блока формирования управляющих воздействий является управляющее воздействие на исполнительный механизм и информация о выполненном действии.
Рис. 4. IDEF0-диаграмма А2 – детализация блока «Пропуск клиента» диаграммы А0
После выполнения данного преобразования осуществляется поиск информации о владельце идентификатора. В зависимости от результатов поиска могут быть сформированы требования о внесении изменений в информацию о клиенте или передана информация на блок, отвечающий за формирование управляющих воздействий.
Детализация блока «Формирование отчетов» диаграммы А0 представлена на рис. 5. (диаграмма А3). Вначале необходимо выбрать тип отчета. Затем формируется соответствующий отчет. Все отчеты в системе можно разделить на два типа:
1. Отчеты, для формирования которых используется только информация о клиенте.
2. Отчеты, для формирования которых нужна информация о выполненных действиях.
Рис. 5. IDEF0-диаграмма А3 – детализация блока «Формирование отчетов» диаграммы А0
К первому типу относятся следующие отчеты:
· список клиентов;
· задолжености клиентов.
Ко второму типу относятся следующие отчеты:
· активность использования машиномест;
· список занятых и свободных машиномест;
· список событий.
Детализация блока «Выполнить изменение информации о клиенте» диаграммы А1 представлена на рис. 6 (диаграмма А14). Требования внесения информации о клиенте могут быть вызваны следующими причинами:
· не произведена оплата аренды машиноместа;
· не произведена оплата пропуска;
· требуются изменения в договоре;
· требуется замена пропуска (идентификатора).
Рис. 6. IDEF0-диаграмма А14 – детализация блока «Выполнить изменение информации о клиенте» диаграммы А1
Детализация блока «Изменение договора» диаграммы 14 представлена на рис. 7 (диаграмма А142). Если требуется изменение договора, то выписывается новый договор, который отдается клиенту. После подписания договора клиентом и руководством автостоянки, информации о договоре вносится в бухгалтерскую программу и в разрабатываемую систему.
Рис. 7. IDEF0-диаграмма А142 – детализация блока «Изменение договора» диаграммы А14
Детализация блока «Оплата» диаграммы А14 представлена на рис. 8 (диаграмма А143). Если требуется произвести оплату аренды машиномест или изготовления нового пропуска, то выписываются документы, на основании которых будет производиться оплата. С этими документами клиент отправляется в бухгалтерию и производит оплату. Информация об оплате фиксируется в бухгалтерской программе и передается в разрабатываемую систему.
Договора и платежные документы выписываются в бухгалтерской программе. Информация о договорах и оплате также хранится в бухгалтерской программе, в разрабатываемой системе достаточно хранить признаки наличия требований оплаты и изменения договора. Данные признаки устанавливаются на основании бухгалтерской информации.
Рис. 8. IDEF0-диаграмма А143 – детализация блока «Оплата» диаграммы А14
Для дальнейшей детализации функциональных блоков будем использовать диаграммы IDEF3, которые будут разработаны при выполнении следующей лабораторной работы.
Контрольные вопросы:
1. В чем суть методологии IDEF0 ?
2. Синтаксис и семантика функциональных блоков диаграммах IDEF0 ?
3. Синтаксис и семантика стрелок в диаграммах IDEF0:
· стрелки входа;
· стрелки управления;
· стрелки выхода;
· стрелки механизма исполнения;
· комбинированные стрелки;
· разбиение и соединение стрелок;
· туннели.
4. Основы методики построения моделей IDEF0.
5. Основные возможности программного продукта MS Visio.
6. Построение диаграмм IDEF0 с помощью программного продукта MS Visio.
7. Основные возможности программного продукта BPwin.
8. Построение диаграмм IDEF0 с помощью программного продукта BPwin.
