
- •Реферат
- •1. Автоматизация процессов управления 10
- •2. Описание предметной области складские операции 14
- •3. Разработка программного продукта 26
- •Введение
- •1. Автоматизация процессов управления
- •1.2. Автоматизированное рабочее место пользователя
- •2. Описание предметной области складские операции
- •3. Разработка программного продукта
- •3.1. Выбор среды разработки
- •3.2. Информационная модель данных.
- •3.3. Логическая модель данных.
- •3.4. Алгоритм решения задач
- •3.5. Входные данные
- •3.6. Выходные данные
- •3.7. Интерфейс
- •3.8. Программная документация
- •3.8.1.Руководство программиста
- •3.8.2 Руководство пользователя
1.2. Автоматизированное рабочее место пользователя
Автоматизированное рабочее место (АРМ)— программно-технический комплекс, предназначенный для автоматизации деятельности определенного вида. При разработке АРМ для управления технологическим оборудованием, как правило, используют SCADA-системы.
АРМ объединяет программно-аппаратные средства, обеспечивающие взаимодействие человека с компьютером, предоставляет возможность ввода информации (через клавиатуру, компьютерную мышь, сканер и пр.) и её вывод на экран монитора, принтер, графопостроитель, звуковую карту — динамики или иные устройства вывода.
Согласно принципу системности, АРМ следует рассматривать как системы, структура которых определяется функциональным назначением. Принцип гибкости означает приспособленность системы к возможным перестройкам, благодаря модульности построения всех подсистем и стандартизации их элементов.
Принцип устойчивости заключается в том, что система АРМ должна выполнять основные функции независимо от воздействия на нее внутренних и внешних возмущающих факторов. Это значит, что неполадки в отдельных ее частях должны быть легко устраняемы, а работоспособность системы быстро восстанавливаема.
Эффективность АРМ следует рассматривать как интегральный показатель уровня реализации приведенных выше принципов, отнесенного к затратам на создание и эксплуатацию системы.
Функционирование АРМ может дать желаемый эффект при условии правильного распределения функций и нагрузки между человеком и машинными средствами обработки информации, ядром которой является компьютер.
2. Описание предметной области складские операции
Описание АИС по реализации складских операций Oracle RAC
Наиболее распространенная база данных, установленная на одном физическом сервере, называется single-instance. Я раньше не предавал особого значения разнице понятий между: экземпляр (instance) базы данных и самой базы данных (в целом). Теперь же хочу особенно отметить, что под экземпляром подразумевается ПО (процессы, потоки, сервисы) которое располагается в оперативной памяти и обрабатывает данные (сортировка, буферизация, обслуживание) полученные непосредственно с диска. Таким образом, под базой данных подразумевается совокупность:
область хранения данных, т.е. физические файлы на диске (datastorage) (сама БД)
экземпляр БД (получающая и обрабатывающая эти данные в оперативной памяти) (СУБД)
Во всех современных реляционных БД данные хранятся в таблицах. Таблицы, индексы и другие объекты в Oracle хранятся в логических контейнерах – табличных пространствах (tablespace). Физически же tablespace располагаются в одном или нескольких файлах на диске. Хранятся они следующим образом: Каждый объект БД (таблицы, индексы, сегменты отката и.т.п.) хранится в отдельном сегменте – области диска, которая может занимать пространство в одном или нескольких файлах. Сегменты в свою очередь, состоят из одного или нескольких экстентов. Экстент – это непрерывный фрагмента пространства в файле. Экстенты состоят из блоков. Блок – наименьшая единица выделения пространства в Oracle, по умолчанию равная 8K. В блоках хранятся строки данных, индексов или промежуточные результаты блокировок. Именно блоками сервер Oracle обычно выполняет чтение и запись на диск. Блоки имеют адрес, так называемый DBA (Database Block Address).
При любом обращении DML (Data Manipulation Language) к базе данных, Oracle подгружает соответствующие блоки с диска в оперативную память, а именно в буферный кэш. Хотя возможно, что они уже там присутствуют, и тогда к диску обращаться не нужно. Если запрос изменял данные (update, insert, delete), то изменения блоков происходят непосредственно в буферном кэше, и они помечаются как dirty (грязные). Но блоки не сразу сбрасываются на диск. Ведь диск – самое узкое место любой базы данных, поэтому Oracle старается как можно меньше к нему обращаться. Грязные блоки будут сброшены на диск автоматически фоновым процессом DBWn при прохождении контрольной точки (checkpoint) или при переключении журнала.
Предположим, что была запущена одна длительная транзакция, считывающая данные, и где-то в процессе ее выполнения запустилась другая транзакция с намерением изменить один из считываемых блоков. Как сервер скоординирует работу этих запросов? На самом деле, вопрос разделяется на два:
Что будет, если Oracle упадет где-то на середине длинной транзакции (если бы она вносила изменения)?
Какие же данные прочтет первая транзакция, когда в кэше у нее «под носом» другая транзакция изменила блок?
Для ответа на эти вопросы рассмотрим механизм обеспечения согласованного чтения CR (consistency read). Все дело в “волшебных” “ пузырьках” журналах транзакций, которые в Oracle представлены двумя типами:
журнал повтора (redo log)
сегмент отмены (undo)
Когда в базу данных поступает запрос на изменение, то Oracle применяет его в буферном кэше, параллельно внося информацию, достаточную для повторения этого действия, в буфер повторного изменения (redo log buffer), находящийся в оперативной памяти. Как только транзакция завершается, происходит ее подтверждение (commit), и сервер сбрасывает содержимое redo buffer log на диск в redo log в режиме append-write и фиксирует транзакцию. Такой подход гораздо менее затратен, чем запись на диск непосредственно измененного блока. При сбое сервера кэш и все изменения в нем потеряются, но файлы redo log останутся. При включении Oracle начнет с того, что заглянет в них и повторно выполнит изменения таблиц (транзакции), которые не были отражены в datafiles. Это называется «накатить» изменения из redo, roll-forward. Online redo log сбрасывается на диск (LGWR) при подтверждении транзакции, при прохождении checkpoint или каждые 3 секунды (default).С undo немного посложнее. С каждой таблицей в соседнем сегменте хранится ассоциированный с ней сегмент отмены. При запросе DML вместе с блоками таблицы обязательно подгружаются данные из сегмента отката и хранятся также в буферном кэше. Когда данные в таблице изменяются в кэше, в кэше так же происходит изменение данных undo, туда вносятся «противодействия». То есть, если в таблицу был внесен insert, то в сегмент отката вносится delete, delete – insert, update – вносится предыдущее значение строки. Блоки (и соответствующие данные undo) помечаются как грязные и переходят в redo log buffer. Да-да, в redo журнал записываются не только инструкции, какие изменения стоит внести (redo), но и какие у них противодействия (undo). Так как LGWR сбрасывает redo log buffer каждые 3 секунды, то при неудачном выполнении длительной транзакции (на пару минут), когда после минуты сервер упал, в redo будут записи не завершенные commit. Oracle, как проснется, накатит их (roll-forward), и по восстановленным (из redo log) в памяти сегментам отката данных отменит (roll-back) все незафиксированные транзакции. Справедливость восстановлена. Кратко стоит упомянуть еще одно неоспоримое преимущество undo сегмента. По второму сценарию (из схемы) когда select дойдет до чтения блока (DBA) 500, он вдруг обнаружит что этот блок в кэше уже был изменен (пометка грязный), и поэтому обратится к сегменту отката, для того чтобы получить соответствующее предыдущее состояние блока. Если такого предыдущего состояния (flashback) в кэше не присутствовало, он прочитает его с диска, и продолжит выполнение select. Таким образом, даже при длительном «select count(money) from bookkeeping» дебет с кредитом сойдется. Согласованно по чтению (CR).
Уровень доступа к данным. ASM
Хранилищем (datastorage) в больших БД почти всегда выступает SAN (Storage Area Network), который предоставляет прозрачный интерфейс серверам к дисковым массивам. Сторонние производители (Hitachi, HP, Sun, Veritas) предлагают комплексные решения по организации таких SAN на базе ряда протоколов (самым распространенным является Fibre Channel), с дополнительными функциональными возможностями: зеркалирование, распределение нагрузки, подключение дисков на лету, распределение пространства между разделами и.т.п. Позиция корпорации Oracle в вопросе построения базы данных любого масштаба сводится к тому, что Вам нужно только соответствующее ПО от Oracle (с соответствующими лицензиями), а выбранное оборудование – по возможности (если средства останутся после покупки Oracle :). Таким образом, для построения высоконагруженной БД можно обойтись без дорогостоящих SPARC серверов и фаршированных SAN, используя сервера на бесплатном Linux и дешевые RAID-массивы. На уровне доступа к данным и дискам Oracle предлагает свое решение – ASM (Automatic Storage Management). Это отдельно устанавливаемый на каждый узел кластера мини-экземпляр Oracle (INSTANCE_TYPE = ASM), предоставляющий сервисы работы с дисками. Oracle старается избегать обращений к диску, т.к. это является, пожалуй, основным bottleneck любой БД. Oracle выполняет функции кэширования данных, но ведь и файловые системы так же буферизуют запись на диск. А зачем дважды буферизировать данные? Причем, если Oracle подтвердил транзакцию и получил уведомления том, что изменения в файлы внесены, желательно, чтобы они уже находились там, а не в кэше, на случай «падения» БД. Поэтому рекомендуется использовать RAW devices (диски без файловой системы), что делает ASM. ASM работает поверх RAW device, его преимуществами являются:
отсутствие необходимости в отдельном ПО для управления разделами дисков
нет необходимости в файловой системе
Disk group — объединение нескольких дисков. При записи файлов на диски данные записываются экстентами размерами по 1 МБ, распределяя их по всем дискам в группе. Это делается для того, чтобы обеспечить высокую доступность, ведь части одной таблицы (из tablespace) разбросаны по разным физическим дискам. Способности ASM:
Зеркалирование данных: как правило, 2-х или 3-х ступенчатое, т.е. данные одновременно записываются на 2 или 3 диска. Для зеркалирования диску указываются не более 8 дисков-партнеров, на которые будут распределяться копии данных.
Автоматическая балансировка нагрузки на диски (обеспечение высокой доступности): если данные tablespace разместить на 10 дисках и, в некоторый момент времени, чтение данных из определенных дисков будет «зашкаливать», ASM сам обратится к таким же экстентам, но находящимся на зеркалированных дисках.
Автоматическая ребалансировка: При удалении диска, ASM на лету продублирует экстенты, которые он содержал, на другие оставшиеся в группе диски. При добавлении в группу диска, переместит экстенты в группе так, что на каждом диске окажется приблизительно равное число экстентов.
Описание АИС по реализации складских операций в ИСУ "Галактика"
Информационная система управления
Комплексная система автоматизации управления предприятием "Галактика" реализована в архитектуре клиент-сервер для интегрированной поддержки управленческого цикла в компаниях различных отраслей и масштабов деятельности, была выпущена на рынок в 1995 г . Первая версия системы "Галактика" вышла на платформе BTrieve, в 1997 г (15 модулей) завершены работы по созданию версий для Microsoft SQL Server и Oracle . В 1998 г . корпорация приступила к выпуску отраслевых решений на основе системы "Галактика": для предприятий связи и телекоммуникаций, металлургии, нефтегазового и лесопромышленного комплексов, торговли, пищевой промышленности, химической индустрии.
Система постоянно развивается: наращивается функциональность, на данный момент включает более 40 модулей. Ее архитектура совершенствуется в сторону большей интероперабельности и открытости, улучшается эргономика, отслеживаются изменения в законодательстве, предоставляются дополнительные средства информационного обмена с другими программными решениями.
"Галактика" изначально проектировалась как интегрированная управленческая система, поддерживающая автоматизацию задач планирования финансовой и хозяйственной деятельности, учета и контроля результатов выполнения планов, анализа итогов хозяйствования. Все элементы цикла управления материальными, финансовыми, людскими ресурсами реализованы в системе комплексно, в едином информационном пространстве, а соответствующая прикладная функциональность апробирована в условиях реальных бизнес-процессов.
С точки зрения решаемых задач систему "Галактика" можно условно разделить на несколько функциональных контуров. Каждый контур, в свою очередь, состоит из нескольких модулей. Модульность построения системы допускает как изолированное использование отдельных составляющих, так и их произвольные комбинации в зависимости от потребностей заказчика. Основными являются контуры:
Функциональные контуры системы "Галактика"
управления персоналом - предназначен для автоматизированного учета кадров и выполнения вычислительных процедур, связанных с оплатой труда персонала предприятий.
управления финансами - обеспечивает решение задач финансового менеджмента, предоставляет набор средств для управления бюджетом, ведения платежного календаря и финансового анализа.
бухгалтерского учета - функционально полная система ведения бухгалтерского учета на предприятиях любой формы собственности и видов деятельности. Единое информационное пространство системы обеспечивает автоматическое отражение в бухгалтерском контуре всех хозяйственных операций. Механизм типовых хозяйственных операций - универсальное средство для формирования проводок.
логистики - охватывает разнообразные задачи, связанные с организацией и управлением производственной и коммерческой деятельностью предприятия.
управления производством - позволяет автоматизировать техническую подготовку производства, технико-экономическое планирование на предприятиях различных отраслей промышленности, таких как машиностроение и приборостроение; легкая, пищевая, химическая, горнорудная промышленность; черная и цветная металлургия.
специализированных решений - осуществляет учет сырья, переданного для переработки сторонней организации, а также полученной от этой организации готовой продукции; кроме того, включает решение для автотранспортных предприятий, предприятий розничной торговли, организаций, где необходимо вести учет специальной и форменной одежды.
управления взаимоотношениями с клиентами - ориентирован на сотрудников отделов сбыта, технической поддержки, маркетинга, которые непосредственно взаимодействуют с клиентами, ответственны за регистрацию контактов с ними, продаж, сделок и договоров на гарантийное и абонентское обслуживание.
администрирования - набор сервисных средств для квалифицированного пользователя и программиста, обеспечивающих администрирование базы данных, корпоративный обмен данными, обмен документами с внешними информационными системами, а также проектирование пользовательского интерфейса и отчетов.
Корпорация "Галактика", создавая свои решения, придерживается следующих базовых принципов.
Принципы корпорации "Галактика"
корпоративность. Модульность и работа в информационном пространстве единой базы данных, охват всего спектра типовых производственно-экономических функций, гибкая настройка на специфику и сферу деятельности конкретного предприятия, предоставление пользователям инструментальных средств для самостоятельного развития возможностей системы, поддержка распределенных баз данных для обеспечения информационного взаимодействия подразделений и территориально удаленных филиалов корпораций, масштабируемость - все эти свойства позволяют считать систему "Галактика" корпоративной управленческой системой.
интегрированность. Это понятие включает комплексный подход к автоматизации, "сквозное" прохождение документов через различные службы предприятия. Формирование необходимой заказчику конфигурации из набора интегрированных модулей дает возможность поэтапного построения нужной функциональности и поэтапного внедрения системы, гибкого маневрирования ресурсами при проведении пусконаладочных работ.
универсальность и адаптивность. Механизм настроек обеспечивает различные схемы эксплуатации системы. Для каждого предприятия важно, чтобы его информационная система точно отражала присущие ему бизнес-процессы. Эта специфика включается в понятие отраслевой версии. Причем для системы "Галактика" понятие отраслевой версии отнюдь не означает ограничения функциональности. В любую поставку входит базовое ядро, содержащее полный комплект функций, а в процессе настройки лишь активизируются бизнес - свойства, отражающие специфику предприятий данной отрасли.
открытость. Сегодня трудно найти предприятие, где в той или иной степени не использовались бы средства автоматизации. Естественно, возникает проблема одновременной эксплуатации продуктов разных поставщиков. В системе "Галактика" открытость обеспечивается средствами утилит администрирования (инструментальный комплекс Support); для обмена данными с банками через систему электронных платежей разработан специальный модуль "Клиент-Банк"; модуль "Обмен бизнес - документами" (Экспорт/Импорт) предоставляет универсальную систему настроек для обмена хозяйственными документами с внешними системами.
многоплатформенность. Для территориально-распределенных корпораций и предприятий со сложной структурой управления важна интероперабельность системы. Система "Галактика" поддерживает наиболее распространенные серверные платформы (см. таблицу) и СУБД: Pervasive.SQL (BTrieve), Microsoft SQL Server, Oracle. При этом клиентская часть может функционировать в различных операционных средах: Windows 95/98/NT и т.д.
ориентация на реальные бизнес-процессы. При проектировании новых версий в качестве важнейшего источника информации выступают пожелания пользователей. Система автоматизированного тестирования AQA, входящая в поставку системы "Галактика", позволяет клиентам сформулировать свои предложения, создать точный "слепок" своих бизнес-процессов для последующего анализа специалистами корпорации.
Масштабируемость. Под ней принято понимать возможность использования программного продукта в вычислительных сетях различного размера: в масштабе отдельного подразделения, предприятия, корпорации. Применительно к системе "Галактика" масштабируемость достигается благодаря двум факторам. Во-первых, это широкий выбор СУБД: Pervasive.SQL (BTrieve), Microsoft SQL Server, Oracle, а в перспективе Sybase, Informix, DB2. Во-вторых, возможность выбора аппаратной платформы и сетевой операционной системы сервера (они перечислены в таблице).
Описание АИС по реализации складских операций в 1С: Предприятие
Система программ «1С:Предприятие 8» включает в себя платформу и прикладные решения, разработанные на ее основе, для автоматизации деятельности организаций и частных лиц. Сама платформа не является программным продуктом для использования конечными пользователями, которые обычно работают с одним из многих прикладных решений (конфигураций), разработанных на данной платформе. Такой подход позволяет автоматизировать различные виды деятельности, используя единую технологическую платформу.
Области применения.
Гибкость платформы позволяет применять 1С:Предприятие 8 в самых разнообразных областях:
автоматизация производственных и торговых предприятий, бюджетных и финансовых организаций, предприятий сферы обслуживания и т.д.
поддержка оперативного управления предприятием;
автоматизация организационной и хозяйственной деятельности;
ведение бухгалтерского учета с несколькими планами счетов и произвольными измерениями учета, регламентированная отчетность;
широкие возможности для управленческого учета и построения аналитической отчетности, поддержка многовалютного учета;
решение задач планирования, бюджетирования и финансового анализа;
расчет зарплаты и управление персоналом;
другие области применения.
Прикладные решения.
Фирма "1С" выпускает тиражные прикладные решения, предназначенные для автоматизации типовых задач учета и управления в коммерческих предприятиях реального сектора и бюджетных организациях. В каждом программном продукте сочетается использование стандартных решений (общих для всех или нескольких программ) и максимальный учет специфики задачи конкретной отрасли или рода деятельности предприятия.
Отраслевые и региональные прикладные решения создаются силами партнеров-разработчиков и предназначены для автоматизации отдельных направлений или областей деятельности предприятий, все они сертифицированы.
Внедрение.
Внедрения выполняются силами партнеров- внедренцев и реализуют особенности деятельности конкретного предприятия или специальные пожелания заказчика.
Внедрения и адаптации прикладных решений также могут выполняться и силами IT-специалистов заказчика, самостоятельно, или во взаимодействии с партнерами - внедренцами.
Кроме этого используются и другие программы как : БЭСТ, Галактика, Парус. У каждой из этих СУБД есть свои достоинства и недостатки, общие и индивидуальные функции, что позволяет пользователю выбрать одну из них для автоматизации профессиональной деятельности.