Методология SADT (Structured Analysis and Design Technique

Методология SADT (Structured Analysis and Design Technique – Технология структурного анализа и проектирования)

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

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

Стандарт IDEF 0 - независимый от частных организаций стандарт моделирования бизнес- процессов, принятый в начале 1990 -х гг. в США на основе методологии SADT. Получил широкое распространение, принят в НАТО и МВФ.

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

SADT M есть модель системы S, если M может быть использована для получения ответов на вопросы относительно S с требуемой точностью. Множество возможных вопросов определяется выбранной при моделировании точкой зрения на систему (Viewpoint) Во многих случаях SADT-модели реальных предметных областей имеют самостоятельную практическую (в т. ч. коммерческую) ценность, и могут быть использованы для реинжиниринга и обучения персонала.

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

Диаграмма

Основные правила проектирования Блоки • на листе следует отражать 3 -6 функциональных блоков для удобства чтения диаграмм (кроме листа с контекстной диаграммой); • название функции пишется внутри блока в неопределенной глагольной форме ( «выписать ордер» , «решить задачу» ) или отглагольное существительное + существительное ( «изготовление детали» , «прием заказа» ); • блоки располагаются и нумеруются по диагонали из верхнего левого угла к нижнему правому;

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

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

Основные правила проектирования Дуги Название соответствующих дуге объектов пишется вдоль нее в форме подлежащего, возможно с дополнениями или определениями ( «утвержденный баланс» , «бракованное изделие» ). По роли в выполнении функции блока дуги подразделяются на: • входные – объекты, преобразуемые и используемые функцией блока (допускается, что функция может не иметь входов); • выходные – изображают объекты, в которые преобразуются входы (каждая функция должна иметь хотя бы одну стрелку выхода); • управляющие – содержат условия выполнения функций и ограничения, учитываемые при их работе: правила, процедуры, стратегии и т. п. (каждая функция должна иметь хотя бы одну стрелку управления); • дуги механизмов – раскрывают средства, которыми происходит выполнение функции (персонал, станки, устройства и пр. ); • вызов – специальная дуга, указывающая на другую модель функции.

Основные правила проектирования Дуги

Основные правила проектирования Дуги Для идентификации внешних дуг в SADT принята система ICOM-обозначений: - I – Input (вход); - C – Control (управление); - O – Output (выход); - M – Mechanism (механизм).

Основные правила проектирования Дуги Типы связей функций: - связь по входу (output-input): стрелка выхода вышестоящего блока направляется на вход нижестоящего; - связь по управлению (output-control): стрелка выхода вышестоящего блока направляется на управление нижестоящего; - обратная связь по входу (output-input feedback) или обратная связь по потоку данных (повторное использование и итерация функций): стрелка выхода нижестоящего блока направляется на вход вышестоящего; - обратная связь по управлению (output-control feedback): стрелка выхода нижестоящего блока направляется на управление вышестоящего (свидетельствует о взаимном влиянии функций); - связь выход – механизм (output-mechanism): стрелка выхода одного блока направляется на механизм другого.

Основные правила проектирования Дуги Туннельные дуги

Этапы моделирования - начало моделирования - сбор информации о моделируемой системе, выбор цели модели и точки зрения, разграничение системы и внешней среды, оформленные в виде диаграммы А 0 и контекстной диаграммы А-0 (строятся основные блоки системы и связывающие их объекты, важно разграничить внутренние, внешние и интерфейсные объекты системы); - выбор блоков, нуждающихся в декомпозиции и построении детализирующих диаграмм (критерий окончания декомпозиции- достигнута цель моделирования); - критический анализ построенной модели и, возможно, возврат к предыдущим этапам (дает ответ на вопрос, соответствует ли модель формальным требованиям SADT).

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

Цель моделирования и Точка зрения Цель моделирования должна отвечать на вопросы: - Почему этот процесс должен быть смоделирован? - Что должна показывать модель? - Что может получить читатель? Формулировка целей позволяет команде аналитиков сфокусировать усилия в нужном направлении. Пример: «Описать функциональность предприятия с целью написания спецификации информационной системы» Точка зрения - взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Часто при выборе точки зрения на модель важно задокументировать дополнительные альтернативные точки зрения.

Модели AS-IS и TO-BE Цели построения модели: - выявление слабых и уязвимых мест деятельности организации; - анализ преимуществ новых бизнес-процессов; - анализ степени изменения существующей структуры организации бизнеса. Анализ недостатков и “узких мест” начинают с построения модели AS-IS (Как есть), т. е. модели существующей организации работы. Полученная модель служит для выявления неуправляемых работ, работ не обеспеченных ресурсами, ненужных и неэффективных работ, дублирующихся работ и других недостатков в организации деятельности предприятия. Исправление недостатков, перенаправление информационных и материальных потоков приводит к созданию модели TO-BE (Как будет) - модели идеальной организации бизнес - процессов.

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