71033

Информационно–справочная система архива проектно–сметной документации для Ставропольнефтегаз

Дипломная

Информатика, кибернетика и программирование

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

Русский

2015-01-11

16.24 MB

11 чел.

Информационно – справочная система архива проектно – сметной документации для Ставропольнефтегаз

ВВЕДЕНИЕ

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

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

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

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

ГЛАВА 1. СИСТЕМНЫЙ АНАЛИЗ

1.1 Анализ организационной структуры предприятия

«Роснефть» – лидер российской нефтяной отрасли и одна из крупнейших публичных нефтегазовых компаний мира. Основными видами деятельности «Роснефти» являются:

-   разведка и добыча нефти и газа;

-   производство нефтепродуктов и продукции нефтехимии;

- сбыт произведенной продукции.

Одной из стратегических задач «Роснефти» является увеличение объемов реализации собственной продукции напрямую конечному потребителю.

В состав нефтяной компании ‹‹Роснефть›› входит общество с ограниченной ответственностью «РН – Ставропольнефтегаз››. Она является важной, неотъемлемой частью ресурсной базы НК «Роснефть» на юге европейской части России. Это предприятие, осуществляющее свою деятельность в Ставропольском крае, было основано в 1992 году, в качестве регионального нефтегазодобывающего предприятия.

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

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

Организационно-производственная структура предприятия ООО «РН – Ставропольнефтегаз» представлена на рисунке 1.1.



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

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

- производственно – технического отдела;

- зам. Главного инженера по ПУ и ТН;

- сектора главного механика.

Заместитель генерального директора по кадровой политике осуществляет руководство за деятельностью отдела по планированию персонала.

Заместитель генерального директора по экономике и финансам руководит экономическим отделом.

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

Заместитель генерального директора по МТО и транспорту контролирует работу отдела материально – технического обеспечения.

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

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

1.1.1 Задачи, выполняемые отделом перспективного планирования и организации проектных работ.

Целью функционирования работы отдела перспективного планирования и организации проектных работ является:

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

Функциональная схема организации проектных работ отделом ПП и ОПР показана на рис 1.2

  1.  Организация и участие  в  подготовке технических условий для разработки  проектно-сметной  документации  на строительство, реконструкцию, модернизацию, техническое перевооружение, капитальный  ремонт  зданий и сооружений.
  2.  Сбор исходных данных и технических условий для проектирования от федеральных, муниципальных органов и сторонних организаций.
  3.  Разработка технических заданий и заданий на проектирование объектов программы капитального строительства.
  4.  Оформление договоров с проектными организациями на проектирование объектов капитального строительства (новое строительство,  реконструкция, модернизация, техническое перевооружение, капитальный ремонт зданий и сооружений).
  5.  Подготовка планов и графиков разработки институтами проектно-сметной документации на строительство, капитальный ремонт зданий и сооружений, реконструкцию, модернизацию и техническое перевооружение объектов Общества.
  6.  Рассмотрение Проектно-сметной документации (ПСД) на строительство, реконструкцию, модернизацию, техническое перевооружение, капитальный ремонт зданий и сооружений на соответствие техническим условиям, заданиям на проектирование, техническим заданиям, а также действующим строительным нормам и правилам.
  7.  Осуществление, совместно с соответствующими отделами, внутренней экспертизы проектов и смет на строительство, реконструкцию, модернизацию, техническое перевооружение, капитальный ремонт зданий и сооружений в том числе по соблюдению норм, правил и других нормативных документов по вопросам промышленной безопасности, охраны труда и окружающей среды.
  8.  Формирование ежемесячной отчетности обеспеченности объектов капитального строительства ПСД будущих лет и текущего периода и предоставление ее в Компанию.
  9.  Обеспечение своевременного проектирования объектов  строительства, реконструкции, модернизации, технического перевооружения, капитального ремонта зданий и сооружений.


  1.  Решение   вопросов в   установленном   порядке     о   своевременном  финансировании  работ по  проектированию объектов,  предусмотренных  бизнес планом.
  2.   Организация  работы в области нормативного обеспечения бизнеса по своему направлению деятельности (Разработка и  актуализация локальных нормативных документов в соответствии с законодательством РФ и корпоративными требованиями).

1.1.2. Структура проектно-сметной документации

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

  1.  Проектная документация состоит из текстовой и графической частей.

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

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

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

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

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

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

в) линейные объекты - трубопроводы, автомобильные и железные дороги, линии электропередачи и др.

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

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

  1.  Раздел 1 "Пояснительная записка";
  2.  Раздел 2 "Схема планировочной организации земельного участка";
  3.  Раздел 3 "Архитектурные решения";
  4.  Раздел 4 "Конструктивные и объемно-планировочные решения";
  5.  Раздел 5 "Сведения об инженерном оборудовании, о сетях инженерно-технического обеспечения, перечень инженерно-технических мероприятий, содержание технологических решений";

а) подраздел "Система электроснабжения";

б) подраздел "Система водоснабжения";

в) подраздел "Система водоотведения";

г) подраздел "Отопление, вентиляция и кондиционирование воздуха, тепловые сети";

д) подраздел "Сети связи";

е) подраздел "Система газоснабжения";

ж) подраздел "Технологические решения".

  1.  Раздел 6 "Проект организации строительства";

  1.  Раздел 7 "Проект организации работ по сносу или демонтажу объектов капитального строительства" выполняется при необходимости сноса (демонтажа) объекта или части объекта капитального строительства;
  2.  Раздел 8 "Перечень мероприятий по охране окружающей среды";
  3.  Раздел 9 "Мероприятия по обеспечению пожарной безопасности";
  4.   Раздел 10 "Мероприятия по обеспечению доступа инвалидов";
  5.   Раздел 11 "Смета на строительство объектов капитального строительства";
  6.   Раздел 12 "Иная документация в случаях, предусмотренных федеральными законами";

В ООО «РН - Ставропольнефтегаз» проектный институт предоставляет проектно-сметную документацию в 4-х бумажных экземплярах на каждый объект. В среднем в год поступает около сотни ПСД. За все время существования ООО «РН - Ставропольнефтегаз» накопилось более 2000 проектно-сметной документации. Поступившая документация на бумажном носителе, размещается на металлических стеллажах в отдельно отведенном помещении (архиве). На рис.1.4. приведена схема размещения стеллажей в помещении архива. На рис.1.5. изображено размещение проектно-сметной документации на стеллажах. А общий вид  размещения стеллажей в архиве представлен на рис.1.6.

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

 Рис.1.4. План расположения стеллажей в помещении архива

Рис.1.5. Образец размещение ПСД на стеллажах

Рис.1.6. Общий вид стеллажей в архиве

  •  кому выдан (кем возвращен);
  •  наименование разделов;
  •  количество экземпляров;
  •  дата выдачи (дата возврата).

В настоящее время в ООО «РН-Ставропольнефтегаз» отсутствует информационно - справочная система проектно-сметной документации,  вследствие чего возникают следующие проблемы:

  •  регистрация изменений вносимых в проектно-сметную документацию в ходе строительства объекта, отсутствует.
  •  Затруднена систематизация архива, в части отслеживания количества имеющейся в архиве бумажных копий проектно-сметной документации, сроков поступления и хранения разделов проектно-сметной документации, сроки хранения которых, определены Федеральными законами;
  •  поиск документов в бумажном архиве отнимает очень много времени, при этом не факт, что найдутся нужные документы;
  •  существует возможность утери документов: по оценкам специалистов, от 5 до 7% технических материалов не могут быть использованы - они потеряны или разукомплектованы.

1.2 Анализ существующих информационно - справочных систем обеспечения деятельности архива

На сегодняшний день существует несколько систем автоматизации архива проектно-сметной документации. Наиболее распространенные системы это электронный архив проектно-сметной документации ОАО "Газпром" и электронный архив проектно-сметной документации в ООО «ПермНИПИнефть» . Рассмотрим их подробнее.  

1. Электронный архив ПСД объектов ОАО "Газпром" предназначен для обеспечения централизованного учета, хранения и использования в электронном виде проектно-сметной и технической документации по объектам строительства и реконструкции (проекты, обоснования инвестиций, рабочая документация и т.д.).

Система управления электронным архивом ЭА ПСД обеспечивает:

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

-    каталогизацию документов, информационных ресурсов;

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

-  коллективную работу пользователей с документацией в единой информационной среде;

-    поддержку процедур комплектования документов;

- обеспечение целостности, надежности хранения и защиты информации;

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

-   консолидация и обзор информации по работам (проектам);

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

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

Автоматизированная система управления проектными данными обеспечивает:

- централизованное хранение и использование архива проектно-сметной и конструкторской документации (ПСД и КД)

- управление процессом сдачи ПСД в архив;

- управление процессом изменения документации.

В состав АСУ ПСД входят следующие подсистемы:

  •  Подсистема автоматизации создания структуры проекта

Предназначена для быстрого и удобного создания структуры проекта. ГИП определяет, какие разделы проекта будут включены в заказ, так же как и для записи на диск.

  •  Подсистема согласования документации

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

  •  Подсистема приема документации в архив

Предназначена для хранения проектной документации в стадии «архив». Архивариус следит за сроками сдачи документации и ее соответствием нормативам и требованиям.

  •  Подсистема работы с изменениями документации

Позволяет проектировщикам вносить изменения в уже сданную проектную документацию.

  •  Подсистема создания набора передаваемой документации для записи на диск

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

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

Рис.1.6. Главная форма ЭА ПСД ООО «ПермНИПИнефть»

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

В системе реализуется поиск документации и объектов строительства по множеству критериев. Результаты поиска отображаются в окне управления структурой проектов в виде отфильтрованного дерева. Кликнув левой кнопкой мыши на компоненты дерева можно просмотреть содержимое документа и информацию о его состоянии.

Сравнительная характеристика рассмотренных информационно – справочных систем представлена в таблице 1.1.

Таблица 1.1 Сравнительная характеристика систем автоматизации

Критерий

ЭА ПСД

ОАО "Газпром"

ЭА ПСД

ООО «ПермНИПИнефть»

Каталогизация документов

+

+

Разделение информации по видам документов

-

+

Хранение электронных документов

+

+

Детальное предоставление информации о комплекте документов

-

+

Доступ к документам на основе прав пользователей

-

-

Управление процессом сдачи ПСД в архив

-

+

Управление процессом изменения документации

-

+

Учет выдачи и возврата проектно-сметной документации

-

-

Внесение в архив нового комплекта документов

+

+

Администрирование системы

-

-

В результате проведенного анализа двух информационных систем автоматизации можно утверждать, что наиболее соответствует задачам ООО «РН - Ставропольнефтега» система ЭА ПСД ООО «ПермНИПИнефть». Эта система обеспечивает учет, хранение и использование архива проектно-сметной и конструкторской документации. Позволяет вносить изменения в уже сданную проектную документацию. К недостаткам системы можно отнести то, что она создана непосредственно для систематизации архива ПСД, т.е. для проектного института. Программа реализует функции, не требующиеся для работы отдела перспективного планирования и организации проектных работ, такие как: 

- управление процессом сдачи ПСД в архив;

- управление процессом изменения документации

- процесс согласования документации.

Поэтому основными недостатками использования этого программного продукта являются его избыточность. При применении этого продукта пользователь вынужден производить:

- техническую поддержку информационной системы;

- модификацию функций реализуемых в системе;

- консультирование по работе с системой;

- обучение сотрудников отдела по эксплуатации этого программного продукта.

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

1.4 Постановка задачи

Результат системного анализа деятельности ООО «РН - Ставропольнефтегаз» позволяет сделать вывод о целесообразности создания специализированной информационно – справочной системы ведения учета и использование проектно – сметной документации отдела перспективного планирования и организации проектных работ. Эта система должна реализовывать следующие функции на имеющемся оборудовании в отделе перспективного планирования и организации проектных работ, в существующей локальной вычислительной системе (ЛВС) с защищенным доступом из общей сети ООО "РН - Ставропольнефтегаз":

  1.  Представление документов в виде «иерархического дерева», выстраиваемого в соответствии со структурной идентификацией всех объектов, сооружений и коммуникаций;
  2.  Поиск необходимых документов:
  •  по атрибутам документа;
  •  по проектным институтам;
  •  по целевым программам;
  1.  Учет выдачи и возврата проектно-сметной документации;
  2.  Возможность отслеживания изменений состояния разработки проектируемого объекта, сооружения, коммуникации;
  3.  Полное предоставление информации о составе комплекта документов;
  4.  Внесение в архив нового комплекта документов, а также корректировка его состава;
  5.  Администрирование системы (заведение новых пользователей, определение прав доступа и контроль).


ГЛАВА 2. СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ

2.1 Технологические операции с ПСД в процессе выполнения проектных работ

В своей деятельности в отделе перспективного планирования и организации проектных работ предприятия ООО «РН - Ставропольнефтегаз» ведется учет проектно – сметной документации по различным категориям: по целевым программам, по институтам, по виду проектно сметной документации и т.д. При работе с ПСД выполняется аналитический и количественный виды учета. Аналитический учет основывается на качественных характеристиках объекта: при формировании поступающих договоров важной информацией является название проектного института. В организации количественного учета основными являются количественные характеристики объекта: сроки проектирования объекта, его стоимость.

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

- проектных институтов, с которыми сотрудничает предприятие;

- объектов, с которыми работаю проектные институты;

- объектов;

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

- целевых программ, к которым относятся объекты;

- сотрудников предприятия, которые работают с проектно – сметной документацией.

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

- состояние проектирования;

- стоимость проектирования;

- сроки проектирования;

- целевая программа;

- проектный институт, который занимается данным объектом.

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

2.2 Функциональная структура системы

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

На функциональной структуре  ИСС проектно – сметной можно выделить следующие функции:

  •  Подсистема администрирования системы включает в себя:

- заведение новых пользователей;

- определение прав доступа к документации;

- контроль над пользователями системы;

- история работы пользователя.

  •  Работа с каталогом:

- создание иерархического каталога;

- разделение информации по видам проектно – сметной документации;

- информация о проектно – сметной документации;

- внесение новой проектно – сметной документации;

- изменение состава проектно – сметной документации;

- удаление проектно – сметной документации;

- учет документации;

- выдача документации;

- возврат документации;



  - печать документации.

  •  Поиск необходимых документов:

- поиск по названию проектно – сметной документации;

- поиск по шифру проектно – сметной документации;

- поиск по институтам;

- поиск по целевым программам;

- поиск по годам.

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

2.2 Комплекс технических средств

В настоящее время в отделе перспективного планирования и организации проектных работ функционирует локальная вычислительная сеть (ЛВС) с защищенным доступом из общей сети ООО «РН - Ставропольнефтегаз». В качестве соединения используется сеть Ethernet. Теоретическая максимальная скорость передачи данных - 1000 Мбит/сек. Реальная скорость передачи данных, при передаче большого файла с одной рабочей станции на другую составляет, не более, 5000 килобайт/сек. Степень защиты документации должна быть высокой, чтобы не позволить злоумышленникам несанкционированный доступ к архиву проектно-сметной документации. Для этого необходимо использовать существующую ЛВС, без выхода в интернет. Структурная схема ЛВС отдела перспективного планирования и организации проектных работ показана на рисунке 2.3

