CC BY
32
Среди максимальных элементов для каждого уровня найдем максимальный. Если таких элементов несколько, то выбирается тот, у которого по матрице Т наибольшая сумма неопрошенных циклов. Пусть уровень этого элемента равен j . Тогда на данном цикле РВ запускается К * экземпляров задачи Zj* над источниками данных из множества I *. Переходим к пункту 3.
3. В соответствии с выбранным типом задач пересчитываем матрицу АК. Для матриц W и Т все элементы j строки и столбцов с индексами из множества 1р обнуляются. К остальным элементам матрицы W прибавляются соответствующие элементы матрицы АW, а к остальным элементам матрицы Т прибавляется 1. Переходим к новому циклу РВ (п. 1).
Адаптивный алгоритм динамического построения расписания запуска задач был исследо-
ван на имитационной модели системы. Результаты проведенных исследований показали, что матрица статических весов, задаваемая (11), не является оптимальной в том смысле, что не обеспечивает при работе алгоритма наименьшую вероятность потери данных. На основе выражения (10) был построен алгоритм получения весовой матрицы АW, а на имитационной модели получены более высокие показатели эффективности алгоритма.
Задача построения статического последовательного алгоритма диспетчирования сведена к целочисленной задаче линейного программирования, решение которой позволяет получить параметры алгоритма, обеспечивающие заданную вероятность потери данных. Построен адаптивный динамический алгоритм, который при оптимизации его параметров обеспечивает более высокие показатели эффективности.
ПРОЕКТНЫЕ «КРИТИКИ.» КАК СРЕДСТВО КОГНИТИВНОЙ ПОДДЕРЖКИ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ УРОВНЯ ПРЕДПРИЯТИЯ
М.В. Князев, В.В. Сидельников
Процесс проектирования программно-аппаратных систем можно рассматривать как последовательность принятия проектных решений и описания их в виде формальных спецификаций. Современные средства проектирования поддерживают преимущественно описание принятых решений, обеспечивая редактирование, просмотр, сохранение результатов, обмен результатами проектирования и совместную работу над проектом нескольких разработчиков.
Когнитивная поддержка процесса проектирования дополняет эти возможности, поддерживая принятие решений на всех стадиях проектирования за счет анализа специальной критической подсистемой всех значимых изменений в проекте.
Процесс поддержки принятия решений такой подсистемой может быть определен как состоящий из следующих базовых подпроцессов:
• выявление множества решений, которые могут быть приняты на данной стадии проектирования, то есть в текущем состоянии проекта;
• приоритизация возможных решений в порядке их значимости и осуществимости с учетом взаимозависимостей;
• предложение вариантов реализации выбранного решения, оценка их качества и предоставление всей «известной» системе информации, относящейся к выбранному решению (мастера/ви-зарды).
Подсистемами первого уровня упомянутой выше критической подсистемы могут являться проектные критики.
Согласно определениям, предложенным в [1,2], проектный критик представляет собой интеллектуальный механизм пользовательского интерфейса, интегрированный в инструмент проектирования и анализирующий проект в контексте принятия решений, предоставляя обратную связь относительно возможностей улучшения проекта. Критическая система, помимо собственно критиков, должна содержать механизмы управления применением критиков к проекту и представления/управления порождаемой критиками информации.
Основной целью критиков является информирование проектировщика о появляющихся возможностях, потенциальных проблемах и возможных путях их решения. Для частично специфицированных решений критики используют пессимистические критерии с целью выявления потенциальных проблем. При этом основное внимание уделяется немедленной реакции на действия разработчика, что в свою очередь побуждает его к непрерывной оценке проектных решений с учетом потенциальных проблем и возможностей по улучшению проекта.
Так, возможные способности критиков можно определить следующим образом:
• выявление возможностей для улучшения проекта (проектные ошибки, неполные/конфликтующие описания, возможные изменения и т.п.);
• немедленная реакция на изменения в проекте - разработчик информируется о потенциальных/снятых проблемах непосредственно во время принятия/реализации связанных с ними решений;
• непрерывная обратная связь - информация о состоянии проекта постоянно доступна в сжатой интерактивной форме;
• способность работать с частично специфицированными решениями;
• способность различать хорошие и плохие проектные решения, а не только корректные/некорректные - использование эвристических критериев/рекомендаций;
• поддержка реализации принятых решений и устранения обнаруженных проблем, альтернативные варианты реализации, обеспечение разработчика информацией, полезной при принятии проектных решений (мастера/визарды).
• приоритизация множества возможных изменений в проекте (осуществляется критической системой на основе информации, получаемой от критиков):
- высокий приоритет - конфликты и ошибки в проекте;
- средний приоритет - неполнота описаний, несоответствие эвристическим критериям/хорошей практике проектирования (guidelines) и т.п.;
- низкий приоритет - все возможные изменения в проекте - способ запуска визардов независимо от состояния проекта (изменение ранее принятых решений и т.п.).
В работе [2] предлагается ADAIR модель функционирования критической системы, названная так по первым буквам названий пяти фаз работы системы, которые описаны ниже.
Activate: при обнаружении изменений в проекте активизируется подмножество критиков, относящихся к внесенным изменениям. Алгоритм выявления релевантных внесенным изменениям критиков играет решающую роль в обеспечении своевременности обратной связи и может оказывать существенное влияние на общую производительность системы.
Detect: активизированные критики выявляют появившиеся проблемы и новые возможности по улучшению проекта, а также оценивают актуальность ранее выявленных проблем и рекомендаций.
Advise: все актуальные рекомендации представляются разработчику в соответствии с приоритетами. Форма представления информации может учитывать текущее состояние процесса проектирования. Основной объем взаимодействия разработчика с критической системой сконцентрирован именно в этой фазе.
Improve: оценив разумность той или иной рекомендации, разработчик вносит соответствующие изменения в проект. Изменения могут вноситься как вручную, так и под управлением соответствующего визарда.
Record: информация о разрешении всех обнаруженных критиками проблем/рекомендаций сохраняется в журнале проектных решений.
Модели реализации критической системы
В [1] предлагается графический язык для описания критиков. Пример такого описания показан на рисунке 1: в овалах записываются условия (фаза detect), кружки отмечают точку запуска визарда, в прямоугольниках описываются шаги визарда (фаза advise), в параллелограммах - вносимые в проект изменения (фаза improve).
Можно предложить три варианта языка для описания критиков:
• API для реализации критиков (например на Java) + дополнительные ограничения на структуру кода и допустимые действия;
• преимущественно графическая нотация, подобная показанной выше;
• специализированный язык для описания критиков.
Критики в ArgoUML
ArgoUML [3] является некоммерческим проектом с открытыми исходными кодами, направленным на создание универсального инструмента проектирования программных систем с использованием UML. Одной из главных задач при разработке ArgoUML было построение расширяемой базы для исследования новых подходов к организации процесса проектирования, в частности, критических систем.
Далее приведены типы критиков, реализованных в ArgoUML, с соответствующими примерами (один и тот же критик может относиться к нескольким группам).
Неполнота описания: не заданы имена классов, атрибутов, состояний в автоматах и т.п.; пустые пакеты; не заданы операции или конструктор для класса; класс содержит только статические атрибуты и не помечен стереотипом <<utility>>; не
указан классификатор для экземпляра; интерфейс, не реализованный ни одним из классов; абстрактный класс, не имеющий неабстрактных наследников и др.
Конфликты: совпадение имен различных элементов проекта; имена, совпадающие с зарезервированными словами, и т.п.
Синтаксическая корректность: ассоциированные классификаторы не могут находиться в разных пространствах имен (namespaces); класс, помеченный стереотипом <<utility>>, может содержать только статические атрибуты; класс, помеченный как 'leaf', не должен иметь подклассов и т.п.
Семантическая корректность: отношение наследования не должно содержать циклов; отношение композиции не может содержать циклов; singleton не имеет статических атрибутов или имеет открытый конструктор и т.п.
Альтернативные варианты реализации: несколько связанных классов могут быть объединены в один; слишком сложный класс может быть декомпозирован; возможно применение шаблона проектирования singleton и т.п.
Визуальное представление: перекрывающиеся объекты на диаграммах; слишком короткие линии-связи и т.п.
Стиль: близкие по написанию имена; несоответствие имен классов, атрибутов, операций и прочего общепринятым соглашениям; класс имеет слишком много атрибутов/операций/ассоциаций; а также состояний/переходов в автомате и т.п.
Кодогенерация: для классов с множественным наследованием не может быть сгенерирован Java код.
Критики в проектировании информационных систем уровня предприятия
Перечисленные выше критики направлены на общую поддержку проектирования объектно-ориентированных программных систем с использованием UML. Подобные критики могут оказывать существенную помощь начинающему разработчику, особенно на начальных стадиях проектирования, но они мало что могут предложить опытному проектировщику. Реальный потенциал критических систем может быть раскрыт с помощью специализированных критиков, направленных на поддержку принятия решений в конкретной предметной области, например, проектирование распределенных информационных систем уровня предприятия (ИСУП). Такие решения могут требовать учета множества специфических факторов, известных лишь немногим экспертам в данной предметной области, и обработки значительных объемов информации, которая во многом может быть автоматизирована.
Предлагаемые далее формальные модели критиков рассматриваются в контексте проекти-
рования архитектуры ИСУП с использованием UML.
Статическая формальная модель критика.
Данная модель представляет критика как соответствие между проблематичной конфигурацией (сочетанием) элементов модели и критической реакцией, идентифицирующей и/или устраняющей данную проблему.
ET - множество типов элементов, которые могут применяться в проектируемой системе, например: ET = {«server», «os», «javaRuntime», «jAppServer»}. Стереотип server применим к UML-элементам node и nodelnstance, остальные стереотипы применимы к UML-элементам component и componentlnstance.
AT - множество ассоциаций, которые могут применяться в проектируемой системе. Например, AT = {deploy}. Ассоциация deploy [4] отражает способность элемента node поддерживать работу соответствующего элемента component, или физическое размещение элемента componentlnstance на элементе nodelnstance. Ассоциация моделируется как бинарное отношение между элементами проектируемой системы.
S= (ME, A) - модель проектируемой системы.
ME = {me| = (t| ,s,) | tf e ET,i = 1,n} - множество элементов проектируемой системы ( t i - тип элемента, si - состояние элемента) отражает множество UML tagged values (именованных значений), связанных с данным элементом; A - множество ассоциаций проектируемой системы, A с AT ; W - множество критических реакций (визардов).
Критика можно определить как соответствие между множествами MEn и W - Cr с MEn х W. Отсюда вытекает простейшая классификация критиков - по количеству анализируемых элементов модели. Например, критики совместимости анализируют пару элементов модели связанных ассоциацией deploy.
Динамическая формальная модель критика
Данная модель отражает две важные особенности критиков: активизация критика является реакцией на изменяющие модель проектируемой системы события; в процессе работы критик может взаимодействовать с пользователем системы (архитектором).
E - множество событий, изменяющих состояние проектируемой системы. Например, E = {ea1,
ea2, er1, er2, em1};
eai(me) - добавление нового элемента;
ea2(me1, me2) - добавление новой ассоциации;
er1(me) - удаление существующего элемента;
er2(me1, me2) - удаление существующей ассоциации;
em1(me) - изменение существующего элемента.
Критика можно описать как автомат, реагирующий на изменения в состоянии проектируемой системы (то есть перечисленные выше события) и вырабатывающий некоторую критическую реакцию (например, активизирующий соответствующего визарда) при выявлении проблем в проектируемой системе.
На рисунке 2 изображен подобный автомат для критиков совместимости. Критик находится в состоянии idle, пока не произойдет одно из событий ea2, emi, er2, которые переводят критика в одно из активных состояний activel, active2, active3 соответственно. Далее может оказаться, что произошедшее событие не интересует данного критика (обратный переход в состояние idle) либо появляется необходимость активировать/деактиви-ровать критическую реакцию. Условия этих переходов (на рисунке не отражены) используют состояние изменяемых элементов и являются достаточно громоздкими.
Activate critic response
Deactivate critic response
Рис. 2. Автомат критиков совместимости
Пример критика конкретизации middleware (процессная модель)
В терминах рассмотренной статической модели критиков начальное состояние критика конкретизации middleware можно описать следующим образом:
mo=((mei=(t1=«server»,Si=(cpuArch=(CPÜ_ARCHx}}),
me2=(t2=«os», S2=(cpuArch=(CPÜ_ARCHx}, osID=(OS,}}), me3=(t3=«javaRuntime», s3=(cpuArch=(CPÜ_ARCHx}, osID=(OS,}, jrID=(JRz}}),
me4=(t4=«jAppServer», s4=(cpuArch=(CPÜ_ARCHx}, osID=(OSy}, jrID=(JRz}, jasID=0})},
(«deploy» = ((mei, me2), (me2, me3), (me3, me4)}}). Далее будем использовать сокращенную форму: mc=((CPÜ_ARCHx}, (OSy}, (JRJ, 0).
Следующее состояние можно представить: mo — mi=((CPÜ_ARCHx}, (OS,}, (JRz},
JASxyz = (JASi I (CPÜ_ARCH¡} с supportedCPÜArchsJAS,),
(OS,}сsupportedOSes(JASi) ,
(JRz } с supportedJavaRuntimes(JASi) })•
Таким образом, mi допускает любые JAS которые совместимы с заданными архитектурой, ОС
и Java runtime. Далее возможны три варианта: выбор JAS по userCapacity, выбор JAS по bench-markResult и выбор JAS по userCapacity + bench-markResult.
m2=(m2i ll m22 ll m23),
e1 (userCapacityReq) v
eL (benchmarkResultReq) 1-'m21 '
e3(userCapacityReq,benchmarkResultReq) 1-'m2
m2i=((CPÜ_ARCHx}, (OS,}, (JRz}, (JASi l JASi € JASxyz,
userCapacityReq € userCapacity(JASi) }), m22=((CPÜ_ARCHx}, (OS,}, (JRz}, (JASi l JAS, € JASxyz,
benchmarkResult(JASi) £ benchmarkResultReq }), m23=((CPÜ_ARCHx}, (OS,}, (JRz}, (JAS, l jas, e jASxyz,
userCapacityReq € userCapac^JAS,) > benchmarkResult(JAS,) ^ benchmarkResultReq }).
Пример критика конкретизации middleware (в терминах алгебры процессов)
В терминах алгебры процессов [5] критика из предыдущего примера можно описать как следующий последовательный процесс: CrMW = detect — initialSuggestion — (setÜserCapacit,—
— constrainByÜserCapacity — CrMW lsetBenchRes —
— constrainB,BenchRes — CrMW lsetCapacit,AndRes—
— constrainByCapacityAndRes—CrMW).
Алфавит процесса состоит из всех событий в которых он может участвовать (другими словами, всех событий, которые могут происходить в рамках данного процесса):
aCrMW = (detect, initialSuggestion, constrainByÜserCapacity, setÜserCapacit,, constrainB,BenchRes, setBenchRes, constrainByCapacityAndRes, setCapacit,AndRes}.
Можно описать этот процесс более подробно: CrMW = detect?m0 — initiaISuggestion!m1=f1(m0) — —(setÜserCapacit,?x—constrainByÜserCapacity!m21= =f2i(mi,x)—CrMWlsetBenchRes?,— —constrainB,BenchRes!m22= f22(mi, ,) —
— CrMWl setCapacit,AndRes?x,, —
—>
constrainByCapacityAndRes!m23=f23(m1, x, y) ^ CrMW ).
Используемые в этой записи события предлагается трактовать следующим образом:
• detect?m0 - в модели обнаружено множество элементов, отвечающих требованиям начального состояния критика - то (? означает получение процессом информации);
• initialSuggestion!m1=f1(m0) - критик предлагает исходное множество решений (! означает вывод (генерацию) информации процессом);
• 8еШ8егСарасЩ?х - пользователь требует показать лишь решения, обеспечивающие заданное значение и5етСарасЫу;
• setBenchRes?x - пользователь требует показать лишь решения, обеспечивающие заданное значение benchmaтkResult;
• setCapacityAndRes?x,y - пользователь требует показать лишь решения, обеспечивающие заданные значения useтCapacity и benchmaтkResult;
• constтainByUseтCapacity!m2l=f2l(m1,x), тти тainByBenchRes!m22 =/22(m1,y), constтainByCapacity-
AndRes!m23=f2s(m1, x, y) - критик сужает исходное множество значений в соответствии с требованиями пользователя (здесь обозначения состояний и вычисляющие их функции совпадают с предыдущим примером.
Аналогично можно определить процессы, описывающие поведение критической системы и пользователя. В простейшем случае, когда в системе представлен только описанный выше критик и игнорируются все события, не имеющие к нему непосредственного отношения, эти процессы можно описать следующим образом: CrSystem = detect!m0 ^ CrSystem
User = initialSuggestion?m1^(setUserCapacity!x ^ constrain-ByUserCapacity?m21 ^ User I setBenchRes!y ^ constrainBy-BenchRes?m22 ^ User I setCapacityAndRes!x,y ^ constrain-ByCapacityAndRes?m23 ^ User ).
Тогда поведение всей среды проектирования в целом можно представить как параллельную композицию процессов:
DesignEnvironment = CrSystem II CrMW II User.
В заключение отметим, что критические системы являются мощным средством организации пользовательского интерфейса инструментов проектирования программных систем, обеспечивающим поддержку принятия решений в контексте текущего состояния проекта. Сочетание оперативности обратной связи по всем изменениям в проекте и немодального характера порождаемых кри-
тиками рекомендаций (немодальные диалоговые окна) повышает осведомленность разработчика о состоянии проекта, облегчает доступ к релевантной информации и не ограничивает при этом свободу внесения изменений в проект.
Особенно полезными описанные выше критические системы могут оказаться в проектировании распределенных ИСУП, поскольку такие решения часто требуют учета множества специфических факторов, известных лишь немногим экспертам в данной предметной области, и обработки значительных объемов информации, которая во многом может быть автоматизирована.
Формальное описание критиков позволит использовать соответствующие математические аппараты в процессе построения и реализации критиков и критических систем.
Список литературы
1. Jason E. Robbins. Design Critiquing Systems. http://www.ics.uci.edu/~jrobbins/papers/CritiquingSurvey.pdf
2. Jason E. Robbins. Cognitive Support Features for Software Development Tools, Ph.D. dissertation. http://www.ics.uci.edu/ ~jrobbins/
3. Сайт проекта ArgoUML: http://www.tigris.org/argouml/
4. OMG Unified Modeling Language Specification, Version 1.5. http://www.omg.org/technology/documents/formal/uml.htm
5. Hoare, C. A. R. Communicating Sequential Processes. http://www.usingcsp.com/cspbook.pdf
ВЕРИФИКАЦИОННАЯ ТЕХНОЛОГИЯ БАЗОВЫХ ПРОТОКОЛОВ ДЛЯ РАЗРАБОТКИ И ПРОЕКТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
С.Н. Баранов, П.Д. Дробинцев, А.А. Летичевский, В.П. Котляров
В традиционном подходе качество программного продукта обеспечивается тем, что проверяется соответствие кода спецификации требований и спецификации проекта. Обычно для этого используется матрица отслеживания (traceability matrix), в которой отмечаются все соответствия элементов кода разделам спецификационной документации (рис. 1). Что же в действительности проверяется при таком подходе?
Проверка спецификаций является элементом процесса разработки программного обеспечения (ПО), который дает соответствующую процедуру и порядок ее применения. Однако интерпретация результатов таких проверок - прерогатива разработчика или тестировщика, которые отмечают в матрице отслеживания, что соответствующий пункт спецификации учтен; но то, как именно понят этот пункт, остается невыясненным. Проблему можно решить только через наблюдение за поведением данного приложения в процессе тестирования.
Формализация спецификаций на языках М8С/8БЬ/иМЬ [1-3] позволяет при определенных условиях формально проверить корректность требований и соответствие им кода.
Корректность проверяется путем верификации (то есть доказательства взаимной непротиворечивости требований), соответствие кода специфика-
