Методы и средства инженерии программного обеспечения
         

Агентное программирование


Понятие интеллектуального и программного  агента появилось более 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).
                                   Р1                                                                            Р2                                         Р3

                 



                            

 

            Рис. 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,  их задач и  соответствующих  задач организационных процессов ЖЦ стандарта. 

                                                                                                                                 Таблица 3

Задачи организационных  и дополнительных процессов  в SWEBOK и ЖЦ

Области –

процессы

Характеристика процессов стандарта


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

 

К основным процессам  стандарта относятся:

– приобретения (acquisition),

– поставки (supply),

– разработки (development),                                                                     

– эксплуатации (operation),

– сопровождения (maintenance).

Процесс приобретения инициирует ЖЦ ПО и определяет действия организации-покупателя (или заказчика), которая приобретает автоматизированную систему, программный продукт или сервис.

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

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

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

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

К вспомогательным процессам стандарта относятся стандарты:

–  документирования (documentation),

–  управления конфигурацией (configuration management),

–  обеспечения качества (quality assurance),

–  верификации (verification),

–  валидации (validation),

–  совместного анализа (оценки) (joint review),

–  аудита (audit),процесс решения проблем (problem resolution).

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

К организационным  процессам стандарта относятся процессы:

– управления (management),

– создания инфраструктуры (infrastructure),


– усовершенствования (improvement),

– обучения (training).

За каждый процесс стандарта отвечает определенный участник разработки или руководитель. Для каждого из процессов стандарта определены  виды деятельности (действия - activity) и задачи, которые в него входят, определена совокупность результатов  видов деятельности и задач, а также некоторые специфические требования. В табл.1 приведено общее количество определенных в стандарте процессов (17), действий (74) и задач (232).

                                                                                                                                Таблица 1

                     Общий перечень процессов ЖЦ стандарта 12207

Класс

 Процесс

 Действие

 Задача
Основные процессы

 5

 35

 135
Вспомогательные процессы

 8

 25

 70
Организационные процессы

 4

 14

 27
Итого

 17

 74

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


Информационная модель


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

– реальные предметы мира, имеющие физическое воплощение;

– абстракции физических предметов этого  мира;

– абстракции или цели использования этих предметов определяются абстрактными действиями,  изменяющими их состояния;

– взаимодействия - это отношение между объектами;

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

Для классов  объектов   выбираются уникальные имена, устанавливаются атрибуты и  устанавливаются связи между объектами.

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

Для каждого из выбранных атрибутов определяются  возможные значения (типы значений) одним из следующих способов:

– задание числового диапазона;

– перечисление возможных значений;

– ссылка  на документ,  в котором определены возможные значения;

– правила генерации значений.

 

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


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

– каждый экземпляр объекта обязательно имеет одно значение (значение не может быть неопределенным  или отсутствующим);

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

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

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

1) проект  имеет  исполнителей, которые   заняты в проекте;

2) руководитель управляет  исполнителями, т.е. исполнитель подчинен руководителю;

3) исполнитель занимает комнату, т.е. комната занята  исполнителем.

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

В методе различаются три фундаментальных вида связи между объектами:

–        один к одному (1:1),  в связи принимают участие по одному экземпляру с каждой стороны (пример, в некоторой организации руководитель занимает отдельный кабинет и руководит лично только одним проектом);

–        один ко многим (1:n), один  экземпляр объекта некоторого класса может поддерживать отношения одновременно с несколькими экземплярами объектов другого или  того же класса (пример, руководитель может иметь несколько подчиненных, но у каждого из них один шеф);



–         много ко многим  (m: n ),  в связи могут принимать участие  несколько экземпляров объектов с каждой стороны.

 Метод С.Шлаер и С.Меллора предусматривает специальную графическую нотацию для фиксации связей, базирующихся  на  диаграммах   метода  Чена сущность -  связь  (entity–relations) [3] для представления  информационной модели проблемной области, суть которого заключается в следующем.

Связи между объектами изображаются стрелками, указывающими направление    связи.    Возле   рамки   объекта, принимающей  участие в связи, на линии стрелки   указывается   роль, которая   этот    объект поддерживает в данной   связи. Связь   1:1   обозначается двунаправленной стрелкой, имеющей по одному "наконечнику" стрелки с каждой стороны, связь 1:n обозначается стрелкой, имеющей  два "наконечника" со стороны объекта, для которого в связи могут принимать участие несколько экземпляров, и, наконец,  по два "наконечника" с каждой стороны имеет стрелка, означающая связь вида n : m.

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

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

                          

                                  Матрица  

                          – тип элемента   

                          – количество строк

                          – количество столбцов


                            Матрица с неполным

                                 заполнением
                                          является 

 



     Диагональная              Ленточная        Разреженная

            

               Рис.4.1. Пример диаграммы класса

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






Инкрементная модель ЖЦ


Эту заложена еще называют нарастающей моделью, суть которой состоит в  возможности

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

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

 

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

– R (Requirements) требования,

– C/T (Coding/Testing) кодирование, тестирование,

– D (Design) проектирование,

– I/AS (Installation/acceptance) инсталляция, сопровождение.

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

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

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

– требования составлены  непонятно для реализации;

– все возможности системы требуется  реализовать с самого начала;

– быстро меняются  технологии и требования к системе;

– ограничения в ресурсном обеспечении (люди, финансы), когда разработчики реализуют систему в течение длительного времени.

Данную модель разработки  целесообразно использовать, в случае когда:

– желательно реализовать некоторые возможности  системы быстро за счет создания промежуточного продукта;

– система  разделена на  отдельные составные  части структуры, которые можно представлять как некоторый промежуточный продукт;

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

 



Интегратор объектов – брокер объектных запросов


Системную функцию «интегратора» в CORBA  выполняет   брокер ORB и механизм их  удаленного вызова. В рамках CORBA  определена эталонная объектная модель, для объектов  которой  определяются свойства, характеристики и типы данных. Объекты,  обладающие одинаковыми свойствами группируются в классы. Каждому объекту соответсвует  одна или несколько операций вызова его  методов. После выполнения операции объект приобретает некоторое  состояние, которое влияет на его поведение.  Эталонная  модель включает:

–                    язык IDL и транслятор интерфейса компонентов приложений (Application Interface);    

–                    общий объектный сервис (Common Object Services) для управления событиями, транзакциями, интерфейсами, запросами и др.;

– общие средства  (Common facilities), необходимые  для групп компонентов и приложений (электронная почта, телекоммуникация,  управления информацией, эмулятор программ  и др.);

–   брокер объектных запросов;

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

 

Общие объектные сервисы обеспечивают базовые операции для логического моделирования и физического хранения объектов, определяют совокупность операций, которые могли бы реализовывать или наследовать все классы.  Сервисы описываются с помощью специального сервиса спецификаций (Common Object Services Spesification – COSS), который определяет набор объектов, их имена, события, взаимодействие и т.п . Операции, предоставляемые объектными сервисами, становятся доступными приложению  через ORB, поддерживают работу с объектами, их существование и независимость от приложений, которые к ним обращаются.

 

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

Инженерия оценивания стоимости реализации ПрО из компонентов


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

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

        С = С1 + С2 + С3

+ С4  ,    

где   С1  –  стоимость анализа функций ПрО, С2 – стоимость подбора ПИК из репозитария или библиотеки методов с учетом   вновь  разработанных  компонентов, С3 –   стоимость интеграции  всех   компонентов в систему, С4 –    стоимость  определения и обработки  данных ПС.

Рассмотрим  отдельно каждую составную единицу  стоимости ПС.     

Стоимость анализа функций  ПрО имеет вид

                         M 

             С1   = S b1i С1i Fi (Di),

                         I

где       Di  – данные  i–функции в ПС, M – количество функций F в системе,

                            1, когда функция  реализована в компонентах ПС,

  bli =        0, в противном случае.

           

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

                           N    M 

             С2   =  S  S a2

ji С2 (Fji )+ С2 ( PFji ),

                         j     I

где     С2  (Fji )

– стоимость поиска ПИК для функции  Fi , сформулированной на этапе анализа ПрО,  N – количество  новых компонентов и ПИК,  C2(PFji) –  стоимость разработки некоторых типичных программных компонентов,

                    1, когда  j– компонент используется  функцией  Fi

,      

  a 2ji  =        0,  в противном случае.

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

                            N      M      K


               С3   =    S  S   S d2 jik С3 (Ijr ),

                            j       I       r

 где  С3(Ijr) – стоимость создания интерфейсных модулей   пары    компонентов    Ki  и K r

,

                   1, когда  r – параметр из набора Х= (Х1, …,Хr )

есть входным                                   

   d2 jik  =            для  J –компонента,   r–

функции (r =1,..., K),

                    0 ,  в противном случае.

Таким образом, конечный результат оценивания стоимости  ПС получается путем суммирования С = С1 + С2

+ С3 + С4    ( расчет С4 громоздкий – не приводится) и имеет вид:                         M                                         N     M

                    S b1и С1и Fi (Di) +  S  S a2ji

С2 (Fji )+ С2 ( PFji )   +

    С =           N      M      K                        J      I

                     S   S    S d2 jik С3 (Ijr )  + C4 .   

                     j       I        r

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

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

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


Инженерия ПИК


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

          

Инженерия  ПИК ­– это  систематическая и целенаправленная деятельность  по подбору  реализованных программных артефактов, и представленных в виде  ПИК,  анализу их  функций для добавления в качестве готовых в  проектируемую систему  и их интеграция  с другими компонентами. Согласно стандарту ISO/IEC 12207 эта деятельность классифицируется как организационная и планируемая  инженерная деятельность, которая  заключается  в выявлении общих и специфических   черт компонентов  для принятия решений об их использовании в разработке новых ПС [1, 6-10].

            

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

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

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


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

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

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

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

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

Систематическое повторное использование – это капиталоемкий подход, который предусматривает наличие двух  процессов в ЖЦ разработки ПС.

 

