Разработка информационной системы на предприятии

Размещено на http://www.allbest.ru/

Содержание

Введение

1. Анализ предметной области

2. Техническое задание

2.1 Основание для разработки

2.2 Назначение разработки

2.3 Требования к программе

2.3.1 Требования к системе в целом

2.3.2 Требования к функциональным характеристикам

2.3.3 Требования к надежности

2.3.4 Требования к составу и параметрам технических средств

2.3.5 Требования к информационной и программной совместимости

2.4 Требования к программной документации

2.5 Стадии и этапы разработки

2.6 Порядок контроля и приемки

3. Разработка модели информационной системы

3.1 Функциональное проектирование информационной системы

3.1.1 Описание средства проектирования системы AllFusion Process Modeler 7

3.1.2 Разработка функциональной модели информационной системы

3.2 Объектно-ориентированное проектирование информационной системы

3.2.1 Описание средства проектирования системы Rational Rose

3.2.2 Построение диаграммы вариантов использования

3.2.3 Построение диаграммы взаимодействия объектов

3.2.4 Построение диаграммы классов

4. Разработка базы данных

4.1 Описание средства проектирования AllFusion Data Modeller 7

4.2 Логическое проектирование базы данных

4.3 Нормализация базы данных

4.4 Физическое проектирование базы данных

5. Анализ целесообразности использования заданных средств разработки

Заключение

Список использованных источников

Перечень принятых сокращений

Приложения



Введение

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

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

Основной недостаток индивидуальной разработки - более высокая стоимость системы и более длительное внедрение, чем в случае использования типовых программных продуктов. Поэтому при принятии решения на внедрение информационной системы необходимо решить, что Вы хотите получить? В результате исследования предприятия специалисты отдела определят, какие процессы и функции подлежат автоматизации, возможно ли для этого использовать типовые программные продукты, какова должна быть степень их доработки, или же целесообразнее разрабатывать систему "с нуля"/1/.

ООО «ПО «Энергоспецтехника» - один из крупнейших российских производителей электротехнической продукции и мобильной техники. Имеющаяся на предприятии собственная проектно-конструкторская база позволяет постоянно совершенствовать выпускаемую продукцию.

Главная цель предприятия - выпуск качественного изделия. Разработанная техническая документация должна включать всю необходимую информацию об изделии. Наиболее важными параметрами считаются трудоёмкость и стоимость изделия. Именно поэтому для ООО «ПО «Энергоспецтехника» весьма важным является процесс расчёта трудоёмкости и стоимости изготовления электрических аппаратов и приборов. Чтобы автоматизировать данный процесс, необходимо создать информационную систему, которая будет соответствовать всем требованиям предприятия.

Не следует ожидать, что разработчик сам полностью определит, как должны быть организованы на предприятии документооборот, финансовые потоки, система управления, и т.д. Конечно, исходя из своего опыта, разработчик может дать некоторые рекомендации, но лучше предоставить решение этих вопросов специалистам по управленческому консалтингу, по аудиту и т.д. или выделить наиболее опытных специалистов, хорошо разбирающихся в протекающих на предприятии бизнес процессах и способных сформировать необходимые требования. В любом случае работа по подготовке ТЗ проводится разработчиком в тесном сотрудничестве со специалистами заказчика.

В связи с этим было решено разработать информационную систему для расчета трудоёмкости и стоимости изготовления электрических аппаратов и приборов ООО «ПО «Энергоспецтехника» в соответствии с требованиями специалистов-расчётчиков.



1. Анализ предметной области

ООО «ПО «Энергоспецтехника» создано на базе механических мастерских ЗАО «Пензенская горэлектросеть», одного из старейших предприятий коммунальной энергетики России, которое уже более 60 лет является производителем передвижной спецтехники и другого электротехнического оборудования, предназначенных для эксплуатации на теплосетевых и электросетевых предприятиях.

ООО «ПО «Энергоспецтехника» являет собой пример успешной, стабильной и надежной компании.

Цели предприятия:

- производство качественного, удобного и надежного в эксплуатации оборудования;

- соблюдение принципов бизнес-этики;

- наилучшее удовлетворение потребностей клиентов и формирование лояльных взаимовыгодных отношений с ними;

- непрерывное развитие и совершенствование бизнеса;

- создание благоприятных условий труда для сотрудников компании;

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

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

