Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Kursovoy_proekt Переделаный.docx
Скачиваний:
1
Добавлен:
01.05.2025
Размер:
724 Кб
Скачать

2 Анализ требований

2.1 Описание концептуальной модели

Склад предприятия является самой первой и самой последней точкой движения продукции по предприятию, и от ритмичности его работы во многом зависит ВЕСЬ производственный цикл. Одним из способов повышения надежности и скорости работы предприятия является формирование и управление функционированием складским хозяйством предприятия на основе последних достижений складской логистики. Особое значение имеет процесс учёта товара на складе. Применение автоматизированных систем учёта помогает обеспечить точность и своевременность ведения учёта, скорость получения необходимых данных, а также предоставляет возможность удалённого просмотра данных.

Разрабатываемая система служит для облегчения учёта товарооборота на складе, а также для ускорения этого процесса.

Основным объектом манипулирования системы служат товары и записи о поставках, которые содержат информацию о доставленном товаре, объёме партии и ответственном лице-работнике склада.

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

2.2 Словарь предметной области

Журнал поставок – набор записей о ввозе-вывозе товара, с указанием товара, объёма партии и ответственного лица.

Объём партии – число единиц продукции в данной партии.

Ответственное лицо – сотрудник склада, производящий контроль и учёт поставки.

Поставка – операция ввоза партии товара на склад или его вывоза со склада.

Склад – помещение, комплекс помещений, предназначенный для хранения материальных ценностей.

Товар – любая вещь, которая может храниться на складе.

2.3 Основные прецеденты использования по

4 Архитектурное и детальное проектирование по.

4.1 Архитектурное проектирование

На сегодняшний день наибольшее распространение следующие архитектуры распределенных систем обработки данных:

  • файл-сервер;

  • стандартная модель клиент/сервер;

  • многоуровневая модель клиент/сервер.

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

Основными недостатками данной архитектуры можно считать следующее:

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

  • средства защиты данных, поддержки целостности данных, транзакции не предусмотрены данной архитектурой;

  • реализация этих функций ложится на разработчиков, что усложняет процесс создания системы.

Многопользовательские системы, основанные на классической технологии клиент/сервер, называются двухзвенными системами или системами с «толстым клиентом».

Они состоят из двух частей – серверной и клиентской.

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

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

На рисунке 6.1 представлена схема классической архитектуры клиент/сервер.

Рисунок 4.1 - Классическая архитектура клиент-сервер

Многозвенными системами клиент/сервер называют более новые системы с так называемым ”тонким” клиентом. В этом случае функциональность, связанная с доступом к данным, возлагается на другое приложение, которое обычно называется сервером приложений и является клиентом серверной СУБД.

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

Таким образом, информационная система становится трехзвенной, а сервер приложений является средним звеном в цепи “тонкий” клиент – сервер приложений – сервер баз данных.

На рисунке 6.2 представлена схема архитектуры клиент/сервер с “тонким” клиентом.

Для выполнения курсового проекта ввиду небольшого объёма работ и отсутствия больших нагрузок на систему выберем классическую двухслойную реализацию архитектуры «клиент-сервер».

Рисунок 4.2 - Архитектура клиент – сервер с «тонким» клиентом

4.2 Концептуальная диаграмма классов

4.3 Разработка логической модели БД ПО.

4.4 Детальное проектирование

4.4.1 Проектирование клиентской части ПО

Клиентская составляющая ПО представляет собой десктопное приложение.

В архитектуре данного приложения можно выделить три составляющих:

Классы-сущности предметной области

Рисунок 4.3 – Классы-сущности предметной области

Эти классы хранят данные из таблиц БД и служат для представления объектов предметной области в проектируемом приложении.

Слой доступа к данным

Рисунок 4.4 – Классы слоя доступа к данным

Слой доступа к данным служит для получения данных из БД и управления ими.

Для написания слоя доступа к данным воспользуемся паттерном проектирования Row Data Gateway.

Суть его в том, что для каждой таблицы БД создаётся класс-репозиторий (repository, англ. хранилище). Данный класс содержит набор методов, обеспечивающих реализацию всех базовых методов работы с таблицей: выборка набора записей, поиск, вставка, изменение, удаление записи, а также некоторых специфических методов, если того требует предметная область.

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]