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

Существуют 3 стратегии конструирования ПО:

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

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

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

 

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

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

У каждого семейства есть свои достоинства, недостатки и область применения:

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

· прогнозирующий процесс применяют при фиксированных требованиях и мно­гочисленной группе разработчиков разной квалификации.

 

 

Основной задачей при планировании проектных задач является определение WBS — Work Breakdown Structure (структуры распределения работ). Она составляется с помощью утилиты планирования проекта. Типовая WBS приведена на рисунке.

Первыми выполняемыми задачами являются системный анализ и анализ требова­ний. Системный анализ проводится с целью:

1) выяснения потребностей заказчика;

2) оценки выполнимости системы;

3) выполнения экономического и технического анализа;

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

5) определения стоимости и ограничений планирования;

6) создания системной спецификации.

 

 

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

Анализ требований дает возможность:

1) определить функции и характеристики программного продукта;

2) обозначить интерфейс продукта с другими системными элементами;

3) определить проектные ограничения программного продукта;

4) построить модели: процесса, данных, режимов функционирования продукта;

5) создать такие формы представления информации и функций системы, кото­рые можно использовать в ходе проектирования.

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

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

Ромбиками на рисунке обозначены вехи — процедуры контроля промежуточных результатов. Очень важно, чтобы вехи были расставлены через регулярные интервалы (вдоль всего процесса разработки ПО). Это даст руководителю возможность регулярно получать информацию о текущем положении дел. Вехи распространя­ются и на документацию как на один из результатов успешного решения задачи. Параллельность действий повышает требования к планированию. Так как парал­лельные задачи выполняются асинхронно, планировщик должен определить межзадачные зависимости. Это гарантирует «непрерывность движения к объединению». Кроме того, руководитель проекта должен знать задачи, лежащие на критическом пути. Для того чтобы весь проект был выполнен в срок, необходимо выполнять в срок все критические задачи.

 

 

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

Предварительное проектирование обеспечивает:

· идентификацию подсистем;

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

Предварительное проектирование включает три типа деятельности:

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

2. Моделирование управления. Определяется модель связей управления между частями системы.

3. Декомпозиция подсистем на модули. Каждая подсистема разбивается на моду­ли. Определяются типы модулей и межмодульные соединения.

 

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

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

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

 

Связность модуля — это мера зависимости его частей. Связность — внутренняя характеристика модуля. Чем выше связность модуля, тем лучше результат проектирования, то есть тем «черней» его ящик (капсула, защит­ная оболочка модуля), тем меньше «ручек управления» на нем находится и тем проще эти «ручки».

Для измерения связности используют понятие силы связности (СС). Существует 7 типов связности:

1. Связность по совпадению (СС=0). В модуле отсутствуют явно выраженные внутренние связи.

2. Логическая связность (СС=1). Части модуля объединены по принципу функ­ционального подобия. Например, модуль состоит из разных подпрограмм об­работки ошибок. При использовании такого модуля клиент выбирает только одну из подпрограмм. Недостатки: сложное сопряжение и большая вероятность внесения ошибок при изменении сопряжения ради од­ной из функций.

3. Временная связность (СС=3). Части модуля не связаны, но необходимы в один и тот же период работы системы. Недостаток: сильная взаимная связь с другими модулями, отсюда — сильная чувствительность к внесению изменений.

4. Процедурная связность (СС=5). Части модуля связаны порядком выполняемых ими действий, реализующих некоторый сценарий поведения.

5. Коммуникативная связность (СС=7). Части модуля связаны по данным (работают с одной и той же структурой данных)

6. Информационная (последовательная) связность (СС=9). Выходные данные одной части используются как входные данные в другой части модуля.

7. Функциональная связность (СС=10). Части модуля вместе реализуют одну функцию.

Типы связности 1,2,3 — результат неправильного планирования архитектуры, а тип связности 4 — результат небрежного планирования архитектуры приложения.

 

Сцепление — мера взаимозависимости модулей по данным. Сцепление — внешняя характеристика модуля, которую желательно уменьшать. Количественно сцепление измеряется степенью сцепления (СЦ). Выделяют 6 ти­пов сцепления.