Немаловажным является то, что осуществляется поставка продукции в любую точку России, а также в страны ближнего зарубежья, предоставляются гарантийное и послегарантийное обслуживание клиентам /2/.

Основной задачей для предприятия является выпуск качественного изделия. Разработанная техническая документация должна содержать полную информацию об изделиях. Наиболее важными параметрами считаются трудоёмкость и стоимость изготовления изделия.

Расчёт трудоёмкости и стоимости изделия необходимо начать с формирования подетального состава изделия. Далее нужно будет составить список операция-деталь, по которому мы будем рассчитывать норму времени и расценку. Затем по формулам рассчитать трудоёмкости и стоимости. И в итоге формируется отчёт, включающий в себя всю необходимую информацию.

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

Трудоемкость - это затраты рабочего времени на единицу или весь объем изготовленной продукции предприятия.

Трудоемкость единицы продукции предприятия рассчитывается отношением фонда рабочего времени на изготовление i-го вида продукции к объему его производства в натуральном или условно-натуральном измерении.

В состав трудоемкости производства продукции включаются все нормируемые затраты труда (рабочего времени) на ее производство в конкретных условиях действующего предприятия. Нормируемые затраты труда измеряются в нормо-часах, человеко-часах или других единицах трудовых затрат в расчете на одно изделие или годовой объем производства.

Норма времени - время, установленное на изготовление единицы продукции или выполнение определённого объёма работы одним или группой рабочих соответствующей квалификации в определённых организационно-технических условиях. Норму времени исчисляются в человеко-часах или человеко-минутах. Если работа выполняется одним рабочим, норма времени устанавливается в часах и минутах, и её величина соответствует продолжительности выполнения работы или времени изготовления одного изделия. Технически обоснованную норму времени определяет время, необходимое для выполнения работы в данных организационно-технических условиях при наиболее полном использовании рабочего времени и оборудования.

Норма времени по i-й операции j-й детали на одно изделие определяется выражением:

где - норма времени по i-ой операции j-ой детали (берется из справочника "Операции");

- полная применяемость (количество) j-ой детали в изделии (берется из подетального состава изделия).

В зависимости от содержания затрат труда на производство продукции на предприятиях различают пять видов трудоемкости: технологическую, обслуживания, управления, производственную и полную.

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

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

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

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

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

Все перечисленные выше виды трудоемкости широко используются в процессе планирования, проектирования, производства, реализации и эксплуатации выпускаемой продукции производства.

Наибольшее распространение имеет на предприятиях технологическая трудоемкость.

Трудоемкость изготовления изделия определяется суммированием норм времени по всем деталям и операциям:

где I - число операций j-ой детали;

J - число деталей в изделии.

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

Расценка по i-ой операции j-ой детали на изделие равна:

где - расценка по i-ой операции j-ой детали (берется из справочника "Операции");

- полная применяемость (количество) j-ой детали в изделии (берется из подетального состава изделия).

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

Стоимость изготовления изделия равна:

где - расценка по i-ой операции j-ой детали./3/

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

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



2. Техническое задание

2.1 Основание для разработки

Разработка ведётся в соответствии с заданием на преддипломную практику, выданное руководителем от кафедры.

2.2 Назначение разработки

Информационная система предназначена для автоматизации процесса расчёта трудоёмкости и стоимости изготовления электрических аппаратов и приборов ООО «ПО «Энергоспецтехника».

2.3 Требования к программе

2.3.1 Требования к системе в целом

Документы, полученные в результате работы АИС должны иметь стандартный формат документов Microsoft Word, просмотр и печать полученных документов осуществлять с помощью стандартных средств Microsoft Office.

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

Квалификация персонала, работающего с АИС, должна соответствовать умению работы с Microsoft Windows, приложениями Microsoft Office и свободному владению клавиатурой персональных ЭВМ.

Регламент эксплуатации комплекса должен сводиться к поддержанию исправности аппаратуры, программных средств.

2.3.2 Требования к функциональным характеристикам

Система должна выполнять следующие функции:

- обработка параметров, вводимых пользователем системы для расчета трудоемкости и стоимости изготовления изделий;

- расчет трудоемкости и стоимости изготовления изделий;

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

- формирование документа, содержащего подробную информацию о составе изделия;

- формирование диаграммы трудоёмкости изготовления изделий и гистограммы стоимости изготовления изделий.

В базе данных должны храниться следующие данные:

