Программная система формирования баз знаний в формате CLIPS

  • Вид работы:
    Дипломная (ВКР)
  • Предмет:
    Информационное обеспечение, программирование
  • Язык:
    Русский
    ,
    Формат файла:
    MS Word
    3,2 Мб
  • Опубликовано:
    2012-05-24
Вы можете узнать стоимость помощи в написании студенческой работы.
Помощь в написании работы, которую точно примут!

Программная система формирования баз знаний в формате CLIPS

Оглавление

 

Введение

1. Общая часть

1.1 Описание предметной области

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

1.3 Система PolyAnalyst

2. Специальная часть

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

2.2 Программные средства и технологии разработки дипломного проекта

2.2.1 BPwin

2.2.2 Rational Rose

2.2.3 CLIPS

2.2.4 Borland Delphi

2.2.5 СУБД Cache’

2.3 Функциональная модель задачи

2.4 Объектная модель задачи

2.5 Информационная модель

2.6 Описание программной системы

3. Организационно-экономическая часть

4. Безопасность жизнедеятельности

4.1 Краткая характеристика помещения и оборудования

4.1.1 Характеристика помещения

4.1.2 Характеристика оборудования

4.2 Общая характеристика опасных и вредных производственных факторов

4.3 Нормирование санитарно-гигиенических условий труда

4.3.1 Микроклимат рабочих помещений

4.3.2 Определение комфортности среды

4.4 Освещение производственных (рабочих) помещений

4.5 Электромагнитные излучения

4.6 Оценка напряженности трудового процесса программиста

4.7 Электробезопасность

4.8 Пожарная безопасность

Заключение

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

 

Введение


В рамках данного дипломного проекта осуществляется разработка "Программной системы формирования баз знаний в формате CLIPS", обеспечивающей автоматизированное формирование баз знаний в формате CLIPS на основе анализа баз данных СУБД Cache, постреляционной СУБД, которая позволяет хранить данные как в виде таблиц (реляционное представление), так и в виде объектов (объектное представление).

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

Разрабатываемая программа должна автоматизировать деятельность экспертов, сокращая их время работы при анализе баз данных, извлечении знаний из СУБД Cache и записи их в формате CLIPS.

1. Общая часть


1.1 Описание предметной области


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

Программные системы искусственного интеллекта называются интеллектуальными.

Одним из видов интеллектуальных систем являются экспертные системы (далее ЭС).

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

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

·        Использование знаний, связанных с конкретной предметной областью;

·        Приобретение знаний от эксперта;

·        Определение реальной и достаточно сложной задачи;

·        Наделение системы способностями эксперта.

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

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

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

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

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

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

2)      Механизм логических выводов - делает логические выводы на основании знаний, имеющихся в базе знаний;

)        Пользовательский интерфейс - используется для правильной передачи ответов пользователю;

4)      Модуль приобретения знаний - служит для получения знаний от эксперта, поддержки базы знаний и дополнения ее при необходимости;

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

база знание формат программный

Рис.1.1 - Архитектура экспертной системы

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

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

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

.        поддержка Принятия управленческих решений;

.        проведение сравнительного анализа Вариантов решений (различных прогнозов, стратегий развития и т.д.);

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

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

Наиболее важным элементом любой экспертной системы, независимо от области ее применения, является база знаний.

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

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

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

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

Ниже приведены два аспекта характеристик членов КР: 1-психологический, 2 - профессиональный.

Пользователь

1.      К пользователю предъявляется самые слабые требования, поскольку его не выбирают. Он является в некотором роде заказчиком системы. Желательные качества:

·        Дружелюбие;

·        Умение объяснить, что он хочет от системы;

·        Отсутствие психологического барьера к применению вычислительной техники:

·        Интерес к новому

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

Эксперт

.        эксперт - чрезвычайно важная фигура в группе КР. В конечном счете, его подготовка определяет уровень компетенции БЗ. Желательные качества:

·        доброжелательность;

·        готовность поделиться своим опытом;

·        умение объяснить;

·        заинтересованность в успешности разработки;

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

Программист

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

·        Общительность;

·        Способность отказаться от традиционных навыков и освоить новые методы;

·        Интерес к разработке.

2. Поскольку современные ЭС - сложнейшие и дорогостоящие программные комплексы, программисты в КР должны иметь опыт и навыки разработки программ. Обязательно знакомство с основными структурами представления знаний и механизмами вывода, состоянием отечественного и мирового рынка программных продуктов для разработки ЭС и диалоговых интерфейсов.

Инженер по знаниям

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

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

·        Интеллект

·        Стиль общения.

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

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

 

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


Целью дипломного проекта является проектирование и реализация программной системы для автоматизированного формирования баз знаний в формате CLIPS, на основе анализа баз данных СУБД Cache.

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

получение и отображение информации о структуре базы данных;

выбор определенных таблиц (классов) в качестве источников для формирования знаний;

формирование образцов (шаблонов) фактов CLIPS на основе описания таблиц (классов) Cache;

формирование правил CLIPS на основе описания таблиц (классов) Cache и отношений между ними.

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

·        Осуществить анализ систем автоматизированного формирования баз знаний.

·        Изучить CLIPS и Cache.

·        Выполнить проектирование программной системы.

·        Программно реализовать систему для автоматизированного извлечения знаний с помощью среды Borland Delphi 7.0.

·        Рассмотреть вопросы расчета себестоимости программного продукта.

·        Рассмотреть вопросы безопасности жизнедеятельности.

Обзор систем автоматизированного формирования баз знаний

Аналитический курьер

Аналитический курьер - система извлечения знаний из документов (интернет, сообщения новостных лент, служебная переписка, платежные документы и т.д.), разработка компании "Ай-Теко".

Основные функции:

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

·        поиск ресурсов в Интернет через поисковые сайты, или по списку исследуемых сайтов;

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

·        доставка тематически структурированного в виде дерева списка релевантных документов (онтологии);

·        автоматическое общее и тематическое реферирование коллекций или отдельных документов;

·        тематическое рубрицирование документов и публикаций;

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

·        определение индекса информационной значимости объекта мониторинга;

·        автоматическое выделение тематических групп внутри полученной по запросу подборки документов (кластерный анализ публикаций);

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

·        построение дайджеста (обзора) по каждому объекту или теме документа;

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

·        Визуализация частотных распределений на географической карте.

Архитектура программного комплекса

Система "Аналитический курьер" реализована на Windows-платформе.net. имеет трехзвенную архитектуру с "тонким" клиентом и предоставляет пользователям Web-интерфейс.

Хранилище аналитических данных реализовано для СУБД MS SQL Server и ORACLE.

Примеры экранных форм системы

Рис.1.3 - Образец семантической карты взаимосвязей тем сообщений

 


1.3 Система PolyAnalyst


