Проектирование АИС "Работа с абонентами оператора сотовой связи" (стр. 5 из 7)
В процессе декомпозиции выявляются задачи, обеспечивающие достижение поставленной цели.
Границы модели определяются посредством описания внешних интерфейсов. На функциональных и информационных моделях все стрелки, выходящие извне, - внешние интерфейсы.
Модель, основанная на методологии IDEF, позволяет описать структуру объекта в виде многоуровневой иерархической системы объектов с необходимой глубиной проникновения, сделать информационные и материальные потоки, а также взаимосвязь их и подсистем объекта максимально “прозрачными”.
Блоки на диаграмме размещаются по ступенчатой схеме в соответствии с их доминированием. Согласно этому принципу расположения в левом верхнем углу располагается самый важный процесс или процесс, выполняемый по времени первым. Далее вправо вниз располагаются менее важные или выполняемые позже процессы. Такое расположение облегчает чтение диаграмм. (BPwin автоматически располагает блоки по ступенчатой схеме). Кроме того, блоки должны быть пронумерованы, в соответствии с их доминированием.
Блоки на диаграммах изображаются прямоугольниками и сопровождаются текстом, описывающим подпроцесс. Каждая сторона блока имеет вполне определенное назначение: левая сторона блока предназначена для входов (материал или информация, которые используются или преобразуются для получения результата), верхняя - для управления (правила, стратегии, стандарты), правая - для выходов (материал или информация, получаемые в результате выполнения процесса), нижняя - для механизмов (ресурсы, которые выполняют процесс). Такое обозначение отражает определенные принципы активности: входы преобразуются в выходы, управления ограничивают или предписывают условия выполнения, исполнители описывают, за счет чего выполняются преобразования.
Уровень А0. Декомпозиция
После создания контекстной диаграммы, которая представляет собой описание контекста моделируемой системы, проводится функциональная декомпозиция – система разбивается на подсистемы и каждая подсистема описывается в том же синтаксисе, что и система в целом. Затем каждая подсистема разбивается на более мелкие и так до достижения нужного уровня подробности. В результате такого разбиения, каждый фрагмент системы изображается на отдельной диаграмме декомпозиции. Диаграмма декомпозиции предназначена для детализации работы.
При декомпозиции процесса все стрелки, входящие или исходящие из него, должны быть перенесены на диаграмму нижнего уровня и использованы при ее построении. При этом запрещены всякие новые стрелки, выходящие за пределы новой диаграммы, кроме специальных, так называемых "тоннелированных" стрелок.
Информационно-логическая модель
Первым шагом при создании логической модели БД является построение диаграммы ERD (Entity Relationship Diagram). ERD-диаграммы состоят из трех частей: сущностей, атрибутов и взаимосвязей. Сущностями являются существительные, атрибуты – прилагательными или модификаторами, взаимосвязи – глаголами.
ERD - диаграмма позволяет рассмотреть систему целиком и выяснить требования, необходимые для ее разработки, касающиеся хранения информации.
ERD - диаграмма графически представляет структуру данных проектируемой информационной системы.
Первым этапом является определение сущностей и атрибутов. В БД будут храниться записи об абонентах, следовательно, сущностью будет абонентская база.
Таблица 1. Атрибуты сущности «Абонентская база».
| Атрибут | Описание |
| № договора | Уникальный номер для идентификации заключенного договора с абонентом |
| Дата заключения | Дата |
| Абонент | Фамилия, имя, отчество абонента, паспортные данные |
| Лицевой счет | Информация о состоянии счета обонента |
| Тарифный план | Список тарифов для выбора абонентом |
| Услуги | Список предоставляемых услуг |
| Состояние договора | Физическое состояние договора (например: заключен, расторгнут, приостановлен) |
В полученном списке существуют атрибуты, которые нельзя определить в виде одного поля БД. Такие атрибуты требуют дополнительных определений и должны рассматриваться как сущности, состоящие, в свою очередь, из атрибутов. К таковым относятся: Абонент, Тарифный план, Лицевой счет, Услуги.
Таблица 2. Атрибуты Сущности «Абонент».
| Атрибут | Описание |
| ФИО абонента | Фамилия, имя, отчество абонента |
| Серия паспорта | Паспортные данные |
| № паспорта | |
| Дата рождения | Дата рождения |
| Адрес | Адрес по прописке |
Таблица 3. Атрибуты сущности «Тарифный план»
| Атрибут | Описание |
| Тариф | Наименование тарифного плана |
| Ст вх вн с | Стоимость входящих звонков внутри сети |
| Ст исх вн с | Стоимость исходящих звонков внутри сети |
| Ст вх с др с оп | Стоимость входящих звонков с телефонов других сотовых операторов |
| Ст исх с др с оп | Стоимость исходящих звонков с телефонов других сотовых операторов |
| Ст вх с гор тел | Стоимость входящих звонков с городских телефонов |
| Ст исх с гор тел | Стоимость исходящих звонков с городских телефонов |
| Sms | Стоимость исходящих sms сообщений (за шт) |
Таблица 4. Атрибуты сущности «Лицевой счет»
| Атрибут | Описание |
| № лицевого счета | Уникальный номер для оплаты услуг оператора |
| Дата | Дата внесения денежных средств |
| Сумма | Сумма внесенных денежных средств |
Таблица 5. Атрибуты сущности «Услуга»
| Атрибут | Описание |
| Код услуги | Уникальный код для идентификации предоставляемой услуги |
| Описание | Описание услуги |
| Примечание | Правила предоставления услуги |
| Стоимость | Стоимость услуги |
Составим ERD-диаграмму, определяя типы атрибутов и проставляя связи сущностями.
Следующим этапом построения логической модели является определение типов атрибутов.
Таблица 6. Типы атрибутов.
| Атрибут | Тип |
| № договора | Integer |
| Дата заключения | Date |
| ФИО абонента | String |
| Серия паспорта | Integer |
| № паспорта | Integer |
| Дата рождения | Date |
| Адрес | String |
| № абонента | Integer |
| Состояние договора | String |
| Тариф | String |
| Ст вх вн с | Float |
| Ст исх вн с | Float |
| Ст вх с др с оп | Float |
| Ст исх с др с оп | Float |
| Ст вх с гор тел | Float |
| Ст исх с гор тел | Float |
| Sms | Float |
| № лицевого счета | Float |
| Дата | Date |
| Сумма | Float |
| Код услуги | Integer |
| Описание | String |
| Примечание | String |
| Стоимость | Float |
UseCase – диаграммы прецедентов
Прецедентом (Use case) называется описание множества последовательностей действий (включая варианты), выполняемых системой для того, чтобы актер мог получить определенный результат. Графически прецедент изображается в виде эллипса. Нотация прецедента похожа на нотацию кооперации.
Диаграммы прецедентов представляют собой один из пяти типов диаграмм, применяемых в UML для моделирования динамических аспектов. Диаграммы прецедентов играют основную роль в моделировании поведения системы, подсистемы или класса. Каждая такая диаграмма показывает множество прецедентов, актеров и отношения между ними.
Диаграммы прецедентов применяются для моделирования вида системы с точки зрения варианта использования. Чаще всего это предполагает моделирование контекста системы, подсистемы или класса либо моделирование требований, предъявляемых к поведению указанных элементов.
Диаграммы прецедентов имеют большое значение для визуализации, специфицирования и документирования поведения элемента. Они облегчают понимание систем, подсистем или классов, представляя взгляд извне на то, как данные элементы могут быть использованы в соответствующем контексте. Кроме того, такие диаграммы важны для тестирования исполняемых систем в процессе прямого проектирования и для понимания их внутреннего устройства при обратном проектировании.
Диаграммой прецедентов, или использования (Use case diagram), называется диаграмма, на которой показана совокупность прецедентов и актеров, а также отношения между ними.
Диаграммы Use Case определяют поведение системы с точки зрения пользователя. Элемент Use Case описывает, что должна делать система, но не определяет, как она должна это делать. Это позволяет отделить внешнее представление от внутреннего представления.
Вершинами в этой д. являются актеры и элементы Use Case, которые представляют собой действия, выполняемые системой в интересах актеров.
Актер – роль объекта вне системы. Актер прямо взаимодействует с ее частью – конкретным элементом Use Case. Различают актеров и пользователей. Пользователь может играть несколько ролей и моделироваться несколькими актерами. Набор всех элементов Use Case определяет полные функциональные возможности системы.
Абонент
| Основной | Альтернативный |
| Заключить контракт на обслуживание | |
| Предоставить личные данные (паспортные данные)Открыть лицевой счетВыдать копию договораВвести информацию об абоненте в БД | Если отсутствуют личные данные – договор не заключать. |
| Запрос информации о состоянии счета | |
| Идентификация пользователяЗапрос баланса на счетеВыдать отчет | Если абонент не идентифицирован – запрос не выполнять. |
| Заказать услугу | |
| Идентификация абонентаПроверка состояния лицевого счетаВыбор услугиВыдать подтверждение | Если абонент не идентифицирован – запрос не выполнять.Если средств на счете не достаточно – услугу не предоставлять. |
Оператор