1. Сцепление по данным (СЦ=1). Все входные и выходные параметры вызываемого модуля - простые элементы данных.

2. Сцепление по образцу (СЦ=3). В качестве параметров используются структу­ры данных (например, в Паскале – записи).

3. Сцепление по управлению (СЦ=4). Модуль А явно управляет функциониро­ванием модуля В (с помощью флагов или переключателей), посылая ему уп­равляющие данные.

4. Сцепление по внешним ссылкам (СЦ=5). Модули А и В ссылаются на один и тот же глобальный элемент данных.

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

6. Сцепление по содержанию (СЦ=9). Один модуль прямо ссылается на содер­жание другого модуля (не через его точку входа). Например, коды их команд перемежаются друг с другом.

2. Разработка сложных программных систем.

Среди современных технологий программирования по праву считаются лидерами технологии COM, CORBA и CASE.

Технология СОМ фирмы Microsoft является развитием техноло­гии OLE I (Object Linking and Embedding - связывание и внедрение объек­тов), которая использовалась в ранних версиях Windows для создания состав­ных документов. Она определяет общую концепцию взаимодей­ствия программ любых типов(библиотек, приложений, операционной сис­темы), т. е. позволяет одной части программного обеспечения использовать функции (службы),предоставляемые другой (рисунок А3). Модификация СОМ, обеспечивающая передачу вызовов между компьютерами, называется DCOM (Distributed COM - распределенная СОМ). Приложение предоставляет свои службы, исполь­зуя специальные объекты -объекты СОМ (экземпляры классовСОМ). Объект СОМ включает поля и ме­тоды, но в отличие от обычных, каждый объект СОМ может реализовывать несколько интерфейсов, обеспечивающих доступ к его полям и функциям за счет организации отдельной таблицы адресов методов для каждого интерфейса. Классы СОМ поддерживают наследование интерфейсов, но не поддерживают наследования реализации, т. е. не наследуют код методов. Объект всегда функционирует в составе сервера - динамической библи­отеки или исполняемого файла, которые обеспечивают функционирование объекта. Различают три типа серверов:внутренний, локальный и удаленный (например, MS Word является локальным сервером). Для обращения к службам клиент должен получить указатель на соот­ветствующий интерфейс. Взаимодействие клиента и сервера обеспечивается базовыми механизмами СОМ или DCOM, поэтому клиенту безразлично местонахождение объ­екта. При использовании локальных и удаленных серверов в адресном пространстве клиента создается proxy-объект - заместитель объекта СОМ, а в адресном пространстве сервера СОМ-заглушка, соответствующая клиенту. Получив задание от клиента, заместитель упаковывает его параметры и, ис­пользуя службы операционной системы, передает вызов заглушке. Заглушка распаковывает задание и передает его объекту СОМ. Результат возвращается клиенту в обратном порядке. На базе технологии СОМ и ее распределенной версии DCOM были разработаны компонентные технологии, решающие различные задачи разработ­ки программного обеспечения [1]. К технологиям, реализующим компонентный подход, заложенный в СОМ, относятся:

 

а) OLE-automation- технология создания программируемых приложений, обеспечивающая программируе­мый доступ к их внутренним службам (например, MS Excel поддерживает ее, предоставляя другим приложениям свои службы);

б) ActiveX- технология, построенная на базе OLE-automation и предназна­ченная для создания как сосредоточенного на одном компьютере программного обеспечения, так и распределенного в сети. Предполагает использование визуального программирования для создания компонентов - элементов управления ActiveX, которые устанавливаются на компьютер дистанционно с удаленного сервера и применяются в клиентских частях приложений Интернет. Преимуществами технологии ActiveX являются: быстрое написание кода; открытость и мобильность; возможность написания приложений с использованием знакомых средств разработки (Visual Basic, Visual C++, Borland Delphi, Borland C++, Java); большое количество существующих бесплатных программных элементов ActiveX; стандартность;

в) MTS(Microsoft Transaction Server - сервер управления транзакциями) - технология, обеспечивающая безопасность и стабильную работу распреде­ленных приложений при больших объемах передаваемых данных;

