Пояснительная записка (1207243), страница 3

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

Диаграмма последовательности наглядно отображает временной аспект взаимодействия. Она имеет два измерения. Одно измерение (слева-направо) указывает на порядок вовлечения экземпляров сущностей во взаимодействие. Крайним слева на диаграмме отображается экземпляр актера или объект, который является инициатором взаимодействия. Правее отображается другой экземпляр сущности, который непосредственно взаимодействует с первым и т.д. Второе измерение (сверху-вниз) указывает на порядок обмена сообщениями. Начальному моменту времени соответствует самая верхняя часть диаграммы. Масштаб на оси времени не указывается, поскольку диаграмма отображает лишь временную упорядоченность взаимодействия типа «раньше-позже».

На диаграмме последовательности отображается ряд специфичных элементов, которые отсутствуют на диаграмме коммуникации.

На рисунок 2.7 приведена диаграмма последовательности «Авторизация пользователя». Данная диаграмма показывает пошаговое взаимодействие актёра и системы, в данном случаи Пользователя и Веб-сайт. Пользователь заходит на сайт интернет-магазина и в главном меню выбирает пункт «Авторизация». Система переходит на форму Авторизации, где Пользователю выводится сообщения «Введите данные». Пользователь вводит данные Логина и Пароля, затем система обращается к серверу базы данных с запросом на получения данных пользователя. После получения данных с сервера система сверяет данные и в случаи несовпадения данных Пользователю выводится сообщения «Попробуйте снова», а если данные совпадают, то система запустит тот интерфейс Пользователя, который соответствует его роли в системе.

Рисунок 2.7 – Диаграмма последовательности «Авторизация пользователя»

Рассмотрим рисунок 2.8 на нём изображена диаграмма последовательности «Управления товарами». Пользователь авторизуется в системе чтобы получить доступ к интерфейсу «Администратора».

Администратор выбирает пункт меню «Управления товарами», после открытия формы Администратор может просматривать список товаров, а также он может добавить новый товар, редактировать или удалить уже имеющиеся товар.

При выборе пункта «Добавить товар» система открывает форму добавления товара, затем система выводит сообщения «Введите данные».

Администратор вводит данные о новом товаре.

При сохранении данных система отправляет запрос серверу на добавления новой записи в базе данных.

После добавления записи в базу данных система возвращается в форму «Управления товарами».

При выборе пункта «Редактировать товар» система открывает форму редактировать товар, затем выводит сообщения «Введите данные». Администратор вводит изменённые данные товара.

При сохранении данных система отправляет запрос серверу на изменения записи в базу данных.

После изменения записи в базе данных система возвращается в форму «Управления товарами».

При выборе пункта «Удалить товар». Система отправляет запрос на удаление записи в базу данных.

После удалении записи в базе данных система возвращается в форму «Управления товарами».

Данная диаграмма последовательности может применяться не только к управлению товаров, но также к управлению категориями и подкатегориями товаров и управлению блогами.

Рисунок 2.8 – Диаграмма последовательности «Управления товарами»

Диаграмма коммуникаций

Диаграмма коммуникации – диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации.

В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).

На диаграмме коммуникации основное внимание уделяется структуре взаимодействия. Помимо общих элементов (экземпляров актеров, объектов и сообщений) между участниками взаимодействия отображаются ненаправленные ассоциации, над которыми указываются передаваемые ими сообщениями. Другой отличительной особенностью является использование в спецификации сообщений нумерации, отражающей порядок их выполнения. Проектировщикам диаграмма коммуникации может дать богатый материал о распределении обязанностей между объектами. Так, например, если диаграмма напоминает форму звезды, то можно сделать вывод, что система сильно зависит от центрального объекта.

В этом случае стоит подумать о более равномерном распределении обязанностей между участниками взаимодействия. Или, наоборот, если в системе хранится и обрабатывается конфиденциальная информация, то большинство сообщений должно проходить через ядро безопасности – классы, отвечающие за идентификацию, аутентификацию и, возможно, шифрование / расшифрованные данных.

На рисунок 2.9 представлена диаграмма коммуникации «Авторизация пользователя». Данная диаграмма сгенерирована автоматически на основе диаграммы последовательности, изображенной на рисунок 2.7.

На рисунок 2.10 представлена диаграмма коммуникации «Управления товарами». Данная диаграмма сгенерирована автоматически на основе диаграммы последовательности, изображенной на рисунок 2.8.

Рисунок 2.9 – Диаграмма коммуникации «Авторизация пользователя»

Рисунок 2.10 – Диаграмма коммуникации «Управления товарами»

2.3 Модель проектирования

Следующий этап в процессе создания системы – проектирование, в ходе которого на основании моделей, созданных ранее, создается модель проектирования. Назначение модели проектирования заключается в создании полного детализированного описания внутренней архитектуры и алгоритмов работы системы. Рекомендуется разрабатывать данную модель без привязки к конкретным языкам программирования, с помощью которых будет создаваться программный продукт, т. е. разрабатывать логическую модель. Стоит оговориться, что создать модель без оглядки на используемые языки программирования невозможно, но, по крайней мере, необходимо стремиться к этому.

Построение этой модели необходимо:

• для уточнения внутренней архитектуры и вариантов использования системы;

• уточнения требований;

• определения детализированных алгоритмов работы системы в целом и ее отдельных элементов.

Диаграмма классов

Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы.