а) об изделиях (наименование изделия, цех, трудоёмкость, стоимость);

б) о деталях (наименование детали, размеры, форма, цвет);

в) об операциях (наименование операции, норма времени, расценка);

г) о составе изделий (количество деталей);

д) о списке «операция-деталь» (количество обработанных деталей).

2.3.3 Требования к надежности

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

2.3.4 Требования к составу и параметрам технических средств

АИС функционирует на технических средствах, включающих в себя:

рабочую станцию с процессором Intel с тактовой частотой 1,2 ГГц и выше, оперативную память не менее 1028 Мб, объём свободного места на жестком диске порядка 512Мб непосредственно под программу и временные файлы, графический видео адаптер, клавиатуру, мышь. Дополнительно необходимо наличие принтера формата А4.



2.3.5 Требования к информационной и программной совместимости

АИС должна функционировать в операционной системе Microsoft Windows XP и выше в составе программного пакета Microsoft Office 2007 с использованием языка создания приложений VBA (обязательно наличие Word).

2.4 Требования к программной документации

Документация на разрабатываемую систему должна включать:

- текст программы (листинг);

- описание программы;

- программу и методику испытаний;

- описание применения.

2.5 Стадии и этапы разработки

Процесс разработки информационной системы должен соответствовать следующим стадиям и этапам разработки:

- Анализ предметной области;

- Разработка модели информационной системы;

- Разработка базы данных;

- Разработка программы;

- Тестирование;

- Оформление пояснительной записки.

2.6 Порядок контроля и приемки

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



3. Разработка модели информационной системы

3.1 Функциональное проектирование информационной системы

3.1.1 Описание средства проектирования системы AllFusion Process Modeler 7

Описание, анализ и моделирование бизнес-процессов без применения специальных инструментов возможно только в самых простейших случаях. Для решения этих задач создана программа AllFusion Process Modeler 7, которая включает следующие методологии: IDEF0, DFD и IDEF3.

Пакет AllFusion Process Modeler 7 предназначен для создания функциональной модели существующей или проектируемой ИС.

Функциональная модель включает в себя:

- поименованные процессы, функции или задачи, которые должны выполняться в системе;

- взаимодействия этих процессов, функций, задач с внешним миром и между собой.

AllFusion Process Modeler 7 с использованием IDEF0 методология позволяет наглядно представить выбранную систему как совокупность взаимодействующих функций и задач. Функции и задачи системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.

IDEF0. В рамках методологии IDEF0 бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, обмениваясь информационными и материальными потоками с помощью людских и производственных ресурсов, потребляемых каждой работой. С помощью функционального моделирования можно провести системный анализ бизнеса, сосредоточившись на регулярно решаемых задачах или функциях, на показателях их правильного выполнения, необходимых для этого ресурсах, результатах и исходных материалах. AllFusion Process Modeler 7 автоматически синхронизирует изменения объектов диаграмм на всех уровнях детализации, тем самым, освобождая пользователя от ручного ведения словаря объектов модели. Так если мы исправим на верхнем уровне название объекта, то получим изменение на всех уровнях, где данный объект встречается. Также невозможным является случайное дублирование наименований работ. При появлении такой ситуации AllFusion Process Modeler 7 генерирует предупреждающее сообщение.

Различают пять типов стрелок:

- Вход (Input) - материал или информация, которые используются или преобразуются работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Стрелка входа рисуется как входящая в левую грань работы;

- Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы;

- Выход (Output) - материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы;

- Механизм (Mechanism) - ресурсы, которые выполняют работу, например персонал предприятия, станки и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы.

Вызов (Call) - специальная стрелка, указывающая на другую модель работы. Стрелка механизма рисуется как исходящая из нижней грани работы. Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы. В AllFusion Process Modeler 7 стрелки вызова используются в механизме слияния и разделения моделей.

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

IDEF3. Третий информационный разрез -- последовательность выполняемых работ. В отличие от диаграмм IDEF0 и DFD, элементы которых позволяют точно описать функциональность системы и организацию документооборота, описать с их помощью логику построения системы не удастся. Для описания логики взаимодействия информационных потоков, последовательности выполнения работ и сценариев взаимодействия модель дополняют диаграммами еще одной методологии -- IDEF3, также называемой диаграммами workflow.

