Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Diploma Нечпай.doc
Скачиваний:
59
Добавлен:
13.04.2015
Размер:
3.74 Mб
Скачать

2 Перечень требований к программной системе

2.1 Общие требования к разработанному программному продукту

Разработанный программный продукт должен быть основан на технологии «клиент-сервер» [4]. Это способ взаимодействия программных компонентов, при котором они образуют единную систему. Существует некий клиенский процесс, требующий определенных ресурсов, а также серверный процесс, который эти ресурсы предоставляет. На рис. 2.1 показана архитектура этого типа.

Рисунок 2.1 - Общая схема системы с архитектурой «клиент-сервер»

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

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

Рисунок 2.2 - Общая функциональная схема автоматизированной системы

Для обеспечения целостности данных в БД должны были реализованы:

  • индексация первичных ключей;

  • каскадное удаление зависимых данных;

  • поддержка внешних ключей;

  • централизованное хранение данных;

  • восстановление данных в исключительных ситуациях;

  • контроль входных данных;

  • управление данными (вставка, редактирование, удаление данных);

  • выдача результатов на запросы пользователей [10].

2.2 Требования к модели данных

Среди множества целей, стоящих перед проектированием базы данных (БД), следующие представляются наиболее важными [7]:

  • возможность хранения всех необходимых данных в БД;

  • исключение избыточности данных;

  • сведение числа хранимых в БД отношений к минимуму;

  • нормализация отношений для упрощения решения проблем, связанных с обновлением и удалением данных.

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

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

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

Нормализация отношений – представляет собой разбиение одного отношения на два или более в соответствии со специальной методикой разбиения [7].

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

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

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

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

Четвертая нормальная форма запрещает хранить независимые атрибуты в одном и том же отношении, когда между этими атрибутами существует связь вида “многие ко многим”.

Рассмотренные выше нормальные формы относятся к методу декомпозиции на основе функциональных зависимостей [7], который является пригодным при условии небольшого числа задействованных атрибутов. В нашем случае число атрибутов существенно усложняют применение этого метода. Поэтому применим метод “сущность-связь” (entity-relation), который отличается от метода декомпозиции тем, что функциональные зависимости привлекаются не на начальном, а на конечном этапе проектирования. Сущность – некоторый объект, имеющий экземпляры, отличающиеся друг от друга и допускающие однозначную идентификацию (обычно существительное). Связь – соединение между двумя или более сущностями (обычно глагол). Атрибут – свойство сущности, а если он или набор атрибутов используется для идентификации экземпляра сущности, то называется ключом сущности. Важной характеристикой связи между двумя (и более) сущностями является степень связи: “один к одному”, “один ко многим”, ”многие ко многим”. Экземпляры сущности, участвующие в связи, делятся на класс принадлежности: обязательные или необязательные. После построения диаграмм ER-типа, из них получают отношения, анализируя степень связи между сущностями [7].

2.3 Алгоритмизация автоматизированной системы управления мебельным производством

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

  • алгоритмы, связанные с проектированием ПП;

  • алгоритмы реляционной алгебры, необходимые для работы с БД;

  • алгоритмы, используемые в клиентской части программы.

Известны три метода проектирования программных продуктов:

  • метод проектирования сверху вниз;

  • метод потоков данных

  • объектно-ориентированное проектирование.

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

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

Объектно-ориентированное проектирование подход, в основе которого лежит представление о том, что программную систему нужно проектировать как совокупность взаимодействующих друг с другом объектов, рассматривая каждый объект как экземпляр определённого класса, причём классы образуют иерархию. Объектно-ориентированный подход отражает топологию новейших языков высокого уровня, таких как Smalltalk,ObjectPascal,C++ иJava.

Объектно-ориентированному проектированию присущи:

- абстрагирование – выделение существенных характеристик некоторого объекта, отличающих его от всех других видов объектов и, таким образом, чётко определяющее его концептуальные границы с точки зрения наблюдателя;

