- •1 Постановка задачи
- •1.1 Требования к разрабатываемому по
- •1.1.1 Требования пользователя
- •1.1.2 Требования к по
- •Интерфейс системы должен быть реализован на английском языке.
- •2 Анализ требований
- •2.1 Описание концептуальной модели
- •2.2 Словарь предметной области
- •2.3 Основные прецеденты использования по
- •4 Архитектурное и детальное проектирование по.
- •4.1 Архитектурное проектирование
- •Пользовательский интерфейс
- •4.4.2 Проектирование серверной части по
- •5 Проверка работоспособности по
- •Литература
- •Приложения Приложение а. Листинг исходного кода sql-спринтов для создания базы данных
- •Приложение б. Листинги исходных кодов классов клиентской части по Классы-сущности
- •Слой доступа к данным
- •Классы пользовательского интерфейса
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, то есть существует в программе в единственном экземпляре.
Слой доступа к данным необходим, чтобы инкапсулировать детали реализации доступа к данным от остальных логических составляющих проектируемого ПО. Теперь получение необходимой информации из БД из любой части программы будет происходить с помощью вызова одного метода Слоя доступа к данным, без необходимости задумываться о логике его работы.