Перечисленные информационные разрезы по-своему уникальны. Каждый из них может быть выполнен отдельно с помощью AllFusion Process Modeler 7, но их совокупность, заключенная в модель, дает аналитику полную картину предметной области клиента. Для детализации процесса используется декомпозиция./4/

3.1.2 Разработка функциональной модели информационной системы

Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее для достижения необходимой степени подробности.

Для разработки функциональной модели использовалось CASE-средство - AllFusion Process Modeler 7. При построении этой модели были выбраны две методологии: IDEF0 и DFD.

На основе анализа предметной области разработана диаграмма верхнего уровня системы обслуживания фирмы на основе методологии IDEF0.

Контекстная диаграмма «АИС расчёта трудоёмкости и стоимости изготовления изделий» (Рис. A1 приложения А). На вход поступает первоначальная информация (запрос на изготовление изделия, расценка и норма времени). На управление - критерии. На механизм - расчётчик. На выходе - отчет о трудоёмкости и стоимости изделия.

Для детализации процесса используется декомпозиция (Рис. A2 приложения А).

Процесс «Занесение нормы времени по операциям и деталям». На вход - норма времени и расценка. На выходе - передача данных.

Хранилище «Операции». На вход - передача данных. На выходе - норма времени по операции и детали, расценка по операции и детали.

Процесс «Формирование подетального состава изделия». На вход - запрос на изготовление изделия. На выходе - перечень деталей в изделии.

Для детализации процесса используется декомпозиция (Рис. A3 приложения А).

Процесс «Занесение информации об изделии». На вход - запрос на изготовление изделия. На выходе - информация об изделии.

Процесс «Занесение информации о деталях». На вход - запрос на изготовление изделия. На выходе - информация о деталях.

Хранилище «Изделие». На вход - информация об изделии. На выходе - список изделий.

Хранилище «Детали». На вход - информация о деталях. На выходе - список деталей.

Процесс «Составление списка подетального состава изделия». На вход - список изделий, список деталей. На выходе - список деталей в изделии.

Хранилище «Состав изделия». На вход - список деталей в изделии.

На выходе - количество деталей в изделии.

Процесс «Расчёт нормы времени по i-й операции j-й детали». На вход - норма времени по операции и детали, количество деталей в изделии. На выходе - норма времени на изделие.

Процесс «Расчёт трудоёмкости изготовления изделия». На вход - норма времени на изделие. На выходе - передача трудоёмкости в отчёт.

Процесс «Расчёт расценки по i-ой операции j-ой детали на изделие». На вход - расценка по операции и детали, количество деталей в изделии. На выходе - расценка на изделие.

Процесс «Расчёт стоимости изготовления изделия». На вход - расценка на изделие. На выходе - передача стоимости в отчёт.

Процесс «Обработка данных для отчёта». На вход - норма времени на изделие, расценка на изделие, количество деталей в изделии, передача трудоёмкости в отчёт, передача стоимости в отчёт. На выходе - отчёт о трудоёмкости и стоимости.

Для детализации процесса используется декомпозиция (Рис. A4 приложения А).

Процесс «Создание списка о деталях в изделии». На вход - количество деталей в изделии, передача шифров. На выходе - передача списка.

Хранилище «Шифры и наименования деталей». На выходе - передача шифров.

Процесс «Добавление нормы времени и расценки на детали». На вход - передача списка, норма времени на изделие, расценка на изделие. На выходе - передача дополненного списка.

Процесс «Добавление стоимости и трудоёмкости на изделие». На вход - передача дополненного списка, передача трудоёмкости в отчёт, передача стоимости в отчёт. На выходе - передача полного списка.

Процесс «Занесение информации об изготовителях». На вход - передача полного списка. На выходе - отчёт о трудоёмкости и стоимости.

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

3.2 Объектно-ориентированное проектирование информационной системы

3.2.1 Описание средства проектирования системы Rational Rose

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

Rational Rose Enterprise Edition - популярное средство визуального моделирования объектно-ориентированных информационных систем компании Rational Software Corp. Работа продукта основана на универсальном языке моделирования UML (Universal Modeling Language). Благодаря уникальному языку моделирования Rational Rose способен решать практически любые задачи в проектировании информационных систем: от анализа бизнес процессов до кодогенерации на определенном языке программирования. Только Rose позволяет разрабатывать как высокоуровневые, так и низкоуровневые модели, осуществляя тем самым либо абстрактное проектирование, либо логическое.