Рабочая станция обладает следующими характеристиками:

Рабочая станция и.о. начальника отдела перспективного планирования и организации проектных работ:

  •  процессор Intel Pentium 4  2400 МГц,
  •  оперативная память 512 Мб,
  •  жесткий диск 320 Гб,


  •  сетевая карта D-LINK DGE-530T (Ethernet 100/1000 Мбит/с).

Рабочая станция работников отдела перспективного планирования и организации проектных работ:

  •  процессор Intel Celeron  1700 МГц,
  •  оперативная память 256 Мб,
  •   жесткий диск 120 Гб,
  •  сетевая карта D-LINK DGE-530T (Ethernet 100/1000 Мбит/с).

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

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

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

2.4 Структурный анализ системы

Диаграммы потоков данных (DFD-Data  FlowDiagram) являются основным средством моделирования функциональных требований к проектируемой системе. Таким образом, эти требования можно представлять в виде иерархии функциональных компонентов (процессов), связанных потоками данных. Главная цель - продемонстрировать, как процессы преобразуют входные и выходные данные, и выявить основные отношения.

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

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

В ходе структурного анализа использовались  контекстная диаграмма и диаграммы потоков данных (DFD) совместно со словарем.

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

2.4.1 Построение контекстной диаграммы

В приведенной контекстной диаграмме с единственным процессом ИСС проектно-сметной документации идентифицируются внешние сущности ПОЛЬЗОВАТЕЛЬ и КОМПЬЮТЕР ПРЕДПРИЯТИЯ, хранящий информацию обо всей проектно-сметной документации. Для обслуживания пользователю необходимо предоставить системе ЛОГИН и ПАРОЛЬ, а также КЛЮЧЕВЫЕ СЛОВА ДЛЯ ПОИСКА ресурсов. Как результат    система    должна     выдать   клиенту СПИСОК ПОДХОДЯЩИХ

Рис. 2.4. Контекстная диаграмма ПО ИСС проектно-сметной документации

ДОКУМЕНТОВ или СООБЩЕНИЕ ОБ ОТСУТСТВИИ НЕОБХОДИМОГО ДОКУМЕНТА.

Если клиент желает добавить документ в ИСС, то ему необходимо передать системе ИНФОРМАЦИЮ О ДОБОВЛЯЕМОМ ДОКУМЕНТЕ.

Обслуживание с позиции пользователя должно обеспечить следующее:

  •  выдать ОТЧЕТ.

Контекстный процесс и КОМПЬЮТЕР ПРЕДПРИЯТИЯ должны обмениваться следующей информацией:

  •  ДАННЫЕ ПО ЗАПРОСУ.
  •  ПРОТОКОЛ ОБСЛУЖИВАНИЯ, включающий в себя информацию об ОБРАБОТАННОЙ ДОКУМЕНТАЦИИ и ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА.
  •  ДОБАВЛЕНИЕ/ИЗМЕНЕНИЕ/УДАЛЕНИЕ ПРОЕКТНО-СМЕТНОЙ ДОКУМЕНТАЦИИ.

2.4.2 Построение DFD-диаграмм потоков данных

В контекстной диаграмме контекстный процесс может быть детализирован. Эта детализация представлена на DFD 1-го уровня.

Рис. 2.5. DFD диаграмма первого уровня

Эта диаграмма содержит 4 процесса и хранилище БД КЛИЕНТОВ.

Процесс 1.1 (ПОЛУЧИТЬ ПАРОЛЬ) осуществляет прием и проверку пароля и имеет на входе/выходе следующие потоки:

  •  внешний выходной поток СООБЩЕНИЕ для информирования и готовности принять пароль.
  •  входной поток ВВЕДЕННЫЙ ПАРОЛЬ как элемент внешнего потока ЛОГИН И ПАРОЛЬ.

Процесс 1.2 (ПОЛУЧИТЬ ЗАПРОС НА ОБСЛУЖИВАНИЕ)  осуществляет прием и проверку запроса на проведение необходимой операции и имеет на входе/выходе следующие потоки:

  •  внешний выходной поток СООБЩЕНИЕ для информирования о своей готовности принять запрос на обслуживание.
  •  входной поток ЗАПРОС НА ОБСЛУЖИВАНИЕ как элемент внешнего потока КЮЧЕВЫЙ СЛОВА ДЛЯ ПОИСКА.

Процесс 1.3 (КЛАССИФИЦИРОВАТЬ ЗАПРОС НА ОБСЛУЖИВАНИЕ) имеет потоки:

  •  входной поток ФОРМА ЗАПРОСА.
  •  Выходные потоки  КОМАНДЫ ЗАПРОСА, ИДЕНТИФИКАЦИЯ ЗАПРОСА.

Процесс 1.4 (ОБРАБОТАТЬ ЗАПРОС ПО ПРОЕКТНО-СМЕТНОЙ ДОКУМЕНТАЦИИ) имеет:

  •  на входе потоки КОМАНДЫ ЗАПРОСА, ДАННЫЕ О ЗАПРОСЕ, а также внешний входной поток ДАННЫЕ ПО ПРОЕКТНО-СМЕТНОЙ ДОКУМЕНТАЦИИ
  •  на выходе внешние выходные потоки ОТЧЕТ и ПРОТОКОЛ ОБСЛУЖИВАНИЯ.

Процессы 1.1, 1.2 являются элементарными, поэтому нет необходимости в их детализации с помощью DFD 2-го уровня. Процессы 1.3 и 1.4 могут быть детализированы в DFD нижнего уровня. Таким образом, строится  иерархия DFD с контекстной диаграммой в корне дерева. При таком построении иерархии DFD каждый процесс более низкого уровня необходимо соотнести с процессом верхнего уровня. Для этой цели используются  структурированные номера процессов.

Рис. 2.6. DFD диаграмма второго уровня

Процесс 1.3.1 (РЕГИСТРИРОВАТЬ ДАННЫЕ КЛИЕНТА) осуществляет регистрацию данных о клиенте, содержит следующие потоки:

  •  входной поток ФОРМА ЗАПРОСА.
  •  выходной поток КОМАНДЫ ЗАПРОСА.

Процесс 1.3.2 (РЕДАКТИРОВАТЬ ДАННЫЕ ПО ПРОЕКТНО-СМЕТНОЙ ДОКУМЕНТАЦИИ)  осуществляет обновление, редактирование, дополнение, данных по документации, содержит следующие потоки:

  •  входной поток ФОРМА ЗАПРОСА.
  •  выходной поток КОМАНДЫ ЗАПРОСА.

Процесс 1.3.3 (ПРОСМОТР ВСЕЙ ПРОКТНО-СМЕТНОЙ ДОКУМЕНТАЦИИ) осуществляет возможность просмотра всей проектно-сметной документации, хранящейся в архиве, содержит следующие потоки:

  •  входной поток ФОРМА ЗАПРОСА.
  •  выходной поток КОМАНДЫ ЗАПРОСА.

Процесс 1.3.4 (УДАЛЯТЬ ДАННЫЕ О ПРОЕКТНО-СМЕТНОЙ ДОКУМЕНТАЦИИ) осуществляет удаление данных по документации, содержит следующие потоки:

  •  входной поток ФОРМА ЗАПРОСА
  •  выходной поток КОМАНДЫ ЗАПРОСА.

Процесс 1.3.5 (ОСУЩЕСТВЛЯТЬ ПОИСК по проектно-сметной документации) осуществляет поиск данных по документации, содержит следующие потоки:

  •  входной поток ФОРМА ЗАПРОСА.
  •  выходной поток КОМАНДЫ ЗАПРОСА.

Процесс 1.4.1 (ОБРАБОТАТЬ ИНФОРМАЦИЮ) осуществляет обработку полученной информации:

  •  входные потоки – КОМАНДЫ, а также внешний входной поток ДАННЫЕ ПО УСЛУГАМ,
  •  выходные данные – ПРОТОКОЛ ОБСЛУЖИВАНИЯ И ОБРАБОТАННЫЕ ДАННЫЕ ПО УСЛУГАМ.

Процесс 1.4.2 (РАСПЕЧАТАТЬ ОБРАБОТАННЫЕ ДАННЫЕ) выдает отчет о выполненных услугах.

  •  входной поток – ОБРАБОТАННЫЕ ДАННЫЕ ПО ЗАПРОСАМ
  •  выходные потоки – ОТЧЕТ О ВЫПОЛНЕННЫХ ЗАПРОСАХ (часть потока ОТЧЕТ) и ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА (часть потока ПРОТОКОЛ ОБСЛУЖИВАНИЯ).

Процесс 1.3.5 может быть детализирован с помощью DFD 3-го уровня.

Процесс 1.3.5.1 (ОСУЩЕСТВЛЯТЬ ПОИСК ПО НАЗВАНИЮ ПРОЕКТНО-СМЕТНОЙ ДОКУМЕНТАЦИИ) осуществляет поиск документов по всем объектам, сооружениям и коммуникациям, содержит следующие потоки:

- входной поток – ФОРМА ЗАПРОСА;

 - выходной поток КОМАНДЫ ЗАПРОСА.

Рис. 2.7. DFD диаграмма третьего уровня

Процесс 1.3.5.2 (ОСУЩЕСТВЛЯТЬ ПОИСК ПО ШИФРУ ПРОЕКТНО-СМЕТНОЙ ДОКУМЕНТАЦИИ) осуществляет поиск документов по его шифру, по всем объектам, сооружениям и коммуникациям, содержит следующие потоки:

           - входной поток – ФОРМА ЗАПРОСА;

           - выходной поток КОМАНДЫ ЗАПРОСА.

Процесс 1.3.5.3 (ОСУЩЕСТВЛЯТЬ ПОИСК ПО  ИНСТИТУТАМ) осуществляет поиск документов по проектным институтам, содержит следующие потоки:

           - входной поток – ФОРМА ЗАПРОСА;

           - выходной поток КОМАНДЫ ЗАПРОСА.

Процесс 1.3.5.4 (ОСУЩЕСТВЛЯТЬ ПОИСК ПО ЦЕЛЕВЫМ ПРОГРАММАМ) осуществляет поиск документов по целевым программам, содержит следующие потоки:

           - входной поток – ФОРМА ЗАПРОСА;

           - выходной поток КОМАНДЫ ЗАПРОСА.

Процесс 1.3.5.5 (ОСУЩЕСТВЛЯТЬ ПОИСК ПО ГОДАМ) осуществляет поиск документов по годам создания документации, содержит следующие потоки:

           - входной поток – ФОРМА ЗАПРОСА;

           - выходной поток КОМАНДЫ ЗАПРОСА.

2.5 Моделирование данных

2.5.1 Выбор модели данных

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

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

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

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

К основным понятиям сетевой модели базы данных относятся: уровень, элемент (узел), связь.

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

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

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

каждый элемент таблицы - один элемент данных

все ячейки в столбце таблицы однородные, то есть все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д.)

каждый столбец имеет уникальное имя

одинаковые строки в таблице отсутствуют

порядок следования строк и столбцов может быть произвольным

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

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

Некоторые объектно-ориентированные базы данных разработаны для плотного взаимодействия с такими объектно-ориентированными языками программирования как Python, Java, C#, Visual Basic .NET, C++, Objective-C и Smalltalk; другие имеют свои собственные языки программирования. ООСУБД используют точно такую же модель, что и объектно-ориентированные языки программирования.

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

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

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

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

2.5.2 Концептуальная модель базы данных

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

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

Для представления концептуальной модели применяются диаграммы "Сущность-связь".

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

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

Каждый экземпляр сущности должен быть отличим от любого другого экземпляра той же сущности.

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

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

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

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

Каждая связь может иметь один из следующих типов связи: один - к - одному, один - ко - многим, многие - ко - многим.

Связь типа один - к - одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой).

Связь типа один - ко - многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны "один") называется родительской, правая (со стороны "много") - дочерней.

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

Каждая связь может иметь одну из двух модальностей связи: может и должен.

Концептуальная модель данных представлена на рисунке 2.8.

На концептуальной модели можно выделить две основные сущности: «пользователь» и «проект».

Атрибуты сущности «Пользователь» отражают все данные, которые необходимо хранить о пользователе:

-    фамилию, имя

роль пользователя

пароль пользователя

логин пользователя

ID пользователя

Атрибуты сущности «Проект» отражают все данные, которые необходимо хранить о проекте:

ID проекта

дату проекта

название

дату создания

целевую программу

номер стеллажа

номер комнаты

стоимость проекта

описание

статус проекта

институт

номер полки

папка

сроки проектирования

ID пользователя

Сущности «пользователь» и «сессия» соединены связью один – ко – многим. Эта связь отражает,  что один пользователь может совершать много сессий. Кроме того сущность «пользователь» включает сущность «выдача».

Где можно узнать кому, когда, какое количество и какой документ был выдан.

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

2.5.3 Логическая модель базы данных

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



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

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

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

- пользователь

- роль

- история

- сессия

- проект

- выдача

- подраздел

- раздел

- целевая программа

- институт

- статус

- тип документа

- документ


ГЛАВА 3. ТЕХНИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

3.1 Выбор инструментальных средств разработки

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

3.1.1. Microsoft SQL Server

Microsoft SQL Server - система управления реляционными базами данных (СУБД), разработанная корпорацией Microsoft. Основной используемый язык запросов - Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями. Используется для работы с базами данных размером от персональных до крупных баз данных масштаба предприятия; конкурирует с другими СУБД в этом сегменте рынка. SQL Server 2008 упрощает инфраструктуру, поддерживаемую ИТ-подразделениями, предоставляя защищённую, масштабируемую и управляемую платформу доступа к корпоративным данным и сокращая время простоя приложений.

Сервер баз данных Microsoft SQL Server в качестве языка запросов использует версию языка SQL, получившую название Transact-SQL (сокращённо T-SQL). Язык T-SQL является реализацией SQL-92 (стандарт ISO для языка SQL) с множественными расширениями. T-SQL позволяет использовать дополнительный синтаксис для хранимых процедур и обеспечивает поддержку транзакций (взаимодействие базы данных с управляющим приложением).

При взаимодействии с сетью Microsoft SQL Server и Sybase ASE используют протокол уровня приложения под названием Tabular Data Stream (TDS, протокол передачи табличных данных). Протокол TDS также был реализован в проекте FreeTDS с целью обеспечить различным приложениям возможность взаимодействия с базами данных Microsoft SQL Server и Sybase.

Для обеспечения доступа к данным Microsoft SQL Server поддерживает Open Database Connectivity (ODBC) - интерфейс взаимодействия приложений с СУБД. Версия SQL Server 2005 обеспечивает возможность подключения пользователей через веб-сервисы, использующие протокол SOAP. Это позволяет клиентским программам, не предназначенным для Windows, кроссплатформенно соединяться с SQL Server. Компания Microsoft также выпустила сертифицированный драйвер JDBC, позволяющий приложениям под управлением Java (таким как BEA и IBM WebSphere) соединяться с Microsoft SQL Server 2000 и 2005.

