Software & Systems

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

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

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

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

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

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

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

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

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

Так, возможные способности критиков можно определить следующим образом:

·   выявление возможностей для улучшения проекта (проектные ошибки, неполные/конфлик тующие описания, возможные изменения и т.п.);

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

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

·  способность работать с частично специфицированными решениями;

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

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

·  приоритизация множества возможных изменений в проекте (осуществляется критической системой на основе информации, получаемой от критиков):

-  высокий приоритет – конфликты и ошибки в проекте;

-  средний приоритет – неполнота описаний, несоответствие эвристическим критериям/хоро шей практике проектирования (guidelines) и т.п.;

-  низкий приоритет – все возможные изменения в проекте – способ запуска визардов независимо от состояния проекта (изменение ранее принятых решений и т.п.).

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

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

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

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

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

Record: информация о разрешении всех обнаруженных критиками проблем/рекомендаций сохраняется в журнале проектных решений.

Модели реализации критической системы

В [1] предлагается графический язык для описания критиков. Пример такого описания показан на рисунке 1: в овалах записываются условия (фаза detect), кружки отмечают точку запуска визарда, в прямоугольниках описываются шаги визарда (фаза advise), в параллелограммах – вносимые в проект изменения (фаза improve).

Можно предложить три варианта языка для описания критиков:

·    API для реализации критиков (например на Java) + дополнительные ограничения на структуру кода и допустимые действия;

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

·    специализированный язык для описания критиков.

Критики в ArgoUML

ArgoUML [3] является некоммерческим проектом с открытыми исходными кодами, направленным на создание универсального инструмента проектирования программных систем с использованием UML. Одной из главных задач при разработке ArgoUML было построение расширяемой базы для исследования новых подходов к организации процесса проектирования, в частности, критических систем.

Далее приведены типы критиков, реализованных в ArgoUML, с соответствующими примерами (один и тот же критик может относиться к нескольким группам).

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

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

Синтаксическая корректность: ассоцииро-ванные классификаторы не могут находиться в разных пространствах имен (namespaces); класс, помеченный стереотипом <>, может содержать только статические атрибуты; класс, помеченный как ‘leaf’, не должен иметь подклас- сов и т.п.

Семантическая корректность: отношение наследования не должно содержать циклов; отношение композиции не может содержать циклов; singleton не имеет статических атрибутов или имеет открытый конструктор и т.п.

Альтернативные варианты реализации: несколько связанных классов могут быть объединены в один; слишком сложный класс может быть декомпозирован; возможно применение шаблона проектирования singleton и т.п.

Визуальное представление: перекрывающиеся объекты на диаграммах; слишком короткие линии-связи и т.п.

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

Кодогенерация: для классов с множественным наследованием не может быть сгенерирован Java код.

Критики в проектировании информационных систем уровня предприятия

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

Предлагаемые далее формальные модели критиков рассматриваются в контексте проектирования архитектуры ИСУП с использованием UML.

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

ET − множество типов элементов, которые могут применяться в проектируемой системе, например: ET = {«server», «os», «javaRuntime», «jAppServer»}. Стереотип server применим к UML-элементам node и nodeInstance, остальные стереотипы применимы к UML-элементам component и componentInstance.

AT − множество ассоциаций, которые могут применяться в проектируемой системе. Например, AT = {deploy}. Ассоциация deploy [4] отражает способность элемента node поддерживать работу соответствующего элемента component, или физическое размещение элемента componentInstance  на элементе nodeInstance. Ассоциация моделируется как бинарное отношение между элементами проектируемой системы.

S= (ME, A) − модель проектируемой системы.

 − множество элементов проектируемой системы ( − тип элемента,  − состояние элемента) отражает множество UML tagged values (именованных значений), связанных с данным элементом; A − множество ассоциаций проектируемой системы, ; W − множество критических реакций (визардов).

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

Динамическая формальная модель критика

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

E – множество событий, изменяющих состояние проектируемой системы. Например, E = {ea1, ea2, er1, er2, em1};

ea1(me) − добавление нового элемента;

ea2(me1, me2) − добавление новой ассоциации;

er1(me) − удаление существующего элемента;

er2(me1, me2) − удаление существующей ассоциации;

em1(me) − изменение существующего элемента.

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

