48561 (588568), страница 4
Текст из файла (страница 4)
Рис.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 Проектирование пользовательского интерфейса
После завершения предыдущих этапов разработки имею всю необходимую информацию для того, чтобы приступить к следующему не менее важному - к проектированию пользовательского интерфейса.
Пользователи программ, как правило, не разделяют функциональность и пользовательский интерфейс. Для пользователей именно пользовательский интерфейс является программой. Для них, если интерфейс хороший, стало быть, и сама программа хороша и удобна.
Пользовательский интерфейс часто понимают только как внешний вид системы. В действительности пользовательский интерфейс включает в себя все аспекты дизайна, которые оказывают влияние на взаимодействие пользователя и системы. Это не только экран, который видит пользователь. Пользовательский интерфейс состоит из множества составляющих, таких как набор задач пользователя, которые он решает при помощи системы, элементы управления системой, навигация между блоками системы, визуальный (и не только) дизайн экранов программы. При проектировании пользовательского интерфейса я опиралась на модель взаимодействий, которая предоставляет информацию о том, какие окна (в данном случае формы) отображаются в ответ на то или иное действие пользователя и какие элементы в них должны содержаться. Кроме того, разработку пользовательского интерфейса я постарался провести с учетом принципов проектирования интерфейса. При построении в интерфейсе были использованы термины и понятия, доступные и понятные будущим пользователям системы. Я сделать так, чтобы разные, но однотипные операции проводились аналогичным способом. Кроме того, интерфейс предоставляет необходимую информацию в случае возникновения каких-либо ошибок. Вся информация о сообщениях об ошибках также представлена на моделях взаимодействий. Ввиду большого объема работы мною была спроектирована лишь часть пользовательского многодокументного интерфейса. Далее результат выполнения этого этапа проектирования.
Рис.25. Модель интерфейса для заключения договора
Так как интерфейс программы многодокументный, то все дочерние окна открываются и сворачиваются в родительском окне в свободной площади. Дочерние окна могут не открываться, выноситься вне родительского.
Меню - в данном компоненте содержатся все основные команды доступные пользователю при работе с системой.
Панель инструментов - на этом графическом элементе размещены кнопки, ассоциированные с наиболее часто применяемыми командами.
2.8 Диаграмма компонентов
Для создания конкретной физической системы необходимо реализовать все элементы логического представления в конкретные материальные сущности. Для описания таких реальных сущностей предназначено физическое представление модели. Базовыми элементами физического представления системы в нотации UML являются компоненты, которые представляют собой физически существующие части системы, которые обеспечивают реализацию классов и отношений, а также функционального поведения моделируемой программной системы.
На рисунке 26 показан результат попытки, определить состав компонентов системы и представить их в виде диаграммы компонентов.
Рис.26. Диаграмма компонентов
2.9 Проектирование архитектуры приложения
Технология клиент-сервер по праву считается одним из "китов", на которых держится современный мир компьютерных сетей.
Для проектирования архитектуры данного приложения я безусловно использую технологию клиент-сервер. Что же касается архитектуры, двухуровневая или трех, то здесь есть над чем порассуждать. Итак, термин "клиент-сервер" означает такую архитектуру программного комплекса, в которой его функциональные части взаимодействуют по схеме "запрос-ответ". Если рассмотреть две взаимодействующие части этого комплекса, то одна из них (клиент) выполняет активную функцию, т.е. инициирует запросы, а другая (сервер) пассивно на них отвечает. По мере развития системы роли могут меняться, например некоторый программный блок будет одновременно выполнять функции сервера по отношению к одному блоку и клиента по отношению к другому.
Замечу, что любая информационная система должна иметь минимум три основные функциональные части - модули хранения данных, их обработки и интерфейса с пользователем, в моем случае с оператором. Каждая из этих частей может быть реализована независимо от двух других. Например, не изменяя программ, используемых для хранения и обработки данных, можно изменить интерфейс с оператором таким образом, что одни и те же данные будут отображаться в виде таблиц, графиков или гистограмм. Не меняя программ представления данных и их хранения, можно изменить программы обработки, например, изменив алгоритм полнотекстового поиска. И наконец, не меняя программ представления и обработки данных, можно изменить программное обеспечение для хранения данных, перейдя, например, на другую файловую систему.
В классической архитектуре клиент-сервер приходится распределять три основные части приложения по двум физическим модулям. Обычно ПО хранения данных располагается на сервере (например, сервере базы данных), интерфейс с пользователем - на стороне клиента, а вот обработку данных приходится распределять между клиентской и серверной частями. В этом-то и заключается основной недостаток двухуровневой архитектуры, из которого следуют несколько неприятных особенностей, сильно усложняющих разработку клиент-серверных систем.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