Также SQL Server поддерживает зеркалирование и кластеризацию баз данных. Кластер сервера SQL - это совокупность одинаково конфигурированных серверов; такая схема помогает распределить рабочую нагрузку между несколькими серверами. Все сервера имеют одно виртуальное имя, и данные распределяются по IP-адресам машин кластера в течение рабочего цикла. Также в случае отказа или сбоя на одном из серверов кластера доступен автоматический перенос нагрузки на другой сервер.

SQL Server поддерживает избыточное дублирование данных по трем сценариям:

Снимок: Производится «снимок» базы данных, который сервер отправляет получателям. История изменений: Все изменения базы данных непрерывно передаются пользователям.

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

В SQL Server 2005 встроена поддержка .NET Framework. Благодаря этому хранимые процедуры БД могут быть написаны на любом языке платформы .NET, используя полный набор библиотек, доступных для .NET Framework, включая Common Type System (система обращения с типами данных в Microsoft .NET Framework). Однако, в отличие от других процессов, .NET Framework, будучи базисной системой для SQL Server 2005, выделяет дополнительную память и выстраивает средства управления SQL Server вместо того, чтобы использовать встроенные средства Windows. Это повышает производительность в сравнении с общими алгоритмами Windows, так как алгоритмы распределения ресурсов специально настроены для использования в структурах SQL Server.

3.1.2. MySQL

MySQL - реляционная свободная система управления базами данных. MySQL является собственностью компании Oracle Corporation, получившей её вместе с поглощённой Sun Microsystems, осуществляющей разработку и поддержку приложени. Распространяется под GNU General Public License или под собственной коммерческой лицензией. Помимо этого разработчики создают функциональность по заказу лицензионных пользователей, именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.

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

Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц.

3.1.3. Microsoft Office Access

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

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

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

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

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

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

MS Access является файл-серверной СУБД и потому применима лишь к маленьким приложениям. Отсутствует ряд механизмов, необходимых в многопользовательских БД, таких, например, как триггеры.

Существенно расширяет возможности MS Access по написанию приложений механизм связи с различными внешними СУБД: "связанные таблицы" (связь с таблицей СУБД) и "запросы к серверу" (запрос на диалекте SQL, который "понимает" СУБД).

Из всего выше сказанного следует что СУБД Microsoft Access предназначена для обработки малых объёмов данных; также, она поддерживает свой собственный стандарт языка SQL, не соответствующий стандарту SQL 92 и имеет файл-серверную архитектуру. Является коммерческим (платным) ПО. На основании этого, можно заключить, что для выполнения поставленных задач эта СУБД не подходит.

Microsoft SQL Server является серьёзной СУБД, предназначенной для обработки значительных объёмов данных и управления корпоративными БД. Имеет большой набор функций, полностью поддерживает стандарт SQL 92. Однако, SQL Server  является коммерческим (платным) ПО, что, на фоне наличия у бесплатного MySQL практически того же набора функций, является достаточным основанием для отказа от использования этой СУБД.

Выбор остановлен на СУБД MySQL в силу ряда причин [1]:

- хорошо зарекомендовавшая себя решениями для организации и управления БД.

- более высокая производительность (по сравнению с другими СУБД);

- большой набор функций, который в дальнейшем позволит расширение функциональности ПО, которое использует эту СУБД;

- меньшая ресурсоёмкость при более высокой производительности.

3.1.4. Язык программирования C++

Язык программирования C++ - компилируемый статически типизированный язык программирования общего назначения. Поддерживая разные парадигмы программирования, сочетает свойства как высокоуровневых, так и низкоуровневых языков. В сравнении с его предшественником - языком C, - наибольшее внимание уделено поддержке объектно-ориентированного и обобщённого программирования. Являясь одним из самых популярных языков программирования, C++ широко используется для разработки программного обеспечения. Область его применения включает создание операционных систем, разнообразных прикладных программ, драйверов устройств, приложений для встраиваемых систем, высокопроизводительных серверов, а также развлекательных приложений (например, видеоигры). Существует несколько реализаций языка C++ — как бесплатных, так и коммерческих. Их производят Проект GNU, Microsoft, Intel и Embarcadero (Borland). C++ оказал огромное влияние на другие языки программирования, в первую очередь на Java и C#.

При создании C++ Бьёрн Страуструп стремился сохранить совместимость с языком C. Множество программ, которые могут одинаково успешно транслироваться как компиляторами C, так и компиляторами C++, довольно велико — отчасти благодаря тому, что синтаксис C++ был основан на синтаксисе C.

C++ имеет достаточно большое количество библиотек готового кода, среди которых особенно выделяются Boost и std, последняя является частью стандарта языка.

3.1.5. Язык программирования  C#

Язык программирования  C# - объектно-ориентированный язык программирования. Разработан в 19982001 годах группой инженеров Microsoft как основной язык разработки приложений для платформы Microsoft .NET Framework.

C# относится к семье языков с C-подобным синтаксисом, из них его синтаксис наиболее близок к C++ и Java. Язык имеет статическую типизацию, поддерживает полиморфизм, перегрузку операторов (в том числе операторов явного и неявного приведения типа), делегаты, атрибуты, события, свойства, обобщённые типы и методы, итераторы, анонимные функции с поддержкой замыканий, LINQ, исключения, комментарии в формате XML.

Переняв многое от своих предшественников - языков C++, Java, Delphi, Модула и Smalltalk - С#, опираясь на практику их использования, исключает некоторые модели, зарекомендовавшие себя как проблематичные при разработке программных систем, например, C# не поддерживает множественное наследование классов (в отличие от старого языка программирования C++).

3.1.6. Встроенный язык программирования 1С

Встроенный язык программирования 1С - язык программирования, который используется в семействе программ «1С:Предприятие». Данный язык является предварительно компилируемым предметно-ориентированным языком высокого уровня. Средой исполнения языка является программная платформа «1С:Предприятие». Визуальная среда разработки («Конфигуратор») является неотъемлемой частью пакета программ «1С:Предприятие».

Диалекты языка для платформ 1С 7 версий (7.0, 7.5, 7.7) совместимы «снизу вверх» с незначительными исключениями. Языки для платформ 1С:7х и 1С:8х совместимы по основным операторам, но значительно отличаются в работе с прикладными объектами, вследствие чего перенос кода из 1С:7х в 1С:8х не имеет смысла.

Встроенный язык 1С:8 наиболее подобен по своему синтаксису языку Visual Basic. Платформой предоставляется фиксированный набор базовых классов, ориентированных на решение типовых задач прикладной области:

- Константа,

- Справочник,

- Документ,

- Журнал документов,

- Перечисление,

- Отчет,

- Обработка

- План счетов и др.

На основании базовых классов средствами визуального конфигурирования можно создавать любое количество порождённых классов (возможность определить новый класс программно — отсутствует). Допускается только одна явная ступень наследования классов. Как правило, объекты порождённых классов представляют собой записи (или некоторые наборы записей) в базе данных. Такие классы образуют «Дерево метаданных». В терминах встроенного языка программирования 1С такие классы называются объектами метаданных.

Основными видами объектов метаданных являются: Справочники, Документы, Отчеты, Обработки, Планы видов характеристик, Планы счетов, Планы видов расчета, Регистры сведений, Регистры накопления, Регистры расчета, Бизнес-процессы, Задачи.

Язык разработки, который будет применён для реализации спроектированного ПО, должен отвечать следующим требованиям:

- достаточно высокий уровень поддерживаемых абстракций;

- наличие развитой библиотеки стандартных классов;

- применимость к решению задач общего плана.

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

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

Выбор между C++ и C# в данном случае является достаточно простым и складывается в пользу C# по ряду причин:

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

- наличие более простого синтаксиса;

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

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

Для программирования на языке C# наиболее распространённой и удобной является среда разработки (IDE) Microsoft Visual Studio. Microsoft Visual Studio — линейка продуктов компании Майкрософт, включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств.

Microsoft Visual Studio 2010 — наиболее полный набор инструментов управления жизненным циклом приложений, гарантирующий отличные результаты на всех этапах разработки: от дизайна до развёртывания. Среди возможностей, реализованных в Visual Studio 2010, отмечается новый редактор, построенный на основе Windows Presentation Foundation, и интеллектуальное расширение, распознающее, что программист пытается сделать, а затем автоматически подставляющее нужный код.

В Visual Studio 2010 появились инструменты разработки под новейшую Windows 7 и «облачную» платформу Windows Azure. Обеспечена полная поддержка технологии Silverlight 2. В интегрированную среду разработки на C++ введена поддержка параллельных вычислений, «облачных» веб-сервисов и сервис-ориентированной архитектуры. Для управления циклом разработки приложений расширены инструменты взаимодействия и сотрудничества в версии Visual Studio 2010 Team System. Появилась возможность создания приложений для платформы SharePoint.

С помощью усовершенствований в интегрированной среде разработки (IDE) программисты могут эффективней применять свои знания при создании современных приложений, полностью отвечающих потребностям пользователей. Новый механизм привязки данных средствами drag-and-drop в технологии Silverlight и WPF, инструменты для разработки с использованием функций новой операционной системы Windows 7 – всё это создано специально, чтобы разработчики могли воплощать в действительность свои самые удивительные идеи. После внедрения новых технологий командной разработки Microsoft стало возможным более быстро и качественно осуществлять реализацию программного обеспечения по новым проектам за счёт автоматизации и стандартизации самого процесса коллективной разработки.

3.2 Физическая модель данных

На физическом этапе проектирования производится разработка БД с учётом конкретной выбранной СУБД: полям присваиваются имена, определяются типы полей, которые поддерживаются выбранной СУБД.

Физическая модель данных создается для преобразования логической модели данных в физическую реализацию с помощью выбранной СУБД. На основе построенной логической модели данных создана физическая структура базы данных, которая показана на рисунке 3.1. Физическая модель базы данных подробно описана в таблицах 3.1 – 3.13.

Структура таблиц базы данных, описывающих пользователей системы и их роли, приведена в таблицах 3.1 – 3.3.

Таблица 3.1 Структура таблицы «User»

Имя поля

Тип данных

Ключ

Описание

ID

int

PK

Идентификатор

Fistname

varchar(128)

Фамилия пользователя

RoleID

int

FK

Ссылка на роль

Lastname

varchar(128)

Имя пользователя

Password

varchar(128)

Пароль

Login

varchar(128)

Логин пользователя



Таблица 3.2 – Структура таблицы «Role»

Имя поля

Тип данных

Ключ

Описание

ID

int

PK

Идентификатор

Role

varchar(128)

Описание роли

Таблица 3.3 – Структура таблицы «Session»

Имя поля

Тип данных

Ключ

Описание

ID

int

PK

Идентификатор

UserID

varchar(128)

FK

Связь с таблицей «user»

DateStart

varchar(128)

Дата начала работы

DateEnd

varchar(128)

Дата окончания работы

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

Таблица 3.4 Структура таблицы «Section»

Имя поля

Тип данных

Ключ

Описание

ID

int

PK

Идентификатор

UserID

int

FK

Связь с таблицей «user»

ProjectID

int

FK

Связь с таблицей «project»

Data

varchar(128)

Дата добавления

DataCreat

varchar(128)

Дата создания

Name

varchar(128)

Название

Survay

varchar(128)

Изыскания

Duplicate

varchar(128)

Копия

Таблица 3.5 – Структура таблицы «Institute»

Имя поля

Тип данных

Ключ

Описание

ID

int

PK

Идентификатор

Institute

varchar(128)

Описание института

Таблица 3.6 Структура таблицы «Project»

Имя поля

Тип данных

Ключ

Описание

ID

int

PK

Идентификатор

UserID

int

FK

Связь с таблицей «user»

ProgrammingID

int

FK

Связь с таблицей «programming»

InstituteID

int

FK

Ссылка на институт

StatusID

int

FK

Ссылка на статус проекта

Name

varchar(128)

Название проекта

Имя поля

Тип данных

Ключ

Описание

Date

varchar(128)

Дата начала проектирования

DateCreate

varchar(128)

Дата добавления проекта

Shelf

varchar(128)

Полка

Rock

varchar(128)

Стеллаж

Room

varchar(128)

Комната

Srok

varchar(128)

Срок проектирования

Cost

varchar(128)

Стоимость проектирования

Description

text

Описание

Folder

varchar(128)

Папка

Таблица 3.7 Структура таблицы «History»

Имя поля

Тип данных

Ключ

Описание

ID

int

PK

Идентификатор

UserID

int

FK

Связь с таблицей «user»

ProjectID

int

FK

Связь с таблицей «project»

Data

varchar(128)

Дата выполнения

Action

varchar(128)

Действие

Description

text

Описание

Таблица 3.8 – Структура таблицы «Status»

Имя поля

Тип данных

Ключ

Описание

ID

int

PK

Идентификатор

Status

varchar(128)

Статус проектирования

Таблица 3.9 Структура таблицы «Subsection»

Имя поля

Тип данных

Ключ

Описание

ID

int

PK

Идентификатор

UserID

int

FK

Связь с таблицей «user»

SectionID

int

FK

Связь с таблицей «section»

Data

varchar(128)

Дата добавления

DataCreat

varchar(128)

Дата создания

Name

varchar(128)

Название

Survay

varchar(128)

Изыскания

Duplicate

varchar(128)

Копия

Таблица 3.10 Структура таблицы «Document»

Имя поля

Тип данных

Ключ

Описание

ID

int

PK

Идентификатор

SectionID

int

FK

Связь с таблицей «section»

SubsectionID

int

FK

Связь с таблицей «subsection»

UserID

int

FK

Связь с таблицей «user»

TypeID

int

FK

Связь с таблицей «type»

Date

varchar(128)

Дата добавления

DateCreate

varchar(128)

Дата создания

Name

varchar(128)

Название

Path

varchar(128)

Путь хранения

Comment

text

Комментарии

Duplicate

varchar(128)

Копии

Таблица 3.11 – Структура таблицы «Type»

Имя поля

Тип данных

Ключ

Описание

ID

int

PK

Идентификатор

Type

varchar(128)

Описание типа

Таблица 3.12 Структура таблицы «Issued»

Имя поля

Тип данных

Ключ

Описание

ID

int

PK

Идентификатор

UserID

int

FK

Связь с таблицей «user»

DocumentID

int

FK

Связь с таблицей «document»

Date

varchar(128)

Дата выдачи

User

varchar(128)

Кому выдано

Count

varchar(128)

Количество документов

ReturnUserId

int

Кто принял документ

ReturnDate

varchar(128)

Дата возврата документа

ReturnUser

varchar(128)

Кто вернул документ

Таблица 3.13 – Структура таблицы «Programm»

Имя поля

Тип данных