Первый процесс – создание ПИК путем:

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

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

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

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



 

Второй процесс

– конструирование новых систем из готовых компонентов путем: 

– понимания сущности новой разработки, цели ее создания и предъявляемых к ней   требований;

– поиска в каталоге готовых компонентов, которые кажутся подходящими для их использования;

– сопоставление  цели новой разработки с возможностями найденных ПИК и принятия решений о целесообразности их использования;

– применение отобранных ПИК и интеграция их  в новую разработку с обеспечением необходимых соединений друг с другом.

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

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

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

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

Основная  парадигма ПИК – “писать – один раз, выполнять – много раз, где угодно”. Архитектура, в которую встраивается готовый ПИК,  поддерживает стандартные механизмы для работы с компонентами как со строительными блоками. Чтобы обеспечить  высокий уровень использования ПИК  они должны обладать такими основными свойствами: функциональность, удобство использования и качество реализации.

 

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



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

– описания, полученные в процессе разработки ПС (спецификации, модели,   каркас (framework и т.п.)

– готовые компоненты ПС или отдельные ее части;

– продукции, фреймы,  диаграммы, паттерны и т.п.

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

Разработке ПС  с помощью ПИК соответствует  модель ЖЦ со следующими этапами:

– анализ объектов  и отношений реализуемой ПрО для выявления ПИК, обладающих общими свойствами, присущими группам объектов этой области;

– адаптация имеющихся в базе ПИК и разработка новых компонентов, не представленных в этой базе и доведение их до уровня ПИК;

–  разработка интерфейсов компонентов и их размещение в базе ПИК;

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

Повторные компоненты могут быть готовыми  прикладными и общесистемными компонентами.

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

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


К ним относятся  ОС, СУБД, сетевое обеспечение, электронная почта и др.

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

На современном рынке программных продуктов циркулируют следующие  виды готовых компонентов:

– структуры данных,

– процедуры и функции на ЯП высокого уровня,

– алгоритмы, программы,

– классы объектов и абстрактные классы,

– API – модули,

– Веб–ресурсы,

 – сервисы и среда развертывания (например, компоненты типа Java Beans, CORBA, COM, .NET)

– готовые абстрактные решения –  паттерны и фреймы.

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

  


Инженерия приложений и предметной области


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

Прикладная инженерия – это инженерия ПИК и  процесс создания ПС из готовых компонентов и ПИК.

Инженерия ПрО ориентирована на создание архитектуры ПрО - ­каркаса (фреймворка), представленной ПИК,  компонентами многоразового применения из семейства программ ПрО и их интерфейсов.

Основными этапами инженерии ПрО являются:

– анализ ПрО и выявление объектов и отношений между ними;

– определение области действий  объектов ПрО;

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

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

– подбор и подготовка компонентов многократного применения, описание аспектов выполнения задач ПрО;

–   генерация отдельного домена, члена семейства  и ПС в целом.

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

Инженерия ПрО  включает в себя  следующие вспомогательные процессы:

– корректировка процессов для  разработки решений на основе ПИК;

– моделирование изменчивости и зависимостей компонентов многоразового использования,  фиксации их в модели характеристик и в справочнике  информации  об изменении моделей (объектных,  Use Case и др.). Фиксация зависимостей между характеристиками модели  избавляет разработчиков от некоторых конфигурационных операций,  выполняемых,  как правило,  вручную;


 – разработка  базы ресурсов  (asset–based development),  в основе которой лежит концепция повторного использования (software reuse) – ПИК, обеспечивающая   компоновку программных продуктов домена;

– сопровождение ресурсов (Asset maintenance) – модификация и эволюция  модели,  архитектуры и продуктов домена за счет готовых ресурсов типа ПИК.

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

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

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


Инженерия требований ПО


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

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

Управление требованиями к ПО заключается  в  планировании и контроле  выполнения  требований и проектных ресурсов в процессе  разработки компонентов системы на этапах ЖЦ.

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

 

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

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

 

При управлении требований выполняются процессы:

–        управления версиями требований,

–        управление рисками,

–        разработка атрибутов требований,

–        контроль статуса требований, измерение усилий  в инженерии требований,


–        другие.

 

Связь между  разработкой и управлением требований представлена на рис.3.1.

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



                          Управление              Управление                   Управление

                            рисками                 конфигурацией                качеством
 

     

        Интеграция                Разработка                       Управление             Планирование

          продукта                 требований                      требованиями              процессов   

 



      Согласование            Технические               Утверждение                 Мониторинг                               

       требований                   решения                     требований                     проекта                       

Рис.3.1. Связь между разработкой требований, управления требованиями и другими процессами проекта


технологии разработки, а  знания, которые


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

Между  стандартом ISO\IEC 12207 и ядром знаний SWEBOK существует связь и взаимовлияние  друг на друга, тем более в разработке обоих документов примерно в одно время принимали участие высококвалифицированные специалисты в области программирования и информатики.

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

Таким образом,  программная инженерии сформировалась как инженерная дисциплина, которая базируются на теоретических и прикладных  методах и средствах разработки ПО, которые будут излагаться в данном учебнике более подробно,  и  стандартах (ISO/IEC 12207,  15404, ISO 9126 и др.), содержащих рекомендации, правила и методики управления  разработкой ПО. Эти два базиса объединяет  инженерия оценивания  результатов на процессах ЖЦ, управление качеством ПО, оценка затраченных ресурсов на его  создание  и учета стоимости деятельности участников разработки. 



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

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

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

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


Изменения в утвержденном КБ


Под конфигурационным контролем принято понимать управление изменениями в ходе ЖЦ или эксплуатации системы. Процесс создания продукта включает

непрерывные корректировки,  которые имеют отношение к уже согласованному и /или утвержденному конфигурационному базису (КБ). В этом плане предметом конфигурационного контроля являются:

– изменения в утвержденном КБ и связанные с ними корректировки в конфигурации и /или ЕК;

–        дефекты и отклонения в конфигурации продукта относительно утвержденного КБ.

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

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

1. Регистрация предложения /запроса на изменение.

2. Анализ влияния предложенного изменения на имеющийся  задел, объем, трудоемкость, график и стоимость работ по проекту.

3. Принятие решения по запросу на изменение (удовлетворить, отказать или отложить).

4. Реализация утвержденного  изменения и его верификация.

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


Для устранения дефектов и выявленных отклонений проводится:

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

–        анализ и: диагностика места и причины дефекта /отклонения, оценка объема, трудоемкости, сроков и стоимости переделок;

–        принятие решения по устранению дефекта /отклонения, реализация и верификация этих недостатков.

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

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

Наиболее удобной формой реализации такого управленческого  решения являются руководящий совет по конфигурационному контролю CCB (Configuration Control Board), как родоначальник теории и практики конфигурационного управления.


Язык описания интерфейсов объектов


 

Язык IDL позволяет описывать типы данных, интерфейсы объектов и модули, которые вызываются для выполнения, а  также предоставляет средства для описания параметров объектов, передаваемых в сообщении другим объектам. В нем описываются интерфейсные программы клиента и сервера (клиент-stub и  сервер-skeleton), а сами программы описываются в ЯП С++ или JAVA.

 

Описание интерфейсов начинается с ключевого слова interface, за  которым следует идентификатор (имя интерфейсной программы), образующие вместе заголовок,  и тело, содержащее описание типов  параметров  для обращения к объекту. Пример описания заголовка  описания интерфейса:

      interface A { ... }

      interface B { ... }

      interface C: B,A { ... }.

Тело интерфейса содержит описание:  типов данных  (type_dcl), констант (const_dcl), исключительных ситуаций (except_dcl), атрибутов параметров (attr_dcl), операций (op_dcl).

                 

Описание типов  данных начинается ключевым словом typedef, за которым следует базовый или конструируемый тип и его идентификатор.  В качестве константы может быть некоторое значение типа данного или выражение,  составленное из констант. Типы констант могут быть:  integer, boolean, string, float, char и др.

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

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

in  - при отсылке параметра от клиента к серверу;

out - при отправке параметр-результатов от сервера к* клиенту;

inout - при передаче параметров в оба направления (от клиента к серверу и от сервера к клиенту).

    

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

     const long l=2

     interface A  {

          void f (in float s [l]);

       }

     interface  B {

          const long l=3

      }

     interface C: B,A {  }.


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

    

interface Vlist  {

status add_item (

     in Identifier item_name,

     in typeCode   item_type,

     in void       * value,

     in long       value_len,

     in Flags      item_flags

                );

status free ( );

status free_memory( );

status get_count (

     out long count);

                 };

    

Описание модуля  в языке IDL начинается с ключевого слова module, за которым следует имя модуля и описание  его тела.

Средства описания типов. Язык IDL позволяет описывать типы данных, которые задают параметры, передаваемые от объекту к объекту. Типы данных подразделяются на базовые, cсылочные и конструируемые.

К базовым типам относятся фундаментальные типы данных:

16- и 32-битовые (короткие и длинные) знаковые и беззнаковые двухкомпонентные целые;

32- и 64-битовые числа с плавающей запятой, что соответствует стандарту IEEE;

cимвольные;

8-битовый непрозрачный тип данных, обеспечивающий преобразование данных в момент пересылки между объектами;

булевые (TRUE, FALSE);

строка, которая состоит из массива одинаковых длин символов, допустимых во время выполнения;

перечисляемый тип, включающий упорядоченную последовательность идентификаторов;

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

Конструируктивные типы создаются  из базовых типов и включают:

– запись, состоящая из множества упорядоченных пар (имя-значение);

– структура, состоящая из совокупности разнородных базовых элементов;

различительное объединение, содержащее дискриминатор, за которым располагается подходящий тип и значение;

– последовательность, представляющая собой массив, компоненты которого имеют переменную длину и одинаковый тип;

– массив, состоящий из компонентов фиксированной длины одинакового типа;

– интерфейсный тип, специфицирующий множество операций, которые клиент может послать в запросе.

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


Язык описания интерфейсов в системе CORBA


Для задания взаимодействия объектов в системе  CORBA используется язык описания интерфейсов IDL, который независим от языка описания самого объекта, а именно С, С++, Паскаль и др. Интерфейсы объектов в IDL-языке запоминаются в репозитории интрфейсов (Interface Repository),  а реализации объектов -- в репозитории реализаций (Implementation Repository). Независимость интерфейсов от реализаций объектов  позволяет их использовать статически и динамически разными приложениями.

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

Интерфейс клиента (Сlient Interface) обеспечивает взаимодействие  с объектом-сервером с помощью ORB и  состоит из трех  интерфейсов:

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

 – интерфейса динамического вызова  (Dynamic Invocation Interface – DII) объекта, определяемого во время выполнения программы клиента посредством поиска описания интерфейса  в репозитории интерфейсов или в  репозитории реализаций;

– интерфейса сервисов ORB (ORB Services Interface), содержащего набор сервисных функций, которые клиент запрашивает у сервера через брокера.

Stub-интерфейс  – клиентский интерфейс, обеспечивает взаимосвязь клиента с ORB. Прикладная программа клиента через посредника stub – статической части программы клиента  посылает в запросе параметры, которым сопоставляются соответствующие описания  из репозитория интерфейсов.

Интефейс DII  обеспечивает доступ (извлечение) объектов  и их интерфейсов во время выполнения. Этот  интерфейс становится известным во время выполнения и  доступен благодаря вызова  брокера ORB. В  каждом вызове указывается тип объекта,  тип запроса  и параметры.  Такую  информацию посылает прикладная  программа либо она извлекается из репозитория интерфейсов или репозитория реализаций.

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

– базовый адаптер  (Basic Object Adapter -- BOA), который может обеспечивать выполнение объектов независимо от брокера;

– библиотечный адаптер (Library Adapter), обеспечивающий выполнение объектов, хранящихся в библиотеке объектов и вызываемых из прикладной программы клиента; 

– адаптер БД (Database Adapter), обеспечивающий доступ к объектно-ориентированным БД.



Языковые средства описания компонентов


В работе в качестве основного объекта всех методов проектирования новых ПС  на процессах ЖЦ применяется компонент. К средствам  описания компонентов относятся  языки программирования  (JAVA, C++), язык описания  интерфейсов  IDL, язык моделирования UML,  средства описания взаимодействия компонентов (вызовы, протоколы) в распределенной среде, а также разные виды  инструментальной поддержки этих описаний (система JAVA, CORBA, RUP, Rational Rose и др.) со средствами  обслуживания и использования готовых сервисов и программ.

Данный раздел посвящен рассмотрению двух основных направлений программной инженерии – средствам и инструментам, включая:

1. Языковые средства описания компонентов,  их интерфейсов и моделей ПС (JAVA, CORBA,  IDL,  UML).

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

3. Методы и средства разработки производственной архитектуры  MSF



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


Компонент – это единица интеграции, специфицированная так, чтобы можно было ее объединять с другими компонентами в ПС. Важнейшее свойство компонента – отделение его интерфейса от реализации, в отличие от объектов в  объектно–ориентированных ЯП,  в которых  реализация класса отделена  от определения  класса [1]..

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

Более крупным образованием компонентов, используемым в практике программирования,  являются  паттерны и каркасы [2].

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

На

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

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

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

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


Экспликативное программирование (ЭП)


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

К принципам ЭП  относятся.

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

– принцип прагматичности   или полезности определения понятия программы выполняется с точки зрения понятия "проблема"  и ориентирован на  решение  задач  пользователя.

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

(номинации).

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

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

Таким образом,  процесс  развития  программы осуществляется в виде  цепочки понятий: данные – функция – имя функции – композиция – дескрипция. Понятия "данные – функция – композиция" задают  семантический аспект программы, а "данные – имя функции – дескрипция" – синтаксический аспект.
Главным в ЭП является  семантический аспект, система композиций и номинативности (КНС), ориентированные на систематическое изучение номинативных отношений при построении данных, функций, композиций и дескрипций [36].

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

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

В рамках ЭП разработаны новые средства [36] для определения систем данных, функций и композиций номинативного типа, имена аргументов которых принадлежат некоторому множеству  имен Z, т.е.  композиция определяется на Z–номинативных

наборах именных функций.

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

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

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

Практическая  проверка теоретического аппарата  формализации дедуктивных и ОО БД прошла в ряде экспериментальных проектов в классе манипуляционных  данных  БД заданных в SQL–подобных языках [39].


Энциклопедия инструментов создания ПС из объектов и компонентов


Основным инструментом проектирования приложений является  CASE–cистема Rational Rose [14], основанная на применении  языка UML для представления архитектуры ПС  с помощью разных  видов его  диаграмм.  Средства системы на проектирование и моделирование общей модели (абстрактной) предприятия, постепенно уточняемой  до конкретной (физической) модели классов создаваемой ПС. Допускается  доработка созданной системы. Результатом моделирования является визуальная логическая модель системы.

Rational Rose – средство для проектировщиков, аналитиков, разработчиков объектно–ориентированных информационных систем на языке  UML, представляемых  в виде  файлов логической модели, используемой при кодировании средствами  конкретного ЯП (С++, Ada, Java, Basic, Xml, Oracle). Имеются  специальные мосты связи с  системой Delphi, что дает возможность связывать программный код системы с БД. Допускается обратное проектирование, т.е.  преобразование готовой  информационной  системы (например, на С++) или база данных (в Oracle)  в наглядную визуальную, структурную модель ПС.

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

 

Управление проектом и версиями. ClearCase – система  управления программным проектом, сохраняет  в  архиве все изменения и версии, которые были внесены в проект. Эти данные хранятся в масштабируемых репозиториях, а также хранятся  исходные тексты программных модулей, исполняемые и объектные модули,  библиотеки DLL.
Система позволяет работать как по  командам, так и по  времени выхода из нее, впоследствии объединяются  данные с общим проектом. Можно выводить подробные характеристики измененных файлов в наглядной графической форме, представлять все изменения в виде дерева версий. При наличии MultiSite открывается возможность обмена данным между группами разработчиков, географически удаленных друг от друга. При этом ClearCase берет на себя все рутинные операции по пересылке/приемке информации.

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

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

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

Ведение изменений. ClearQuest  для архивирования всех изменений и создания БД в  MS SQL, MS Access, Sybase SQL Anywhere или Oracle.


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

– управление изменениями, возникающими в ходе процесса разработки ПО;.

– оптимизация пути прохождения запросов и  связанных с ними форм и процедур;

– поддержка связи объектов, разделенных территориально через World Wide Web;

– внедрение надежного и проверенного процесса CRM, либо изменение уже существующего процесса для удовлетворения специфическим требованиям;

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

– интеграция со средствами конфигурационного управления (Rational’s ClearCase), позволяющая создавать связи между запросами на изменение и развитием кода;

– связь с  Sybase, Oracle, Microsoft;.

– интеграция со средствами тестирования Rational (TeamTest, VisualTest, Purify, PureCoverage, Quantify и Robot);

– создание  отчетов на базе Crystal Reports (из составаProfessional);

–  интеграция через COM с MS Word и MS Excel.

Инструменты измерения. Rational Quantify – инструментальное средство для идентификации "узких мест" в разрабатываемых приложениях, учета производительности, идентифицирующее и выявляющее части приложения, которые замедляют скорость его выполнения. Это средство генерирует в табличной форме список всех вызываемых в процессе работы приложения функций, указывая временные характеристики каждой из них; предоставляет  статистику по всем вызовам (внешним и внутренним). Сбор данных осуществляется посредством технологии OCI (Object Code Insertion) путем подсчета  циклов, вставки счетчиков в код тестируемой программы. Уникальность данного подхода заключается в тестировании  исходного кода, внутреннего представления, а также всех используемых компонентов. Статистическая информация по вызовам может быть перенесена в Microsoft Excel для построения  графиков и сводных таблиц для разных запусков приложения.

Основные свойства продукта:

– предоставление точной информации  о производительности созданного  приложения;



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

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

– графическое средство Call Graph из Rational Quantify – наглядное представление данных о критических функциях системы, требующих наибольшего времени для выполнения;

– средства Function List и Function Detail выдает в визуальных  окнах данные в  табличной форме  для непосредственного внесения изменений в участки кода, а также для построчного просмотра данных в  аннотированных копиях окон Source Code;

– выход  в DCE,  систему  Solaris и библиотеки SunOS;

– сбор  данных о производительности по всем используемым инструментам

– использование  языков (C, C++, FORTRAN, Ada и Java ) и соответствующих систем программирования.

Тестирование. Visual Test обеспечивает функциональное, не зависящее от языка реализации тестирование 32–битных приложений, написанных для Windows, а также компонентов ActiveX, DLL, сервера автоматизации OLE (OLE Automation server) или приложения на основе Web. Продукт имеет интерфейс с VisualStudio  компании Microsoft. Кроме того,  он  дает возможность создавать поддерживаемые, расширяемые и пригодные для повторного применения компоненты тестирования, а также приспосабливать их  во многие версии других проектов.

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



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

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

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

 

Pure Coverage предназначен для выявления участков кода, пропущенных при тестировании приложения  Windows NT и компонентов, написанных на Visual Basic,  Visual C++ или Java. Инструмент собирает статистику о тех участках программы, которые во время тестирования не были пройдены   выявляет  не исполнившиеся строки  и анализирует   причины их невыполнения.

 

Управление качеством.  Для улучшения качества производимого кода в методологии Rational предусмотрен определенный набор средств: Visual Test, Rational Quantify, Purify, Pure Coverage. Инструмент Visual Test  используется  для высокоуровневого тестирования ПС и интерфейсов компонентов.


Rational Robot и LoadTest обеспечивают загрузочное тестирование приложений клиент–сервер.

Инженерия и реинженерия. Rational Rose Professional  имеет набор изобразительных средств и в  зависимости от выбранного ЯП осуществляет прямое и обратное проектирование ПС. Результат проектирования – шаблон информационной системы, который необходимо  запрограммировать на  ЯП. Rose Enterprise  для проектирования предприятия  с использованием многих перечисленных выше инструментов.

Rose DataModeler компонент  Rational Rose, предназначен  для  проектирования системы и баз данных без  кодогенерации.

 

Rose RealTime – специализированная версия для проведения  полной (100%) кодогенерации и реинженерии  систем на С и С++ с использованием набора диаграмм UML.

Анализ состояния среды. Purify направлен на разрешение проблем, связанных с утечками памяти и Run–time ошибками. Программа собирает данные о любых потерях в памяти. К ним можно отнести и невозвращение блока, и не использование указателей, и остановку исполнения программы с выводом состояния среды при возникновении ошибки run–time. Разработчик ПС имеет возможность не только видеть состояние исполнения (предупреждения, ошибки) ПС, но и переходить к соответствующим  внутренних вызовов других компонентов.

 

Документация. SoDa – инструмент автоматизации документов и подготовки отчетов по заранее установленному шаблону, по которому компилируется документация в одном документ с текстовыми и графическими данными. Допускается использование стандартных шаблонов,  созданных пользователем при помощи Wizard и  меню Word.

 


Этап анализа поведения ПС


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

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

– построение объектной системы;

– адаптация объектной системы.

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

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

– в определении отношений и связей между этими понятиями соответственно  отношениям и связях между реальными объектами, которые важные для функциональности будущей ПС;

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

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

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

Адаптация объектной системы.

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



Этап интеграции


 

Главными задачами этого этапа является определение, поиск и выбор всех необходимых компонентов, их адаптация, определение плана компонентной конфигурации, создание и тестирование интегрированной среды для ПС. Поиск и выбор компонентов объединяются в одну задачу, что называется квалификацией (Component Qualification), а интеграция компонентов определяется  как композиция, которая разделяется на несколько видов  в зависимости от комбинаций компонентов. Входными данными процесса  являются описания:

– интерфейсов компонентов на языке описания интерфейсов;

– взаимодействие компонентов описывается соответственно последовательностями операций для выполнения функций в ПС;

– дополнительные условия и данные для интеграции и управления компонентами.

На  этапе интеграции  соответственно выполняются  следующие процессы:

– поиск компонентов соответственно описанию интерфейсов;

– выбор совокупности компонентов, которые обеспечивают необходимую функциональность;

– адаптация существующих компонентов к требованиям построения интегрированной среды;

– создание новых компонентов, для которых результаты поиска, выбора и адаптации не дали требуемых результатов;

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

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

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

– тестирование интегрированной среды.

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

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

 

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

 

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

– расширение существующих интерфейсов компонентов с целью соответствия интерфейсам в интегрированной среде;

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

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

 

Создание компонентов.

Этот процесс выполняется, когда предыдущие процессы поиска, выбора, адаптации для определенных компонентов дают отрицательные результаты. В этом случае необходимо создавать новые компоненты с заранее определенными интерфейсами и функциональностью.  Для правильного построения новых элементов используется модель Enterprise java beans (EJB), в состав которой входят:

– сервер EJB, как прикладной сервер, в среде которого загружаются и выполняются один или больше контейнеров EJB;

– контейнер EJB, который отвечает за создание среды и условия функционирования соответствующего компонента;

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

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



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

 Определение правил и условий интеграции. Правила и условия интеграции зависят от компонентной модели, практическое применение имеют три:

– COM/DCOM/COM+, реализованная в операционных системах семейства WINDOWS;

– система CORBA [11], которая  поддерживается на различных платформах;

–Javabeans и enterprise javabeans [13] на базе JAVA–технологий, которые функционируют на платформах, для которых реализованы виртуальные JAVA–машины.

 

Построение проекта. Главная цель процесса – выполнить все действия относительно подготовки интегрированной среды к функционированию и создание плана конфигурации компонентов ПС.

Тестирование интегрированной среды.  При тестировании решаются две задачи:

– проверка функциональности ПС;

– проверка возможности совместимой работы компонентов системы.

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

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

1.  Инициирование работы интегрированной среды для ПС.

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

3. Для каждой пары компонентов, которые взаимодействуют, один с них является  клиентом, а второй – сервером. Серверы функционируют в режиме ожидания, пока клиенты к ним не обратятся. Механизм поддержки режима функционирования на уровне операционной среды является  механизмом сервисов.

4. Схема взаимодействия компонентов в ПС является  ориентированным графом. Приведенные факторы и определяют порядок и содержание второй задачи для проведения тестирования:

– проверка процедуры старта ПС;

– проверка функционирования и создания инфраструктуры для поддержки компонентной модели;

– проверка корректности регистрацииї сервисов и возможности взаимодействия с ними с различных компьютеров сети;

– проверка корректности последовательностей инициирования сервисов.

 


Этап развертывания компонентов системы


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

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

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

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

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

В состав этапа развертывания  входят:

– оптимизация плана компонентной конфигурации  соответственно  имеющей компьютерной базе пользователя, ее свойств и топологии;

– развертывание отдельных программных компонентов;

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

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

 Главная задача  процесса – определения реальной конфигурации компонентов и оптимизационная  задача с данными:

–  компьютерные мощности и способы коммуникации у пользователя;

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

– план компонентной конфигурации.

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

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

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

– расположение отдельных компонентов (сетевые адреса, имена каталогов и файлов);

– характеристики компонентов (например, размеры, необходимые ресурсы и условия функционирования и др.);

– описание взаимосвязей компонентов (например, описание последовательностей инициирования и окончания работы).

Этот процесс завершает создание целевой конфигурации. Предыдущая информация дополняется:

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

– технологическим регламентом (например, по времени и периодичности инициирования компонентов, выполнению определенных задач и др.);

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


Этап сопровождения


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

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

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

– замена существующих компонентов новыми компонентами с  сохранением интерфейсов и сервисных возможностей;

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

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

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

– модификация компонентной конфигурации;

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

– анализ отказов функционирования, обнаружение дефектов, поиск и исправления ошибок в программной системе;

–  тестирование ПС.

Кратко остановимся на общей характеристике этих процессов.

Модификация компонентной конфигурации. Этот процесс отвечает за следующее:

– добавление и исключение определенных компонентов;

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


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

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

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

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

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

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

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

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



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

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

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

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

–  сами компоненты в готовом к применению виде;

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

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

 При  разработке  тестов учитывается:

– последовательности взаимодействий компонентов, в состав которых входят те компоненты, которые  проходят тестирование;

– информация о самостоятельном тестировании компонентов (используется для уменьшения объема тестирования);

–  условия для нормального функционирования компонентов.

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

 

                                                                                                          






Этап спецификации интерфейсов и взаимодействия компонентов


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

– распределение ролей компонентов;

– проектирование и спецификация отдельных интерфейсов;

– описание взаимодействий компонентов.

 

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

 

Проектирование и спецификация интерфейсов.

Проектирование интерфейсов происходит соответственно ролям компонентов. Важно придерживаться концепции оптимальности в проектировании – интерфейсов для компонента не должно быть много, но в тот же время не нужно проектировать мало, но  большие по размеру интерфейсы. Каждый из  типов интерфейсов – клиентский или сервисный – проектируется в отдельности, идентифицируется  и определяется состав поддерживаемых ими операций. Описание отдельных интерфейсов проводится в языке  IDL для модели CORBA.

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

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



Эволюционная модель ЖЦ


В случае эволюционной модели система разрабатывается в виде последовательности блоков структур (конструкций). В отличие от инкрементной модели ЖЦ, подразумевается, что требования устанавливаются частично и уточняются в каждом последующем промежуточном блоке  структуры системы (рис.2.4.).

На данном рисунке модели  используются следующие обозначения

– R (Requirements) требования,

– C/T (Coding/Testing) кодирование, тестирование,

– D (Design) проектирование,

– I/AS (Installation/acceptance) инсталляция, сопровождение.

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

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

При этом подходе учитываются такие факторы риска:

– реализация  всех возможностей системы сразу;

– ограниченные ресурсы (людские, финансовые) заняты разработкой  в течение длительного времени.

Преимущества применения данной модели ЖЦ состоит в следующем:

– проведение быстрой реализация некоторых возможностей системы;

– промежуточный продукт  может использоваться на следующем процессе;

– в системе выделяются  отдельные части для реализации их в отдельности;

– возможность увеличения финансирования системы;

–  обратная связь устанавливается с заказчиком для уточнения  требований;

–  упрощение внесения  изменений.

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



Качество ПО (Software Quality)


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

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

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

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


Окончательная оценка качество проводится в соответствии  со стандартом  ISO 15504-98 [15]. Качество может повышаться за счет постоянного улучшения используемого продукта, в связи с  процессами обнаружения, устранения и предотвращения сбоев/ дефектов в ПО.  

Область знаний «Качество ПО (Software Quality)» состоит из следующих разделов:

– концепция качества ПО  (Software Quality Concepts),

– определение и  планирование качества (Definition & Planning for Quality),

– деятельности и техники гарантии  качества и V&V(Activities and Techniques for Software Quality Assurance, Validation –V & Verification – V),

– измерения в анализе качества ПО (Measurement in Software Quality Analysis).

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

 

Концепция качества ПО включает внешние и внутренние  характеристики  качества,  их метрики, а также  модели качества, определенные на множестве  внешних и внутренних характеристик, которые определены  в стандартах качества [16] – это  шесть характеристик  и для каждого из них  4-5 атрибутов. К характеристикам качества относятся:

– функциональность,

– надежность,

– удобства использования,

– эффективность, 

– сопровождаемость, 

– переносимость.

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

 

Определение  и планирование качества ПО

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

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


Планирование качества включает: 

– определение продукта в терминах заданных характеристик качества;     

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

– выбор методов оценки планируемых характеристик качества и установления соответствия продукта сформулированным требованиям.

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

 

Деятельности и техники гарантии  качества включают: инспекцию, верификацию и валидацию  ПО.

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

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

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

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

 

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



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

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

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

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

 

Таким образом,   данная область знаний SWEBOK представляет методологию проведения мероприятий по достижению высокого качества ПО.  Рассматриваются характеристики и  атрибуты качества,  согласно  стандарта  ISO 9126-98,  и приведены способы  их достижения   на процессах ЖЦ ПО. Определяются  виды и техники   анализа  ПО, прогонки системы на тестах и методы оценки показателей качества.


Каскадная модель ЖЦ


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

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

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

            

                 Рис. 2.1. Каскадная модель ЖЦ разработки программных систем

При таком подходе необходимо  учитывать следующие факторы риска:

– требования недостаточно хорошо представлены;

– система слишком большая по объему, чтобы быть реализованной  в целом;

– быстрые изменения в технологии и в требованиях;

– ограниченные ресурсы (людские, программные и др.);

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

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

– все возможности системы реализуются одновременно;

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

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

 



Классификация моделей надежности


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

В виду большого разнообразия моделей надежности, разработано несколько подходов к классификации этих моделей. Эти подходы  в целом основываются на истории ошибок в проверяемой и тестируемой ПС на этапах ЖЦ. Одной из классификаций моделей надежности ПО является классификация  Хетча [5, 16]. В ней  предлагается  разделение моделей на: прогнозирующие, измерительные и оценочные (рис 9.1).

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

Модель Холстеда дает прогнозирование  количества ошибок в программе  в зависимости от  ее объема и таких данных, как число операций (n1) и операндов (n2), а также их общее число (N1, N2).

                        

                                                              Модели

                                                       надежности  ПС

             Прогнозирующие              Измерительные                   Оценочные

         Модель        Модель           Модели         Модели       Модели           Модели


          Холс–          Мотли–                без             с  под–        Муссы,           подсева

          теда             Брукса           подсчета        счетом          выбора           ошибок

                                                       ошибок        ошибок        области

                                                                                                   данных

                                   Рис.9.1.   Классификация моделей надежности

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

           T = (n1 N2   (n1 log2 n1  + n2 log2 n2  ) log2 n1 / 2 n2 S,

где S – число Страуда (Холстед принял равным 18 – число умственных операций в единицу времени).

Объем вычисляется по формуле:

          V = ( 2 + n2*) log2 (( 2 + n2 *), где  n2 * ­–  мах число различных операций.

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

 – программного обеспечения не модифицируется во время периода измерений свойств надежности;

– обнаруженные ошибки не исправляются;

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

Типичным примером таких моделей является модель Нельсона и Рамамурти–Бастани и др.

Модель оценки надежности Нельсона основывается на выполнении  k–прогонов программы при тестировании и   позволяет определить надежность

                R (k) = exp [– å Ñtj l (t)],

где  tj – время выполнения  j–прогона, l (t) = – [ln (1– qi) Ñj] и при   qi  £ 1  она интерпретируется  как интенсивность отказов.

В процессе испытаний программы на тестовых nl

прогонах  оценка надежности вычисляется по формуле

            R (l) =  1 – nl / k, где k

– число прогонов программы.

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



Оценочные модели основываются на серии  тестовых прогонов и проводятся на этапах тестирования ПC. В тестовой среде  определяется вероятность отказа программы при ее выполнении или тестировании.

Эти типы моделей могут применяться на этапах ЖЦ. Кроме того,  результаты прогнозирующих моделей могут использоваться как входные данные  для оценочной модели. Имеются модели (например, модель Мусы), которые  можно рассматривать как оценочную и в тоже время, как  измерительную модель [19, 20].

Другой вид классификации моделей предложил Гоэл [21, 22], согласно которой модели надежности базируются на отказах и  разбиваются на четыре класса моделей:

– без подсчета ошибок,

– с подсчетом отказов,

– с подсевом ошибок,

–  модели с выбором областей входных значений.

 Модели без подсчета  ошибок   основаны на  измерении  интервала  времени  между 

отказами и позволяют спрогнозировать количество ошибок, оставшихся в программе.  После каждого отказа оценивается надежность и определяется среднее время до следующего отказа. К такой модели относится модель Джелински и Моранды, Шика Вулвертона и Литвуда–Вералла [23, 24].

Модели  с подсчетом отказов базируются   на количестве ошибок, обнаруженных на заданных интервалах времени. Возникновение отказов в зависимости от времени  является стохастическим процессом с непрерывной интенсивностью, а количество отказов является случайной величиной. Обнаруженные ошибки устраняются  и поэтому количество ошибок в единицу времени уменьшается. К этому классу моделей относится модель Шумана, Шика–Вулвертона, Пуассоновская модель и др.[24–,27]

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


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

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

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

модели, которые рассматривают количество отказов как  Марковский процесс;

модели, которые рассматривают интенсивность  отказов как Пуассоновский процесс.

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


Классификация требований


Формируемые требования к системе разделены на две   категории:

  –  функциональные требования, которые отображают возможности проектируемой системы;

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

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

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

 

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

 

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

– конфиденциальность;

– отказоустойчивость;

– одновременность  доступа к системе пользователей;

– безопасность;

– время ожидания ответа на обращение к системе;

– ограничения на исполнительские функции  системы ( ресурсы памяти, скорость реакции на обращение к системе и т.п.);

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

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

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

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



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

Процесс формализованного описания функциональных и нефункциональных требований, а также требований к характеристикам  качества   с учетом  стандарта  качества  ISO/IEC 9126–94 будет уточняться   на этапах ЖЦ ПО и специфицироваться. В спецификации требований отражается структура ПО, требования к функциям,   качеству и  документации, а также задается архитектура системы и ПО, алгоритмы, логика управления и структура данных. Специфицируются также системные,  нефункциональные требования и требования к взаимодействию с другими   компонентами и платформами (БД, СУБД,  сеть и др.).  


Кодекс этики программной инженерии


Своим появлением программная инженерия обязана деятельности мощных  профессиональных   объединений – The Assocіatіon for Computer Machіnery (ACM) и Instіtute of Electrіcal and Electronіcs Engіneers Computer Socіety (IEEE Computer Socіety).  Общими усилиями этих двух объединений разработан кодекс этики программной инженерии, который фокусирует мораль, правила и нормы поведения профессионалов, их обязательства и ответственность по отношению к обществу и один к  другому [1, 2].

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

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

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

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

В кодексе задекларировано восемь принципов, которые  касаются соответственно:

1) согласование профессиональной деятельности с интересами общества;

2) взаимоотношение между клиентом, работодателем и исполнителем разработки;

3) достижение соответствия качества продукта лучшим профессиональным стандартам;