Диаграмма классов представляет собой некоторый граф, вершинами которого являются элементы типа "классификатор", которые связаны различными типами структурных отношений. Следует заметить, что диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи. Когда говорят о данной диаграмме, имеют в виду статическую структурную модель проектируемой системы. Поэтому диаграмму классов принято считать графическим представлением таких структурных взаимосвязей логической модели системы, которые не зависят или инвариантны от времени.

Класс (class) в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов.

Предполагается, что окончательный вариант диаграммы содержит наиболее полное описание классов, которые состоят из трех разделов или секций. Иногда в обозначениях классов используется дополнительный четвертый раздел, в котором приводится семантическая информация справочного характера или явно указываются исключительные ситуации.

Имя класса должно быть уникальным в пределах пакета, который описывается некоторой совокупностью диаграмм классов (возможно, одной диаграммой)

Атрибут класса определяет его свойства.

Метод представляет собой некоторый сервис, предоставляющий каждый экземпляр класса по определенному требованию. Совокупность операций характеризует функциональный аспект поведения класса.

Далее приведены диаграммы классов для рассмотренных пакетов (рисунок 2.11) и (рисунок 2.12). Каждая диаграмма представлена в двух экземплярах: как логическая (на русском языке) и как физическая (с учетом языка программирования).

Рисунок 2.11 – Диаграмма классов пакета Database – логическая

Рисунок 2.12 – Диаграмма классов пакета Database – физическая

2.4 Модель реализации

Основная цель, преследуемая при построении модели реализации, – получение работоспособной версии системы. Помимо непосредственного написания программного кода будущей системы, на данной стадии окончательно определяется логическая и физическая организация классов в виде компонентов и подсистем, а также топология распределенной информационной системы.

Таким образом, при разработке модели преследуются цели:

• определение окончательного состава, структуры и кода классов;

• распределение классов по компонентам и подсистемам;

• определение топологии распределенной системы и распределение подсистем по узлам сети;

• планирование итераций (версий) сборки системы;

• сборка версий системы.

При разработке модели реализации рекомендуется построить диаграммы:

• компонентов;

• развертывания.

Диаграмма компонентов

Диаграмма компонентов – статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.

Диаграмма компонентов позволяет определить состав программных компонентов, в роли которых может выступать исходный, бинарный и исполняемый код, а также установить зависимости между ними.

При разработке диаграмм компонентов преследуются цели:

• спецификация общей структуры исходного кода системы;

• спецификация исполнимого варианта системы.

Данная диаграмма обеспечивает согласованный переход от логического к физическому представлению системы в виде программных компонентов. Одни компоненты могут существовать только на этапе компиляции программного кода, другие – на этапе его исполнения.

Основными элементами диаграммы являются компоненты, интерфейсы и зависимости между ними. Кроме этого, на ней могут отображаться ключевые классы, входящие в компоненты.

Компонент – это физическая часть системы. Компоненты, представляющие собой файлы с исходным кодом классов, библиотеки, исполняемые модули и т.п., которые должны обладать согласованным набором интерфейсов. Для их графического представления используются следующие графические символы.

Внутри компонента, как и класса, могут быть выделены дополнительные секции, в которых указываются предоставляемые или необходимые для работы интерфейсы и классы, методы, наименование файла-компонента и т.п.

Интерфейс – это внешне видимый, именованный набор операций, который класс, компонент или подсистема может предоставить другому классу, компоненту или подсистеме, для выполнения им своих функций.

В некоторых языках программирования, в частности в C#, интерфейс представляет собой отдельный класс, включаемый и реализуемый (конкретизируемый) в части программного кода операций в составе других классов.

На диаграмме компонентов интерфейс отображается так же, как и на диаграмме классов (слева от компонента необходимые для работы интерфейсы, справа - предоставляемые).

Отношение ассоциации отображается между компонентами и их интерфейсами.

На рисунке 2.13 показана диаграмма компонентов, в которой отражены основные элементы разрабатываемой информационной системы.

Рисунок 2.13 – Диаграмма компонентов

вв

Диаграмма развертывания

Физическое представление информационной системы не может быть полным, если отсутствует информация о ее топологии и необходимых аппаратных средствах. Помимо сведений о компьютерах, обрабатывающих информацию, необходимо определить, как будет осуществляться связь между ними и какие дополнительные ресурсы (принтеры, модемы, маршрутизаторы и т. д.) должны быть задействованы. Конечно, если разрабатывается однопользовательская локальная система, то отсутствует необходимость в разработке подобной диаграммы. Однако при разработке сетевых корпоративных приложений ситуация представляется совсем по-другому.

Во-первых, сложные информационные системы могут реализовываться на различных вычислительных платформах и технологиях доступа к базам данных. Наличие корпоративной сети требует решения целого комплекса дополнительных задач по рациональному размещению компонентов по узлам сети, что определяет общую производительность информационной системы.

Во-вторых, интеграция информационной системы с Интернетом определяет необходимость решения дополнительных вопросов при проектировании системы, таких как обеспечение безопасности и доступности информации для корпоративных клиентов.

Наконец, доступ и манипулирование данными в рамках двух или трехуровневой технологии «клиент-сервер» также требуют размещения больших БД в различных сегментах корпоративной сети, их резервного копирования, архивирования, кэширования для обеспечения необходимой производительности системы в целом. Эти аспекты также требуют визуального представления с целью спецификации программных и технологических особенностей реализации распределенных архитектур.

Второй формой физического представления программной системы является диаграмма размещения (развертывания). Она применяется для представления общей конфигурации и топологии распределенной информационной системы, содержит сведения о распределении компонентов по отдельным узлам системы и каналом связи между аппаратными средствами (соединения).

Характеристики

Список файлов ВКР