- инкапсуляция – отделение друг от друга элементов объекта, определяющих его устройство и поведение для изоляции контрактных обязательста абстракции от их реализации;

- абстракция и инкапсуляция дополняют друг друга: абстрагирование направлено на наблюдаемое поведение объекта, а инкапсуляция занимается внутренним устройством. Инкапсуляция, таким образом, определяет чёткие границы между различными абстракциями;

- модульность – это свойство системы, которая была разложена на внутренне связные, но слабо связанные между собой модули.

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

Основными видами иерархических структур применительно к сложным системам являются структура классов (иерархия “is-a”) и структура объектов (иерархия ”part of”).

Также имеются еще три дополнительных элемента:

- типизация – способ защититься от использования объектов одного класса вместо другого, или по крайней мере управлять таким использованием;

- параллелизм – это свойство, отличающее активные объекты от пассивных. Оно позволяет различным объектам действовать одновременно;

- сохраняемость – это способность объекта существовать во времени, переживая породивший его процесс, и (или) в пространстве, перемещаясь из своего первоначального адресного пространства.

Использование этих элементов проектирования позволяет увеличить производительность любой проектируемой системы. Таким образом, для проектирования ПП использовался объектно-ориентированный подход.

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

В результате анализа выбрана реляционная модель данных с использованием классической архитектуры клиент/сервер.

Любой язык работы с базами данных должен предоставлять пользователю следующие возможности [4]:

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

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

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

Кроме того, язык работы с БД должен решать все указанные выше задачи при минимальных усилиях со стороны пользователя, а структура и синтаксис его команд должны быть достаточно просты и доступны для изучения. И, наконец, он должен быть универсальным, т.е. отвечать некоторому признанному стандарту, что позволит использовать один и тот же синтаксис и структуру команд при переходе от одной СУБД к другой.

SQL является основным языком обработки данных в реляционных базах данных. Все наиболее распространенные серверы баз данных применяют также внутренний SQL, который еще называют процедурным SQL [13]. Он позволяет работать со структурами данных более высокого уровня. Вместо того, чтобы манипулировать множествами строк. Благодаря умению SQL манипулировать множествами результаты одного предложения SQL могут использоваться как ввод для другого. SQL не заставляет специфицировать метод доступа к данным. Это позволяет сконцентрироваться на получении желаемых результатов. SQL предоставляет легко усваиваемые команды, которые согласуются и одинаково применяются всеми типами пользователей.

Учитывая вышеперечисленные преимущества SQL, в качестве средства алгоритмизации используем этот язык для создания программного продукта.

Под алгоритмом понимается точно определенное правило действий, для которого задано указание: как и в какой последовательности это правило необходимо применять к исходным данным задачи, чтобы получить ее решение [14].

Главной особенностью любого алгоритма является формальное исполнение, позволяющее выполнять заданные действия или команды не только человеку, но и различным исполняющим техническим устройствам. Множество команд, которые в состоянии выполнить данное устройство, называется системой команд исполнителя (СКИ). Алгоритм может быть понят и выполнен в том случае, если его команды входят в СКИ.

Каждый алгоритм должен быть:

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

  • дискретным, т.е. выполняться команды алгоритма должны последовательно, с точной фиксацией моментов окончания выполнения одной команды и начала выполнения следующей;

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

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

Процесс составления алгоритмов называется алгоритмизацией.

Алгоритмы могут быть заданы: словесно, графически, псевдокодом.

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

Графическое задание, или блок-схема – способ представления алгоритма геометрическимифигурами, называемымиблоками. Последовательность блоков и соединительных линий образуют блок-схему [15]. Схемы алгоритмов обладают большей наглядностью, чем словесная запись алгоритма. Однако эта наглядность быстро теряется при изображении большого алгоритма, в этом случае схема получается плохо обозримой. Единой системой программной документации стандартизовано два метода описания алгоритмов программ: при помощи блок-схем и при помощи р-схем [15].Достоинством метода является его независимость от языка реализации, позволяющаядобиться переносимости алгоритмического обеспечения.

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

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