Только Rational Rose имеет весь необходимый набор визуальных средств проектирования. Только Rose поможет решить проблемы с кодогенерацией на определенном языке программирования. Только Rational Rose осуществляет такие подходы, как прямое и обратное проектирование, а так же Round Trip Engineering. Такой арсенал позволит не только проектировать новую систему, но и доработать старую, произведя процесс обратного проектирования.

Rational Rose поддерживает прямое и обратное проектирование на языках:

- ADA, Java, С, C++, Basic;

- Позволяет генерировать схемы Oracle и SQL;

- Rational Rose имеет открытый API, позволяющий создавать собственными силами модули для конкретных языков программирования.

На рынке уже сейчас имеется достаточное число модулей для популярных языков программирования и систем. Таких как: Delphi, AllFusion Data Modeller, Jbuilder, VisualCafe, Jdeveloper, VisualAge SmallTalk. Одна из ведущих компаний в области создания дополнительных модулей -- Ensemble Systems

Rational Rose неоднократно признавалось различными изданиями лучшим средством проектирования./5/

3.2.2 Построение диаграммы вариантов использования

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

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

Для построения диаграммы необходимо:

? выбрать актера, который будет являться инициатором какого-либо действия;

? определить функционирование системы при том или ином варианте использования./6/

Исходя из анализа предметной области и основных функций, выполняемых разрабатываемой системой была построена диаграмма вариантов использования. Диаграмма вариантов использования представлена на Рис. Б.1 приложения Б.

Главным пользователем программы является расчётчик. Он должен иметь возможность добавлять, изменять и удалять информацию. Также он получает запрос на расчёт трудоёмкости и стоимости изготовления изделия от заказчика. Далее он выполняет расчёты и формирует отчёт.

Перечисленные ниже варианты использования описывают функциональные возможности разрабатываемой системы.

Вариант использования «Формировать подетальный состав изделия». Расчётчик открывает форму для добавления нового подетального состава изделия. Система создаёт форму для добавления новой записи. Расчётчик создаёт изделие и определяет детали и их количество. Система сохраняет все изменения.

Вариант использования «Проверить наличие детали». Расчетчик, прежде чем добавить новую запись проверяет список деталей на наличие повторений. Система контролирует этот процесс.

Вариант использования «Заполнить справочник детали». Расчётчик открывает форму для добавления новой детали в справочник «Детали». Система создаёт форму для добавления новой детали. Расчётчик вводит наименование и характеристики детали. Система сохраняет все изменения.

Вариант использования «Заполнить справочник операции». Расчётчик открывает форму для добавления новой операции в справочник «Операции». Система создаёт форму для добавления новой операции. Расчётчик вводит наименование и характеристики операции. Система сохраняет все изменения.

Вариант использования «Создать список операция-деталь». Расчётчик открывает форму для добавления новой записи в список «Операция-Деталь». Система создаёт форму для добавления новой записи. Расчётчик вводит наименование детали и операцию, которая будет выполняться над этой деталью. Система сохраняет все изменения.

Вариант использования «Рассчитать трудоёмкость изделия». Расчётчик открывает форму для расчета трудоёмкости изделия. Расчётчик выбирает норму времени по каждой операции. Система рассчитывает и сохраняет все изменения.

Вариант использования «Выбрать норму времени». Расчётчик должен указать норму времени при расчете трудоёмкости изделия по имеющимся тарифам. Система сохраняет все изменения.

Вариант использования «Рассчитать стоимость изделия». Расчётчик открывает форму для расчета стоимости изделия. Расчётчик выбирает расценку по каждой операции. Система рассчитывает и сохраняет все изменения.

Вариант использования «Выбрать расценку». Расчётчик должен указать расценку при расчете трудоёмкости изделия по имеющимся тарифам. Система сохраняет все изменения.

Вариант использования «Составить отчёт о трудоёмкости и стоимости изделия». Расчётчик составляет отчёт о трудоёмкости и стоимости изделия. Помимо основных параметров он должен указать номера операций, информацию об изготовителях, при необходимости указать наименования деталей. Система сохраняет и печатает отчёт.

Вариант использования «Указать номер операции». До создания отчёта расчётчик должен проверить наличие номеров операций. Система сохраняет все изменения.

Вариант использования «Указать информацию об изготовителях». До создания отчёта расчётчик должен указать всю необходимую информацию об изготовителях изделия. Система сохраняет все изменения.

