14
программ получило название блок-схемы алгоритма, которая
регламентировал использование условных обозначений в схемах алгоритмов,
программ, данных и систем.
Однако потребности практики не всегда требовали установления
вычислимости конкретных функций или разрешимости отдельных задач. В
языках программирования возникло и закрепилось новое понятие процедуры,
которое конкретизировало общее понятие алгоритма применительно к
решению задач на компьютерах. Так же, как и алгоритм, процедура
представляет собой законченную последовательность действий или
операций, направленных на решение отдельной задачи. В языках
программирования появилась специальная синтаксическая конструкция,
которая получила название процедуры.
Со временем разработка больших программ превратилась в серьезную
проблему и потребовала их разбиения на более мелкие фрагменты. Основой
для такого разбиения как раз и стала процедурная декомпозиция, при
которой отдельные части программы или модули представляли собой
совокупность процедур для решения некоторой совокупности задач. Главная
особенность процедурного программирования заключается в том, что
программа всегда имеет начало во времени или начальную процедуру
(начальный блок) и окончание (конечный блок). При этом вся программа
может быть представлена визуально в виде направленной
последовательности графических примитивов или блоков.
Важным свойством таких программ является необходимость завершения
всех действий предшествующей процедуры для начала действий
последующей процедуры. Изменение порядка выполнения этих действий
даже в пределах одной процедуры потребовало включения в языки
программирования специальных условных операторов типа if-then-eise и
Goto для реализации ветвления вычислительного процесса в зависимости от
промежуточных результатов решения задачи.
15
Рассмотренные идеи способствовали становлению некоторой системы
взглядов на процесс разработки программ и написания программных кодов,
которая получила название методологии структурного программирования.
Основой данной методологии является процедурная декомпозиция
программной системы и организация отдельных модулей в виде
совокупности выполняемых процедур. В рамках данной методологии
получило развитие нисходящее проектирование программ или
программирование «сверху-вниз».
Центральным понятием системного анализа является понятие системы,
под которой понимается совокупность объектов, компонентов или элементов
произвольной природы, образующих некоторую целостность. Определяющей
предпосылкой выделения некоторой совокупности как системы является
возникновение у нее новых свойств, которых не имеют составляющие ее
элементы.
Важнейшими характеристиками любой системы являются ее структура
и процесс функционирования. Под структурой системы понимают
устойчивую во времени совокупность взаимосвязей между ее элементами
или компонентами. Структура системы может отражать самые различные
взаимосвязи, в том числе и вложенность элементов одной системы в другую.
В этом случае принято называть более мелкую или вложенную систему
подсистемой, а более крупную - метасистемой.
Методология системного анализа служит концептуальной основой
системно-ориентированной декомпозиции предметной области. В этом
случае исходными компонентами концептуализации являются системы и
взаимосвязи между ними. Результатом системного анализа является
построение некоторой модели системы или предметной области.
Под структурным системным анализом принято понимать метод
исследования системы, который начинается с наиболее общего ее описания с
последующей детализацией представления отдельных аспектов ее поведения
16
и функционирования. При этом общая модель системы строится в виде
некоторой иерархической структуры, которая отражает различные уровни
абстракции с ограниченным числом компонентов на каждом из уровней.
Одним из главных принципов структурного системного анализа является
выделение на каждом из уровней абстракции только наиболее существенных
компонентов или элементов системы.
В рамках данного направления программной инженерии принято
рассматривать три графические нотации, получивших названия диаграмм:
диаграммы «сущность-связь» (Entity-Relationship Diagrams, ERD), диаграммы
функционального моделирования (Structured Analysis and Design Technique,
SADT) и диаграммы потоков данных (Data Flow Diagrams, DFD).
Диаграммы «сущность-связь» (ERD) предназначены для графического
представления моделей данных разрабатываемой программной системы и
предлагают некоторый набор стандартных обозначений для определения
данных и отношений между ними. С помощью этого вида диаграмм можно
описать отдельные компоненты концептуальной модели данных и
совокупность взаимосвязей между ними, имеющих важное значение для
разрабатываемой системы.
Начало разработки диаграмм функционального моделирования
относится к середине 1960-х годов, когда Дуглас Т. Росс предложил
специальную технику моделирования, получившую название SADT
(Structured Analysis & Design Technique). Военно-воздушные силы США
использовали методику SADT в качестве части своей программы интеграции
компьютерных и промышленных технологий (Integrated Computer Aided
Manufacturing, ICAM) и назвали ее IDEFO (Icam DEFinition). Целью
программы ICAM было увеличение эффективности компьютерных
технологий в сфере проектирования новых средств вооружений и ведения
боевых действий.
17
В рамках программы ICAM было разработано несколько графических
языков моделирования, которые получили следующие названия:
Нотация IDEF0 - для документирования процессов производства и
отображения информации об использовании ресурсов на каждом из этапов
проектирования систем:
- нотация IDEF1 - для документирования информации о
производственном окружении систем;
- нотация IDEF2 - для документирования поведения системы во
времени;
- нотация IDEF3 - специально для моделирования бизнес-процессов.
Модель системы в контексте DFD представляется в виде некоторой
информационной модели, основными компонентами которой являются
различные потоки данных, которые переносят информацию от одной
подсистемы к другой. Каждая из подсистем выполняет определенные
преобразования входного потока данных и передает результаты обработки
информации в виде потоков данных для других подсистем.
Основными компонентами диаграмм потоков данных являются:
- внешние сущности;
- накопители данных или хранилища;
- процессы;
- потоки данных;
- системы/подсистемы.
В настоящее время диаграммы потоков данных используются в
некоторых CASE-средствах для построения информационных моделей
систем обработки данных. Основной недостаток этой методологии также
связан с отсутствием явных средств для объектно-ориентированного
представления моделей сложных систем, а также для представления сложных
алгоритмов обработки данных.
18
Фундаментальными понятиями методологии объектно-
ориентированного анализа и проектирования ООП являются понятия класса
и объекта. При этом под классом понимают некоторую абстракцию
совокупности объектов, которые имеют общий набор свойств и обладают
одинаковым поведением. Каждый объект в этом случае рассматривается как
экземпляр соответствующего класса. Объекты, которые не имеют полностью
одинаковых свойств или не обладают одинаковым поведением, по
определению, не могут быть отнесены к одному классу.
Важной особенностью классов является возможность их организации в
виде некоторой иерархической структуры, которая по внешнему виду
напоминает схему классификации понятий формальной логики.
Основными принципами ООП являются наследование, инкапсуляция и
полиморфизм.
Принцип, в соответствии с которым знание о более общей категории
разрешается применять для более узкой категории, называется
наследованием. Инкапсуляция характеризует сокрытие отдельных деталей
внутреннего устройства классов от внешних по отношению к нему объектов
или пользователей. Под полиморфизмом (греч. Poly- много, morfos - форма)
понимают свойство некоторых объектов принимать различные внешние
формы в зависимости от обстоятельств.
Необходимость анализа предметной области до начала написания
программы была осознана при разработке масштабных проектов.
Для выделения или идентификации компонентов предметной области
было предложено несколько методов. Сам этот процесс получил название
концептуализации предметной области.
Рассмотрим язык UML, который ориентирован для применения в
качестве языка моделирования различными пользователями и научными
сообществами для решения широкого класса задач ООАП. С одной стороны,
он фактически устраняет многие из несущественных различий между
19
известными ранее языками моделирования и методиками построения
диаграмм. С другой стороны, создает предпосылки для унификации
различных моделей и этапов их разработки для широкого класса систем, не
только программного обеспечения, но и бизнес-процессов.
Специфика языка UML заключается в том, что он определяет
семантическую метамодель, а не модель конкретного интерфейса и способы
представления или реализации компонентов.
Подводя итог анализу методологии ООАП и исторических предпосылок
появления UML, можно утверждать следующее. Имеются все основания
предполагать, что в ближайшие годы язык UML в его современном виде
станет основой для разработки и реализации во многих перспективных
инструментальных средствах: в RAD-средствах визуального и
имитационного моделирования, а также в CASE-средствах самого
различного целевого назначения. Более того, заложенные в языке UML
потенциальные возможности могут быть использованы не только для
объектно-ориентированного моделирования систем, но и для представления
знаний в интеллектуальных системах, которыми, по существу, станут
перспективные сложные программно-технологические комплексы.
1.3 Схема работы управления розничной торговли ООО «Заодно»
Процесс товародвижения на данном предприятии можно разделить на
два этапа. На первом этапе товары завозятся от оптовых фирм и
поставщиков. На втором – распределяются между магазинами и продаются
покупателям (рисунок 3).
20
Рисунок 3. Схема товародвижения.
Бухгалтерский учет реализации товаров на осуществляется по мере
поступления денег в кассу от покупателей и ежемесячном пересчёте товаров
оставшихся в магазине (ревизия).
Схема товародвижения предприятия показана на рисунке 4.
-потоки товара;
Поставщики
Оптовые
фирмы
Покупатели
Магазин
Магазин
Магазин
Магазин
Магазин
Магазин
Первый этап
Второй этап
Администрация
Бухгалтерия
Завмаг
Экспедитор
Продавцы
Водитель
Оптовые фирмы
Московской
области
Поставщики
Налоговая
инспекция
Покупатели
Оптовые фирмы,
фирмы
производители
отдаленных
регионов
Склад
21
- потоки денег;
- потоки документов, информации;
- потоки бракованного товара;
- система управления;
- объект управления (технологический процесс).
Рисунок 4. Схема информационных, денежных и товарных потоков на
предприятии.
Товар в магазин доставляется тремя путями: поставщиками,
экспедиторами или заказывается руководителем предприятия у оптовых
фирм или производителей отдалённых регионов. Поставщики – это
сторонние организации, которые сами доставляют товар в магазины.
Работа с постоянными поставщиками происходит следующим образом:
1. поставщики завозят товар с определённой периодичностью,
продавцы, зная эту периодичность, подготавливают заявки на
требующиеся наименования товара к приезду поставщиков;
2. продавцы отдают заявку поставщику;
3. на основе заявки поставщик отгружает товары, и отдаёт фактуру –
регламентированный документ, на основе которого продавцы
оплачивают товар;
4. продавцы проверяют наличие товара по фактуре;
5. продавцы расплачиваются с поставщиком.
1. потенциальный поставщик подходит (либо как-нибудь связывается)
с завмагом со своим предложением, как правило, прайс-листом, и
документами, предоставляющими ему право заниматься торговой
деятельностью (свидетельство предпринимателя);
Поставщики предоставляют далеко не все необходимые товары, поэтому
в фирме имеются подразделения – товарные экспедиции. собрать заявки с
магазинов, составленные продавцами;
22
1.4 Основные функции управления розничной торговли
Исходя из анализа предметной области, можно определить основные
функции, которые реализует управление розничной торговли, и требования,
предъявляемые к АИС.
Проектируемая информационная система предназначена для работы с
данными, используемыми в розничной торговле.
Определим требования к разрабатываемой АИС.
Разрабатываемая АИС данных должна:
- отражать перечень номенклатуры товара;
- вести учет остатков товаров;
- вести учет товаров для закупок;
- давать возможность отслеживать товары с истекшим сроком
годности;
- отражать информацию о поставщиках;
- отражать информацию о сотрудниках;
- вести учет поставок товаров;
- формировать сопроводительные документы и необходимые отчеты
для получения оперативной информации.
В результате по итогам первой главы было выполнено следующее:
1. описание объекта автоматизации методом функционального
моделирования;
2. проведен анализ предметной области;
3. построена структурная схема объекта автоматизации;
4. определены основные требования к разрабатываемой системе.
23
ГЛАВА 2.ПРАКТИЧЕСКАЯ ЧАСТЬ. ПРОЕКТИРОАНИЕ
АВТОМАТИЗИРОВАННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ
2.1 Обоснование архитектуры ИС
Эффективность функционирования информационной системы (ИС) во
многом зависит от ее архитектуры. Для рассмотрения способов организации
баз данных нужно определить несколько понятий.
Ядро БД отвечает за управление данными во внешней памяти,
управление буферами оперативной памяти, управление транзакциями и
журнализацию. Соответственно, можно выделить такие компоненты ядра (по
крайней мере, логически, хотя в некоторых системах эти компоненты
выделяются явно), как менеджер данных, менеджер буферов, менеджер
транзакций. Ядро БД обладает собственным интерфейсом, не доступным
пользователям напрямую и используемым в программах, производимых
компилятором SQL и утилитах БД. Ядро БД является основной резидентной
частью СУБД. При использовании архитектуры «клиент-сервер» ядро
является основной составляющей серверной части системы.
Местоположение Ядра БД и баз данных зависит от используемой
архитектуры. Использование той или иной архитектуры накладывает
сильный отпечаток на общую идеологию работы приложения, на
программный код в приложении, на состав компонентов для работы с БД,
используемых в приложении.