4) соблюдение честности и независимости при профессиональных оценках;

5) соблюдение этических норм в менеджменте и в сопровождении разработок;

6) поддержка становления профессии в соответствия с кодексом этики;

7) соблюдение этических норм во взаимоотношениях между коллегами;

8) усовершенствование специальности.

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

                           



Количественная оценка рисков


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

– вероятность достижения конечной цели проекта

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

– риски, требующие скорейшего реагирования и большего внимания, а также влияние их последствий на проект;

–        фактические затраты и  предполагаемые сроки окончания работ на проекте.

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



Команда тестировщиков


За функциональные и исполнительные  тесты  несут  ответственность разработчики,   а   заказчик  больше влияет на   составление тестов испытаний и инсталляции системы.

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

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

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

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

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

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

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

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

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

Для проведения тестирования тестовые инженеры предлагают процедуры тестирования (Test Procedures), включающие  валидацию объектов и верификацию тестовых сценариев в соответствии с планом графикам.


Оценка тестов (Test Evaluation) заключается в оценке результатов тестирования и степени покрытия программ сценариями и  статуса полученных  ошибок. На рис. 7.5. приведен круг обязанностей тестового инженера.    

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

                                                       

                                                          Teстировщик

                                                                    



           Программы       Тестовые        Тестовые                Оценка                  План  

                тестов           ситуации       процедуры              тестов                    теста

                           Рис.7.5. Ответственности инженера– тестировщика

       