Вариант использования «Указать наименование деталей». До создания отчёта расчётчик должен проверить названия деталей. Система сохраняет все изменения.

На диаграмме применяются следующие виды связи:

- ассоциация (association relationship) - служит для обозначения специфической роли актера в отдельном варианте использования. Другими словами, ассоциация специфицирует семантические особенности взаимодействия актеров и вариантов использования в графической модели системы;

- расширение (extend relationship) - указывает, что применительно к отдельным примерам некоторого варианта использования должны быть выполнены конкретные условия, определенные для расширения данного варианта использования;

- обобщение (generalization relationship) - служит для указания того факта, что некоторый вариант использования А может быть обобщен до варианта использования В. В этом случае вариант А будет являться специализацией варианта В;

- включение (include relationship) - указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования.

3.2.3 Построение диаграммы взаимодействия объектов

Для моделирования динамических свойств проектируемой системы в UML определены диаграммы взаимодействия объектов: диаграммы последовательностей и диаграммы кооперации

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

Обязательными элементами диаграмм взаимодействий являются объекты, связи, сообщения. информация клиентский приложение серверный

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

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

Для построения диаграмм взаимодействия укажем состав для 3 вариантов использования:

Заполнить справочник "Детали"

Состав:

- Форма добавления детали;

- Управление записями;

- Деталь;

- Менеджер транзакций;

Создать список "Операция-деталь"

Состав:

- Форма добавления детали;

- Управление записями;

- Деталь;

- Операция;

- Менеджер транзакций.

Формировать подетальный состав изделия

Состав:

- Управление записями;

- Изделие;

- Деталь;

- Состав изделия;

- Менеджер транзакций.

Диаграммы последовательностей для вариантов использования представлены на Рис. Б.2-Б.7 приложения Б.

3.2.4 Построение диаграммы классов

Диаграмма классов - статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами. Это один из наиболее часто используемых видов диаграмм UML. Обычно создание диаграммы классов знаменует собой окончание процесса анализа и начало процесса проектирования.

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

Классом называется именованное описание совокупности объектов с общими атрибутами, операциями, связями и семантикой. Диаграмма классов отражает систему в статическом состоянии.

Полученная диаграмма классов представлена на Рис. Б.8 приложения Б.

В проектируемой системе были выделены следующие классы:

- класс «Состав» необходим для описания состава изделия. Атрибуты класса: «Количество деталей», «Номер состава». Методы класса: Создать(), Указать название(), Выбрать(), Указать количество().

- класс «Операции» необходим для описания производимых операций над деталями. Атрибуты класса: «Название операции», «Норма времени», «Расценка», «Номер операции». Методы класса: Создать(), Сохранить().

- класс «Детали» необходим для описания информации о деталях. Атрибуты класса: «Название детали», «Вид детали», «Размеры», «Номер детали». Методы класса: Создать(), Сохранить().

- класс «Изделие» необходим для описания информации об изделии. Атрибуты класса: «Название изделия», «Цех», «Трудоёмкость», «Стоимость», «Номер изделия». Метод класса: Создать().

- класс «Менеджер» необходим для описания информации о состоянии системы. Методы класса: Создать(), Сохранить информацию().

- класс «Управление» необходим для описания информации об управлении системы. Методы класса: Создать(), Информация().

- класс «Форма» необходим для описании состояния о формах системы. Метод класса: Открыть().

Описание кратностей связей между классами.

Между классами «Операции» и «Состав» будет связь «один-ко-многим», так как одна операция может выполняться над многими составами изделий.

Между классами «Операции» и «Изделие» будет связь «один-ко-многим», так как одна операция может выполняться над многими изделиями.

Между классами «Детали» и «Операции» будет связь «один-ко-многим», так как над одной деталью может выполняться много операций.

Между классами «Детали» и «Состав» будет связь «один-ко-многим», так как одна деталь может входить в разные составы изделий.

Все перечисленные диаграммы представлены в приложении Б.

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



4. Разработка базы данных

4.1 Описание средства проектирования AllFusion Data Modeller 7

Пакет AllFusion Data Modeller 7 предназначен для создания информационной модели базы данных. Он позволяет формировать модель данных с учетом всех связей, а также ограничений на исходные данные. AllFusion Data Modeller 7 имеет два уровня представления модели - логический и физический.

Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире. Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД.

Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах. Основные компоненты диаграммы ? это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Атрибут выражает определенное свойство объекта. С точки зрения БД (физическая модель) сущности соответствует таблица, экземпляру сущности - строка в таблице, а атрибуту - колонка таблицы.

