Разработка программных средств различного назначения (далее для краткости — программ) состоит из трех фаз: анализа, проектирования и реализации. Основное назначение этих фаз:
анализа — определить требования к программе: что она должна делать и в каких условиях работать;
проектирования — определить составные части программы и порядок их взаимодействия: как они должны работать, чтобы удовлетворить разработанным на предыдущей фазе требованиям;
реализации — согласно результатам проектирования написать программу на выбранном языке (реже — языках) программирования и отладить ее, т.
е. добиться ее устойчивой правильной работы при различных вариантах исходных данных и режимах фун кционирован ия.
В любой программе можно выделить три базисные составные части, каждая из которых является объектом разработки:
1) данные; 2) процессы; 3) интерфейс.
При разработке программного обеспечения АИС параллельно решаются и вопросы, связанные с созданием их информационного обеспечения.
Методы и средства разработки программного обеспечения
Фазы анализа и проектирования завершаются созданием документации, содержащей, в частности, набор моделей, описывающих базисные составные части разрабатываемой программы.
Состав этого набора определяется выбранной методологией и методом разработки (см. п. 3.4).
Например, на первой фазе разработки программы — фазе анализа — могут быть использованы процессно-ориентированные методы, которые относят к классу методов структурного анализа, базирующихся на двух принципах: декомпозиции и иерархического упорядочивания.
На основе этих методов разрабатываются три группы моделей, описывающих:
— функции, которые должна выполнять программа;
— объекты предметной области (данные) и связи (отношения) между этими объектами (данными);
— поведение системы, зависящее от времени и внешних событий (в частности — от действий пользователей).
Модели первой группы называются функциональными, третьей группы — событийными, второй — моделями данных.
Основной упор в процессно-ориентированных методах делается на моделирование процессов обработки данных, что определяет ведущую роль функциональных моделей. Осуществляется последовательное разложение автоматизируемого процесса на отдельные, достаточно простые составляющие, объединен-
ные общей структурой. Для построения функциональных моделей чаще всего используются:
— DFD (Data Flow Diagrams) — диаграммы потоков данных, выделяющие внешние источники и внешних потребителей информации, функции (задачи) обработки информации, хранилища данных (базы данных, файлы, массивы);
— метод функционального моделирования, входящий в методологию SADT (Structured Analysis and Design Technique), дающий возможность указать в модели исполнителя каждой из имеющихся функций, но не содержащий средств моделирования хранилищ данных.
Иерархическая система моделей подобного класса позволяет описать с любой степенью подробности функции программы, информационные связи между ними, но не порядок и частоту их выполнения. Декомпозиция должна носить строго функциональный характер, т. е. отдельный элемент модели должен описывать законченную содержательную функцию обработки информации, которая предполагает определенный способ реализации ее на программном уровне. Степень детализации функций может быть различной. Функции ввода-вывода данных рекомендуется отделять от функций их вычислительной или логической обработки.
Методы и средства разработки программного обеспечения
Модели данных описывают перечень и структуры входных, выходных и хранимых данных программы. В АИС для построения моделей данных используются диаграммы «сущность-связь» — ERD (Entity Relationship Diagrams), отражающие выделенные объекты (сущности) предметной области, их признаки (атрибуты) и взаимосвязи. Именно этим моделям принадлежит ведущая роль при разработке программного и информационного обеспечения АИС.
При анализе модели данных надо рассмотреть диапазоны изменения значений всех исходных данных, установить, при всех ли комбинациях их значений применимы имеющиеся методы обработки данных, какой вид могут принять результаты, в каких пределах будут находиться их значения.
Такой анализ позволит заранее представить границы возможных значений результатов и обеспечить надежную работу программы.
Событийные модели, разрабатываемые на основе так называемых диаграмм перехода состояний (см. п. 1.5), являются удобным средством описания взаимодействия (интерфейса) пользователя с программой. Они позволяют выделить множество процессов (подфункций), реализуемых программой, а также отделить их от функций, реализуемых пользователем.
На этапе анализа требуется также выбрать методы решения задач, описать характер и режимы использования программы, оценить необходимость сетевого варианта ее работы, определить тип операционной системы, требования к комплексу технических средств и т. д.
Анализ может осуществляться неавтоматизированным и автоматизированным (с использованием САБЕ-технологий) способами (см. пп. 3.4). Неавтоматизированно ведется разработка лишь небольших по трудоемкости и структурной сложности программ. Автоматизированная разработка необходима при создании больших и средних программных систем, когда необходимо скоординировать работу коллектива разработчиков, уменьшить затраты на проектные работы, сократить сроки их выполнения, гарантированно обеспечить высокое качество системы.
В фазе проектирования модели, полученные в фазе анализа, получают свое развитие. Из блоков функциональной модели с использованием базовых конструкций структурного программирования и с учетом модели данных строятся блок-схемы алгоритмов, реализующих выполнение всех функций, описываемых этой моделью (см. п. 1.5).
Графическое оформление алгоритмов регламентируется ГОСТ 19.003-80 ЕСПД (Единая система программной документации), обозначения условные графические — ГОСТ 19.002-80 ЕСПД «Схемы алгоритмов и программ. Правила обозначения».
Анализ структуры алгоритмов с учетом частоты использования отдельных их фрагментов позволяет распределить эти фрагменты по различным функциональным элементам, которые будут решать различные, в том числе технологические, задачи и нести различную нагрузку в программной среде.
Конструктивное оформление и способ взаимодействия этих функциональных элементов определяются принятой методологией проектирования и инструментальными средствами реализации программы.
При использовании процессно-ориентированных методов функциональными элементами ПО появляются программные модули — относительно автономные конструктивные единицы (функции, процедуры, подпрограммы), логически взаимосвязанный набор которых и образует программу. Модули могут быть взаимосвязаны по управлению и по данным. Связь по управлению реализуется путем вызова одного модуля из другого. Вызванный модуль после завершения своей работы возвращает управление вызвавшему его модулю. Связь по данным может быть реализована двумя способами:
— непосредственным указанием при описании модуля его формальных параметров (переменных, массивов). При вызове модуля вместо формальных параметров указывают их фактические имена, используемые в вызывающем модуле. Часть этих параметров используется для передачи исходных данных. Вызванный модуль после завершения своей работы возвращает выходные данные вызвавшему его модулю с помощью другой части параметров. Этот способ обеспечивает интерфейс между вызываемым модулем и всеми непосредственно его вызывающими;
— использованием несколькими модулями общей области памяти, в которой размещены данные, необходимые этим модулям. Взаимосвязь модулей по данным будет осуществляться не непосредственно, а через эту область путем использования имен переменных, хранящих эти данные, одних и тех же в различных модулях. Сами модули образуют зону действия (область видимости) этих переменных. Из-за того, что значения переменных могут изменяться в нескольких модулях, контроль корректности их значений перед использованием затруднен. Поэтому рекомендуется размещать в общих областях постоянные данные или редко изменяемые данные, используемые небольшим числом модулей.
Для модуля характерны:
— один вход и один выход — на входе программный модуль получает определенный набор исходных данных, выполняет их содержательную обработку и возвращает один набор выходных данных;
— функциональная завершенность — модуль выполняет перечень определенных операций, необходимых для реализации соответствующей функции и достаточных для завершения начатой обработки;
— достаточно слабые информационные связи с другими программными модулями;
— логическая независимость — результат работы программного модуля зависит только от исходных данных и не зависит от работы других модулей;
— ограниченная сложность и размер.
Таким образом, модули содержат определение доступных для обработки данных, операции обработки данных, описание взаимосвязи с другими модулями. Каждый модуль состоит из спецификации и тела. Спецификации определяют правила использования модуля, а тело — способ реализации процесса обработки.
При определении набора модулей, реализующих функции конкретного алгоритма, необходимо учитывать следующее:
— принятие основных решений в алгоритме выносится на максимально «высокий» уровень иерархии;
— для реализации одной и той же функции в разных местах алгоритма создается один модуль, который при необходимости вызывается на выполнение.
Среди множества модулей различают:
— головной модуль — управляет запуском программного продукта (существует в единственном числе);
— управляющий модуль — обеспечивает вызов других модулей на обработку;
— рабочие модули — выполняют функции обработки;
— сервисные модули и библиотеки, утилиты — реализуют технологические, обслуживающие функции.
В результате создается функционально-модульная структура программы, являющаяся основой для ее реализации (программирования).
При проектировании интерфейса необходимо преобразовать полученную ранее диаграмму перехода состояний с учетом диалоговых возможностей, предоставляемых инструментальными средствами реализации программы, предусмотрев возможность контроля ошибочных действий пользователя.
Наиболее распространены и просты для реализации диалоговые системы с жестким сценарием диалога, использующим стандартизированные интерфейсные средства:
— меню — пользователю предлагается выбор альтернативы функций обработки из фиксированного перечня;
— действия запрос-ответ — фиксирован перечень возможных значений, выбираемых из списка, например ответы типа Да/Нет;
— запрос по формату — с помощью ключевых слов, фраз или путем заполнения экранной формы с регламентированным по составу и структуре набором реквизитов осуществляется подготовка сообщений.
Ранее составленный перечень данных в фазе проектирования дополняют и уточняют с учетом выбранных решений по интерфейсу и программным модулям.
К настоящему времени известно порядка десятка объектно- ориентированных методов анализа и проектирования, различающихся составом моделей и последовательностью их составления. Наиболее распространенные из них основаны на использовании унифицированного языка моделирования UML (Unified Modeling Language), появившегося в результате синтеза наиболее удачных сторон трех основных методов. UML содержит стандартный набор диаграмм и нотаций (обозначений).
Опишем основные диаграммы. Ведущей является диаграмма вариантов использования, описывающая роли пользователей системы и выполняемые ими функции (процессы). Все варианты использования связаны с внешними требованиями к функциональности разрабатываемой программной системы.
Диаграммы классов определяют типы объектов предметной области, их атрибуты и методы, а также статические связи между ними. Процесс обмена сообщениями между объектами моделируется диаграммами взаимодействия. Диаграммы состояний описывают переход объектов из состояния в состояние. Логика выполнения процессов описывается с помощью диаграмм деятельности.
На диаграммах компонентов изображают компоненты программы (исполняемые модули и библиотеки) и иерархические связи между ними. Диаграммы размещения используют в распределенных АИС для отражения физических взаимосвязей между программными и техническими компонентами.
Объектно-ориентированная методология проектирования предусматривает реализацию функциональных элементов алгоритмов не только в виде традиционных модулей (процедур), а в основном с помощью методов объектов и событийных процедур. Вызов методов и процедур осуществляется с помощью событий, формирующих сообщения для объектов. Данные (свойства объектов) могут быть доступны лишь с помощью методов этого объекта. Другими словами, никакой другой объект или никакая процедура не могут изменить свойство объекта иначе, как вызвав соответствующий метод этого объекта. Методы объектов и событийные процедуры можно рассматривать как развитие (один из вариантов) программных модулей.
Объектно-ориентированные инструментальные средства разработки программ предоставляют большие возможности для создания диалоговых процессов и интерфейса конечного пользователя. Отметим среди них многооконность, наличие различных классов управляющих элементов (кнопки, переключатели и т. д.), возможность программного и ручного (визуального) изменения параметров элементов интерфейса.
Фаза реализации программы осуществляется с помощью выбранных инструментальных средств, основой которых является
язык программирования. Основной задачей этой фазы является программирование, т. е. составление программы на этом языке, удовлетворяющей проекту.
В рассматриваемом в данной главе языке программирования Visual Basic реализована концепция событийно-управляемого программирования. В программе, составленной на этом языке, должны быть описаны объекты и их реакция на различные события.
События заключаются либо в использовании какого-либо управляющего элемента (щелчок мышью по кнопке, перемещение указателя линейки прокрутки и т. п.), либо в действиях, заложенных в программных кодах. Большинство событий связывается с экранными формами (окнами) и расположенными на них управляющими элементами, которые являются объектами и описываются на фазе проектирования. Объектами являются как сами формы, так и расположенные на них элементы. Задача программиста состоит в реализации логики вычислений в соответствии с имеющимися алгоритмами и управлении событиями, возникающими при воздействии на объекты.
Структура программных модулей зависит от выбранного инструментального средства реализации. Приложение, созданное на языке Visual Basic, оформляется в виде совокупности программных модулей следующих уровней:
— модули классов объектов;
— событийные процедуры управляющих элементов, расположенных на форме;
Событийные процедуры и процедуры пользователя не оформляются в виде отдельного файла и поэтому не имеют в своем названии слова «модуль», так как в Visual Basic оно используется лишь для тех программных модулей, для хранения которых создаются отдельные файлы.
Источник: lawbooks.news
Лекция 2-Средства разработки программ. Средства разработки программ средства разработки программного обеспечения
Единственный в мире Музей Смайликов
Самая яркая достопримечательность Крыма
Скачать 319.31 Kb.
СРЕДСТВА РАЗРАБОТКИ ПРОГРАММ
Средства разработки программного обеспечения – совокупность приемов, методов,
методик, а также набор инструментальных программ (компиляторы, прикладные/системные
библиотеки и т.д.), используемых разработчиком для создания программного кода Программы,
отвечающего заданным требованиям.
Разработка программ – сложный процесс, основной целью которого является создание, сопровождение программного кода, обеспечивающего необходимый уровень надежности и качества. Для достижения основной цели разработки программ используются средства разработки программного обеспечения.
ОСНОВНЫЕ СРЕДСТВА, ИСПОЛЬЗУЕМЫЕ НА РАЗНЫХ ЭТАПАХ РАЗРАБОТКИ ПРОГРАММ
В зависимости от предметной области и задач, поставленных перед разработчиками, разработка программ может представлять собой достаточно сложный, поэтапный процесс, в котором задействовано большое количество участников и разнообразных средств. Для того, чтобы определить, когда и в каких случаях какие средства применяются, выделяют следующие основные этапы разработки программного обеспечения:
1.
Проектирование приложения.
2.
Реализация программного кода приложения.
3.
Тестирование приложения.
Средства проектирования приложений
На этапе проектирования приложения в зависимости от сложности разрабатываемого программного продукта, напрямую зависящего от предъявляемых требований, выполняются следующие задачи проектирования:
1.
Анализ требований.
2.
Разработка архитектуры будущего программного обеспечения.
3.
Разработка устройств основных компонент программного обеспечения.
4.
Разработка макетов Пользовательских интерфейсов.
Результатом проектирования обычно является «Эскизный проект» (Software Design
Document) или «Технический проект» (Software Architecture Document).
Задача «Анализ требований» обычно выполняется с использованием методов системологии (анализа и синтеза) с учетом экспертного опыта проектировщика. Результатом анализа обычно является содержательная или формализованная модель процесса функционирования программы. В зависимости от сложности процесса для построения данных моделей могут быть применены различные методы и вспомогательные средства. В общем случае для описания моделей обычно применяются следующие нотации (в скобках приведены программные средства, которые могут быть использованы для получения моделей):
BPMN (Vision 2003 + BPMN, AcuaLogic BPMN, Eclipse, Sybase Power Designer).
Блок-схемы (Vision 2003 и многие другие).
ER-диаграмы (Visio 2003, ERWin, Sybase Power Designer и многие другие).
UML-диаграмы (Sybase Power Designer, Rational Rose и многие другие).
макеты, мат-модели и т.д.
Результаты анализа позволяют сформировать обоснованные требования к той или иной функциональности разрабатываемой программы и просчитать реальную выгоду от внедрения разрабатываемого продукта. Более того, иного получается так, что по результатам анализа первоначальные цели и задачи автоматизации кардинально меняются или по результатам оценки эффективности разработки и внедрения принимается решение продукт не разрабатывать.
Целью второй и третьей задачи из приведенного списка задач является разработка модели
(описания) будущей системы, понятной для кодировщика – человека, который пишет код программы. Здесь огромное значение имеет то, какую парадигму программирования необходимо использовать при написании программы. В качестве примера основных парадигм необходимо привести следующее:
Функциональное программирование;
Структурное программирование;
Императивное программирование;
Логическое программирование;
Объектно-ориентированное программирование (прототипирование; использование классов; субъективно-ориентированное программирование).
Выбор её во многом зависит от сложившихся привычек, опыта, традиций, инструментальных средств, которыми располагает коллектив разработчиков. Иногда разрабатываемый программный продукт настолько сложен, что для решения ряда задач в разных компонентах системы используются разные парадигмы. Выбор того или иного подхода накладывает ограничения на средства, которые будут применены на этапе реализации программного кода. Результатом решения данной задачи в зависимости от подхода могут быть
(в скобках приведены программные средства, которые могут быть использованы для их получения):
диаграмма классов и т.д (Ration Rose, Sybase PowerDisigner и многие другие).
описание модулей структур и их программного интерфейса (например, Sybase
PowerDisigner и многие другие).
Разработка макетов пользовательских интерфейсов подразумевает создание наглядного представления того, как будут выглядеть те или иные видеоформы, окна в разрабатываемом приложении. Решение данной задачи основывается на применение средств дизайнера.
Средства реализации программного кода
На этапе реализации программного кода выполняется кодирование отдельных компонент программы в соответствии с разработанным техническим проектом. Средства, которые могут быть применены, в значительной степени зависит от того, какие подходы были использованы во время проектирования и, кроме этого, от степени проработанности технического проекта. Тем не менее, среди средств разработки программного кода необходимо выделить следующие основные виды средств:
• методы и методики алгоритмирования.
языки программирования (C++,Си, Java, C#, php и многие другие);
средства создания пользовательского интерфейса (MFC, WPF, QT, GTK+ и т.д.)
средства управления версиями программного кода (cvs, svn, VSS).
средства получения исполняемого кода (MS Visual Studio, gcc и многие другие).
средства управления базами данных (Оracle, MS SQL, FireBird, MySQL и многие другие).
отладчики (MS Visual Studio, gdb и т.д.).
Средства тестирования программ
Основными задачами тестирования является проверка соответствия функциональности разработанной программы первоначальным требованиям, а также выявление ошибок, которые в явном или неявном виде проявляются во время работы программы. Среди основных работ по тестированию можно выделить следующее:
Тестирование на отказ и восстановление.
Функциональное тестирование.
Тестирование безопасности.
Тестирование взаимодействия.
Тестирование процесса установки.
Тестирование удобства пользования.
Конфигурационное тестирование.
Нагрузочное тестирование.
Среди основных видов средств, которые могут быть применены для выполнения поставленных работ можно привести следующие:
средства анализа кода, профилирования (Code Wizard – ParaSoft, Purify – Rational
Softawre. Test Coverage – Semantic и т.д.);
средства для тестирования функциональности (TEST – Parasoft, QACenter –
Compuware, Borland SilkTestи т.д.);
средства для тестирования производительности (QACenter Performance –
Compuware и т.д).
Источник: topuch.com
Основные средства, используемые на разных этапах разработки программ
В зависимости от предметной области и задач, поставленных перед разработчиками, разработка программ может представлять собой достаточно сложный, поэтапный процесс, в котором задействовано большое количество участников и разнообразных средств. Для того, чтобы определить, когда и в каких случаях какие средства применяются, выделим основные этапы разработки программного обеспечения. Наибольший интерес для проблематики рассматриваемого вопроса представляют следующие этапы разработки:
- Проектирование приложения.
- Реализация программного кода приложения.
- Тестирование приложения.
Здесь сознательно опущены этапы, связанные с написанием технического задания, планирования сроков, бюджета и т.д. Причина этого заключается в том, что на данных этапах, за редким исключением, практически не используются специфические средства разработки.
78. Различают три вида интерфейсов пользователя: командный, WIMP и SILK — интерфейсы
Командный интерфейс, при котором взаимодействие человека с компьютером осуществляется путем подачи компьютеру команд, которые он выполняет и выдает результат пользователю. Командный интерфейс может быть реализован в виде пакетной технологии и технологии командной строки. В настоящее время пакетная технология практически не используется, а технология командной строки можно встретить в виде резервного способа общения человека с компьютером.
Пакетная технология.
Исторически этот вид технологии появился первым на электромеханических вычислительных машинах К. Цюзе, Г. Айкина, а затем на электронных вычислительных машинах Эккерта и Моучли, на отечественных ЭВМ Лебедева, Брусенцова, на ЭВМ IBM-360, на ЕС ЭВМ и так далее. Идея его проста и состоит в том, что на вход компьютера подается последовательность программ, набитых, например, на перфокартах и последовательность символов, определяющих порядок выполнения этих программ. Человек здесь имеет малое влияние на работу машины. Он может лишь приостановить работу машины, сменить программу и снова запустить ЭВМ.
Технология командной строки.
При этой технологии в качестве способа ввода информации оператором в ЭВМ служит клавиатура, а компьютер выводит информацию человеку с помощью алфавитно-цифрового дисплея (монитора). Комбинацию монитор-клавиатура стали называть терминалом или консолью.
Команды набираются в командной строке, представляющей собой символ приглашения и мигающий курсор, при этом набранные символы можно стирать и редактировать. По нажатию клавиши «Enter» («Ввод») ЭВМ принимает команду и начинает ее выполнять. После перехода в начало следующей строки компьютер выдает на монитор результаты своей работы. Наиболее распространенным командный интерфейс был в операционной системе MS DOS.
ООМУ (окно, образ, меню, указатель) WIMP (window, image, menu, pointer) — интерфейс. Характерной чертой этого интерфейса является то, что диалог пользователя с компьютером ведется не с помощью командной строки, а с помощью окон, графических образов меню, курсора и других элементов. Хотя в этом интерфейсе подаются команды машине, но это делается через графические образы.
Идея графического интерфейса зародилась в средине 70-х годов в исследовательском центре фирмы Xerox Palo Alto Research Center (PARC). Предпосылкой графического интерфейса явилось уменьшение времени реакции компьютера на команду, увеличение объема оперативной памяти, а также развитие элементной базы, технических характеристик ЭВМ и в частности мониторов. После появления графических дисплеев с возможностью вывода любых графических изображений различного цвета графический интерфейс стал неотъемлемой частью всех компьютеров. Постепенно проходил процесс унификации в использовании клавиатуры и мыши прикладными программами. Слияние этих двух тенденций привело к созданию такого пользовательского интерфейса, с помощью которого при минимальных затратах времени и средств на переучивание персонала можно работать с любыми программными приложениями
Этот вид интерфейса реализован в виде двух уровней:
— простой графический интерфейс;
— полный WINP — интерфейс.
Простой графический интерфейс, который на первом этапе очень походил на технологию командной строки со следующими отличиями:
— при отображении символов с целью повышения выразительности изображения допускалось выделение части символов цветом, инверсным изображением, подчеркиванием и мерцанием;
— курсор мог быть представлен некоторой областью, выделенной цветом и охватывающей несколько символов и даже часть экрана;
— реакция на нажатие любой клавиши во многом стало зависеть от того, в какой части находится курсор.
— кроме часто используемых клавиш управлением курсором стали использоваться манипуляторы типа мыши, трекбола и т.п., которые позволяли быстро выделять нужную область экрана и перемещать курсор;
— широкое использование цветных мониторов.
Появление простого графического интерфейса совпадает с широким распространением операционной системы MS DOS. Типичным примером его использования является файловая оболочка Norton Commander и текстовые редакторы MaltiEdit, ChiWriter, Microsoft Word для DOS, Лексикон и др.
Полный WIMP-интерфейс, явился вторым этапом развития графического интерфейса, который характеризуется следующими особенностями:
— вся работа с программами, файлами и документами происходит в окнах;
— программы, файлы, документы, устройства и другие объекты представляются в виде значков (иконок), которые при открытии превращаются в окна;
— все действия с объектами осуществляются с помощью меню, которое становится основным элементом управления;
— манипулятор выступает в качестве главного средства управления.
Следует отметить, что WIMP-интерфейс требует для своей реализации повышенного требования к производительности компьютера, объему его памяти качественного растрового цветного дисплея программного обеспечения, ориентированного на этот вид интерфейса. В настоящее время WIMP-интерфейс стал стандартом де-факто, а операционная система Microsoft Windows стала ярким его представителем.
РОЯЗ (речь, образ, язык, знания) SILK (speech, image, language, knowledge) — интерфейс. Этот интерфейс наиболее приближен к обычной человеческой форме общения. В рамках этого интерфейса идет обычный разговор человека и компьютера. При этом компьютер находит для себя команды, анализируя человеческую речь и находя в ней ключевые фразы.
Результаты выполнения команд он также преобразует в понятную человеку форму. Этот вид интерфейса требует больших аппаратурных затрат, поэтому находится в стадии разработки и совершенствования и используется пока только в военных целях.
SILK- интерфейс для общения человека с машиной использует:
— речевую технологию;
— биометрическую технологию (мимический интерфейс);
— семантический (общественный) интерфейс.
Речевая технология появилась в середине 90-х годов после появления недорогих звуковых карт и широкого распространения технологий распознавания речи. При этой технологии команды подаются голосом путем произнесения специальных стандартных слов (команд), которые должны выговариваться четко, в одном темпе с обязательными паузами между словами. Учитывая, что алгоритмы распознавания речи недостаточно развиты, требуется индивидуальная предварительная настройка компьютерной системы на конкретного пользователя. Это простейшая реализация SILK- интерфейса.
Биометрическая технология («Мимический интерфейс») возникла в конце 90-х годов и в настоящее время находится в стадии разработки. Для управления компьютером используется выражение лица, направление взгляда, размер зрачка и другие признаки человека. Для идентификации пользователя используется рисунок радужной оболочки его глаз, отпечатки пальцев и другая уникальная информация, которая считывается с цифровой камеры, а затем с помощью программы распознавания образов из этого изображения выделяются команды.
Семантический (общественный) интерфейс возник еще в конце 70-х годов ХХ века, с развитием искусственного интеллекта. Его трудно назвать самостоятельным видом интерфейса, так как он включает в себя и интерфейс командной строки, и графический, и речевой, и мимический интерфейсы. Основной его особенностью является отсутствие команд при общении с компьютером.
Запрос формируется на естественном языке, в виде связанного текста и образов. По сути — это моделирование общения человека с компьютером. В настоящее время используется для военных целей. Такой интерфейс крайне необходим в обстановке ведения воздушного боя.
В настоящее время наиболее актуально изучение технологии WIMP-интерфейса, так как он наиболее часто используемый для всех типов компьютеров. Основное внимание будет уделяться программной части интерфейса пользователя, в которой важным звеном является человеческая часть.
Наши компьютеры и сотовые телефоны, оснащенные самыми последними моделями чипов и другой электронной начинкой. Современные операционные системы способны радовать глаз великолепными цветными заставками и стремительными трехмерными эффектами, но когда Вы начинаете пользоваться этой системой, выясняется, что в некоторых случаях она ограничивает вас своим непредсказуемым поведением. Из тысячи команд, предусмотренных в системе, вам не удается найти ту, которая нужна в данный момент, а простые стандартные процедуры выполняются бесконечно долго. Разрешение этого противоречия лежит в разработке удачного интерфейса пользователя. В основе разработки хороших интерфейсов лежат принципы, которые на сегодня не являются общеизвестными.
Несмотря на то, что интерфейсы непрерывно совершенствовались в течение двух десятилетий, опубликованы руководства по созданию интерфейсов и созданы средства их разработки проблема совершенствования интерфейсов пользователя с учетом более глубоких познаний менталитета и психологии пользователя является актуальной. Тем более что проблема разработки однопользовательских интерфейсов еще не решена, а если индивидуальное взаимодействие с некоторой системой не проходит для пользователя легко и комфортно, то в результате этот недостаток будет негативно отражаться на качестве работы всей системы, независимо от того насколько она хороша в других своих проявлениях.
Ути́лита (англ. utility или tool) — компьютерная программа, расширяющая стандартные возможности оборудования и операционных систем, выполняющая узкий круг специфических задач.
Утилиты предоставляют доступ к возможностям (параметрам, настройкам, установкам), недоступным без их применения, либо делают процесс изменения некоторых параметров проще (автоматизируют его).
Источник: allrefrs.ru