лекция. Сборник лекций по МДК _Технология разработки программного обеспе. Курс лекций для специальности спо базовой подготовки

• Название: Курс лекций для специальности спо базовой подготовки
• Анкор: лекция
• Дата: 02.09.2022
• Размер: 4.41 Mb.
• Имя файла: Сборник лекций по МДК _Технология разработки программного обеспе.docx
• Тип: Курс лекций; #660044
• страница: 23 из 62

Диаграммы 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 ¹, диаграмма Диаграмма вариантов использования.

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

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

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

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

- Вы действительно хотите, чтобы я поставил свою подпись под этим документом?

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

- Хорошо, я подпишу, но это ровным счетом ничего не значит.

- ??

- Ведь это всего лишь бумага, слова… А мне нужна программа, которая реально облегчит жизнь сотрудникам моего предприятия. Подпишу я сейчас документ или не подпишу - не имеет никакого значения. Важно лишь - сможете Вы или нет сделать такую систему, которая действительно принесет пользу. А это выяснится лишь, когда я смогу ее "пощупать".

Такой или примерно такой диалог состоялся у автора с генеральным директором полиграфического предприятия - заказчиком системы комплексной автоматизации его деятельности при подписании эскизного проекта.

И эта ситуация - не нонсенс. Каждый, кто выполнял проекты автоматизации рано или поздно сталкивается с ней. Что же делать - отказываться от выгодного проекта? Или взять на себя риск, что проект не будет принят в эксплуатацию: ведь при таком подходе к документу описания требований наверняка найдется что-то, очевидное для Заказчика, неожиданное для Исполнителя и не вошедшее в ТЗ. Хорошо, если придется переделывать 5% функций. А что, если 30% или 50%?

К счастью, выход существует. И этот выход - создание прототипов. Прототипы позволяют увидеть за сухими строчками документа описания требований фрагменты реальной системы, "поиграть" в эксплуатацию системы до ее создания.