Ключ

Описание

ID

int

PK

Идентификатор

Programm

varchar(128)

Описание целевой программы

3.3. Алгоритмы обработки информации

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

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

- процедура поиска документации.

3.3.1. Алгоритм аутентификации

В информационно – справочной системе архива проектно-сметной документации реализован механизм аутентификации, который подразумевает проверку подлинности пользователя путём сравнения введённого им пароля с паролем в базе данных пользователей. Общий алгоритм аутентификации пользователя приведен на рисунке 3.2.

Аутентификация реализует следующий общий алгоритм:

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

происходит инициализация слоя работы с БД;

осуществляется поиск записи в БД с введенными значениями;

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

3.3.2 Алгоритм поиска документации

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

Алгоритм поиска документации выводит дерево результатов поиска. Оно отображает искомую документацию, с помощью стандартной компоненты платформы WinForms - TreeView.

Процедура поиска проектно – сметной документации осуществляет поиск по следующему алгоритму:

- происходит инициализация слоя с работы с БД;

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

- выбирается объект поиска, критерий поиска;

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

- в конце отображается дерево результатов поиска.


Рисунок 3.2 – Алгоритм механизма аутентификации


3.5 Интерфейс пользователя

Для более детального представления диалога пользователя с подсистемой была разработана структура диалога пользователя, которая показана на рисунке 3.4.

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

Рис. 3.5. Вход в систему

На рисунке 3.6 показана главная форма программы. В самом верху расположено главное меню программы, в котором отражены пункты:

- «Файл»;

- «Вид»;

-  «Администрирование»;

- «Справочники»;

- «Операции».

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

- нового проекта;

- нового раздела;

- нового подраздела;

- нового документа.


Рисунок 3.4. Структура диалога пользователя в информационно – справочной системе


Рис. 3.6 Главная форма системы

При открытии формы «Новый проект» пользователю необходимо заполнить обязательные поля:

- название проекта;

- идентификационный номер проекта;

- дата создание проекта;

- целевая программа, в которую входит проект;

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

- номер комнаты, стеллажа, полки где находится проект;

- стоимость проекта;

- срок выполнения проекта.

Необязательным является поле описание проекта. В этом поле пользователь системы может написать дополнительную информацию о проекте. На рисунке 3.7 представлена форма добавления нового проекта.

Рис.3.7. Форма добавления нового проекта

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

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

- название раздела;

- тип документации (рабочая/проектная документация);

- количество имеющихся копий раздела;

- дата добавления раздела.

Форма добавления нового раздела приведена на рисунке 3.8.

Рис.3.8. Форма добавления нового раздела

Кнопки сохранить и отмена аналогичны форме добавления нового проекта.

Документация добавляется в раздел формате «pdf». Форма имеет следующие поля:

- название документа;

- идентификационный номер документа;

- дата добавления документа;

- количество имеющихся копий;

- комментарии.

На рисунке 3.9 представлена форма добавления нового документа.

Рис. 3.9. Форма добавления нового документа

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

Форма управления пользователями представлена на рисунке 3.10.

Рис. 3.10. Форма управления пользователями

В этой форме можно осуществлять следующие действия:

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

- Удаление пользователя;

- Редактирование информации о пользователе.

Форма добавления/редактирования, представленная на рисунке 3.11, имеет следующие поля:

Рис. 3.11. Форма добавления нового пользователя

- Имя пользователя;

- Фамилия пользователя;

- Логин пользователя;

- Пароль пользователя;

- Роль пользователя (администратор, пользователь, гость);

Кнопки сохранить и отмена аналогичны форме добавления нового проекта.

Меню справочники представлено на рисунках 3.12-3.14. Оно содержит сведения о институтах, целевых программах и статусе проекта.

Рис.3.12. Форма справочники (целевые программы)

Рис.3.13. Форма справочники (институты)

Рис.3.14. Форма справочники (статусы проекта)

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

Добавить;

Редактировать.

Каждая проектно – сметная документация может выдаваться работнику ООО «РН – Ставропольнефтегаз». Для того чтобы можно было отслеживать кому (кем), когда и какая документация была выдана (возвращена) в информационно – справочной системе предусмотрена форма журнала регистрации документации которая показана на рисунке 3.15

Рис.3.15 Форма журнала регистрации

На рисунке 3.16 приведена форма история изменений.

Рис.3.16. Форма история изменений

На этой форме можно просмотреть в какой проектно – сметной документации, когда  и кем была добавлена (изменена) необходимая документация.

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

Рис. 3.17. Форма поиска проектно – сметной документации

3.6 Тестирование программного обеспечения информационно – справочной системы архива проектно – сметной документации

Для информационно - справочной системы архива проектно – сметной документации требуется провести проверку функциональных требований технических заданий. Чтобы удостовериться в работоспособности и соответствии определённым требованиям программы в целом и ее отдельных частей систему нужно протестировать.

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

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

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

Тестовый случай (англ. TestCase) - это описание совокупности шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

Под тест - кейсом понимается структура вида:

Действие -> Ожидаемый результат -> Результат теста.

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

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

Результат теста – описывается, удачно или неудачно закончился тест.

Тест - кейсы разделяются по ожидаемому результату на позитивные и негативные:

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

Существует достаточно много различных структур тест кейсов. В большинстве случаев тест-кейс состоит из трех частей. Структура типового тест кейса представлена в таблице 3.14.

Совокупность всех тестовых случаев по программному обеспечению информационно – справочной системы образует основу тест-плана.

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

Таблица 3.14 – Структура тест кейса

Имя раздела

Описание раздела

Предусловия

Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки.

Описание тест кейса

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

Постусловия

Список действий, переводящих систему в первоначальное состояние.

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

  1.  Объект тестирования. Этот пункт включает описание объекта тестирования: системы, приложения;
  2.  Функциональность объекта тестирования. Этот пункт должен включает список функций и описание тестируемой системы и ее компонент в отдельности;
  3.  Тест кейсы. Этот пункт включает стратегию тестирования, а именно описание тестовых случаев и их применение по отношению к тестируемому объекту;
  4.  Время проведения тестирования. Включает последовательность проведения работ: подготовка (англ.TestPreparation), тестирование (англ.Testing), анализ результатов (англ.TestResultAnalisys ) в разрезе запланированных фаз разработки;
  5.  Критерии начала тестирования – законченность разработки требуемого функционала, наличие всей необходимой документации;
  6.  Критерии окончания тестирования – результаты тестирования удовлетворяют критериям качества продукта, требования к количеству открытых багов выполнены.

Примеры тест- кейсов для информационно – справочной системы архива проектно – сметной документации представлены в таблицах 3.15-3.16.

Таблица 3.15 – Тест кейс входа в систему

ID

EMT100.1.1-2-1. Log In.

Type of tested section

Text fields “User”, “Password”, button “Login”.

General data

User: test.

Password: test.

Actions

Enter user.

Enter password.Click button “Login”.

Expected result

“MainForm” pagecorrectlyopened.The project tree node correctly loaded.

Тест кейс входа в систему проверяет реализацию в системе механизма аутентификации.

Таблица 3.16 – Тест кейс добавления нового проекта документации

ID

EMT110.1.1-2-1. Add a new project.

Type of tested section

Button “Save”.

General data

Name: test.

Number: 0001.

Date: 14.05.2012.

Programm: test programm.

Institute: test institute.

Status: test status.

Shelf: 1.

Actions

  1.  Open “Add a new project” form.
  2.  Fill all necessary fields.
  3.  Click a “Save” button.

Expected result

A project is correctly added and saved.

Тест кейс  добавления нового проекта проверяет реализацию функции добавления информации о новом проекте в систему.


4. ОРГАНИЗАЦИОННО - ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ПРОЕКТА

4.1 Технико-экономическое обоснование необходимости разработки системы управления проектами

Одной из основных задач отдела перспективного планирования и организации проектных работ ООО «РН - Ставропольнефтегаз» является обеспечение объектов капитального строительства проектно-сметной документацией (ПСД).

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

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

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

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

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

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

4.2 Календарное планирование

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

Общая трудоемкость проектирования (чел.-дн.) распределяется по работам (этапам) выполнения с использованием формул для расчета ожидаемой продолжительности выполнения работ (tОЖ, чел.-дн.).

 ,

где     tmin, tmax - минимальная и максимальная продолжительности отдельной работы, чел.-дн..

Перечень проектных работ и расчет ожидаемой трудоемкости приведен в таблице 4.1.

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

Таблица 4.1 – Трудоемкость проектных работ

№ п/п

Наименование работы

Оценка трудоемкости,
чел.-дн.

tmin

tmax

tож

1

Постановка задачи

10

15

12

2

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

12

17

14

3

Выбор метода решения задачи

17

22

19

4

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

22

27

24

5

Проектирование базы данных

25

35

29

6

Изучение технологий проектирования приложений

22

27

24

7

Разработка форм диалога

25

35

29

8

Подбор инструментальных средств программирования

42

52

46

9

Написание программных модулей

102

138

117

10

Отладка программных модулей

42

62

50

11

Тестирование программы

22

32

26

12

Составление документации

15

20

17

13

Подготовка и установка системы

15

20

17

14

Общая трудоемкость

371

502

424

4.3 Организационный, юридический и финансовый аспекты разработки информационно - справочной системы

Данная тема выполнялась одним разработчиком, основная квалификация которого – программист, имеющий определенный опыт работы в предметной области. Для разработки проекта требовались знания языка С#,  а также принципов работы СУБД MY SQL. Проект выполнялся по заказу предприятия  “ООО РН - Ставропольнефтегаз”. Со стороны заказчика

Рисунок 4.1 – Календарный план работ по проектированию автоматизированной системы расчетов

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

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

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

Разработка финансировалась управляющей компанией “ООО РН-Ставропольнефтегаз” и выполнялась с целью последующей установки в офисе управляющей компании.

Расчеты стоимости проекта приведены в разделе 4.4, расчеты цены изделия приведены в разделе 4.5.

4.4 Стоимостная оценка проекта

Все цены и расценки взяты на апрель 2012 г. Стоимостная оценка проекта рассчитывается по формуле

,                         (4.2)

где СТР– оценка труда разработчика темы, руб.;

СОТЛ – затраты на отладку программного обеспечения, руб.;

СЭВМ – затраты на доукомплектование ЭВМ техническими средствами, если они приобретались специально для выполнения этого проекта      (СЭВМ=0 руб.);

СП – прочие затраты, руб.

Оценка труда разработчика задачи может быть определена исходя из должностного оклада О (О = 7462,5 руб/мес.) и периода проектирования ТПР, взятого по фактическим данным из рисунка 4.1 (ТПР = 424 дн.) по формуле:

,

где О – должностной оклад разработчика в день (7462,5/21,2=352 руб./дн.);

ТПР – фактический период проектирования в днях, взятый из       рисунка 4.1 (424дн.);

ПД – процент дополнительной заработной платы (10 %);

ППФ - отчисления в пенсионный фонд РФ-ПРФ (22%);

ПСС - отчисления  в фонд социального страхования - ФСС (2,9%);

ПФМС - отчисления в федеральный фонд обязательного медицинского страхования - ФФОМС (5,1%);

ПНК – процент накладных расходов (10 %).

Тогда:

руб.

Стоимостная оценка использования ЭВМ при проектировании проводится по формуле:

СОТЛ  = ТОТЛ ∙ СМЧ,                    (4.3)

где ТОТЛ – время отладки на ЭВМ (ч.);

СМЧ  – стоимость машино-часа работы ЭВМ (руб.).

Время отладки на ЭВМ, взято из  графика рисунка 4.1 как сумма фактических времен всех работ, связанных с использованием ЭВМ:

ТОТЛ = 398×4 = 1592 ч.

Стоимость машино-часа работы ЭВМ можно определить исходя из эксплуатационных расходов, связанных с использованием вычислительной техники:

,            (4.4)

где  ЗЭКСПЛ – суммарные эксплуатационные затраты за год работы ЭВМ (руб.);

      ТД – действительный фонд времени работы ЭВМ за год (ч.).

Для определения действительного фонда времени за год определим номинальный фонд:

,

где КД – количество дней в году (366);

КВ – количество выходных в неделе (2);

КП – количество праздничных дней в году (12);

ТСМ – продолжительность рабочего дня (4 ч.);

КСМ – коэффициент сменности (2).

Тогда:

ч/год

Исходя из номинального фонда времени за год, определим действительный фонд времени за год по формуле:

,

где  – процент потерь рабочего времени, связанных с профилактикой и ремонтом ЭВМ (5 %);

        ТН – номинальный фонд времени (ч/год).

В результате получаем:

ч/год

Суммарные эксплуатационные затраты за год работы ЭВМ можно определить по формуле:

,                          (4.5)

где ЗТР – затраты на оплату труда персонала, обслуживающего             ЭВМ (руб./год);

ЗПОМ – затраты на содержание помещения под размещение вычислительной техники (руб./год);

ЗЭН – затраты на электроэнергию (руб./год);

ЗАМ – амортизационные отчисления от стоимости ЭВМ (руб./год);

ЗМ – затраты на материалы (носители информации) (руб./год);

ЗР – затраты на ремонт (руб./год).

Затраты на оплату труда персонала, обслуживающего ЭВМ, определяются по формуле:

,

где O– доля месячного оклада работника за обслуживание одной       ЭВМ, руб.

Проект выполнялся на ЭВМ, на обслуживание которой выделяется   300 руб./мес., т.о. O = 300 руб./мес., тогда:

Так как проект выполнялся на предприятии ООО «РН - Ставропольнефтегаз», то затраты на содержание помещения отсутствуют, т.е. ЗПОМ=0.

Расчет затрат, связанных с потреблением силовой электроэнергии, выполняется по формуле:

,

где М – паспортная мощность ЭВМ (М = 0,3 кВт);

ТД – действительный фонд времени работы ЭВМ в течение года, ч.;

КИ – коэффициент интенсивного использования мощности (КИ = 0,9);

ЦЭ – цена одного кВт-ч энергии на момент выполнения расчета (ЦЭ = 3,9 руб/ кВт-ч).

Получим:

Амортизационные отчисления, затраты на материалы и ремонт вычисляются, исходя из балансной стоимости ЭВМ:

,

где ЦПР – цена приобретения ЭВМ,  руб.;

– коэффициент, характеризующий дополнительные затраты связанные с доставкой, монтажом и наладкой оборудования ( = 3 %).

ЭВМ, на которой выполнялась разработка, была приобретена за 17000 руб. В результате находим:

руб.

Амортизационные отчисления от балансовой стоимости ЭВМ

,

где НАМ – норматив амортизационных отчислений (НАМ = 33%).

В результате получаем:

руб./год,

Затраты на материалы и носители информации:

,

где Нм – норматив затрат на материалы и носители информации                    (Нм = 2 %).

руб./год,

Затраты на ремонт:

,

где НР – норматив затрат на ремонт (НР = 2 %).

руб./год,

По формуле (4.5) находим величину эксплуатационных затрат

