Автоматизированное рабочее место мастера строительно-монтажных работ структурного подразделения ОАО "Сургутнефтегаз"
Шеечная часть (шейка)
Рисунок 1.12 - Отвод
При вычислении площади отвода с прямой шейкой сначала вычисляется площадь “шейки”, затем площадь “затылка” и после чего вычисляется площадь фасонной части. Площади “затылка” и “шейки” вычисляются легко. Они представляют собой прямоугольники, вырезанные из металла и вычисляются по формуле
S = a * b,
где a и b являются смежными сторонами прямоугольника. Труднее вычисляется площадь фасонной части. Сначала вычисляется периметр одной стороны шейки затем другой стороны шейки (в случае если шейка одинакова с обеих сторон). Затем как видно на рис. 1.5.5 остается вычислить площадь сегмента, которая вычисляется по формуле
Sсегм = (рR2 /360) * a.
Общая площадь получается из суммы частей всех вычисленных площадей и представляет собой формулу:
Sотв. = Sш. + Sз. + Sф. где (1.5)
Sш. - площадь шейки;
Sз. - площадь затылка;
Sф. - площадь фасонной части.
Далее
Sш. = Sз.= a * b,
где a и b стороны прямоугольника. Особое внимание уделяется вычислению площади фасонной части как видно на рис 1.5.6 она состоит из трех частей - Sсегм, S1, S2 и вычисляется по формуле:
Sф. = (Sсегм * 2) + S1 + S2 где (1.6)
Sсегм = (рR2 /360) * a.
S1 = S2 = a * b, где
сторона a = высоте фасонной части отвода;
сторона b = половине длины шейки.
S1
Площадь сегмента a
a b
S2 b
Рисунок 1.13 - Фасонная часть
Вычисление площади перехода (1 вид центровой)
Рисунок 1.14 - Переход центровой
Площадь перехода вычисляется аналогично площади зонта трапециевидного ((a*b)/2)*h) и представляет собой сумму площадей всех сторон (трапеций).
Sпер. = S1 + S2 + S3 + S4 (1.7)
Вычисление площади перехода (2 вида одностороннего)
Рисунок 1.15 - Переход односторонний
Вычисление площади перехода этого вида производится следующим образом:
· Вычисляются площади двух сторон (трапециевидных) - ((a*b)/2)*h;
· затем площади оставшихся двух сторон - a * b
· После чего все стороны складываются - Sпер. = S1 + S2 + S3 + S4
Вычисление площади детали “утка”.
Лицевая часть S1
S2 Sпрям
Фасонная часть Лицевая часть
Рисунок 1.16 - Утка
Площадь детали “утка” вычисляется следующим образом - Площадь лицевой части умножается на два и прибавляется площадь фасонной части тоже умноженной на два
Sутка = (Sл * 2) + (Sф * 2) (1.8)
Sл = a * b и представляет собой прямоугольник;
Sф = (S1 * 2) + (S2 * 2) + (Sпрям * 2)
Все выше перечисленные формулы будут включены в автоматизируемые функции вычисления и войдут в БД информационной системы.
1.6 Анализ существующих программных продуктов для автоматизации предметной области
Для анализа существующих программных продуктов автором проекта были выбраны существующие на сегодняшний день системы управления базами данных (СУБД).
На сегодняшний день известно более двух десятков форматов данных настольных СУБД, однако наиболее популярными, исходя из числа проданных копий, следует признать dBase, Paradox, FoxPro и Access. Из появившихся недавно СУБД следует также отметить Microsoft Data Engine -- по существу серверную СУБД, представляющую собой «облегченную» версию Microsoft SQL Server, но предназначенную, тем не менее, для использования главным образом в настольных системах и небольших рабочих группах.
Сведения о производителях перечисленных выше СУБД представлены в таблице 1.4.
Таблица 1.4. - Производители СУБД
СУБД
|
Производитель
|
URL
|
|
Visual dBase
|
dBase, Inc
|
http://www.dbase2000.com
|
|
Paradox
|
Corel
|
http://www.corel.com
|
|
Microsoft Access 2000
|
Microsoft
|
http://www.microsoft.com
|
|
Microsoft FoxPro
|
Microsoft
|
http://www.microsoft.com
|
|
Microsoft Visual FoxPro
|
Microsoft
|
http://www.microsoft.com
|
|
Microsoft Visual FoxPro
|
Microsoft
|
http://www.microsoft.com
|
|
Microsoft Data Engine
|
Microsoft
|
http://www.microsoft.com
|
|
|
Далее мы рассмотрим каждую из этих СУБД в отдельности. Начнем с dBase -- СУБД, бывшей некогда необычайно популярной и сегодня по-прежнему не забытой, несмотря на то, что за время своего существования она сменила несколько хозяев и в настоящее время судьба ее до конца не определена.
dBase и Visual dBase
Хранение данных в dBase основано на принципе «одна таблица -- один файл» (эти файлы обычно имеют расширение *.dbf). MEMO-поля и BLOB-поля (доступные в поздних версиях dBase) хранятся в отдельных файлах (обычно с расширением *.dbt). Индексы для таблиц также хранятся в отдельных файлах. При этом в ранних версиях этой СУБД требовалась специальная операция реиндексирования для приведения индексов в соответствие с текущим состоянием таблицы.
Формат данных dBase является открытым. В роли интерпретатора команд xBase выступает обычно либо среда разработки приложения на этом языке, либо среда времени выполнения. Отметим, что для скрытия исходного текста xBase-приложения подобные СУБД обычно содержат утилиты для псевдокомпиляции кода, который затем поставляется вместе со средой времени выполнения.
Отметим, однако, что для работы с данными формата dBase (или иных dBase-подобных СУБД) совершенно необязательно пользоваться диалектами xBase. Доступ к этим данным возможен с помощью ODBC API (и соответствующих драйверов) и некоторых других механизмов доступа к данным (например, Borland Database Engine, некоторых библиотек других производителей типа СodeBase фирмы Sequenter), и это позволяет создавать приложения, использующие формат данных dBase, практически с помощью любого средства разработки, поддерживающего один из этих механизмов доступа к данным.
После покупки dBase компанией Borland этот продукт, получивший впоследствии название Visual dBase, приобрел набор дополнительных возможностей, характерных для средств разработки этой компании и для имевшейся у нее другой настольной СУБД -- Paradox. Среди этих возможностей были специальные типы полей для графических данных, поддерживаемые индексы, хранение правил ссылочной целостности внутри самой базы данных, а также возможность манипулировать данными других форматов, в частности серверных СУБД, за счет использования BDE API и SQL Links.
В настоящее время Visual dBase принадлежит компании dBase, Inc. Его последняя версия -- Visual dBase 7.5 имеет следующие возможности:
Средства манипуляции данными dBase и FoxPro всех версий.
Средства создания форм, отчетов и приложений.
Средства публикации данных в Internet и создания Web-клиентов.
Ядро доступа к данным Advantage Database Server фирмы Extended Systems и ODBC-драйвер для доступа к данным этой СУБД.
Средства публикации отчетов в Web.
Средства визуального построения запросов.
Средства генерации исполняемых файлов и дистрибутивов.
В настоящее время к Visual dBase в качестве дополнения может быть приобретен компонент dConnections, позволяющий осуществить доступ к данным Oracle, Sybase, Informix, MS SQL Server, DB2, InterBase из Visual dBase 7.5 и приложений, созданных с его помощью.
Paradox
Paradox был разработан компанией Ansa Software, и первая его версия увидела свет в 1985 году. Этот продукт был впоследствии приобретен компанией Borland. С июля 1996 года он принадлежит компании Corel и является составной частью Corel Office Professional.
Принцип хранения данных в Paradox сходен с принципами хранения данных в dBase -- каждая таблица хранится в своем файле (расширение *.db), MEMO- и BLOB-поля хранятся в отдельном файле (расширение *.md), как и индексы (расширение *.px).
Однако, в отличие от dBase, формат данных Paradox не является открытым, поэтому для доступа к данным этого формата требуются специальные библиотеки. Например, в приложениях, написанных на C или Pascal, использовалась некогда популярная библиотека Paradox Engine, ставшая основой Borland Database Engine. Эта библиотека используется ныне в приложениях, созданных с помощью средств разработки Borland (Delphi, C++Builder), в некоторых генераторах отчетов (например, Crystal Reports) и в самом Paradox. Существуют и ODBC-драйверы к базам данных, созданным различными версиями этой СУБД.
Отметим, однако, что отсутствие «открытости» формата данных имеет и свои достоинства. Так как в этой ситуации доступ к данным осуществляется только с помощью «знающих» этот формат библиотек, простое редактирование подобных данных по сравнению с данными открытых форматов типа dBase существенно затруднено. В этом случае возможны такие недоступные при использовании «открытых» форматов данных сервисы, как защита таблиц и отдельных полей паролем, хранение некоторых правил ссылочной целостности в самих таблицах -- все эти сервисы предоставляются Paradox, начиная с первых версий этой СУБД.
По сравнению с аналогичными версиями dBase ранние версии Paradox обычно предоставляли разработчикам баз данных существенно более расширенные возможности, такие как использование деловой графики в DOS-приложениях, обновление данных в приложениях при многопользовательской работе, визуальные средства построения запросов, на основе интерфейса QBE -- Query by Example (запрос по образцу), средства статистического анализа данных, а также средства визуального построения интерфейсов пользовательских приложений с автоматической генерацией кода на языке программирования PAL (Paradox Application Language).
Windows-версии СУБД Paradox, помимо перечисленных выше сервисов, позволяли также манипулировать данными других форматов, в частности dBase и данными, хранящимися в серверных СУБД. Такую возможность пользователи Paradox получили благодаря использованию библиотеки Borland Database Engine и драйверов SQL Links. Это позволило использовать Paradox в качестве универсального средства управления различными базами данных (существенно облегченная версия Paradox 7 под названием Database Desktop по-прежнему входит в состав Borland Delphi и Borland C++Builder именно с этой целью). Что же касается базового формата данных, используемого в этом продукте, то он обладает теми же недостатками, что и все форматы данных настольных СУБД, и поэтому при возможности его стараются заменить на серверную СУБД, даже сохранив сам Paradox как средство разработки приложений и манипуляции данными.
Текущая версия данной СУБД -- Paradox 9, поставляется в двух вариантах -- Paradox 9 Standalone Edition и Paradox 9 Developer's Edition. Первый из них предназначен для использования в качестве настольной СУБД и входит в Corel Office Professional, второй -- в качестве как настольной СУБД, так и средства разработки приложений и манипуляции данными в серверных СУБД. Обе версии содержат:
Средства манипуляции данными Paradox и dBase.
Средства создания форм, отчетов и приложений.
Средства визуального построения запросов.
Средства публикации данных и отчетов в Internet и создания Web-клиентов.
Corel Web-сервер.
ODBC-драйвер для доступа к данным формата Paradox из Windows-приложений.
Средства для доступа к данным формата Paradox из Java-приложений.
Помимо этого Paradox 9 Developer's Edition содержит:
Run-time-версию Paradox для поставки вместе с приложениями.
Средства создания дистрибутивов.
Драйверы SQL Links для доступа к данным серверных СУБД.
Отметим, однако, что популярность этого продукта как средства разработки в последнее время несколько снизилась, хотя в мире эксплуатируется еще немало информационных систем, созданных с его помощью.
Microsoft FoxPro и Visual FoxPro
FoxPro ведет свое происхождение от настольной СУБД FoxBase фирмы Fox Software. Разрабатывая FoxBase в конце 80-х годов, эта компания преследовала цель создать СУБД, функционально совместимую с dBase с точки зрения организации файлов и языка программирования, но существенно превышающую ее по производительности. Одним из способов повышения производительности являлась более эффективная организация индексных файлов, нежели в dBase, -- по формату индексных файлов эти две СУБД несовместимы между собой.
По сравнению с аналогичными версиями dBase, FoxBase и более поздняя версия этого продукта, получившая название FoxPro, предоставляли своим пользователям несколько более широкие возможности, такие как использование деловой графики, генерация кода приложений, автоматическая генерация документации к приложениям и т.д.
Visual Fox Pro 6.0 предоставляет следующие возможности:
Средства публикации данных в Internet и создания Web-клиентов;
Средства создания ASP-компонентов и Web-приложений;
Средства создания COM-объектов и объектов для Microsoft Transaction Server, позволяющих создавать масштабируемые многозвенные приложения для обработки данных;
Средства доступа к данным серверных СУБД, базирующиеся на использовании OLE DB (набор COM-интерфейсов, позволяющий осуществить унифицированный доступ к данным из разнообразных источников, в том числе из нереляционных баз данных и иных источников, например Microsoft Exchange);
Средства доступа к данным Microsoft SQL Server и Oracle, включая возможность создания и редактирования таблиц, триггеров, хранимых процедур;
Средства отладки хранимых процедур Microsoft SQL Server;
Средство визуального моделирования компонентов и объектов, являющиеся составными частями приложения -- Visual Modeller;
Средство для управления компонентами приложений, позволяющее осуществлять их повторное использование.
Итак, тенденции развития этого продукта очевидны: из настольной СУБД Visual FoxPro постепенно превращается в средство разработки приложений в архитектуре «клиент/сервер» и распределенных приложений в архитектуре Windows DNA. Впрочем, эти тенденции в определенной степени характерны для всех наиболее популярных настольных СУБД -- мы уже убедились, что и dBase, и Paradox также позволяют осуществлять доступ к наиболее популярным серверным СУБД.
Достоинства и недостатки существующих СУБД
Достоинства: код, контролирующий стандартную ссылочную целостность, содержится в библиотеках, используемых всеми приложениями, работающими с этой базой данных, а сама база данных при этом может содержать описание правил ссылочной целостности.
Недостатки: проблема СУБД заключается в возможности нарушения ссылочной целостности данных, так как единственным механизмом, контролирующим ее, является пользовательское приложение.
1.7 Обоснование проектных решений по видам обеспечения
1.7.1 Обоснование проектных решений по информационному обеспечению (ИО)
Информационное обеспечение - это совокупность средств и методов построения информационной базы.
· Информационное обеспечение должно удовлетворять пользователя по своей упорядоченности, точности, достоверности и своевременности представления информации для решения поставленных задач, а также однозначности и удобства ее восприятия всеми потребителями;
· Свойство объектов системы должны иметь возможность оформляться в виде сложной структуры, ссылающейся на другие объекты и хранящей историческую последовательность значений;
· Структура данных Системы должна обеспечивать расширяемость по номенклатуре и свойствам новых объектов;
· Система должна обеспечивать поддержку иерархической структуры типов объектов, реализующей механизм наследования свойств объектов.
· Совокупность информационных массивов Системы должна быть организована в виде БД на машинных носителях;
· Система должна иметь механизм регистрации событий, который связывает изменение свойств объектов, вызванное каким-либо внешним событием, с последующей реакцией системы на это событие;
· Форма представления выходной информации должна согласовываться с заказчиком (пользователем) системы. При разработке форм выходных документов в выходных документах АИС должны применяться термины и сокращения общепринятые в данной предметной области и согласованные с заказчиком системы;
· Структура процесса сбора, обработки и передачи данных в ИС должна соответствовать процессам, которые выполняются на рабочем месте мастера строительно-монтажных работ.
Внутримашинная информационная база представляет собой физически реализованную базу данных. Носителем данных является жесткий диск, на котором находится СУБД. Доступ к данным осуществляется посредством SQL-запросов к СУБД. Основные принципы построения внутримашинной информационной базы:
· информационный массив накапливается и хранится в реляционной базе данных;
· проектирование таблиц осуществляется с принципами построения и организации реляционных баз данных;
· уменьшение избыточности данных не должно приводить к усложнению доступа и уменьшению скорости обработки информации.
Во внутримашинной информационной базе осуществляется контроль целостности данных с помощью бизнес-правил, то есть процедур, применяемых к элементам БД в качестве ограничения целостности. На этапе ввода происходит сопоставление типов вносимых данных с типом поля БД, а также проверка на допустимые значения. Хорошо спроектированная база данных:
· удовлетворяет всем требованиям пользователей к ее содержимому. Перед проектированием базы необходимо провести исследования требований пользователей к ее функционированию;
· гарантирует непротиворечивость и целостность данных. При проектировании таблиц нужно определить их атрибуты и некоторые правила, ограничивающие возможность ввода пользователем неверных значений. Для верификации данных перед непосредственной записью их в таблицу база данных должна осуществлять вызов правил модели данных и тем самым гарантировать сохранение целостности информации;
· обеспечивает естественное, легкое для восприятия структурирование информации. Качественное построение базы позволяет делать запросы к ней более “прозрачными” и легкими для понимания; следовательно, снижается вероятность внесения некорректных данных и улучшается качество сопровождения базы;
· удовлетворяет требованиям пользователей к ее производительности. При больших объемах информации вопросы сохранения производительности начинают играть главную роль, сразу “высвечивая” все недочеты этапа проектирования.
1.7.2 Обоснование проектных решений по технологическому обеспечению
Технологический процесс - последовательность технологических операций, необходимых для выполнения определённого вида работ. Технологический процесс состоит из рабочих операций, которые в свою очередь складываются из рабочих движений.
Под операцией технологического процесса следует понимать комплекс действий, выполняемых над информацией и её носителем на одном рабочем месте.
Технологический процесс включает: сбор и регистрацию исходных данных, передачу их на обработку, хранение, подготовку данных к обработке, ввод данных в ЭВМ, обработку информации по заданным алгоритмам, выдачу результирующей информации и передачу её пользователям.
1.7.3 Обоснование проектных решений по программному обеспечению (ПО)
Требования к использованию типовых и поставляемых программных средств:
ПО сервера: операционная система (ОС): ОС- MS Windows 2003 Server, СУБД: MS SQL Server.
ПО мастера СМР: может быть использованы операционная система (ОС): MS Windows XP Professional (желательно Rus), компоненты Borland Delphi, пакет MS Office ХР/2003, в виду их распространённости.
Конкретные версии компонентов ПО должны определяться на этапе ввода в действие. ПО является покупным и должно быть лицензионным.
Общие требования к программному обеспечению:
1) программное обеспечение системы должно быть достаточным для выполнения всех функций системы, реализуемых с применением средств вычислительной техники, а также иметь средства организации всех требуемых процессов обработки данных, позволяющие своевременно выполнять все автоматизированные функции во всех регламентированных режимах функционирования ИС;
2) программное обеспечение системы должно обладать следующими свойствами:
· функциональная достаточность (полнота);
· надежность (в том числе восстанавливаемость, наличие средств выявления ошибок);
· адаптируемость;
· модифицируемость;
· модульность построения;
· удобство эксплуатации.
3) программное обеспечение системы должно быть построено таким образом, чтобы отсутствие отдельных данных не сказывалось на выполнении функций системы, при реализации которых эти данные не используются;
4) в программном обеспечении системы должны быть реализованы меры по защите от ошибок при вводе и обработке информации, обеспечивающие заданное качество выполнения функций системы;
5) все компоненты программного обеспечения системы должны быть совместимы как между собой, так и с системным программным обеспечением;
6) эксплуатационная программная документация на систему должна содержать сведения, необходимые персоналу системы для использования программного обеспечения, для его первоначальной установки, запуска программ системы.
Программное приложение должно быть реализовано c помощью пакета MS Office.
Система управления БД - MS Access
SQL (Structured Query Language) - это сокращенное название структурированного языка запросов, предоставляющего средства создания и обработки данных в реляционных БД. Независимость от специфики компьютерных технологий, а также поддержка SQL лидерами промышленности в области технологии реляционных баз данных сделали его основным стандартным языком БД.
Реализация в SQL концепции операций, ориентированных на табличное представление данных, позволила создать компактный язык с небольшим набором предложений. SQL может использоваться как для выполнения запросов, так и для построения прикладных программ. В нем существуют:
· предложения определения данных - определение БД, а также определение и уничтожение таблиц и индексов;
· запросы на выбор данных - предложение SELECT;
· предложения модификации данных - добавление, удаление и изменение данных;
· предложения управления данными - предоставление и отмена привилегий на доступ к данным, управление транзакциями и другие.
Особенно важно, что Delphi 7 поддерживает базы данных SQL Server. Система управления БД SQL Server является одной из мощнейших многопользовательских БД, обеспечивающих быстрый доступ к данным и их надежное хранение. Она имеет ряд существенных преимуществ перед другими БД:
· поддерживает БД сколь угодно большого размера до сотни тысяч мегабайт;
· обеспечивает высокий уровень производительности системы;
· минимизирует соперничество за данные и гарантирует их согласованность;
· для компьютеров, соединенных в сети, объединяет данные физически расположенные на различных компьютерах, в одну логическую БД, обеспечивая к ней доступ всех пользователей сети;
· поддерживает очень большое число одновременно работающих пользователей, которые выполняют различные приложения БД и обрабатывают одни и те же данные;
· имеет режимы спасения и восстановления информации, позволяющие защищать БД от программных и аппаратных сбоев.
1.7.4 Выбор технического обеспечения (ТО)
Так как разработка АРМ не предусматривает капитальной реорганизации существующей технологии, парк технических средств остаётся без изменения. То есть, в системе должны в основном использоваться технические средства (ТС) серийного производства типа IBM-совместимых персональных компьютеров с серийным периферийным оборудованием и серверы баз данных с процессором не ниже Pentium IV.
Сервер баз данных должен обеспечивать хранение данных и доступ рабочих станций к базе данных общего пользования.
Аппаратная платформа сервера:
· процессор типа Pentium IV 1ГГц - 2,8 ГГц (не ниже);
· объем ОЗУ 512 Мб - 1Гб;
· память на жестком диске SCSI - 20 Гб минимум;
· ИГП, обеспечивающий работу сервера в течении не менее 30 минут при полностью заряженных батареях ИГП;
· монитор SVGA;
· сетевая карта 100 Мбит;
· клавиатура;
· манипулятор типа «мышь».
Аппаратная платформа компьютера мастера СМР состоит из:
· процессора типа Pentium IV 1ГГц
· объем ОЗУ 256 MB;
· HDD 40 Гб;
· монитор с диагональю 17”-19” с разрешением 1024*768 точек при цветовой палитре 65 536 цветов и удовлетворяющий нормам безопасности ТСО 92 и ТСО 95;
· видео карта типа SVGA 4-8 Мб VRAM;
· сетевая карта 100 Мбит;
· клавиатура;
· манипулятор типа «мышь»;
· устройство печати.
Конфигурация локальных вычислительных сетей (ЛВС) должна удовлетворять требованиям, предъявляемым к ЛВС, имеющим шинную конфигурацию типа Ethernet. Система должна строиться на базе унифицированных технических средств.
Комплекс ТС должен быть достаточным для выполнения всех автоматизированных функций системы. Функциональные и эксплуатационные характеристики ТС содержатся в технической и эксплуатационной документации к комплексу технических средств.
Технические средства системы должны быть размещены с соблюдением требований, содержащихся в технической, в том числе эксплуатационной документации на них, и так, чтобы было удобно использовать их при функционировании системы и выполнять техническое обслуживание.
Защита технических средств системы от воздействия внешних электрических и магнитных полей, а также помех по цепям питания должна быть достаточной для эффективного выполнения техническими средствами своего назначения при функционировании системы.
2. Проектная часть
2.1 Техническое задание
Оформление технического задания осуществлялось на основании ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы; введ. 01.01.1990.
2.1.1 Полное наименование системы и ее условное обозначение
Управление, изготовление заказов (ИС “УИЗ”).
2.1.2 Наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты
Заказчик: Специализированное управление треста “Сургутремстрой” ОАО “Сургутнефтегаз”. Начальник производственной базы - Огородов Сергей Викторович ул. Аэрофлотская д. 2 каб 110 тел. 40-12-81
Разработчик: Чернобровкин Виталий Викторович студент 6-го курса МосАП, г Сургут ул. Маяковского д. 47 кв. 39 тел. 89222590472.
Информационная система разрабатывается согласно ГОСТ 34-602-89 ИТ.
2.1.3 Плановые сроки начала и окончания работы по созданию системы
· Срок начало работы по созданию ИС: 26 06 09.
· Окончание работы 15 02 10.
· порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке: 1) демонстрация ИС в приложении PowerPoint написанной с помощью Case - средства BPwin. 2) Демонстрация работы Базы Данных написанной в приложении Access.
2.1.4 Порядок оформления и предъявления заказчику результатов работ по созданию системы
1) Заказчику передается: технический проект, загрузочный модуль, инструкции пользователя
2) Порядок передачи указанных материалов заказчику:
· технический проект: CD, 2 экземпляра, pdf - файл;
· рабочий проект: CD, 2 экземпляра, pdf - файл;
· загрузочный модуль: на CD, 2 экземпляра, exe - файл;
· инструкции пользователя: на CD, 2 экземпляра, pdf - файл.
2.1.5 Назначение системы
Автоматизация приложения СУБД. Управление материальными потоками. Автоматизированная выборка данных. Расчет выработанного материала. Учет изготовленных деталей в м2. Учет остатков материала в м2. Упрощение переработки информации при использовании СУБД. Так как, обработка бумажной документации в ручную долговременный и затратный труд.
2.1.6 Цель создания
Отражение материального потока производственного процесса, вычисление площади различных заготовок, учет остатка материала после изготовления деталей и рациональное использование оставшегося материала (экономия материала в производственном процессе).
2.1.7 Характеристика объекта автоматизации
Организационная структура:
1) Начальник производственной базы;
2) Мастер СМР;
3) Бригадир по изготовлению СВ И КВ;
4) Рабочие изготовители;
Номенклатура видов предоставляемых услуг: 1 (администрирование БД); Количество отчётов в месяц: 20; Количество запросов информации: 50; Количество функций системы: 6.
1) Учет ТМЦ;
2) Вычисление площади заготовок;
3) Учет бракованных изделий;
4) Учет расписания тех. специалистов;
5) Учет объема дневной выработки;
6) Учет объема месячной выработки.
Количество исполнителей: 1.
2.2 Требования к Информационной системе
2.2.1 Требования к системе в целом
1. Данная ИС должна иметь четкую, последовательную, легковоспринимаемую организованную структуру. Базу данных. Слаженно и бесперебойно функционировать: Открывать формы, запросы составлять отчеты.
2. Система должна эксплуатироваться как одним, так и несколькими пользователями.
3. Система должна выдавать отчеты согласно утвержденным ГОСТам, а также выполнять функции согласно написанных для них требований.
4. При эксплуатации система должна иметь удобный и понятный интерфейс. Каждая кнопка должна соответствовать своему назначению.
5. Если в системе имеется особая или секретная информация, то она должна иметь код доступа (пароль).
6. Режим функционирования - диалоговый (интерактивный).
2.2.2 Требования к численности и квалификации персонала
· ИС должна быть однопользовательской. Хотя состав пользователей может быть неограниченным, т.е. мастера
· Квалификация пользователей должна быть на уровне “уверенного пользователя”. Т.е. пользователь должен хорошо разбираться и работать в приложении Access из пакета Microsoft Office ОС Windows XP Professional.
2.2.3 Показатели назначения
· Жизненный цикл системы: 3 года.
· Степень приспособляемости системы к изменению процессов: открытая система.
· Допустимый предел модернизации: 40%
2.2.4 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
· Режим эксплуатации ТС: односменный (8 часов).
· Виды и периодичность обслуживания ТС системы: по мере возникновения неполадок.
· Форма обслуживания: специалистами объекта автоматизации
2.2.5 Требования к защите информации
Конфиденциальная информация и доступ к базе данных должен с держать пароль.
2.2.6 Требования к сохранности информации при аварийных ситуациях
АРМ должен гарантированно функционировать 8 часов в сутки, 5 дней в неделю. При аварийных ситуациях предусмотрены действия:
Ситуация
|
Действия
|
|
Отключение питания
|
Использование источника бесперебойного питания
|
|
Заражение ПК вирусом
|
Использование антивирусных программ
|
|
Сбой ОС
|
Создание резервных копии системы
|
|
|
2.2.7 Требования по сохранности информации при авариях
Резервное копирование данных на внешних носителях.
2.2.8 Требования к функциям (задачам), выполняемым системой
Структура системы:
1) подсистема «Заготовка»; назначение: вычисление площади; функции:
· ввод данных об изделии;
· обновление информации по каждой заготовке;
· выборка информации по каждому изделию;
· ввод информации по объектам монтажа;
· обновление информации по объектам монтажа;
· выборка информации по партиям;
· ввод данных по ТМЦ;
· обновление информации по ТМЦ.
2.3 Требования к видам обеспечения
2.3.1 Математическое обеспечение
· Состав формул и функций семантически прост и легок в понимании;
· Построение формул для вычисления согласно ГОСТам применяемых в образовании;
· Используется метод прямого счета.
2.3.2 Лингвистическое обеспечение
Требования к языкам разработки ИС зависят от метода проектирования:
· Представляет собой языки программирования на, которых пишется ИС, т.е. SQL,VBA - языки, применяемые в разработке БД в приложении Access.
Требования к языкам ввода - вывода:
· Ввод-вывод данных осуществляется с использованием типовых инструментов (радиокнопок, флажков, полей редактирования, меток, текстовых кнопок и т.д.).
Требования к языкам манипулирования данными:
· Используется язык SQL, Формирование кода запроса осуществляется программой и пользователем, который с использованием визуальных компонентов (радиокнопки, выпадающий список и т.д.) задает ключевые параметры запроса.
2.3.3 Информационное обеспечение
Требования к составу, структуре и способам организации данных в системе:
1) Характеристики внутреннего ИО:
Состав данных в системе: БД со следующими таблицами: партия, вставка, решетка, результат, персонал, переход, рейка, отвод, лента-крепеж, короб, изготовление, объект.
Структура данных: реляционная.
Способ организации данных: локальный
2) Характеристики внешнего ИО:
Номенклатура документов: заказы на изготовление, чертеж - подмерка, отчеты по выполненным заказам, отчеты использованным ТМЦ, отчеты по объектам.
Порядок хранения документов:
· место хранения: РМ пользователем мастера СМР;
· форма хранения: однотипные документы группируются в Дела.
правила выдачи документов:
· выдача подлинников документов разрешается только сотрудникам организации;
· выдача документов осуществляется с оформлением листа-заместителя, в котором указывается: наименование документа; дата выдачи; ФИО - сотрудника, взявшего документ; дата возврата документа; роспись сотрудника, взявшего документ.
Требования к информационному обмену между компонентами системы:
Автоматизированное рабочее место является однопользовательской системой, поэтому информационный обмен между компонентами осуществляется через оперативную память.
Страницы: 1, 2, 3, 4
|