Опубликован: 18.06.2007 | Уровень: для всех | Доступ: платный | ВУЗ: Сибирский федеральный университет (г. Красноярск)
Лекция 9:

Расширенный анализ требований. Моделирование

< Лекция 8 || Лекция 9: 123 || Лекция 10 >

Диаграммы UML, поясняющие внутреннее устройство системы

Некоторые авторы [9.3] рекомендуют использовать при описании требований диаграммы UML, описывающие создаваемую систему через ее компоненты (классы, объекты), отношения и взаимодействия между ними. Данный подход имеет свои ограничения (см. Принцип 2).

Диаграмма классов

Для создания диаграммы классов необходимо:

  1. Осуществить поиск классов (ключевых компонент проблемной области).
  2. Для каждого найденного класса определить его имя, основные атрибуты, операции и (или) ответственности.
  3. Исследовать отношения найденных классов.

Классы на диаграмме представляются в виде прямоугольников, отношения - в виде линий, связывающих прямоугольники. Линии разного типа графически отличаются различной штриховкой и стрелками.

Принято выделять [9.1] 3 уровня абстракции классов:

  • концептуальный уровень,
  • уровень спецификации,
  • уровень реализации.

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

Отношения, подлежащие анализу на концептуальном уровне - это:


Рис. 9.7.

Диаграмма классов показывает статическую структуру проблемной области. Для анализа взаимодействия объектов - экземпляров класса в ходе реализации варианта использования в UML предусмотрены две диаграммы взаимодействия: диаграмма кооперации и диаграмма последовательности.

По мнению автора, если диаграмма классов в ряде случаев и может рассматриваться, как артефакт, поясняющий структуру проблемной области, то диаграммы взаимодействия вряд ли стоит рассматривать в качестве выразительного языкового средства, иллюстрирующего требования к системе в диалоге "Заказчик-Исполнитель". Тем не менее, в соответствии с Принципом 3 свободы выбора языковых средств, аналитик, решивший использовать данные диаграммы, может ознакомиться с ними в специальной литературе [9.1-9.2].

Альтернативные языки моделирования

Диаграмма потоков данных

Диаграмма потоков данных (data flow diagram, DFD) - один из основных инструментов структурного анализа и проектирования информационных систем, существовавших в "доюмээльную" эпоху. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, "старинные" структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.

DFD (Data Flow Diagram) – диаграмма потоков данных [41]. Методология графического структурного анализа,  описывающая взаимосвязи функций системы с потоками и хранилищами данных, а также с внешними по отношению к системе источниками, к которым осуществляется доступ. Диаграмма DFD – один из основных инструментов структурного анализа и проектирования информационных систем. Авторы SWEBOK 3.0 http://www.computer.org/portal/web/swebok/swebokv3 отмечают полезность DFD при анализе безопасности информационных систем, поскольку в нем удобно проводить идентификацию возможных путей атак и раскрытия конфиденциальной информации.

Исторически сложилось так, что для описания диаграмм DFD используются две нотации - Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом. На приведенной ниже иллюстрации использована нотация Гейна-Сарсона.


Рис. 9.8.

Информационная система принимает извне потоки данных. Для обозначения элементов среды функционирования системы используется понятие внешней сущности. Внутри системы существуют процессы преобразования информации, порождающие новые потоки данных. Потоки данных могут поступать на вход к другим процессам, помещаться (и извлекаться) в накопители данных, передаваться к внешним сущностям.

Модель DFD, как и большинство других структурных моделей - иерархическая модель. Каждый процесс может быть подвергнут декомпозиции, т.е. разбиению на структурные составляющие, отношения между которыми в той же нотации могут быть показаны на отдельной диаграмме. Когда достигнута требуемая глубина декомпозиции - процесс нижнего уровня сопровождается мини-спецификацией (текстовым описанием).

Кроме того, нотация DFD поддерживает понятие подсистемы - структурной компоненты разрабатываемой системы.

Нотация DFD - удобное средство для формирования контекстной диаграммы, т.е. диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это - диаграмма верхнего уровня в иерархии диаграмм DFD. Ее назначение - ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда. Другие нотации, часто используемые при формировании контекстной диаграммы - диаграмма SADT 1Марка Д.А. Методология структурного анализа и проектирования. - С.-Пб.: Питер, 1995. - 235 с., диаграмма Диаграмма вариантов использования.

Другие виды моделей

Среди многообразия моделей, использующихся в анализе систем, хочется особо отметить еще две нотации, позволяющие описать сложные многоальтернативные взаимодействия компонент информационной системы - нотацию IDEF3 [9.4] и eEPC-диаграмму ARIS [9.6].

EPC Event-Driven Process Chain - цепочка функций, направляемая событиями [24]. Событийно-ориентированная графическая диаграмма функций; используется в методологии ARIS. Позволяет строить сложные комбинации вызовов функций на основе генерируемых ими событий с использованием логических операторов. Содержит широкие иллюстративные возможности для описания контекста каждой функции (например – источники данных, оргтехника, пользователи и т.д.).

Для моделирования требований к системам с разветвленной логикой К.Вигерс рекомендует использовать таблицы и деревья решений [Вигерс]. Часто на практике бывают полезны диаграммы сущность-связь и SADT-диаграммы [Маклаков].

< Лекция 8 || Лекция 9: 123 || Лекция 10 >
Ринат Гатауллин
Ринат Гатауллин

Здравствуйте. Интересует возможность получения диплома( https://intuit.ru/sites/default/files/diploma/examples/P/955/Nekommerch-2-1-PRF-example.jpg ). Курс пройден. Сертификат не подходит. В сертификате ошибка, указано по датам время прохождения около 14 дней, хотя написано 576 часов.

Аминат Албакова
Аминат Албакова

Здравствуйте, я прошла весь курс, но нигде не указано, что курс завершился удачно или что-то в этом роде, не знаю что делать, как получть диплом в электронном виде?

Анатолий Федоров
Анатолий Федоров
Россия, Москва, Московский государственный университет им. М. В. Ломоносова, 1989
Алексей Махонин
Алексей Махонин
Россия, Волжский, Средняя школа №12, 1990