г) MIDAS(Multitier Distributed Application Server - сервер многозвенных распределенных приложений) - технология, организующая доступ к данным разных компьютеров с учетом балансировки нагрузки сети.

Технология CORBA, разработанная группой компаний OMG (Object Management Group - группа внедрения объектной технологии про­граммирования), реализует подход аналогичный СОМ, на базе объектов и интерфейсов CORBA. Программное ядро CORBA реализовано для всех ос­новных аппаратных и программных платформ, и потому технологию можно использовать для создания распределенного программного обеспечения в разнородной вычислительной среде. Организация взаимо­действия между объектами клиента и сервера в CORBA осуществляется с помощью посредника (VisiBroker) и специ­ализированного программного обеспечения.

Отличительной особенностью современного этапа развития технологии программирования, кроме изменения подхода, является создание и внедре­ниеавтоматизированных технологий разработки и сопровождения про­граммного обеспечения, которые были названы CASE-технологиями (Computer-Aided Software/System Engineering - разработка программного обеспечения/программных систем с использованием компьютерной под­держки). Без средств автоматизации разработка достаточно сложного про­граммного обеспечения на настоящий момент становится трудно осуществи­мой: память человека уже не в состоянии фиксировать все детали, которые необходимо учитывать при разработке программного обеспечения. CASE-технологии поддерживают как структурный, так и объектный (компонентный) подходы к программированию [5].

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

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

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

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

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

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

а) непротиворечивость - контроль согласованности элементов;

б) полнота - контроль на присутствие лишних элементов;

в) формализация - строгость методического подхода;

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

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

Совокупность языков моделей, постановок задач, методов описаний некоторого иерархического уровня принято называть уровнем проектирования. Различные взгляды на объект проектирования принято называть аспектами проектирования. Достоинства блочно-иерархического подхода: возможность создания сложных систем; упрощение проверки работоспособности от­дельных блоков и системы в целом; обеспечение возможности модернизации систем. Использование блочно-иерархического подхода применительно к программным системам стало возможным только по­сле конкретизации общих положений подхода и внесения измене­ний в процесс проектирования. При этом структурный подход учитывает только свойства иерархии «целое-часть», а объектный дополнительно использует свойства иерархии «простое-сложное».

Дополнительную информацию по теме можно получить в [1, 4, 5, 10]

4.Организация проектирования программного обеспечения

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

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

 

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

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

 

3. Разработка программы

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

 

4. Отладка

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

 

5. Внедрение

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

5.Этапы процесса проектирования

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

• анализ требований к проекту;

• проектирование;

• реализация;

• тестирование продукта;

• внедрение и поддержка.

Анализ требований к проекту

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

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

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

Проектирование

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

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

Реализация

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

Тестирование продукта

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

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

Внедрение и поддержка

Внедрения системы обычно предусматривает следующие шаги:

• установка системы,

• обучение пользователей,

• эксплуатация.

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

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

6.Способы формального представления знаний

Глава 1. Способы формального представления знаний1.1 История в информатике

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

Под термином «Представление Знаний» чаще всего подразумеваютсяспособы представления знаний, ориентированные на автоматическую обработкусовременными компьютерами, и в частности, представления, состоящие из явныхобъектов ('класс всех слонов', или 'Клайд — экземпляр'), и из суждений илиутверждений о них ('Клайд слон', или 'все слоны серые'). Представление знаний вподобной явной форме позволяет компьютерам делать дедуктивные выводы из ранеесохраненного знания ('Клайд серый').

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

В 1980-х годах появились формальные компьютерные языкипредставления знаний. Основные проекты того времени пытались закодировать(занести в свои базы знаний) огромные массивы общечеловеческого знания. Напримерв проекте «Cyc» была обработана большая энциклопедия, и кодировалась не самахранящаяся в ней информация, а знания, которые потребуются читателю чтобыпонять эту энциклопедию: наивная физика, понятия времени, причинности имотивации, типичные объекты и их классы. Проект Cyc развивается компаниейCycorp, Inc.; большая часть (но не вся) их базы свободно доступна.

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

