Интеллектуальные возможности человека используемые при разработке пс кратко описать

Обновлено: 05.07.2024

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

Интеллектуальные возможности человека

Дейкстра [1] выделяет три интеллектуальные возможности человека, используемые при разработке ПС:

· способность к перебору,

· способность к абстракции,

· способность к математической индукции.

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

При разработке ПС мы не всегда можем уверенно знать обо всех связях между её элементами из-за возможных ошибок. Поэтому полезно уметь оценивать сложность системы по числу ее элементов: числом потенциальных путей взаимодействия между её элементами, т.е. n! , где n -- число её элементов. Систему назовём малой, если n 7 . При n = 7 имеем промежуточный класс систем. Малая система всегда проста, а большая может быть как простой, так и сложной. Задача технологии программирования -- научиться делать большие системы простыми.

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

· способность к перебору,

· способность к абстракции,

· способность к математической индукции.

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

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

При разработке ПС мы не всегда можем уверенно знать о всех связях между ее элементами из-за возможных ошибок. Поэтому полезно уметь оценивать сложность системы по числу ее элементов: числом потенциальных путей взаимодействия между ее элементами, т.е. n! , где n - число ее элементов. Систему назовем малой, если n 7 . При n=7 имеем промежуточный класс систем. Малая система всегда проста, а большая может быть как простой, так и сложной. Задача технологии программирования - научиться делать большие системы простыми.

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

ИСТОЧНИКИ ОШИБОК В ПРОГРАММНЫХ СРЕДСТВАХ

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

· способность к перебору,

· способность к абстракции,

· способность к математической индукции.

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

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

28 Вспомогательные средства проектирования ПС (схемы ВарньеОрра, СИС, схемы HIPO, функциональные схемы)

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

Для построения диаграмм Варнье используют 3 базовых элемента: последовательность, выбор, повторение.

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

Функциональная схема ПС.

Состоит из нескольких блоков, содерж-щих название программ. эти блоки соед-ся входящими в них стрелками и источниками с исходящими из них стрелками с приёмниками данных. Источники и приёмники изображаются в виде блоков согласно ЕСПД.

Функциональные схемы, учитывающие синхронизацию процесса.

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

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

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

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

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

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

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

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

29 Объекты и отношения в программировании

Объект (предмет) - всё, что предствляется чувством (объект вещественный) и всё, что представляется умом (умственный) - по Далю.

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

Объекты могут быть неделимыми и делимыми. Отношение связывает некоторые объекты. Объединение этих объектов обладает некоторым свойством. Если отношение связывает n объектов, то оно называется n-арным (n-местным). Одноместное отношение называетя простым своством объекта, многоместное - ассоциативным.Состояние объекта можно изучать по простым или ассоциативным свойствам. Множество объектов, обладающих общим набором свойств, называют классом. Каждый объект может быть представлен некоторой структурой данных. Простые свойства объекта могут задаваться в виде отдельных компонентов, либо специальной функцией этой структуры данных. Ассоциативные свойства (n > 1) можно представить в активной или пассивной форме. В активной форме n-местное отношение представляется некоторым фрагментом программы, реализующим n-местную функцию. В пассивной форме такое отношение может быть представлено некоторойструктурой данных (реляционной базой данных). Пользователи могут получать информацию об оъектах различными способами. В одних случаях пользователя могут интересовать свойства определенных объектов, в других - результаты взаимодействий с объектами, в третьих - изменение состояний объекта. Это требует использования нисходящих информационных моделей таких объектов, создания программных средств, моделирующих их свойства и предоставление пользователю доступа к этим моделям. В структурном подходе это было затруднено. Сущность состоит в систематическом использовании объекта при опиании.

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

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

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

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

30 Особенности объектного подхода к разработке внешнего описания ПС

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

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

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

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

Класс объекта = имя + список артибутов + список операций

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

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

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

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

Динамическая модель необходима, если в объектной модели имеются активные объекты.

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

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

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

32 Источники ошибок в ПС: интеллектуальные возможности человека, модель перевода информации. Причины появления ошибок.

Интеллектуальные возможности человека

Способность к перебору;
Способность к абстракции;
Способность к математической индукции.

Средство преодоления ограниченности — 2. Можно объединить предметы и экзамепляры в одно понятие, заменить множество одних, элементом другого рода.

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

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

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

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

Лекции

Лабораторные

Справочники

Эссе