Связь является логическим соотношением между сущностями. Различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, AllFusion Data Modeller 7 автоматически преобразует дочернюю сущность в зависимую. Экземпляр зависимой сущности определяется только через отношение к родительской сущности. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ - (FK). При установлении не идентифицирующей связи дочерняя сущность остается независимой, а атрибуты первичного ключа родительской сущности мигрируют в состав не ключевых компонентов родительской сущности. Не идентифицирующая связь служит для связывания независимых сущностей.

Мощность связи служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней. Различают четыре типа мощности: общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности не помечается каким-либо символом; символом Р помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности; символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности; цифрой помечается случай точного соответствия, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности./8/

4.2 Логическое проектирование базы данных

В результате анализа задания средствами AllFusion Data Modeller 7 разработана логическая модель данных, которая представлена на Рис. В.1 приложения В.

Выделены следующие сущности и их атрибуты (таблица 1):

Таблица 1 - Сущность и их атрибуты

Сущность	Атрибут	Ключ
1	2	3
Изделие	id_изделия	PK
	Название изделия
	Цех
	Трудоемкость
	Стоимость
Операция-деталь	Шифр детали	FK
	id_операции	FK
	Кол-во обраб. деталей
Деталь	Шифр детали	РК
	Наименование детали
	Форма детали
	Цвет детали
Операции	id_операции	PK
	Название операции
	Норма времени
	Расценка
Состав изделия	Шифр детали	FK
	Количество деталей
	id_изделия	FK

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



Таблица 2 - Связи между сущностями

Родительская сущность	Дочерняя сущность	Тип связи	Мощность связи	Внешний ключ
1	2	3	4	5
Изделие	Состав изделия	идентифицирующая	1:М	id_изделия
Деталь	Состав изделия	идентифицирующая	1:М	Шифр детали
Деталь	Операция-деталь	идентифицирующая	1:М	Шифр детали
Операции	Операция-деталь	идентифицирующая	1:М	id_операции

4.3 Нормализация базы данных

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

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

Рассмотрим нормализацию отношения до 1НФ на примере сущности «Изделие». Данное отношение имеет первичный ключ id_изделия, а атрибут Название изделия содержит только одно значение. Таким образом, данное отношение находится в 1НФ.

Рассмотрим нормализацию отношения до 1НФ на примере сущности «Операции». В данном отношении выделен первичный ключ id_операции, его кортежи содержат только одно значение для каждого из атрибутов.

В результате проведенной нормализации для всех сущностей можно утверждать, что данная модель удовлетворяет 1НФ.

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

Отношение «Изделие», «Деталь», «Операции» находятся в 1НФ и имеют в своем составе единственный первичный ключ, автоматически находятся во 2НФ.

Проведем нормализацию для отношения «Состав изделия» и «Операция-деталь». Атрибуты «Количество деталей» и «Количество обработанных деталей» функционально зависят от всего составного первичного ключа, но при этом не находятся в функциональной зависимости от какой-либо из входящих в него атрибутов.

Таким образом, можно сделать вывод, что данное отношение находится во 2НФ.

Отношение находится в 3НФ тогда и только тогда, когда выполняются следующие условия:

а) отношение R (таблица) находится во второй нормальной форме;

б) каждый непервичный атрибут R находится в нетранзитивной (то есть прямой) зависимости от каждого ключа R.

Непервичный (неключевой) атрибут R -- это атрибут, который не принадлежит ни одному из возможных (альтернативных) ключей R. Транзитивная зависимость -- это функциональная зависимость, при которой X > Z (X определяет Z) не напрямую, а посредством отношения X > Y и Y > Z (отношение Y > X не является обязательным условием).

Рассмотрим отношения «Изделие», «Деталь», «Операции», «Состав изделия» и «Операция-деталь». В данных сущностях не присутствуют транзитивные зависимости, следовательно, они находится в 3НФ.

В результате проведенной нормализации все отношения находятся в трех нормальных формах, кроме отношений

4.4 Физическое проектирование базы данных

