48561 (588568), страница 2
Текст из файла (страница 2)
SADT (Structured Analysis and Design Technique) - технология структурного анализа и проектирования и ее подмножество стандарт IDEF0;
DFD (Data Flow Diagrams) - диаграммы потоков данных;
ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь";
STD (State Transition Diagrams) - диаграммы переходов состояний.
В моей работе была использована методология DFD (Data Flow Diagrams). В DFD методологии исследуемый процесс разбивается на подпроцессы и представляется в виде сети, связанной потоками данных. В число элементов данной методолошии входят процессы, потоки данных и хранилища. Хранилище позволяет в необходимых случаях определить данные, которые будут сохраняться в памяти между процессами.
Диаграммы потоков данных (DFD - Data Flow Diagram) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Декомпозиция DFD осуществляется на основе процессов: каждый процесс может раскрываться с помощью DFD нижнего уровня. Важную специфическую роль в модели играет специальный вид DFD - контекстная диаграмма, моделирующая систему наиболее общим образом. Контекстная диаграмма отражает интерфейс системы с внешним миром, а именно, информационные потоки между системой и внешними сущностями, с которыми она должна быть связана.
Индивидуальные данные в системе часто являются независимыми. Однако иногда необходимо иметь дело с несколькими независимыми данными одновременно. Для этого используется диаграммы декомпозиции. Применение этих операций над данными позволяет обеспечить структуризацию данных, увеличивает наглядность и читабельность диаграмм.
Построю контекстную DFD диаграмму системы. Для этого необходимо изобразить основную функцию рассматриваемой системы "Центр обслуживания абонентов" и внешние по отношению к ней сущности, а также взаимосвязи между внешними сущностями и функцией системы. Контекстная диаграмма будет выглядеть следующим образом.
Рис.1. Контекстная диаграмма системы "Обслуживание абонентов"
Основным процессом является Обслуживание абонентов, т.к вся деятельность системы направлена именно на это. Внешними сущностями являются Оператор и Клиент. На первоначальном этапе взаимодействия, то есть, для заключения Договора, клиент предоставляет документы, составляет анкету, после чего она рассматривается оператором. В случае положительного ответа заключается договор об оказаниях услуг связи, иначе клиенту сообщается об отказе.
Далее клиент в случае необходимости посещает центр для заполнения заявления. Заявление может быть по разному поводу (просьба детализации счета, замена абонентского номера, замена sim-карты, заявка на пополнение счета…). Оператором рассматриваются заявления, и выносится решение об удовлетворении либо об отказе, что показано на диаграмме.
После создания контекстной диаграммы, я постаралась рассмотреть функции системы более подробно и построить диаграмму детализации первого уровня. Построенная диаграмма первого уровня также имеет множество процессов, которые в свою очередь могут быть декомпозированы в DFD нижнего уровня. Таким образом строится иерархия DFD с контекстной диаграммой в корне дерева. Этот процесс декомпозиции продолжается до тех пор, пока процессы могут быть эффективно описаны с помощью коротких (до одной страницы) миниспецификаций обработки (спецификаций процессов).
Рис.2. Диаграмма детализации первого уровня системы "Обслуживание абонентов"
Обслуживание абонентов может быть представлено в виде семи основных функций:
Рассмотрение анкеты
Заключение договора
Отказ от заключения договора
Подключение к сети
Рассмотрение заявления
Отказ от исполнения заявления
Исполнение заявления
Целью каждой функции является учет выполняемых в рамках данного процесса действий и отражение их результата в проектируемой информационной системе. Коротко прокомментирую каждую из них.
Рассмотрение анкеты.
Данная операция осуществляется оператором и не может быть полностью автоматизирована, так как изучение анкеты проходит в два этапа, второй из которых заключается в обязательным заполнении анкеты вручную абонентом. Результатом данной операции является решение о внесение в систему информации о новом абоненте. Отсутствие ее в общей модели привело бы к выпадению одного из звеньев цепи обслуживания абонента.
Заключение договора.
Результатом данной операции является внесение в систему информации о клиенте.
Отказ от заключения договора.
Оператор решает в силу тех или иных причин отказать в заключении договора о предоставлении услуг связи.
Подключение к сети.
При заключении договора необходимо выбрать оператора сети, приобрести sim-карту и соответственно абонентский номер.
Рассмотрение заявления.
В процессе пользования услугами связи у абонента могут возникнуть те или иные требования, которые ему необходимо отразить в заявлении. Заявление рассматривается операторами.
Отказ от исполнения заявления.
При наличии новых заявлений оператор осуществляет их проверку. Если принято решение о нецелесообразности исполнения данного требования, то сообщается абоненту об отказе.
Исполнение заявления
В случае принятия положительного решения, требования заявления исполняется.
Глава 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 позволяет проектировать варианты использования и их диаграммы для визуализации функциональных возможностей системы.
2.1 Выявление вариантов использования
UML и Rational Rose являются универсальными средствами, которые вполне подходят и для моделирования бизнес-процессов.
Use case diagram (диаграммы прецедентов) - позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций. Каждая такая диаграмма или, как ее обычно называют, каждый Use case - это описание сценария поведения, которому следуют действующие лица (Actors). Данный тип диаграмм используется при описании бизнес процессов автоматизируемой предметной области, определении требований к будущей системе. Отражает объекты как системы, так и предметной области и задачи, ими выполняемые.
2.1.1 Выделение субъектов (актеров) и прецедентов (видов деятельности)
Исходя из поиска ответов на следующие вопросы:
Кто взаимодействует с системой или использует систему?
Кто передает или принимает информацию в/из системы?
Кто является внешним по отношению к системе?
Я выявил следующих субъектов.
Рис.3 Субъекты системы "Обслуживание абонентов"
Прецедент представляет собой целостный набор функций, имеющих определенную ценность для субъекта. Прецеденты можно вывести в результате определения задач для субъекта. Для этого следует задаться вопросом: "Каковы обязанности субъекта по отношению к системе и чего он ожидает от системы?" Каждый вариант использования (прецедент) определяет набор действий, совершаемых системой при диалоге с актером. При этом ничего не говорится о том, как конкретно будет реализовано взаимодействие актеров с системой и собственно выполнение вариантов использования. Прецедент изображается в виде эллипса, внутри или ниже которого помещается имя прецедента.
Рис.4. Прецеденты системы "Обслуживание абонентов"
2.1.2 Документирование прецедентов
Структура документа, описывающего прецеденты, может варьироваться, однако типичное описание должно содержать следующие разделы.
1. Краткое описание.
2. Участвующие субъекты.
3. Предусловия, необходимые для инициирования прецедента.
4. Детализированное описание потока событий, которое включает:
основной поток, который можно разбить для того, чтобы показать подчиненные потоки событий (подчиненные потоки могут быть разделены дальше на еще более мелкие потоки, с целью сделать читаемость документа более удобной);
альтернативные потоки для определения исключительных ситуаций.
5. Постусловия, определяющие состояние системы, по достижении которого прецедент завершается.
Приведу описательную документацию выше одного из обозначенных прецедентов.
Документ, содержащий описания прецедента, развивается по ходу разработки. На ранней стадии определения требований составляется только краткое описание. Остальные части документа создаются постепенно и итеративно. Полный документ возникает в конце этапа спецификации требований.
| Прецедент | Заключение договора |
| Краткое описание | Данный прецедент необходим для регистрации нового абонента в сети. |
| Субъект | Оператор, клиент |
| Предусловия | Оператору необходимо ознакомить с имеющимися операторами связи и выдать форму анкеты потенциальному абоненту |
| Основной поток | После выбора клиентом соответствующего оператора, он заполняет форму, после чего оператор проверяет правильность заполнение формы на бумажном носителе и вводит данные в систему следующим действием "Выбор оператора связи - Договор об оказании услуг связи". После чего в системе "Обслуживание абонентов" открывается форма по заключению абонента сети в системе. При этом сначала система спрашивает, кто будет регистрироваться: Физическое лицо или Юридическое, и только после этого выводится соответствующая регистрационная форма. Оператор вводит информацию об организации-клиенте, о контактном лице юридического лица, а также вводит номера счетов организации. Далее договор сохраняется. Производится сеанс связи с Сервером в процессе которого эти данные передаются на сервер. |
| Альтернативный поток | В случае, если пользователь не ввел все поля, система выдает сообщение "Введите все поля", дает возможность пройти процесс регистрации снова при ошибке. Также оператор и имеет возможность отказа от регистрации абонента путем выбора соответствующей команды (Отмена или аналогичной). |
| Постусловия | После успешного завершения прецедента, клиент внесен в базу данных Абоненты сети на сервере. |
| Прецедент | Замена абонентского номера |
| Краткое описание | Данный прецедент необходим для удовлетворения потребности абонента, а именно, замены его номера. |
| Субъект | Оператор, клиент |
| Предусловия | Оператору необходимо ознакомиться с заявлением клиента. |
| Основной поток | После проверки твердой копии заявления оператор в БД системы находит данного абонента, вызывает функцию "замена номера", после чего появляется соответствующая форма, которую необходимо заполнить. При нажатии кнопка ОК (или аналогичной) система автоматически меняет в БД номер клиента, оставляя при этом остальные данные неизменными. Далее изменения сохраняются. Производится сеанс связи с Сервером в процессе которого эти данные передаются на сервер. |
| Альтернативный поток | В случае, если пользователь не ввел все поля либо, система выдает сообщение об ошибке. |
| Постусловия | После успешного завершения прецедента, внесены изменения в базу данных. |
2.1.3 Диаграмма прецедентов
Этот вид диаграмм позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций.
Каждая такая диаграмма или, как ее обычно называют, каждый Use case - это описание сценария поведения, которому следуют действующие лица (Actors).
Диаграмма прецедентов приписывает прецеденты к субъектам. Она также позволяет пользователю установить отношения между прецедентами, конечно, если такие отношения существуют.
Диаграмма прецедентов - это наглядное представление субъектов и прецедентов вместе с любыми дополнительными определениями и спецификациями. На данном виде диаграмм отображаются основные функции, которые выполняет система, лица, оказывающие влияния на систему - внешние сущности, а также связи между ними. Диаграмма прецедентов представляет собой не просто некую схему, а является полностью документированной моделью предполагаемого поведения системы. Достоинства модели вариантов использования заключаются в том, что она:
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
