Webсистема "Складская логистика " на платформе asp net mvc
 Скачать 377 Kb.
|
1 2 КУРСОВОЙ ПРОЕКТ ТЕМА: Web-система "Складская логистика " на платформе asp. net mvc. Выполнил: Проверил: 2022 г. СОДЕРЖАНИЕ ЗАДАНИЕ 3 ВВЕДЕНИЕ 4 Проектирование и разработка базы данных 6 Концептуальное проектирование базы данных 6 Логическое проектирование базы данных 9 Физическое проектирование базы данных 9 Создание таблиц 9 Создание триггеров для формирование первичного ключа 10 Создание дополнительных триггеров 10 Создание процедур и функций 12 Проектирование и разработка приложения 15 Функциональные возможности системы 15 Описание входной и выходной информации 16 Разработка интерфейсных форм приложения 17 Руководство пользователя 23 Требования к техническому и программному обеспечению 26 Программа и методика испытания разработанной системы 27 Тестирование работоспособности системы через базу данных 27 Тестирование работоспособности системы через интерфейс пользователя 31 ЗАКЛЮЧЕНИЕ 35 СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 36 ПРИЛОЖЕНИЕ А. Диаграмма в нотации Питера-Чена 39 ПРИЛОЖЕНИЕ Б. ER-диаграмма 40 ПРИЛОЖЕНИЕ В. Коды создания таблиц 41 ЗАДАНИЕ Приложение должно предоставлять доступ к просмотру и редактированию данных в зависимости от роли пользователя в системе. Роль – совокупность связанных функций, выполняемых пользователем приложения. Доступ к приложению обеспечивается на основании введенных учетных данных. Права доступа назначаются администратором системы. Администратор системы – сотрудник компании, ответственный за функционирование ИС, настройку и обеспечение целостности данных. ВВЕДЕНИЕ В наши дни получила широкое распространение сеть Интернет. Благодаря этому, появилась возможность быстрого и удобного доступа к различным источникам информации. Интернет обладает рядом достоинств, таких, в частности, как широкомасштабность и относительная доступность. «Склад учет» – это автоматизированное рабочее место (далее АРМ) работника строительной организации, ответственного за учет, выдачу и прием строительных материалов на территории склада. К приложению также могут иметь доступ другие работники предприятия из управляющего и инженерного состава. Приложение должно позволять оперативно изменять информацию в системе о количестве имеющегося на складе строительного материала. Автоматизированный учет выполняемых приходно-расходных операций будет разработан в рамках полнофункциональной информационной системы. Цель работы: систематизация и закрепление полученных теоретических знаний и практических умений по разработке информационных систем с использованием языка программирования C# и СУБД Oracle в соответствии с требованиями Федерального государственного образовательного стандарта высшего образования по дисциплине «Платформа .NET» направления подготовки 09.03.02 «Информационные системы и технологии». Задачи работы: изучить литературу по разработке приложений на языке программирования C# в среде Visual Studio и по проектированию и разработке базы данных в СУБД Oracle; получить практический опыт разработки базы данных в СУБД Oracle и информационной системы на языке C#. Для разработки программного продукта был выбран язык программирования C#. Серверная часть разработана на СУБД Oracle 11g. Клиентская часть реализована в форме Web-приложения с использованием фреймворка ASP.NET MVC. Проектирование и разработка базы данных Требования к системе в целом: Система должна предоставлять полноценный оконный интерфейс Windows-приложения; Система должна предоставлять широкие и гибкие возможности настройки и доработки под нужды предприятия; Система должна обеспечивать безопасность на уровне разграничения прав доступа пользователей по ролям и в соответствии с организационной структурой предприятия; Функциональные требования Система должна позволять вести общую информацию по следующим справочникам: Пользователи; Роли пользователей; Права доступа; материалы А также позволять производить операции с данными таблицы «склад», обрабатывая и по возможности исключая ошибки пользовательского ввода. Система должна обеспечивать хранение архивных данных по произведенным операциям с привязкой к пользователям, инициировавшим изменение данных. Система должна позволять получать отчёты по шаблонам, утвержденным Управляющим компании. Проектирование системы Процесс проектирования приложения был разбит на три этапа: Проектирование структуры классов приложения, проектирование базы данных и проектирование интерфейса. UML-диаграмма классов Диаграмма классов UML позволяет обозначать отношения между классами и их экземплярами. Отношения между классами любого объектно-ориентированного приложения можно представить в виде структурной схемы, которая представлена в приложении к курсовому проекту. Необходимо построить UML-диаграмму классов, а затем отразить ее в объектно-ориентированном коде. Отношение обобщение – это наследование. Наследование объектом членов другого класса представлено в явном виде в классе Storage Coursework. User Controls.Material. Это пользовательский элемент управления, унаследовавший свойства и методы класса System.Windows. Forms. User Control, позволяющий «визуализировать» объект класса Storage_Coursework. Objects. Material. Но наследование происходит в неявном виде. Объект Storage_Coursework. Objects. Material m передается в конструктор пользовательского элемента управления и становится одним из его членов. При построении элемента управления в методе Setup Controls() происходит присвоение значений свойствам визуальных элементов от свойств этого члена. В коде метода SetupControls() это выглядит так: lbMaterialName.Text = material.MaterialName; т.е. визуальный объект lbMaterialName получает новое значение свойства Text от родительского (хотя наследование не явное) класса material (свойство MaterialName). Наследование можно представить в виде схемы (Рисунок 1): Отношение ассоциация показывает отношения между объектами-экземплярами класса. Пример бинарной ассоциации можно рассмотреть в отношении классов User и Role пространства имен Storage_Coursework. Objects Предоставление доступа к приложению осуществляется на основании совокупности прав, закреплённых за ролью. Каждый пользователь имеет только одну роль в приложении, а значит, имеет набор прав доступа, определённых этой ролью. Таким образом, между классами User и Role можно установить связь «один к одному» (Рисунок 2).  Рисунок 2  Рисунок 3 В свойстве User.UserRole получаем единственную роль пользователя так (Листинг 1): public Role UserRole { get { return Storage_Coursework.Providers. RoleProvider.GetUserRole(this.UserID); } Каждая роль содержит набор разрешений. Соответственно, связь между классами Role и RoleAccess будет «Один ко многим». Такое отношение называется N-арной ассоциацией (Рисунок 4).  Рисунок 4 Класс RoleAccess отвечает за права (разрешения), закреплённые за ролями. Например, ролям «администратор», «работник склада» и «прораб» дано разрешение на просмотр списка строительных материалов на складе. Кодовое название (AccessCode) этого разрешения StorageView. Проверку возможности просмотра списка материалов можно реализовать методом (Листинг 2): public bool ExistAccess(string accessCode) { return Storage_Coursework.Providers.RoleProvider. ExistAccess(this.RoleID, accessCode); } Таким образом, можно исключить класс RoleAccess из набора классов приложения, а получать наличие разрешения для текущего пользователя на выполнение той или иной операции в системе можно таким путем: bool access = currentUser.UserRole.ExistAccess(“ShowAdminPanel”) Исключая вспомогательные классы, содержащие небольшое количество членов можно “облегчить” само приложение и упростить его дальнейшую разработку. В результате моделирования была получена диаграмма, показывающая отношения классов в приложении. На рисунке 5 пунктирной линией выделены классы, не вошедшие в состав приложения. Однако, эти классы имеют свою сущность в базе данных.  Рисунок 5 Отношения 1, 4 – бинарная ассоциация; Отношение 2 – N-арная ассоциация; Отношение 3 – обобщение. Классы, описывающие пользователя и права доступа, и классы, описывающие материалы и склад не взаимосвязаны. 3. Архитектура приложения Системная архитектура приложения определяет, как взаимодействуют элементы приложения и какую функциональность они предоставляют. Существует три типа системной архитектуры: одно-, двух- и многоуровневая. Одноуровневые приложения также называются монолитными. В сценарии построения многоуровневых приложений как правило используется разделение на клиентскую и серверную часть. Клиент предоставляет интерфейс пользователя, а сервер – приложение базы данных. В курсовой работе рассмотрен вариант с локально расположенным файлом базы данных, чтобы упростить демонстрацию работы приложения. Однако, созданные классы позволят без труда переориентировать программу для взаимодействия с удалённой БД. 3.1 Структура классов Класс User определяет учетные данные пользователя, прошедшего авторизацию в приложении. Он имеет минимальное количество свойств, необходимое для идентификации пользователя: UserID – идентификационный номер пользователя; UserName – имя пользователя (логин); UserPassword – пароль При необходимости можно расширить данный класс полями: фамилия, имя, отчество, год рождения, дата трудоустройства, должность и пр. При этом необходимо создать поля с теми же названиями в соответствующей таблице базы данных. Это связано с использованием пространства имен System.Reflection (.NET Framework). Метод присвоения значений свойствам объектов с использованием System.Reflection рассмотрен в описании класса ObjectProvider. Класс Role позволяет присваивать пользователю ту или иную роль при использовании приложения, определить его права на редактирование и просмотр данных. Каждому пользователю присваивается только одна роль. Список возможностей (данные таблицы RoleAccess) привязан к роли. Приложение разрешает или запрещает определенный функционал для текущего пользователя на основании того, имеет или нет роль этого пользователя разрешение с указанным AccessCode. Пример метода проверки права пользователя на совершение операции добавления материала на склад: boolean user. Класс Material имеет следующие свойства, позволяющие описать строительный материал, размещаемый на складе: MaterialID – идентификатор материала; MaterialName – название; MaterialMeasure – единица измерения Для получения количества материала, находящегося на складе, служит свойство StorageCount. Эти классы, находящиеся в пространстве имен Storage_Coursework.Objects наследуют свойства объектов (записей) БД соответствующих таблиц. 3.2 Классы-провайдеры Классы, служащие для конвертирования набора полученных в результате запроса данных в понятные приложению и удобные для разработчика объекты представлены в пространстве имен Storage_Coursework.Providers. Эти классы позволяют передать «требование» разработчика, допустим, получить все имеющиеся на складе материалы GetMaterials() в виде готового запроса к БД - SELECT * FROM Material. Таким образом, приложение поделено на несколько уровней. На нижнем уровне мы имеем класс для работы с базой данных Storage_Coursework.SqlDB, на промежуточном уровне – класс-провайдер, имеющий все необходимые разработчику методы получения готовых, понятных объектов на верхнем уровне и обеспечивающий запись изменений объектов на верхнем уровне в БД. Каждому из ключевых классов (User, Role, Material) предназначен свой класс-провайдер. 3.3 Провайдер объектов Класс Object Provider позволяет преобразовать строку данных из набора данных, полученных в результате запроса в экземпляр класса, описанного в приложении. Этот класс имеет всего один статический метод GetObject. Он принимает в качестве аргументов DataRow r – строка данных и Type objectType – тип возвращаемого объекта. После вызова этого метода, посредством System.Reflection осуществляется поиск конструктора в членах класса типа objectType. Затем создается объект этого класса и заполняются публичные свойства созданного экземпляра данными, содержащимися в исходной строке r. После чего метод возвращает полученный экземпляр. Пример использования метода для получения объекта User на основании введенных логина и пароля представлен ниже (Листинг 3): public static Storage_Coursework.Objects.User GetUser(string uName, string uPassword) { string query = String.Format("SELECT * FROM [User] WHERE UserName = '{0}' AND UserPassword = '{1}'", uName, uPassword); var ds = OleDB.ExecuteQuery(query); if (OleDB.DsIsNullOrEmpty(ds)) return null; return (Storage_Coursework.Objects.User) ObjectProvider.GetObject (ds.Tables[0].Rows[0], typeof (Storage_Coursework.Objects.User)); } Где ds – DataSet (набор данных), полученный в результате запроса. В его составе единственная таблица с единственной строкой данных (пользователь имеет уникальные логин и пароль). SqlDB – статический класс выполняющий запрос к БД. Если потребуется использование другого поставщика данных, то необходимо будет лишь заменить этот класс другим с такими же методами Execute Query (string query) и Ds Is Null Or Empty (DataSet ds), а также изменить строку подключения в конструкторе класса. 4. База данных База данных для приложения разрабатывалась с учётом дальнейшего её расширения. Добавление таблиц в БД должно сопровождаться добавлением классов с соответствующим именем в структуру классов приложения, в пространстве имен Storage_Coursework.Objects. 4.1 Средства проектирования База данных спроектирована в среде MS Sql Express 2012. Для работы приложения на компьютере пользователя должны быть запущены службы SQL Server. Перенос структуры БД на другую платформу не составит труда, однако для удобства демонстрации работы приложения было решено использовать локальную БД. 4.2 Перспективы расширения БД В рамках курсового проекта схема базы данных будет расширена рядом таблиц, что позволит приложению получить новые функции: Учет персонала, производящего операции в системе; Учет возвращенного материала с объекта на склад; Отслеживание сроков хранения материалов; Формирование средней стоимости всех материалов на складе; Возможность формирования списка ожидаемых материалов; Создание прорабом заказа на вывоз материала. 4.3 Схема базы данных База данных состоит из шести таблиц: User; UserRole; Role; RoleAccess; Storage; Material Схема представлена на рисунке 1.  Рисунок 6 Пользовательский интерфейс разработан с расчётом на невысокую компьютерную подготовку персонала, который будет иметь к нему доступ. При запуске программы пользователь должен будет авторизоваться, введя данные своей учётной записи в окне авторизации. В случае ввода неверных данных, работа приложения будет завершена. 4.4 Доступность элементов управления Интерфейс приложения будет иметь разный вид в зависимости от прав текущего пользователя. А точнее, в зависимости от набора разрешений, привязанных к роли этого пользователя. Например, работник склада может осуществлять любые операции, касающиеся манипуляций со строительным материалом на складе, но не должен иметь доступа к интерфейсу администратора системы. Прораб имеет право знать какое количество того или иного материала находится на складе, но не может самостоятельно производить приходно-расходных операций. На основании разрешений (прав), относящихся к роли текущего пользователя, изменяется видимость элементов управления на этапе загрузки формы. 1 2 |