Другие журналы

научное издание МГТУ им. Н.Э. Баумана

НАУКА и ОБРАЗОВАНИЕ

Издатель ФГБОУ ВПО "МГТУ им. Н.Э. Баумана". Эл № ФС 77 - 48211.  ISSN 1994-0408

Экспертная система ╚Кардиолог╩

#6 июнь 2008

Овчинникова Евгения Павловна,

гимназия ╧ 1515, 11 класс

 

Научный руководитель:

Зобнин Алексей Игоревич,

кандидат физико-математических наук,

учитель информатики гимназии ╧ 1515

 

Введение

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

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

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

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

·         Исследование предметной области;

·         Выбор и изучение инструментального средства разработки ЭС;

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

·         Разработка структур данных и знаний медицинской ЭС;

·         Разработка алгоритмов работы системы;

·         Кодирование, тестирование и отладка ЭС;

·         Оформление отчета по проведенной работе.

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

 

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

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

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

Диагноз - установление болезни на основании исследования больного (в случае ЭС – на основании полученных симптомов).

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

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

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

 

 

Подпись: Симптом 1

 

Рис. 1.

 

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

 

2. Выбор технологии, языка и среды разработки

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

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

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

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

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

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

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

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

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

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

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

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

·       уменьшить вероятность морального устаревания системы за время разработки.

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

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

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

1)процедурная декомпозиция - предполагает разбиение общего алгоритма программы на отдельные фрагменты (подпрограммы) - структурный подход;

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

3) логическая декомпозиция - предполагает выделение целей и подцелей - логически-ориентированный подход;

4) декомпозиция по правилам продукции - предполагает формирование правил вида «Если ...То» - подход, ориентированный на правила;

5) инвариантная декомпозиция - предполагает описание предметной области в виде инвариантных соотношений - подход, ориентированный на ограничения. 

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

Инструментальные средства для построения ЭС можно разбить на следующие четыре группы:

1.        Алгоритмические языки общего назначения.

2.        Языки искусственного интеллекта.

3.        Специальные программные среды.

4.        Оболочки.

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

 

3. Определение структуры экспертной системы

При проектировании и разработке ЭС необходимо ответить на ряд следующих вопросов:

1.         Какие способы представления знаний лучше всего использовать?

2.         Какой механизм логического вывода лучше подходит для получения наиболее правильного решения?

3.         Как пользователи должны взаимодействовать с ЭС?

4.         Какие сервисные функции должны быть реализованы в ЭС?

5.         Какие инструментальные средства лучше всего использовать при реализации ЭС? и т.д.

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

Рис. 1. Обобщенная схема функционирования системы, основанной на знаниях

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

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

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

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

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

Рис. 2. Структура экспертной системы

 

Механизм логического вывода (МЛВ) выполняет следующие функции:

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

·       определение порядка выбора и применения фактов и правил.

МЛВ можно представить в виде четырех последовательных процессов:

·       выбор активных правил и фактов;

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

·       разрешение конфликтов;

·       выполнение выбранного означенного правила (действие).

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

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

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

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

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

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

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

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

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

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

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

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

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

Модуль объяснения.

Наряду с понятием «модуль объяснений» (МО) используются другие понятия: «блок объяснений», «подсистема объяснений» и др.

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

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

Модуль накопления знаний.

Модуль накопления (МН) является сервисным модулем, выполняющим различные вспомогательные функции. Как правило, добавление знаний осуществляется в дискретные интервалы времени в процессе эксплуатации системы. Естественно, что добавление знаний предполагает добавление «новых» знаний. К ним относятся знания, полученное на основе сообщений по особенностям эксплуатации системы.

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

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

На рис. 3 представлена структура медицинской экспертной системы «Кардиолог», которая была разработана в среде программирования Delphi 7.

Рис. 3. Структура медицинской экспертной системы «Кардиолог»

 

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

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

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

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

 

3.1. Определение структуры базы знаний

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

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

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

Type

    Tf=record

         Diag:string[80];                           {диагноз}

         Simp:array [1..5] of string[80];     {симптомы}

         Lec: array [1..5] of string[4];       {массивномеровлечения}

      end;

Рис. 4. Структура прикладной единицы базы знаний фреймов

Const N=50; {количество строк в описании лечения}

Type Tf=record

  N:string[4];                                        {номерлечения}

  Lec:array [1..N] of string[200];          {лечение}

end;

 

