Агентное программирование
Понятие интеллектуального и программного агента появилось более 20 лет назад, их роль в программной инженерии все время возрастает [25-–29]. Так, в [30] Джекобсон отметил перспективу для использования агентов в качестве разработчиков архитектуры системы из вариантов использования, менеджеров проекта и др. Использование агентов в этих ролях в ближайшем будущем будет способствовать повышению производительности, качества и ускорению разработки ПС.
Основным теоретическим базисом данного программирования являются темпоральная, модальная и мультимодельная логики, дедуктивные методы доказательства правильности свойств агентов и др. Рассмотрим сущность основных прикладных аспектов агентной тематики.
С точки зрения программной инженерии, агент это самодостаточная программа, способная управлять своими действиями в информационной среде функционирования для получения результатов выполнения поставленной задачи и изменения текущего состояния среды.
Агент может обладать такими свойствами:
– автономность – это. способность действовать без внешнего управляющего воздействия;
– реактивность – это способность реагировать на изменения данных и среды, и воспринимать их;
– активность – это способность ставить цели и выполнять заданные действия для достижения этой цели;
– социальность – это способность к взаимодействию с другими агентами (или людьми).
В задачи программного агента входят:
– самостоятельная работа и контроль своих действий;
– взаимодействие с другими агентами;
– изменение поведения в зависимости от состояния внешней среды;
– выдача достоверной информации о выполнении заданной функции и т.п.
С интеллектуальным агентом связываются знания типа: убеждение, намерение, обязательства и т.п. Эти понятия входят в концептуальную модель и связываются между собой операционными планами реализации целей каждого агента. Для достижения целей интеллектуальные агенты взаимодействуют друг с другом, устанавливают связь между собой через сообщения или запросы и выполняют заданные действия или операции в соответствии с имеющимися знаниями.
Агенты могут быть локальными и распределенными. Процессы локальных агентов протекают в клиентских серверах сети, выполняют заданные функции и не влияют на общее состояние среды функционирования. Распределенные агенты, расположенные в разных узлах сети, выполняют автономно (параллельно, синхронно, асинхронно) предназначенные им функции и могут влиять на общее состояние среды. В обоих случаях характер взаимодействия между агентами зависит от таких факторов: совместимость целей, компетентность, не стандартные ситуации т.п. [27] (рис.5.5).
Рис.5.5 Пример взаимодействия агентов в разных средах
Основу агентно–ориентированного программирования составляют:
– формальный язык описания ментального состояния агентов;
– язык спецификации информационных, временных, мотивационных и функциональных действий агента в среде функционирования;
– язык интерпретации спецификаций агента;
– инструменты конвертирования любых программ в соответствующие агентные программы.
Агенты взаимодействуют между собой с помощью разных механизмов взаимодействия, а именно, координация, коммуникация, кооперация или коалиция.
Под координацией агентов понимается процесс обеспечения последовательного функционирования при согласованности их поведения и без взаимных конфликтов. Координация агентов определяется:
– взаимозависимостью целей других агентов–членов коалиции, а также от возможного влияния агентов друг на друга;
– ограничениями, которые принимаются для группы агентов коалиции в рамках общего их функционирования;
– компетенцией – знаниями условий среды функционирования и степени их использования.
Главным средством коммуникации агентов является транспортный протокол ТСР/IP или протокол агентов ACL (Agent Communication Languages). Управления агентами (Agent Management) выполняется с помощью таких сервисов: передача сообщений между агентами, доступ агента к серверу и т.п.
Коммуникация агентов базируется на общем протоколе, языке HTML и декларативном или процедурном (Java, Telescript, ACL и т.п.) языке описания этого протокола.
Примером активного использования агентов является Интернет. В нем агенты обеспечивают доступ к информации, расположенной в информациооных ресурсах Интернет, анализ, фильтрацию и передачу клиенту результат запроса. В результате выполнения этих функций агенты создают некоторое поведение среды, которое в любой момент времени находится в некотором состоянии, а агент, выполняя заданные действия, изменяет его в целевое состояние и учитывает возможность возникновения нерегулярных состояний (тупиков, отсутствия ресурса и др.).
Одной из систем построения агентов, основанной на обмене сообщениями в АСL, является JATLite. Она включает Java–классы для создания новых агентов, ориентированных на вычисление функций в распределенной среде. Система Agent Builder предназначена для конструирования программных агентов, которые описываются в языке Java и могут взаимодействовать на основе языка KQML (Knowledge Guery and Manipulation Language). Построенные агенты выполняют функции: менеджера проекта и онтологий, визуализации, отладки и др. На реализацию механизмов взаимодействий агентов ориентирована и система JAFMAS. Ряд мультиагентных систем описано в [44].
Алгебраическое программирование (АП)
АП обеспечивает описание процессов конструирования программ, алгебраические преобразования, доказательство математических теорем и создание интеллектуальных агентов с помощью математиского аппарата, в качестве которого используется понятие транзитивной системы [31–34].
Данный аппарат позволяет определить поведение систем и их эквивалентность. В качестве транзитивных систем в общем случае могут быть компоненты, программы и их спецификации, объекты, взаимодействующие друг с другом и со средой их существования.
Эволюция такой системы описывается с помощью истории функционирования систем, которая может быть конечной или бесконечной, и включать обзорную часть в виде последовательности действий и скрытую часть в виде последовательности состояний. История функционирования включает в себя успешное завершение вычислений в среде транзитивной системы, тупиковое состояние, когда каждая из параллельно выполняющихся частей системы находятся в состоянии ожидания событий и, наконец, неопределенное состояние, возникающее при выполнении алгоритма, например, с бесконечными циклами.
Расширением понятия транзитивных систем является множество заключительных состояний с успешным завершением функционирования системы и без неопределенных состояний.
Главным инвариантом состояния транзитивной системы является поведение системы, которое можно задать выражениями алгебры поведения F(A) на множестве операций алгебры А, а именно две операции префиксинга a× u, задающие поведение u на операции а, недетерминированный выбор u+v одной из двух поведений u и v, который является ассоциативным и коммутативным. Конечное поведение задается константами: D, ^, 0, обозначающими соответственно состояние успешного завершения, неопределенного и тупикового состояния.
Алгебра поведения частично задается отношением £, для которого элемент ^ является наименьшим, а операции алгебры поведения – монотонными. Теоретически алгебра поведения F(A) проверена путем доказательства теоремы про наименьшую неподвижную точку.
Транзитивные системы называют бисимуляцийно эквивалентными, если каждое состояние любой из них эквивалентно состоянию другой системы. На множестве
поведений определяются новые операции, которые используются для построения программ агентов. К ним относятся операции: последовательная композиция (u; v) и параллельная композиция u//v.
Среда Е, где находится объект, определяется как агент в алгебре действий А и функции погружения от двух аргументов Ins(e, u) = e[u]. Первый аргумент – это поведение среды, второй – поведение агента, который погружается в эту среду в заданном состоянии. Алгебра агента – это параметр среды. Значения функций погружения – это новое состояние одной и той же среды.
Разработанная общая теория выходит за рамки определения вычислительных и распределенных систем, а также механизмов взаимодействия со средой. Базовым понятием является “действие”, которое трансформирует состояние агентов, поведение которых, в конце концов, изменяется.
Поведение агентов характеризуется состоянием с точностью до бисимиляции и, возможно, слабой эквивалентности. Каждый агент рассматривается как транзитивная система с действиями, определяющими не детерминированный выбор и последовательную композицию (т.е. примитивные и сложные действия).
Взаимодействие агентов может быть двух типов. Первый тип выражается через параллельную композицию агентов над той же самой областью действий и соответствующей комбинацией действий. Другой тип выражается через функцию погружения агента в некоторую среду; результатом трансформации является новая среда.
Язык действий А имеет синтаксис и семантику. Семантика – это функция, определяемая выражениями языка и ставящая в соответствие программным выражениям языка значения в некоторой семантической области. Разные семантические функции дают равные абстракции и свойства программ. Семантика может быть вычислительной и интерактивной. Доказано, что каждая алгебра действий есть гомоморфным образом алгебры примитивных действий, когда все слагаемые разные, а представление однозначно с точностью до ассоциативности и коммутативности в детерминированном
выборе. Установлено, что последовательная композиция – ассоциативная, а параллельная композиция – ассоциативная и коммутативная. Параллельная композиция раскладывается на комбинацию действий компонентов.
Агенты рассматриваются как значения транзитивных систем с точностью до бисимиляционной эквивалентности. Эквивалентность характеризуется в алгебре поведения непрерывной алгеброй с аппроксимацией и двумя операциями: не детерминированным выбором и префиксингом. Среда вводится как агент, куда погружения функция, имеет поведение типа агент и среды. Произвольные непрерывные функции могут быть использованы как функции погружения и эти функции, определены значениями логики переписывания. Трансформации поведения среды, которые определяются функциями погружения, составляют новый тип эквивалентности – эквивалентность погружения.
Создание новых методов программирования с введением агентов и сред позволяет интерпретировать элементы сложных программ как самостоятельно взаимодействующие объекты.
В АП интегрируется процедурное, функциональное и логическое программирование, используются специальные структуры данных – граф термов, который разрешает использовать разные средства представления данных и знаний о ПрО в виде выражений многоосновной алгебры данных.
Наибольшую актуальность имеют системы символьных вычислений, которые дают возможность работать с математическими объектами сложной иерархической структуры. Многие алгебраические структуры (группы, кольца, поля) являются иерархически – модулярными. Теория АП обеспечивает создание математической информационной среды с универсальными математическими конструкциями, вычислительными механизмами, учитывающими особенности разработки ПС и функционирования. АП является основой формирования нового вида программирования – инсерционного, обеспечивающего программирование систем на основе моделей поведения агентов, транзитивных систем и бисимуляционной эквивалентности [14].
Техника программирования в системе алгебраического программирования АПС использует аппарат переписывания терминов, необходимого при автоматизации доказательства теорем, символьных вычислениях, обработки алгебраических спецификаций.АПС реализован. мониторинг данных, моделирование ситуации, условное прерывание, управление экспериментами и др.
Алгоритмика программ
На протяжении многих лет Цейтлин Г.Е. занимается разработкой теоретических аспектов алгоритмов, представляемых блок–схемами, как способа детализации и
реализации алгоритмов. Аппарат блок–схем пополнен математическими формулами, свойственными математике, которые используются при аналитических преобразованиях и обеспечивают улучшение качества алгоритмов [40–42].
Построение и исследование алгебры алгоритмов впервые осуществил В.М. Глушков в рамках проектирования логических структур ЭВМ. В результате была построена теория систем алгоритмических алгебр (САА), которая затем была положена в основу обобщенной теории структурированных схем алгоритмов и программ, называемой теперь алгоритмикой [41].
Объектами алгоритмики являются модели алгоритмов и программ, представляемые в виде схем. Метод алгоритмики базируется на компьютерной алгебре и логике и используется для проектирования алгоритмов прикладных задач. Построенные алгоритмы описываются с помощью ЯП и реализуются соответствующими системами программирования в машинное представление.
В рамках алгоритмики разработаны специальные инструментальные средства реализации алгоритмов, которые базируются на современных объектно–ориентированных средствах и методе моделирования UML. Тем самым обеспечивается полный цикл работ по практическому применению разработанной теории алгоритмики при реализации прикладных задач, начиная с постановки задачи, формирования требований и разработки алгоритмов до получения программ решения этих задач.
Алгебра алгоритмов. Под алгеброй алгоритмов АА= {A, W} понимается основа А и сигнатура W операций над элементами основы алгебры. С помощью операции сигнатуры может быть получен произвольный элемент q Î AА, который называется системой образующих алгебры. Если из этой системы не может быть исключен ни один элемент без нарушения ее свойств, то такая система образующих называется базисом алгебры.
Операции алгебры удовлетворяют следующим аксиоматическим законам: ассоциативности, коммутативности, идемпотентности, закону исключения третьего, противоречия и др.
Алгебра, которой удовлетворяют перечисленные операции, называется булевой.
В алгебре алгоритмов используется алгебра множеств, элементами которой являются множества и операции над множествами (объединение, пересечение, дополнение, универсум и др.).
Основным объектами алгебры алгоритимки являются схемы алгоритмов и их суперпозиции, т.е. подстановки одних схем в другие. С подстановкой связана развертка, которая соответствует нисходящему процессу проектирования алгоритмов, и свертка, т.е. переход к более высокому уровню спецификации алгоритма. Схемы алгоритмов соответствуют конструкциям структурного программирования:
Последовательное выполнение операторов А и В записывается в виде композиции А*В; альтернативное выполнение операторов А и В (fu (А, В)) означает, если u истинно, то выполняется А иначе В; цикл (u (А, В)) выполняется, пока не станет истинным условие u (u – логическая переменная). С помощью этих элементарных конструкций строиться более сложная схема P алгоритма:
P ::= ((u1 ) А1}},
А1 ::= { (u2 ) А2 * D}
А2 ::= А3 * C,
А3 ::= { (u ) А, B}, u::= u2 Ù u1.
Проведя суперпозицию путем свертки приведенной схемы алгоритма P, получается формула:
P ::= ( u1 ) (u2 ) ( (u2 Ù u1) А, В ) * С * D).
Важным результатом является сопоставительный анализ аппарата алгебры алгоритмики и следующих известных алгебр.
Алгебра Дейкстры АД = {АСС, L(2), СИГН} – двухосновная алгебра, основными элементами которой являются множество АСС операторов, представленных структурными блок–схемами, множество L(2) булевых функций в сигнатуре СИГН, в которую входят операции дизъюнкции, конъюнкции и отрицания, принимающие значения из L(2). С помощью специально разработанных механизмов преобразования АД в алгебру алгоритмики установлена связь между альтернативой и циклом, т.е. ((u ) А} = ((u ) Е, А * ((u ) А}}, произвольные операторы представлены суперпозицией основных операций и констант.
Операция фильтрации Ф (u ) = ((u ) Е, N} в АД представлена суперпозицией тождественного Е и неопределенного N операторов и альтернативы алгебры алгоритмики, где N – фильтр разрешения выполнения операций вычислений. Оператор цикла while do также представлен суперпозицией операций композиции и цикла в алгебре алгоритмики.
Алгебра схем Янова АЯ включает в себя операции построения неструктурных логических схем программ. Схема Янова состоит из предикатных символов множества P{p1, p2,…), операторных символов множества A{a1, a2,…} и графа переходов. Оператором в данной алгебре есть пара A{p}, состоящая из символов множества А и множества предикатных символов. Граф перехода представляет собой ориентированный граф, в вершинах которого располагаются преобразователи, распознаватели и один оператор останова. Дуги графа задаются стрелками и помечаются они знаками + и –.
Преобразователь имеет один преемник, а распознаватель – два. Каждый распознаватель включает в себя условие выполнения схемы, а преобразователь представляет операторы, включающие логические переменные, принадлежащие множеству {p1, p2,…).
Каждая созданная схема АЯ отличается большой сложностью, требует серьезного преобразования при переходе к представлению программы в виде соответствующей последовательности действий, условий перехода и безусловного перехода. В работе [86] разработана теория интерпретации схем Янова и доказательство эквивалентности двух операторных схем исходя из особенностей алгебры алгоритмики.
Для представления схемы Янова аппаратом алгебры алгоритмики сигнатура операций АЯ вводятся композиции А* В и операции условного перехода, который в зависимости от условия u выполняет переход к следующим операторам или к оператору помеченному меткой (типа goto). Условный переход трактуется как бинарная операция P (u, F), которая зависит от условия u и разметок схемы F. Кроме того, производится замена альтернативы и цикла типа while do.
В результате выполнения бинарных операций получается новая схема F’, в которой установлена P (u) вместо метки и булевы операции конъюнкции и отрицания. Эквивалентность выполненных операций преобразования обеспечивает правильность неструктурного представления.
Система алгебр Глушкова АГ = {ОП, УС, СИГН}, где ОП и УС – множество операторов суперпозиции, входящих в сигнатуру СИГН, и логических условий, определенных на информационном множестве ИМ, СИГН = {СИГНад È Прогн.}, где
СИГНад – сигнатура операций Дейкстры, а Прогн. – операция прогнозирования. Сигнатура САА включает в себя операции алгебры АД, операции обобщенной трехзначной булевой операции и операцию прогнозирования (левое умножение условия на оператор u = (А* u’), порождающая предикат u = УС такой, что u(m) = u’( m’), m’ = А (m), А ÎОП. ИМ – множество обрабатываемых данных и определения операций из множеств ОП и УС. Сущность операция прогнозирования состоит в проверке условия u в состоянии m оператора А и определения условия u’, вычисленного в состоянии m’ после выполнения оператора А.Данная алгебра ориентирована на аналитическую форму представления алгоритмов и оптимизацию алгоритмов по выбранным критериям.
Алгебра булевых функций и связанные с ней теоремы о функциональной полноте и проблемы минимизации булевых функций также сведены до алгебры алгоритмики. Этот специальный процесс отличается громоздкостью, и рассматриваться не будет, можно только отослать к главному источнику [86].
Алгебра алгоритмики и прикладные подалгебры. Алгебра алгоритимки пополнена двухуровневой алгебраической системой и механизмами абстрактного описания данных (классами алгоритмов). Под многоосновной алгоритмической системой (МАС) понимается система S ={{Di÷ iÎI }; СИГН0 , СИГНn }, где Di –основы или сорта, СИГН0 , СИГНn – совокупности операций и предикатов, определенных на Di .Если они пусты, то определяются многоосновные модели – алгебры. Если сорта интерпретируются как множество обрабатываемых данных, то МАС представляет собой концепцию АТД, в виде подалгебры, широко используемую в объектно–ориентированном программировании.Тем самым устанавливается связь с современными тенденциями развития современного программирования.
Практическим результатом исследований алгебры алгоритмики является построение оригинальных инструментальных систем проектирования алгоритмов и программ на основе современных средств поддержки ООП.
Читателям данной темы предоставляется возможность познакомиться более подробно с приведенными источниками.
Анализ и характеристика областей знаний SWEBOK
Ядра знаний SWEBOK [20] является основополагающим документом, отображает мнение многих зарубежных и отечественных специалистов в области программной инженерии [3-13] и согласуется с современными регламентированными процессами ЖЦ ПО стандарта ISO/IEC 12207. В этом ядре знаний содержится описание 10 областей, каждая из которых представлена согласно принятой всеми участниками создания этого ядра общей схемы описания, включающей определение понятийного аппарата, методов и средств, а также инструментов поддержки инженерной деятельности. Описание каждой области вносит определенный запас знаний, который должен практически использоваться на соответствующих процессах ЖЦ с учетом приведенного стандарта.
Для наглядного представления понятийного аппарата областей SWEBOK проведено условное разбиение областей (рис. 1.а, б.) на основные (пять процессов проектирования ПС) и дополнительные, организационные методы и подходы, которые отображают инженерию управления проектированием ПС (конфигурацией, проектами, качеством и т.д.). В каждой области приведены ключевые понятия, подходы и методы проектирования разных типов ПС. Данное разбиение областей на главные и вспомогательные области соответствует структуре процессов стандарта ISO/IEC 12207 (см. подраздел 2), выполнение которых определяется знаниями, содержащимися в ядре SWEBOK и изученными разработчиками ПС.
Далее приводится изложение каждой в отдельности области знаний ядра знаний SWEBOK, их назначение и роль при проектировании и реализации программных продуктов.
В некоторых разделах данной главы показана связь с положениями соответствующих стандартов, которые регламентируют и регулируют выполнение процессов проектирования ПС разных видов программных систем.
Анализ и оценка качества проектирования ПО
Анализ и оценка качества проектирования ПО включает мероприятия по анализу сформулированных в требованиях атрибутов качества, оценки различных аспектов ПО – размера и структуры ПО, функций и качества проектирования с помощью формальных метрик (функционально-ориентированных, структурных и объектно-ориентированных), а также проведения качественного анализа результатов проектирования путем статического анализа, моделирования и прототипирования.
Нотации проектирования позволяют представить артефакты ПО и его структуру, а также поведение системы. Существует два типа нотаций: структурные, поведенческие и множество различных их представлений.
Структурные нотации являются графическими, они используются для представления структурных аспектов проектирования, компонентов и их взаимосвязей, элементов архитектуры и их интерфейсов. К ним относятся формальные языки спецификаций и проектирования: ADL (Architecture Description Language), UML (Unified Modeling Language), ERD (Entity–Relation Diagrams), IDL (Interface Description Language), классы и объекты, компоненты и классы (CRC Cards), Use Case Driven и др. Нотации включают языки описания архитектуры и интерфейса, диаграммы классов и объектов, диаграммы сущность-связь, компонентов, развертывания, а также структурные диаграммы и схемы.
Поведенческие нотации отражают динамический аспект поведения систем и их компонентов. Таким нотациям соответствуют диаграммы: Data Flow, Decision Tables, Activity, Colloboration, Pre-Post Conditions, Sequence, таблицы принятия решений, формальные языки спецификации, языки проектирования PDL и др.
Стратегия и методы проектирования ПО. Данный раздел знаний представляет различные стратегии и методы, которые используются при проектировании. К общим стратегиям относятся: снизу-вверх, сверху–вниз, абстракции, паттерны и др. Функционально–ориентированные (структурные) методы базируются на структурном анализе, структурных картах, Dataflow-диаграммах и др.
Анализ и сбор требований
В современных информационных технологиях процесс ЖЦ, на котором фиксируются требования на разработку ПО системы, является определяющим для задания функций, сроков и стоимости работ, а также показателей качества и др.
Анализ и сбор требований является довольно нетривиальной задачей, поскольку в реальных проектах приходится сталкиваться с такими общими трудностями:
– требования не всегда очевидны и могут исходить из разных источников, их не всегда удается ясно выразить словами;
– имеется много различных типов требований на различных уровнях детализации и их число может стать большим, требующим ими управлять;
– требования связаны друг с другом, а также с процессами разработки ПС и постоянно меняются.
Требования имеют уникальные свойства или значения свойств. Например, они не являются одинаково важными и простыми для согласования.
Аналитик системы, который занимается анализом и составлением требований, должен иметь определенные знания ПрО и навыки, чтобы справиться с этими трудностями. Он должен уметь:
– анализировать проблему,
– понимать потребности заказчика и пользователей,
– определять функции системы и требования к ним,
– управлять контекстом проекта и изменением требований.
В требованиях к ПС должны отображаться проблемы системы и фиксироваться реальные потребности заказчика, касающиеся функциональных, операционных и сервисных возможностей разрабатываемой системы. В результате создается договор между заказчиком и исполнителем системы на ее создание.
Здесь цена ошибок и нечетких неоднозначных формулировок очень высока, поскольку время и средства могут расходоваться на ненужную заказчику систему или программу. Для внесения изменений в требования может потребоваться повторное проектирование и, соответственно, перепрограммирование всей системы или отдельных ее частей. Как утверждает статистика, процент ошибок в постановке требований и в определении задач системы превышает процент ошибок кодирования.
Это является следствием субъективного характера процесса формулирования требований и отсутствия способов его формализации. К примеру, в США ежегодно расходуется до $ 82 млрд. на проекты, признанные после реализации не соответствующими требованиям заказчиков.
Существуют стандарты на разработку требований на систему и документы, в которых фиксируются результаты создания программного, технического, организационного и др. видов обеспечения автоматизированных систем (АС) на этапах жизненного цикла, включающие. В приложении 2, 3 дается краткое описание ГОСТ 34.601-90 «Стадии и этапы разработки АС» и ГОСТ 34.201-89 «Документация на разработку АС».
В процессе формулирования требований на систему принимают участие:
– представители от заказчика из нескольких профессиональных групп;
– операторы, обслуживающие систему;
– разработчики системы.
Процесс формулирования требований состоит из нескольких подпроцессов? Сбор и анализ требований.
Сбор требований. Источниками сведений о требованиях могут быть:
– цели и задачи системы, которые формулирует заказчик. Для однозначного их понимания разработчику системы необходимо их тщательно осмыслить и согласовать с заказчиком;
– действующая система или коллектив, выполняющий ее функции. Система, которую заказывают, может заменять собою старую систему, переставшую удовлетворять заказчика или действующий персонал. Изучение и фиксация ее функциональных возможностей дает основу для учета имеющегося опыта и формулирования новых требований к системе. При этом имеется определенная опасность перенесения недостатков старой системы в новую, поэтому нужно уметь отделить новые требования к реализуемой проблеме от заложенных неудачных решений в старой системе.
Таким образом, требования к системе формулируются исходя из:
– знаний заказчика относительно проблемной области, формулирующего свои проблемы в терминах понятий этой области;
– ведомственных стандартов заказчика и требований к среде функционирования будущей системы, ее исполнительских и ресурсных возможностей.
Методами сбора требований являются:
– интервью с носителями интересов заказчика и операторами;
– наблюдение за работой действующей системы с целью отделения ее проблемных свойств от тех, которые обусловлены структурою кадров;
– сценарии (примеров) возможных случаев выполнении ее функций, ролей лиц, запускающих эти сценарии или взаимодействующих с системой во время ее функционирования.
Продукт процесса сбора требований – неформализованное их описание – основа контракта на разработку между заказчиком и исполнителем системы. Такое описание является входом для следующего процесса инженерии требований - анализа требований. Исполнитель этого процесса выполняет дальнейшее уточнение и формализацию требований, а также их документирование в нотации, понятной коллективу разработчиков системы.
Анализ требований. Это процесс изучения потребностей и целей пользователей, классификация и их преобразование к требованиям системы, к ПО, установление и разрешение конфликтов между требованиями, определение приоритетов, границ системы и принципов взаимодействия со средой функционирования. Требования классифицируются по функциональному и нефункциональному принципу, а также по отношению их в внешней или внутренней стороне системы.
Функциональные требования относятся к заданию функций системы или ее ПО, к , способам поведения ПО в процессе выполнения функций и методам преобразования входных данных в результаты.
Нефункциональные требования определяют условия и среду выполнения функций (например, защита и доступ к БД, секретность, взаимодействие компонентов функций и др.).
Разработанные требования специфицируются и отражается в специальном документе, по которому проводится согласование требований для достижения взаимопонимания между заказчиком и разработчиком.
Функциональные требования отвечает на вопрос "что делает система", а нефункциональные требования определяют характеристики ее работы (вероятность сбоя системы, защита данных и др.).
К основным нефункциональным требованиям, существенным для большинства ПС и выражающих ограничения, актуальные для многих проблемных областей относятся:
– конфиденциальность;
– отказоустойчивость;
– несанкционированный доступ к системе;
– безопасность и защита данных;
– время ожидания ответа на обращение к системе;
– свойства системы (ограничение на память, скорость реакции при обращении к системе и т. п.).
Для большинства этих ограничений может быть зафиксирован спектр характерных понятий – дескрипторов, которые используются для наименования и раскрытия смыслового названия. Состав дескрипторов для ряда нефункциональных требований зафиксирован в соответствующих международных и ведомственных стандартах, которые позволяют избежать неоднозначности в их толковании.
Функциональные требования отражают семантические особенности проблемной области, а терминологические расхождения для них являются достаточно существенными. Имеется тенденция к созданию стандартизации понятийного базиса большинства проблемных областей, которые имеют опыт компьютеризации.
Следующий шаг анализа требований - установление их приоритетов и избежание конфликтов между ними.
Продукт процесса анализа – построенная модель проблемы, которая ориентирована на понимание этой модели исполнителем до начала проектирования системы.
К настоящему времени сложилось направление в инженерии программирования – инженерия требования, сущность которой достаточно подробно рассмотрена в соответствующей области знаний ядра SWEBOK и приводится ниже.
Анализ результатов дистанционного обучения
По инициативе и в рамках Украинской Ассоциации Производителей ПО (УАППО) было создано (март 2003г.) Украинский Учебно-Практический Центр Программной Инженерии [33], учебная программа [34], основная целью которой была подготовка менеджеров программных проектов, руководителей проектов за счет овладения знаниями, представленными в ядре знаний SWEBOK, а также знаний методам современного программирования .
Обучением было охвачено 35 человек. Первоначально в обучение включились 5 человек (руководители групп разработчиков ПО, инженеры, программисты и др.). Они не были знакомы с базисом дисциплины – программная инженерия и начали обучение именно с этого курса. Содержание тем учебной программы по замыслу составлялось очень коротким, чтобы учащийся самостоятельно изучал дополнительную литературу. В частности по этому курсу предлагалась в качестве основной литературы – оригинал материала SWEBOK – knowledge areas.
Анализ дистанционной коммуникации преподавателей и учащихся позволил выделить следующие факты:
– отсутствие необходимых коммуникативных навыков и базовых знаний у значительной части обучающихся;
– высокая эффективность в обучении формальному представлению пилотных проектов; – многие учащиеся продемонстрировали качество выполнения заданий и в краткие сроки;
– выявление учащихся, не имеющих способностей к управленческой деятельности в ИТ сфере.
По результатам обучения можно сделать следующие выводы:
– предварительное повышение квалификации учащихся до уровня базового с постепенным переходом к изучению курсов основной программы.
– постепенное наращивание сложности практических заданий для выработки необходимых навыков.
– увеличение объема вводных лекций для каждой темы.
– предоставление шаблонов выполнения практических заданий.
Формирование электронной библиотеки материалов (включая выполненные практические задания) на курсам программы обучения.
Построение схемы обучения сотрудников компании, совместно с консалтингом по улучшению процессов разработки этой компанией программных проектов.
Значительную помощь в дистанционном процессе обучения оказали специальные фонды при общественных и коммерческих организациях, заинтересованных в подготовке квалифицированных ИТ–специалистов.
Анализ системы знаний у ИТ–специалистов
Вопрос обучения специалистов, занимающихся разработкой и внедрением информационных технологий (ИТ- специалистов), дискутируется много лет [22-28]. Считается, что обучение должно быть поставлено таким образом, чтобы ИТ - специалисты обладали не только фундаментальными знаниями в области computer science, но и достигали баланса между эффективными и жесткими сроками, широтой функциональных возможностей продукта и его низкой ценой, многообразием потребностей пользователей и ограничениями архитектур, постоянно повышали свою квалификацию. Во всем мире сохраняется высокая потребность в квалифицированных специалистах в области ИТ (информационных технологий). Сфера образования должна готовить специалистов, которые могли бы приступать к производственной деятельности сразу после получения диплома для удовлетворения этой потребности.
Одной из наиболее серьезных проблем, является подбор специалистов на руководящие должности: директоров информационных служб, руководителей проектов и технологов. Руководители бизнес–проектов отмечают, что выпускники технических специальностей университетов не имеют навыков управления и знаний современных технологии, что не позволяет им управлять проектами в области ИТ. Специалисты, обладающие навыками управления, как правило, не обладают актуальными фундаментальными знаниями, не знают специфики информационных и компьютерных ресурсов и зачастую пытаются решить проблемы проекта с помощью стандартных инженерных или управленческих методов, что приводит к серьезным управленческим ошибкам. Как свидетельствует статистика [1], в итоге более 42% проектов проваливаются или не укладываются в заданную стоимость и сроки.
Другой серьезной проблемой является, как указывалось выше, существующие отличия программной инженерии от классических инженерных дисциплин. Постоянное изменение предмета изучения и большой объем фундаментальных знаний, для непосредственного создания информационных систем требуются знания. Современный ИТ-специалист, в первую очередь, сам использует богатый арсенал программных средств, в результате производительность труда возросла многократно, и значительно возросла ответственность, лежащая на каждом специалисте и требования к его квалификации.
С другой стороны информационные системы тоже изменились, они стали значительно сложнее, объем требуемых знаний для построения и использования настолько возрос, что потребовалась значительная специализация ИТ-специалистов для обеспечения достижения необходимых результатов. Как правило, большинство систем требует эффективной работы большого коллектива высококвалифицированных специалистов.
Таким образом, ИТ-специалисты должны знать основополагающие принципы и системные подходы к решению вопросов разработки, внедрения и вывода информационных систем из эксплуатации, управления требованиями [9], рисками, качеством и конфигурацией [13], интеграцией информации/компонентов [11], тестированием и метрическим анализом готовых систем [13]. ИТ-специалисты должны уметь эффективно работать в команде разработчиков, выбирать адекватные задачам процессы и технологии. Для распределенных проектов особые требования предъявляются к навыкам невербальной коммуникации.
ИТ-специалисты, занимающие руководящие должности, должны знать общие методы, стандарты ЖЦ ПО и качества, инструменты проектирования компьютерных систем [5–12], а также инфраструктуру организации-разработчика (оборудование, связи, интерфейсы и т.п.), уровни зрелости организации (коллектива) в соответствии с моделью CMM (Capability Maturity Model [29, 30]), базовые понятия программной инженерии SWEBOK [4] и другие действующие отечественные и международные стандарты.
Ключевыми дисциплинами получения знаний студентов на современных факультетах информатики, ориентированных на разработку ПО, являются: программирование и языки программирования, как формальные математические объекты, дискретная математика Кнута, основы математической логики, введение в формальную семантику Хоара, теория алгоритмов и основы построения ЯП. Получаемый такой базис знаний способствует формированию математического мышления и формального подхода к процессам разработки ПО.
С точки зрения когнитивной психологии требуется не только преподавание этих дисциплин, но и применение теоретических знаний на практике.Например, проведение силами студентов разработки некоторого прототипа проекта с использованием идей объектно-ориентированного или компонентного проектирования с повторным использованием готовых объектов и компонентов согласно ЖЦ создания программного продукта. Прототип может быть собран из готовых компонентов и на нем отработаны функции, определенные в требованиях к системе. При реализации долговременного проекта, в процессе разработки могут быть определены стандарты на компоненты, модели качества, новые методы проверки надежности компонентов, а также подходы к определению уровня зрелости по модели СММ, соответствующей оценки деятельности разработчиков этого проекта. Таким образом, в процессе обучения студентами приобретаются не только теоретические знания, но и умение их использовать при выполнении различных ролей в группе разработчиков ПО, создании отдельных версий проекта, проведении их качественного анализа и оценки заданных в требованиях показателей качества.
Аспектно–ориентированное программирование
Аспектно–ориентированное программирование (АОП) [18–20] – это парадигма построения гибких к изменению ПС за счет добавление новых функций, средств безопасности и взаимодействия компонентов с другой средой, синхронизации одновременного доступа частей ПС к данным, вызова общесистемных средств и др.
Аспектом может быть некоторая функция, ПИК, элемент или часть готовой программы, отдельный компонент, концепция взаимодействия, защиты и др. Созданная средствами АОП ПС из отдельных программ семейства может включать набор ПИК, объекты, небольшие методы и аспекты, как средство дополнения ПС необходимыми концепциями взаимодействия или защиты для новой среды, которые пересекают (переплетают) компоненты и тем самым значительно усложняют процесс вычислений.
Реализация аспектов в различных частях программного кода ПС решается путем установления перекрестных ссылок и точек соединения, через которые осуществляется связь аспекта с транзакциями, защитой данных и т.п.
В основе АОП лежит метод разбиения задач ПрО на ряд функциональных компонентов с применением аспектов (синхронизации, взаимодействия, защиты и др.), которые встраиваются в отдельные компонентов в некоторые их точки для выполнения соответствующих нефункциональных требований к организации выполнения компонента с другими компонентами или средами.
Кроме того, в качестве аспекта может использоваться некоторая задача, которая интересует нескольких заинтересованных лиц проекта и представленная с помощью вариантов использования, функции для компонента или программы. Некоторые аспекты могут реализовываться на этапах ЖЦ процесса разработки, способствуя улучшению результат разработки ПС.
Создание конечного продукта ПС в АЛП выполняется по технологии, соответствующей разработке компонентных систем, с той разницей, что здесь используются аспекты, которые задают условия выполнения компонентов (безопасность, защиту, взаимодействие и др.) в среде функционирования. В процессе разработки аспекты отображают разные роли взаимодействующих лиц, что приближает аспект к роли программного агента в плане выполнения некоторых функций при определении архитектуры системы, управления проектом и повышения качества ПС.
Для использования аспекта в проектных решениях в АОП введен дополнительный механизм фильтрации входных сообщений, с помощью которых выполняется изменение параметров и имен текстов аспектов в конкретно заданном компоненте системы. Код компонента становится «нечистым» (т.е.с пересекаемыми его аспектами), для которого требуется разработка новых подходов к композиции компонентов, ориентированных на Уро и на выполнение ее функций.
Общие средства композиции объектов ООП или компонентов (вызов процедур, RPC, RMI, IDL и др.) в АОП являются недостаточными, так как аспекты требуют декларативного сцепления между частичными описаниями, а также связывания отдельных обрывков из различных объектов. Одним из механизмов композиции является фильтр композиции, суть которого состоит в обновлении заданных аспектов синхронизации или взаимодействия без изменения функциональных возможностей компонента с помощью входных и выходных параметров сообщений, которые проходят фильтрацию и изменения, связанные с переопределением имен или функций самих объектов.
Фильтры делегируют внутренним компонентам параметры, переадресовывая установленные ссылки, проверяют и размещают в буфере сообщения, локализуют ограничения на синхронизацию и готовят компонент для выполнения.
В ОО–программах могут быть мелкие методы, дополнительно выполняющие расчеты с обращением к другим методам внешнего уровня. Деметер сформулировал закон [40–43], согласно которому длинные последовательности мелких методов не должны выполняться. В результате создается код алгоритма с именами классов, не задействованных в выполнении расчетных операций, а также новый дополнительный класс, который расширяет этот код функциями изменения расчетных программ.
С точки зрения моделирования, аспекты можно рассматривать как каркасы декомпозиции системы, в которых отдельные аспекты синхронизации, взаимодействия и др. пересекают ряд многократно используемых ПИК (рис.5.4).
Рис. 5.4. Пример структуры программы из Р1, Р2 и Р3 аспектами защиты
Разным аспектам проектируемой системы могут отвечать и разные парадигмы программирования: объектно–ориентированные, структурные и др. Они по отношению к проектируемой ПрО образуют мультипарадигмную концепцию аспектов, такую как синхронизация, взаимодействие, обработка ошибок и др. и требуют значительных доработок процессов их реализации. Кроме того, можно устанавливать связи с другими предметными областями для описания аспектов приложения в терминах родственных
областей. Появились языки АОП, которые позволяют описывать пересекающиеся аспекты в разных ПрО. В процессе компиляции переплетения объединяются, оптимизируются и генерируются [20] и выполняются в динамике.
Существенной чертой любых аспектов является модель, которая пересекает структуру другой модели, для которой первая модель является аспектом. Так как аспект связан с моделью, то ее можно перестроить так, чтобы аспект стал, например, модулем и выполнял функцию посредника, беря на себя все образцы взаимодействия. Однако решение, таким образом, проблемы пересечения может привести к усложнению и понижению эффективности выполнения созданного модуля или компонента.
Переплетение аспектов с компонентами может проявиться на последующих этапах процесса разработки, поэтому требуется минимизация количества сцеплений между аспектами и компонентами путем реализации ссылок в вариантах использования или сопоставления с образцом. Аспекты реализуются блоками кода с установленными перекрестными ссылками между ними, иными словами в блоках появляются точки связей с сообщениями, обработкой ошибок и т.п.
Связь между характеристиками и аспектами ПС может быть выявлена в ходе анализа ПрО.
Тогда создается динамическое связывание или статическое или «жесткое» связывание в период компиляции.
АОП стимулирует разработку новых механизмов композиции, ориентированных на ПрО и на выполнение ее задач. Аспекты с точки зрения моделирования можно рассматривать как каркасы декомпозиции системы с многократным использованием. АОП соответствует мультипарадигмовой концепции, сущность которой состоит в том, что разным аспектам проектируемой ПС, должны отвечать разные парадигмы программирования: объектно–ориентированные или структурные. Каждая из парадигм относительно реализации разных аспектов ПС (синхронизации, внедрения, обработки ошибок и др.) требует усовершенствования и обобщения применительно к каждой новой ПрО.
В АОП используется модель модульных расширений, создаваемая в рамках метамодельного программирования. Эта модель ориентирована на оперативное использование новых механизмов композиции отдельных частей ПС или семейств с учетом предметно–ориентированных возможностей языков (например, SQL) и каркасов, которые поддерживают разного рода аспекты [20].
Технология разработки прикладной системы с использованием АОП базируется на технологии ООП и имеет вид:
1..Декомпозиция функциональных задач с предположением многоразового применения соответствующих модулей и выделение аспектов, т.е свойств их выполнения (параллельно, синхронно, безопасно и т.д.).
2. Анализ языков спецификации аспектов и определение конкретных аспектов для выполнения задач ПрО;
3. Определение в модулях точек соединения аспектов для формирования ссылок на них.
4. Разработка фильтров и описание связей аспектов с функциональными компонентами, выделенными в ПрО. Система фильтров отображается в модели EJB, работающей на стороне сервера и управляющей данными с обеспечением безопасности и защитой доступа;
5. Определение механизмов композиции (вызовов процедур, методов, сцеплений) функциональных модулей многоразового применения и аспектов в точках их соединения, как фрагментов модулей с обеспечением свойств управления выполнением этих модулей, или ссылок из этих точек на другие модули.
6. Создание объектной или компонентной модели, дополнение ее входными и выходными фильтрами сообщений, посылающих объектам с ссылками, задание на выполнение методов или аспектов управления синхронизацией, защитой и т.д.
7. Анализ библиотеки расширений для выбора некоторых функциональных модулей, необходимых для реализации задач домена.
8. Компиляция, отладка модулей и аспектов, а также композиция их в прикладную программу.
Для эффективной реализации аспектов разработаны ІР–библиотека расширений, активные библиотеки, Smalltalk и ЯП, расширенные средствами описания аспектов.
В ІР–библиотеке
размещены некоторые функции компиляторов, методов, средства оптимизации, редактирования, отображения. и др. Например, библиотека матриц, с помощью которой вычисляются выражения с массивами, обеспечивается скорость выполнения, предоставления памяти и т.п.[21]. Использование таких библиотек в расширенных средах программирования называют родовым программированием, а решение проблем экономии, перестройки компиляторов под каждое новое языковое расширение, использование шаблонов и результатов предыдущей обработкой относят к области ментального программирования [22].
Библиотека включают отдельные функции компиляторов, средств оптимизации, редактирования, отображения понятий, перестройки отдельных компонентов компиляторов под новое языковое расширения, а также средства программирования на основе шаблонов и т.п. Библиотеки с такими возможностями получили название библиотек генерирующего типа.
Иной вид библиотек АОП – активные библиотеки, которые содержат не только базовый код реализации понятий ПрО, но и целевой код обеспечения компиляции, оптимизации, адаптации, визуализацию и редактирование.
Активные библиотеки пополняются средствами и инструментами интеллектуализации агентов, с помощью которых поддерживается разработка специализированных агентов для решения конкретных задач реализуемой ПрО.
Базовые операция проекта
Базовые операция проекта – это создание нового проекта, импорт компонентов из другого проекта, создание новых компонентов с помощью “Мастера шаблонов”, компиляция, выполнение и отладка группы подключенных к проекту компонентов как единой композиции. Проект является мощным средством разработки, сохранения и корректировки шаблона для поддержки взаимодействия разных типов компонентов для решения одной задачи и для последующего повторного использования.
Для реализации ПИК типа проект JAVA предлагает ряд шаблонов для развертывания компонентов:
BlankAntProject создает проект, который не содержит в себе ни одного класса или пакета классов, разрешает подключать новые классы и пакеты в схему проекта;
SampleAntProject разрешает сконфигурировать общую схему проекта с помощью иерархии системы файлов как корневой узел схемы нового проекта. Этот шаблон создает первичный эскиз проекта. Потом предоставляется возможность добавлять компоненты к проекту, делать их пакетирование и просматривать более детально для достройки отдельных компонентов.
CastomTask. разрешает создать новый проект, начиная с формирования первоначального класса в этом проекте.
Классы – основа ЯП JAVA, порождаются с помощью ключевого слова Extends, после которого указывается тип компонента (например, JApplet). В проектах используются основной класс, с которого начинается выполнение проекта, и вторичный класс. К основному классу относится Class, Main, Empty (пустой класс) и шаблоны типа:
– exception применяется для создания класса, его исключений и соответствующих сообщений об ошибках, которые могут случиться в программе;
– persistence–Capable разрешает отобразить реляционную схему БД и использовать ее для создания БД без подключения к MySQL;
– interface – шаблон, который помогает создать новый JAVA интерфейс и в дальнейшем использовать его любым классом с помощью ключевого слово implements.
При построении классов с помощью шаблонов применяются стандартные классы–оболочки (Boolean, Character, BigInteger, BigDecimal, Class), класс работы из строчными переменными, класс–коллекция (Vector, Stack, Hashtable, Collection, List, Set, Map, Iterator) и класс–утилита (Calendar, работа с массивами, работа со случайными числами).
Динамические методы тестирования
Динамические методы используются в процессе выполнения программ. Они базируются на графе, который связывает причины ошибок с ожидаемыми реакциями на эти ошибки. В процессе тестирования накапливается информация об ошибках, которая используется при оценке надежности и качества ПС.
Динамическое тестирование ориентировано на проверку корректности ПС на множестве тестов, прогоняемых по ПС, в целях проверки и сбора данных на этапах ЖЦ и проведения измерения отдельных элементов тестирования для оценки характеристик качества, указанных в требованиях посредством выполнения системы на ЭВМ. Оно основывается на систематических, статистических, (вероятностных) и имитационных методах.
Дадим краткую характеристику этим методам.
Систематические методы тестирования делятся на методы, в которых программы рассматриваются как "черный ящик" (используется информация о решаемой задаче), и методы, в которых программа рассматривается как " белый ящик" (используется информация о структуре программы). Этот вид называют тестированием с управлением по данным или управлением по входу–выходу. Цель – выяснение обстоятельств, при которых поведение программы не соответствует ее спецификации. При этом количество обнаруженных ошибок в программе является критерием качества входного тестирования.
Целью динамического тестирования программ по принципу «черного ящика» является выявление одним тестом максимального числа ошибок с использованием небольшого подмножества возможных входных данных.
Методы «черного ящика» обеспечивают:
– эквивалентное разбиение;
– анализ граничных значений;
– применение функциональных диаграмм, которые в объединении с реверсивным анализом дают достаточно полную информацию о функционировании тестируемой программы.
Эквивалентное разбиение состоит в разбиении входной области данных программы на конечное число классов эквивалентности так, чтобы каждый тест, являющийся представителем некоторого класса, был эквивалентен любому другому тесту этого класса.
Классы эквивалентности выделяются путем перебора входных условий и разбиения их на две или более групп. При этом различают два типа классов эквивалентности: правильные, задающие входные данные для программы, и неправильные, основанные на задании ошибочных входных значений.
Разработка тестов методом эквивалентного разбиения осуществляется в два этапа: выделение классов эквивалентности и построение тестов. При построении тестов, основанных на выборе входных данных, проводится символическое выполнение программы.
Итак, методы тестирования по принципу «черного ящика» используются для тестирования функций, реализованных в программе, путем проверки несоответствия между реальным поведением функций и ожидаемым поведением с учетом спецификаций требований. Во время подготовки к этому тестированию строятся: таблицы условий, причинно–следственные графы и области разбивки. Кроме того, подготавливаются тестовые наборы, учитывающие параметры и условия среды, которые влияют на поведение функций. Для каждого условия определяется множество значений и ограничений предикатов, которые тестируются.
Метод «белого ящика» позволяет исследовать внутреннюю структуру программы, причем обнаружение всех ошибок в программе является критерием исчерпывающего тестирования маршрутов ее потоков (графа) передач управления, среди которых рассматриваются:
(а) критерий покрытия операторов – набор тестов в совокупности должен обеспечить прохождение каждого оператора не менее одного раза;
(б) критерий тестирования ветвей (известный как покрытие решений или покрытие переходов) – набор тестов в совокупности должен обеспечить прохождение каждой ветви (каждого выхода оператора) по крайней мере один раз.
Критерий (б) соответствует простому структурному тесту и наиболее распространен на практике. Для удовлетворения этого критерия необходимо построить систему путей, содержащую все ветви программы. Нахождение такого оптимального покрытия в некоторых случаях осуществляется просто, а в других является более сложной задачей.
Тестирование по принципу « белого ящика» ориентировано на проверку прохождения всех путей программ посредством применения путевого и имитационного тестирования
.
Путевое тестирование применяется на уровне модулей и графовой модели программы путем выбора тестовых ситуаций, подготовки данных и включает тестирование:
– операторов, которые должны быть выполнены хотя бы один раз, без учета ошибок, которые могут остаться в программе из–за большого количества логических путей и необходимости прохождения подмножеств этих путей;
– путей по заданному графу потоков управления для выявления разных маршрутов передачи управления с помощью путевых предикатов, для вычисления которого создается набор тестовых данных, гарантирующих прохождение всех путей. Однако, все пути выполнить невозможно, поэтому остаются и невыявленные ошибки, которые могут проявиться в процессе эксплуатации;
– блоков, разделяющих программы на отдельные части–блоки, которые выполняются один раз или многократно при нахождении путей в программе, включающих совокупность блоков реализации одной функции либо нахождения входного множества данных, которое будет использоваться для выполнения указанного пути.
«Белый ящик» базируется на структуре программы, а «черный ящик», когда о структуре ничего неизвестно. Для выполнения тестирования с помощью этих «ящиков» известными считаются выполняемые функции, входы (входные данные) и выходы (выходные данные), а также логика обработки, представленные в документации.
Формальное описание данных в ЯП и их преобразование
Основными ЯП, используемыми для описания компонентов для распределенной сети, являются С++, Паскаль, JAVA и др.
При обращении разноязыковых компонентов устанавливается взаимно однозначное соответствие между фактическими параметрами V= { v1,v2
,...vк} вызывающего компонента и формальными параметрами F = { f1, f2 , ..., fк1} вызываемого компонента, а также строится отображение (mapping) типов данных одного ЯП в соответствующие типы другого ЯП.
В общем случае задача отображения А: Пà Ф для множеств параметров V и F состоит в построении:
П = { V1, V2 ,..., Vm } , Ф = { F1, F2 ,..., Fm }
m
È V t = V , Vt Ç Vt¢ = Æ при t £ t¢
t=1
m
È F t = F , Ft Ç Ft¢ = Æ при t = t¢
t=1
Построение отображения выполняется за два этапа.
1) Построение операций преобразования типов данных T a = {Tat} для множества языков L = {la }a=1, n
.
2) Построение отображения типов данных для каждой пары взаимодействующих компонентов в ЯП la1 и la2 с применением операций селектора S и конструктора С.
Для проведения формализованного преобразования типов данных используется алгебраический подход, при котором каждому типу данных Tat ставиться в соответствие алгебраическая система
Gat = <Xat
, Wat
>,
где t – тип данных, Xat – множество значений, которые могут принимать переменные этого типа данных, Wat – множество операций над этими типами данных.
Для простых типов данных ЯП t = b (bool), c (char), i (int), r (real)
и сложных типов данных t = a (array), z (record), u (union), e (enum), как комбинация простых типов данных, построены две алгебраические системы:
S1 = { G ab , Gac , Gai , Gar }
S2 = { Gaa , Gaz G au , Gae ...} (1)
Каждая из систем определяется на множестве значений типов данных и операций над ними:
Gat = <Xat , Wat >, где t = b, c, i, r, a, z, u, e.
Операциям преобразования каждого t типа данных соответствует изоморфное отображение двух алгебраических систем, построенных для совместимых типов данных двух ЯП.
В классе систем (1) преобразование типов данных t® q для пары языков la и lb обладает такими свойствами отображений:
1) Системы Gat и Gbq
являются изоморфными (типы q, t определены на том же множестве).
2) Между значениями Xat и Xbq существует изоморфизм, если множества операций Wat и Wbq различны. Если множество операций W = Wat Ç Wbq не пусто, то имеем изоморфизм двух систем G at¢ = < Xat , W > и Gbq¢ = < Xbq , W > . Если тип t – строка, а тип q – вещественный, то между множествами Xat и Xbq не существует изоморфного соответствия.
3) Мощности алгебраических систем должны быть равны çGat ç = ç Gbq ç.
Алгебраические системы линейно упорядочены и поэтому любое отображение 1), 2) сохраняет линейный порядок.
Формальные методы
Понятие формальные методы более всего связано с математическими техниками спецификаций, верификации та доказательства правильности создаваемых программ. Эти методы содержат математическую символику, формальную нотацию, аппарат вывода и потому они трудно используются рядовыми программистами. Кроме того, постоянно развиваемые эти средства не вкладываются в стандартизованные процессы ЖЦ, в котором регламентированы все основные и дополнительные процессы (управление качеством, проектом, ресурсами и др.).
За многие годы своего существования (более 20–лет) такие известные формальные методы, как VDM, Z, RAISE [43–46] используются редко, эпизодически в реальных проектах, более всего в университетских и академических организациях и до промышленного производства фактически не дошли.
Это связано с тем, что формальные техники трудно использовать практически особенно в системах реального времени, где особенно важно применение формальных методов для создания более надежных программ, стоимость разработки которых возрастает, так как тратиться много времени на спецификацию и верификацию.
Наука формального проектирования ПС получила значительный прогресс при создании обобщенного UML, который доведен до стандарта, отодвинув на второй план такие средства спецификации, как RAISE, VDM и др.
Далее рассматриваются некоторые техники спецификации моделей программ и методы формального доказательства.
Графова модель VDM создается с помощью композиционной теоремы [5], которая определяется в виде ациклического графа, узлы которого – модули, а дуги – интерфейс между модулями.
Каждому модулю модели соответствует сервис как provider, так и потребителя (consumer) услуг. Дуга графу от модуля M к N определяет интерфейс, который может предоставлять модуль N для модуля M.
Базисом формального метода представления модели есть спецификация интерфейсов модулей для двух выше указанных пользователей сервисов.
Интерфейс удовлетворяет следующим свойствам:
– разделенность (separable) модулей с точки зрения проектирования и спецификации, интерфейс которых не требует описания среды модуля;
– композиционность (сомроsіtіоn), когда модули соединяются через композиционную теорию в систему с гарантированными связями между ними.
Данная теория базируется на модели интерфейса для взаимодействия модулей системы между собою через сетевые протоколы (TCP, UDP и др.). Каждый протокол передает разным модулям этой модели параметры для нахождения нужного сервиса.
Модель интерфейса задает связь модуля со средой в виде дискретного события (event), которое возникает только тогда, когда модуль и среда действуют вместе, и создают событие, рассматриваемое со стороны интерфейса. Иными словами, интерфейс специфицируется в виде множества последовательностей событий для наблюдения за поведением модулей модели.
Предположим, что S определяет спецификацию модуля M, которая включает в себя все возможные случаи его поведения и задает разные ситуации, которыми могут быть:
– событие интерфейса или состояние наблюдателя системы;
– анализ является конечным или представлен неопределенной последовательностью;
– формализм определения этой последовательности;
– условия выполнения события.
Эти предположения разрешают обеспечить разноуровневую систему взаимодействия модулей модели через механизм протоколов и систему наблюдения за событиями.
Формальный метод и спецификация RAISE. RAISE– метод и RSL–спецификация (RAISE Spesification Language) [45, 46] были разработаны в 1985–1998гг. как результат предварительного исследования формальных методов. Метод содержит нотации, техники и инструменты для использования формальных методов при конструировании ПС и доказательстве их правильности. Метод имеет программную поддержку в виде набора инструментов и методик, которые постоянно развиваются и используются для конструирования и доказательства правильности программ.
описанных в RSL и ЯП (С++ и Паскаль).
Язык RSL содержит абстрактные параметрические типы данных (алгебраические спецификации) и конкретные типы данных (модельно–ориентированные), подтипы, операции для задания последовательных и параллельных программ, предоставляет аппликативный и императивный стиль спецификации абстрактных программ, а также формальное конструирование программ в других ЯП и доказательства их правильности. Синтаксис этого языка близок к синтаксису языков С++ и Паскаль.
В RSL–языке имеются предопределенные абстрактные типы данных и конструкторы сложных типов данных, такие как произведение (product), множества (sets), списки (list), отображения (map), записи (record) и т.п. Далее рассмотрим, для примера, некоторые конструкторы сложных типов данных.
1. Произведение типов – это упорядоченная конечная последовательность типов Т1, Т2 , …, Тn произведения (product) Т1 ´ Т2 ´, …, ´ Тn . Представитель типа имеет вид (v1, v2 , …, vn ), где каждое vi есть значением типа Тi. Компонент произведения можно получить get и переслать set, т.е.
get component (i, d) = getvalue (i, d),
set component (d, i, val) = d ÞÑ (I ® val).
Количество компонентов произведения d находится таким образом:
size (d) = id Ñ (null (couter inc(counter))).
Конструктор произведения d1 и d2 строит произведение d1 ´ d2 вида
product (d1 , d2 ) = id Ñ (size (d1) Þ couter 1) Ñ (null (couter 2) inc couter 2))).
Для каждого конкретного типа product (Т1 ´Т2
´, …, ´ Тn) можно построить конструктор значения этого типа из отдельных компонентов произведения таким образом:
make product (value 1, …, value n) = (value i Þ 1) Ñ… Ñ (value n Þ n),
где каждое значение value i имеет тип Тi , а результирующее значение – тип произведения Т1 ´Т2 ´, …, ´ Тn .
2. Списки типов – это последовательность значений одного типа списка list Т, могут быть конечным списком типов Тk и неконечными списком типов T n . в качестве структур данных типа списку может быть бинарное дерево, в котором есть голова (head) и сын ( tail), следует за ним в списке и хвост. Операциями для списка является операция hd взятия первого элемента списка, т.е. головы и операция tl – хвоста остальные элементы.
Функция Caddr (I) = L Þ tail Þtail Þ Head выбирает из списка I –элемент. Индекс элемента помогает выбрать нужный элемент списка Index(I, idx) = L (idx) =
while (Ø is null(idx))do((L Þ tail ÞL) Ñdec(idx)) L Þ Head. Для определения количества элементов в списке выполняется функция
len (L) = (ld Ñ null (result))
while (L Þ) do (( L Þ tail Þ tail ÞL) Ñ inc (result))
result Þ
Элемент списка находится так:
elem (L) = (ld Ñ empty (result))
while (L Þ) do (( L Þ tail ÞL) Ñ
( result ( LÞ head Þ) Þ elem ) Þ result)
result Þ.
Аналогично можно представить функции конкатенации, преобразование типов данных, добавления элемента в голову и хвост списка и др.
3. Отображение – это структура (map), которая ставит в соответствие значениям одного типа значение другого типа. С другой стороны, отображение является бинарным отношением декартового произведения двух множеств, как совокупности двухкомпонентных пар, в которой первый компонент arg содержит элементы аргументов отображения, а другой компонент res соответствующие элементы значений этого отображения.
В языке представлены разные допустимые операции над отображениями: наложение, объединение, композиция, срез и др. Среди этих видов отношений рассмотрим только композицию отображений.(m1, m2).
(ld Ñ (compose (m1, m2) Þ m)) apply (m, elem)
apply to composition (m1, m2, elem) =
(ld Ñ (image (elem, m1) Þ s) restrict (m2, s) Þ map
(ld Ñ (map getname elem Þ name)) getvalue (name, map).
При этом используются функции:
Apply (m, elem) = image (elem, m) elem Þ,
Apply (m, elem) = getvalue (elem, m) elem Þ.
4. Запись – это совокупность именованных полей. Этот тип соответствует типу record в языке Паскаль и struct в языке С++. В языке RAISE определено два конструктора типа, record, shurt record, которые описываются в виде – type record id =
type mk_id (short _record id ) ::=
destr_id1 : type_expr1 « recon_id
. . .
destr_idn : type_exprn « recon_id.
Идентификатор mk_id является конструктором типа record, для которого даны деструкторы destr_idn , как функции получения значения компонентов записи.
5. Объединение – это конструктор Union, обеспечивающий объединение типов
type id = id1 , id2 ,…, idn
при котором тип id получает одно из значений в списке элементов.
Конструктор этого типа имеет вид:
type id = id_from_ id1 (id_to_ id1: id1) ½… ½ id_from_ idn (id_to_ idn: idn)/
Операции над самим типом не определены в языке RAISE.
Рассмотренные формальные структуры данных языка RAISE позволяет математически описывать и конструировать новые структуры данных в проектируемых программах. Их проще проверять на правильность методами верификации.
Формирование требований к автоматизированной системе
Данный стандарт определяет стадии и этапы разработки автоматизированных систем (АС). В зависимости от конкретных условиях стадии и этапы могут объединяться друг с другом. В стандарте определено восемь этапов разработки АС, на каждом из которых формируются документы, описываемые ниже.
1 этап. Формирование требований к автоматизированной системе (АС). Проводится обследование объекта и обоснование необходимости создания АС. Формулируются требования пользователя к АС, оформляются отчет о выполненной работе. Выясняется документооборот, формы начальных и исходящих документов, методики расчета отдельных показателей. Отчет об обследовании создается в произвольной форме, является основой разработки технического проекта АС, в приложениях к отчету приводятся формы документов и методики расчета экономических показателей АС.
Сформулированные требования к системе – заявка на разработку технического задания.
2 этап. Разработка концепции АС. Определяются путей и оценки возможностей реализации требований пользователя, а также методы, которые будут положены в основу расчетов и подходы к решению конкретных задач системы. Заканчивается этап созданием и утверждением отчета о научно–исследовательской работе, в котором дается оценка необходимых для реализации ресурсов, вариантов разработки и оценки качества АС.
3 этап. Разработка технического задания (ТЗ). ТЗ – это основной документ, который определяет требования и порядок создания (развития или модернизации) АС. На основании ТЗ ведется разработка АС, ее прием во время ввода в действие. Дополнительно могут быть разработаны ТЗ на отдельные части АС.
4 этап. Разработка эскизного проекта. На основе проектных решений ко всей системе или ее частям определяется перечень задач, которые будут выполняться в системе, концепция информационной базы, функции и параметры основных программных средств. Для каждой задачи приводятся согласованные с заказчиком формы первичных и исходящих документов, структура информационных массивов или их перечень, основные алгоритмы обработки информации.
5 этап. Разработка технического проекта (ТП). В ТП дается описание разработанных проектных решений для системы и ее частей, документации на АС и комплектации АС или технических требований на нее, задач проектирования смежных частей проекта для проектные решения определяют организационную структуру, функции персонала в АС, структуру технических средств, языки программирования, СУБД, общие характеристики ПО, система классификации и кодирование, а также варианты информационной базы.
6 этап. Разработка рабочей документации. На этом этапе создаются проектные документы, которые определяются государственными стандартами и включают: постановки задач, алгоритмы их решения, организация информационного, технического и программного обеспечения. Эти проектные документы могут оформляться как отдельные документы, а могут входить в технический проект как отдельные разделы. К документам рабочего проекта относятся общее описание системы, описание технологического процесса обработки информации, инструкции по выполнению отдельных операций технологического процесса, руководство пользователя, описание программ и т.п.
7 этап. Введение АС в эксплуатацию. При создании рабочего проекта проводится разработка и отладка программ или адаптация, готовых программ, которые разрабатывалось для других объектов, их описание или паспорт. На этапе ввода в эксплуатацию выполняется: подготовка объекта к вводу в эксплуатацию, комплектация АС, установка технических и программных средств, выполнение монтажных работ и проведения приемочных испытаний. Готовится приказ об изменениях в структуре объекта, документообороте, а также о распределении обязанностей персонала при переходе на новую технологию обработки информации. Параллельно с подготовкой персонала ведутся работы по установке технических и программных средств, а также разрабатываются средства охраны и защиты АС.
Предварительные испытания системы выполняет разработчик на основе контрольного примера или реальных данных.
По результатам опытной эксплуатации программного обеспечения могут вноситься изменения, которые могут повлечь за собой доработку технического проекта системы.
После завершения опытной эксплуатации проводятся приемочные испытания соответственно ТЗ специально созданной комиссией. В результате создается акт введения системы в эксплуатацию.
8 этап. Сопровождение АС. Во время сопровождения устраняться недостатки, которые обнаружены во время эксплуатации и создается акт о выполненных работах. По мере внесения изменений в рабочую документацию могут вноситься изменения и в технический проект и, как правило, самими разработчиками.
АС может создаваться на основе готовых типовых программных средств, которые ориентированы на предметную область этой АС. Программные средства могут продаваться разработчиком или его представителем. В этом случае работы для заказчика выполняются в одну стадию — введение в эксплуатацию АС. Проводится экспертиза, принимается решение о закупке необходимых программных средств. Кроме того, готовится приказ об изменении технологии работы на отдельных участках проекта АС и определяются ответственные за внедрение новой технологии. Разработчик передает заказчику системы рабочую документацию на АС или на ее отдельные части. Все перечисленные работы создаются по договору между заказчиком и разработчиком.
Формы
Формы. Интерфейсы компонентов содержат методы работы с графическими объектами и классы, реализующие эти методы, подключаются к AWT библиотеке классов, каждый из которых описывает отдельный графический компонент, применяемый независимо от других элементов. В AWT существует класс Component, а графический компонент является экземпляром этого класса. При выводе графического элемента на экран он размещается в окне дисплея, как потомок класса Container.
Библиотека AWT содержит формы, каждая из форм представляет собою контейнер для размещения графических элементов интерфейса пользователя, а также систему классов Abstract Window Toolkit для построения абстрактного окна.
Различаются AWT формы и Swing формы. AWT формы построены на базе“тяжелых” интерфейсов (peer–интерфейс), а Swing формы – на базе “легких” интерфейсов. В разных средах AWT компоненты имеют вид, специфический для данной среды, а Swing компоненты выглядят одинаково в разных средах и сохраняют этот вид (“plaf” – Pluggable Look and Feel) за счет того, что они разработаны средствами ЯП JAVA независимо от платформы. Swimg и AWT библиотеки используются самостоятельно.
Все упомянутые окна применяются как контейнеры, к которым можно добавлять более простые графические элементы интерфейса с пользователем (кнопок, полос прокрутки, разных типов меню и т.п.). Интеграция простых компонентов в программный код происходит с помощью панели с изображением всех графических компонентов, изменение которого выполняются автоматически. Необходимые методы обработки форм подключаются к коду с помощью окна Inspector Components.
Аплет представляет собою небольшую программу, доступную на Internet сервере, автоматически устанавливается и выполняется WEB браузером или программой просмотра аплета appletviewer пакета JDK (Java developer Kit). Аплети не выполняются JAVA интерпретатором, а работают в консольном режиме. После компиляции аплет подключается к HTML файлу, использующий тег <applet>. Компонент JAVA Applet обеспечивается набором стандартных методов инициализации, запуска, подключения аплета в требуемый WEB контекст для работы с аудиоклипами, с URL адресами, с объектами типа Image и др.
Диалоговая форма создается в виде окна для поддержки диалога с пользователем, имеет механизм открытия и закрытия в зависимости от интерфейса с пользователем, может существовать при условии, если оно принадлежит определенному окну–фрейма. Каждое такое окно может быть модальным (из него невозможно выйти, пока пользователь не выполнит все приписанные ему действия) и немодальное, из которого можно выйти в любой момент времени.
Фрейм представляет собою окно со строкой заголовка, которое может быть встроено в апелет или существовать само по себе в программе. Чаще всего фрейм используют для того, чтобы сделаться собственником других окон, которые имеют свой порядок открытия и закрытия, но могут существовать только как подокна Frame.
Панель – это область окна (фрейм или диалоговое окно), в которой могут быть собраны разные элементы, открываемые и закрываемые вместе с панелью. Swing формы представляют набор компонентов интерфейса пользователя, подобных функциональности AWT формам, но реализованных на языке JAVA, что дает Swing компонентам быть независимым от платформы компонентов.
Для создания наиболее употребляемых форм в языке JAVA используются шаблоны:
– Application, который создает фрейм, в состав которого входит трехуровневое меню;
– MDI Application служит для создания фрейма, в состав которого входит меню и панель с заведомо определенными в ней элементами;
– OkCancelDialog создает диалоговое окно, которое имеет обязательно две кнопки – Ok и Cancel.
Функциональное тестирование
Целью функционального тестирования является обнаружение несоответствий между реальным поведением реализованных функций и ожидаемым поведением в соответствии со спецификацией и исходными требованиями. Функциональные тесты должны охватывать все реализованные функции с учетом наиболее вероятных типов ошибок. Тестовые сценарии, объединяющие отдельные тесты, ориентированы на проверку качества решения функциональных задач.
Функциональные тесты создаются по внешним спецификациям функций, проектной информации и по тексту на ЯП, относятся к функциональным его характеристикам и применяются на этапе комплексного тестирования и испытаний для определения полноты реализации функциональных задач и их соответствия исходным требованиям.
В задачи функционального тестирования входят:
– идентификация множества функциональных требований;
– идентификация внешних функций и построение последовательностей функций в соответствии с их использованием в ПС;
– идентификация множества входных данных каждой функции и определение областей их изменения;
– построение тестовых наборов и сценариев тестирования функций;
– выявление и представление всех функциональных требований с помощью тестовых наборов и проведение тестирования ошибок в программе и при взаимодействии со средой.
Тесты, создаваемые по проектной информации, связаны со структурами данных, алгоритмами, интерфейсами между отдельными компонентами и применяются для тестирования отдельных компонентов и интерфейсов между ними. Основная цель – обеспечение полноты и согласованности реализованных х функций и интерфейсов между ними.
Комбинированный метод "черного ящика" и "прозрачного ящика" основан на разбиении входной области функции на подобласти обнаружения ошибок. Подобласть содержит однородные элементы, которые все обрабатываются корректно либо некорректно. Для тестирования подобласти производится выполнение программы на одном из элементов этой области.
Предпосылками функционального тестирования являются:
– корректное формирование требований и ограничений к качеству ПО;
– корректное описание модели функционирования ПО в среде его эксплуатации заказчиком;
– адекватность модели ПО заданному классу.
Генерирующее (порождающее) программирование
Порождающее программирование (generatе programming) основана на генерации и моделировании групп или отдельных элементов ПС из разных продуктов программирования: объектов, компонентов, аспектов, сервисов, ПИК, систем, характеристик, каркасов и т.п. Базисом этого программирования является ООП, дополненное механизмами применения ПИК, а также свойствами изменчивости, взаимодействия, синхронизации и др. [22].
В нем используются другие методы программирования, например, для поддержки инженерии ПрО как дисциплины проектирования семейств ПС из разных ранее указанных продуктов программирования.
В рамках данного программирования построена объединенная технология генерации как отдельных ПС, так и их семейств. В результате в нем сформирован базис будущего программирования, включающий современные методы программирования, новые формализмы и объединяющие модели, посредством которых можно будет создавать более долговременные качественные программные изделия семейств ПС по принципу конвейера.
Главным элементом проектирования ПС является не уникальный программный продукт, созданный из ПИК для конкретных применений, а семейство ПС или конкретные его экземпляры. Элементы семейства не создаются с нуля, а генерируются на основе общей генерирующей модели домена (generative domain model), т.е. модели семейства, включающей средства определения членов семейства, компоненты реализации и ПИК для сборки любого члена семейства и базы конфигурации, специфицирующей членов семейства.
Каждый член семейства отражает максимум знаний о его производстве, а именно, конфигурации, инструментарии измерения и оценки, методах тестирования и планирования, отладки, визуального представления, а также о многократно используемых ПИК из активной библиотеки [21, 22].
Базовый код элементов активной библиотеки содержит целевой код по обеспечению процедур компиляции, отладки, визуализации и др. Фактически компоненты активных библиотек выполняют роль интеллектуальных агентов, в процессе взаимодействия которых создаются новые агенты, ориентированные на предоставление пользователю возможности решать конкретные задачи ПрО. Для выполнения агентами задач генерации, преобразования и взаимодействия должна создаваться инфраструктура, а именно, расширяемая среда программирования.
Эта среда предназначена для конструирования ПС из компонентов библиотек, а также специальных метапрограмм среды, которые осуществляют редактирование, отладку и взаимодействие компонентов непосредственно в расширяемой среде. С другой стороны, имеется возможность пополнять эту среду новыми сгенерированными компонентами в рамках отдельных ПС семейства, которые относятся к числу компонентов многоразового применения.
Целью порождающего программирования является разработка правильных компонентов для целого семейства и автоматическое их предоставление другим членам семейства. Реализации этой цели соответствует два сформировавшихся направления использования ПИК[13–15]:
1) прикладная инженерия – процесс производства конкретных ПС из ПИК, созданных ранее в среде самостоятельных ПС, или как отдельных элементов процесса инженерии некоторой ПрО.
2) инженерия ПрО – построение семейства ПС путем сбора, классификации и фиксации ПИК, опыта конструирования систем или готовых частей систем конкретной ПрО. При этом создаются системные инструментальные системы поддержки поиска, адаптации ПИК и внедрения их в новый элемент семейства ПС или самого ПС.
Инженерия ПрО включает в себя инженерию приложений как способ создания отдельных одиночных членов семейства, а также метод конструирования семейств приложений и компонентных систем через механизмы разделения задач ПрО на отдельные члены и многократно используемые решения для сборки отдельных подсистем и членов семейства в общую систему для ПрО.
Основными этапами инженерии ПрО являются:
– анализ ПрО и выявление объектов и отношений между ними;
– определение области действий объектов ПрО;
– определение общих функциональных и изменяемых характеристик, построение модели характеристик, устанавливающей зависимость между различными членами семейства, а также в пределах членов семейства системы;
– создание базиса для производства конкретных программных членов семейства с механизмами изменчивости независимо от средств их реализации;
– подбор и подготовка компонентов многократного применения, описание аспектов выполнения задач ПрО;
– генерация отдельного домена, члена семейства и ПС в целом.
Генерация доменной модели для семейства ПС основывается на модели характеристик, наборе компонентов реализации задач ПрО, конфигурации и спецификации компонентов. Эти элементы генерируются готовую систему или отдельных членов семейства.
Для реализации инженерии ПрО используются следующие вспомогательные процессы:
– корректировка процессов для разработки решений на основе ПИК;
– моделирование изменчивости и зависимостей, которое начинается с разработки словаря описания различных понятий, фиксации их в модели характеристик и в справочной информации сведений об изменчивости моделей (объектных, Use Case, взаимодействия и др.). Фиксация зависимостей между характеристиками модели избавляет пользователей от некоторых конфигурационных манипуляций, которые выполняются, как правило, вручную;
– разработка инфраструктуры ПИК –
описание, хранение, поиск, оценивание и объединение готовых ПИК.
При определении членов семейства ПрО используются пространство проблемы и пространство решений.
Пространство проблемы (speace problem) состоит из компонентов семейства системы, в которых используется ПИК, объекты, аспекты и др. Процесс разработки этих членов семейства с ПИК включает в себя и инструменты, созданные в ходе разработки ПрО. В рамках инженерии ПрО разрабатывается модель характеристик, которая объединяет функциональные характеристики системы, характеристики определения свойств выполнения компонентов и изменяемые параметры разных частей семейства, а также решения, связанные с особенностями выполнения групп ПС.
Инженерия ПрО включает разработку моделей групп систем, моделирование понятий ПрО, разработку их моделей характеристик и групп систем для последующего повторного использования. В рамках инженерии ПрО используются горизонтальные и вертикальные типы компонентов, предложенные OMG–комитетом в системе объектного проектирования Corba [23, 24].
К горизонтальным типам компонентов отнесены общие системные средства, а именно, графические пользовательские интерфейсы, СУБД, системные программы, библиотеки расчета матриц, контейнеры, каркасы и т.п. К вертикальным типам компонентов
относятся прикладные системы (медицинские, биологические, научные и т.д.), методы инженерии ПрО, а также компоненты из горизонтального типа по обслуживанию архитектуры многократного применения, интерфейсов и др.
Пространство решений (speace solution) состоит из компонентов, каркасов, образцов проектирования, а также средств их соединения и оценки избыточности. Эти элементы обеспечивают решение задач ПрО. Так, каркас
оснащен аппаратом обеспечения изменения параметров модели, требующих лишнюю фрагментацию из «множества мелких методов и классов». Образцы
проектирования обеспечивают создание многократно используемых решений в различных типах ПС. Для задания и реализации таких аспектов, как синхронизация, удаленное взаимодействие, защита данных и т.д. применяются технологии ActiveX и JavaBeans, а также новые механизмы композиции, метапрограммирования и др.
Примером систем поддержки инженерии ПрО и реализации горизонтальных методов является система DEMRAL [22, 16], предназначенная для разработки библиотек: численного анализа, контейнеров, распознавания речи, графовых вычислений и т.д. Основными видами абстракций этих библиотек ПрО являются абстрактные типы данных (abstract data types– ADT) и алгоритмы. DEMRAL позволяет моделировать характеристики ПрО в виде высокоуровневой характеристической модели и предметно–ориентированных языков конфигурирования.
Система конструирования RSEB [22] базируется на вертикальных методах, ПИК и ориентирована на использование Use Case элементов при проектировании крупных ПС. Эффект достигается, когда вертикальные методы инженерии ПрО «вызывают» различные горизонтальные методы, относящиеся к разным прикладным подсистемам. При работе над отдельной частью семейства системы могут быть задействованы такие основные аспекты — взаимодействие, структуры, потоки данных и др.Главную роль, как правило, выполняет один из методов, например, графический пользовательский интерфейс в бизнес–приложениях и метод взаимодействия компонентов в распределенной, открытой среде (например, в CORBA).
Характеристика модели процессов в ядре SWEBOK
В ядре знаний SWEBOK определено 10 областей знаний, пять из них по своим задачам и выполняемым действиям соответствуют основным процессам ЖЦ стандарта. Остальные пять областей ядра можно отнести к числу процессов обеспечения и управления разработкой программного продукта, в части верификации, сбора данных для оценки качества и др., начиная от разработки требований и кончая сопровождением программного продукта. И хотя ядро знаний явно не содержит названий процессов, функционально они соответствуют общепринятым процессам разработки и стандарту, а именно отдельным основным, вспомогательным и организационным процессам.
Первые пять областей ядра знаний SWEBOK по своему содержанию соответствуют следующим процессам:
– разработка требований;
– проектирование;
– конструирование;
– тестирования;
– сопровождение.
Эти процессы задают последовательность задач и действий при разработке разных типов ПС с применением современных методов и средств, которые представлены в ядре знаний.
В табл.2 приведен сопоставительный перечень основных процессов, их задач, приведенных в SWEBOK и ЖЦ стандарте. При этом процессы приобретения и поставки из состава основных процессов исключаются, поскольку они не относятся к процессам разработки программных систем.
Остальные пять областей, которые определены в ядре знаний SWEBOK, по своим функциям соответствуют отдельным вспомогательным и организационным процессам ЖЦ стандарта:
– управление конфигурацией;
– управление инженерией;
– управление качеством
– процесс инженерии;
– методы и средства инженерии ПО;
– управление качеством.
Данные процессы предназначены для управления программным проектом, конфигурацией и методами и средствами обеспечения инженерии программирования, а именно оценки качества процессов, промежуточных результатов, полученных на процессах, и конечного продукта.
Таблица 2
Задачи основных процессов в SWEBOK и ЖЦ
Области–процессы |
Задачи областей SWEBOK |
Задачи процессов ЖЦ в стандарте |
Разработка Требований |
Инженерия требований. Выявления требований. Анализ требований. Спецификация требований. Проверка требований. Управления требованиями. |
Подготовка заказа Выявление требований Анализ требований к системе Анализ требований к ПО Описание документа . |
Проектирование ПО |
Разработка архитектура ПО Структура ПО. Нотация. Анализ качества проектирования. Стратегия и методы проектирования. |
Проектирование архитектуры системы Проектирование архитектуры ПО Детальное проектирование ПО. Кодирование и тестирование ПО. |
Конструирование ПО |
Снижение сложности. Предупреждение отклонений от стиля. Структуризация системы для проверок. Использование внешних стандартов. |
Конструирование структуры системы Кодирование элементов структуры и ПО Интеграция элементов. Применение стандартов программной инженерии. |
Тестирование ПО |
Уровни тестирования. Техники тестирования. Метрики тестирования. Управления тестированием. |
Тестирование ПО. Интеграционное тестирование. Квалификационное тестирование. Интеграция системы. Системное тестирование. Установка ПО. Обеспечение приемки ПО. |
Сопровождение ПО |
Процесс сопровождения. Ключевые вопросы сопровождения. Техники сопровождения. |
Инсталляция ПО Внедрение процесса. Анализ проблем и модификаций. Реализация модификаций. Анализ сопровождения. Миграция (перемещение) ПО. Удаление ПО. |
Эксплуатация системы |
Методы обеспечения эксплуатации системы |
Внедрение процесса. Функциональное тестирование. Эксплуатация системы. Поддержка пользователя. |
Таблица 3
Задачи организационных и дополнительных процессов в SWEBOK и ЖЦ