руб./год

Результаты расчета эксплуатационных расходов приведены в таблице 4.2.

Таблица 4.2 – Смета эксплуатационных расходов по работе ЭВМ

Наименование статей затрат

Сумма, руб./год

Затраты на оплату труда обслуживающего персонала

5508

Затраты на электроэнергию

2000,7

Амортизационные отчисления

5778,3

Затраты на носители информации

350,2

Затраты на ремонт

350,2

Итого эксплуатационных расходов

13987,4

Исходя из эксплуатационных расходов по обеспечению работы ЭВМ, по формуле (4.4) находим стоимость машинного часа:

По формуле (4.3) находим стоимостную оценку использования ЭВМ при проектировании, исходя из суммарного фактического периода            1592 часов, взятого из таблицы 4.1:

руб./ч.

Также в процессе разработки были потрачены средства СП на услуги и материалы (таблица 4.3).

Таблица 4.3 – Прочие затраты

Наименование статей затрат

Сумма, руб.

1 пачка бумаги по 500 листов

130

Картридж черно-белый для струйного принтера

450

Канцелярские товары

120

Лазерные диски

100

Услуги интернета

450

Итого:

1250

Тогда стоимостная оценка проекта в соответствии с формулой (4.2) составит:

 руб.

Себестоимость проектирования приведена в таблице 4.4.

Таблица 4.4 – Себестоимость проектирования

Наименование статей затрат

Сумма, руб.

Расходы по оплате труда разработчика, в том числе:

228349,44

Затраты на отладку программного обеспечения

11717,12

Прочие затраты

1250

Итого себестоимость проекта

241316,56

4.4 Формирование цены разработки

Цену разработки, руб., определяли по следующей формуле:

,                             (4.7)

где СПР – стоимостная оценка проекта (руб.);

П – прибыль (руб.).

Прибыль рассчитывается с использованием норматива рентабельности по формуле:

,

где  – норматив рентабельности (%).

Получаем:

руб.

Тогда, в соответствие с формулой (4.7), получаем:

 руб.

Цена с учетом НДС определяется как

руб.

где  = 18% – ставка налога на добавленную стоимость.

4.5 Анализ экономической целесообразности внедрения объекта проектирования

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

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

Совокупные затраты, связанные с владением технологией (TCO) определяются следующим образом:

,

где СПР - себестоимость проекта, руб., которая делится на срок ТА морального старения для определения годовой доли, в данном случае

ТА = 3 года;

СЭКСПЛ – затраты на эксплуатацию системы, руб./год.

Так как предприятие работает с 8.00 до 17.00 часов, то пользователь может пользоваться программным продуктом в течение 8 часов в сутки. В соответствии с этим затраты на эксплуатацию СЭКСПЛ  определяются при условии ежедневного использования разработки в среднем в течение 3 часов с использованием данных о часовой заработной плате работника, занятого эксплуатацией (часовая заработная плата работника со стажем работы один год – 30 руб./час) и стоимость машино-часа работы ЭВМ при эксплуатации:

СЭКСПЛ = ТРАБТСМ ЗП + СМЧ),

где ТРАБ – количество рабочих дней в году;

 ТСМ – время ежедневной эксплуатации системы, ч.;

 СЗП – оплата пользователя системы за 1 час работ, руб.;

 СМЧ – стоимость одного  машинного часа работы ЭВМ         пользователя, руб.; СМЧ =10 руб./ч.

СЭКСПЛ =249∙3∙(30+10) = 29880 руб./год;

ТСО =241316,56/3 + 29880 = 110318,8 руб./год

Коэффициент отдачи с инвестированных средств (ROI) определяется по формуле:

ROI = [(PRS - TCO) / TCO]∙100 = [(150000-110318,8) /110318,8] ∙100 = 36%.

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


5 БЕЗОПАСНОСТЬ ЖИЗНЕДЕЯТЕЛЬНОСТИ

5.1 Обеспечение микроклимата на рабочем месте оператора информационной системы с учетом санитарных норм

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

Нормируемыми параметрами микроклимата на рабочем месте оператора информационной системы являются: температура воздуха; температура наружных поверхностей оборудования, стен; относительная влажность воздуха; интенсивность теплового облучения работников [6].

Характер выполняемой работы по тяжести определяется в зависимости от общих энергозатрат работника. Чем больше энергозатрат тратит работник на выполнение работы, тем более тяжелой считается эта работа. Тяжесть выполняемой работы оператора информационной системы можно отнести к категории “1б – лёгкие физические работы”, которая обозначает незначительное физическое напряжение с расходом энергии до 174 Вт [6].

5.1.1 Требования санитарных норм к микроклимату

При нормировании параметров микроклимата установлены два периода года – теплый и холодный. Теплый период – период года, когда среднесуточная температура наружного воздуха больше +10ºС. Холодный период – период года, когда среднесуточная температура наружного воздуха меньше +10 ºС [6].

Согласно категории работ «1б – легкие физические работы», выполняемых оператором информационной системы, микроклиматические условия на рабочих местах в помещениях с вычислительной техникой, соответствующие умеренно-континентальной климатической зоне, для холодного и теплого периодов года должны соответствовать требованиям, см. табл. 5.1 [7].

Таблица 5.1. Значения санитарных норм микроклимата на рабочем месте оператора информационной системы

Период года

Температура воздуха, °С

Относительная влажность, %

Скорость движения воздуха, м/с

опти-мальная

допус-тимая

опти-мальная

допус-тимая

опти-мальная

допус-тимая

Холодный

20-23

20-25

40-60

75

0,1

менее 0,1

Теплый

22-25

21-28

40-60

55

0,1

0,1-0,2

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

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

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

5.1.2 Расчет воздухообмена на рабочем месте оператора информационной системы с учетом санитарных норм

Расчет необходимого количества воздуха для помещения с тепловыделениями производится по избыткам явного тепла. Расход воздухообмена определим для теплого периода года, так как он позволит определить максимальное значение воздухообмена. Расчет приточного воздуха [8]:

где Q – избыточный  явный  и  полный  тепловые потоки в помещении, Дж/с;

    с – теплоемкость воздуха, равная 1,2 Дж/(кг) [6];

    – плотность воздуха, поступающего в помещение,  = 1,29 кг/м3 [8];

      – температура воздуха, удаляемого из помещения,  = 25   [см. санитарные нормы к микроклимату, табл. 5.1];

    – температура воздуха, подаваемого в помещение, = 20  [см. санитарные нормы к микроклимату, табл. 5.2].

Источниками выделения избыточного тепла являются работающие люди, нагретые поверхности системных блоков ЭВМ и солнечное тепло, поступающее сквозь оконные проемы [8]:

где  – тепло, выделяемое людьми, Дж/с ;

Qоб – тепло, выделяемое оборудованием, Дж/с ;

                Qс – солнечное тепло, поступающее сквозь оконные проемы,  Дж/с;

где – тепло, выделяемое человеком при работе и равное 45 Дж/с [8];

      n – количество человек, работающих в помещении, которое составляет 3 человек,

где m – количество ЭВМ, m = 3;

              Qсб  – тепло, выделяемое системным блоком одной ЭВМ, Дж/с;

где F – площадь поверхности оборудования;

где  hсб – высота системного блока, hсб = 0,33 м;

       xсб – ширина системного блока, xсб = 0,17 м;

       yсб – длина системного блока, yсб = 0,36 м,  

        R – сопротивление теплопередачи ограждающей конструкции,

R =  0,175  [8];

  – температура воздуха в ограждающей конструкции, для системного блока ЭВМ,  = 30 ;

 – температура воздуха в помещении,  = 20  [см. табл. 5.1],

где S – площадь оконных проемов, в данном случае S = 6,7 м2;

     k – коэффициент, зависящий от характеристики остекленения, для двойных стекол k = 1,15 [6];

   q – количество тепла, поступающего через 1 м2 оконного проема, в зависимости от ориентации по сторонам света, для северной ориентации равно 117 Дж/() [6],

Подачу такого объема наружного воздуха может обеспечить автономный бытовой кондиционер LG G07LH, характеристики которого следующие:

– воздухоподача – до ;

– потребляемая мощность – 2,4 кВт;

– масса – ;

– габариты – ;

– электроснабжение - переменный ток с напряжением .

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

5.2 Расчет естественного освещения на рабочем месте оператора информационной системы

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

Неудовлетворительное освещение ухудшает условия зрительной работы, повышает утомляемость глаз, нервной системы, снижает производительность труда, может стать причиной аварий, несчастных случаев или заболеваний. Хорошее освещение повышает производительность труда до 20%, снижает утомляемость за счет уменьшения психологических нагрузок, правильного цветового решения при окраске помещений, оборудования [6].

Характер зрительной работы по точности определяется минимальным размером объекта различения, контрастом объекта с фоном и свойствами фона. Работу оператора информационной системы можно отнести к работе с высокой точностью (наименьший размер объекта различения от 0,3 до 0,5 мм) что соответствует третьему разряду зрительных работ [9].

Нормируемой характеристикой естественного освещения является коэффициент естественной освещенности (КЕО). При боковом естественном освещении нормируется минимальное значение КЕО, а при верхнем и комбинированном освещении нормируется среднее значение КЕО. Коэффициент естественной освещенности – это отношение  естественной освещенности, создаваемой в некоторой точке заданной плоскости внутри помещения светом неба, к наружной горизонтальной освещенности, создаваемой светом полностью открытого небосвода [9].

В помещение, где находится рабочее место оператора информационной системы, естественное освещение должно осуществляться через окна и обеспечивать коэффициент естественной освещенности не ниже 1.5% [9]. Указанные значения КЕО нормируются для зданий, расположенных в III световом климатическом поясе [7].

Расчет естественного освещения осуществляется путем определения площади световых проемов.

Расчет необходимой площади световых проемов производится по формуле [6]:

где Sn – площадь рабочего помещения оператора информационной системы, Sn = 6 м2;

           Kз– коэффициент запаса (1,4  - для вертикально расположенного окна) [10];

              – нормированное значение КЕО [8]:

где  – значение КЕО для зданий, располагаемых в I группе административных районов по солнечным ресурсам ( = 1,5) [10];

                 mn – коэффициент светового климата, зависящий от номера группы административных районов по солнечным ресурсам, места расположения светового проема и его ориентации по сторонам света (для Ставропольского края и северной ориентации проемов  mn  = 0,8) [10];

             – световая характеристика окон (= 13) [6];

       – коэффициент затемнения окон противоположными зданиями (равен 1, так как затемнений нет);

       – коэффициент, учитывающий повышение КЕО при боковом освещении благодаря свету, отраженному от поверхности помещения и поверхности вокруг здания (1,5) [6];

                  – общий коэффициент светопропускания [6]:

где   – коэффициент светопропускания материала (0,8 для двойных стекол);

                 – коэффициент, учитывающий потери света в переплетах светопроема (0,65 – для двойного раздельного деревянного переплета);

                – коэффициент, учитывающий  потери света в несущих конструкциях (1 – при боковом освещении);

                 – коэффициент, учитывающий потери света в светозащитных устройствах (так как световые проемы ориентированы на север, необходимость в защитных устройствах отсутствует).

Площадь световых проемов в помещении равна:

где n – количество проемов, n = 2;

      l – длина одного проема, l = 1,8 м;

                h – высота одного проема, h = 2,1 м.

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

5.3     Эвакуация населения при чрезвычайных ситуациях

Одним из способов защиты населения в чрезвычайной ситуации (ЧС) является эвакуация населения.

Эвакуация - комплекс мероприятий по организованному вывозу, выводу из городов, других населенных пунктов, зоны возможного катастрофического затопления, тридцатикилометровой зоны вокруг АЭС и размещение в загородной зоне или безопасном районе всего населения в случае угрозы жизнедеятельности людей какой либо ЧС[9].

Загородная зона - это территория в пределах административных границ субъектов Российской Федерации, расположенная вне зон возможных разрушений (ЗВР), возможного опасного радиоактивного загрязнения (ЗВОРЗ), возможного опасного химического заражения (ЗВОХЗ), катастрофического затопления (ЗВКЗ), вне приграничных районов, заблаговременно подготовленная для размещения эвакуируемого населения по условиям его первоочередного жизнеобеспечения. 

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

В мирное время формируются следующие эвакоорганы:

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

- сборные эвакуационные пункты (СЭП) - городские и объектовые;

- эвакуационные приемные комиссии - при органах местного самоуправления;

-   промежуточные пункты эвакуации (ППЭ);

-   приемные эвакуационные пункты (ПЭП);

- оперативные группы (ОГ) - по организации вызова эваконаселения;

-   группы управления на маршрутах пешей эвакуации;

-  администрация пунктов посадки (высадки) населения на транспорт (с транспорта).

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

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

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

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

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

По предназначению средства индивидуальной защиты подразделяются на средства индивидуальной защиты органов дыхания (СИЗОД) и средства защиты кожи (СЗК).

К средствам индивидуальной защиты органов дыхания относятся противогазы, респираторы и простейшие средства защиты типа противопыльных тканевых масок и ватно-марлевых повязок.

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

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

Соответствующим образом необходимо подготовить к эвакуации детей. Подбирая одежду и обувь для детей, нужно учитывать их защитные свойства и время года. Для детей до 3 лет следует запасти детские продукты, которых в пунктах питания может не быть, - детское питание, сухое молоко, консервированные соки. Для детей дошкольного и младшего школьного возраста из продуктов питания лучше всего брать консервы, концентраты, сыры, сухари, печенье и другие не скоропортящиеся продукты, а также флягу с кипяченой водой. Все продукты должны быть упакованы в целлофановые пакеты. Дошкольникам необходимо, подготовить их любимые игрушку и книгу. К чемоданам (рюкзаками) с вещами и продуктами питания эвакуируемых детей надо прикрепить бирки, на которых разборчиво написать фамилию, имя и отчество ребенка, домашний адрес и пункт эвакуации. Аналогичные метки нужно сделать детям дошкольного возраста: во внутренний карман той одежды, в которой они обычно ходят, следует вложить карточку с указанием имени, отчества и фамилии ребенка, года рождения, место жительства и места работы отца или матери. Еще лучше написать эти сведения на кусочке белой материи и подшить его с внутренней стороны одежды ребенка под воротником. На сбор населения для эвакуации отводится  4 часа.

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

Эвакуация пешим порядком планируется на расстояние одного суточного перехода – 30 – 40 км. Для проведения эвакуации формируются колонны по 500 – 1000 человек. Средняя скорость движения колонны 4 – 5 км, ч, малые привалы через 1-1,5 часа на 10-15 минут, большой привал во второй половине суточного перехода на 1-2 часа. На приемных эвакопунктах эвакуируемые люди регистрируются и распределяются по населенным пунктам.

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

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

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

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

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

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

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

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

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

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

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

За эвакуацию в мирное время отвечает РСЧС, а в военное время эти функции берет на себя Гражданская оборона Российской Федерации.


ЗАКЛЮЧЕНИЕ

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

