maran program engineering (830029), страница 11
Текст из файла (страница 11)
Затем системный аналитик реструктурирует модель, определяя общие части вариантов использования. Для завершения этой работы требуется 1−2 итерации.Действующих лиц и варианты использования выделяют для:• отделения системы от окружения;• определения, какие действующие лица взаимодействуют с системой икакие функциональные возможности ожидаются от системы.Системный аналитик совместно с заказчиком должен идентифицироватьпотенциальных пользователей и разделить их по категориям.
При этом надоиметь в виду следующее:• при выявлении кандидата в действующее лицо следует найти хотя быодного пользователя, который в состоянии оценить его и который былбы реальным его представителем;• перекрытие ролей разных действующих лиц должно быть минимальным, другими словами, мы должны четко сформулировать, чем отличаются разные кандидаты в действующие лица.Выделенные действующие лица должны быть идентифицированы иснабжены кратким описанием.При определении вариантов использования надо помнить, что каждыйвариант должен приносить для действующих лиц ценный для них результат.Кроме того, мы должны четко сформулировать, чем отличаются различные варианты использования.
Каждый выделенный вариант использования должениметь имя и краткое описание. В дальнейшем в ходе детализации вариантовиспользования должны быть получены ответы на следующие вопросы.1. При каких предусловиях вариант использования может быть запущен,что делать, если предусловия не выполнены (например, из-за ошибокдействующего лица)?2. Какие существуют пути реализации варианта использования: выбираемые действующим лицом или зависящие от хода выполнения?3.
Как заканчивается выполнение варианта использования? Какие имеются конечные состояния? Как о результате узнает действующее лицо?554. Какие существуют запрещенные пути выполнения? Как предотвращается их запуск? Должно ли передаваться сообщение о попытке их запуска?5. Что в процессе выполнения делает действующее лицо и что делаетпрограмма?6.
Какие исходные данные (пока на качественном уровне) требуются отдействующего лица?7. Если один и тот же вариант использования связан с двумя или болеедействующими лицами, зависит ли его выполнение от очередности егозапуска?Результаты проведенного анализа можно оформлять в виде табл. 4.2. Обращаем еще раз внимание на то, что диаграмма вариантов использования должна дать ответ на вопрос «Что должна делать создаваемая программа?», недопустимо превращать ее в диаграмму функциональной декомпозиции!Таблица 4.2НазваниеНазвание варианта использованияКраткое описаниеДействующие лицаПредусловие запускаОсновной путь выполненияПостусловиеАльтернативный(ые) путь(и) выполненияПостусловия альтернативного путиЗначениеВ более сложных случаях можно рекомендовать использовать для этойцели диаграмму активности (показывая на ней процесс выполнения или хотя быего основные моменты).При разработке прототипов пользовательских интерфейсов для действующих лиц необходимо получить ответы на следующие вопросы:1.
Какие элементы пользовательского интерфейса необходимы ему длявыполнения его вариантов использования?2. Какие действия он может производить?3. Какую информацию он должен вводить при запуске различных вариантов использования?4. Каким образом он будет информирован о результатах выполнения(с учетом того, что ход выполнения и результат могут быть различными)?В завершение выполняется структурирование модели вариантов использования, в ходе которого:• извлекаются общие и совместно используемые разными действующими лицами описания функциональности;56• извлекаются дополнительные и необязательные описания функциональности;• проводят классификацию действующих лиц.В результате выполнения перечисленного в диаграммах вариантов использования могут появиться отношения обобщения между действующими лицами и отношения расширения и включения между вариантами использования.Подведем итоги.
В результате выполнения работ по определению требований должны быть получены (программа-минимум):1. Описание контекста системы.2. Модель вариантов использования (одна или несколько диаграмм).3. Эскизы интерфейсов пользователей для всех действующих лиц.4. Описания вариантов использования.5. Основные нефункциональные требования.4.3.
Уточнение и структурирование требованийВ результате выполнения предыдущей стадии жизненного цикла мыимеем модель вариантов использования, которая описана понятными заказчикусредствами, дает ответы на вопросы «Что должна делать программа?», «Какимхарактеристиками должна обладать программа?» и ввиду своей специфики может содержать неточности и неоднозначности. На этом заканчиваются предпроектные исследования и начинается собственно разработка.На предстоящей стадии жизненного цикла мы должны разработать аналитическую модель, которая составлена на языке разработчика, описывает реализацию функциональности, не должна содержать неопределенностей и неоднозначностей и может служить основой для проектирования.Центральной задачей является составление модели классов анализа (состоит из диаграмм классов).
Для этого необходимо выделить классы анализа иопределить отношения между ними. Классы анализа обладают следующимихарактеристиками:• сосредоточены на представлении функциональных требований, откладывают нефункциональные требования до фазы проектирования;• имеют атрибуты, но в основном на концептуальном уровне, без уточнения типов и структур данных;• их операции заданы концептуально — что надо делать?• имеют отношения с другими классами, но эти отношения концептуального значения.Составление модели классов желательно начинать с выделения классовсущностей.
Напомним, они предназначены для хранения условно-постоянныхданных, необходимых при выполнении вариантов использования. Такие классыназывают стабильными. Определение их структуры выполняется методамипроектирования баз данных (в простых случаях можно ограничиться применением файлов). На данном этапе следует определить лишь состав хранимых данных.
Операции таких классов, как правило, простые: добавление, удаление, изменение данных и выдача данных по запросу. Однако нельзя упустить следую57щее: каким образом будет выполняться внесение изменений? Это делается ужевыделенными вариантами использования или нет. В противном случае придется добавить новые варианты использования для обслуживания этих данных.Как показывает практика, часто труднее всего следить за изменениями редкоизменяемых данных.Классы анализа должны отражать ключевые понятия предметной области, объекты этих классов должны обеспечивать решение всех выделенных вариантов использования.
Согласно [8], хороший класс обладает следующимипризнаками:• имя означает назначение;• ему соответствует конкретный объект предметной области;• у него четко определенный набор обязанностей — операций;• у него высокая внутренняя связность (его операции обрабатывают его жеданные);• у него низкая связанность с другими классами.Рекомендованы следующие количественные характеристики:• у класса не более 5 обязанностей, т. е.
функций, доступных извне;• классы связаны между собой отношениями;• не должно быть классов, где одни данные или одни операции;• уровней обобщения не более 3.Для выявления состава классов анализа рекомендуют написать словесноеописание предметной области, существительные и устойчивые словосочетанияявляются кандидатами на классы и атрибуты, глаголы — кандидаты на операции. В процессе определения классов анализа рекомендуют использовать CRTкарты (class — responsibilities — collaborators; класс — обязанности — участники), представленные на рис. 4.1.Имя класса:Обязанности (операции)Связи с другими классамиРис. 4.1Размер CRT-карты не более 5–7 сантиметров (чтобы нельзя было создатьслишком большие классы). Заполнение CRT-карт выполняется в два этапа:сбор информации для их первоначального заполнения и анализ полученнойинформации для определения окончательного их состава.
Как любой процесспроектирования, этот процесс тоже итеративный. После определения составаклассов необходимо определить отношения между ними. Состав отношенийбыл рассмотрен выше. Отношение обобщения часто задает классификациюмежду классами анализа. Напомним, что все что записано для класса-предка,должно остаться в силе для всех его наследников без всяких ограничений.58Можно рекомендовать при наличии многих общих атрибутов и операций у нескольких классов специально ввести для них обобщающий класс, компонентами которого они будут. Для отношения ассоциации важно не забыть указатьих мощность, эта информация будет очень полезна при проектировании.Следующей задачей при уточнении и структурировании требованийявляется составление диаграмм деятельности для всех вариантовиспользования (может быть, за исключением самых простых).
Помните, впредыдущем разделе мы говорили о необходимости в процессе определениятребований задать для каждого варианта использования основной иальтернативные пути выполнения. Теперь настала пора проанализировать иотразить на диаграмме деятельности все возможные пути выполнения.Например, человек подошел к банкомату и хотел снять наличные. Основнойпоток очевиден: он их получил в желаемом количестве. Для определенияальтернативных потоков следует тщательно проанализировать все причины,по каким основной поток не может быть выполнен. Программа управлениябанкоматом должна обрабатывать все эти случаи, сообщить пользователю опричинах неудач и восстановить исходное состояние.Возникает еще одна проблема, решение которой находится за пределами программной инженерии.
Мы моделируем с помощью диаграмм деятельности процессы такими, как они выполняются в настоящее время (называютэто as-is). В общем случае протекание этих процессов может претерпеть заметные изменения после внедрения разрабатываемого программного обеспечения, особенно при разработке информационных систем. Поэтому требуетсяразработать диаграммы деятельности для протекания этих процессов послевнедрения (называют это to-be). Эти вопросы необходимо обговорить с заказчиком.Следующей задачей является создание диаграмм кооперации, показывающих участие объектов при выполнении вариантов использования. Диаграмма кооперации состоит из объектов и их взаимосвязей, которые отражают передачу сообщений между ними.
Напомним, что объект — это реальносуществующий предмет со всеми своими индивидуальными характеристиками, выраженными значениями его свойств. Класс — это множество объектов,имеющих одинаковые свойства (список характеристик) и одинаковое поведение (состав методов). Минимальное количество диаграмм кооперации равноколичеству вариантов использования. Каждая из них показывает, какие объекты каких классов будут задействованы при его выполнении. Связь между объектами на этой диаграмме показывает, что между этими объектами осуществляется обмен сообщениями в ходе выполнения варианта использования. Сутьэтих сообщений и их временнáя очередность будут уточнены в ходе проектирования.Составление диаграммы кооперации позволяет критически осмыслить составленную ранее диаграмму классов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