Обычно разработка модели базы данных состоит из двух этапов: составление логической модели и создание на ее основе физической. AllFusion Data Modeller 7 полностью поддерживает такой процесс. При этом каждой сущности ставится в соответствие таблица, атрибутам сущности соответствуют атрибуты таблицы, а идентификатору сущности соответствует ключ таблицы.

Описание физической модели: соответствие атрибутам логической модели, типы данных представлены в таблице 3.

Таблица 3 - Описание физической модели

Имя поля	Тип данных	Свойства поля
1	2	3
Сущность «Операции»
id_операции	Числовой	Целое, индекс без повторений, первичный ключ
Название операции	Текстовый	Длина 20
Норма времени	Числовой	Целое
Расценка	Числовой	Целое
Сущность «Операция-деталь»
id_операции	Числовой	Целое, индекс без повторений, составной ключ
Шифр детали	Текстовый	Длина 20, индекс без повторений, составной ключ
Кол-во обраб. деталей	Числовой	Целое
Сущность «Деталь»
Шифр детали	Текстовый	Длина 20, индекс без повторений, первичный ключ
Название детали	Текстовый	Длина 20
Форма детали	Текстовый	Длина 20
Цвет детали	Текстовый	Длина 20
Сущность «Состав изделия»
Шифр детали	Текстовый	Длина 20, составной ключ
ip_изделия	Числовой	Целое, индекс без повторений, составной ключ
Количество деталей	Числовой	Целое
Сущность «Изделие»
ip_изделия	Числовой	Целое, индекс без повторений, первичный ключ
Название изделия	Текстовый	Длина 20
Цех	Текстовый	Длина 20
Трудоёмкость	Числовой	Целое
Стоимость	Числовой	Целое

Физическая модель информационной системы приведена на Рис. В.2 приложения В.

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



5. Анализ целесообразности использования заданных средств разработки

«Информационная система для расчёта трудоёмкости и стоимости изготовления промышленных изделий» будет разработана в среде Microsoft Access 2007 с использованием VBA для операционных система Windows 2000/NT/XP.

Разработку программы было решено вести в среде Microsoft Access 2007, это обуславливается тем, что в ООО «ПО «Энергоспецтехника» широко используется Microsoft Office 2007.

Microsoft Office Access или просто Microsoft Access -- реляционная СУБД корпорации Microsoft. Имеет широкий спектр функций, включая связанные запросы, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных.

Основные компоненты MS Access:

- построитель таблиц;

- построитель экранных форм;

- построитель SQL-запросов (язык SQL в MS Access не соответствует стандарту ANSI);

- построитель отчётов, выводимых на печать.

Они могут вызывать скрипты на языке VBA, поэтому MS Access позволяет разрабатывать приложения и БД практически «с нуля» или написать оболочку для внешней БД.

Microsoft Jet Database Engine (англ.), которая используется в качестве движка базы данных MS Access является файл-серверной СУБД и потому применима лишь к приложениям, работающим с небольшими объемами данных и при небольшом числе пользователей, одновременно работающих с этим данными. Непосредственно в Access отсутствует ряд механизмов, необходимых в многопользовательских БД, таких, например, как триггеры.

Встроенные средства взаимодействия MS Access со внешними СУБД с использованием интерфейса ODBC снимают ограничения, присущие Microsoft Jet Database Engine. Инструменты MS Access, которые позволяют реализовать такое взаимодействие называются "связанные таблицы" (связь с таблицей СУБД) и "запросы к серверу" (запрос на диалекте SQL, который "понимает" СУБД).

Корпорация Microsoft для построения полноценных клиент-серверных приложений на базе MS Access рекомендует использовать в качестве движка базы данных СУБД MS SQL Server. При этом имеется возможность совместить с присущей MS Access простотой инструменты для управления БД и средства разработки.

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

Access, при работе с базой данных, иначе взаимодействует с жёстким (или гибким) диском, нежели другие программы.

В других программах, файл-документ, при открытии, полностью загружается в оперативную память, и новая редакция этого файла (изменённый файл) целиком записывается на диск только при нажатии кнопки «сохранить».

В Access новая редакция содержимого изменённой ячейки таблицы записывается на диск (сохраняется) сразу, как только курсор клавиатуры будет помещён в другую ячейку (или новая редакция изменённой записи записывается на диск сразу, как только курсор клавиатуры будет поставлен в другую запись (в другую строку)). Таким образом, если внезапно отключат электричество, то пропадёт только изменение той записи, которую не успели покинуть.