Было разработано несколько языков программированияориентированных на представление знаний. Пролог, разработанный в 1972 (см. www.aaai.org/AITopics/bbhist.html#mod),но получивший популярность значительно позже, описывает высказывания и основнуюлогику, и может производить выводы из известных посылок. Ещё больше нацелен напредставление знаний язык KL-ONE (1980-е).

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

1.2 Связи и структуры

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

Для представления знаний можно использовать семантическиесети. Каждый узел такой сети представляет концепцию, а дуги используются дляопределения отношений между концепциями. Одна из самых выразительных и детальноописанных парадигм представления знаний основанных на семантических сетях этоMultiNet (акроним для Многослойные Расширенные Семантические Сети англ. MultilayeredExtended Semantic Networks).

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

Использование фреймов в экспертных системах являетсяпримером объектно-ориентированного программирования, с наследованием свойств,которое описывается связью «is-a». Однако, в использовании связи «is-a»существовало немало противоречий: Рональд Брахман написал работу озаглавленную «Чемявляется и не является IS-A», в которой были найдены 29 различных семантиксвязи «is-a» в проектах, чьи схемы представления знаний включали связь «is-a». Другиесвязи включают, например, «has-part».

Фреймовые структуры хорошо подходят для представлениязнаний, представленных в виде схем и стереотипных когнитивных паттернов. Элементыподобных паттернов обладают разными весами, причем большие весы назначаются темэлементам, которые соответствую текущей когнитивной схеме (schema). Паттернактивизируется при определённых условиях: Если человек видит большую птицу, приусловии что сейчас активна его «морская схема», а «земная схема» — нет, онклассифицирует её скорее как морского орлана, а не сухопутного беркута.

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

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

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

1.3 Язык и нотация

Некоторые люди считают, что лучше всего будет представлятьзнания также как они представлены в человеческом разуме, который являетсяединственным известным на сегодняшний день работающим разумом, или жепредставлять знания в форме естественного языка. Доктор Ричард Баллард,например, разработал «семантическую систему, базирующуюся на теории», котораяне зависит от языка, которая выводит цель и рассуждает теми же концепциями итеориями что и люди. Формула, лежащая в основе этой семантики: Знание=Теория+Информация.Большинство распространенных приложений и систем баз данных основаны на языках.К несчастью, мы не знаем как знания представляются в человеческом разуме, иликак манипулировать естественными языками также как это делает человек. Одной изподсказок является то, что приматы знают как использовать интерфейсыпользователя point and click; таким образом интерфейс жестов похоже являетсячастью нашего когнитивного аппарата, модальность которая не привязана к устномуязыку, и которая существует в других животных кроме человека.

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

Нотация.

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

Примеры нотаций:

DATR является примером представления лексических знаний

RDF является простой Нотация для представления отношениймежду и среди объектов

Языки

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

CycL

IKL

KIF

Loom

OWL

KM: Машина Знаний (англ. Knowledge Machine) (фреймовый язык,использовавшийся для задач представления знаний)

язык Пролог

7.Спецификации программного обеспечения при структурном подходе.

Спецификации программного обеспечения при структурном подходе

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

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

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

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

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

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

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

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

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

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

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

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

● диаграмм потоков данных (DFD - Data Flow Diagrams), описывающих взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе;

● диаграмм “сущность-связь” (ERD - Enity Relationhship Diagrams), описывающих базы данных разрабатываемой системы;

● диаграмм переходов состояний (STD - State Transition Diagrams), характеризующих поведение системы во времени;

● спецификаций процессов;

● словаря терминов.

Взаимосвязь элементов такой обобщенной модели показана на рис.2

Поток данных

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

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

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

Обычно описание термина в словаре выполняют по следующей схеме:

● термин;

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

● краткое описание.

В качестве примера приведем описание одного из терминов системы решения комбинаторно-оптимизационных задач:

Термин . . . . . . . . . Алгоритм

Категория . . . . . . . Понятие предметной области

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

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

9.Типы пользовательских интерфейсов и этапы их разработки\

1. Типы пользовательских интерфейсов и этапы их разработки

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

• входные сообщения, которые генерируются человеком с помощью средств ввода: клавиатуры, манипуляторов (мышь, и.т.п.);

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

Пользователь генерирует сообщения типа:

• запрос информации,

• запрос помощи,

• запрос операции или функции,

• ввод или изменение информации,

• выбор поля кадра.

Получает в ответ:

• подсказки или справки,

• информационные сообщения, не требующие ответа,

• приказы, требующие действий,

• сообщения об ошибках, нуждающиеся в ответных действиях,

• изменение формата кадра.

Основные устройства, обеспечивающие выполнение операций ввода-вывода. Для вывода сообщений:

• монохромные и цветные мониторы – вывод оперативной текстовой и графической информации;

• принтеры – получение «твердой копии» текстовой и графической информации;

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

• синтезаторы речи – речевой вывод;

• звукогенераторы – вывод музыки.

Для ввода сообщений:

• клавиатура – текстовый ввод;

• планшеты – графический ввод;

• сканеры – графический ввод;

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

Типы интерфейсов Интерфейсы Пользователя Рисунок 1 – Типы интерфейсов ^ Процедурно-ориентированные интерфейсыиспользуют модель взаимодействия с пользователем, основанную на понятиях «процедура» и «операция». Программное обеспечение предоставляет пользователю возможность выполнения некоторых действий, для которых пользователь определяет соответствующие данные и следствием выполнения которых является получение желаемых результатов. ^ Объектно-ориентированные интерфейсы используют модель взаимодействия с пользователем, ориентированную на манипулированиеобъектами предметной области. Пользователю предоставляется возможность напрямую взаимодействовать с каждым объектом и инициировать выполнение операций, в процессе которых взаимодействуют несколько объектов. Задача пользователя формулируется как целенаправленное изменение некоторого объекта, имеющего внутреннюю структуру, определенное содержание и внешнее символьное или графическое представление. Например, модель реальной системы или процесса, база данных, текст и т.д. Элементы интерфейсов данного типа включены в пользовательский интерфейс Windows. Например, пользователь может «взять» файл и «переместить» его в другую папку. Таким образом, он инициирует выполнение операции перемещения файла. Примитивным называют интерфейс, который организует взаимодействие с пользователем в консольном режиме. Такой интерфейс реализует конкретный сценарий работы программного обеспечения, например: ввод данных – решение задачи – вывод результата. Обычно используются при обучении программированию или когда программа реализует одну функцию. Интерфейс-меню позволяет выбирать необходимые операции из специального списка, выводимого ему программой. Эти интерфейсы предполагают реализацию множества сценариев работы, последовательность действий в которых определяется пользователем. Различают одноуровневые и иерархические меню.  ^ Интерфейсы со свободной навигацией называют графическими пользовательскими интерфейсами. Интерфейсы этого типа ориентированы на использование экрана в графическом режиме с высокой разрешающей способностью. Графические интерфейсы поддерживают концепцию интерактивного взаимодействия с программным обеспечением, осуществляя визуальную обратную связь с пользователем и возможность прямого манипулирования объектами и информацией на экране. В отличии от интерфейса-меню интерфейс со свободной навигацией обеспечивает возможность осуществления любых допустимых в конкретном состоянии операций, доступ к которым возможен через различные интерфейсные компоненты. Например, окна программ, реализующих интерфейс Windows, обычно содержат:

• меню различных типов: ниспадающее, кнопочное, контекстное;

• разного рода компоненты ввода данных.

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

• постановка задачи – определение типа интерфейса и общих требований к нему;

• анализ требований и определение спецификаций – определение сценариев использования и пользовательской модели интерфейса;

• проектирование – проектирование диалогов и их реализация в виде процессов ввода-вывода;

• реализация – программирование и тестирование интерфейсных процессов.

10.Стандартизация и метрология в разработке программного обеспечения

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

 

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

 

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

 

Стандартизация характеристик качества

 

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

 

Выбор показателей качества

 

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

 

Оценка качества

 

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

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

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

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

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

 

Основные понятия стандартизации программных средств

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

11. Оценка качества процессов создания программного обеспечения