Пример спецификация последовательностей

Построимдиаграмму последовательностей для прецедента «EnterProgramofStudy».

На рисунке 4 показана диаграмма последовательностей дляприведенного выше сценария. Субъект DataEntryPerson (Лицо, вводящееданные) инициирует прецедент, отправляя сообщение с запросом объектуграничного класса ProgramEntryWindow (Окно программы ввода) длятого, чтобы добавить студента (обозначенного аргументом std) к спискузаписавшихся на курс (аргумент crs) в данном семестре (аргумент sem).

Объект класса ProgramEntryWindow проверяет с помощью объектаaStudent, имеет ли право студент записаться (например, внес ли студентs_check соответствующую плату). Выходной аргумент возвращаетзначение «yes» или «no» объекту: ProgramEntryWindow. Есливозвращается значение «no», запись не может продолжаться, и объект:ProgramEntryWindow отправляет автосообщение самому себе, чтобыуничтожить (destroy) себя (операция деструктора). Запись условия вквадратных скобках говорит о том, что операция деструктора являетсянеобязательной.

Использование автосообщения для указания на необходимостьуничтожения объекта является просто сокращенной записью.

В действительности объект_экземпляр не может уничтожить себя.

Сообщение об уничтожении (destroy) должно быть отправленообъекту_классу. Кроме того, в языке UML имеется специальноеобозначение для операции уничтожения объекта — большой знак Х,помещенный на жизненной линии объекта в точке, в которой объектдолжен быть уничтожен.

Если студент aStudent может быть записан, нам требуется выяснить,открыта ли запись на курс aCourse. Для обслуживания этого требования объект aCourse должен запросить свой текущий объект aCourseOffering(на который указывает агрегативная связь от Course к CourseOffering (рисунок 4)). Если в текущем объекте aCourseOffering свободных мест уже нет,запись не может продолжаться, и объект :ProgramEntryWindow сноваотправляет себе автосообщение, чтобы разрушить себя.

Рисунок 4 – Диаграмма последовательностей

Если процесс записи может продолжаться, объект: ProgramEntryWindow требует от объекта aStudent добавить себе объектaCourseOffering, а затем требует, чтобы объект aCourseOffering добавил объектaStudent к себе. Последовательность двух операций объекта: ProgramEntryWindow может быть изменена на обратную, если программагарантирует ссылочную целостность между aCourseOffering и aStudent (т.е. если студент записался на предлагаемый курс, то в список студентов поданному курсу должен быть внесен данный студент).

Если для хранения объектов Student и CourseOfferingиспользуется ПО СУБД, то объект :ProgramEntryWindow мог быотправлять только одно из этих двух сообщений, т.е. отправить либосообщение addCourse, либо сообщение addStudent.

После того как объект aStudent добавлен к объекту aCourseOffering,ПО СУБД берет на себя ответственность за поддержание ссылочнойцелостности и должно зафиксировать существование связи от aStudent кaCourseOffering, и наоборот.

Фактические аргументы, включенные в сообщения addCourse и addStudent, представляют собой идентификаторыобъектов (OID), содержащие значения OID (дескрипторы), указывающиена объект aStudent и aCourseOfferin, соответственно. Эти значения OIDбыли определены, когда объект :ProgramEntryWindow получил доступ кобъектам aStudent и aCourse с помощью сообщений areYouValid иareYouOpen, представляющих собой запросы на возможность записи иналичие мест на курсе.

Задание

Составить спецификацию установленных в лабораторной работе №10 требований для проектируемой ИС. Для составления спецификации использовать язык UML. Модели спецификации разделить на три группы:

- модели состояний;

- модели поведений;

- модели изменения состояний.

Построить UML-диаграммы к каждой группе моделей проектируемой системы и написать комментарии к ним. UML-диаграммы необходимые построить: вариантов использования системы, деятельности, взаимодействия объектов, классов и развертывания.

Построение UML-диаграмм желательно осуществлять с помощью CASE-средств (StarUML, Rational Rose, MS Visio 2003 идр.).

Список индивидуальных данных

Вариант 1. АСУ деятельностью отдела кадров предприятия

Вариант 2. АСУ складского хранения

Вариант 3. АСУ деятельностью библиотеки

Вариант 4. Веб-магазин по продаже часов

Вариант 5. Веб-магазин по продаже фотоаппаратов

Вариант 6. АСУ деятельностью аптечной сети

Вариант 7. Веб-сайт букмекерской конторы

Вариант 8. ИС учета успеваемости студентов

Вариант 9. Веб-магазин по продаже компьютерных комплектующих

Вариант 10. Программный RSS-агрегатор

Вариант 11. Веб RSS-агрегатор

Вариант 12. ИС «Ежедневник»

Вариант 13. АСУ деятельностью магазина видеопроката

Вариант 14. АСУ деятельностью автосалона

Вариант 15. Веб-магазин по продаже одежды

Вариант 16. ИС «Почтовый коллектор»

Вариант 17. АСУ деятельностью магазина бензозаправки

Вариант 18. АСУ учетом пациентов в поликлинике

Вариант 19. АСУ учетом коммунальных платежей

Вариант 20. АСУ деятельностью службы такси

Вариант 21. ИС сбора и обработки ошибок (багтрекер)

Вариант 22. Веб-сайт кафедры

Вариант 23. Веб-сайт факультета

Вариант 24. ИС хранения и каталогизации фотографий

Вариант 25. ИС «Каталог недвижимости»