PolyAnalyst - программный продукт, реализующий методы анализа числовых данных и алгоритмы Text Mining - анализа текстовой информации.получил широкое распространение в мире. Более 500 инсталляций в 20 странах мира, среди пользователей системы внушительный список составляют крупнейшие мировые корпорации: Boeing, 3M, Chase Manhattan Bank, Dupont, Siemens и другие. PolyAnalyst - универсальная система Data Mining, она с успехом применяется в различных областях: в решении бизнес-задач (direct marketing, cross-selling, customer retention), в социологических исследованиях, в прикладных научных и инженерных задачах, в банковском деле, в страховании и медицине.

Архитектура системы

PolyAnalyst является клиент/серверным приложением. Пользователь работает с клиентской программой PolyAnalyst Workplace. Математические модули выделены в серверную часть - PolyAnalyst Knowledge Server. Такая архитектура предоставляет естественную возможность для масштабирования системы: от однопользовательского варианта до корпоративного решения с несколькими серверами. PolyAnalyst написан на языке С++ с использованием спецификации Microsoft's COM (ActiveX). Эта спецификация устанавливает стандарт коммуникации между программными компонентами. Математические модули (Exploration Engines) и многие другие компоненты PolyAnalyst выделены в отдельные динамические библиотеки и доступны из других приложений. Это дает возможность интегрировать математику PolyAnalyst в существующие ИС, например, в CRM или ERP системы.

Рис.1.4 - Архитектура системы

Workplace - лаборатория аналитика

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

Аналитический инструментарий PolyAnalyst

Версия PolyAnalyst 4.6 включает 18 математических модулей, основанных на различных алгоритмах Data и Text Mining. Большинство из этих алгоритмов являются Know-How компании Мегапьютер и не имеют аналогов в других системах. Алгоритмы анализа данных можно объединить в группы по их функциональному назначению: моделирование, прогнозирование, кластеризация, классификация, текстовый анализ, в частности:

·        Модуль Find Laws (FL) - построитель моделей

·        Memory based reasoning (MR) - метод "ближайших соседей"

·        Алгоритмы кластеризации

·        Алгоритмы ассоциации

·        Модули текстового анализа.

·        Text Analysis (ТА) - текстовый анализ

·        Text Categorizer (TC) - каталогизатор текстов

·        Link Terms (LT) - связь понятий

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

Rule Language (SRL) - язык символьных правил

SRL - это универсальный алгоритмический язык PolyAnalyst, который используется для символьного представления автоматически найденных системой в процессе Data Mining правил, а также для создания пользователем своих собственных правил. На языке SRL можно выразить широкий спектр математических конструкций, используя алгебраические операции, большой набор встроенных функций, операции с датами и временем, логические и условные конструкции. Для удобства написания выражений на SRL в программе предусмотрен маcтер создания правил.

Доступ к данным

PolyAnalyst может получать исходные данные из различных источников. Это: текстовые файлы с разделителем запятая (. csv), файлы Microsoft Excel 97/2000, любая ODBC - совместимая СУБД, SAS data files, Oracle Express, IBM Visual Warehouse.

2. Специальная часть


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


Техническое задание распространяется на разработку программной системы автоматизированного формирования баз знаний в формате CLIPS (C Language Production System). При наличии программных продуктов подобной направленности, актуальным является создание специализированных интегрируемых редакторов, совместимых с наработками лаборатории 4.3 и с CASE-средством.

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

Основанием для разработки является план научных работ лаборатории 4.3 Института динамики систем и теории управления СО РАН.

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

Основным назначением системы является формирование баз знаний в формате CLIPS. Источником данных для формирования баз знаний является база данных СУБД Cache, схема данных имеет структуру типа звезда (с центральной таблицей).

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

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

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

1.      Возможность задания вида продукционных правил (использование набора шаблонов).

2.      Выбор структур БД в качестве элементов формируемых правил.

.        Формирование баз знаний в соответствии с информацией, содержащейся в БД.

.        Просмотр сформированных баз знаний.

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

Результаты: базы знаний в формате CLIPS.

Замечания по программной реализации: В качестве средства реализации предлагается использовать Borland Delphi. Основные модули программной системы:

набор мастеров ввода/редактирования вида (шаблонов) правил (сложная структура правила, наличие коэффициентов уверенности).;

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

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

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

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

Система должна работать на IBM совместимых персональных компьютерах.

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

Система должна работать под управлением семейства операционных систем Win 32 (Windows 95, Windows 98, Windows 2000, Windows NT и т.п.).

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

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

В состав сопровождающей документации должна входить пояснительная записка на 70-90 листах, содержащая:

обзор аналогичных систем;

описание разработки, включая модели прецедентов, классов и деятельности;

руководство пользователя.

 


2.2 Программные средства и технологии разработки дипломного проекта


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

.        BPWin.

2.      Rational Rose.

.        CLIPS.

.        Cреда разработки приложений Delphi 7.

.        СУБД Cache.

 

2.2.1 BPwin

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

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

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

Для построения модели была использована методология IDEF0 (Integrated Computer - Aided Manufacturing DEFinition), которая предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы (иерархическая декомпозиция системы). При использовании данной методологии первоначально проводится описание анализируемой системы в целом и ее взаимодействий с окружающим миром в виде контекстной диаграммы, далее проводится ее функциональная декомпозиция - представление анализируемой системы в виде набора подпроцессов, каждый из которых описывается отдельно в виде диаграмм декомпозиции. Затем каждый подпроцесс разбивается на более мелкие и так далее до достижения нужной степени подробности.

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

 

2.2.2 Rational Rose

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

-   диаграммы вариантов использования,

-   диаграммы классов,

-   диаграммы состояний,

-   диаграммы деятельности,

-   диаграммы последовательности,

-   диаграммы кооперации,

-   диаграммы компонентов,

-   диаграммы развертывания.

Rational Rose поддерживает разработку большинства из этих диаграмм.

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

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

2.2.3 CLIPS

CLIPS - C Language Integrated Production System, разработана в центре космических исследований NASA (NASA’s Johnson Space Center) в середине 1980-х годов и во многом сходен с языками, созданными на базе LIPS, в частности OPS5 и ART. Использование C в качестве языка реализации объясняется тем, что компилятор LISP не поддерживается частью распространенных платформ, а также сложностью интеграции LISP-кода в приложения, которые используют отличный от LIPS язык программирования. Хотя в то время на рынке уже появились программные средства для задач искусственного интеллекта, разработанные на языке C, специалисты из NASA решили создать такой продукт самостоятельно. Разработанная ими система в настоящее время доступна во всем мире, и нужно сказать, что по своим возможностям она не уступает множеству гораздо более дорогих коммерческих продуктов.

Первая версия представляет собой, по сути, интерпретатор порождающих правил. Процедурный язык и объективно-ориентированное расширение CLIPS Object-Oriented Language {COOL} были включены в этот программный продукт только в 1990-х годах. Существующая в настоящее время версия может эксплуатироваться на платформах UNIX, DOS, Windows и Macintosh. Она является хорошо документированным общедоступным программным продуктом и доступна по сети FTR с множества университетских сайтов. Исходный код программного пакета CLIPS распространяется совершенно свободно и его можно установить на любой платформе, поддерживающей стандартный компилятор языка C.

Правила в CLIPS