Компонентный подход к проектированию


По оценкам экспертов, 75 % работ по программированию в мире дублируются (например, программы складского учета, начисления зарплаты, расчета затрат на производство продукции и т.п.). Большинство из этих программ типовые, но каждый раз находятся особенности, которые влияют на их повторное разработку. Компонентное проектирование сложных программ из готовых компонентов является наиболее производительным [8–12].

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

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

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

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

Элемент композиции

 Описание элемента

Схема взаимодействия

Представле–ние, хранение

Результат композиции
Процедура, подпрограмма, функция

 Идентификатор

 Непосредственное обращение, оператор вызова

 Библиотеки подпрограмм и функций

 Программа
Модуль

 Паспорт модуля, связи

 Вызов модулей, интеграция модулей

 Банк, библиотеки модулей

 Программа с модульной структурой
Объект

 Описание класса

 Создание экземпляров классов, вызов методов

 Библиотеки классов

 Объектно–ориентиро–ванная программа
Компонент

 Описание логики (бизнес), интерфейсов (APL,IDL), схемы развертывания

Удаленный вызов в

компонентных моделях (COM, CORBA, OSF, …)

 Репозитарий компонентов, серверы и контейне–ры компонентов

 Распреде–ленное компонентно–ориенти–рованное приложение
Сервис

 Описание бизнес–логики и  интерфей–сов сервиса (XML, WSDL, …)

 Удаленный вызов (RPC, HTTP, SOAP, …)

 Индексация и каталогизация сервисов (XML, UDDI, …)

 Распреде–ленное сер–висо–ориен–тированное приложение
<
 

               Рис.5.2. Схема эволюции элементов компонентов

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

–        интероперабельность  как способ взаимодействия с другими компонентами,  с  клиентом или сервером, а также обеспечения переносимости на другую платформу;

–        способ интеграции (композиции) компонентов;

–        нефункциональные сведения (безопасность, аутентификация, надежность и др.);

–        технология проектирования  (например, объектно–ориентированная среда и т.п.) и повторное использования компонентов.

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

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

 

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

Внутренняя часть компонента состоит  из (рис.5.3): интерфейса (interfaces), реализации (implementation), схемы развертки (deployment).

ХАРАКТЕРИСТИКИ
Интерфейс

¨      Один или несколько;

¨      Уникальность именования в пределах системы;

¨      Клиентский или серверный (входной или выходной);

¨      определенная сигнатура;

¨      описание методов взаимодействия 

Реализация

¨      одна или несколько;

¨      ориентация на конкретную платформу и  операционное окружение

¨      выбор конкретной реализации;

¨      поддержка интерфейсов компонента

 Схемы развертывания

 

¨      типовость процедуры развертывания;

¨      управляемость;

¨      настраиваемость на операционную среду;

¨      модифицируемость
<


           

                   Рис.5.3. Основные составные  элементы  компонента

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

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

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

