обслужтел. Диплом 2010 по информатике
 Скачать 420.55 Kb.
|
|
Глава 2. Проектирование системы "обслуживание абонентов" Rational Rose - мощное CASE-средство для проектирования программных систем любой сложности. Одним из достоинств этого программного продукта будет возможность использования диаграмм на языке UML. Можно сказать, что Rational Rose является графическим редактором UML диаграмм. В распоряжение проектировщика системы Rational Rose предоставляет следующие типы диаграмм, последовательное создание которых позволяет получить полное представление о всей проектируемой системе и об отдельных ее компонентах: Use case diagram ( диаграммы прецедентов); Deployment diagram ( диаграммы топологии); Statechart diagram ( диаграммы состояний); Activity diagram ( диаграммы активности); Interaction diagram ( диаграммы взаимодействия); Sequence diagram ( диаграммы последовательностей действий); Collaboration diagram ( диаграммы сотрудничества); Class diagram ( диаграммы классов); Component diagram ( диаграммы компонент). Для целей анализа деятельности предприятия все большее распространение получает средство моделирования Rational Rose компании Rational Software. Rational Rose - мощный инструмент анализа и проектирования объектно-ориентированных программных систем. Он позволяет моделировать системы до написания кода, так что вы можете с самого начала быть уверены в адекватности их архитектуры. С помощью готовой модели недостатки проекта легко обнаружить на стадии, когда их исправление не требует еще значительных затрат. Среда Rational Rose позволяет проектировать варианты использования и их диаграммы для визуализации функциональных возможностей системы. Document shared on www.docsity.com Downloaded by: sabina-valievna (sabinavalievna16@gmail.com) 2.1 Выявление вариантов использования UML и Rational Rose являются универсальными средствами, которые вполне подходят и для моделирования бизнес-процессов. Use case diagram ( диаграммы прецедентов) - позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций. Каждая такая диаграмма или, как ее обычно называют, каждый Use case - это описание сценария поведения, которому следуют действующие лица (Actors). Данный тип диаграмм используется при описании бизнес процессов автоматизируемой предметной области, определении требований к будущей системе. Отражает объекты как системы, так и предметной области и задачи, ими выполняемые. 2.1.1 Выделение субъектов (актеров) и прецедентов (видов деятельности) Исходя из поиска ответов на следующие вопросы: Кто взаимодействует с системой или использует систему? Кто передает или принимает информацию в/из системы? Кто является внешним по отношению к системе? Я выявил следующих субъектов. Document shared on www.docsity.com Downloaded by: sabina-valievna (sabinavalievna16@gmail.com) Рис.3 Субъекты системы "Обслуживание абонентов" Прецедент представляет собой целостный набор функций, имеющих определенную ценность для субъекта. Прецеденты можно вывести в результате определения задач для субъекта. Для этого следует задаться вопросом: "Каковы обязанности субъекта по отношению к системе и чего он ожидает от системы?" Каждый вариант использования (прецедент) определяет набор действий, совершаемых системой при диалоге с актером. При этом ничего не говорится о том, как конкретно будет реализовано взаимодействие актеров с системой и собственно выполнение вариантов использования. Прецедент изображается в виде эллипса, внутри или ниже которого помещается имя прецедента. Рис.4. Прецеденты системы "Обслуживание абонентов" Document shared on www.docsity.com Downloaded by: sabina-valievna (sabinavalievna16@gmail.com) 2.1.2 Документирование прецедентов Структура документа, описывающего прецеденты, может варьироваться, однако типичное описание должно содержать следующие разделы. 1. Краткое описание. 2. Участвующие субъекты. 3. Предусловия, необходимые для инициирования прецедента. 4. Детализированное описание потока событий, которое включает: основной поток, который можно разбить для того, чтобы показать подчиненные потоки событий (подчиненные потоки могут быть разделены дальше на еще более мелкие потоки, с целью сделать читаемость документа более удобной); альтернативные потоки для определения исключительных ситуаций. 5. Постусловия, определяющие состояние системы, по достижении которого прецедент завершается. Приведу описательную документацию выше одного из обозначенных прецедентов. Документ, содержащий описания прецедента, развивается по ходу разработки. На ранней стадии определения требований составляется только краткое описание. Остальные части документа создаются постепенно и итеративно. Полный документ возникает в конце этапа спецификации требований. Прецедент Заключение договора Краткое описание Данный прецедент необходим для регистрации нового абонента в сети. Субъект Оператор, клиент Предусловия Оператору необходимо ознакомить с имеющимися операторами связи и выдать форму анкеты потенциальному абоненту Основной поток После выбора клиентом соответствующего оператора, он заполняет форму, после чего оператор проверяет правильность заполнение формы на бумажном носителе и вводит данные в систему следующим действием "Выбор оператора связи - Договор об оказании Document shared on www.docsity.com Downloaded by: sabina-valievna (sabinavalievna16@gmail.com) услуг связи". После чего в системе "Обслуживание абонентов" открывается форма по заключению абонента сети в системе. При этом сначала система спрашивает, кто будет регистрироваться: Физическое лицо или Юридическое, и только после этого выводится соответствующая регистрационная форма. Оператор вводит информацию об организации- клиенте, о контактном лице юридического лица, а также вводит номера счетов организации. Далее договор сохраняется. Производится сеанс связи с Сервером в процессе которого эти данные передаются на сервер. Альтернативный поток В случае, если пользователь не ввел все поля, система выдает сообщение "Введите все поля", дает возможность пройти процесс регистрации снова при ошибке. Также оператор и имеет возможность отказа от регистрации абонента путем выбора соответствующей команды ( Отмена или аналогичной). Постусловия После успешного завершения прецедента, клиент внесен в базу данных Абоненты сети на сервере. Прецедент Замена абонентского номера Краткое описание Данный прецедент необходим для удовлетворения потребности абонента, а именно, замены его номера. Субъект Оператор, клиент Предусловия Оператору необходимо ознакомиться с заявлением клиента. Основной поток После проверки твердой копии заявления оператор в БД системы находит данного абонента, вызывает функцию "замена номера", после чего появляется соответствующая форма, которую необходимо заполнить. При нажатии кнопка ОК (или аналогичной) система автоматически меняет в БД номер клиента, оставляя при этом остальные данные неизменными. Далее изменения сохраняются. Производится сеанс связи с Сервером в процессе которого эти данные передаются на сервер. Альтернативный поток В случае, если пользователь не ввел все поля либо, система выдает сообщение об ошибке. Постусловия После успешного завершения прецедента, внесены изменения в базу данных. Document shared on www.docsity.com Downloaded by: sabina-valievna (sabinavalievna16@gmail.com) 2.1.3 Диаграмма прецедентов Этот вид диаграмм позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций. Каждая такая диаграмма или, как ее обычно называют, каждый Use case - это описание сценария поведения, которому следуют действующие лица (Actors). Диаграмма прецедентов приписывает прецеденты к субъектам. Она также позволяет пользователю установить отношения между прецедентами, конечно, если такие отношения существуют. Диаграмма прецедентов - это наглядное представление субъектов и прецедентов вместе с любыми дополнительными определениями и спецификациями. На данном виде диаграмм отображаются основные функции, которые выполняет система, лица, оказывающие влияния на систему - внешние сущности, а также связи между ними. Диаграмма прецедентов представляет собой не просто некую схему, а является полностью документированной моделью предполагаемого поведения системы. Достоинства модели вариантов использования заключаются в том, что она: определяет пользователей и границы системы; определяет системный интерфейс; удобна для общения пользователей с разработчиками; используется для написания тестов; является основой для написания пользовательской документации; хорошо вписывается в любые методы проектирования (как объектно- ориентированные, так и структурные). Варианты использования и субъекты, выделенные для данной модели, можно представить в виде следующей диаграммы прецедентов: Document shared on www.docsity.com Downloaded by: sabina-valievna (sabinavalievna16@gmail.com) Рис.5. Диаграмма прецедентов системы "Обслуживание абонентов" Диаграмма прецедентов представляет собой не просто некую схему, а является полностью документированной моделью предполагаемого поведения системы. Это вид диаграмм особенно важен при организации и моделирования поведения системы. На них представлены прецеденты и актеры (частный случай классов), а также отношения между ними. Актер - это роль, которую пользователь играет по отношению к системе. Между субъектами и вариантами использования могут быть различные виды взаимодействия. Так, из построенной диаграммы видно, что Оператор, инициирует различные варианты использования: Рассмотрение заявления, Замена абонентского номера, Детализация счета, Замена SIM-карты, Блокировка номера и так далее. Клиент также может инициировать варианты использования, например, Заполнение заявления, Составление анкеты, Выбор оператора связи и т.д. Остановлюсь подробнее на некоторых отношениях между вариантами использования. Document shared on www.docsity.com Downloaded by: sabina-valievna (sabinavalievna16@gmail.com) Рис.6. Диаграмма прецедентов для субъекта Оператор. Следует прокомментировать некоторые особенно "привлекательные" отношения между вариантами использования. Так, смысл отношения "include" состоит в том, что Подключение включает в себя Выбор оператора связи. Смысл же связи < Рассмотрение анкеты "расширяется" вариантом использования Заключение договора. Я объясняю это тем, что Заключить договор можно только после проверки оператором анкеты. Рассмотрение заявления "расширяет" прецедент Блокировка номера, Замена sim-карты, Детализация счета, Замена абонентского номера. Таким образом, связь < Document shared on www.docsity.com Downloaded by: sabina-valievna (sabinavalievna16@gmail.com) Рис.7. Диаграмма прецедентов для субъекта Клиент. Подключение абонента включает в себя Выбор оператора связи. Составление анкеты "расширяется" вариантом использования Заключение договора. 2.2 Выявление классов - сущностей Параллельно с моделированием вариантов использования выполняется выявление так называемых классов-сущностей, их атрибутов и взаимосвязей между ними, что представляется в виде диаграммы классов (Class diagram), использующейся для моделирования статического видения системы с точки зрения проектирования, т.е. для построения логической модели разрабатываемой системы. Она не содержит информации о временных аспектах функционирования системы. Каждый класс рассматривается в разрезе нескольких функциональных требований. Класс (class) в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. Класс-сущность - класс, определяющий типы объектов системы и различного рода связи, существующие между ними. Классы-сущности представляют собой элементы, используемые системой постоянно. Они хранят в определенный момент времени часть БД. Данные в них могут извлекаться, меняться, снова записываться. Анализ требований сводится к выявлению классов-сущностей. Проводя глубокий анализ предметной области, я выявил следующие классы - сущности: Клиент, Физическое лицо, Юридическое лицо, Договор, Заявление, Оператор, Заявление. Рис.8. Первоначальный вид классов-сущностей. Document shared on www.docsity.com Downloaded by: sabina-valievna (sabinavalievna16@gmail.com) Класс "Клиент" необходим для хранения информации о клиентах абонентах) системы. Он включает в себя следующие атрибуты: индекс, страна, город, область, район, улица, дом, корпус, квартира, e-mail, факс, телефон. Так как клиентом системы может быть как частное лицо, так и организация, мною составлены такие классы как "Физическое лицо" и " Юридическое лицо". Их взаимосвязь с классом "Клиент" я покажу на диаграмме классов. Класс "договор" является хранилищем договоров об оказаниях услуг связи. Он включает в себя следующие атрибуты: телефонный номер, тарифный план, серийный номер sim - карты, услуги связи, особые условия, срок действия договора, дата заключения. Услуги связи имеют тип list Телефонный номер имеет тип integer, так как номер состоит только из целых чисел. Классы не существуют, как правило, автономно, а взаимодействуют между собой. Потому далее была построена диаграмма классов. Рис.9. Диаграмма классов Document shared on www.docsity.com Downloaded by: sabina-valievna (sabinavalievna16@gmail.com) Интересна связь между рассматриваемыми объектами Физическое лицо - Клиент и Юридическое лицо - Клиент. Это отношение, называется Обобщение. Оно представляет собой видовое отношение между более общим классом (суперкласс или родительский класс) и более специфическим видом класса (подкласс или дочерний класс). Подкласс является видом суперкласса. Там, где допустимо использование суперкласса, может использоваться и объект подкласса. Обобщение делает невозможным переопределение уже заданных свойств. Атрибуты и операции, уже определенные для суперкласса, могут повторно использоваться в подклассе. Говорят, что подкласс наследует (inherit) атрибуты и методы его родительского класса. Обобщение способствует пошаговой спецификации, использованию общих свойств разными классами и лучшей локализации изменений. Обобщение изображается в виде незаполненного треугольника на конце линии отношения, присоединенной к родительскому классу. На диаграмме классов Клиент является суперклассом, a Физическое лицо и Юридическое лицо - подклассами. Классы Физическое лицо и Юридическое лицо наследуют все атрибуты класса Клиент. Центральным классом рассматриваемой модели стал класс Договор. Факт того, что документы создаются Клиентами, а вносятся в систему Операторами показан на диаграмме существованием связи между объектами Клиент - Договор и Договор-Оператор. Кратность этой ассоциации вполне объяснима: Клиент может создать один документ или их множество ( кратность в этой позиции - [1. n]), и он обязательно должен быть создан (и впоследствии введен оператором в систему), на что и указывает кратность ассоциации [1. n]. Класс Договор служит для хранения всех договоров об оказании услуг связи, по структуре абсолютно идентичных. Поэтому различие между ними устанавливается посредством атрибута тип платежного документа. Document shared on www.docsity.com Downloaded by: sabina-valievna (sabinavalievna16@gmail.com) Клиент может в силу определенных обстоятельств составить заявление, но также заявление может быть и не составлено, на что указывает кратность [0. .1]. Итак, формирование диаграммы классов-сущностей окончено. Мною были определены типы объектов, определяющих будущую модель базы данных, а также связи, существующие между ними. Однако построенную диаграмму классов нельзя назвать полной статической моделью системы в силу отсутствия многих важных элементов, таких как управляющие и интерфейсные классы. 2.3 Моделирование видов деятельности Модели видов деятельности (Activity Diagram) строятся для описания общей последовательности действий для нескольких объектов и вариантов использования. На диаграммах этого типа представляются переходы потока управления от одной деятельности к другой внутри системы. Этот вид диаграмм относится к динамическим представлениям системы, и является наиболее полезным при моделировании ее функционирования, так как отражает передачу потока управления между объектами. Основным элементом диаграммы видов деятельности является деятельность. Интерпретация этого термина зависит от той точки зрения, с которой строится данная диаграмма. На концептуальной диаграмме деятельность - это некоторая задача, которую необходимо выполнить вручную или автоматизированным способом. На диаграмме, построенной в аспекте спецификации или реализации, деятельность представляет собой некоторый метод над классом. Диаграмма деятельностей предоставляет свободу выбора порядка выполнения. Другими словами, она только устанавливает основные правила последовательности, которым необходимо следовать. Такая возможность важна при моделировании бизнес-процессов. Среди бизнес-процессов нередко встречаются такие, которые не обязаны выполняться Document shared on www.docsity.com Downloaded by: sabina-valievna (sabinavalievna16@gmail.com) последовательно. В таких ситуациях данный метод хорошо работает, так как он позволяет реализовывать процессы параллельно. Диаграммы видов деятельности являются также полезными при параллельном программировании, поскольку можно графически изобразить все ветви и определить, когда их необходимо синхронизировать. Если при описании поведения системы имеются параллельные деятельности, то их необходимо синхронизировать. Простая линейка синхронизации показывает, что ее выходная деятельность активизируется только тогда, когда выполнены обе входные деятельности. Диаграммы видов деятельности можно применять для описания потоков событий в вариантах использования. С помощью текстового описания можно достаточно подробно рассказать о потоке событий, но в сложных и запутанных потоках с множеством альтернативных ветвей будет трудно понять логику событий. Диаграммы видов деятельности предоставляют ту же информацию, что и текстовое описание потока событий, но в наглядной графической форме. Рассмотрим теперь модели видов деятельности, построенные для проектируемой системы. Составление анкеты: Рис.10. Диаграмма видов деятельности для прецедента Составление анкеты Document shared on www.docsity.com Downloaded by: sabina-valievna (sabinavalievna16@gmail.com) Клиент получает форму для заполнения от оператора, после чего ему Document shared on www.docsity.com Downloaded by: sabina-valievna (sabinavalievna16@gmail.com) необходимо заполнить все поля данной формы. Далее оператор проверяет анкету, в случае наличия ошибок клиенту выдается новая форма. При одобрении - заключается договор об оказании услуг связи. Рассмотрение анкеты: Рис.11. Диаграмма видов деятельности для прецедента Рассмотрение анкеты Оператор получает от клиента заполненную анкету, проверяет все поля. При наличии ошибок отказывает в заключении договора. В противном случае заключает договор. Document shared on www.docsity.com Downloaded by: sabina-valievna (sabinavalievna16@gmail.com) Замена абонентского номера: Рис.12. Диаграмма видов деятельности для прецедента Замена абонентского номера Оператор получает от клиента заявление на замену абонентского номера, проверяет на наличие ошибок в реквизитах. Если они есть, то выдается новая форма заявления, иначе, рассматривается причина. В результате рассмотрения причины заявление могут удовлетворить, либо отклонить. Document shared on www.docsity.com Downloaded by: sabina-valievna (sabinavalievna16@gmail.com) Детализация счета: Рис.13. Диаграмма видов деятельности для прецедента Детализация счета Оператор получает от клиента заявление на получение детализации счета, проверяет соответствие личности и паспорта. Если паспорт не принадлежит будущему абоненту, ему отказывают. Далее идет проверка на наличие ошибок в заявлении. При их отсутствии выдается детализация счета за необходимый период. При наличии ошибок выдается новая форма заявления. Document shared on www.docsity.com Downloaded by: sabina-valievna (sabinavalievna16@gmail.com) Замена SIM-карты: Рис.14. Диаграмма видов деятельности для прецедента Замена SIM- карты Оператор получает от клиента заявление на Замену sim-карты, проверяет соответствие личности и паспорта. Если паспорт не принадлежит будущему абоненту, ему отказывают. Далее идет проверка на наличие ошибок в заявлении. При их отсутствии рассматривается причина, если она удовлетворительная, то карты заменят. При наличии ошибок выдается новая форма заявления. Document shared on www.docsity.com Downloaded by: sabina-valievna (sabinavalievna16@gmail.com) |