Разработанное приложение реализует следующие функции:

разграничение прав доступа к информационно – справочной системе архива проектно – сметной документации;

внесение/изменение проектно – сметной документации;

поиск необходимой документации по критериям;

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

учет выдачи и возврата проектно – сметной документации.

В разделе «Безопасность жизнедеятельности» Освещены вопросы по организации  и охране труда. Проведен расчет параметров для обеспечения оптимального микроклимата на рабочих местах специалистов отдела перcпективного планирования и организации проектных работ предприятия ООО «РН - Ставропольнефтегаз».

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

  1.  Фаулер М. Архитектура корпоративных программных приложений. – М.: Изд. дом "Вильямс", 2006. – 544с. . 
  2.  Троелсен Э. Язык программирования C# 2010 и платформа .NET4.0. – М.: Изд. дом "Вильямс", 2011. – 1392 с.
  3.  Джозеф C. Раттц-мл. LINQ язык интегрированных запросов в C# 2008 для профессионалов. – М.: Изд. дом "Вильямс", 2008. – 560 с.
  4.  Котляров В.П., Коликова Т.В. Основы тестирования программного обеспечения. – М.: БИНОМ. Лаборатория знаний, 2006. – 285с.
  5.  Зайцева И.В., Никитенко А.В. Методические указания по организационно-экономическому обоснованию технических решений с программным обеспечением. Новочеркасск: ЮРГТУ, 2005. - 38с.
  6.  Естественное и искусственное освещение. СНиП 23-05-95. – М.: Минстрой России, 1995 – 36с.
  7.  Фролов А.В. Практикум по безопасности жизнедеятельности: Учебное пособие для ВУЗов. – Ростов н/Д: Феникс, 2009 – 264с.
  8.  Отопление, вентиляция и кондиционирование. СНиП 2.04.05-91. – М.: Госстрой России, 2000 – 123 с.
  9.  Шупляк Н.Г. Основы защиты населения и территории в чрезвычайных ситуациях: Учебно–методическое пособие к изучению курса «Безопасность в ЧС». – Юж.-Рос. Гос.тех.ун-т-Новочеркасска: ЮРГТУ, 2004.

  10. Строительная климатология. СНиП 23-01-99. – М.: Госстрой России, 2000 – 57с.

 

ПРИЛОЖЕНИЕ А

(обязательное)

Исходные коды модулей

Серверная часть – слой доступа к данным

Файл «IUsersRepository.cs»:

using System.Collections.Generic;

using DomainModel.EF;

namespace DomainModel.Abstract

{

public interface IUsersRepository

   {

       IEnumerable<user> Users { get; }

       IEnumerable<role> Roles { get; }

void DeleteUser(int id);

void AddUser(user user);

void EditUser(user user);

   }

}

Файл «SqlUsersRepository.cs»:

using System.Collections.Generic;

using System.Linq;

using DomainModel.Abstract;

using DomainModel.EF;

namespace DomainModel.Concrete

{

   public class SqlUsersRepository : IUsersRepository

   {

       private readonly myarchiveEntities _context = new myarchiveEntities();

       public SqlUsersRepository()

       {

           _context = new myarchiveEntities();

       }

       public IEnumerable<user> Users

       {

           get { return _context.user.AsEnumerable(); }

       }

       public IEnumerable<role> Roles

       {

           get { return _context.role.AsEnumerable(); }

       }

       private void Save()

       {

           _context.SaveChanges();

       }

       public void DeleteUser(int id)

       {

           var editUser = _context.user.Where(x => x.id == id).FirstOrDefault();

           if (editUser != null)

           {

               _context.user.DeleteObject(editUser);

           }

           Save();

       }

       public void AddUser(user user)

       {

           _context.user.AddObject(user);

           Save();

       }

       public void EditUser(user user)

       {

           var editUser = _context.user.Where(x => x.id == user.id).FirstOrDefault();

           if (editUser != null)

           {

               editUser.firstname = user.firstname;

               editUser.lastname = user.lastname;

               editUser.login = user.login;

               editUser.password = user.password;

           }

           Save();

       }

   }

}

Веб-приложение

Файл «UserController.cs»:

using System;

using System.Linq;

using System.Web.Mvc;

using DomainModel.Abstract;

using DomainModel.Concrete;

using DomainModel.EF;

namespace MyArchiveService.Controllers

{

   [MyCheckSessionAttribute]

public class UserController : Controller

   {

private readonly IUsersRepository _usersRepository;

public UserController(SqlUsersRepository usersRepository)

       {

           _usersRepository = usersRepository;

       }

public JsonResult All()

       {

try

           {

var users = _usersRepository.Users;

var roles = _usersRepository.Roles;

var list = from u in users

join r in roles on u.role_id equals r.id

select new

                          {

                              Id = u.id,

                              Firstname = u.firstname,

                              Lastname = u.lastname,

                              Login = u.login,

                              Password = u.password,

                              Role = r.role1

                          };

return Json(new { message = "success", count = list.Count(), data = list }, JsonRequestBehavior.AllowGet);

           }

catch (Exception)

           {

return Json(new { message = "failed" }, JsonRequestBehavior.AllowGet);

           }

       }

public JsonResult Create()

       {

try

           {

var firstName = Request.Params["firstname"];

var lastName = Request.Params["lastname"];

var login = Request.Params["login"];

var password = Request.Params["password"];

var roleId = Request.Params["role_id"];

var newUser = new user

               {

firstname = firstName,

lastname = lastName,

login = login,

password = password,

                   role_id = Int32.Parse(roleId)

               };

               _usersRepository.AddUser(newUser);

return Json(new { message = "success" }, JsonRequestBehavior.AllowGet);

           }

catch (Exception)

           {

return Json(new { message = "failed" }, JsonRequestBehavior.AllowGet);

           }

       }

public JsonResult Update()

       {

try

           {

var id = Int32.Parse(Request.Params["id"]);

var firstName = Request.Params["firstname"];

var lastName = Request.Params["lastname"];

var login = Request.Params["login"];

var password = Request.Params["password"];

var roleId = Request.Params["role_id"];

var editUser = new user

               {

id = id,

firstname = firstName,

lastname = lastName,

login = login,

password = password,

                   role_id = Int32.Parse(roleId)

               };

               _usersRepository.EditUser(editUser);

return Json(new { message = "success" }, JsonRequestBehavior.AllowGet);

           }

catch (Exception)

           {

return Json(new { message = "failed" }, JsonRequestBehavior.AllowGet);

           }

       }

public JsonResult Delete()

       {

try

           {

var id = Int32.Parse(Request.Params["id"]);

               _usersRepository.DeleteUser(id);

return Json(new { message = "success" }, JsonRequestBehavior.AllowGet);

           }

catch (Exception)

           {

return Json(new { message = "failed" }, JsonRequestBehavior.AllowGet);

           }

       }

public JsonResult Roles()

       {

try

           {

var roles = _usersRepository.Roles;

var list = from r in roles

select new

                          {

                              Id = r.id,

                              Role = r.role1

                          };

return Json(new { message = "success", count = list.Count(), data = list }, JsonRequestBehavior.AllowGet);

           }

catch (Exception)

           {

return Json(new { message = "failed" }, JsonRequestBehavior.AllowGet);

           }

       }

   }

}

Файл «ProjectController.cs»:

using System;

using System.Collections.Generic;

using System.IO;

using System.Linq;

using System.Web.Mvc;

using DomainModel.Abstract;

using DomainModel.Concrete;

using DomainModel.EF;

using JsonModel;

namespace MyArchiveService.Controllers

{

   [MyCheckSessionAttribute]

public class ProjectController : Controller

   {

private readonly IHistoryRepository _historyRepository;

private readonly IProjectRepository _projectRepository;

private readonly ISectionRepository _sectionRepository;

private readonly ISubsectionRepository _subsectionRepository;

private readonly IDocumentsRepository _documentsRepository;

private readonly IUsersRepository _usersRepository;

public ProjectController(SqlHistoryRepository historyRepository, SqlProjectRepository projectRepository, SqlSectionRepository sectionRepository, SqlSubsectionRepository subsectionRepository, SqlDocumentsRepository documentsRepository, SqlUsersRepository usersRepository)

       {

           _historyRepository = historyRepository;

           _projectRepository = projectRepository;

           _sectionRepository = sectionRepository;

           _subsectionRepository = subsectionRepository;

           _documentsRepository = documentsRepository;

           _usersRepository = usersRepository;

       }

       //

       // GET: /Project/

public JsonResult All()

       {

try

           {

var projects = _projectRepository.Projects;

var programms = _projectRepository.Programms;

var institutes = _projectRepository.Institutes;

var statuses = _projectRepository.Statuses;

var sections = _sectionRepository.Sections;

var subsections = _subsectionRepository.Subsections;

var documents = _documentsRepository.Documentses;

var users = _usersRepository.Users;

var list = new List<JsonProject>();

var projectInfo = (from pr in projects

join p in programms on pr.programm_id equals p.id

join i in institutes on pr.institute_id equals i.id

join s in statuses on pr.status_id equals s.id

select new {pr, programm = p.name, institute = i.name, status = s.status1}).ToList();

foreach (var p in projectInfo)

               {

var id = p.pr.id; // cts t1 = t;

var sec = (from s in sections

join u in users on s.user_id equals u.id

where s.project_id == id

let subsec = (from ss in subsections

join u2 in users on ss.user_id equals u2.id

where ss.section_id == s.id

let subsecDoc = (from d in documents

join ud in users on d.user_id equals ud.id

where d.subsection_id == ss.id

select new JsonDocument

   {

       Id = d.id,

       Name = d.name,

       Path = d.path,

       Date = d.date,

       DateCreate = d.date_create,

       Comment = d.comment,

       Duplicate = d.duplicate,

       User = ud.firstname + " " + ud.lastname

    }).ToList()

select new JsonSubsection

   {

        Id = ss.id,

        Name = ss.name,

        Documents = subsecDoc,

        Duplicate = ss.duplicate,

        Survey = ss.survey,

        Date = ss.date,

        DateCreate = ss.date_create,

       User = u2.firstname + " " + u2.lastname

    }).ToList()

let secDoc = (from d in documents

join ud in users on d.user_id equals ud.id

where d.section_id == s.id

select new JsonDocument

      {

            Id = d.id,

            Name = d.name,

            Path = d.path,

            Date = d.date,

            DateCreate = d.date_create,

            Comment = d.comment,

            Duplicate = d.duplicate,

            User = ud.firstname + " " + ud.lastname

     }).ToList()

select new JsonSection

     {

            Id = s.id,

            Name = s.name,

            Subsections = subsec,

           Documents = secDoc,

           Duplicate = s.duplicate,

           Survey = s.survey,

           Date = s.date,

           DateCreate = s.date_create,

           User = u.firstname + " " + u.lastname

     }).ToList();

list.Add(new JsonProject

     {

          Id = p.pr.id,

          Name = p.pr.name,

          Folder = p.pr.folder,

          Sections = sec,

          Date = p.pr.date,

          DateCreate = p.pr.date_create,

          Description = p.pr.description,

          Shelf = p.pr.shelf,

          Rack = p.pr.rack,

          Room = p.pr.room,

          Coast = p.pr.cost,

          Srok = p.pr.srok,

          ProgrammId = p.pr.programm_id.ToString(),

          InstituteId = p.pr.institute_id.ToString(),

          StatusId = p.pr.status_id.ToString(),

          Programm = p.programm,

          Institute = p.institute,

            Status = p.status

      });

               }

return Json(new { message = "success", count = list.Count, data = list }, JsonRequestBehavior.AllowGet);

           }

catch (Exception)

           {

return Json(new { message = "failed" }, JsonRequestBehavior.AllowGet);

           }

       }

public JsonResult Create()

       {

try

           {

var name = Request.Params["name"];

var date = Request.Params["date"];

var programmId = Request.Params["programm_id"];

var instituteId = Request.Params["institute_id"];

var shelf = Request.Params["shelf"];

var room = Request.Params["room"];

var rack = Request.Params["rack"];

var cost = Request.Params["cost"];

var srok = Request.Params["srok"];

var description = Request.Params["description"];

var userId = Request.Params["user_id"];

var statusId = Request.Params["status_id"];

var newProject = new project

               {

     name = name,

     date = DateTime.Parse(date).ToShortDateString(),

                   date_create = DateTime.Now.ToShortDateString(),

                   programm_id = Int32.Parse(programmId),

                   institute_id = Int32.Parse(instituteId),

     cost = cost,

     folder = "project" + DateTime.Now.ToString().Replace(' ', '_').Replace('.', '_').Replace(':', '_'),

        rack = rack,

       room = room,

     shelf = shelf,

    srok = srok,

    description = description != String.Empty ? description : null,

                   user_id = Int32.Parse(userId),

                   status_id = Int32.Parse(statusId)

               };

               _projectRepository.AddProject(newProject);

Directory.CreateDirectory(AppDomain.CurrentDomain.BaseDirectory + "Archive/" + newProject.folder);

var newHistory = new history

                                    {

action = "create",

date = DateTime.Now.ToShortDateString(),

description = name,

                                        user_id = Int32.Parse(userId),

                                        project_id = newProject.id

                                    };

               _historyRepository.AddHistory(newHistory);

 return Json(new { message = "success" }, JsonRequestBehavior.AllowGet);

           }

catch (Exception)

           {

   return Json(new { message = "failed" }, JsonRequestBehavior.AllowGet);

           }

       }

public JsonResult Update()

       {

try

           {

var id = Int32.Parse(Request.Params["id"]);

var name = Request.Params["name"];

var date = Request.Params["date"];

var programmId = Request.Params["programm_id"];

var instituteId = Request.Params["institute_id"];

var shelf = Request.Params["shelf"];

var room = Request.Params["room"];

var rack = Request.Params["rack"];

var cost = Request.Params["cost"];

var srok = Request.Params["srok"];

var description = Request.Params["description"];

var userId = Request.Params["user_id"];

var statusId = Request.Params["status_id"];

var newProject = new project

               {

     id = id,

    name = name,

    date = DateTime.Parse(date).ToShortDateString(),

                   programm_id = Int32.Parse(programmId),

                   institute_id = Int32.Parse(instituteId),

    cost = cost,

   rack = rack,

   room = room,

    shelf = shelf,

    srok = srok,

    description = description != String.Empty ? description : null,

                   status_id = Int32.Parse(statusId)

               };

               _projectRepository.EditProject(newProject);

 var newHistory = new history

               {

action = "update",

date = DateTime.Now.ToShortDateString(),

description = name,

                  user_id = Int32.Parse(userId),

                        project_id = newProject.id

               };

               _historyRepository.AddHistory(newHistory);

return Json(new { message = "success" }, JsonRequestBehavior.AllowGet);

           }

catch (Exception)

           {

 return Json(new { message = "failed" }, JsonRequestBehavior.AllowGet);

           }

       }

public JsonResult Delete()