Компонент описывается в языке программирования, не зависит от операционной среды (например, от среды виртуальной машины JAVA) и от реальной платформы (например, от платформ в системе CORBA), где он будет функционировать.

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

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

 

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

Спецификация интерфейса в API и IDL включает описание функциональных свойств компонентов, их типов и порядка задания операций передачи аргументов и результатов для взаимодействия компонентов. То есть, компонент – физическая сущность, которая реализует определенную совокупность интерфейсов. Сами интерфейсы являются понятием, которое связывает логическую и физическую модели. Для описания самих компонентов, как правило, применяется ООП и его свойства: наследование, инкапсуляция, полиморфизм.В  языке JAVA  понятие интерфейса и класса являются базовыми. Компонентные модели – Javabeans и Enterprise Javabeans, а также модель CORBA используют объектно–ориентированные свойства.


КОМПОНЕНТОВ И ДАННЫХ


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

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

2. Методы преобразования типов данных программ, записанных на разных ЯП, для  обеспечения  их взаимосвязи, а также рекомендации стандарта ISO/IEC 11404-1996 по обеспечению независимости типов данных от  современных ЯП;

3.  Преобразование  данных, хранящихся   в разных типах БД  в целях   замены устаревших БД на новые.

4. Методы внесения изменений в компоненты и в ПС (реинженерия, рефакторинг и реверсная инженерия).

                                                                



Компоненты сеансов


В языке  JAVA в качестве  готовых компонентов используются beans компоненты, которые включают описание функциональности, интерфейса и шаблона развертывания, как средства интеграции  их в новые ПС. Он может повторно использоваться в разных средах для  выполнения своих  функций самостоятельно  или в составе с другими компонентами. Класс можно сделать Beans компонентом, внеся  небольшие  изменения  с помощью специальной утилиты  системы BDK (Bean Development Kit) [3-5].

Компоненты beans подразделяются на три категории:

1. Компоненты сеансов, которые  поддерживают правила бизнеса–логики, ориентированы

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

 2. Компоненты сущностей используются для связи с БД непосредственно, представляют данные в объектной форме;

3. Компоненты, которые управляются событиями, функционируют для получения сообщений, поступающих от системы обмена сообщениями JMS (Java Messaging System), и реагируют на них.

При  создании bean компонентов используется  интерфейсы: Home для управления ЖЦ компонента, интерфейс Remote для вызова и рализации компонента  в среде виртуальной машины JVM (Java Virtual Machine). Каждый компонент beans имеет свой контейнер, который  вызывает и регулирует все аспекты ЖЦ, а также  интерфейс.

Основной особенностью beans компонентов в JAVA является  отображение –   т.е.способность анализировать самого себя и описывать свои возможности динамично во время выполнения, а не во время компиляции. Пакет JAVA java.lang.reflect входит в ядро API, поддерживает отображение разных компонентов и содержит один интерфейс – Member,  определяющий методы получения информации о полях, структуре  классов.

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

Bean компонента – это подмножество состояний, которые  определяют поведение и внешний вид компонента.
Эти свойства делятся на простые, булевы и индексированные. Простые свойства имеют одиночные значения, могут быть идентифицированы  проектными шаблонами (например,  свойства для   read/write, read–only, write–only). Булевы  свойства принимают значение true или false и идентифицируются проектными шаблонами. Индексированные свойства состоят из множества индексированных значений, задаваемых   проектным  шаблоном. 

Bean компоненты могут иметь,  так называемые связанные свойства, которые  отражают  событие без изменения свойства компонента. В стандартном шаблоне BeanInfo непосредственно содержатся информационные массивы свойств, событий и методов PropertyDescriptor, EventSetDescriptor, MethodDescriptor), при реализации которых разработчик может обеспечивается предложение  пользователя.

Bean компонент с ограниченным свойством генерирует событие и изменяет значение этого свойства, затем это событие отсылается  объектам, которые могут отклонить  изменение свойств или  поддержать в зависимости от среды выполнения. Инструментарий BDK позволяет  сохранять компоненты  с помощью  пунктов меню (File, Save) в    JAR архиве следующей последовательностью  шагов:

– создать каталог для нового Bean компонента;

– создать одних или несколько исходных JAVA файлов, которые реализуют компонент;

– скомпилировать эти файлы;

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

– сгенерировать JAR файл;

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

– протестовать компонент.

Для взаимодействия разных компонентов используется механизм вызова удаленного метода RMI, который дополнен к языку JAVA через стандартную модель  EJB (Enterprise Java Beans) компании Sun. К ней подключены классы языка JAVA, определения их атрибутов, параметров среды и свойств группирования компонентов  в прикладную программу для выполнения на виртуальной машине JVM. Механизм развертывания JAVA–компонентов типа beans на сервере базируется на  программах в  исходном языке, а сервер  создает  для них оптимальную среду для выполнения задач EJB.



Для реализации и повторного использования ПИК типа beans разработаны  следующие шаблоны  в Java for Forte:

– Bean для  создания нового beans компонент и формирования  каркас компонента с простыми свойствами и возможностью автоматического изменения этих свойств;

– BeanInfo для  интеграции beans компонентов и обеспечения  взаимодействия;

– Customizer создает панель, на которой размещаются элементы, которые со временем можно использовать для управления конфигурацией beans компонента;

– Property Editor создает класс, который используется во время проектирования и редактирования свойств beans компонентов.

Фирма Microsoft Active разработала ряд Beans компонентов, которые формируют интегрированную архитектуру приложения. Контейнеры этих компонентов поддерживаются  Internet Explorer, Microsoft Office и Visual Basic. Кроме того, на  сайте java.sun.com можно загрузить инструментальную систему Bridge for Active в целях применения  Java Beans компонентов в контейнерах Active, а также загрузить инструментарий Java Beans Migration Assistant for Active для анализа элементов управления Active и генерации каркаса JavaBean компонентов.


Конфигурационный аудит


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

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

– функциональный аудит конфигурации для  подтверждения соответствия фактических характеристик конфигурации/единиц продукта предъявляемым требованиям;

– физический аудит конфигурации, как подтверждение взаимного соответствия документации и фактической конфигурации продукта.

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



Конструирование ПО (Software Construction)


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

Область знаний «Конструирование ПО (Software Construction)»  включает следующие разделы:

– снижение сложности  (Reduction in Complexity),

– предупреждение отклонений от стиля  (Anticipation of Diversity),

– структуризация для  проверок (Structuring for Validation),

– использование внешних стандартов (Use of External Standards)

 

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

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

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

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

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

В процессе конструирования должны использоваться  внешние стандарты  ЯП (Ада 95, С++ и др.), языков описания данных (XML, SQL и др.), средств  коммуникации (COM, CORBA  и др.),  интерфейсов компонентов  (POSIX, IDL, APL) [33],  сценариев UML [31] и др.

Управление конструированием

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

Модели конструирования включают набор операций, последовательность действий и результаты. Виды моделей определяются стандартом ЖЦ, методологиями и практиками. Основные стандарты ориентированы на  экстремальное программирование и  RUP [32].

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

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

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

 

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

 


Контрольные вопросы и задания


1. Назовите цели и задачи  программной инженерии.

2. Назовите  признаки  зрелой  профессии.  Какие  из  них присущи программной инженерии.

3.  Назовите области знаний SWEBOK инженерии разработки ПО.

4. Приведите базовые понятия  SWEBOK.

5. Определите цели и задачи области инженерии – управление проектом.

6. Определите цели и задачи области инженерии – управление качеством.

7. Дайте определение жизненного цикла разработки программного обеспечения.

8. Назовите три основные группы процессов жизненного цикла и   перечислите процессы каждой из групп.

9. Назовите  дополнительные процессы ЖЦ и   перечислите их.

10. Дайте характеристику организационных процессов ЖЦ.

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

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

13. Какие разделы ядра знаний и стандарта наиболее необходимы при разработке программных систем.

 


1. Охарактеризуйте  понятие модели ЖЦ и назовите их виды.

2..Дайте характеристику каскадной модели.

3. Определите отличительную особенность спиральной модели ЖЦ.

4. Какие общие черты  имеют инкрементная и эволюционная модели?

5. Дайте перечень процессов ЖЦ стандарта и назовите их назначение.

6. Как построить новую модель ЖЦ на основе стандарта?

7. Дайте классификацию процессов ЖЦ  стандарта.

8. Назовите процессы управления проектом.

9. Назовите процессы управления качеством.

10. Проведите сравнительную оценку модели процессов ЖЦ стандарта 12207 и  областей–процессов ядра знаний SWEBOK.




1. Как   называется  этап  ЖЦ разработки ПО,  на  котором  фиксируется контракт между заказчиком и исполнителем разработки?

2. Назовите   действующих   лиц   процесса   формирования требований.

3. Назовите  источники сведений о требованиях.

4. Какова последовательность шагов по использованию  действующей системы в новой разработке?

5. Назовите категории классификации требований.

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

7. Что определяет онтология концептуального моделирования проблемы?

8. Объясните  суть отношений,  с помощью которых строятся понятия: обобщение, декомпозиция, абстракция, ассоциация.

