Разработка имитационной модели программного обеспечения информационной системы "Центр обслуживания абонентов" (стр. 5 из 7)
Оператор получает от клиента заявление на получение детализации счета, проверяет соответствие личности и паспорта. Если паспорт не принадлежит будущему абоненту, ему отказывают. Далее идет проверка на наличие ошибок в заявлении. При их отсутствии выдается детализация счета за необходимый период. При наличии ошибок выдается новая форма заявления.
Замена SIM-карты:
Рис.14. Диаграмма видов деятельности для прецедента Замена SIM-карты
Оператор получает от клиента заявление на Замену sim-карты, проверяет соответствие личности и паспорта. Если паспорт не принадлежит будущему абоненту, ему отказывают. Далее идет проверка на наличие ошибок в заявлении. При их отсутствии рассматривается причина, если она удовлетворительная, то карты заменят. При наличии ошибок выдается новая форма заявления.
Выбор оператора связи:
Рис.15. Диаграмма видов деятельности для прецедента Выбор оператора связи
Выбор оператора связи после ознакомления со всеми возможными вариантами, изучение тарифов. Далее заключается договор об оказании услуг связи и абонент может подключиться к сети.
2.4 Моделирование взаимодействий
Взаимодействие объектов в системе происходит посредством приема и передачи сообщений объектами-клиентами и обработки этих сообщений объектами-серверами. Чтобы отразить последовательность передачи сообщений между объектами, для каждого прецедента использования может быть построена модель динамического взаимодействия объектов, которая представляется в одной из двух форм:
в форме диаграммы последовательностей (sequence diagram), на которой основное внимание уделяется временной упорядоченности событий. На них изображают множество объектов и посланные или принятые ими сообщения. Объекты, как правило, представляют собой экземпляры классов.
в форме диаграммы кооперации (collaboration diagram), которая отражает структурную организацию объектов, принимающих или отправляющих сообщения. На диаграмме кооперации показано множество объектов, связи между ними и сообщения, которые они посылают или получают.
Диаграммы последовательностей и кооперации относятся к динамическому виду системы. Они изоморфны, то есть их можно преобразовывать друг в друга без потери информации. Поэтому мною в работе будет рассмотрена лишь диаграмма последовательности, из которой при желании можно получить и кооперацию объектов.
Для диаграммы последовательности ключевым моментом является динамика взаимодействия объектов во времени. При этом диаграмма последовательности имеет как бы два измерения. Одно представлено слева направо в виде линии жизни (lifeline) (период времени существования) отдельного объекта, участвующего во взаимодействии, а второе - вертикальной временной осью, направленной сверху вниз. Взаимодействие объектов реализуется посредством сообщений, посылаемые одними объектами другим. Сообщения появляются в том порядке, в котором они показаны - сверху вниз.
Заключение договора:
Рис.16. Диаграмма последовательности Заключение договора
Для Заключения договора клиенту необходимо передать подписанный договор оператору, который в последствии открывает главное окно. Далее он должен выбрать регистрацию. Вводятся сведения в пограничный класс Окно регистрации окно составления договора, заполняет появившуюся форму. Система управления проверяет введенные данные и сохраняет договор. Затем в контейнерном классе Клиент сохраняется информация о новом клиенте.
Ниже приведена диаграмма кооперации для рассмотренного варианта использования
Заключение договора:
Рис.17. Диаграмма кооперации Заключение договора
Детализация счета:
Рис.18. Диаграмма последовательности Детализация счета
Оператор открывает главное окно системы, затем окно документа, а именно окно детализации счета. Далее формирует отчет путем передачи сообщения управляющему классу Система управления критерии времени. В окне детализации отображается перечень всех звонков, удовлетворяющих требованию клиента. Документ, отобразившийся в окне, оператор может распечатать.
Ниже приведена диаграмма кооперации для рассмотренного варианта использования.
Блокировка номера:
Рис. 19. Диаграмма последовательности Блокировка номера
Оператор открывает главное окно системы, затем окно документа, а именно окно блокировки. Далее путем передачи сообщения управляющему классу Система управления, блокирует номер. Система управления выполняет заданный запрос, сохраняет свои действия и информирует об этом.
Ниже приведена диаграмма кооперации для рассмотренного варианта использования.
Блокировка номера:
Рис. 20. Диаграмма кооперации Блокировка номера
2.5 Моделирование состояний
Следующим этапом разработки является моделирование состояний, необходимая информация для которого содержится в модели классов-сущностей и модели взаимодействий. Модель классов представляет классы, которые подлежат анализу на предмет выявления нетривиального поведения, а модель взаимодействий помогает определить методы, которые могут влиять на изменение состояний классов.
Состояние можно рассматривать как отдельную ситуацию, в течение которой имеет место выполнение некоторого условия. Состояние может быть задано в виде набора конкретных значений атрибутов класса или объекта, при этом изменение их отдельных значений будет отражать изменение состояния моделируемого класса или объекта.
Следует заметить, что не каждый атрибут класса может характеризовать его состояние. Как правило, имеют значение только такие свойства элементов системы, которые отражают динамический или функциональный аспект ее поведения.
Диаграммы состояний (Statechart Diagram) определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых событий. В большинстве объектно-ориентированных методов диаграммы состояний строятся для единственного класса и отражают динамику поведения единственного объекта.
Не следует строить диаграммы состояний для каждого класса в системе; их стоит использовать только для тех классов, поведение которых действительно интересует, и построение диаграмм состояний помогает лучше его понять.
На основании анализа проектируемой системы и требований к ней, можно сказать, что интересным разработчику представляется поведение класса Договор.
Рассмотрю диаграмму состояний для этого класса.
Рис.21. Диаграмма состояний для класса "Договор"
Перед созданием Договора он приобретает состояние Новый. При подписании договора обеими сторонами переходит в состояние Подписан. Действителен он будет до срока действия, после чего он может перейти в состояние Продлен либо Просрочен, Расторгнут и, соответственно, перейдет в состояние Удален.
Рис.22. Диаграмма состояний для класса "Заявление"
Перед созданием и в процессе создания заявления, он приобретает состояние Новый. После подписи клиентом переходит в состояние Заполненное. При передаче его оператору, заявление переходит с состояние На рассмотрении. Если на стадии рассмотрения обнаружены ошибки, то заявление переходит в состояние Отвергнут, иначе - в состояние На обработке. При удовлетворении заявления он Исполнен, в противном случае - отвергнут.
2.6 Проектирование статической структуры
Статическая структура информационной системы представляет собой конечную диаграмму классов, на которой представлено взаимодействие сущностей, управляющих и пограничных классов, выявленных на начальном этапе проектирования и в процессе моделирования взаимодействий. Модель взаимодействий служит источником информации не только о том, какие классы, помимо сущностей, выявленных в начале разработки, должны существовать в системе, но и о том, как они взаимодействуют и связаны друг с другом, а также какими методами они обладают.
На диаграммах ниже статическая структура представлена в двух частях. Первая иллюстрирует взаимодействие управляющего класса с сущностями, а вторая - взаимодействие управляющего класса с пограничными.
Рис.23. Статическая структура ИС (часть 1)
Рис.24. Статическая структура ИС (часть 2)
Не все модели последовательностей и кооперации были построены с учетом принципа трехслойного взаимодействия (что, возможно, является недостатком данной разработки), поэтому на конечной диаграмме классов должны присутствовать связи между некоторыми пограничными классами и сущностями. Однако ввиду того, что при отображении всех этих связей на одной диаграмме ее практически невозможно будет читать, она в работе не приводится
2.7 Проектирование пользовательского интерфейса
После завершения предыдущих этапов разработки имею всю необходимую информацию для того, чтобы приступить к следующему не менее важному - к проектированию пользовательского интерфейса.