       {

try

           {

var id = Int32.Parse(Request.Params["id"]);

var userId = Int32.Parse(Request.Params["user_id"]);

var name = _projectRepository.Projects.Where(x => x.id == id).Select(x => x.name).FirstOrDefault();

           _projectRepository.DeleteProject(id);

var newHistory = new history

               {

action = "delete",

date = DateTime.Now.ToShortDateString(),

description = name,

                user_id = userId,

               project_id = id

               };

               _historyRepository.AddHistory(newHistory);

return Json(new { message = "success" }, JsonRequestBehavior.AllowGet);

           }

catch (Exception)

           {

   return Json(new { message = "failed" }, JsonRequestBehavior.AllowGet);

           }

       }

public JsonResult Programms()

       {

try

           {

var programms = _projectRepository.Programms;

var list = from p in programms

select new

                         {

                              Id = p.id,

                              Name = p.name

                         };

return Json(new { message = "success", count = list.Count(), data = list }, JsonRequestBehavior.AllowGet);

           }

catch (Exception)

           {

     return Json(new { message = "failed" }, JsonRequestBehavior.AllowGet);

           }

       }

public JsonResult AddProgramm()

       {

try

           {

var nameProgramm = Request.Params["programm"];

var newProgramm = new programm

                                     {

name = nameProgramm

                                     };

             _projectRepository.AddProgramm(newProgramm);

return Json(new { message = "success" }, JsonRequestBehavior.AllowGet);

           }

catch (Exception)

           {

return Json(new { message = "failed" }, JsonRequestBehavior.AllowGet);

           }

       }

public JsonResult UpdateProgramm()

       {

try

           {

var nameProgramm = Request.Params["programm"];

var idProgramm = Int32.Parse(Request.Params["programm_id"]);

var newProgramm = new programm

               {

id = idProgramm,

name = nameProgramm

               };

               _projectRepository.EditProgramm(newProgramm);

return Json(new { message = "success" }, JsonRequestBehavior.AllowGet);

           }

catch (Exception)

           {

    return Json(new { message = "failed" }, JsonRequestBehavior.AllowGet);

           }

       }

public JsonResult Institutes()

       {

try

           {

var institutes = _projectRepository.Institutes;

var list = from i in institutes

select new

                        {

                              Id = i.id,

                              Name = i.name

                        };

return Json(new { message = "success", count = list.Count(), data = list }, JsonRequestBehavior.AllowGet);

           }

catch (Exception)

           {

   return Json(new { message = "failed" }, JsonRequestBehavior.AllowGet);

           }

       }

public JsonResult AddInstitute()

       {

try

           {

var nameInstitute = Request.Params["institute"];

var newInstitute = new institute

               {

name = nameInstitute

               };

                _projectRepository.AddInstitute(newInstitute);

return Json(new { message = "success" }, JsonRequestBehavior.AllowGet);

           }

catch (Exception)

           {

   return Json(new { message = "failed" }, JsonRequestBehavior.AllowGet);

           }

       }

public JsonResult UpdateInstitute()

       {

try

           {

var nameInstitute = Request.Params["institute"];

var idInstitute = Int32.Parse(Request.Params["institute_id"]);

var newInstitute = new institute

               {

id = idInstitute,

name = nameInstitute

               };

             _projectRepository.EditInstitute(newInstitute);

return Json(new { message = "success" }, JsonRequestBehavior.AllowGet);

           }

catch (Exception)

           {

   return Json(new { message = "failed" }, JsonRequestBehavior.AllowGet);

           }

       }

public JsonResult Statuses()

       {

try

           {

var statuses = _projectRepository.Statuses;

var list = from s in statuses

select new

                        {

                              Id = s.id,

                              Name = s.status1

                        };

return Json(new { message = "success", count = list.Count(), data = list }, JsonRequestBehavior.AllowGet);

           }

catch (Exception)

           {

    return Json(new { message = "failed" }, JsonRequestBehavior.AllowGet);

           }

       }

public JsonResult AddStatus()

       {

try

           {

var nameStatus = Request.Params["status"];

var newStatus = new status

               {

                   status1 = nameStatus

               };

              _projectRepository.AddStatus(newStatus);

return Json(new { message = "success" }, JsonRequestBehavior.AllowGet);

           }

catch (Exception)

           {

   return Json(new { message = "failed" }, JsonRequestBehavior.AllowGet);

           }

       }

public JsonResult UpdateStatus()

       {

try

           {

var nameStatus = Request.Params["status"];

var idStatus = Int32.Parse(Request.Params["status_id"]);

var newStatus = new status

               {

id = idStatus,

                   status1 = nameStatus

               };

               _projectRepository.EditStatus(newStatus);

return Json(new { message = "success" }, JsonRequestBehavior.AllowGet);

           }

catch (Exception)

           {

    return Json(new { message = "failed" }, JsonRequestBehavior.AllowGet);

           }

       }

   }

}

Клиентское приложение

Файл «MainView.cs»:

using System;

using System.Drawing;

using System.Windows.Forms;

using MyArchive.Code;

using MyArchive.DetailsView;

using TreeViewTags;

namespace MyArchive.View

{

public partial class MainView : Form, IMainView

   {

private PDFView.PDFViewer _pdfViewer;

private readonly ProjectUserControl _projectDetails;

private readonly SectionUserControl _sectionDetails;

private readonly SectionUserControl _subsectionDetails;

private readonly DocumentUserControl _documentDetails;

private bool _guestMode;

public MainView()

        {

InitializeComponent();

           //

             _pdfViewer = new PDFView.PDFViewer {Dock = DockStyle.Fill, Location = new Point(10, 10), Enabled = false};

splitContainer2.Panel1.Controls.Add(_pdfViewer);

           //

           _projectDetails = new ProjectUserControl { Visible = false, Dock = DockStyle.Fill };

           _sectionDetails = new SectionUserControl { Visible = false, Dock = DockStyle.Fill };

           _subsectionDetails = new SectionUserControl { Visible = false, Dock = DockStyle.Fill };

           _documentDetails = new DocumentUserControl { Visible = false, Dock = DockStyle.Fill };

splitContainer2.Panel2.Controls.Add(_projectDetails);

splitContainer2.Panel2.Controls.Add(_sectionDetails);

splitContainer2.Panel2.Controls.Add(_subsectionDetails);

splitContainer2.Panel2.Controls.Add(_documentDetails);

       }

private void MainViewLoad(object sender, EventArgs e)

       {

               if (LoadedForm != null)

               LoadedForm(this, EventArgs.Empty);

       }

public void SetTreeView(TreeNode[] nodes)

       {

             treeViewProject.Nodes.Clear();

             treeViewProject.Nodes.AddRange(nodes);

       }

public void SetOpenFile(string filename)

       {

             _pdfViewer.OpenFile(filename);

       }

public void CloseView()

       {

foreach (var ownedForm in OwnedForms)

                {

ownedForm.Close();

                }

Close();

       }

public void SetAdminMode()

       {

           администрированиеToolStripMenuItem.Visible = true;

           toolStripButton10.Visible = true;

       }

public void SetGuestMode()

       {

           _guestMode = true;

           toolStripMain.Enabled = false;

           выдачаДокументовToolStripMenuItem.Enabled = false;

           возвратДокументовToolStripMenuItem.Enabled = false;

           справочникиToolStripMenuItem.Visible = false;

           новыйРазделToolStripMenuItem1.Enabled = false;

           новыйПодразделToolStripMenuItem1.Enabled = false;

           новыйПроектToolStripMenuItem1.Enabled = false;

           новыйДокументToolStripMenuItem1.Enabled = false;

       }

public TreeNode GetSelectedNode

       {

get { return treeViewProject.SelectedNode; }

       }

public void Search(string what, string where, string optional)

       {

var searchEventArgs = new SearchEventArgs {Optional = optional, What = what, Where = where};

if (SearchForm != null)

SearchForm(this, searchEventArgs);

       }

public event EventHandler<EventArgs> LoadedForm;

public event EventHandler<TreeNodeMouseClickEventArgs> SelectedNode;

public event EventHandler<EventArgs> SearchForm;

public event EventHandler<EventArgs> CreatedProject;

public event EventHandler<EventArgs> DeletedProject;

public event EventHandler<EventArgs> UpdatedProject;

public event EventHandler<EventArgs> CreatedSection;

public event EventHandler<EventArgs> DeletedSection;

public event EventHandler<EventArgs> UpdatedSection;

public event EventHandler<EventArgs> CreatedSubsection;

public event EventHandler<EventArgs> DeletedSubsection;

public event EventHandler<EventArgs> UpdatedSubsection;

public event EventHandler<EventArgs> CreatedDocument;

public event EventHandler<EventArgs> DeleteDocument;

public event EventHandler<EventArgs> UpdatedDocument;

public event EventHandler<EventArgs> OpenedAdminView;

public event EventHandler<EventArgs> OpenedHistoryView;

public event EventHandler<EventArgs> OpenedDictionaryView;

public event EventHandler<EventArgs> OpenedIssuedView;

public event EventHandler<EventArgs> OpenedReturnView;

public event EventHandler<EventArgs> OpenedReportView;

private void TreeViewProjectNodeMouseDoubleClick(object sender, TreeNodeMouseClickEventArgs e)

       {

if (SelectedNode == null) return;

           _pdfViewer.Enabled = true;

SelectedNode(this, e);

       }

private void TreeViewProjectNodeMouseClick(object sender, TreeNodeMouseClickEventArgs e)

       {

           treeViewProject.SelectedNode = e.Node;

           treeViewProject.SelectedNode.ImageIndex = e.Node.ImageIndex;

           //

if (e.Node.Tag != null)

           {

switch (e.Node.Tag.GetType().Name)

               {

case "ProjectTreeViewTag":

var project = e.Node.Tag as ProjectTreeViewTag;

                       _projectDetails.Visible = true;

                       _projectDetails.SetFields(project);

                       _sectionDetails.Visible = false;

                       _subsectionDetails.Visible = false;

                       _documentDetails.Visible = false;

break;

case "SectionTreeViewTag":

var section = e.Node.Tag as SectionTreeViewTag;

                       _sectionDetails.Visible = true;

                       _sectionDetails.SetSectionFields(section);

                       _projectDetails.Visible = false;

                       _subsectionDetails.Visible = false;

                       _documentDetails.Visible = false;

break;

case "SubsectionTreeViewTag":

var subsection = e.Node.Tag as SubsectionTreeViewTag;

                       _subsectionDetails.Visible = true;

                       _subsectionDetails.SetSubsectionFields(subsection);

                       _projectDetails.Visible = false;

                       _sectionDetails.Visible = false;

                       _documentDetails.Visible = false;

break;

case "DocumentTreeViewTag":

var doc = e.Node.Tag as DocumentTreeViewTag;

                       _documentDetails.Visible = true;

                       _documentDetails.SetFields(doc);

                       _projectDetails.Visible = false;

                       _subsectionDetails.Visible = false;

                       _sectionDetails.Visible = false;

break;

               }

           }

           //

if (e.Button != MouseButtons.Right || _guestMode) return;

var x = Location.X + e.X;

var y = Location.Y + e.Y;

           //

           y -= 30;

           x += 10;

if (e.Node.Tag as ProjectTreeViewTag != null)

           {

               contextMenuStripProject.Show(x, y);

           }

else if (e.Node.Tag as SectionTreeViewTag != null)

           {

               contextMenuStripSection.Show(x, y);

           }

else if (e.Node.Tag as SubsectionTreeViewTag != null)

           {

               y += 20;

               contextMenuStripSubsection.Show(x, y);

           }

else if (e.Node.Tag as DocumentTreeViewTag != null)

           {

               y += 35;

               contextMenuStripDocument.Show(x, y);

           }

       }

private void НовыйПроектToolStripMenuItem1Click(object sender, EventArgs e)

       {

if (CreatedProject != null)

CreatedProject(this, EventArgs.Empty);

       }

private void НовыйДокументToolStripMenuItemClick(object sender, EventArgs e)

       {

if (CreatedDocument != null)

CreatedDocument(this, EventArgs.Empty);

       }

private void НовыйРазделToolStripMenuItemClick(object sender, EventArgs e)

       {

if (CreatedSection != null)

CreatedSection(this, EventArgs.Empty);

       }

private void УдалитьToolStripMenuItemClick(object sender, EventArgs e)

       {

if (DeleteDocument != null)

DeleteDocument(this, EventArgs.Empty);

       }

private void ПользователиToolStripMenuItemClick(object sender, EventArgs e)

       {

if (OpenedAdminView != null)

OpenedAdminView(this, EventArgs.Empty);

       }

private void СвойстваДокументаToolStripMenuItemClick(object sender, EventArgs e)

       {

if (UpdatedDocument != null)

UpdatedDocument(this, EventArgs.Empty);

       }

private void УдалитьПроектToolStripMenuItemClick(object sender, EventArgs e)

       {

if (DeletedProject != null)

DeletedProject(this, EventArgs.Empty);

       }

private void НовыйПроектToolStripMenuItemClick(object sender, EventArgs e)

       {

if (UpdatedProject != null)

UpdatedProject(this, EventArgs.Empty);

       }

private void ИнформацияРазделToolStripMenuItemClick(object sender, EventArgs e)

       {

if (UpdatedSection != null)

UpdatedSection(this, EventArgs.Empty);

       }

private void УдалитьРазделToolStripMenuItemClick(object sender, EventArgs e)

       {

if (DeletedSection != null)

DeletedSection(this, EventArgs.Empty);

       }

private void НовыйПодразделToolStripMenuItemClick(object sender, EventArgs e)

       {

if (CreatedSubsection != null)

CreatedSubsection(this, EventArgs.Empty);

       }

private void ДокументToolStripMenuItemClick(object sender, EventArgs e)

       {

if (CreatedDocument != null)

CreatedDocument(this, EventArgs.Empty);

       }

private void ИнформацияToolStripMenuItemClick(object sender, EventArgs e)

       {

if (UpdatedSubsection != null)

UpdatedSubsection(this, EventArgs.Empty);

       }

private void УдалитьToolStripMenuItem1Click(object sender, EventArgs e)

       {

if (DeletedSubsection != null)

DeletedSubsection(this, EventArgs.Empty);

       }

private void ИсторияToolStripMenuItemClick(object sender, EventArgs e)

       {

if (OpenedHistoryView != null)

OpenedHistoryView(this, EventArgs.Empty);

       }

private void ИсторияToolStripMenuItem1Click(object sender, EventArgs e)

       {

var node = GetSelectedNode;

var tag = node.Tag as ProjectTreeViewTag;

if (tag == null) return;

var proEventArgs = new ProjectEventArgs {ProjectId = tag.Id};

if (OpenedHistoryView != null)

OpenedHistoryView(this, proEventArgs);

       }

private void ПоискToolStripMenuItemClick(object sender, EventArgs e)

       {

var searchView = new SearchView();

AddOwnedForm(searchView);

searchView.Show();

       }

private void ВыдачаДокументовToolStripMenuItemClick(object sender, EventArgs e)