Вопросы

Стандарты

Программы

Дипломные

Курсовые

Помогалки

Графические

Доступные файлы (14):

2Л ПСиТП.doc

Лекция 2

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

1.Программные средства как продукт технологии программирования.

1.1. Программа - формализованное описание процесса обработки данных. Программное средство.

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

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

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

1.2. Неконструктивность понятия правильной программы.

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

1.3. Надежность программного средства.

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

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

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

1.4 Технология программирования как технология разработки надежных программных средств.

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

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

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

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

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

1.5. Технология программирования и информатизация общества.

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

В 50-е годы мощность компьютеров (первого поколения) была невелика, а программирование для них велось, в основном, в машинном коде. Решались, главным образом, научно-технические задачи (счет по формулам), задание на программирование содержало, как правило, достаточно точную постановку задачи. Использовалась интуитивная технология программирования: почти сразу приступали к составлению программы по заданию, при этом часто задание несколько раз изменялось (что сильно увеличивало время и без того итерационного процесса составления программы), минимальная документация оформлялась уже после того, как программа начинала работать. Тем не менее, именно в этот период родилась фундаментальная для технологии программирования концепция модульного программирования, ориентированная на преодоления трудностей программирования в машинном коде. Появились первые языки программирования высокого уровня, из которых только ФОРТРАН пробился для использования в следующие десятилетия.

В 60-е годы можно было наблюдать бурное развитие и широкое использование языков программирования высокого уровня (АЛГОЛ 60, ФОРТРАН, КОБОЛ и др.), значение которых в технологии программирования явно преувеличивалась. Надежда на то, что эти языки решат все проблемы, возникающие в процессе разработки больших программ, не оправдалась. В результате повышения мощности компьютеров и накопления опыта программирования на языках высокого уровня быстро росла сложность решаемых на компьютерах задач, в результате чего обнаружилась ограниченность языков, проигнорировавших модульную организацию программ. И только ФОРТРАН, бережно сохранивший возможность модульного программирования, гордо прошествовал в следующие десятилетия (все его ругали, но его пользователи отказаться от его услуг не могли из-за грандиозного накопления фонда программных модулей, которые с успехом использовались в новых программах). Кроме того, было понято, что важно не только то, на каком языке мы программируем, но и то, как мы программируем. Это было уже началом серьезных размышлений над методологией и технологией программирования. Появление в компьютерах 2-го поколения прерываний привело к развитию мультипрограммирования и созданию больших программных систем. Широко стала использоваться коллективная разработка, которая поставила ряд серьезных технологических проблем.

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

ИСТОЧНИКИ ОШИБОК В ПРОГРАММНЫХ СРЕДСТВАХ
^

1.6 Интеллектуальные возможности человека.

способность к перебору,
способность к абстракции,
способность к математической индукции.

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

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

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

При разработке ПС мы не всегда можем уверенно знать о всех связях между его элементами из-за возможных ошибок. Поэтому полезно уметь оценивать сложность системы по числу ее элементов: числом потенциальных путей взаимодействия между ее элементами, т.е. n! , где n  число ее элементов. Систему назовем малой, если n 7. При n=7 имеем промежуточный класс систем. Малая система всегда проста, а большая может быть как простой, так и сложной. Задача технологии программирования  научиться делать большие системы простыми.

1.7 Неправильный перевод как причина ошибок в программных средствах.

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

Рис. 2.1. Грубая схема разработки и применения ПС.

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

1.8 Модель перевода.

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

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

Недавно был описан результат работы над проектом Programmer's Apprentice - прототип системы представления знаний и рассуждений, названный Cake [5]. Он служит для поддержки разработки наукоемких, эволюционирующих, интеллектуальных помощников для разработки программного обеспечения. (Таким образом, это мета-инструмент разработки).

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

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

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

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

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

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

1- какие знания (языки, навыки, методы) следует выбрать для усвоения обучающимся (содержание)

2- какое представление знаний подходит для усвоения учащимся (форма)

3- какой подход к процессу обучения (метод)

Среди нескольких недавних исследовательских проектов, направленных на разработку интеллектуальных обучающих систем для обучения программированию, следует упомянуть, по крайней мере, следующие: Lisp Tutor [4] для ознакомления с программированием на Lisp и PROUST для проблемы программирования. Программный анализ, который основан на выводе правдоподобного процесса проектирования.

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

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

Читайте также: