Файл: Анализ и оценка средств реализации структурных методов анализа и проектирования экономической информационной системы(Теоретические аспекты структурного анализа).pdf
Добавлен: 17.05.2023
Просмотров: 61
Скачиваний: 4
• модели данных (Data Model Diagrams). Эти диаграммы использовались структурными методами в различных комбинациях. Среди них встречалось множество вариаций. Примерно в 1990 появляется термин «инженерия разработки ПО» (Information Engineering, IE, James Martin), являющаяся логическим расширением структурных методов, появившихся в течение 1970х.
Глава 2. Основные методологии структурного анализа
SADT (аббревиатура выражения Structured Analysis and Design Technique - методология структурного анализа и проектирования) - это методология, разработанная специально для того, чтобы облегчить описание и понимание искусственных систем, попадающих в разряд средней сложности. SADT была создана и опробована на практике в период с 1969 по 1973 г.
Затем эта методология была принята в качестве стандарта в ВВС США и получила название IDEF0. Настоящее время IDEF0 получил статус международного стандарта.
Описание системы с помощью SADT называется моделью. В SADT-моделях используются как естественный, так и графический языки. Для передачи информации о конкретной системе источником естественного языка служат люди, описывающие систему, а источником графического языка - сама методология SADT. Графический язык SADT организует естественный язык вполне определенным и однозначным образом, за счет чего SADT и позволяет описывать системы, которые до недавнего времени не поддавались адекватному представлению.
Как известно, модель может быть сосредоточена либо на функциях системы, либо на ее объектах. Поэтому при моделировании систем различают два подхода:
- Функциональный
- Объектный.
Возникает вопрос, какой из методов наиболее полно претворяет в жизнь принципы системного подхода, или в другой формулировке, что является первичным – функции или объекты? На первый взгляд этот вопрос сродни проблеме «»курица – яйцо»: функции выполняются объектами и с помощью объектов и, в то же время, объекты создаются для выполнения функций. Чтобы разобраться с этой проблемой, обратимся к определению основополагающего понятия теории проектирования систем – понятию системы.
Основой существования любой системы, несомненно, является цель (или полезный результат). Именно на основе системной цели определяются функции, с помощью которых будет достигнута данная цель. Функции определяются путем разбиения глобальной цели на подцели, то есть путем построения дерева цели. При этом, рассматривая два соседних уровня дерева целей, можно говорить, что нижний уровень по отношению к верхнему является функциями, а верхний по отношению к нижнему – целью. Таким образом, построив дерево целей с достаточной для конкретной задачи степенью детализации, мы можем считать нижний уровень этого дерева функциями системы, то есть цели превращаются в средства достижения этой цели.
Таким образом, функции системы проявляются на этапе целеполагания, то есть на самых ранних этапах формирования систем. Объекты, которые должны выполнять выявленные функции, определяются вслед за этим, а не наоборот: создадим объекты (отделы, подразделения, персонал, оборудование), а потом придумаем, чем они будут заниматься (хотя в реальной жизни так бывает достаточно часто).
Данные рассуждения доказывают, что при реализации системного подхода, именно функции исходной системы (предприятия, организации, фирмы) должны быть отправной точкой в процессе проектирования информационной системы. Таким образом, именно функциональный подход, наиболее полно отвечает требованию системности, целостности.
SADT-модели, реализованные в CASE средствах, ориентированы именно на функции, то есть эти модели являются функциональными. Функциональная модель представляет с требуемой степенью детализации систему функций, которые в свою очередь отражают свои взаимоотношения через объекты системы. Модели данных (объектные модели) дуальны к функциональным моделям и представляют собой подробное описание объектов системы, связанных системными функциями.
Целью функциональной модели является получение ответов на некоторую совокупность вопросов. Эти вопросы неявно присутствуют (подразумеваются) в процессе анализа и, следовательно, они руководят созданием модели и направляют его. Это означает, что сама модель должна будет дать ответы на эти вопросы с заданной степенью точности. Если модель отвечает не на все вопросы или ее ответы недостаточно точны, то мы говорим, что модель не достигла своей цели.
Принципы SADT-моделирования
Метод структурного анализа и проектирования основан на достаточно простых и ясных принципах, и это позволяет избегать разночтений модели разными людьми, что зачастую бывает в процессе моделирования и анализа систем. Но чтобы достичь этого результата, очень важно строго придерживаться этих принципов. Нужно отметить, что современные CASE – средства, реализуют поддержку выполнения большинства из этих принципов.
Принцип первый – принцип «черного ящика»
Модель является отображением системы. Однако моделируемая система никогда не существует изолированно: она всегда связана с окружающей средой. Причем зачастую трудно сказать, где кончается система и начинается среда.
По этой причине в методологии SADT подчеркивается необходимость точного определения границ системы. SADT-модель всегда ограничивает свой объект, то есть, модель устанавливает точно, что является и что не является объектом моделирования, описывая то, что входит в систему, и подразумевая то, что лежит за ее пределами. Отделенная от окружающей среды система с указанием связей с этой средой называется контекстом системы. Контекст системы изображается в виде «черного ящика», имеющего входы и выходы, которые отображают взаимодействие системы с окружающей средой (рис.4.1). Каждая из показанных на рисунке стрелок имеет свое название и назначение.
1. Стрелки слева Вход (Input) отображают необходимые для исполнения процесса входы.
1. Стрелки справа Выход(Output) отображают результаты исполнения процесса (выходы).
1. Стрелки снизу Механизм (Mechanism) отображают, с помощью чего и кого выполняется процесс, то есть механизмы – это те объекты, которые собственно и исполняют данный процесс. Например: оператор, рабочий, автоматизированная система предприятия и т. п.
Стрелки сверху Управления (Control) отображают объекты, диктующие правила исполнения процесса. Это могут быть инструкции по технике безопасности для процесса изготовления детали рабочим, работающим на станке, или учебные планы для процесса обучения в вузе.
Принцип второй – принцип неизменности точки зрения
Ответы на поставленные вопросы будут зависеть от того, чья точка зрения отражается при создании модели. Например, мы получим разные модели предприятия при отражении точки зрения генерального директора, главного инженера или начальника отдела кадров. Поскольку качество описания системы резко снижается, если оно делается с различных позиций, SADT требует, чтобы модель рассматривалась все время с одной и той же позиции.У модели может быть только одна точка зрения, иона не должна меняться при декомпозиции.
Например, если вы строите модель образовательного процесса в вузе с точки зрения ректора и добрались при декомпозиции до деятельности кафедры, вы не должны описывать ее с позиций заведующего кафедрой, как бы логично это не казалось.
Принцип третий «функции – объекты»
После того, как определены субъект, цель и точка зрения модели, начинается первая интеграция процесса моделирования по методологии SADT. Автор модели определяет, что включить в модель, а что исключить из нее. Точка зрения диктует автору модели выбор нужной информации об объекте моделирования и форму ее подачи. Цель становится критерием окончания моделирования. Конечным результатом этого процесса является набор тщательно взаимоувязанных описаний, начиная с описания самого верхнего уровня всей системы и кончая подробным описанием деталей или операций системы.
Объекты изображаются дугами (стрелками) и именуются существительными: «деталь», «студент», «станок», «паспорт» и т.д.
Кроме того, SADT требует, чтобы в диаграмме было не менее трех и не более шести блоков. Эти ограничения поддерживают сложность диаграмм и модели на уровне, доступном для чтения, понимания и использования.
Принцип четвертый – принцип декомпозиции диаграмм
SADT-модель объединяет и организует диаграммы в иерархические структуры, в которых диаграммы наверху модели менее детализированы, чем диаграммы нижних уровней.
Принцип пятый –принцип сохранения дуг
В процессе построения модели мы переходим на более детальное представление системы. При этом важно не потерять связь с родительскими диаграммами, иначе на нижних уровнях мы получим систему, отличную от контекстной. Это гарантируется только в том случае, если будет соблюдаться принцип сохранения дуг. Он означает, что при построении дочерней диаграммы все граничные дуги родительской диаграммы должны быть перенесены в неизменном виде.
Принцип шестой – принцип декомпозиции дуг
Дуга в SADT на верхних уровнях модели обычно представляет набор объектов. На нижних уровнях модели бывает важно уточнить, какие конкретно объекты связаны с выполнением данной функции. Для этого дуги могут разветвляться и эти ветви подсоединяться к различным блокам.
Принцип седьмой – принцип единства оформления диаграмм
Поскольку в разработке модели принимает участие целый коллектив аналитиков и экспертов, необходимо соблюдать единые правила оформления диаграмм.
Нотация DFD (диаграммы потоков данных)
DFD — общепринятое сокращение от англ. data flow diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML.
DFD – это нотация, предназначенная для моделирования информационный систем с точки зрения хранения, обработки и передачи данных.
Исторически синтаксис этой нотации применяется в двух вариантах — Йордана (Yourdon) и Гейна-Сарсона (Gane-Sarson).
Непосредственно DFD нотация состоит из следующих элементов:
- Процесс (англ. Process), т.е. функция или последовательность действий, которые нужно предпринять, чтобы данные были обработаны. Это может быть создание заказа, регистрация клиента и т.д. В названиях процессов принято использовать глаголы, т.е. «Создать клиента» (а не «создание клиента») или «обработать заказ» (а не «проведение заказа»). Здесь нет строгой системы требований, как, например, в IDEF0 или BPMN, где нотации имеют жестко определенный синтаксис, так как они могут быть исполняемыми. Но все же определенных правил стоит придерживаться, чтобы не вносить путаницу при чтении DFD другими людьми.
- Внешние сущности (англ. External Entity). Это любые объекты, которые не входят в саму систему, но являются для нее источником информации либо получателями какой-либо информации из системы после обработки данных. Это может быть человек, внешняя система, какие-либо носители информации и хранилища данных.
- Хранилище данных (англ. Data store). Внутреннее хранилище данных для процессов в системе. Поступившие данные перед обработкой и результат после обработки, а также промежуточные значения должны где-то храниться. Это и есть базы данных, таблицы или любой другой вариант организации и хранения данных. Здесь будут храниться данные о клиентах, заявки клиентов, расходные накладные и любые другие данные, которые поступили в систему или являются результатом обработки процессов.
- Поток данных (англ. Data flow). В нотации отображается в виде стрелок, которые показывают, какая информация входит, а какая исходит из того или иного блока на диаграмме.
Нотация DFD может описывать любые действия, в том числе, процесс продажи или отгрузки товара, работу с заявками от клиентов или закупки материалов, с точки зрения описания системы.
Эта нотация помогает понять, из чего должна состоять система, что нужно для автоматизации бизнес-процесса. Но DFD не является описанием непосредственно бизнес-процесса. Здесь, например, нет такого важного параметра, как время. Также в этой нотации не предусмотрены условия и «развилки». В DFD мы рассматриваем откуда появляются данные, какие данные нужны, их обработку и куда результаты отправить.
Т.е. в этой нотации описывается не столько непосредственно процесс, сколько движение потоков данных.
DFD нотации удобны при анализе, когда система рассматривается с точки зрения документооборота. При этом можно наглядно увидеть, где хранятся данные, каким образом производится обмен документацией, где в этом процессе допущены ошибки организации бизнес-процессов и пр. Но здесь применение DFD диаграмм требует особой осторожности. Все же это не описание бизнес-процесса как такового, а, скорее, диаграмма перемещения данных при реализации бизнес-процессов.
Джексон структурированное развитие ( JSD ) является линейной методологией разработки программного обеспечения , разработанная Майкл А. Джексоном и Джон Камерон в 1980 - х годах.
JSD был впервые представлен Майклом А. Джексоном в 1982 году, в статье под названием «Система Метод разработки».
Развитие системы может начинаться с этапа в проекте, когда есть только общее утверждение требований. Тем не менее, многие проекты, которые использовали развитие системы Джексона фактически началась несколько позже в жизненном цикле, делая первые шаги в основном из существующих документов, а не напрямую с пользователями.
Первый метод Джексона, Джексон Структурное программирование (JSP), используется для получения конечного кода. Выход из ранних стадий JSD представляет собой набор дизайнерских программ задач, разработка которых является предметом JSP.
Три основных принципа работы JSD:
- Развитие должно начинаться с описания и моделирования реального мира, а не указывать или структурирования функции, выполняемой системой. Система с использованием метода JSD выполняет имитацию реального мира.
- Главная цель состоит в том, чтобы отобразить прогресс в реальном мире
- Способ реализации системы основан на преобразовании спецификации в эффективное множество процессов. Эти процессы должны быть разработаны таким образом, чтобы можно было бы запускать их на доступных программных и аппаратных средствах.