На рисунке 2 изображен подобный автомат для критиков совместимости. Критик находится в состоянии idle, пока не произойдет одно из событий ea2, em1, er2, которые переводят критика в одно из активных состояний active1, active2, active3 соответственно. Далее может оказаться, что произошедшее событие не интересует данного критика (обратный переход в состояние idle) либо появляется необходимость активировать/деактиви ровать критическую реакцию. Условия этих переходов (на рисунке не отражены) используют состояние изменяемых элементов и являются достаточно громоздкими.

Пример критика конкретизации middleware (процессная модель)

В терминах рассмотренной статической модели критиков начальное состояние критика конкретизации middleware можно описать следующим образом:

m0=({me1=(t1=«server»,s1={cpuArch={CPU_ARCHx}}),

       me2=(t2=«os», s2={cpuArch={CPU_ARCHx}, osID={OSy}}),

      me3=(t3=«javaRuntime», s3={cpuArch={CPU_ARCHx},

osID={OSy}, jrID={JRz}}),

      me4=(t4=«jAppServer», s4={cpuArch={CPU_ARCHx},

osID={OSy}, jrID={JRz}, jasID=Ø})},

      {«deploy» = {(me1, me2), (me2, me3), (me3, me4)}}).

Далее будем использовать сокращенную форму: m0=({CPU_ARCHx}, {OSy}, {JRz}, Ø).

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

m0 → m1=({CPU_ARCHx}, {OSy}, {JRz},

   JASxyz = {JASi |,

                                ,

}).

Таким образом, m1 допускает любые JAS которые совместимы с заданными архитектурой, ОС и Java runtime. Далее возможны три варианта: выбор JAS по userCapacity, выбор JAS по benchmarkResult и выбор JAS по userCapacity + benchmarkResult.

m2=(m21 || m22 || m23),

,

,

.

m21=({CPU_ARCHx}, {OSy}, {JRz}, {JASi | ,

}),

m22=({CPU_ARCHx}, {OSy}, {JRz}, {JASi | ,

}),

m23=({CPU_ARCHx}, {OSy}, {JRz}, {JASi | ,

                         ,

}).

Пример критика конкретизации middleware (в терминах алгебры процессов)

В терминах алгебры процессов [5] критика из предыдущего примера можно описать как следующий последовательный процесс:

CrMW = detect → initialSuggestion → (setUserCapacity→

→ constrainByUserCapacity → CrMW |setBenchRes →

→ constrainByBenchRes → CrMW |setCapacityAndRes→

→ constrainByCapacityAndRes→CrMW).

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

αCrMW = {detect, initialSuggestion, constrainByUserCapacity,

setUserCapacity, constrainByBenchRes, setBenchRes,

constrainByCapacityAndRes, setCapacityAndRes}.

Можно описать этот процесс более подробно:

CrMW = detect?m0  → initialSuggestion!m1=f1(m0) →

→(setUserCapacity?x→constrainByUserCapacity!m21=

=f21(m1,x)→CrMW|setBenchRes?y→

→constrainByBenchRes!m22= f22(m1, y) →

→ CrMW| setCapacityAndRes?x,y →

→ constrainByCapacityAndRes!m23=f23(m1, x, y) → CrMW ).

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

·    detect?m0 – в модели обнаружено множество элементов, отвечающих требованиям начального состояния критика – m0 (? означает получение процессом информации);

·    initialSuggestion!m1=f1(m0) – критик предлагает исходное множество решений (! означает вывод (генерацию) информации процессом);

·    setUserCapacity?x – пользователь требует показать лишь решения, обеспечивающие заданное значение userCapacity;

·    setBenchRes?x – пользователь требует показать лишь решения, обеспечивающие заданное значение benchmarkResult;

·    setCapacityAndRes?x,y – пользователь требует показать лишь решения, обеспечивающие заданные значения userCapacity и benchmarkResult;

·    constrainByUserCapacity!m21=f21(m1,x), const- rainByBenchRes!m22=f22(m1,y), constrainByCapacity AndRes!m23=f23(m1, x, y) – критик сужает исходное множество значений в соответствии с требованиями пользователя (здесь обозначения состояний и вычисляющие их функции совпадают с предыдущим примером.

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

CrSystem = detect!m0 → CrSystem

User = initialSuggestion?m1→(setUserCapacity!x → constrainByUserCapacity?m21 → User | setBenchRes!y → constrainByBenchRes?m22 → User | setCapacityAndRes!x,y → constrainByCapacityAndRes?m23 → User ).

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

DesignEnvironment = CrSystem || CrMW || 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