2.2.5. Глава 2. Проектная часть
Проектная часть дипломного проекта является описанием решений, принятых по всей вертикали проектирования. Глава должна быть основана на информации, представленной в аналитической части, обобщать ее. По сути, проектная часть является решением проблематики, изложенной в аналитической части, на языке информационных технологий. Поэтому недопустимо, если при проектировании используется информация об объекте управления, не описанная в первой главе.
Проектная часть дипломного проекта должна содержать следующие разделы:
2. ПРОЕКТНАЯ ЧАСТЬ
2.1. Информационное обеспечение задачи
2.1.1. Описание прецедентов. Диаграмма прецедентов
2.1.2. Описание типичного хода событий
2.1.3. Модель предметной области (концептуальная модель)
2.2. Диаграмма последовательности. описание системных операций
2.3.Диаграммы взаимодействия (коопераций и последовательностей), распределение обязанностей между классами
2.4. Диаграмма классов
2.5.Реальные прецеденты и пользовательский интерфейс
Диаграмма состояний
Диаграмма развертывания.
Описание прецедентов
Процессы предметной области могут описываться в форме прецедентов – словесных описаний в структурированном формате.
Прецедент – это набор взаимосвязанных успешных и неудачных сценариев, описывающий использование системы исполнителем для решения одной из задач. Шаблон описания идеального прецедента приведен в табл. 1.
Таблица 1
Шаблон описания идеального прецедента
Название прецедента |
Осмысленное название, определяющее основную функцию прецедента |
Исполнитель |
Лицо, инициирующее и реализующее работу сценария |
Цель |
Основное назначение выполнения прецедента |
Описание |
Типичный ход событий, который приводит к успешному завершению сценария |
Тип |
Тип прецедента: идеальный либо реальный |
Ссылки |
Функции, которые выполняет система в процессе выполнения прецедента |
Для выделения прецедентов используются следующие процедуры.
1. Определение рамки системы: является ли она программным приложением, аппаратно-программным комплексом, включает ли в себя своих пользователей или всю организацию?
2. Идентифицикация основных исполнителей, потребности (цели) которых удовлетворяются с помощью системы.
3. Определение задач для каждого исполнителя.
4. Определение прецедентов, удовлетворяющих потребности каждого исполнителя, и присвоение им имен в соответствии с задачами.
Диаграмма прецедентов описывает типичное взаимодействие между пользователем и системой. На данной диаграмме прецедентов человеческие фигурки обозначают действующих лиц, овалы – прецеденты, а линии и стрелки – различные связи между действующими лицами и прецедентами.
Диаграмма прецедентов, как правило, отражает требования к системе с точки зрения пользователя. Таким образом, прецеденты – это функции, выполняемые системой, а действующие лица – это заинтересованные лица по отношению к создаваемой системе. Такие диаграммы показывают, какие действующие лица инициируют прецеденты.
Сценарии прецедента следует выделять в отдельные прецеденты, связанные отношением включает (include), при выполнении следующих условий:
эти сценарии дублируются в других прецедентах.
прецедент является очень сложным и длинным, поэтому выделение сценариев в отдельный прецедент позволит значительно его упростить.
Взаимосвязь расширяет (extend) предоставляет дополнительную возможность в том случае, когда основной прецедент нельзя модифицировать. Основная идея заключается в создании расширяющего или дополнительного прецедента, в котором описывается, где и при каких условиях он расширяет некоторый основной прецедент.
Описание типичного хода событий
Типичный ход событий – обеспечивает наглядное представление общения с системой.
Как правило, типичный ход событий описывают с использованием таблицы, где в первой колонке приводятся действия внешних исполнителей, а во второй колонке - отклик системы на действия исполнителей. В табл. 2 приведен шаблон описания типичного хода событий.
Таблица 2
Шаблон описания типичного хода событий
Действия исполнителя |
Отклик системы |
|
|
|
2. … |
Концептуальная модель
Модель предметной области – это визуальное представление концептуальных классов или объектов реального мира в терминах предметной области. Такие модели также называют концептуальными моделями.
Для создания модели предметной области необходимо выполнить следующие действия.
Выделить концептуальные классы.
Отобразить их в модели предметной области в виде классов на диаграмме UML.
Добавить необходимые ассоциации и атрибуты.
На рис. 1 приведен фрагмент модели предметной области, составленной при проектировании информационной системы для автоматизации работы торговой точки.
Рис. 1. Фрагмент модели предметной области
Основная проблема построения модели предметной области состоит в выделении концептуальных классов.
Класс – описание множества объектов с одинаковыми атрибутами, связями и семантикой. Изображается в виде прямоугольника. Обозначение класса состоит из трех частей, в которых указываются имя класса, его атрибуты и методы.
Атрибут – именованное свойство класса, описывающее диапазон значений, которые может принимать экземпляр атрибута. Можно уточнить спецификацию атрибута, указав его класс и начальное значение по умолчанию.
Операция – реализация услуги, которая может быть запрошена у любого объекта данного класса, чтобы вызвать определенное его поведение. Можно специфицировать операцию, указав тип и значение по умолчанию всех параметров, а для функций тип возвращаемого значения.
В процессе разработки модели предметной области также необходимо идентифицировать связи (ассоциации) между концептуальными классами.
Ассоциация (association) – это отношение между классами, отражающая некоторые значимые и полезные связи между ними. Ассоциация обозначается проведенной между классами линией, с которой связано определенное имя, начинающееся с большой буквы.
Обобщение – отношение между более общим элементом и более конкретным. Отношение обобщения в UML изображается при помощи сплошной линии жирной треугольной стрелки, ведущей от подкласса к суперклассу. Дочерняя сущность наследует свойства родителя, его атрибуты и операции. Потомок может иметь дополнительные атрибуты и операции, помимо родительских.
Зависимость – связь, которая устанавливает, что одна сущность использует информацию и сервис (операцию либо услугу), предоставляемые другой сущностью. Изображается в виде пунктирной линии со стрелкой, направленной на зависимую сущность.
Диаграмма последовательностей
Диаграмма последовательности – одна из диаграмм взаимодействия. На диаграмме последовательностей иллюстрируются события, инициированные в системе исполнителями.
На рис. 2 представлен пример диаграммы последовательности для прецедента Оформление продажи.
Рис. 2. Диаграмма последовательности прецедента Оформление продажи
Системные диаграммы последовательностей определяют системные операции, которые являются начальными сообщениями для диаграмм взаимодействия.
Системные операции
Системное событие – это внешнее входное событие, сгенерированное для системы исполнителем. Событие инициирует выполнение определенной операции. Системная операция является операцией, которую система выполняет в ответ на сгенерированное событие. Описание системной операции – это документ, описывающий предполагаемые результаты выполнения операций. Обычно он акцентирует внимание на том, что должно произойти, а не на том, как этого достичь.
Ниже в табл. 3 представлен шаблон описания системных операций.
Таблица 3
Шаблон описания системной операции
Операция |
Имя операции и ее параметры |
Ссылки |
Прецеденты, в рамках которых может выполняться эта операция |
Предусловия |
Предположения о состоянии системы или объектов модели предметной области до выполнения операции. Выполнение этих условий не проверяется в рамках логики выполнения данной операции, а предполагается, что они истинны. Это нетривиальные условия, на которые студент должен обратить внимание |
Постусловия |
Это самый важный раздел. Состояние объектов модели предметной области после завершения операции |
Диаграммы взаимодействия (кооперации и последовательности)
Диаграммы кооперации, так же как и диаграммы последовательности, относятся к диаграммам взаимодействия. Они иллюстрируют взаимодействие объектов в формате графа или сети, отражают потоки сообщений между программными объектами и вызовы методов.
Связь является соединением между двумя экземплярами классов, которое определяет некоторую форму перемещения и видимости между ними. Передаваемые между объектами сообщения представляются в виде имен этих сообщений над линиями связей, помеченных стрелками. Над одной линией связи может быть указано любое количество сообщений. Для отображения порядка следования сообщений в текущем потоке управления рядом с сообщением приводится порядковый номер.
На рис. 3 и 4 представлена диаграмма последовательности makePayment и диаграмма кооперации makePayment соответственно.
Рис. 3. Диаграмма последовательности makePayment
Рис.
4. Диаграмма кооперации makePayment
Диаграмма классов
Диаграммы классов являются центральным звеном объектно-ориентированных методов. Они составляются на основе концептуальной модели, однако иллюстрируют взаимоотношения программных элементов, а не понятий из предметной области. На рис. 5 приведен пример диаграммы классов для системы NextGen.
Рис.5. Диаграмма классов системы NextGen
Диаграммы классов предназначены для статического моделирования объектов.
Реальные прецеденты и пользовательский интерфейс
Реальный прецедент описывает конкретное проектное решение по реализации идеального прецедента в терминах выбранной технологии. Описание реальных прецедентов аналогично описанию идеальных прецедентов (табл. 4).
Таблица 4
Шаблон описания реального прецедента
Название прецедента |
Осмысленное название, определяющее основную функцию прецедента |
Исполнители |
Лицо, инициирующее и реализующее работу сценария |
Цель |
Основное назначение выполнения прецедента |
Описание |
Типичный ход событий, который приводит к успешному завершению сценария |
Тип |
Тип прецедента: идеальный либо реальный |
Ссылки |
Ссылки на функции и идеальные прецеденты, которые выполняет система в ходе реального прецедента |
На рис. 6 приведен пример интерфейсной формы для прецедента Оформление продажи. Интерфейсные формы имеет смысл составлять для каждого реального прецедента.
Рис. 6. Интерфейсная форма для прецедента Оформление продажи
Диаграмма состояний
Диаграммы состояний используются для моделирования динамических аспектов системы. На рис. 7 приведен пример диаграммы состояний.
Диаграммы состояния применяются для моделирования поведения сложных объектов, реагирующих на внешние события, а также для моделирования допустимых последовательностей операций – спецификаций протоколов или языков.
Рис. 7. Диаграмма состояний для прецедента Оформление продажи
Диаграмма состояний отражает жизненный цикл объекта. На них отображаются события, в которых участвует данный объект, переходы и состояния объекта между событиями. Диаграммы состояния позволяют описывать жизненный цикл объекта с произвольной степенью детализации или упрощения, в зависимости от текущих потребностей.
Событие (event) – это значимое или заслуживающее внимания происшествие.
Состояние (state) – условие, характеризующее объект в некоторый момент между двумя состояниями.
Переход (transition) – это такое отношение между двумя состояниями, которое указывает на переход объекта из одного состояния в другое при выполнении некоторого события.
Диаграмма развертывания.
Диаграммы развертывания - диаграммы, используемые при моделировании физических аспектов объектно-ориентированной системы. Такая диаграмма показывает конфигурацию узлов, где производится обработка информации, и то, какие компоненты размещены на каждом узле.
Основной элемент диаграммы развертывания – узел, который может относиться к одному из двух типов:
узел устройства – физический вычислительный ресурс с памятью и процессорным элементом, на котором работает программное обеспечение. Например, компьютер или мобильный телефон;
исполняющий узел окружения – программный вычислительный ресурс, работающий в рамках другого узла и обеспечивающий выполнение других выполняемых программных элементов. Например, операционная система, виртуальная машина, система управления базами данных, Web-браузер и т. д.