CLIPS включает в язык представления порождающих правил и язык описания процедур.

Основными компонентами языка описания правил являются база фактов (fact base) и база правил (rule base). На них возлагаются следующие функции:

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

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

Машина логического вывода CLIPS сопоставляет эти факты и правила и выясняет, какие из правил можно активизировать. Это выполняется циклически, причем каждый цикл состоит из трех шагов:

·        сопоставление фактов и правил;

·        выбор правила, подлежащего активизации;

·        выполнение действий, предписанных правилом.

Такой трехшаговый циклический процесс иногда называют "циклом распознование - действие".

Факты

Факты являются одной из основных форм высокого уровня для представления информации в системе CLIPS. Факт (fact) - это список элементарных значений, на которые ссылаются либо позиционно (упорядоченные (ordered) факты), либо по имени (неупорядоченные (non-ordered) или шаблонные (template) факты). Обращение к фактам осуществляется по индексу или адресу.

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

Факты могут быть добавлены в список фактов (используя команду assert), удалены из него (используя команду retract), изменены (используя команду modify) или скопированы (используя команду duplicate) в результате явного воздействия пользователя или при исполнении программы CLIPS. Число фактов в списке фактов и количество информации, которая может быть запомнена в факте, ограничено только объемом памяти компьютера. Если в список фактов заявлен факт, который точно соответствует уже имеющемуся там факту, эта вставка будет проигнорирована (впрочем, такое поведение может быть принудительно изменено).

Некоторые команды, такие как retract, modify и duplicate требуют наличия факта (что вполне логично: довольно затруднительно удалить, изменить или скопировать несуществующий факт!). Факт может быть указан или индексом (fact-index), или адресом (fact-address). Каждый раз при добавлении (или изменении) факта он получает уникальный целочисленный индекс, называемый fact-index. Индексы начинаются с нуля и увеличиваются на единицу для каждого нового или измененного факта. Каждый раз при выполнении команд reset (обновление рабочей памяти) или clear (очистка рабочей памяти) индексы фактов сбрасываются в ноль. Факт может быть указан и с использованием адреса факта (fact-address). Адрес факта может быть получен, перехватив возвращаемое значение команд, которые возвращают адреса (например, assert, modify, duplicate), или присвоением переменной адреса факта, который соответствует образцу в левой части правила (LHS - Left-Hand Side, т.е. список условий), например, так:

;; присвоение переменной адреса факта (somefact exists)

? somefact < - (somefact exists)

Идентификатор факта (fact identifier) представляет собой краткую нотацию для отображения факта. Формат идентификатора факта - f-<fact-index>, например, запись f-10 относится к факту с индексом 10.

Как отмечалось выше, факты хранятся в одном из двух форматов: упорядоченном (ordered) или неупорядоченном (non-ordered).

Упорядоченные факты состоят из символьного обозначения с последовательностью нуля или более полей, разделенных пробелами, ограниченного начальной круглой скобкой с левой стороны и завершающей круглой скобкой справа. Первое поле упорядоченного факта обозначает "отношение", которое следует применять к следующим полям в факте. Например, факт (father-of Jack Bill) означает, что Билл - отец Джека (Bill is father of Jack) Ниже приведены примеры упорядоченных фактов:

;; скорость - 80 км/ч;

(speed is 80 km/h);

;; список бакалеи - хлеб молоко масло;

(grocery-list bread milk butter);

;; Робот находится в комнате;

(at room robot).

Следующие символьные обозначения зарезервированы и не могут быть использованы в качестве первого поля в любых фактах: test, and, or, not, declare, logical, object, exists и проч. Эти слова зарезервированы и не могут быть использованы в качестве имен шаблонов в конструкциях deftemplate, но могут быть использованы в качестве имен слотов (slot) (см. в библиотеке), хотя это и не желательно.

Неупорядоченные факты. Упорядоченные факты кодируют информацию позиционно. Чтобы обратиться к этой информации, пользователь должен знать не только то, какие данные хранятся в факте, но и какое именно поле содержит те или иные конкретные сведения. Неупорядоченные (или deftemplate) факты обеспечивают пользователю способность абстрагироваться от структуры факта, назначая имя каждому полю факта. Конструкция deftemplate используется для создания шаблона, который затем может быть применен для получения доступа к полям шаблонных фактов по их имени. Конструкция deftemplate является аналогом определения записей или структур в таких языках программирования, как Pascal и C.:

(deftemplate имя_шаблона;

(slot атрибут1 (тип) [ (default значение_по_умолчанию)];

(slot атрибут2 (тип) [ (default значение_по_умолчанию)]);

………

(slot атрибутN (тип) [ (default значение_по_умолчанию)]).

)

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

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

Ниже приведены примеры шаблонных фактов:

(patient (name "Ivanov Ivan") (age 46));

(class (teacher "Alexey Alexeev") (N_pupils 28) (Room "37A"));

(car (model "BMW-Z3") (color "silver") (price 50000)).

Заметьте, что порядок слотов в шаблонном факте не важен. Например, следующие факты идентичны:

(patient (age 46) (name "Ivanov Ivan"));

(patient (name "Ivanov Ivan") (age 46));

………

(car (color "silver") price 50000 (model "BMW-Z3"));

(car (price 50000) (model "BMW-Z3") (color "silver")).

В отличие от приведенных фактов, следующие упорядоченные факты не идентичны:

(class "Alexey Alexeev" 28 "37A";)

(class 28 "37A" "Alexey Alexeev");

(class "37A" "Alexey Alexeev" 28.

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

Правила

В языке CLIPS правила имеют следующий формат:

(defrule <имя правила>

< необязательный комментарий >

< необязательное объявление >

< предпосылка_1 >

……………….

< предпосылка_m >

=>

< действие_1 >

……………….

< предпосылка_n >

)

Например:

(defrule chores

“Things to do on Sunday”

(salience 10)

(today is Sunday)

(weather is warm)

=>

(assert (wash car))

(assert (chop wood)

)

В этом примере Chores - произвольно выбранное имя правила. Предпосылки в условной части правила

(today is Sunday)

(weather is warm)

сопоставляются затем интерпретатором с базой фактов, а действия, перечисленные в выполняемой части правила (она начинается после пары символов =>), вставят в базу два факта

(wash car)

(chop wood)

в случае, если правило будет активизировано. Приведенный в тексте правила комментарий

“Things to do on Sunday”

“Что делать в воскресенье”

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

(salience 10)

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

(defrule fun

“Better things to do on Sunday”

(salience 100)

(today is Sunday)

(weather is warm)

=>

(assert (drink beer))

(assert (play guitar))

)

Поскольку предпосылки обоих правил одинаковы, то при выполнении оговоренных условий они будут "конкурировать" за внимание интерпретатора. Предпочтение будет отдано правилу, у которого параметр salience имеет более высокое значение, в данном случае - правилу fun. Параметру salience может быть присвоено любое целочисленное значение в диапазоне [-10000, 10000]. Если параметр salience в определении правила опущен, ему по умолчанию присваивается значение 0.

Обычно в определении правила присутствуют и переменные. Если, например, правило

(defrule pick-a-chore

“Allocating chores to days”

(today is? day)

(chore is? job)

=>

(assert (do? job on? day))

)

будет сопоставлено с фактами

(today is Sunday)

(chore is carwash)

то в случае активизации оно включит в базу новый факт

(do carwash on Sunday).

Аналогично, правило

(defrule drop-a-chore

“Allocating chores to days”

(today is? day)

? chore < - (do? job on? day)

=>

(retract? chore)

)

отменит выполнение работ по дому (a chore). Обратите внимание на то, что оба экземпляра переменной? day должны получить одно и то же значение. Переменная? chore в результате сопоставления должна получить ссылку на факт, который мы собираемся исключить из базы. Таким образом, если это правило будет сопоставлено с базой фактов, в которой содержатся

(today is Sunday)

(do carwash on Sunday)

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

(do carwash on Sunday)

И мы отметим, что факт

(do carwash on Sunday)

будет сопоставлен с любым из представленных ниже образцов

(do?? Sunday)

(do? on?)

(do? on? when)

(do $?)

(do $? Sunday)

(do? chore $? when)

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

(on Sunday)

Если за префиксами? и $? не следует имя переменой, они рассматриваются как универсальные символы подстановки, которым соответственно может быть сопоставлен любой элемент или сегмент списка.

 

2.2.4 Borland Delphi

Delphi является средой разработки, используемой прежде всего для поддержки и разработки приложений, предназначенных как для отдельных рабочих станций, так и для серверов. Delphi может функционировать под управлением операционной системы Windows 95, 98, NT, XP. Отличительными чертами рабочей среды Delphi являются: - большинство созданных с помощью Delphi приложений будут направлены главным образом на решение задач, связанных с производством и бизнесом; это значит, что обеспечение функционирования баз данных и создание отчетов будут наиболее часто решаемыми задачами; - совместимость приложений становится все более важной. Помимо всего прочего, это обусловлено еще и бурным развитием аппаратного обеспечения (Hardware), в частности: а) широким распространением мобильных компьютеров; б) дальнейшим развитием технических средств, предназначенных для приема, воспроизведения и передачи информации следующих типов: цифровой, текстовой, изображения и звука.имеет пользовательский графический интерфейс, подобный Visual Basic и C++. Человек, ранее работавший в подобной среде, не будет чувствовать себя не в своей тарелке. Честно говоря, на данный момент множество фирм приняло за стандарт данный интерфейс для собственных приложений. Хорошим стимулом к получению знаний по данному предмету является знание хоть какого-нибудь языка программирования, или принципов написания программы. Идеально - знание языка программирования Pascal. Ведь весь исходный текст программы на Дельфи пишется на языке Object Pascal, практически ничем не отличающимся от принципов, заложенных в такой знаменитой программной оболочке. Синтаксис, принцип модуля, процедуры, функции, все взято за основу.

Raize Components 4.3.2

Raize Components - набор визуальных компонентов для Delphi / C++Builder. Расширяет возможности стандартных визуальных компонентов для Win32.

Поддерживаются IDE:

·        CodeGear RAD Studio 2009/Delphi 2009/C++Builder 2009

·        CodeGear RAD Studio 2007/Delphi 2007/C++Builder 2007

·        Borland Developer Studio 2006/Delphi 2006/C++Builder 2006/Win32 Turbo Editions

·        Delphi 2005

·        Delphi 7

·        Turbo Delphi Professional Turbo C++ Professional

Raize Components 4.3.2 - самая последняя версия, состоит из 125 компонентов, которые позволят улучшить программы, написанные на Delphi и C++ Builder.

 

2.2.5 СУБД Cache’

В конце 1997 года компания InterSystems Corp. выпустила постреляционную СУБД Cache'. Компания и раньше занималась системами управления базами данных, в России активно использовались и продолжают использоваться предшественники Cache': MSM, DTM, ISM. За 4 года вышло несколько версий СУБД Cache', в настоящий момент компания предлагает Cache' 4.1.' 4.1 - высокопроизводительная промышленная СУБД, интегрированная с технологией разработки Web-приложений - Cache' Server Pages.

СУБД Cache' относится к постреляционным СУБД. Термин "постреляционная СУБД" обозначает принадлежность Cache' к СУБД нового поколения. Имеется в виду не столько аспект времени (Cache' появилась после своих основных реляционных конкурентов), сколько ряд технологических преимуществ: единая архитектура данных и полная поддержка Cache' объектно-ориентированных технологий, о которых будет подробно рассказано ниже.

На рис.2.1 изображены основные элементы архитектуры СУБД Cache': платформы, на которых работает Cache', Многомерный сервер данных, три способа доступа к данным, язык описания бизнес-логики Cache' ObjectScript, интерфейсы к средствам проектирования и разработки приложений и Web-технология Cache' Server Pages. Далее мы подробно остановимся на всех основных элементах архитектуры, которые будут рассмотрены подробнее.

Рис.2.1 Архитектура постреляционной СУБД Cache

' - кроссплатформенная система. Cache' поддерживает следующие операционные системы: всю линейку Windows, Linux, основные реализации Unix и Open VMS. Планируется поддержка новых реализаций Unix. Большое внимание уделяется новой платформе Itanium.

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

В отличие от ранних многомерных СУБД, которые были оптимизированы для создания аналитических систем, Cache' ориентирована на системы обработки транзакций (Online Transaction Processing). Многомерный сервер данных Cache' предназначен для обработки транзакций в системах с большими и сверхбольшими БД (сотни гигабайт, терабайты) и большим количеством одновременно работающих пользователей. Многомерный сервер данных Cache' позволяет разработчикам получить великолепную производительность, отказавшись от хранения избыточных данных и таблиц. Реляционная модель не всегда подходит для описания сложных предметных областей. Транзакционная модель данных Cache' позволяет оптимизировать данные на уровне хранения, поддерживать объектную модель и сложные типы данных. Все эти возможности значительно упрощают создание сложных систем.

В Cache' реализована концепция Единой архитектуры данных. К одним и тем же данным, хранящимся под управлением Многомерного Сервера Данных Cache' есть три способа доступа: прямой, объектный и реляционный:

Рис 2.2 Концепция Единой архитектуры данных Cache'

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

2.      Cache' SQL - реляционный доступ, обеспечивающий максимальную производительность реляционных приложений с использованием встроенного SQL. Cache' SQL соответствует стандарту SQL 92. Кроме этого, разработчик может использовать разные типы триггеров и хранимых процедур. Все это позволяет Cache' успешно конкурировать с реляционными СУБД. Даже без использования прямого и объектного доступа приложения на Cache' работают быстрее за счет высокой производительности Многомерного Сервера Данных.

.        Cache' Objects - объектный доступ, для максимальной продуктивности разработки при использовании Java, Visual C++, VB и других ActiveX-совместимых средств разработки, таких как PowerBuilder и Delphi. В Cache' реализована объектная модель в соответствии с рекомендациями ODMG (Группа управления объектными базами данных - Object Database Management Group). В Cache' полностью поддерживаются наследование (в том числе и множественное), инкапсуляция и полиморфизм. При создании информационной системы разработчик получает возможность использовать объектно-ориентированный подход к разработке, моделируя предметную область в виде совокупности классов объектов, в которых хранятся данные (свойства классов) и поведение классов (методы классов). Cache', поддерживая объектную модель данных, позволяет естественным образом использовать объектно-ориентированный подход как при проектировании (в Rational Rose) предметной области, так и при реализации приложений в ОО-средствах разработки (Java, C++, Delphi, VB). Постреляционная СУБД Cache' конкурирует с объектными СУБД, значительно превосходя их по таким показателям как надежность, производительность и удобство разработки.

Cache' позволяет комбинировать три типа доступа, оставляя разработчику свободу выбора. Например, при реализации биллинговой системы объектный доступ может использоваться при описании бизнес-логики приложения и создания пользовательского интерфейса с помощью объектно-ориентированных средств разработки (VB, Delphi, C++), реляционный доступ - для совместимости с другими системами и интеграции с инструментами построения отчетов и аналитической обработки данных (Seagate Info, Cognos, Business Objects). Прямой доступ обеспечивает максимальную производительность и может быть использован для реализации таких операций, в которых применение обычных хранимых процедур, основанных на SQL, не может обеспечить необходимую производительность. В биллинге к таким операциям относятся закрытие периода, массовая загрузка данных (CDR). Использование прямого доступа для реализации подобных операций позволяет увеличить производительность на 1-2 порядка.

Для реализации бизнес-логики БД в СУБД Cache' используется Cache' Object Script. COS - полнофункциональный язык, который имеет все необходимые механизмы для работы с данными с помощью любого способа доступа. С помощью COS разработчик создает методы классов, триггеры, хранимые процедуры, различные служебные программы. В настоящее время ведется работа над созданием еще одного языка описания бизнес-логики - Бейсика. Использование Бейсика позволит облегчить изучение Cache' большому количеству программистов, владеющих этим широко распространенным языком.

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

 

2.3 Функциональная модель задачи


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

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

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

Структура диаграмм рассмотрена на рис.2.3, где:

Вход (Input) - материал или информация, которая используется или преобразовывается работой.

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

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

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

Рис. 2.3 - Структура контекстной диаграммы

На контекстной диаграмме A-0 (рис.2.4) отразим основные входные потоки, выходные данные, механизмы и управление. Управляющими воздействиями здесь будет Инструкция. Механизмами являются пользователь и ПО.

Рис.2.4 - Контекстная диаграмма "Формирование баз знаний в формате CLIPS".

Отразим этот блок на диаграмме первого уровня А0 "Формирование баз знаний в формате CLIPS" (рис.2.4). Входными данными модели будут:

·              знания экспертов;

·              база данных СУБД Cache’.

Выходными данными модели будут:

·              базы знаний в формате CLIPS.

Декомпозируем процесс формирования баз знаний на три подпроцесса (Рис.2.5). Это будут:

·              Подключение к СУБД;

·              Формирование структуры баз знаний;

·              Ручное извлечение знаний.

Рис.2.5 - Декомпозиция "Формирование баз знаний в формате CLIPS"

Декомпозируем подзадачу "Формирование структуры баз знаний" на два подзадачи (Рис.2.6), разделяя ее общую работу на два - "Формирование структуры шаблона" и "Формирование структуры правил". Аналогично декомпозируется работа "Формирование структуры правил" (Рис.2.7) на три подзадачи - "Выбор связующей таблицы", "Выбор таблицы для левой части правила" и "Выбор таблицы для правой части правила".

Рис.2.6 - Декомпозиция "Формирование структуры баз знаний"

Рис.2.7 - Декомпозиция "Формирование структуры правил"

Анализ диаграмм AS-IS (Рис.2.4 - Рис.2.7) показал, что все действия эксперта по извлечению знаний могут быть автоматизированы при помощи специализированного программного обеспечения, таким образом, были разработаны диаграммы TO-BE (Рис.2.8 - 2.11), отображающие автоматизацию всех процессов.

Рис.2.8 - Контекстная диаграмма "Формирование баз знаний в формате CLIPS" в модели TO-BE.

Рис.2.9 - Декомпозиция "Формирование баз знаний в формате CLIPS" в модели TO-BE

Рис.2.10 - Декомпозиция "Формирование структуры баз знаний" в модели TO-BE

Рис.2.11 - Декомпозиция "Формирование структуры правил" в модели TO-BE

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

 


2.4 Объектная модель задачи


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

Проектирование объектной модели осуществлялось с помощью RationalRose.

На основании анализа функциональной модели, определено одно действующее лицо: "Эксперт", который формирует базы знаний в формате CLIPS. Кроме того, на этом этапе определены функции, выполняемые этим действующим лицом (варианты использования), такие как "Подключение к СУБД", "Формирование структуры баз знаний", "Извлечение знания", "Сохранение баз знаний в файл" (рис.2.12).

Рис.2.12 - Диаграмма использования

Описание основных вариантов использования:

Спецификация варианта использования "Подключение к СУБД"

Цель: Подключить к определенной СУБД Cache’.

Активные субъекты: эксперт (пользователь).

Краткое описание: Подключение к СУБД, из которого мы будем извлекать знания.

Основной поток событий:

.        Эксперт запускает программу.

2.      Программа отображает окно ввода IP адреса компьютера, на котором запущена СУБД.

.        Эксперт вводит IP адрес компьютера, на котором находится СУБД Cache’.

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

Альтернативные потоки событий:

.        Эксперт запускает программу.

2.      Программа отображает окно ввода IP адреса компьютера, на котором запущена СУБД.

.        Эксперт вводит неверный IP адрес.

.        Система пытается установить соединение.

.        Система выводит сообщение об ошибке.

Специальные требования: нет.

Предусловия: эксперт должен знать IP адрес компьютера с СУБД Cache’.

Постусловия: нет.

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

Спецификация варианта использования "Формирование структуры БЗ"

Цель: Определение структур БЗ, по которым будут извлечены знания из базы данных.

Активные субъекты: эксперт (пользователь).

Краткое описание: Эксперту (Пользователю) необходимо сформировать структуры БЗ: указать таблицы для формирования шаблонов и правил.

Основной поток событий:

.        Система отображает список доступных таблиц (классов).

2.      Эксперт выбирает таблицы для формирования шаблонов фактов.

.        Эксперт выбирает центральную (связующую) таблицу для формирования правила.

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

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

Альтернативные потоки событий: нет

Специальные требования: нет.

Предусловия:

Эксперт должен предварительно знать структуру знаний;

Перед активизацией варианта использования должен быть выполнен вариант использования "Подключение к СУБД".

Постусловия: нет.

Дополнительные замечания: нет.

Спецификация варианта использования "Извлечение знаний"

Цель: Извлекать знания из СУБД по определенной структуре.

Активные субъекты: эксперт (пользователь).

Краткое описание: Извлечение знаний из БД в формат CLIPS.

Основной поток событий:

.        Эксперт инициирует процесс извлечения нажатием кнопки.

2.      Система извлекает знания согласно введенным экспертам структурам.

.        Система преобразовывает извлеченные знания в формат CLIPS.

.        Система публикует извлеченные знания.

Альтернативные потоки событий: нет.

Специальные требования: нет.

Предусловия: Перед активизацией варианта использования должен быть выполнен вариант использования "Формирования структуры БЗ".

Постусловия: нет.

Дополнительные замечания: нет.

Спецификация варианта использования "Сохранение в файл"

Цель: Сохранить базы знаний в файл.

Активные субъекты: эксперт (пользователь).

Краткое описание: Сохранить извлеченные базы знаний в определенный файл.

Основной поток событий:

.        Эксперт вводит наименование файла для сохранения базы знаний.

2.      Система сохраняет базу знаний в файл.

Альтернативные потоки событий: нет.

Специальные требования: нет.

Предусловия: Перед активизацией варианта использования должен быть выполнен вариант использования "Извлечение знаний".

Постусловия: нет.

Дополнительные замечания: нет.

 

2.5 Информационная модель


Проектирование информационной модели задачи осуществляется в два этапа. На первом этапе проектируется концептуальная модель данных (рис.2.13). На втором этапе строятся логическая и физическая модели данных.

Основными понятиями (концептами) предметной области, описывающими решаемую задачу являются:

·        База знаний;

·        Правило;

·        Шаблон;

·        Факт;

·        Слот;

·        Условие;

·        Действие.

Данные понятия связаны следующим отношениями:

·        База знаний содержит множество фактов, шаблонов и правил.

·        Факт может состоять из слотов.

·        Шаблон состоит из слотов.

·        Правило содержит условие и действие.

·        Условие и действие являются фактами.

Графически данные понятия и отношения отображены на рис.2.14 в виде логической модели. Физическая модель представлена на рис.2.15.

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

Рис.2.13 - Инфологическая (концептуальная) модель

Рис.2.14 - Логическая модель

Рис.2.15 - Физическая модель

 

.6 Описание программной системы


Используя результаты проектирования, была реализована программная система. На рис.2.16-2.26 показаны экранные формы по работе с системой формирования баз знаний.

Рис.2.16 - Главное окно программы после загрузки

Для формирования баз знаний в формате CLIPS, необходимо подключить системе к определенной СУБД Сache’.

Адрес: IP_адрес нахождения СУБД Cache’. Необходимо писать точно и правильно (Рис.2.17).

Рис.2.17 - Установить соединение

После этого мы будем нажать на кнопку "Установить подключение". Если существует СУБД Cache’ на таком IP_адресе, система показывает состояние "соединение установлено" (Рис.2.18) и список таблиц, с помощью которых мы создаем правилы или определим "шаблоны фактов" (Рис.2.19 - 2.20).

Рис.2.18 - Успешное соединение к СУБД

Рис.2.19 - Список таблиц у СУБД при определении "шаблонов фактов"

Рис.2.20 - Интерфейс создания правилы

Для определения "шаблонов фактов", мы выбираем нужные таблицы из списка и кнопка "Формировать шаблоны" изменит в активном состоянии (Рис.2.21).

Рис.2.21 - Формировать шаблоны

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

Рис.2.22 - Создание правилы. Выбор связующей таблицы

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

Рис.2.23 - Создание правила. Выбор таблицы для левой части правила

Рис.2.24 - Создание правила. Выбор таблицу для правой части правила

Если правило создано, то кнопка "Извлечь знания" станет активной.

Нажмем на кнопку что бы извлечь знания или формировать шаблоны в формате CLIPS. Результат показывается на форме "Результат" и состояние у кнопки "Сохранить" в активном.

Рис.2.25 - Создание правила. Результат

Чтобы сохранить в файл извлеченные знания необходимо нажать кнопку "Сохранить" (Рис.2.16).

Рис.2.26 - Сохранить результат в файл

3. Организационно-экономическая часть


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

Этапы расчета трудоемкости и их соответствующие параметры приведены на рис.3.1 - 3.4.

Поскольку система формирования баз знаний реализована в Delphi7.0, будем называть ее программным средством (ПС), как указано в методике [8].

ПС является развитием определенного ряда ПС на прежнем типе ЭВМ/ОС. При разработке системой используются CASE-технологии. Степень охвата реализуемых функций разрабатываемого ПС будет свыше 60%, как показано на рис.3.1.

Рис.3.1 - Первый этап

Программное средство обладает следующими характеристиками (рис.3.2):

·        наличие мощного интеллектуального языкового интерфейса высокого уровня с пользователем;

·        режим работы в реальном времени;

·        обеспечение телекоммуникационной обработки данных;

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

·        управление работой компонентов ПС;

·        формирование базы данных;

·        обработка записей базы данных;

·        организация поиска и поиск в базе данных;

·        статистическая обработка данных.

Рис.3. 2 - Второй этап

Инструмент моделирования построен на Delphi 7, поэтому средством обработки ПС являются языки 4GL. ПС пока работает на ПС совместимы и должно предусматривать: наличие экранных подсказок, выдача на экране контекстно-зависимой помощи, обеспечение хранения и поиска данных в сложных структурах и возможность связи с другими ПС (рис.3.3).

Рис.3.3 - Третий этап

На рис.3.4 приведен результат расчета трудоемкости данной работы

Рис.3.4 - Результат расчета трудоемкости

Из рис.3.4 видно что, общая трудоемкость для разработки системой составляет 1432 чел/дней.

Из них 832 чел/дня на реализацию прототипа системы в Delphi7.0, 350 чел/дней - для заполнения БД актуальной информацией, 250 чел/дней - для устранения ошибочных ситуаций, связанных с обработкой больших объемов данных.

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

Обоснование решения

Общая трудоемкость разработки ПС (Тобщ) в человеко-днях определяется по формуле:


где Ti - трудоемкость i-й стадии разработки ПС;- количество стадий разработки ПС.

Так как CASE-средства используются, то разработка ПС содержит три стадии: Предварительное проектирование (ПП), Рабочий проект (РП), Внедрение (ВН).

Трудоёмкоть стадии ПП рассчитывается по формуле:


Трудоёмкоть стадии РП рассчитывается по формуле:


Трудоёмкоть стадии ВН рассчитывается по формуле:


Таблица 3.1 - Зависимость значений поправочного коэффициента Кн от степени новизны ПС

Степень новизны

Новый тип ЭВМ

Новая ОС

Значение Код степени новизны


ПС, являющееся развитием определенного ряда ПС

Нет

Нет

0,7

В


Таблица 3.2 - Зависимости коэффициентов удельного веса трудоемкости стадий разработки от степени новизны ПС и вида технологии

B

L1=0,5

L3=0,35

L3=0,15



Таблица 3.3 - Значение коэффициента использования в разработке типовых программ

Использование типовых программ, %

Значение Км

Свыше 60

0,6


Общая трудоемкость разработки ПС (То) рассчитывается по формуле:

,

где Тур - трудоемкость разработки ПС с учетом конкретных условий разработки; Kсл - коэффициент сложности ПС>. Тур находится из:

,

где Тб - базовая трудоемкость разработки ПС;

Кур - поправочный коэффициент, учитывающий конкретные условия и средства разработки ПС.

Базовая трудоёмкость расчитывается по формуле:

,

где Тбпред - предыдущее значение Тб,

Тбпосл - последующая значение Тб пред-предыдущее значение Vo, посл - последующая значение Vo

Группа сложности равна 1

Таблица 3.4 - Каталог функций программного средства

Наименование функции

Объём функции ПС

Управление работой компонентов ПС

3560

Формирование базы данных

5580

Обработка записей базы данных

2750

Орзанизация поиска и поиск в базе данных

10560

Статистическая обработка данных

12930



Объём программного средства Vo, тыс. условных машинных команд 35,38

Таблица 3.5 - Базовая трудоёмкость разработки

Объем ПС, тыс. услов. машин. Команд

Нормы времени, чел. - дни (группа 1)

34

6110

36

6334


Для данного случая

б=6110 + ( (6334-6110) * ( (35,38-34) / (36-34))) = 6264,56

Таблица 3.6 - Коэффициент повышения сложности

Элемент, повышающий сложность ПС

Значение

Наличие экранных подсказок и меню функций

0,06

Выдача на экран контекстно-зависимой помощи

0,07

Обеспечение хранения и поиска данных в сложных структурах

0,07

Возможность связи с другими ПС

0,08

Наличие двух характеристик, повышающих сложность

0,18


Коэффициент повышения сложности находится по формуле:


и равен: 1,46

Таблица 3.7 - Поправочный коэффициент Kур

Средства разработки ИС

Локальные сети

Языки 4GL (Visual Basic, Delphi, Java Builder)

0,26


На основе этого Тyr=1628,7856;

Тo=2378,026976

Трудоёмкость по стадиям ТПП=0,5*0,7*2378,026976=832 Т=0,35*0,7*0,6*2378,026976=350 ТВН=0,15*0,7*2378,026976=250 Общая трудоёмкость=832+350+250=1432

Один рабочий час программиста стоит 200 рублей.

Стоимость разработки ПО для Delphi7.0 составляет 286400 рублей

4. Безопасность жизнедеятельности


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

 

4.1 Краткая характеристика помещения и оборудования

 

4.1.1 Характеристика помещения

В качестве объекта рассматривается компьютерный класс ИрГТУ, расположенный на третьем этаже здания ИрГТУ (В310а). Здание снабжено подъездными дорогами, системой коммуникаций, сетями электроснабжения, компьютерной сетью, телефонной связью. Здание состоит из 10 корпусов, в каждом из них имеются эвакуационные выходы. Предусмотрена система вентиляции и система пожарной сигнализации. Используется система общего равномерного освещения.

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

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

Предоставленный кабинет имеет один вход-выход и один оконный проём. Общая площадь кабинета составляет - 10,5 м2 (ширина 3,0 м, длина 3,5 м). В комнате имеется десять рабочих мест для студентов и одно место для администратора у класса (оборудованы ПК). Расположение рабочих мест представлено на рис.4.1.

Рис.4.1 - Схема расположения рабочих мест

 

4.1.2 Характеристика оборудования

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

4.2 Общая характеристика опасных и вредных производственных факторов


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

Производственные факторы среды включают:

·   Физические: температура, влажность, подвижность воздуха, шум, электрические и магнитные поля, освещенность;

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

·   Биологические: патогенные микроорганизмы, вирусы, препараты, содержащие живые клетки и споры микроорганизмов и т.д.

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

БЖД - Это наука о комфортном и безопасном взаимодействии человека с средой обитания. Главная задача при работе над разделом - анализ вредных и опасных факторов, влияющих на работу программиста. При работе над данным разделом использовались учебные пособия [1,2].

Таблица 4.1 - Общая характеристика опасных и вредных производственных факторов

Опасные и вредные факторы

Источники, места, причины возникновения опасных и вредных факторов

Нормируемые параметры

Основные средства защиты

1

2

3

4

Вредные факторы

Аномальные параметры микроклимата     Щели в оконных прямых, сквозняки.         Холодный период

теплый период

Центральное отопление, кондиционер.


 

Аномальное освещение

Недостаточно естественного освещения.

ен=1,5 % Ен=300-500 лк

Использование общего и местного искусственного освещения.

Электромагнитные излучения

ПК, принтеры.

Е-напряженность электрического поля, 25 В/м Н-напряженность магнитного поля, 15 кВ/м

Использование малоизлучающей техники.

Напряженность трудового процесса

Малая подвижность, неудобная рабочая поза.

Класс опасности условий труда - 3

Правильная организация рабочего места.

 Опасные факторы

Опасность поражения электрическим током

Заземление, зануление.

Опасность возникновения пожаров и взрывов

Организационная техника, бумага, электронная проводка.

Категорирование производственного помещения по взрыво-, пожароопасности В

Пожарная сигнализация, огнетушитель ОУ-5

 

4.3 Нормирование санитарно-гигиенических условий труда

 

4.3.1 Микроклимат рабочих помещений

Для создания нормального теплового баланса организма человека параметры микроклимата в производственном (рабочем) помещении нормируются. Параметры микроклимата регламентируются ГОСТ 12.1.005-88 [3] и СанПиН 2.2.4.548-96 [4].

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

Таблица 4.2 - Оценка условий труда по параметрам микроклимата

Факторы, влияющие на нормирование

Нормируемые параметры


Оптимальные

Допустимые

Период года          Категория работ              






 

Холодный и переходный

Лёгкой тяжести Iб

21-23

40-60

0,1

19-24

15-75

0,1-0,2

Теплый


22-24

40-60

0,2

20-28

15-75

0,1-0,3


Вывод: Параметры микроклимата соответствуют нормам и хорошо влияют на работоспособность программиста, поэтому класс условит труда - 2.

 

4.3.2 Определение комфортности среды

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

,

где:  - энергозатраты организма (Вт), это тепло, вырабатываемое организмом при выполнении определенной категории работ по тяжести;

 - теплопотери организма (Вт), это тепло, которое отдает организм в окружающую среду в зависимости от микроклиматических параметров.

Получение длительного тепла () приводит к перегреву организма, потеря тепла () приводит к понижению температуры тела и ощущению холода.

Наиболее оптимальное комфортное состояние, при котором , свидетельствует об отсутствии как перегрева, так и охлаждения организма.

Таким образом, при  выражение (1) описывает область комфортных сочетаний параметров микроклимата: °С,  %,  м/с.

Величина  обычно принимается по нормам в зависимости от характера выполняемой работы (таблица 4.2 и методических указаний [1]).

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


где:  - температура в градусах Кельвина;

 - принимается равной средневзвешенной температуре тела человека, T=31,5°С;

 - температуру поверхностей принять равной температуре воздуха в°К.

 - соответствующее значение парциального давления насыщенных водяных паров при температуре тела человека, = 4,61 кПа;

 - плотность водяных паров при температуре  и относительной влажности , определяется как:


где:  - парциальное давление насыщенных паров воды.

Расчёт комфортности среды проводится по методике, указанной в [1]. Результаты расчета представлены в таблицу 4.3

Таблица 4.3 Расчет суммарных теплопотерь организма

Исходные Данные

Параметры микроклимата

Составляющие Теплопотерь

Fизл, м2

FК, м2

Fисп, м2

ТП, 0С

Кизл, Вт/м2×с×гр×К4

Кисп, Вт/м2

ТВ, 0С

V, м/с

jн, %

РН, кПа

РВ, кПа

Qизл, Вт

Qисп, Вт

QК, Вт

QТП, Вт

1.7

1.5


22

4.5


22

0,1

47

2642

1241.7

78,3

100

58,4

236,78


 Вт

 Вт

 Вт

 Вт

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

Она предусматривается независимо от степени загрязнения воздуха в помещениях. Воздухообмен рабочего помещения производится согласно СПиН 41.03-2003 [7].

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

 

4.4 Освещение производственных (рабочих) помещений


Естественное освещение предусматривается во всех производственных помещениях, где проводится работа на компьютерах, ПЭВМ, дисплеях (допускается отсутствие естественного освещения только в помещениях, предусматривающих работу с драгоценными металлами).

Освещение кабинета равномерное и должно освещаться согласно СанПиН 2.2.2/2.5.1340-03 [5]. Фон помещения светлый, контраст объекта средний. Нормируемая освещенность при этих условиях согласно СНиП 23-05-95 [6] Е=200 лк, коэффициент естественного освещения е н = 1,5 %.

Для освещения необходимо использовать светильники типа "Люцетта" (4 шт.). В светильниках использованы лампы при напряжении 220 В.

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

4.5 Электромагнитные излучения


При работе на ВДТ, ПЭВМ, компьютерах, а также при пуско-наладочных работах АСУ персонал подвергается воздействию электромагнитных и статических полей.

В соответствии с СанПиН 2.2.2/2.5.1340-03 [5], СанПиН 2.2.4/1191-03 [8] и работой [9] временные допустимые уровни электромагнитных полей, создаваемых ПЭВМ, не должны превышать значения, представленные в таблице 4.4.

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

Таблица 4.4 - Временные допустимые уровни ЭМП, создаваемых ПЭВМ на рабочих местах

Наименование параметров

ВДУ ЭМП

Напряженность электрического поля, Е В/м

в диапазоне частот 5 Гц - 2 кГц

25 В/м


в диапазоне частот 2 кГц - 400 кГц

2,5 В/м

Плотность магнитного потока В нТл

в диапазоне частот 5 Гц - 2 кГц

250 нТл


в диапазоне частот 2 кГц - 400 кГц

25нТл

Напряженность электростатического поля

15 кВ/м


Таблица 4.5 Максимально допустимые значения интенсивности ЭМИ

Величина, единицы измерения

Диапазон воздействия ЭМП


30 кГц-300МГц

3-30МГц

30-300МГц

300МГц-300ГГц

ЕПДУ, В/м

500

396

80

-

НПДУ, А/м

50

3

3

-

ППЭПДУ, мкВт/см2

-

-


1000


В помещении ЭМП не превышают нормируемых значений.

4.6 Оценка напряженности трудового процесса программиста


Оценка напряженности трудового программиста производилась согласно P2.2.013-94 [10]

Таблица 4.6 Результаты оценки условий труда аттестуемых работников по показателям напряженности трудового процесса

Показатели напряженности трудового процесса

Классы условий труда для аттестуемого Программиста

А. Данные по отдельным показателям

1. Интеллектуальные нагрузки

1.1 Содержание работы

3.2

1.2 Восприятие сигналов и их оценка

2

1.3 Степень сложности задания

3.1

1.4 Характер выполняемой работы

1

2. Сенсорные нагрузки


2.1 Длительность сосредоточенного наблюдения

3.2

2.2 Плотность сигналов и сообщений

3.2

2.3 Число объектов одновр. Наблюдения

2

2.4 Нагрузка на зрительный анализатор


2.4.1 Размер объекта различения

2

2.4.2 Работа с оптическими приборами

1

2.4.3 Наблюдение за экранами видеотерминалов

3.2

2.5 Нагрузка на слуховой анализатор

3.2

3. Эмоциональные нагрузки


3.1 Степень ответственности, значимость ошибки

3.1

3.2 Степень риска за собств. Жизнь

1

3.3 Степень риска за других лиц

1

4. Монотонность нагрузок


4.1 Число элементов в задании

1

4.2 Продолжительность выполнения простых заданий

1

5. Режим работы


5.1 Фактическая продолжительность рабочего дня

2

5.2 Сменность работы

1

Б. Итоговые данные по отдельным показателям

1 класс

7

2 класс

4

3 класс:


1 степени (3.1)

2

2 степени (3.2)

5

3 степени (3.3)


В. Общая оценка условий труда работников

3.1


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

 

4.7 Электробезопасность

 

Компьютерный класс по степени опасности поражения электрическим током относится к помещениям без повышенной опасности. Электроснабжение осуществляется сетью с напряжением 220 В, частотой 50 Гц. Имеется система защитного заземления и зануления.

Поражение электрическим током возможно при следующих условиях:

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

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

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

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

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

Действия следующие:

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

·        запрещается касаться руками металлических предметов или тела пострадавшего, нужно тащить человека только за его одежду (воротник);

·        выполнять действия по спасению нужно только одной рукой;

·        если нет диэлектрических перчаток, то нужно обмотать руку сухой тряпкой или краем рукава;

·        освободить пострадавшего от продолжающегося действия электрического тока нужно не электропроводным предметом (наприме, палкой);

·        перерубать электропровод можно только топором с сухой деревянной ручкой;

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

 

4.8 Пожарная безопасность

 

Компьютерный класс по пожарной безопасности относится к помещениям класса В согласно СП 12.13130.2009 [11].

Пол класса покрыт воспламеняющимся линолеумом, имеется деревянная мебель, бумага и др. В случае возникновения пожара в кабинете огнетушитель ОУ - 2. Кроме того, на этаже есть два углекислотных огнетушителя ОУ - 5.

План эвакуации здания

Рис.4.2 - План эвакуации сотрудников корпуса В здания при возникновении пожара


Действия при пожаре

·        Позвонить по телефону 01

·        Оповестить персонал об угрозе

·        Эвакуироваться согласно плану эвакуации

Вывод по разделу:

Оценка параметров производственного микроклимата показала, что условия труда программиста допустимые - класс 2.

По напряжённости труда - условие класса 3.1, так как имеются значительные эмоциональные и сенсорные нагрузки.

Заключение


В ходе выполнения дипломного проекта была разработана программная система для автоматизированного формирования баз знаний в формате CLIPS на основе баз данных СУБД Cache.

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

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

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

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

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

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

Похожие работы на - Программная система формирования баз знаний в формате CLIPS

 

Не нашли материал для своей работы?
Поможем написать уникальную работу
Без плагиата!