10. Назовите   элементы   объектно-ориентированного моделирования программных систем.

11. В чем состоит принцип сокрытия информации?

12. Определите   концепция   модели   сценариев   для   сбора требований.

13. Дайте пояснения для  нотации диаграммы сценариев  и   базовых   отношений в них.

14.  Назовите основные типы объекты модели.

15. Приведите задачи трассировки требований.    

16. Расскажите о принципах взаимоотношений между заказчиком и разработчиком требований к системе.




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

2.Сформулируйте задачи  концептуального проектирования моделей ПрО.

3.  Назовите  продукты  анализа  домена  в методе Шлаер и Меллора.

4. Назовите модели метода  Шлаер и Меллора и их суть.

5.Какие еще модели ПрО Вы знаете?

6. Перечислите  ключевые факторы,  влияющие на проектирование  интерфейсов.

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

8. Какие   уровни выделяются  в  архитектуре  системы?

9. Какие  известны   способы   объединения   объектов  в подсистемы?

10. Назовите приемы обеспечения переноса системы в другую среду.




1. Определите цели и задачи метода интеграции в программной инженерии.

2. Назовите системы, которые поддерживают процессы интеграции и преобразования данных.

3. Охарактеризуйте кратко современные системы  взаимосвязи объектов – COM, CORBA, JAVA и др.

4. Назовите методы вызова компонентов в распределенных средах.

5. Какую роль выполняет брокер объектных запросов

6.  Определите проблему преобразования данных в ЯП.

7. Какие требуется провести преобразования передаваемых по сети данных от объекта JAVA  в  к объекту в С++  и обратною

8. Определите проблемы преобразования данных, связанные с заменой одной БД на другую.

9. Какие методы переноса данных  существуют?

10. Определите цели и задачи изменения ПС при проведении сопровождения.

11. Какие выполняются работы при сопровождении, когда вносятся изменения?

12. Дайте краткую характеристику  проблем, возникающих при сопровождении системы.

13. Определите основные задачи реинженерии ПО.

14. Определите основные операции рефакторинга компонентов.

15. Определите основные операции реинженерии программных систем.




1. Назовите формальные методы проверки правильности программ.

2.   Какие процессы проверки зафиксированы в стандарте?

3.   Какие объекты входят в доказательство правильности программ? 

4.   Назовите основные методы доказательства корректности программ и  базис этих методов.

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

6.    В чем состоит отличие техники формального доказательства от символьного  выполнения программ?

7.    Сформулируйте основные задачи верификации и валидации программ.

8.   В чем отличие  верификации и валидации?

9.   Определите процесс тестирования.

10.  Назовите методы тестирования.

11. Объясните значения терминов «черный ящик», «белый ящик».

12.  Назовите объекты тестирования и подходы к их тестированию.

13.  Какая  существует классификация  типов ошибок в программах?

14.  Определите основные этапы ЖЦ тестирования ПО.

15.  Наведите классификацию тестов для проверки ПО.

16. Какие задачи выполняет группа тестировщиков?

17. Какая организация работ проводится для проведения тестирования.




1. Определите понятие – качество ПО.

2. Назовите основные аспекты и уровни модели качества ПО.

3. Определите характеристики качества ПО и  их  назначение.

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

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

6. Какие стандарты в области качества ПО существуют?

7. Назовите основные цели и задачи  системы управления качеством.

8. В чем суть инженерии качества?

9. Назовите содержание классификации моделей надежности.

10. Определите типы моделей надежности и их базис.

11. Какие данные необходимы для оценивания надежности ПО?



Литература


1. Jotterbarn D., Mіller K., Rogerson S.  Software Engіneerіng Code of Ethіes іs Approved / Cоmmunіcatіons of the AСM.– v.42. – №1O. – 1999.– p.1O2 –1O7.

2. www. asm. org / servіng /se / code.hfm

 



Литература к теме


1. Программы следующего десятилетия. Открытые системы.– Декабрь, 2001.–с.60-71.

2. McConnel S., Tripp L. Professional Software Engineering:  Fact or Fiction ? //IEEE Software.-Nov.-Dec.-1999.-P.13-18

3.  Pfleeger S.L. Software Engineering. Theory and practice. – Printice Hall: Upper Saddenle River, New Jersey 07458, 1998. – 576 p.

4. Jacobson I.  Object-Oriented Software Engineering. A use Case Driven Approach, Revised Printing. – New York: Addison-Wesley Publ.Co., – 1994.– 529 p.

5. Иан Соммервил Инженерия программного обеспечения. 6 -издание.–Москва–Санкт–Петербург–Киев, 2002.–623 с.

6. Е.М. Лаврищева Проблематика  программной инженерии// K.: Знання.–1991.–19с.

7. Бабенко Л.П., Лаврищева Е.М. Основы программной  инженерии.  Учебник (укр. язык). – Киев: Знання, 2001. –269 с.

8. Jackson M. Software requirement & specifications.– Wokingham, England: Addison–Wesley, ACM Press Books, 1995. –228 p.

9. Meyer. Object-oriented  Software Construction. – 2nd. ed.,  Prentice Hall, 1997.–531 p.

10.  Jacobson I., Griss M., Jonsson P. Software Reuse.–N.–Y.– Addison–Wesley, 1997. – 497 p.

11. Андон Ф.И., Лаврищева Е.М. Методы инженерии  распределенных  компьютерных систем, Киев, Изд. «Наукова думка», 1997г.–228 с.

12. Андон Ф.И., Коваль Г.И., Коротун Т.М., Суслов В.Ю. Основы инженерии качества программных систем.–К: Академпериодика, 2002.–502 с.

13. Jotterbarn D., Miller K., Rogerson S. Software Engineering CODE of Ethic is Approved//Com. of the ACM .v. 42.–N 10.–1999.–P.

102–107.  

14. ISO/IEC 12207: 1995.– Information technology - Software life cycle processes)  Информационные технологии - Процессы жизненного  цикла программного обеспечения..

15. ISO/IEC TR 15504, Information Technology–Software Process Assessment (Part 1 – 9).

16. ISO/IEC 9126, Information Technology - Software quality characteristics and metrics (Part 1 – 4) 1997.

17.  ISO-IEC 15288, System Life Cycle Processes.

18. ISO/IEC DIS 15026, Information technology – System and Software integrity levels.


1. ISO\IEC 12207: 1995-0801:Informational Technology - Software life cycle processes. // ГОСТ Р ИСО/МЭК 12207- 99 Информационная технология. Процессы жизненного цикла программных средств.

2. Андон Ф.И., Коваль Г.И., Коротун Т.М., Суслов В.Ю. Основы инженерии качества программных систем.–К: Академпериодика, 2002.–502с.

3. Иан Соммервил. Инженерия программного обеспечения. 6 -издание.–Москва–Санкт–Петербург–Киев, 2002.–623с.

4. С.А.Орлов.

Технологии разработки программного обеспечения. Учебник для Вузов. Питер.–2002.–463с.

5. Васютович В., Самотохин С., Никифоров Г. Регламентация жизненного цикла программных средств // iakimov@gost.ru







1. Леонов И.В. Введение в методологию разработки программного обеспечения при помощи Rational Rose.  Требования к системе и способы использования// igorvleonov@esc.ru

2. Вигерс К.И. Разработка требований к ПО.  Москва, 2004.– Русская редакция Microsoft.–575c.

3. Pamela Zave, Michael Jackson,

«Four Dark Corners of Requirements Engineering», ACM Transactions on Software Engineering, January 1997, №1.

4. Jacobson I., Griss M., Jonsson P. Software Reuse. - N.-Y. - Addиson-Wesley, 1997. - 497p.

5.   http:/www.rational.com.uml.html

6. Francisco A. C. Pinheiro, Joseph A. Goguen, «An Object - Oriented tool for Tracing Requirements», «Software», Mach 1996, № 3.







1.  Бабенко Л.П., Лаврищева Е.М. Основы программной инженерии (укр.).– Киев, Знання. –2001.–269с.

2. Грищенко В.Н., Лаврищева Е.М. Методы и средства компонентного пограммирования//Кибернетика и     системный анализ, 2003.– №1.– с.39–55.

3.  Jacobson I., Griss M., Jonsson P. Software Reuse.–N.Y.:Adison Wesley, 1997.

4.  Сrnkovik I, Larsson S., Stafford  J. Component-Based Software Engineering: building systems from  Components at  9th Conference and Workshops on Engineering  of Computer –Based Systems.- Software   Engineering Notes.-2002.- vol.27.-N 3.-c.47-50.

5.  К.Чернецки, У.Айзенекер. Порождающее программирование. Методы, инструменты, применение.–    Издательский дом «Питер».– Москва– Санкт-Петербург… Харьков, Минск.– 2005.–730с.

6.   Meyer B. On to Components. Computer. – vol. 32, N 1, January 1999. – pp.139–140.

7.   Lowy J. COM and .NET Component Services. - O'Reilly, 2001. – 384 p.

8.   Batory D., O'Malley S. The Design and Implementation of Hierarchical Software Systems with Reusable Components/ ACM Transactions  on Software Engineering and Methodology. – N 4, vol. 1, October 1992. –  pp.355–398.

9.  Weide B., Ogden W., Sweden S. Reusable Software Components/ Advances in Computers, vol. 33. – Academic Press, 1991. – pp.1–65.

10. Jacobson I.,  Griss M., Johnson  P.

Software Reuse: Architecture, Process and organization for Business Success – Addison Wesley,  Reading , MA, May 1997.–501p.





1. Open  Software Foundation. Inroduce to Open  Software Foundation. Disributed Computed Environments.– Englewood Cliffs: Prentice Hall, 1993.– 437p.

2.  Corbin J. The art of Distributed  Application. Programming Techn. For Remote Procedure Calls.– Berlin: Springer Verlag, 1992.– 305p.

3. Роджерсон Д. Основы СОМ. Руск..пер.– Microsoft Press.– 361c.

