Пояснительная записка Аушев (1206665), страница 2
Текст из файла (страница 2)
В ходе анализа проектируемой ИС было определено три актера:
-
администратор;
-
пользователь;
-
гость;
и следующие варианты использования:
-
регистрация;
-
просмотр контактной информации;
-
просмотр услуг;
-
просмотр каталога;
-
поиск материала;
-
оформление заказа;
-
добавление и удаление товаров/изменение данных;
-
просмотр и редактирование личных данных;
На рисунке 2.1 изображена контекстная диаграмма вариантов использования проектируемого интернет-магазина. Контекстная диаграмма представляет собой граф, узлами которого являются достаточно крупные блоки функциональности системы.
На рисунке данной диаграммы присутствуют все актеры, участвующие в процессах, происходящих в компании: пользователь (зарегистрированный или незарегистрированный), администратор, менеджер, техник.
Отдельной частью графа представлены варианты использования, в которых непосредственное участие принимает администратор: анализ состояния сети и контроль активности пользователя.
Незарегистрированному пользователю (гостю) доступен лишь просмотр общей информации, тогда как зарегистрированный пользователь получает следующие возможности: просмотр личной информации, осуществление заказа.
Рисунок 2.1 – Контекстная диаграмма вариантов использования
На основе контекстной диаграммы были созданы несколько диаграмм декомпозиции. Такие диаграммы, как правило, представляют собой «ромашку», в центре которой декомпозируемый вариант использования, а вокруг – входящие в него обязательные или расширяющие составные части. В работе представлены две диаграммы декомпозиции для разных вариантов использования.
Диаграмма декомпозиции варианта использования «Оформление заказа», представленная на рисунке 2.2, отображает взаимодействие двух актеров – Пользователя и Администратора. Согласно данной диаграмме администратор должен просматривать новые заказы, изменять статус заказа с «Заказ ожидает обработки» на «Заказ принят» и оповещать по почте пользователя о том, есть ли такие материалы в наличии, и в какой срок магазин может их доставить.
Рисунок 2.2 – Диаграмма декомпозиции варианта использования «Оформление заказа»
Диаграмма декомпозиции для варианта использования «Просмотр каталога», представленная на рисунке 2.3, описывает процесс просмотра каталога. В качестве актеров задействованы Гость и Пользователь.
Рисунок 2.3 – Диаграмма декомпозиции варианта использования «Просмотр каталога»
Диаграммы автоматов
После создания необходимых диаграмм вариантов использования осуществляется их детализация, главная цель которой – определить, в процессе какого поведения система обеспечит необходимую функциональность.
Одним из видов диаграмм, позволяющих детализировать варианты использования – это диаграммы автоматов.
Диаграмма автомата– это один из способов детального описания поведения в UML на основе явного выделения состояний и описания переходов между состояниями.
Диаграмма автоматов служит для моделирования динамических аспектов системы, она полезна при моделировании жизненного цикла объекта и используется для описания поведения, реализуемого в рамках варианта использования, или поведения экземпляра сущности (класса, объекта, компонента, узла или системы в целом).
Диаграмма автоматов является графом специального вида, который представляет некоторый автомат.
Вершинами графа являются возможные состояния автомата, изображаемые соответствующими графическими символами, а дуги обозначают его переходы из состояния в состояние.
Диаграммы состояний могут быть вложены друг в друга для более детального представления отдельных элементов модели.
В языке UML под состоянием понимается некоторый абстрактный объект, используемый для моделирования отдельной ситуации, в течение которой выполняются некоторые условия.
В проектируемой ИС предусмотрено четыре категории пользователей с разными функциями и правами, в соответствии с которыми и реализуется пользовательский интерфейс.
На рисунке 2.4 приведена контекстная диаграмма автоматов, представляющая собой некоторую иерархию выбираемых пользователем пунктов меню и диалоговых окон.
Инициализация той или иной подсистемы происходит после успешной аутентификации пользователя с учетом предоставленных ему прав доступа.
Рассмотрим диаграмму автоматов для подсистемы «Авторизация» (рис. 2.5). В ней учавствует пользователи. Пользователь – лицо или организация, которое использует действующую систему для выполнения конкретной функции. Для входа нужно вести логин и пароль. Далее система проверяет соответствие введенного логина и пароля. Если пользователь ввел данные верно, происходит его авторизация и получение прав. В противном случае выводится сообщение о неверно введенной паре логин/пароль, а также количестве оставшихся попыток входа в систему. Далее пользователю необходимо ввести данные заново. Для входа в систему предоставляется три попытки входа. Если превышено максимальное количество попыток ввода пароля происходит блокировка пользователя и принудительное закрытие приложения.
Рисунок 2.4– Контекстная диаграмма автоматов
Рисунок 2.5– Диаграмма автоматов для Подсистемы «Авторизация»
2.2 Разработка информационной модели
Следующим этапом разработки проектаweb-приложения является разработка информационной модели. Эта модель отражает отношения между элементами системы в виде структур данных. То есть разработка информационной модели сводиться к построению диаграммы классов анализа,схемы классов базы данных и диаграмм классов приложения.
Диаграмма классов анализа.
Фундаментальными понятиями объектно-ориентированного подхода являются понятия объекта и класса, которые представляются абстракциями реальной или воображаемой сущности (набора сущностей). Класс анализа – еще более абстрактная сущность, чем просто класс, представляет собой набор из одного или более классов. Таким образом, класс анализа – это укрупненная абстракция, которая на концептуальном уровне (без точного определения атрибутов и операций) описывает некоторый фрагмент системы.
Диаграмма классов анализа по существу является прообразом классической диаграммы классов. Элементами, отображаемыми на диаграмме, являются классы и отношения между ними. При этом для отображения классов можно воспользоваться стандартным обозначением класса (прямоугольник) с указанием внутри него соответствующего стереотипа или значком-стереотипом.
Диаграмма классов представляет собой граф, вершинами которого являются различные виды классов анализа (управляющий, граничный, класс сущности), связанные различными типами структурных отношений.
На рисунке 2.6 приведена диаграмма классов анализа проектируемой системы. На диаграмме сосредоточены граничные классы, представляющие собой структуру пользовательского интерфейса, и классы сущности, представляющие собой структуру базы данных.
Рисунок 2.6 – Диаграмма классов
Условно ее можно разделить на три составляющих: интерфейсы подсистемы, классы-сущности таблиц БД и управляющие классы. Управляющий класс Соединение с БД осуществляет взаимодействие приложения с базой данных. Группа классов Отчеты реализуют выборки для организации сводных таблиц. Основной класс представляет основной поток приложения, из которого вызываются все остальные потоки, формы и т.д.
Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:
-
концептуальная точка зрения – диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;
-
точка зрения спецификации – диаграмма классов применяется при проектировании информационных систем;
-
точка зрения реализации – диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).
Понятие класс присутствует и в объектно-ориентированных языках программирования, то есть между классами UML и программными классами есть соответствие, являющееся основой для автоматической генерации программных кодов или для выполнения реинжиниринга. Каждый класс имеет имя, атрибуты и операции.С точки зрения структурного подхода, атрибуты – это переменные, а операции (методы) – это функции, описанные в теле класса.
Классы могут иметь логическую и физическую реализации. Логические диаграммы классов, в отличие от физических, строятся без привязки к языкам программирования.
Прежде чем перейти к разработке этих двух моделей, продумаем структуру таблиц 2.1-2.7 базы данных.
Таблица 2.1 –Реализованные товары
| Название | Код | Тип |
| IDПродукта | ProductID | int |
| IDЗаказа | OrderID | int |
| Количество | Count | int |
Таблица 2.2 –Товары
| Название | Код | Тип |
| IDТовара | ProductID | int |
| Тип | TypeID | int |
| Наименование | ProductName | nvarchar(MAX) |
| Цена | Price | int |
| Поставщик | ManufacturerID | int |
| Информация | Info | nvarchar(MAX) |
| Изображение | ImagePath | nvarchar(255) |
| Количество | Count | int |
Таблица 2.3 –Заказы
| Название | Код | Тип |
| IDЗаказа | OrderID | int |
| IDПользователя | UserID | int |
| Дата | RegData | datetime |
| Цена | Cost | decimal(18, 2) |
| Доставка | Delivery | bit |
| Фамилия | SurName | nvarchar(MAX) |
| Имя | Name | nvarchar(MAX) |
| Номер телефона | PhoneNumber | nvarchar(MAX) |
| Улица | Street | nvarchar(MAX) |
| Дом | House | int |
| Квартира | Flat | int |
| Дополнительная информация | Addinfo | nvarchar(MAX) |
| Способ оплаты | Method | int |
Таблица 2.4 –Тип товара
| Название | Код | Тип |
| IDТипа | TypeID | int |
| Наименование | TypeName | nvarchar(50) |
| IDРодительский типа | ParentTypeID | int |
Таблица 2.5 –Способ оплаты
| Название | Код | Тип |
| Способ оплаты | Method | int |
| Наименование | MethodName | nvarchar(MAX) |
Таблица 2.6 –Поставщик
| Название | Код | Тип |
| IDПоставщика | ManufactorerID | int |
| Имя | Name | nvarchar(50) |
| Описание | Description | nvarchar(MAX) |
| Изображение | ImagePath | nvarchar(255) |
Таблица 2.7 –Аккаунт
| Название | Код | Тип |
| IDПользователя | UserID | int |
| Логин | Login | nvarchar(50) |
| Пароль | Password | nvarchar(50) |
| Электронная почта | | Nvarchar(50) |
Далее на основе представленных таблиц приведены диаграммы классов для разрабатываемой информационной системы с учетом специфики шаблона проектирования MVC (Model-view-controller, Модель-представление-контроллер). Было создано два вида диаграмм классов: диаграмма классов приложения (в этой диаграмме представленные классы, имеющие атрибуты, методы и свойства) и схема БД (диаграмма представляет собой структуру базы данных, которая будет создана с применением реляционных баз данных, поэтому на ней приведены только атрибуты каждого класса). Каждый вид диаграммы представлен в двух экземплярах: логическая (на русском языке, описывает структуру данных без привязки к конкретным языкам программирования и СУБД) и физическая (с учетом конкретного языка программирования и СУБД).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