Рис. 5. Структура прикладной единицы базы знаний лечения

Имя диагноза ограничено 80 символами, описание причин ограничено 250 символами, а количество лечения может быть не более 5.

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

 

3.2. Разработка алгоритма механизма логического вывода

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

Рис. 6. Обобщенный алгоритм работы механизма логического вывода

 

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

Procedure TForm2.Button1Click(Sender: TObject);

Var Md,i,j,x,L,k,p:integer; W:Tf; S:string[80];

    m:array [1..10] of string[50];

    d:array [1..3] of Tds;

    Ch:set of char;

begin

ch:=[' ',',',';','.',':','-']; {множестворазделителей}

S:=Edit1.Text;

for i:=1 to 10 do m[i]:='';

for i:=1 to 3 do  {начальная установка массива вероятных диагнозов}

begin d[i].Mark:=-1; d[i].k:=0; d[i].d:='' end;

L:=length(S); j:=1;

for i:=1 to L do

begin

       if not (S[i] in Ch) then m[j]:=m[j]+S[i]   else  if m[j]<>'' then j:=j+1 ;

end;

Diagnoz:='';

for i:=1 to 10 do Lecdiag[i]:='';

Md:=0; seek(F,Md);

While (Not Eof(F)) and (S<>'') Do

begin 

     seek(F,Md); read(F,W); k:=0;

         for i:=1 to 5 do

begin  {подсчетколичествавхождений}

       if W.Simp[i]<>'' then

                   for p:=1 to j do

                       begin

   x:=pos(m[p],W.Simp[i]);

                           if x<>0 then inc(k);

 end;

end;

{Если нашли диагноз и в списке не существует}

if k>0  then begin {определяем три варианта}

   if (k>d[1].k) then begin {если 1-йприоритет}

               Diagnoz:=W.diag;

               for i:=1 to 10 do Lecdiag[i]:=W.Lec[i];

               d[3]:=d[2];  d[2]:=d[1]; d[1].Mark:=Md;

               d[1].k:=k; d[1].d:=W.diag;

               end else

   if (k>d[2].k)then begin {если 2-йприоритет}

               d[3]:=d[2];d[2].Mark:=Md;

               d[2].k:=k; d[2].d:=W.diag;

               end else

   if (k>d[3].k) then begin {если 3-йприоритет}

               d[3].Mark:=Md; d[3].k:=k; d[3].d:=W.diag;

               end;

            end;

Md:=Md+1;

end;

assignfile(Ft,'main.txt'); rewrite(Ft); {формируемфайлотчета}

if d[1].k>0 then begin

     for i:=1 to 3 do

       begin str(d[i].k,s);

                 s:='[вероятность '+s+']       '+d[i].d ;  writeln(Ft,s);

        end

end

else writeln(Ft,'Трудно определить диагноз !');

closefile(Ft); reset(Ft);  {просмотр результатов вывода}

while not seekeof(Ft) do

   begin

      readln(Ft,Sv);

      ListBox1.Items.Add(Sv);

   end;

closefile(Ft);     {закрытьфайлотчета}

end;

 

3.3. Структурная схема компоновки экспертной системы

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

Файл Expert.dpr - основной файл проекта. Для каждого проекта только один такой файл. В нем дополнительно перечисляются имена других файлов проекта.

Файлы Unit1.dfmUnit7.dfm  являются файлами форм. Это двоичные файлы дизайнера форм.

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

Файлы Unit1.dcuUnit7.dcu являются откомпилированными файлами соответствующих модулей. (*.DCU- DelphiCompiledUnits). Содержат объектный код файла модуля *.PAS. Создаются при запуске команд : Run, Compile или Build  All  из меню Run.

Файл Expert.EXE - основной откомпилированный программный файл.

Существует еще один вид откомпилированных файлов динамических библиотек (*.DLL - Dynamic Link Library), но в данном работе не используются. Эти откомпилированные модули могут одновременно использоваться многими программами Windows.

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

Файл Frame.bd содержит факты базы знаний, структура которых представлена на рис. 4.

 

 

Рис. 7. Структурная схема компоновки системы

Файл Lec.bd содержит знания о лечении пациента, структура которых представлена на рис. 5.

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

 

 

4. Разработка интерфейса с пользователем

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

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

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

2. Табличная. Включает в себя следующие конкретные типы:

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