4. CORBA. The Common Object Request Broker: Architecture and Specification. Revision 2.0. Copyright 1991, 1992, 1995 by Sun Microsystems, Inc.–1995.–621 p.

5.  Монсон–Хейфел Р. Enterprise JavaBeans. – СПб: Символ–Плюс, 2002. – 672 с.

6.

Барлет Н., Лесли А., Симкин С. Программирование на JAVA. Путеводитель.– Киев.–1996.– 736с.

7. Иванников В.П., Дышлевый К.В., Мажелей С.Г., Содовская Д.Б., Шебуняев А.Б.Распределенные объектно–ориентированные среды.– Москва // РАН.ИСП. Труды ИСП,.–2000.– с.84–100.

8. Гост 30664 (ИСО/МЭК 11404:1996). Информа­ционные технологии. Языки программирования, их среда и системный интер­фейс. Зависимые от языков типы данных/ Межгосударственный стандарт.–Межгосударственный совет по стандартизации, метрологии и сертификации, 2000. – 112 с.

9.  Джордан Д. Обработка объектных бах данных в С++. Программирование по стандарту ODMG: Пер.с англ. – М.: Издательский дом “Вильямс”, 2001. – 384 с.

10.   Дунаев С. Б. Доступ к базам данных и техника работы в сети. – М.: Диалог–Мифи, 1999. – 416 с.      

11. Эммерих В. Конструирование распределенных объектов. Методы и средства программирования интероперабельных объектов в архитектурах OMG/CORBA, Microsoft COM и Java RMI. – М.: Мир, 2002. – 510с.

12. Лаврищева Е.М., Грищенко В.М. Сборочное программирование .–Киев.– Наукова думка.– 1991. –213с.

13.

Лаврищева Е.М. Парадигма интеграции в программной инженерии// Программирование, 2000.– №1–2 (Труды второй междун.науч..конф. УкПрог–2000, 23–26мая 2000г. –Киев).– с.351–360.

14.  Lanza M., Ducasse  S. Polimetric Views –A lightweight Visual Approach to  Reverse Engineering //IEEET Transaction on  Software Engineering.–   2003.– Sept., №3 (ISSN 0098–5589).– P.782–796.

15. Фаулер М. Рефакторинг: улучшение соответствующего кода. – СПб.: Символ–Плюс, 2003. – 432 с.

16. Пантелеймонов А.А. Аспекты реинженерии приложений с графическим интерфейсом  пользователя//Проблемы программирования .–2001.–№1–2.– С.53–62.

17. Бабенко Л.П., Лаврищева Е.М. Основы программной инженерии  «Знание».–2001. –269с.

18. Соммервилл И. Инженерия программного обеспечения.– Изд. Дом «Вильямс», Москва

19. Игнатенко П.П., Неумоин В.Н., Бистров В.М. Об обеспеченни эффективного реинжинеринга прикладних програмних систем // Пробл. программирования. – 2001. – №1–2. – с. 42–52.

20. Гласс  Г., Нуазо Р. Сопровождение  программного обеспечения. Пер.с анг. // Под ред. Ю.А.Чернышова.– М.:.Мир.– 1983.–256 с.





1.ISO/IEC 9126. Infofmation Technology. – Software Quality Characteristics and metrics. – 1997.

2. ДСТУ 2844–1994. Программные средства ЭВМ. Обеспечение качества. Термины и определения..

3. ДСТУ 2850–1994. Программные средства ЭВМ. Обеспечение качества. Показатели и  методы оценки качества  программного обеспечения.

4. ДСТУ 3230–1995. Управление качества и обеспечение качества. Термины и определения.

5.  Haag S., Raja H.K., Sekade L.L. Quality Function Deployment. Usage in Software Development// Comm. оf ACM.– 1998. –39. –N1.

6.   Кулаков А.Ю. Оценка качества программ ЭВМ .–Киев: Технiка.–1984.–167с.

7.  Липаев В.В. Методы обеспечения качества крупномасштабных  программных систем. – М.: СИНТЕГ.–  2003.–510 с.

8.  Андон Ф.И., Суслов В.Ю.,  Коваль Г.И.,  Коротун Т.М. Основы качества программных систем.–Киев,  Академпериодика.– 2002.–502с.

9.  Липаев В.В.  Надежность  программного обеспечения АСУ.–М.: Сов.радио, 1977.–400с.

10.    Майерс Г.

Надежность  программного обеспечения .– М.: Мир, 1980.–360с.

11.    Гласс  Г.   Руководство по надежному программированию.–М.: Финансы и   

              Статистика, 1982.–256с.

12.    Тейер Т., Липов Р., Нельсон Э. Надежность  программного обеспечения.–М.:     

              Мир, 1981.– 325с.

13.  Барлоу Р., Прошан Ф. Математическая теория надежности. Пер.с анг. М.: 1969.–483с.

14. Meyer B. The role of Object–Oriented Metrics.– Computer, 1998. –№11.–p.23–125.

15.  NASA –STD–2201/ Software Assurance Standart, 1993.

16. ISO 14598. Information  Technology – Software product evolution– Part1: General overview.–1996.

17. Мороз  Г.Б.,  Лаврищева Е.М. Модели роста надежности программного обеспечения.– Киев.–Препринт 92–38, 1992.– 23с.

18.  Коваль Г.И. Подход к прогнозированию надежности ПО при управлении проектом // Проблемы программирования. –2002. – № 1 – 2. – С. 282 – 290.

19. John D. Musa, Anthony Iannino, and Kazuhira Okumoto. Software Reliability: Measurement, Prediction, Application. Whippany, NJ: McGraw–Hill, 1987.




 

1. Майерс Г. Искусство тестирования программ. – Пер.с англ.M: Финансы и статистика. – 1982. – 176 с.

 2. Липаев  В.В. Отладка сложных программ.–М.: Энергоатомиздат,  1993.–296с.

3.  Липаев В.В. Тестирование программ.–М: Радио и связь,–1986.–295с.

 4. Канер С., Фолк Д., Нгуен Е.К. Тестирование программного обеспечения: Пер с англ. – К.: DiaSoft. – 2000. – 544 с.

5.  Weyuker E.J., Ostrand T.J. Theories of program testing and the application of revealing subdomains // IEEE Trans.Soft.Eng. – 1980, –V.6, –№. 3, – P. 236–246.

6.  Software unit test coverage and adequacy. / Zhu H., Hall P. A. // ACM Computing Surveys, 29, –№ 4, Dec. 1997. –P. 336–427.

7.  Коул Дж., Горем Т. и др. Принципы тестирования ПО //Открытые системы. – 1998.– №2.  www.osp.ru/os/1998/02/60.htm

8. Burstall R.M. Program proving as hand simulation with a little induction. – Proc. IFIP Congress 74, North–Holland, 1974. –P.80 – 89.

9. Dijkstra T.W. Finding the Correctness proof of a  concurrent program. – Proc.Konf. Nederland Acad.Wetenach, 1978. – 81. – N2. – p.207– 215.

10. Clint M., Hoare C.A.R. Program proving: jumps and functions. — Acta Informatikee, 1972. — 1. — N3. — P.214—224.

11. Pfleeger  S.L. Software Engineering. Theory and Practice. –  Prentice Hall, 1998. – 576p.

12. Grossman D., McCobe C.

Perfomance Testing a Large Finance Аpplication. – IEEE Software. – 1996. – Sept. – P.50 –60.

13. Y.Wang, J.King, J.Kourt,  M.Ross, S.Staples. On testable odject–oriented programming// Software Engineering Notes, volume 22, N4. –1997.­­– pp.84–90

14.  Perry  D.E. and Kaiser  C.E.

Adequate testing and object–oriented  programming // Journal  of Object–Oriented  Programming,  January /Febrary. –1990. – p.13–19.

15. ANSI / IEEE Std. 10122–1986. Standard for Software  Verification  and  Validation  Plans // IEEE . – New York . – 1986. – 61p.

16. Dolores R. Wallase M. Ippolito, b. Cuthill. Reference  Information  for  the  Software  Verification and Validation  Process // NIST Special  Publication .


1. Reiter D.J. Software managment, IEEE Computer Society Press, Los Alomos.- 1993.

2.  B. Duncan. A Guide to the Project Management Body of Knowledge // PMBOK GUIDE.–2000.– Edition / www.pmi.org/publication/download/2000welcome.html.

3. Боэм Б.У. Инженерное проектирование программного обеспечения.- М:, Радио и связь.-1985.- 511с.

4.  Pfleeger  S.L. Software Engineering. Theory and Practice.- Prentice Hall, 1998.-576p.

5. Андон Ф.И., Суслов В.Ю.,   Коваль  Г.И., Коротун  Т.M.Основы инженерии качества программных систем.– Киев, Академпериодика.–2002.–502с..

6. R.H. Thayer, ed., Software Engineering Project Managment, 2nd.ed., IEEE CS Press, Los Alamitos, Calif. 1997.–391p.

7. Бабенко Л.П., Лаврищева Е.М. Основы програмной  инженерии.  Учебник (укр.язык). – Киев: Знання, 2001. –269 с.

8. ISO/IEC TR 16326:1999. Guide for the application of ISO/IEC 12207 to project management.

9. IEEE Std 1058-1998. IEEE Standard for Software Project Management Plans.

10. Glib T. Principles of software engineering management. – Wokingham, England: Addison-Wesley, 1998. – 396 p.

11. Гультяев А.К. MS PROJECT 2002. Управление проектами. Русская версия; Практическое пособие. – Спб.КОРОНА, 2003. –592 с.

12. Джалота П. Управление программными проектами на практике, Лори, 2005.-

13. Брукс П. Мифический человеко – месяц. – Г.: Мир, 1972. – 234 с.

14. Черников A. Теория и практика управления проектами // Компьютерное обозрение. – 2003.– №10 – С. 24-39.

15. Первое знакомство с Microsoft Office project Professional 2003. – Microsoft, 2003. – 34 c.