Ис. Конспект лекций Маглинец Ю. А. Красноярск сфу 2007 Введение. Понятие и классификация требований
 Скачать 0.88 Mb.
|
|
Диаграмма действий Если диаграмма вариантов использования даёт «вид сверху» на функциональность системы, диаграмма действий UML, напротив, позволяет подробно иллюстрировать отдельный вариант использования и его сценарии. Основные компоненты описания системы: Функции (действия), Символы «старт» и «стоп», Потоки управления, Разветвители, Линейки синхронизации. Принять заказ Оформить накладную Инициировать поставку [Товар есть на складе] [Товар отсутствует на складе] Выдать товар Диаграмма действий позволяет проиллюстрировать вариант использования с требуемой степенью подробности. Линейный вариант использования приводит к диаграмме действий с линейным потоком управления между действиями. Действия варианта использования с альтернативными сценариями реализуется через разветвители. Линейки синхронизации позволяют описывать такие сложные конструкции, как синхронизацию начала (окончания) параллельных во времени процессов. Помимо стандартного формата описания, UML предлагает вариант с «плавательными дорожками». Этот формат удобен для описания случая, когда в варианте использования участвуют несколько акторов. Диаграмма состояний Диаграмма состояний в анализе требований используется, когда требуется исследовать поведение системы, как конечного автомата. Это представление пришло в UML из теории систем. В общем случае диаграмма состояний описывает, как система себя ведёт в более, чем одном варианте использования. Синтаксис диаграмм состояний во многом совпадает с синтаксисом диаграмм действий. Основные компоненты описания системы: Простые состояния, Составные состояния, Символы «старт» и «стоп», Переходы, Линейки синхронизации. В языке UML под состоянием понимается абстрактный метакласс, используемый для моделирования отдельной ситуации, в течение которой имеет место выполнение некоторого условия [15]. Состояние может быть задано в виде набора конкретных значений атрибутов класса или объекта, при этом изменение их отдельных значений будет отражать изменение состояния моделируемого класса или объекта. Заказ поступил Заказ обеспечен материалами Заказ в производстве Заказ отгружен Ожидание материалов Переход системы из состояния в состояние осуществляется при наступлении событий. При этом говорится, что переход срабатывает. Переход может быть безальтернативным, либо содержать альтернативы. Во втором случае переход обусловлен наступлением сторожевых условий. Наконец, событие может сопровождаться выражением действия, которое происходит в случае, если срабатывает переход. Полный синтаксис описания перехода (надписи на стрелке) следующий: Событие [сторожевое условие] / выражение действия Иногда бывает полезным объединить часть состояний в одно мета-состояние. Графически это выглядит, как символ состояния (прямоугольник со скруглёнными углами), содержащий внутри себя несколько символов состояний. При этом возможны переходы между подчинёнными состояниями, переходы между подчинённым и внешним состояниями и переходы между составным и внешним состоянием. Диаграммы UML, поясняющие внутреннее устройство системы Некоторые авторы [16] рекомендуют использовать при описании требований диаграммы UML, описывающие создаваемую систему через её компоненты (классы, объекты), отношения и взаимодействия между ними. Данный подход имеет свои ограничения (см. Принцип 2 ). Диаграмма классов. Для создания диаграммы классов необходимо: 1. Осуществить поиск классов (ключевых компонент проблемной области). 2. Для каждого найденного класса определить его имя, основные атрибуты, операции и (или) ответственности. 3. Исследовать отношения найденных классов. Классы на диаграмме представляются в виде прямоугольников, отношения – в виде линий, связывающих прямоугольники. Линии разного типа графически отличаются различной штриховкой и стрелками. Принято выделять [14] 3 уровня абстракции классов: концептуальный уровень, уровень спецификации, уровень реализации. Анализ требований разумно сопровождать диаграммами, отражающими концептуальный уровень. На данном уровне при описании классов целесообразно указать их наименования и ответственности. Атрибуты и операции можно не указывать, либо ввести только самые основные, отложив их исследование на более поздние стадии детализации. Отношения, подлежащие анализу на концептуальном уровне – это: * * 1 * 1 * ассоциация (именованная связь), зависимость (изменения в одном классе приводят к изменениям в другом), обобщение / генерализация (родовидовое отношение), агрегация (отношение «часть-целое»), композиция (отношение «часть-целое», однозначно регламентирующее количество и состав частей целого). Диаграмма классов показывает статическую структуру проблемной области. Для анализа взаимодействия объектов – экземпляров класса в ходе реализации варианта использования в UML предусмотрены две диаграммы взаимодействия: диаграмма кооперации и диаграмма последовательности. По мнению автора, если диаграмма классов в ряде случаев и может рассматриваться, как артефакт, поясняющий структуру проблемной области, то диаграммы взаимодействия вряд ли стоит рассматривать в качестве выразительного языкового средства, иллюстрирующего требования к системе в диалоге «Заказчик- Исполнитель». Тем не менее, в соответствие с Принципом 3 свободы выбора языковых средств, аналитик, решивший использовать данные диаграммы, может ознакомиться с ними в специальной литературе [14-15]. Альтернативные языки моделирования Диаграмма потоков данных Диаграмма потоков данных (data flow diagram, DFD) – один из основных инструментов структурного анализа и проектирования информационных систем, существовавших в «доюмээльную» эпоху. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем. Исторически сложилось так, что для описания диаграмм DFD используются две нотации – Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом. На приведённой ниже иллюстрации использована нотация Гейна-Сарсона. Клиент Картотека складского учёта Запрос на поставку Зарегистрир овать запрос База данных запросов Зарегистрирован- ный запрос Зарегистрирован- ный запрос Инициировать поставку Остатки База данных поставок Информация о поставке Информировать клиента о поставке Информация о поставке Уведомление о поставке Информационная система принимает извне потоки данных. Для обозначения элементов среды функционирования системы используется понятие внешней сущности. Внутри системы существуют процессы преобразования информации, порождающие новые потоки данных. Потоки данных могут поступать на вход к другим процессам, помещаться (и извлекаться) в накопители данных, передаваться к внешним сущностям. Модель DFD, как и большинство других структурных моделей – иереархическая модель. Каждый процесс может быть подвергнут декомпозиции, т.е. разбиению на структурные составляющие, отношения между которыми в той же нотации могут быть показаны на отдельной диаграмме. Когда достигнута требуемая глубина декомпозиции – процесс нижнего уровня сопровождается мини-спецификацией (текстовым описанием). Кроме того, нотация DFD поддерживает понятие подсистемы – структурной компоненты разрабатываемой системы. Нотация DFD – удобное средство для формирования контекстной диаграммы, т.е. диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это - диаграмма верхнего уровня в иерархии диаграмм DFD. Её назначение – ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда. Другие нотации, часто используемые при формировании контекстной диаграммы – диаграмма SADT 15 , диаграмма Диаграмма вариантов использования. Другие виды моделей Среди многообразия моделей, использующихся в анализе систем, хочется особо отметить ещё две нотации, позволяющие описать сложные многоальтернативные взаимодействия компонент информационной системы – нотацию IDEF3 [17] и eePC- диаграмму ARIS [6]. Для моделирования требований к системам с разветвлённой логикой К.Вигерс рекомендует использовать таблицы и деревья решений [8]. Часто на практике бывают полезны диаграммы сущность-связь и SADT-диаграммы [17]. 15 Марка Д.А. Методология структурного анализа и проектирования. – С.-Пб.: Питер, 1995. – 235 с. Цели прототипирования Всё то, что говорилось в предыдущей лекции об особенностях восприятия человеком вербальной и невербальной информации по отношению к моделям, в ещё большей степени следует отнести и к визуальным прототипам. Рассмотрим основные цели, требующие применения прототипов [8-21]: прояснить неясные требования к системе; выбрать одно из различных концептуальных решений; проанализировать осуществимость. 1. Неясные требования. Часто Заказчику бывает трудно сформулировать требования к тому, что он ожидает от системы. В этом случае прототип интерфейса пользователя (User Interface, UI), оперативно созданный по результатам интервью, даёт ему возможность увидеть схематичную реализацию того, как Исполнитель увидел соответствующую часть системы. Что интересно – в данном случае полезен любой исход прототипирования: если Исполнитель понял требования хорошо – польза очевидна; если не очень – польза заключается в том, что Заказчик может указать, в чём заключается непонимание, тем самым решив основную задачу – сделать неясное ясным. 2. Разные варианты решения. Любую техническую задачу можно решить различными способами. Это касается как задачи формулировки требований, так и её реализации в UI. Рассмотрим пример. Снабженцу поступает входной поток требований на комплектацию заказов материалами. Разные позиции одного и того же требования могут быть закуплены у различных поставщиков. Снабженец должен сопоставить поставщика каждой позиции каждого из требований. Есть как минимум два сценария решения этой задачи. А) Сценарий последовательной обработки требований. А1. Система отображает реестр требований, имеющихся во входной очереди. А2. Пользователь выбирает очередное требование. А3. Система отображает перечень материалов требования и справочник поставщиков. А4. Пользователь сопоставляет каждой из позиций требования поставщика из справочника поставщиков. А5. Система придаёт требованию статус «обработано», высылает по электронной почте автору требования уведомление. А6. Продолжать с шага А1, пока очередь не опустеет. Б) Сценарий группировки по материалам. Б1. Система отображает позиции всех требований и справочник поставщиков. Б2. Пользователь группирует позиции по типу (так, чтобы однотипные позиции, поставляемые одним и тем же поставщиком, находились рядом). Б3. Пользователь выбирает группу позиций и сопоставляет ей поставщика. Б4. Система проверяет – не появились ли полностью обработанные требования. При положительном исходе проверки присваивает этим требованиям статус «обработано» и высылает по электронной почте автору требования уведомление. Б5. Продолжать с шага Б1, пока очередь не опустеет. Первый сценарий удобен тем, что позволяет снабженцу работать в разрезе авторов требований, начать с самых критичных по времени требований, контролировать процесс их обработки. Второй сценарий удобен тем, что позволяет одновременно наблюдать на экране строки разных требований, объединяя их в единый заказ. После реализации прототипов UI по первому и второму сценариям Заказчик, оценив их достоинства и недостатки, смог в диалоге с Разработчиком сформулировать третий, комбинированный сценарий, сочетающий достоинства первых двух. 3. Анализ осуществимости. Часто бывает так, что комбинация функциональных, нефункциональных требований и ограничений такова, что возникает риск невозможности их реализации. Как правило, такой риск связан с требованиями к быстродействию системы при известных ограничениях среды её реализации. В этом случае создаются прототипы (не обязательно, связанные с UI), реализующие соответствующую часть системы, имитирующие потоки данных, поступающие на её вход и их обработку. Классификация прототипов Вслед за К. Вигерсом [8] рассмотрим следующие классификации прототипов: горизонтальные и вертикальные; одноразовые и эволюционные; бумажные и электронные, раскадровки 16 Горизонтальный прототип Горизонтальный или поведенческий прототип (horizontal prototype, behavioral prototype) моделирует интерфейс пользователя приложения, не затрагивая логику обработки и базу данных. Если в разработанном интерфейсе используются фрагменты базы данных – они имитируются в программном коде. При этом тексты, отображаемые на экране, должны отражать реальную специфику проблемной области, иначе пользователю будет трудно сосредоточиться. Если при нажатии на элемент управления должны производиться какие- то расчёты или запросы во внешние системы – результаты запросов также имитируются. Желательно реализовать ту часть кода, которая отвечает за перемещение между экранами в процессе исполнения вариантов использования, чтобы пользователь смог понять, как будет действовать система в ответ на его действия. Горизонтальные прототипы следует использовать для достижения цели прояснения неясных, либо многоальтернативных требований. Вертикальный прототип Вертикальный или структурный прототип (vertical prototype, structural prototype) не ограничивается интерфейсом пользователя. Он реализует вертикальный «срез» системы, затрагивая все уровни её реализации. При создании такого рода прототипов рекомендуется использовать те языки и среды реализации, что и при изготовлении целевой системы (что, вообще говоря, совсем не обязательно для горизонтальных прототипов). Основные цели применения такого рода прототипов – анализ применимости, проверка архитектурных концепций. Одноразовый прототип Одноразовый или исследовательский прототип (throwaway prototype, exploratory prototype) создаётся, когда нужно быстро промакетировать те или иные аспекты и компоненты системы. Целям создания исследовательских прототипов служит технология RAD (rapid application development) – быстрая разработка приложений 17 , см. материалы лекции 3 16 Понятие раскадровки [22] отсутствует в классификации Вигерса, но хорошо её дополняет. 17 Строго говоря, данная технология разрабатывалась не только для целей создания одноразовых прототипов, но и для реально действующих систем. Однако, приложения, созданные по технологии RAD на современном уровне её развития, редко бывают жизнеспособными, в первую очередь за счёт недостаточного быстродействия. Одноразовый прототип должен создаваться быстро. При его разработке не следует уделять внимание вопросам повторного использования кода, качества, быстродействия, технологичности и т.п. В результате получается «сырой» код, который может содержать значительное количество дефектов. Необходимо принять меры к тому, чтобы фрагменты кода, реализующие такого рода прототипы, не стали частью целевой системы. К. Вигерс приводит следующую схему перехода от одноразового прототипа к детально проработанному UI: На рисунке присутствует новое, не раскрытое ранее не понятие: «карта диалога», говорят также «схема диалога». Прежде, чем создавать горизонтальный прототип, необходимо определиться – какие основные экраны будут присутствовать, какие окна будут открываться, какие правила перехода между ними будут поддерживаться. Информация такого рода хорошо ложится на модель диаграммы состояний, см. материалы лекции 5 , где разным экранам (окнам) сопоставляются состояния, а активным элементам управления, вызывающим закрытие одних интерфейсных элементов и открытие других – переходы. Эволюционный прототип Эволюционный прототип (evolutionary prototype) создаётся, как первое приближение системы, призванное стать впоследствии самой системой. Код эволюционного прототипа должен последовательно, в течении одной или более итераций, перерасти в код целевого приложения. Поэтому данный вид прототипов требует всего того, от чего следует отказаться при создании одноразовых прототипов: скрупулёзной разработки, применения технологических методов и приёмов, тестирования результатов и т.п. В таблице приведено соотношение между рассмотренными выше 4 видами прототипов [8]. Одноразовые Эволюционные Горизон- тальные Прояснение и уточнение примеров использования и функциональных требований Выявление пропущенных требований Исследование возможных вариантов интерфейса пользователя Реализация базовых вариантов использования Реализация дополнительных вариантов использования по приоритетам Реализация и доработка web- сайтов Адаптация системы к быстро меняющимся требованиям бизнеса Вертикаль- ные Демонстрация технической осуществимости Реализация и наращивание ключевой клиент-серверной функциональности и уровней коммуникации Реализация и оптимизация основных алгоритмов Тестирование и настройка производительности Бумажный прототип Бумажный прототип (paper prototype) – отличная альтернатива рассмотренным выше разновидностям электронных прототипов в случае, когда Разработчик ограничен в ресурсах. Наброски интерфейсов на бумаге, конечно, не заменят интерфейс, созданный в среде разработки. Однако, при всех недостатках, у таких прототипов есть два существенных достоинства. 1. Заказчик не станет акцентировать внимание на цветовом решении, форме кнопок и т.п., отвлекаясь от анализа функциональности. 2. Заказчик никогда не скажет, глядя на бумажный интерфейс: «Да вы, я вижу, уже создали систему на 85%! Давайте закончим её в течении недели». |