Дипломная работа: Разработка имитационной модели программного обеспечения информационной системы "Центр обслуживания абонентов"
Класс (class ) в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов.
Класс-сущность - класс, определяющий типы объектов системы и различного рода связи, существующие между ними. Классы-сущности представляют собой элементы, используемые системой постоянно. Они хранят в определенный момент времени часть БД. Данные в них могут извлекаться, меняться, снова записываться. Анализ требований сводится к выявлению классов-сущностей.
Проводя глубокий анализ предметной области, я выявил следующие классы - сущности: Клиент, Физическое лицо, Юридическое лицо, Договор, Заявление, Оператор, Заявление.
Рис.8. Первоначальный вид классов-сущностей.
Класс "Клиент" необходим для хранения информации о клиентах абонентах) системы. Он включает в себя следующие атрибуты: индекс, страна, город, область, район, улица, дом, корпус, квартира, e-mail, факс, телефон.
Так как клиентом системы может быть как частное лицо, так и организация, мною составлены такие классы как "Физическое лицо" и "Юридическое лицо". Их взаимосвязь с классом "Клиент" я покажу на диаграмме классов.
Класс "договор" является хранилищем договоров об оказаниях услуг связи. Он включает в себя следующие атрибуты: телефонный номер, тарифный план, серийный номер sim - карты, услуги связи, особые условия, срок действия договора, дата заключения.
Услуги связи имеют тип list<integer>, который обозначает тот факт, что клиент может из нескольких видов услуг выбрать нужный из списка.
Телефонный номер имеет тип integer, так как номер состоит только из целых чисел. Классы не существуют, как правило, автономно, а взаимодействуют между собой. Потому далее была построена диаграмма классов.
Рис.9. Диаграмма классов
Интересна связь между рассматриваемыми объектами Физическое лицо - Клиент и Юридическое лицо - Клиент . Это отношение, называется Обобщение . Оно представляет собой видовое отношение между более общим классом (суперкласс или родительский класс) и более специфическим видом класса (подкласс или дочерний класс). Подкласс является видом суперкласса. Там, где допустимо использование суперкласса, может использоваться и объект подкласса.
Обобщение делает невозможным переопределение уже заданных свойств. Атрибуты и операции, уже определенные для суперкласса, могут повторно использоваться в подклассе. Говорят, что подкласс наследует (inherit) атрибуты и методы его родительского класса. Обобщение способствует пошаговой спецификации, использованию общих свойств разными классами и лучшей локализации изменений. Обобщение изображается в виде незаполненного треугольника на конце линии отношения, присоединенной к родительскому классу. На диаграмме классов Клиент является суперклассом, a Физическое лицо и Юридическое лицо - подклассами. Классы Физическое лицо и Юридическое лицо наследуют все атрибуты класса Клиент.
Центральным классом рассматриваемой модели стал класс Договор . Факт того, что документы создаются Клиентами, а вносятся в систему Операторами показан на диаграмме существованием связи между объектами Клиент - Договор и Договор-Оператор. Кратность этой ассоциации вполне объяснима: Клиент может создать один документ или их множество (кратность в этой позиции - [1. n]), и он обязательно должен быть создан (и впоследствии введен оператором в систему), на что и указывает кратность ассоциации [1. n].
Класс Договор служит для хранения всех договоров об оказании услуг связи, по структуре абсолютно идентичных. Поэтому различие между ними устанавливается посредством атрибута тип платежного документа.
Клиент может в силу определенных обстоятельств составить заявление, но также заявление может быть и не составлено, на что указывает кратность [0. .1].
Итак, формирование диаграммы классов-сущностей окончено. Мною были определены типы объектов, определяющих будущую модель базы данных, а также связи, существующие между ними. Однако построенную диаграмму классов нельзя назвать полной статической моделью системы в силу отсутствия многих важных элементов, таких как управляющие и интерфейсные классы.
2.3 Моделирование видов деятельности
Модели видов деятельности (Activity Diagram ) строятся для описания общей последовательности действий для нескольких объектов и вариантов использования. На диаграммах этого типа представляются переходы потока управления от одной деятельности к другой внутри системы. Этот вид диаг?