Внесение изменений в проектное решение takeCard

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

Для исправления этой ситуации нам необходимо внести новый концептуальный класс Attempt в предметную область (рис. 7).

Рисунок 7 - Исправленная модель предметной области

Соответственно, необходимо зафиксировать изменения и в описании операции.

Описание операции ОП1: takeCard

Операция takeCard(studentID:integer).

Ссылки Прецеденты: Получение билета.

Предусловия Студент успешно зарегестрирован на экзамене и имеет идентификатор.

Постусловия - Создан экземпляр card класса Card (создание экземпляра).

- Атрибуту card.timeOfBegin присвоено значение time (модификация атрибута).

- Экземпляр card связан с классом CardDescriptor на основе соответствия идентификатора (номера) билета (формирование ассоциации).

- Атрибут pickCount экземпляра класса CardDescriptor,ассоциированного с экземпляром card, изменен (модификация атрибута).

- Экземпляр card связан с классом Student на основе соответствия идентификатора студента (формирование ассоциации).

- Создан экземпляр a класса Attempt (создание экземпляра).

- Инициализированы все атрибуты объекта a соответствующими контексту значениями (модификация атрибута).

- Объект a связан с классом AttemptStorage (формирование асоциации).

Теперь внесем изменения в диаграмму взаимодействий (рис. 8).

Рисунок 8 - Исправленная диаграмма взаимодействия для takeCard

На рис. 8, кроме всего прочего, был добавлен фрейм, отражающий наличие альтернативного сценария прецедента. Кроме того, объект Card теперь является временным, несмотря на то, что описание операции ничего об этом не говорит.

И в последнюю очередь внесем изменения в диаграмму классов проектирования (рис. 9).

Рисунок 9 - Исправленная диаграмма классов проектирования для takeCard

На диаграмме (рис. 9) не показан класс Attempt в силу его тривиальности.

Заключение

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

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

Главный акцент в данном пособии делается на усвоении и последующем использовании на практике подхода к проектированию на основе распределения обязанностей. С этой точки зрения, процесс UP можно разделить не на модели, а на два этапа: этап формулирования обязанностей и этап распределения (назначения) обязанностей.

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

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

Содержание отчета

1. Титульный лист.

2. Текст задания на курсовое проектирование.

3. Содержание.

4. Содержательная часть проектирования, выполненная в соответствии с критериями выполнения курсового проектирования.

5. Словарь терминов.

6. Список литературы.

7. Развернутые тезисы доклада на защите проекта с указанием авторов каждого тезиса.

Приложение 1