       {

if (OpenedIssuedView != null)

OpenedIssuedView(this, EventArgs.Empty);

       }

private void ОтменитьПоискToolStripMenuItemClick(object sender, EventArgs e)

       {

if (SearchForm != null)

SearchForm(this, EventArgs.Empty);

       }

private void ВыдатьПроектToolStripMenuItemClick(object sender, EventArgs e)

       {

if (OpenedIssuedView != null)

OpenedIssuedView(this, new IssuedEventArgs {Project = true});

       }

private void ВозвратДокументовToolStripMenuItemClick(object sender, EventArgs e)

       {

if (OpenedReturnView != null)

OpenedReturnView(this, EventArgs.Empty);

       }

private void ИнститутыToolStripMenuItemClick(object sender, EventArgs e)

       {

var dicEventArgs = new DictionaryEventArgs {TabId = 1};

if (OpenedDictionaryView != null)

OpenedDictionaryView(this, dicEventArgs);

       }

private void ПрограммыToolStripMenuItemClick(object sender, EventArgs e)

       {

var dicEventArgs = new DictionaryEventArgs { TabId = 0 };

if (OpenedDictionaryView != null)

OpenedDictionaryView(this, dicEventArgs);

       }

private void СтатусыToolStripMenuItemClick(object sender, EventArgs e)

       {

var dicEventArgs = new DictionaryEventArgs { TabId = 2 };

if (OpenedDictionaryView != null)

OpenedDictionaryView(this, dicEventArgs);

       }

private void ДетальнаяИнформацияToolStripMenuItemClick(object sender, EventArgs e)

       {

if (детальнаяИнформацияToolStripMenuItem.Checked)

           {

               детальнаяИнформацияToolStripMenuItem.Checked = false;

               splitContainer2.Panel2Collapsed = true;

           }

else

           {

               детальнаяИнформацияToolStripMenuItem.Checked = true;

               splitContainer2.Panel2Collapsed = false;

           }

       }

private void ВыдатьРазделToolStripMenuItemClick(object sender, EventArgs e)

       {

if (OpenedIssuedView != null)

OpenedIssuedView(this, new IssuedEventArgs { Section = true });

       }

private void ВыдатьПодразделToolStripMenuItemClick(object sender, EventArgs e)

       {

if (OpenedIssuedView != null)

OpenedIssuedView(this, new IssuedEventArgs { Subsection = true });

       }

private void ВыдатьДокументToolStripMenuItemClick(object sender, EventArgs e)

       {

if (OpenedIssuedView != null)

OpenedIssuedView(this, new IssuedEventArgs { Document = true });

       }

private void ВыходToolStripMenuItemClick1(object sender, EventArgs e)

       {

CloseView();

       }

private void ЖурналРегистрацииToolStripMenuItemClick(object sender, EventArgs e)

       {

if (OpenedReportView != null)

OpenedReportView(this, EventArgs.Empty);

       }

   }

}

Файл «IAdminView.cs»:

using System;

using System.Collections.Generic;

using MyArchive.Model;

namespace MyArchive.View

{

public interface IAdminView

   {

void SetUserData(List<UserViewModel> data);

       UserViewModel GetSelectedUser { get; }

event EventHandler<EventArgs> LoadedForm;

event EventHandler<EventArgs> CreatedUser;

event EventHandler<EventArgs> EditedUser;

event EventHandler<EventArgs> DeletedUser;

   }

}

Файл «AdminView.cs»:

using System;

using System.Collections.Generic;

using System.Text.RegularExpressions;

using System.Windows.Forms;

using MyArchive.Model;

namespace MyArchive.View

{

public partial class AdminView : Form, IAdminView

   {

public AdminView()

       {

InitializeComponent();

       }

private void ButtonAddClick(object sender, EventArgs e)

       {

if (CreatedUser != null)

CreatedUser(this, EventArgs.Empty);

       }

private void ButtonEditClick(object sender, EventArgs e)

       {

if (EditedUser != null)

EditedUser(this, EventArgs.Empty);

       }

private void ButtonDeleteClick(object sender, EventArgs e)

       {

if (DeletedUser != null)

DeletedUser(this, EventArgs.Empty);

       }

private void AdminViewLoad(object sender, EventArgs e)

       {

if (LoadedForm != null)

LoadedForm(this, EventArgs.Empty);

       }

public void SetUserData(List<UserViewModel> data)

       {

foreach (var user in data)

           {

               user.Пароль = Regex.Replace(user.Пароль, ".", "*");

           }

           dataGridViewUsers.DataSource = data;

       }

public UserViewModel GetSelectedUser

       {

get

           {

var row = dataGridViewUsers.SelectedRows[0];

return row == null

                          ? null

                          : new UserViewModel

                                {

                                    Id = row.Cells[0].Value.ToString(),

                                    Имя = row.Cells[1].Value.ToString(),

                                    Фамилия = row.Cells[2].Value.ToString(),

                                    Логин = row.Cells[3].Value.ToString(),

                                    Пароль = row.Cells[4].Value.ToString(),

                                    Роль = row.Cells[5].Value.ToString()

                                };

           }

       }

public event EventHandler<EventArgs> LoadedForm;

public event EventHandler<EventArgs> CreatedUser;

public event EventHandler<EventArgs> EditedUser;

public event EventHandler<EventArgs> DeletedUser;

   }

}

Файл «AdminPresenter.cs»:

using System;

using System.Windows.Forms;

using MyArchive.View;

namespace MyArchive.Presenter

{

public class AdminPresenter

   {

private readonly IAdminView _view;

private readonly string _sessionKey;

private readonly string _userId;

private readonly MyArchiveApi _api;

public AdminPresenter(IAdminView view, string sessionKey, string userId)

       {

           _api = new MyArchiveApi();

           _view = view;

           _sessionKey = sessionKey;

           _userId = userId;

           _view.LoadedForm += OnLoadForm;

           _view.CreatedUser += OnCreateUser;

           _view.DeletedUser += OnDeleteUser;

           _view.EditedUser += OnEditUser;

       }

private void OnEditUser(object sender, EventArgs e)

       {

var user = _view.GetSelectedUser;

if (user == null) return;

var userView = new UserView

                              {

                                  Text = @"Редактирование пользователя",

textBoxFirstName = { Text = user.Имя },

textBoxLastName = { Text = user.Фамилия },

textBoxLogin = { Text = user.Логин },

textBoxPassword = { Text = user.Пароль },

comboBoxRole = { Text = user.Роль }

                              };

var roles = _api.GetRoles(_sessionKey, _userId);

           //

userView.comboBoxRole.Items.Clear();

foreach (var role in roles)

           {

userView.comboBoxRole.Items.Add(role.Role);

           }

           //

if (userView.ShowDialog() != DialogResult.OK) return;

var firstname = userView.textBoxFirstName.Text;

var lastname = userView.textBoxLastName.Text;

var login = userView.textBoxLogin.Text;

var password = userView.textBoxPassword.Text;

var r = userView.comboBoxRole.Text;

var roleId = String.Empty;

foreach (var role in roles)

           {

if (role.Role != r) continue;

roleId = role.Id;

break;

           }

var res = _api.UpdateUser(_sessionKey, _userId, user.Id, firstname, lastname, login, password, roleId);

if (res == null)

           {

MessageBox.Show(@"Не удалось выполнить операцию.", @"Ошибка");

return;

           }

RefreshUsers();

       }

private void OnDeleteUser(object sender, EventArgs e)

       {

var user = _view.GetSelectedUser;

if (user == null) return;

           _api.DeleteUser(_sessionKey, _userId, user.Id);

var users = _api.GetUsers(_sessionKey, _userId);

if (users == null)

           {

MessageBox.Show(@"Не удалось выполнить операцию.", @"Ошибка");

return;

           }

           _view.SetUserData(users);

RefreshUsers();

       }

private void OnCreateUser(object sender, EventArgs e)

       {

var userView = new UserView {Text = @"Новый пользователь"};

var roles = _api.GetRoles(_sessionKey, _userId);

           //

userView.comboBoxRole.Items.Clear();

foreach (var role in roles)

           {

userView.comboBoxRole.Items.Add(role.Role);

           }

if (userView.ShowDialog() != DialogResult.OK) return;

var firstname = userView.textBoxFirstName.Text;

var lastname = userView.textBoxLastName.Text;

var login = userView.textBoxLogin.Text;

var password = userView.textBoxPassword.Text;

var r = userView.comboBoxRole.Text;

var roleId = String.Empty;

foreach (var role in roles)

           {

if (role.Role != r) continue;

roleId = role.Id;

break;

           }

           //

           /*var resValidate = Validate.ValidateUser(firstname, lastname, login, password, roleId);

if (!resValidate.IsValid)

           {

MessageBox.Show(resValidate.ToString(), @"Ошибка!");

OnCreateUser(sender, e);

           }*/

var res = _api.CreateUser(_sessionKey, _userId, firstname, lastname, login, password, roleId);

if (res == null)

           {

MessageBox.Show(@"Не удалось выполнить операцию.", @"Ошибка");

return;

           }

RefreshUsers();

       }

private void OnLoadForm(object sender, EventArgs e)

       {

RefreshUsers();

       }

private void RefreshUsers()

       {

var users = _api.GetUsers(_sessionKey, _userId);

if (users == null)

           {

MessageBox.Show(@"Невозможно загрузить список пользователей.", @"Ошибка");

return;

           }

           _view.SetUserData(users);

       }

   }

}

Файл «HomeController.cs»:

using System;

using System.Threading;

using System.Windows.Forms;

using MyArchive.Presenter;

using MyArchive.View;

namespace MyArchive

{

static class Program

   {

       /// <summary>

       /// The main entry point for the application.

       /// </summary>

       [STAThread]

static void Main()

       {

Application.EnableVisualStyles();

Application.SetCompatibleTextRenderingDefault(false);

           //

var mainView = new MainView();

var mainPresenter = new MainPresenter(mainView);

Application.Run(mainView);

       }

   }

}


ПРИЛОЖЕНИЕ
 В. Образцы экранных форм системы


 

А также другие работы, которые могут Вас заинтересовать

15236. Етістіктің лексика-грамматикалық сипаты 69 KB
  Етістіктің лексикаграмматикалық сипаты Етістік қазақ тіліндегі сөз таптарының ішіндегі ең күр делілерінің бірі. Оның күрделілігі лексикасемантикалық сипатынан грамматикалық формалары мен категорияларының көптігінен синтаксистік қізметінен айқын көрінеді. Е...
15237. Әбілғазы баһадүр ханның «Түркі шежіресіндегі» араб-парсы сөздерінің қолданылу ерекшелігі 277 KB
  Әбілғазы шығармасының тіл ғылымы үшін, оның ішінде түркітану ғылымы үшін маңызы зор екендігін Г.С.Саблуков өзінің аудармасының кіріспесінде былайша көрсетеді: «Исправно изданный Родословной был бы при скудости литературы на восточно-джагатайском наречии
15238. Әлем тілдерінің топтастырылуы 171.5 KB
  Әлем тілдерінің топтастырылуы Мазмұны 1. Тілдердің генеологиялық туыстық классификациясы. 2. Тілдердің типологиялық классификациясы. 5.1. Тілдердің генеологиялық туыстық классификациясы. Тілдердің генеологиялық ту...
15239. Әлемнің тілдік көрінісінің тіл мәдениетіндегі бейнесі 73.88 KB
  ӘЛЕМНІҢ ТІЛДІК КӨРІНІСІНІҢ ТІЛ МӘДЕНИЕТІНДЕГІ БЕЙНЕСІ О.Сапашев ШҚМУ Түркітану оқытуғылымизерттеу орталығының директоры филология ғылымдарының кандидаты Тілдің табиғилығы мен оның даму мәдениеті қадым заманнан бері көтеріліп келе жатқан мәселе бұл ұлт...
15240. Әңгімелеу мәтінінің тілдік-стилистикалық сипаты 283.5 KB
  Мәтін лингвистикасында зерттеуді аса қажет ететін маңызды мәселелердің бірі – әңгімелеу мәтінінің тілдік және стилистикалық ерекшелігін таныту. Әңгімелеу – тұтасым, байласым және мағыналық аяқталғандық, ақпарат беру категорияларына ие композициялық-сөйлеу формаларының бірі
15241. ИССЛЕДОВАНИЕ РАСПРЕДЕЛЕНИЙ СКОРОСТИ ПОТОКА НА ВХОДЕ В АКТИВНУЮ ЗОНУ РЕАКТОРА ВВЭР-1000, В УСЛОВИЯХ РАЗЛИЧНЫХ РАСХОДОВ ТЕПЛОНОСИТЕЛЯ В ОТДЕЛЬНЫХ ПЕТЛЯХ 1.23 MB
  Лабораторная работа №1 ИССЛЕДОВАНИЕ РАСПРЕДЕЛЕНИЙ СКОРОСТИ ПОТОКА НА ВХОДЕ В АКТИВНУЮ ЗОНУ РЕАКТОРА ВВЭР1000 В УСЛОВИЯХ РАЗЛИЧНЫХ РАСХОДОВ ТЕПЛОНОСИТЕЛЯ В ОТДЕЛЬНЫХ ПЕТЛЯХ Объект исследования: течение теплоносителя в кольцевом опускном тракте в части напорно...
15242. ИССЛЕДОВАНИЕ РАСПРЕДЕЛЕНИЙ ТЕМПЕРАТУРЫ (ИМИТАТОРА БОРА) НА ВХОДЕ В АКТИВНУЮ ЗОНУ В УСЛОВИЯХ РАЗЛИЧНЫХ РАСХОДОВ ТЕПЛОНОСИТЕЛЯ В ОТДЕЛЬНЫХ ПЕТЛЯХ 454 KB
  Лабораторная работа №3 ИССЛЕДОВАНИЕ РАСПРЕДЕЛЕНИЙ ТЕМПЕРАТУРЫ ИМИТАТОРА БОРА НА ВХОДЕ В АКТИВНУЮ ЗОНУ В УСЛОВИЯХ РАЗЛИЧНЫХ РАСХОДОВ ТЕПЛОНОСИТЕЛЯ В ОТДЕЛЬНЫХ ПЕТЛЯХ Объект исследования: изучение динамики распределения температуры при подогреве воды подав
15243. Моделирование линейных динамических систем 84.75 KB
  Лабораторная работа №1 Моделирование линейных динамических систем Вариант 1 I.Исследование модели входвыход Исходные данные: a0=9 a1=6 a2=3 b0=12 b1=2 b2=0.1 Начальные условия: y0=1 0=0.50=0 Дифференциальное уравнение описания системы: Рисунок 1 –
15244. Геодезия. Лабораторные работы 2.31 MB
  Лабораторная работа №1. ОСНОВНЫЕ ПАРАМЕТРЫ ЗЕМНОГО ЭЛЛИПСОИДА. Эллипсоидом вращения называется геометрическое тело образуемое вращением эллипса вокруг его малой оси. Земной эллипсоид эллипсоид который характеризует фигуру и...