·           заполнение и редактирование шаблона данных (совокупность фиксированных полей кадра). Различают шаблон-вектор  и шаблон-таблицу.

·           комбинирование меню и шаблонов в одном кадре.

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

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

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

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

 

4.1. Построение графа состояний интерфейса

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

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

С0 - запуск основного исполняемого файла Kardiolog.exe.

С1 - закрыть окно (форму) с помощью стандартной кнопки.

С2 - вызов сведений о системе с помощью соответствующей кнопки.

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

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

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

С6 - вызов редактора фреймов с помощью соответствующей кнопки.

С7 - выход из системы с помощью стандартной кнопки.

С8 - ввод симптомов.

С9 - вывод диагноза по нажатии кнопки «Определить диагноз».

С10 - чистка зоны вывода информации с помощью соответствующей кнопки.

С11 - вывод текста лечения по нажатии кнопки «Посмотреть лечение».

С12 - вывод статьи о причинах заболеваний по нажатии кнопки «Причины заболеваний».

С13 - создание новых знаний по нажатии кнопки «Создать».

С14 - поиск по ключу элементов знаний.

С15 - модифицирование текущего знания.

С16 - переход между элементами знаний.

С17 - сохранение модифицированных знаний.

С18 – ввод номера необходимого для просмотра лечения.

 

Рис. 8. Граф состояния интерфейса

 

 

Рис. 9. Форма главного меню системы

4.2. Разработка форм ввода-вывода информации

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

 

 

Рис. 10. Форма определения диагноза

 

 

Рис. 11. Форма для модифицирования фрейма

 

Рис. 12. Форма для вывода рекомендаций по лечению

 

5. Выбор стратегии тестирования

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

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

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

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

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

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

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

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

Метод оценки посредством просмотра непосредственно не связан с тестированием. Он является методом оценки анонимной программы в терминах ее общего качества, простоты эксплуатации и ясности. Цель этого метода - обеспечить сравнительно объективную оценку и самооценку программистов. Выбирается программист, который должен выполнять обязанности администратора процесса. Администратор набирает группу от 6 до 20 участников, которые должны быть одного профиля. Каждому участнику предлагается представить для рассмотрения две программы с его точки зрения наилучшую и наихудшую. Отобранные программы случайным образом распределяются между участниками. Им дается по 4 программы - две наилучшие и две наихудшие, но программист не знает, какая из них плохая, а какая хорошая. Программист просматривает их и заполняет анкету, в которой предлагается оценить их относительное качество по семибальной шкале.

Существуют и другие методы тестирования: по принципу «белого ящика», «черного ящика» и оценочное тестирование.

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

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

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

 

Заключение

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

В качестве дальнейшего развития системы может быть следующее:

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

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

·       разработка и реализация модуля объяснения;

·       расширение возможностей интерфейса с пользователем;

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

 

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

1.         Статические и динамические экспертные системы/ Э.В.Попов, И.Б.Фоминых, Е.Б.Кисель, М.Д.Шапот.- М.: Финансы и статистика, 1996.

2.         Попов Э.В. Экспертные системы. Решение неформализованных задач в диалоге с ЭВМ.- М.: Наука, 1987.- 288с.

3.         Тунсенд К., Фохт Д. Проектирование и программная реализация экспертных систем на персональных ЭВМ. -М.: Финансы и статистика,1990. -320с.

4.         Герман О.В. Введение в теорию экспертных систем и обработку знаний.-Минск.:ДизайнПРО,1995.-256с.

5.         Иванова Г.С. Технология программирования. -Москва: МГТУ, 2002.-320с.

6.         Федоров Ф.Г. Delphi для всех. -Москва: КомпьютерПресс, 1998.-543с.

 

 


Тематические рубрики:
Поделиться:
 
ПОИСК
 
elibrary crossref ulrichsweb neicon rusycon
 
ЮБИЛЕИ
ФОТОРЕПОРТАЖИ
 
СОБЫТИЯ
 
НОВОСТНАЯ ЛЕНТА



Авторы
Пресс-релизы
Библиотека
Конференции
Выставки
О проекте
Rambler's Top100
Телефон: +7 (915) 336-07-65 (строго: среда; пятница c 11-00 до 17-00)
  RSS
© 2003-2017 «Наука и образование»
Перепечатка материалов журнала без согласования с редакцией запрещена
 Тел.: +7 (915) 336-07-65 (строго: среда; пятница c 11-00 до 17-00)