Case-технологии - статьи

ЧТО?

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

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

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

• неадекватная спецификация требований;

• неспособность обнаруживать ошибки в проектных решениях;

• низкое качество документации, снижающее эксплуатационные качества;

• затяжной цикл и неудовлетворительные результаты тестирования.

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

Но рано или поздно должны были появиться специализированные программно-технологические средства для разработки проектов, в частности, основанных на информатизации. Ими стали средства, реализующие CASE-технологию создания и сопровождения информационных систем. Термин CASE (Computer-Aided Software Engineering) сегодня понимается достаточно широко. Первоначальное значение термина, ограниченное вопросами автоматизации разработки программного обеспечения (ПО), в настоящее время приобрело новый смысл, и теперь это понятие охватывает процесс разработки сложных информационных систем в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения подобных систем, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом и т. д. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки.

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


• подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;

• широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования;

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

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

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

• CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;

• реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

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


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

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

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

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

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

• использование специальным образом организованного хранилища проектных метаданных (репозитория).

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный жизненный цикл ПО) содержит следующие компоненты:

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


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

• средства разработки приложений, включая языки 4GL и генераторы кодов;

• средства конфигурационного управления;

• средства документирования;

• средства тестирования;

• средства управления проектом;

• средства реинжиниринга.

Все современные CASE-средства можно классифицировать по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы жизненного цикла. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла информационных систем (toolkit) и полностью интегрированные средства, поддерживающие весь жизненный цикл информационных систем и связанные общим репозиторием. Помимо этого CASE-средства можно классифицировать по применяемым методологиям и моделям систем и БД; степени интегрированности с СУБД; доступным платформам.

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает:

• средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

• средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

• средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;


• средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;

• средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Вспомогательные типы включают:

• средства планирования и управления проектом (SE Companion, Microsoft Project и др.);

• средства конфигурационного управления (PVCS (Intersolv));

• средства тестирования (Quality Works (Segue Software));

• средства документирования (SoDA (Rational Software)).

КАК?

Итак, вы решились на внедрение CASE-средств. Процесс внедрения состоит из следующих этапов:

• определение потребностей в CASE-средствах;

• оценка и выбор CASE-средств;

• выполнение пилотного проекта;

• практическое внедрение CASE-средств.
Определение потребностей в CASE-средствах можно проиллюстрировать следующей диаграммой (см. рис. 1).

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

• оценку нескольких CASE-средств и выбор одного или более из них;

• оценку одного или более CASE-средств и сохранение результатов для последующего использования;

• выбор одного или более CASE-средств с использованием результатов предыдущих оценок.
Ниже приведена диаграмма, описывающая наиболее общую ситуацию оценки и выбора, а также показывает зависимость между ними (см. рис. 2).


Как видно из рисунка, входной информацией для процесса оценки является:

• определение пользовательских потребностей;

• цели и ограничения проекта;

• данные о доступных CASE-средствах;

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

Элементы процесса включают:

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


• потребности пользователей, отражающие количественные и качественные требования пользователей к CASE-средствам;

• критерии, определяющие набор параметров, в соответствии с которыми производится оценка и принятие решения о выборе;

• формализованные результаты оценок одного или более средств;

• рекомендуемое решение (обычно либо решение о выборе, либо дальнейшая оценка).

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

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

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

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

• определение дополнительных критериев;

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

• определение одной или более метрик для каждого критерия оценки;

• назначение веса каждому критерию при выборе.

Перед полномасштабным внедрением выбранного CASE-средства в организации выполняется пилотный проект. Его цель — экспериментальная проверка правильности решений, принятых на предыдущих этапах, и подготовка к внедрению.

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


• подтвердить достоверность результатов оценки и выбора;

• определить, действительно ли CASE-средство годится для использования в данной организации, и если да, то определить наиболее подходящую область его применения;

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

• приобрести собственный опыт использования CASE-средства.

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



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

Ну и, наконец, наступает переход к практическому использованию CASE-средств. Он начинается с разработки и последующей реализации плана перехода.

План перехода должен включать следующее:

• Информацию относительно целей, критериев оценки, графика и возможных рисков, связанных с реализацией плана.

• Информацию относительно приобретения, установки и настройки CASE-средств.

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

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

• Определение стандартных процедур использования средств.

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


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

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

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

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

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


• использованное время;

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

• размер, сложность и качество ПО;

• удобство сопровождения.

Еще до начала внедрения CASE-средств метрическая оценка должна начинаться с реальной оценки текущего состояния среды и поддерживать процедуры постоянного накопления данных.

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

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

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

КОГДА?

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

• широкое разнообразие качества и возможностей CASE-средств;

• относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;

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

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

• широкий диапазон предметных областей проектов;

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

Для успешного внедрения CASE-средств организация должна обладать следующими качествами:

• Технология. Понимание ограниченности существующих возможностей и способность принять новую технологию;

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

• Управление. Четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения.

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

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


• достоверная оценка отдачи от инвестиций в CASE-средства затруднительна ввиду отсутствия приемлемых метрик и данных по проектам и процессам разработки ПО;

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

• отсутствие полного соответствия между теми процессами и методами, которые поддерживаются CASE-средствами, и теми, что используются в данной организации, может привести к дополнительным трудностям;

• CASE-средства зачастую трудно использовать в комплексе с другими подобными средствами. Это объясняется как различными парадигмами, поддерживаемыми разнообразными средствами, так и проблемами передачи данных и управления от одного средства к другому;

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

• негативное отношение персонала к внедрению новой CASE-технологии может быть главной причиной провала проекта.

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

Но все же грамотное, продуманное и обоснованное использование CASE-технологии способно принести следующие выгоды:

• высокий уровень технологической поддержки процессов разработки и сопровождения ПО;

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

• приемлемый уровень отдачи от инвестиций в CASE-средства.

Алгоритм реинжиниринга

Если взять за основу общий вид алгоритма реинжиниринга, то он может быть таким:

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

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

Шаг 3. Формулировка общих стратегических целей предприятия и целей бизнесов.

Шаг 4. Разработка для каждого бизнеса средне- и краткосрочных стратегий, которые позволят достичь поставленных целей.

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

Шаг 6. Формирование бюджетов для каждого бизнеса, свод общего бюджета, коррекция запланированных мероприятий. Выстраивается оперативный план действий.

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

Впрочем, рассмотрим, почему же так происходит.

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

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


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

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

Что касается непосредственной автоматизации бизнес-процессов, как раз здесь и нужен «хозяин», — именно он и станет переводить запросы руководителей отделов на язык постановки задач программирования. Однако это подразумевает, что реинжиниринг будет выполнен до назначения «хозяина».

Предмет реинжиниринга

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

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

Несмотря на сложность терминологии, и о бизнес-процессах, и об их реинжиниринге (Business Process Reengineering — BRP) слышали многие. Кому-то казалось, что BRP – панацея практически от всех организационных неурядиц, кто-то считал его хорошо забытым старым, вновь возникнувшим из небытия, а кто-то наоборот – видел в нем не более чем новомодное веяние.

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

Плохо то, что впечатление об организации зачастую складывается разрозненное и статичное, и уж никак не способствует составлению адекватной картины того, как же на самом деле функционирует бизнес. Так, департамент очень просто назвать «бухгалтерия» или «отдел продаж», но определить границы их действий часто достаточно затруднительно. Майкл Хаммер (Michael Hammer), крупнейший американский специалист в области управления, изобретатель понятия «реинжиниринг бизнес-процессов», рекомендовал называть процессы, используя границы «от» и «до», как, например, «от размещения рекламы и до продажи товара». Именно данными мелочами и характеризуются бизнес-процессы, ведь они создаются с использованием множества связей между подразделениями, которые передают друг другу некоторое ключевое задание. Таким образом, постепенно, проходя всю цепочку взаимоотношений, запрос превращается в результат – товар или услугу. При этом вовсе не обязательно, чтобы клиентом выступал непосредственно потребитель — им может быть и другой процесс. Например, если взять конкретный процесс «от получения денег в бухгалтерии до выплаты заработной платы», потребителями будут сотрудники организации, в свою очередь, также являющиеся частью процессов предприятия.


Существует три идеи:

1. Реинжиниринг помогает организовать бизнес кардинально по-новому и наиболее оптимально.

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

3. Бизнес-процесс превосходно поддается автоматизации и позволяет достичь максимальной эффективности в новом качестве.

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

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

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

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

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

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

Программы на службе моделирования

Исторически большинство консалтинговых фирм основывали свои подходы к реинжинирингу, исходя из CASE-технологии разработки информационных систем. Тут можно упомянуть такие известные компании, как Gemini Consulting с методологией Construct и Andersen Consulting с ее Eagle. Методологии обеих компаний ориентированы на IТ-профессионалов и направлены на разработку поддерживающих информационных систем.

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

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

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

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


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

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

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

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

При введении процессного управления параллельные внедрения систем автоматизации становятся не просто данью моде, но жизненно необходимой составной частью. Лидерами рынка программных средств для моделирования и интеграции деятельности предприятия являются ARIS ToolSet компании IDS Scheer AG и Ataffware одноименной компании, которые являются также и законодателями мод в этой области.

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


Сегодня конкурентоспособность компании в значительной степени зависит от возможности преобразования основных процессов предприятия в поддержку стратегических инициатив, способных удовлетворить требования заказчика. Более того, не так давно в обиход вошел термин «экс-инжиниринг». Его суть заключается в расширенной перестройке бизнес-процессов, выходящей за корпоративные рамки. Несмотря на то что большинство компаний чаще всего не успевает завершить реинжиниринг бизнес-процессов, следующим способом улучшения их работы выбирается всеобъемлющая перестройка процессов. К тому же под влиянием Интернета все чаще возникает идея виртуальных, не имеющих границ компаний, и это тоже подразумевает некий уровень готовности, к которому можно прийти при помощи экс-инжиниринга. Определенное преимущество имеют компании, сумевшие изначально заложить необходимые принципы в свою работу. Примеры Dell и Cisco Systems представляют собой концентрацию удачного экс-инжиниринга. Эти компании с самого начала основывались на принципах прозрачности, гармонизации и стандартизации – тех принципах, на которые необходимо ориентироваться всем современным предприятиям, желающим достичь успеха в бизнесе.

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

от руководителя до уборщика. Реинжиниринг

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

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

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

Все это приводит к мысли, что реинжиниринг нужно использовать исключительно тогда, когда необходимо существенно и быстро улучшить показатели работы. Ради 5%-ных улучшений показателей нужды форсировать события с использованием BRP нет. Даже наоборот – в большинстве таких случаев он принесет только вред предприятию.

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

Реинжиниринг и совершенствование: кто кого?

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

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

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

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

Суть непрерывного совершенствования (Continuous Improvement — CI) — понятия, впервые возникшего в социальной психологии, заключается в долгосрочном развитии организации через развитие ее составляющих.

Реинжиниринг: многое в малом

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

Автоматизированное создание документов

Галахов И.В., Лапыгин Д.В., Новичков А.Н., Подоляк О.Р., Позин Б.А.

,

Доклад и статья опубликованы в рамках III-ей Всероссийской практической конференции: "Стандарты в проектах современных информационных систем"

,
Предисловие
В статье представлена технология автоматизированного создания документов серии ГОСТ 34 и 19 с помощью инструментальных средств фирмы IBM Rational, разработанная на основе опыта, полученного в ходе реализации ряда проектов при проведении сравнительного анализа состава и содержания артефактов Rational Unified Process (RUP) и требований к оформлению документов по ГОСТ 34 и 19.
Рассмотрены краткие сведения об используемых инструментальных средствах IBM Rational.
На конференции по стандартам данный доклад вызвал практический интерес аудитории, что и побудило авторов к его размещению в Интернете. Планируется публикация продолжения данной статьи. Если Вас заинтересовал данный материал, то можете присылать вопросы по адресу
По этому же адресу () можно запросить презентацию доклада на русском языке в формате PowerPoint и подписаться на рассылку новостей по продуктам и технологиям IBM Rational.

Введение

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

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

Регламентация проектной деятельности основывается на стандартах и методологиях, среди которых в настоящее время наиболее популярны как стандарты ГОСТ 34-й и 19-й серий, определяющие требования к разрабатываемой документации, так и новые стандарты ГОСТ Р ИСО/МЭК 12207-99 и ГОСТ Р ИСО/МЭК 14764-2002, определяющие процессы жизненного цикла программных средств. Одной из наиболее развитых и популярных методологий, описывающих процессы ЖЦ ПС, является Rational Unified Process (RUP), разработанный компанией Rational Software и соответствующий ГОСТ Р ИСО/МЭК 12207-99. При этом необходимо отметить, что RUP ориентирован прежде всего на разработку ПС и без предварительной адаптации не может использоваться для задач процесса сопровождения.

Сейчас складывается ситуация, когда многие коллективы, разрабатывающие программные средства, переходят на использование технологий, основанных на методологии RUP. В то же время, большинство Заказчиков, как внешних, так и внутренних, продолжают использовать стандарты серии ГОСТ 19 и 34 как основные при приемке программных средств от разработчика. Таким образом, возникает необходимость поддерживать двойную технологию, ориентируясь при разработке на методологию RUP, а при сдаче результатов – на стандарты ГОСТ 19 и 34. Такая ситуация может просуществовать достаточно долго и требует решения, позволяющего максимально снизить затраты по использованию такой двойной технологии.

Далее в статье представлены результаты обобщения опыта нескольких проектов, сведенные в единую технологию, позволяющую автоматизировать процесс формирования документов серии ГОСТ 19 и 34 на основании данных и артефактов, создаваемых в ходе разработки ПС по технологии, основанной на Rational Unified Process.



Адаптация RUP



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


Реализация методологии RUP в виде набора взаимосвязанных компонентов (см. рисунок 1), таких как “стадия”, “процесс”, “работа”, “задача”, “роль”, “артефакт”, позволяет применять типовой подход при его адаптации, учитывая при этом требования, как международных стандартов, так и стандартов серии ГОСТ 19 и 34. Представленный в статье опыт адаптации стандартов к потребностям организации (предприятия) обобщен и доведен до уровня типовой технологии, которая может быть использована при реализации аналогичных проектов.



Рисунок 1 -



Далее рассматривается только вариант адаптации RUP, выполняемый с целью формирования в ходе проекта документации, соответствующей требованиям ГОСТ 19 и 34. Адаптация проводится в основном за счет уточнения состава работ, задач, ролей и, прежде всего, артефактов и взаимосвязей между ними. В отдельных случаях может изменяться состав стадий и процессов, но такие случаи в данной статье не рассматриваются.



Артефакты RUP и документы ГОСТ



Пусть имеется один или несколько проектов разработки или сопровождения программных средств, в которых используется технология работ, основанная на RUP, а документация на программные средства должна соответствовать требованиям ГОСТ 19 или 34.

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

Для решения задачи было проведено сопоставление артефактов RUP и документации, разрабатываемой по требованиям ГОСТ 19 и 34. При сопоставлении артефактов учитывались стадии ЖЦ ПС, на которых они разрабатываются. Сопоставление стадий RUP и ГОСТ 34 приведено в таблице 1.



Таблица 1 - Сравнительный анализ стадий RUP и ГОСТ

Стадии RUP	Стадии ГОСТ 34.601-90
Обследование (Inception)	Формирование требований Разработка концепции Техническое задание
Технический проект (Elaboration)	Эскизный проект Технический проект
Рабочий проект (Construction)	Рабочая документация
Передача в эксплуатацию (Transition)	Ввод в действие Сопровождение

<


С учетом установленного соответствия стадий, для каждой стадии были выделены группы артефактов RUP, на основании которых могут автоматически генерироваться документы ГОСТ19 и 34. Необходимо отметить, что понятие “артефакт” включает не только документы, но и другие проектные материалы, создаваемые в ходе выполнения проекта. Например, модели, исходные коды, тестовые скрипты и т.п.

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

Для установления четкого однозначного соответствия между артефактами RUP и документами ГОСТ необходимо “опуститься” на уровень отдельных разделов документов и компонентов артефактов. Понятие “компонент” используется для артефакта вместо понятия “раздел” по той причине, что, как было показано ранее, не все артефакты являются документами и говорить о “разделе” применительно к модели нельзя. Поэтому в каждом артефакте выделяются компоненты, а в документах используются разделы, соответствующие требованиям ГОСТ (см. рисунок 2).



Рисунок 2 -



В сравнении участвуют только те артефакты RUP, которые создаются в ходе для конкретного проекта (их перечень определяется при планировании), и действует правило сопоставления по стадиям – документы ГОСТ 19 и 34 или их разделы, формирующиеся на определенной стадии, сопоставляются с артефактами RUP, которые создаются на той же стадии. В качестве примера можно привести перечень основных документов по ГОСТ 19, обычно используемых в проектах и наиболее часто используемых артефактов RUP (см. таблицу 2).



Таблица 2 - Основные документы ГОСТ 19 и артефакты RUP

Стадия	Артефакт RUP	Документы ГОСТ 19
Техническое задание	Концепция системы Описание процесса разработки продукта План разработки продукта	Техническое задание 19.201-78
Эскизный проект	Архитектура системы Руководство по программированию Руководство по проектированию Дополнительные технические требования План тестирования План обеспечения качества План разработки продукта	Пояснительная записка 19.404-79

<


В результате на этом шаге мы имеем для каждого формируемого документа ГОСТ 19 и 34 набор компонентов артефактов, на основании которого можно формировать документ.



Адаптация структуры и содержания артефактов RUP



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

Примером практически полного соответствия разделов могут служить требования ГОСТ 19.301-79 “программа и методика испытаний”, которые совпадают с требованиями к разделу артефакта RUP “план тестирования” (см. таблицу 3).



Таблица 3 - Соответствие требований ГОСТ 19.301-79 и артефакта RUP “План тестирования”

Требования ГОСТ 19.301-79	Требования RUP
…должны быть приведены описания используемых методов испытаний. Методы испытаний рекомендуется по отдельным показателям располагать в последовательности, в которой эти показатели расположены в разделах “Требования к программе” и “Требования к программной документации”	…в этом разделе описывается, как будут протестированы объекты тестирования. Каждый тип тестирования сопровождается описанием и объяснением, почему он реализуется и выполняется. Стратегия тестирования рассматривает, какие методы нужно использовать и критерий завершенности тестирования…

Все же в большинстве случаев невозможно установить однозначное соответствие между компонентами артефактов и разделами документов ГОСТ 19 и 34 без дополнительной адаптации структуры и содержания артефактов RUP. В отношении документов ГОСТ 19 и 34 мы исходим из предположения, что их структура и содержание согласовано с Заказчиком и дальнейшего уточнения не требует. Остается только “подогнать” артефакты RUP под структуру и содержание документов ГОСТ 19 и 34 путем дополнительной адаптации.


На этом шаге необходимо решить следующие задачи (см. рисунок 3):

Выделить внешнюю информацию, которую требуется передавать Заказчику в виде документов ГОСТ 19 и 34;

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

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

Рисунок 3 -



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



Автоматизированное создание документов ГОСТ



После установления соответствия между документами ГОСТ 19 и 34 и артефактами RUP на уровне разделов и компонентов является разработка специальных шаблонов для настройки автоматизированной отчетности с помощью инструментального средства Rational SoDA.

Rational SoDA имеет возможности выборки данных из различных артефактов, созданных на основе инструментальных средств Rational, – моделей данных и классов (Rational Rose), версионного хранилища (Rational ClearCase), репозитория требований (Rational RequisitePro), репозитория запросов на изменения (Rational ClearQuest), репозитория тестирования (Rational Test Manager).

Документация генерируется по заранее определенным шаблонам на основе артефактов, создаваемых в процессе выполнения работ ЖЦ ПС. Генератор отчетов Rational SoDA имеет ряд встроенных отчетов, ориентированных на работу по методологии RUP. Для генерации документов другого типа требуется разработать новые шаблоны, что и было сделано при формировании документов серии ГОСТ 19 и 34.



Преимущества представленной технологии



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

Адаптированные шаблоны артефактов RUP с разделением внутренней и внешней информации на уровне компонент артефактов;

Перечень компонент артефактов RUP, на основании которых формируются разделы документов серии ГОСТ 19 и 34;

Шаблоны Rational SoDA, разработанные для автоматизированного формирования документов серии ГОСТ 19 и 34 на основании компонент артефактов RUP;

Использование инструментальных средств Rational при выполнении работ ЖЦ ПС.

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

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

Применение такой технологии сокращает до минимума количество ручных операций при создании документации;

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

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

Сведения об авторах:

Все авторы работают в дирекции по консалтингу и методологии создания программного обеспечения информационных систем компании ООО ИК СИБИНТЕК в г. Москва.

Позин Борис Аронович– директор дирекции,

Галахов Илья Владимирович– начальник управления,

Лапыгин Дмитрий Владимирович – главный специалист,

Новичков Александр Николаевич – ведущий специалист,

Подоляк Ольга Робертовна – старший специалист.

Использование языка макрокоманд в AllFusion ERwin Data Modeler

,
технический специалист компании Interface Ltd.
На современном этапе редко какое предприятие имеет единую информационную структуру. Как правило, информационный отдел организации имеет мозаичную структуру, где каждый элемент мозаики является решением отдельной задачи или подразделения и реализован в соответствии с параметрами этой задачи. Такая мозаика во многом определяется историческим развитием организации. К примеру, на гипотетическом предприятии первоначально был автоматизирован бухгалтерский учет при помощи собственной разработки, далее была внедрена сторонняя программа по учету заработной платы и т.д. Не секрет что такая участь была уготована и системам управления баз данных - от настольных баз MS Access до высокопроизводительных баз данных Oracle. В итоге практически перед любой организацией стоит задача унификации процесса создания баз данных с использованием различных СУБД, документирования и сопровождения уже существующих наработок. Именно таким инструментом является AllFusion ERwin Data Modeler (ранее: ERwin). Данный программный продукт выпускается американской компанией Computer Associates. ERwin DM поддерживает более 20 типов СУБД, как настольных, так и реляционных. Среди функциональных возможностей ERwin DM можно выделить следующие:

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

прямое генерирование (Forward engineer). Это функция создания системных объектов выбранного сервера базы данных на основе созданной в ERwin DM схемы данных.

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

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

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

встроенный API (ERwin API)

поддержка XML

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

использования построителя отчетов для извлечения данных по модели

использование языка макрокоманд.

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

Любая СУБД подразумевает поддержку определенной модели данных, которая определяет структуру данных, и правила, по которым эта структура создается. На данный момент наиболее используемой моделью данных является реляционная модель. Первая практическая реализация реляционной модели была предпринята компанией IBM в семидесятые годы (1973-1978) прошлого столетия в продукте System R. Эта система была основой для всех последовавших за ней коммерческих продуктов, реализующих реляционный подход. В данном продукте был предложен язык манипулирования данными, который носил название SEQUEL (structured English query language), в дальнейшем получивший название SQL. В коммерческих продуктах язык SQL дополнялся, и в итоге появилось большое количество диалектов, не совместимых между собой. В 1987 году американским комитетом стандартизации был предложен первый стандарт языка SQL, в 1992 году был создан стандарт SQL-92, дополняющий SQL-87, в 1999 году предложена его третья версия, главным дополнением которой были объектные возможности и хранимые процедуры. Несмотря на процесс стандартизации, версии языка SQL очень сильно различаются от производителя к производителю. Язык макрокоманд ERwin DM позволяет расширить стандартный синтаксис языка SQL до диалектов конкретных баз данных. Однако это не единственная возможность использования макрокоманд в ERwin DM. Макрокоманды могут быть использованы:

в доменах

в настройках правил именования объектов схемы

для создания триггеров и хранимых отображений

для создания шаблонов скриптов.

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



Рис. 1. Использование макрокоманд в определении доменов

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

%Lower - макрокоманда, понижающая регистр
%OwnerEntity - макрокоманда, возвращающая имя сущности, к которой принадлежит атрибут
%AttDomain - макрокоманда, возвращающая имя домена, к которому принадлежит атрибут

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




Рис. 2. Пример использования макрокоманд в редакторе именования объектов модели.

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

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

Язык макрокоманд состоит из 195 команд.

В ERwin DM включена специальная панель инструментов - Macro Toolbox для работы с макрокомандами. С помощью данной панели можно выбрать нужную макрокоманду из списка, просмотреть синтаксис выбранной макрокоманды и получить справку по ее использованию.



Рис. 3. Панель инструментов Marco Toolbox.

Рассмотрим синтаксис одной из макрокоманд ERwin DM.

%ForEachColumn(,,) { }

Фраза %ForEachColumn является названием макрокоманды. Все фразы, заключенные в кавычки (<>), являются переменными макрокоманды, скобки и запятые указывают на необходимый синтаксис.

%ForEachColumn(cust,","){%ColName} - в результате действия этой макрокоманды будет выведен список столбцов таблицы cust.

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

Тип действия	Макрокоманда
определение переменных	%ChildFKDecl %ChildNKDec l%ChildParamDecl %ChildPKDecl %Decl %NKDecl %ParamDecl %ParentNKDecl %ParentParamDecl %ParentPKDecl %PKDecl
выполнение арифметических операций	%- %* %/ %+
использование операций сравнения и логических операций	%!= %< %<= %= = %> %>= %And %Not %Or
ветвление	%If %Else %Switch
организация циклов	%ForEachAtt %ForEachAttribute %ForEachChildRel %ForEachColumn %ForEachDefault %ForEachDomain %ForEachEntity %ForEachFKAtt %ForEachFKAttribute %ForEachFKColumn %ForEachIndex %ForEachIndexMem %ForEachKey %ForEachKeyMem %ForEachLogEntity %ForEachParentRel %ForEachTable %ForEachValidation %ForEachValidValue %ForEachView %ForEachViewColumn
работа с внешними файлами	%File %Include %Lookup

<


Перейдем к использованию макрокоманд в триггерах. Как известно, одной из задач, стоящих перед современными СУБД, стоит задача поддержания логической целостности данных. Реляционные базы состоят из таблиц, связанных между собой при помощи механизма ключей. Для поддержания целостности между двумя таблицами используется триггер ссылочной целостности (RI триггер). В общем случае текст триггера зависит от типа связи таблицы, с которой он связан (триггер для родительской таблицы, триггер для дочерней таблицы) и от действия, при котором он срабатывает (добавление, изменение, удаление записи в таблице). В ERwin DM используется набор шаблонов для реализации триггеров ссылочной целостности. Тексты шаблонов зависят от типа сервера базы данных. Шаблоны представляют собой специальные скрипты, в которых используются макрокоманды ERwin DM. При генерации триггеров вместо макрокоманд подставляются имена таблиц, колонок, переменных и других фрагментов кода, соответствующих синтаксису выбранной макрокоманды. Для каждой комбинации ссылочной целостности (к примеру, Parent-Delete Cascade) в ERwin DM существует предопределенный шаблон, однако у пользователя имеется возможность переопределить этот шаблон, причем сделать это можно на трех уровнях: на уровне всей схемы, на уровне отдельной таблицы и на уровне отдельной связи. В дальнейшем на этапе генерации кода DDL будет использоваться шаблон, переопределенный пользователем.

Рассмотрим, каким образом используются макрокоманды в шаблонах триггеров ссылочной целостности. В схеме данных существуют две таблицы: отдел и сотрудник, между ними существует неидентифицирующая связь между полями отдел.ид_отд и сотрудник.ид_отд. В правилах ссылочной целостности этой связи была выбрана опция Parent-Delete RESTRICT, в результате которой запрещается удалять строку в таблице отдел, если существуют записи, ссылающиеся на эту строку из таблицы сотрудник.

Шаблон на данный триггер выглядит следующим образом:

/* ERwin Builtin %Datetime */
/* %Parent %VerbPhrase %Child ON PARENT DELETE RESTRICT */
select count(*) into numrows
from %Child
where
/* %%JoinFKPK(%Child,:%%Old," = "," and") */
%JoinFKPK(%Child,:%Old," = "," and");
if (numrows > 0)
then
raise_application_error(
-20001,
'Cannot DELETE %Parent because %Child exists.'
);
end if;


При генерации будет создан следующий триггер

create trigger tD_Отдел after DELETE on Отдел for each row
-- ERwin Builtin Wed Oct 15 17:06:44 2003
-- DELETE trigger on Отдел
declare numrows INTEGER;
begin
/* ERwin Builtin Wed Oct 15 17:06:44 2003 */
/* Отдел R/2 Сотрудник ON PARENT DELETE RESTRICT */
select count(*) into numrows
from Сотрудник
where
Сотрудник.ид_отд = :old.ид_отд;
if (numrows > 0)
then
raise_application_error(
-20001,
'Cannot DELETE Отдел because Сотрудник exists.'
);
end if;
end;

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

create trigger %TriggerName
%Fire %Actions(" or ")
on %TableName
%RefClause
%Scope
/* ERwin Builtin %Datetime */
/* default body for %TriggerName */
begin
Insert into Security (OldName, NewName, UserUpdate, UpdateDate)
values (:old1.CustomerName, :new1.CustomerName, User, Sysdate);
end;
/

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

create trigger SecurWrite
BEFORE UPDATE OF
CustomerName
on CUSTOMER
REFERENCING OLD AS old1 NEW AS new1
for each row
/* ERwin Builtin %Datetime */
/* default body for %TriggerName */
begin
Insert into Security (OldName, NewName, UserUpdate, UpdateDate)
values (:old1.CustomerName, ;new1.CustomerName, User, Sysdate);
end;
/

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


Создание хранимых процедур при помощи языка макрокоманд не отличается от создания триггеров.

Как уже было сказано выше, язык макрокоманд ERwin DM также может быть использован для создания пре- и пост-скриптов. В ERwin DM есть возможность создания шаблонов скриптов, которые могут быть использованы на этапе прямого генерирования. Могут быть скрипты уровня всей схемы и уровня таблицы. По времени генерации скрипты могут делиться на прескрипты и постскрипты. Генерация кода прескрипта происходит перед генерацией основного объекта, с которым этот скрипт связан, и соответственно генерация кода постскрипта осуществляется после генерации объекта. Проиллюстрируем использование макрокоманд на примере создания прескрипта уровня всей схемы и постскрипта уровня таблицы.

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

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

%ForEachTable() {
If Exists (select * from sysobjects where name = '%TableName') Drop table %TableName
%DMBSDelim
}

примечание - скрипт написан для СУБД MS SQL Server 2000

Этот скрипт легко можно преобразовать до скрипта уровня таблицы, удалив макрокоманду %ForEachTable(), в этом случае скрипт будет выглядеть следующим образом

If Exists (select * from sysobjects where name = '%TableName') Drop table %TableName
%DMBSDelim

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

grant select on %TableName to %TableProp(GrantSelect)
%DBMSDelim

В ERwin DM существует механизм свойств, определенных пользователем (UDP - user defined property), которые позволяют существенно расширить функциональность продукта. В приведенном выше примере используется UDP под названием GrantSelect, в котором перечислены все пользователи базы данных. На этапе моделирования каждой таблице присваивается данный UDP и в нем указываются пользователи, которые будут иметь привилегию на выборку из таблицы. На этапе генерации кода SQL выбранным пользователям будет предоставлена привилегия на выбор из соответствующих таблиц.

AllFusion ERwin Data Modeler является мощным средством, позволяющим создавать, документировать и сопровождать базы данных. Язык макрокоманд, включенный в состав данного продукта, позволяет генерировать SQL-код, приближенный к коду диалектов SQL конкретных производителей СУБД.

Декомпозиция

Выделение классов и объектов – одна из самых сложных задач объектно-ориентированного проектирования , которая осуществляется в процессе декомпозиции ключевых абстракций программной системы.
Декомпозиция занимает центральное место в объектно-ориентированном анализе и проектировании программного обеспечения. Под объектно-ориентированной декомпозицией понимается процесс разбиения системы на части, соответствующие объектам предметной области. Практическое применение объектно-ориентированного проектирования приводит к объектно-ориентированной декомпозиции, при которой мы рассматриваем мир, как совокупность объектов, согласованно действующих для обеспечения требуемого поведения.
Г. Буч в своей книге задает непростой вопрос : существует ли наилучший метод проектирования? На этот вопрос однозначного ответа нет. По сути дела этот вопрос сводится к другому вопросу: существует ли лучший способ декомпозиции сложной системы? Если он и существует, то пока никому не известен. Также этот вопрос можно поставить и по-другому: как наилучшим способом разделить сложную систему на подсистемы? Правильное разделение системы на составные части, представление предметной области в виде набора объектов, или разбиение программы на модули является почти такой же сложной задачей, как выбор правильного набора абстракций.
Г. Буч в своей книге приводит правило Клеменса и Вейса, которым активно пользуются разработчики программного обеспечения при выделении модулей программ: «Особенности системы, подверженные изменениям, следует скрывать в отдельных модулях; в качестве межмодульных можно использовать только те элементы, вероятность изменения которых мала». Также необходимо отметить, что поскольку модули служат элементарными и неделимыми блоками программы, которые могут использоваться повторно, это должно учитываться при распределении классов и объектов по модулям.
С проблемой декомпозиции исследователи ранее сталкивались при проектировании и анализе сложных административных, хозяйственных, производственных систем. В этих процессах очень часто «... непосредственное изучение объекта в целом как системы невозможно из-за его сложности. В этих случаях приходится расчленять объект на конечное число частей, учитывая связи между ними, характеризующие их взаимодействие. Здесь и начинается интерпретация исследуемого объекта как сложной системы, а его частей – как подсистем.
Если некоторые подсистемы оказываются все еще чрезмерно сложными, каждая из них разделяется (с сохранением связей) на конечное число более мелких подсистем. Процедура разделения подсистем продолжается до получения таких подсистем, которые в условиях данной задачи будут признаны достаточно простыми и удобными для непосредственного изучения. Эти подсистемы, не подлежащие дальнейшему расчленению, назовем элементами сложной системы.
Таким образом, в общем случае сложная система представляется как многоуровневая конструкция из взаимодействующих элементов, объединяемых в подсистемы различных уровней. Разделение системы на элементы в общем случае может быть выполнено неоднозначным образом и является в высшей степени условным.»
Естественно возникает вопрос о правилах разделения сложных систем или декомпозиции в случае разработки объектно-ориентированной модели для задач, поставленных для заданной предметной области.

Эмергентность свойств систем

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

Материальные и знаковые системы. Программные системы как разновидность знаковых

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

Обобщенное правило декомпозиции

Зададим в общем виде функционал эффективности системы в виде следующего выражения: А = F(a1,…,an), где А – показатель, отражающий качество реализации основного назначения системы (например, некоего системного качества или эмергентного свойства), a1,…,an – параметры, от которых зависит данное системное качество (они также могут быть функционально зависимыми от других параметров).
В качестве пояснения назначения функционала рассмотрим задачу увеличения высоты полета самолета. Пусть А – высота полета самолета. Первый вопрос, на который должен ответить человек, решающий данную задачу – от чего зависит высота полета? Для простоты рассмотрим два составляющих элемента самолета: двигатель, крылья, и, кроме того, саму систему – самолет. Выделим свойства, оказывающие влияние на заданное системное свойство, например, в двигателе – мощность (пусть это а), в крыльях – площадь (с), а в самолете его вес (b).
Значит, для увеличения системного качества А нужно рассмотреть возможности синтеза такой структуры рассмотренных элементов при которой значения показателей а, b, с приведут к требуемому результату. Это очевидный пример синтеза через анализ.
Конечно же, для увеличения высоты полета самолета необходимо рассматривать более сложный комплекс показателей. И более того, нельзя забывать о возможной функциональной зависимости данных параметров и о влиянии других (неучтенных) параметров. Вполне может оказаться так, что один из неучтенных параметров оказывает большее влияние на анализируемое системное качество А.
Таким образом, в общем виде правило декомпозиции заключается в выполнении следующих основных этапов:

Определение системных(ого) свойств(а), значимых (ого) для решения поставленной задачи. В примере – высота полета самолета.

Поиск составных частей системы и их свойств, оказывающих решающие влияние на выделенные системные свойства. В примере – двигатель (мощность), крылья (площадь), самолет (вес).

Декомпозиция может продолжаться до тех пор, пока не будут выделены достаточно простые составляющие рассматриваемой системы и её подсистемы. Здесь «простота» – является субъективным показателем, то есть каждый аналитик определяет сам для себя как долго необходимо выполнять разбиение системы и ее подсистем на составляющие элементы. Выделенные элементы и их упрощенное описание в виде набора свойств, необходимых для решения поставленной задачи представляет собой не что иное как абстракцию.

Особенности проектирования программных систем

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

многоуровневая система абстракции;

модульность;

простота.

Многоуровневая система абстракции основывается на иерархии классов, максимально взаимосвязанных по горизонтали и минимально по вертикали. Каждый уровень абстракции «сотрудничает» по вертикали с другим посредством четкого интерфейса с внешним миром и основываются на столь же хорошо продуманных средствах нижнего уровня. На каждом уровне интерфейс абстракции строго отграничен от реализации. Реализацию можно изменять, не затрагивая при этом интерфейс. Изменяясь внутренне, абстракции продолжают соответствовать ожиданиям внешних клиентов.
Модульность – это свойство программной системы, которая была разделена на связные и слабо зацепленные между собой модули, реализующие заданные абстракции разрабатываемой системы. Модуль – это единица кода, служащая строительным блоком физической структуры системы; программный блок, который содержит объявления, выраженные в соответствие с требованиями языка и образующие физическую реализацию части или всех классов и объектов логического проекта системы. Как правило, модуль состоит из интерфейсной части и реализации.

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

Г.Буч приводит мнение Ингалса , отражающие суть модульности: «для построения системы должен использоваться минимальный набор неизменяемых компонент; сами компоненты должны быть по возможности стандартизованы и рассматриваться в рамках единой модели». Применительно к объектно-ориентированному проектированию такими компонентами являются классы и объекты, отражающие ключевые абстракции системы, а единство обеспечивается соответствующими механизмами реализации.

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

Понятие объекта, объектно-ориентированной модели

В методологии объектно-ориентированного проектирования одним из основных понятий являются объект, объектная модель и класс объектов. Поскольку для системологического подхода к декомпозиции в объектно-ориентированном анализе и проектировании программного обеспечения эти понятия очень важны, приведем их определения и разъяснения.
По определению Г.Буча, объект – это нечто, чем можно оперировать. Объект имеет состояние, поведение и идентичность . Объект в методологии объектно-ориентированного проектирования с точки зрения системологии является знаковым объектом. Г.Буч в своей книге приводит определение Смита и Токи: «Объект представляет собой конкретный опознаваемый предмет, единицу или сущность (реальную или абстрактную), имеющую четко определенное функциональное назначение в данной предметной области». Состояние объекта характеризуется перечнем (обычно статическим) всех свойств данного объекта и текущими (обычно динамическими) значениями каждого из этих свойств . К числу свойств объекта относятся присущие ему или приобретаемые им характеристики, делающие объект самим собой . Поведение – это то, как объект действует и реагирует; поведение выражается в терминах состояния объекта и передачи сообщений .
Объектная модель – это совокупность основополагающих принципов, лежащих в основе объектно-ориентированного проектирования, и/или парадигма программирования, основанная на принципах абстрагирования, инкапсуляции, модульности, иерархичности, типизации, параллелизма и устойчивости . Абстракция – это существенные характеристики объекта, которые отличают его от всех других объектов и четко определяют его концептуальные границы для наблюдателя. Абстрагирование – процесс выявления абстракций . Инкапсуляция – это процесс объединения и защиты элементов абстракции, которые образуют ее структуру и поведение. Служит для отделения внешних обязательств объекта от его реализации .
Таким образом, абстракция – это знаковая модель, содержащая существенные (имеющие значение в рамках решаемой задачи) свойства объекта. Кроме того, абстракция допускает разделение на составные элементы, которые и формируют состояние и поведение объекта. Для понимания в рамках описанных выше системных понятий важно то, что объект описывается существенными характеристиками или абстракциями, которые являются результатом взаимосвязи компонентов объекта. Вполне допустимым является вывод, что абстракция должна содержать эмергентное(ые) свойство(а), появившееся(иеся) в результате взаимосвязи инкапсулированных компонентов объекта.

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

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

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

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

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

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

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


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

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

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

Понятие системы

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

Синтез и анализ в изучении сложных систем

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

Системологический подход к декомпозиции

к.т.н. И.М. Слюсаренко, к.т.н. М.Ю Слюсаренко, «InfoSoftCom»
В статье рассмотрена взаимосвязь основных вопросов объектно-ориентированного анализа и проектирования программного обеспечения с понятиями и процедурами системологии. Предложено обобщенное правило декомпозиции. Показана целесообразность применения основных принципов системологии при анализе и синтезе программных систем.
Развитие науки осуществляется в направлении интеграции отдельных ее направлений; при этом появляются обобщенные методологии, основные принципы которых применимы к частным дисциплинам. Так, со временем стало ясно, что теория надежности, информации, управления, самоорганизации и другие дисциплины кибернетики исследуют различные свойства одного и того же целостного объекта – сложной системы. Поэтому современные исследователи отождествляют кибернетику с системологией .
Как показывает практика, системологические принципы целесообразно осознанно внедрять в автоматизацию бизнес-процессов , процессы изучения, проектирования различных систем, в том числе информационных. При разработке программных систем одним из наиболее сложных вопросов является вопрос декомпозиции – выделения основных составных частей разрабатываемого программного продукта. Правильное понимание процесса декомпозиции и навыки владения декомпозицией полностью определяют успех создания программного продукта. Применение основных системологических принципов позволяет упростить решение этого вопроса.

Системологическое описание проектирования программных систем

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

Список литературы

Флейшман Б. С. Основы системологии, М.: Радио и Связь. 1982.

Слюсаренко И.М., Слюсаренко М.Ю. Системный подход в автоматизации процессов компаний.

Слюсаренко И.М., Слюсаренко М.Ю. Основы системологии и автоматизация бизнес-процессов компаний.

Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С ++, 2-е изд./Пер. с англ .- М.: «Издательство Бином», СПб.: «Невский диалект», 1999 г.

Бусленко Н. П. Моделирование сложных систем. М.: Наука. 1978г.

ориентированного анализа является одной из

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

Моделирование программных систем

Для успешной реализации проекта объект проектирования (в нашем случае ПО) должен быть прежде всего адекватно описан, то есть должна быть построена полная и непротиворечивая архитектура ПО. Архитектура ПО представляется в виде совокупности моделей, которые строятся для того, чтобы понять и осмыслить структуру и поведение будущей системы, облегчить управление процессом ее создания и уменьшить возможный риск, а также документировать принимаемые проектные решения. Разработка архитектуры системы ПО промышленного характера на стадии, предшествующей ее реализации или обновлению, в такой же мере необходима, как и наличие проекта для строительства большого здания. Это утверждение справедливо как в случае разработки новой системы, так и при адаптации типовых продуктов класса R/3 или BAAN, в составе которых также имеются собственные средства моделирования. Хорошие модели являются основой взаимодействия участников проекта и гарантируют корректность архитектуры.
Очевидно, что основная цель разработки ПО — это не моделирование, а получение работающих приложений (кода). Диаграммы в конечном счете — это всего лишь наглядные изображения. Поэтому при использовании графических языков моделирования очень важно понимать, чем это поможет, когда дело дойдет до написания кода. Можно привести следующие причины, побуждающие прибегать к их использованию.

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

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

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

Из всего сказанного выше можно сделать вывод, что моделирование сложных программных систем с помощью CASE-средств является самостоятельным и самодостаточным видом деятельности в процессе создания ПО.
В то же время практическое внедрение CASE-технологии в организациях-разработчиках ПО связано с рядом проблем. Они достаточно полно изложены в американском стандарте IEEE Std. 1348-1995. IEEE Recommended Practice for the Adoption of Computer-Aided Software Engineering (CASE) Tools. Цель приведенных в стандарте рекомендаций — предоставить руководство, позволяющее повысить вероятность успешного внедрения CASE-технологии. Эти рекомендации достаточно актуальны и ценны, поскольку отражают опыт, накопленный многими зарубежными пользователями и разработчиками CASE-средств.

Ниша и внедрение CASE-средств

Александр Вендров

15.11.2000

С внедрением CASE-средств обычно связывают большие надежды, однако не всем им суждено стать реальностью
После того как я прочел в сентябрьском выпуске журнала «Директору ИС» статью Фреда Хэпгуда «CASE: конец истории?», захотелось поделиться своими (и не только своими) соображениями — все-таки уже почти десять лет занимаюсь этой проблематикой. Заголовок статьи сразу вызвал желание возразить: какой же это конец истории, когда ей без году неделя, и все только начинается (достаточно обратиться к оценке степени развитости программной инженерии, содержащейся в техническом отчете SEI «A Mature Profession of Software Engineering», опубликованном в 1996 году). По существу, я хочу поддержать одно из мнений, процитированных в статье Хэпгуда, а именно то, что CASE-средства заняли свою нишу в области проектирования больших и сложных систем.
Если рассматривать CASE (Computer Aided Software Engineering) в первоначальном понимании — как средство компьютерной поддержки разработки программного обеспечения (ПО), то их польза в проектировании больших и сложных программных систем станет вполне понятной. В подтверждение этого тезиса можно сослаться на «Мифический человеко-месяц» Фредерика Брукса. Самой большой проблемой, которую приходится решать программной инженерии, является сложность ПО. Сложность становится существенным и неотъемлемым свойством программных систем. Поэтому попытки описания программных объектов, абстрагируясь от их сложности, приводят к абстрагированию и от их сущности. Наблюдается нелинейный рост сложности при увеличении размера ПО. Создаются трудности в процессе общения между разработчиками, что ведет к ошибкам в продукте, превышению стоимости разработки, затягиванию выполнения графиков работ. Сложность структуры затрудняет развитие ПО и добавление новых функций.

О выборе CASE-средства

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

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

Обеспечение целостности проекта и контроля за его состоянием.

Независимость от программно-аппаратной платформы и СУБД.

Поддержка одновременной работы групп разработчиков.

Возможность разработки приложений «клиент-сервер» требуемой конфигурации.

Открытая архитектура и возможности экспорта/импорта.

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

Простота освоения и использования.

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

Использование общепринятых, стандартных нотаций и соглашений.

В конечном счете мы пришли к выводу, что решающее значение имеет критерий № 7 — качество технической поддержки и т. д., поскольку в случае отсутствия у фирмы-поставщика надежного партнера в России, выполняющего на высоком уровне весь комплекс услуг по поддержке CASE-средства, его внедрение становится просто бессмысленным.
Кстати, началом появления на российском рынке первых CASE-средств можно считать 1992 год. Первыми такими средствами были ProKit Workbench фирмы McDonnell Douglas Information Systems, Design/IDEF фирмы MetaSoftware и отечественная разработка фирмы «Эйтекс» под названием CASE.Аналитик. В дальнейшем на рынке появились и успешно использовались такие продукты, как ERwin, BPwin, Silverrun, Oracle Designer, Rational Rose.

Ожидаемые и неожиданные результаты

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

ускорение и повышение согласованности разработки приложений;

снижение доли ручного труда в процессе разработки и/или эксплуатации;

более точное соответствие приложений требованиям пользователей;

отсутствие необходимости большой переделки приложений для повышения их эффективности;

улучшение реакции службы эксплуатации на требования внесения изменений и усовершенствований;

лучшее документирование;

улучшение коммуникации между пользователями и разработчиками;

последовательное и постоянное повышение качества проектирования;

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

лучшая прогнозируемость затрат.

Нереалистичные ожидания:

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

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

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

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

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

достижение абсолютной полноты и непротиворечивости спецификаций;

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

немедленное снижение затрат, связанных с информационной технологией;

снижение затрат на обучение.

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

специалисты по планированию внедрения CASE-средств;

выбор и установка средств;

учет специфических требований персонала;

приобретение CASE-средств и обучение;

настройка средств;

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

интеграция с другими средствами и существующими данными;

освоение средств разработчиками;

технические средства;

обновление версий.

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

Подытоживая сказанное

Отмечу еще раз, что основная ниша CASE-средств — проектирование больших и сложных систем. Однако их применение может быть успешным в полной мере только при условии надлежащей организации проекта, достаточного финансирования, разумных сроков и т. д. В то же время в последние годы складывается культура так называемых экстремальных проектов. В англоязычной литературе с легкой руки Эдварда Йордана, одного из ведущих мировых специалистов в области программной инженерии и автора книги Death March. The Complete Software Developers’s Guide to Surviving «Mission Impossible» Projects, выпущенной издательством Prentice-Hall в 1997 году (в издательстве «ЛОРИ» выходит ее русский перевод), за такими проектами утвердилось название death march, буквально — «смертельный марш». Однако более подробный разговор на тему об использовании CASE-средств в таких проектах лучше оставить для отдельной статьи.
document.write('');

Новости мира IT:

02.08 -

02.08 -

02.08 -

02.08 -

02.08 -

01.08 -

01.08 -

01.08 -

01.08 -

01.08 -

01.08 -

01.08 -

01.08 -

01.08 -

01.08 -

31.07 -

31.07 -

31.07 -

31.07 -

31.07 -

Архив новостей

Последние комментарии:
(66)

2 Август, 17:53
(19)

2 Август, 17:51
(34)

2 Август, 15:40
(42)

2 Август, 15:35
(1)

2 Август, 14:54
(3)

2 Август, 14:34
(3)

2 Август, 14:15
(2)

2 Август, 13:34
(7)

2 Август, 13:04
(3)

2 Август, 12:28

BrainBoard.ru

Море работы для программистов, сисадминов, вебмастеров.

Иди и выбирай!

Loading
google.load('search', '1', {language : 'ru'}); google.setOnLoadCallback(function() { var customSearchControl = new google.search.CustomSearchControl('018117224161927867877:xbac02ystjy'); customSearchControl.setResultSetSize(google.search.Search.FILTERED_CSE_RESULTSET); customSearchControl.draw('cse'); }, true);

IT-консалтинг

Software Engineering

Программирование

СУБД

Безопасность

Internet

Сети

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

Hardware

PR-акции, размещение рекламы — , тел. +7 495 6608306, ICQ 232284597

Пресс-релизы —

This Web server launched on February 24, 1997 Copyright © 1997-2000 CIT, © 2001-2009

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

Актуальное предложение: по адекватным ценам.

Проблемы внедрения CASE-средств

Несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате чего создание с их помощью ПО становится «полочным» (shelfware).
В связи с этим необходимо отметить следующее:

CASE-средства не обязательно дают немедленный эффект; результат может быть получен только спустя какое-то время;

реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

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

относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;

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

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

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

различная степень интеграции CASE-средств в различных проектах.

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

Процесс внедрения CASE-средств

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

достоверная оценка отдачи от инвестиций в CASE-средства затруднительна ввиду отсутствия приемлемых метрик и данных по проектам и процессам разработки ПО;

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

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

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

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

негативное отношение персонала к внедрению новой CASE-технологии может быть главной причиной провала проекта.

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

Инструмент разработчика ПО: реализация

Начнем с нескольких предварительных замечаний. Считаем, что разработка ведется в объектно-ориентированной среде. Следовательно, будем моделировать объекты, но больше обращать внимание на их алгоритмическую и поведенческую часть. Однако разработчикам, не использующим ООП, не следует переживать: инструмент может использоваться и в классическом процедурном программировании. Этот инструмент - метод "Автоматно-алгоритмических схем".
Определение состава элементов уже в значительной степени выполнено выше: колонка "Базовое понятие" содержит все необходимое: Состояние, Событие, Действие, и Решение. Именно такой состав элементов, с небольшой коррекцией, содержится и в нашем методе. Рассмотрим их подробнее.
Состояние. В излагаемом методе состояние - элемент конечно-автоматного происхождения. Оно означает, что моделируемый объект в нем "находится". Находясь в некотором состоянии, объект не выполняет никаких действий. Состояние обозначается подобно UML, в виде вытянутого по горизонтали прямоугольника с закругленными углами, выполненного жирной линией (Рисунок 4). Содержимое состояния - только его название. Ширина фигуры должна быть достаточной для размещения названия элемента. Высота - как правило, достаточная для размещения одной строки текста.

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

Рисунок 5.

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

Рисунок 6.

Рассмотрим далее элемент "Действие" (Рисунок 6). Под ним понимается любой оператор действия какого-либо языка, или некоторая неразрывная последовательность действий. Это чисто алгоритмический символ, аналог символа "Процесс" по стандарту []. Он изображается прямоугольником с линиями обычной толщины, и с размерами, достаточными для размещения внутри него однозначного описания сути выполняемых действий. Например, описание может быть оператором присвоения, вызовом кого-либо метода, и т.д., а также может быть группой из нескольких подобных операций (Рисунок 7).

Рисунок 7.

Наконец, последний элемент нашего представления - Решение. По смыслу он аналогичен алгоритмическому символу "Решение" по []. Фактически это аналог операторов if - else, switch (case) в языках программирования. Он выполняется в виде ромба, усеченного сверху и снизу (Рисунок 8). Подобный вариант изображения предлагается стандартом [], считаю его весьма удобным.

Рисунок 8.

Он имеет две формы. Первая - простое решение - аналог операторов if - else (Рисунок 9).

Рисунок 9.

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

Вторая форма элемента "решение" - аналог операторов switch (case) (Рисунок 10). В отличие от первой, она дополняется колонкой выбора - узким вертикальным прямоугольником из линий обычной толщины, примыкающим к середине нижней грани основной фигуры. Колонка выбора служит для размещения на ней отправных точек специальных дуг - ветвей выбора, обозначающих варианты ветвления аналогично вхождениям case оператора switch (метки ветвления оператора case).

Рисунок 10.

Над первым отрезком ветви выбора указывается конкретное значение проверяемого в операторе выражения.

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

Дуга, выходящая из бокового угла основной фигуры, всегда соответствует предложению default (otherwise, else) оператора switch (case). То есть переход по ней происходит, если не выполняется ни одно из условий ветвей выбора. Поэтому она также не нуждается в обозначении.

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

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

Рисунок 11.

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

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

Рисунок 12.

Читатель может возразить: вместо одного элемента - шесть: где же здесь упрощение? Ответ такой:

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

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

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

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

В качестве примера применения схем на представлена простейшая модель буфера сообщений (очереди) между двумя объектами. Он реагирует на три события: Готовность к записи (Готов), Запись в буфер (Запись), и Передача из буфера (Передача). Первые два события генерируются источником данных, последнее - приемником данных. Реакция "Запись" содержит параметр "Вход" - входное сообщение буфера. Реакция на событие "Готов" имеет возвращаемое источнику данных значение логического типа "Возврат", которое означает возможность записи в буфер. Реакция на событие "Запись" также имеет возвращаемое значение, которое означает, что запись в буфер выполнена. Для простоты операция перемещения указателей в пределах кольцевого буфера показана в виде инкремента "++". Буфер может находиться в одном из трех состояний: Свободен, Занят, и Переполнен.

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

Инструмент разработчика ПО: требования

На основании изложенного выше сформулируем требования, предъявляемые к средству моделирования "средних" программных средств:

Количество представлений должно быть минимальным (в идеале - одно).

В инструменте не должно быть ортогональных представлений.

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

Элементы представлений должны быть простыми.

В представлениях не должно быть неявных элементов.

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

Представления UML

Еще одна особенность UML - заложенное в нем многообразие представлений. Наличие нескольких представлений в модели, конечно же, дает более разностороннее, и в итоге более качественное понимание проектируемого объекта. Однако такое суждение справедливо только в первом приближении. Рассмотрим эту особенность более внимательно с точки зрения рассматриваемой области применения.
Для начала введем некоторые термины, необходимые для понимания последующего изложения.
Разработка программных систем представляет собой некоторое количество отображений, то есть создание ряда представлений проектируемой системы на основании разработанных ранее других представлений. Например, разработка программного кода - это отображение сформулированных ранее требований к системе, либо созданных ранее диаграмм, моделей, в упорядоченное множество операторов языка программирования. При прямом программировании выполняется отображение требований к системе в программный код (Рисунок 2). В случае использования CASE-средства выполняется несколько отображений. Например, в UML выполняются такие отображения: требования - диаграммы взаимодействия, требования - диаграммы состояний, требования - структурные диаграммы, и т.д. (Рисунок 3).

Рисунок 2.

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

Трансляция - когда элементы исходного представления, в т.ч. их совокупности (или их существенная часть), имеют соответствующие аналоги в виде элементов или их совокупностей в целевом представлении.

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

При некоторой схожести этих терминов (в том смысле, что оба они означают перевод из одной системы понятий в другую), трансляция - особенно в программистской среде - хорошо ассоциируется с формализованным процессом, что и требуется в данном случае. Преобразование же ассоциируется с чем-то гораздо менее определенным. Условимся считать эти два понятия своеобразными "полюсами", противоположными сторонами спектра возможных отображений
Если в первом случае можно определить некоторые стандартные процедуры отображения, вплоть до полной формализации процесса, то во втором - таких процедур либо не существует в принципе, либо возможное их количество незначительно. Отсюда вытекает оценка трудоемкости: если преобразование требует существенных трудозатрат, причем квалифицированного персонала, то с трансляцией может справиться практически любой специалист, знающий правила этой трансляции. Выполнение преобразования является в основном искусством, в то время как трансляция - довольно рутинный набор операций, легко поддающийся автоматизации.
В реальном мире, конечно же, имеется спектр возможных характеристик, то есть отображение может быть различным по качеству - от преобразования до трансляции. Практическая полезность данной классификации состоит в том, что конкретное отображение, его трудоемкость, требуемую квалификацию персонала, мы можем качественно оценивать путем определения степени приближения его к одному из краев этого спектра.
Отсюда вытекает возможность сопоставления представлений, связываемых отображением.
Введем еще одно понятие. Будем оценивать соотношение представлений, участвующих в отображении, степенью приближения этого отображения к преобразованию, и назовем эту характеристику "ортогональность". Она может принимать значения от нуля до максимума, то есть, от стопроцентной трансляции (нулевая ортогональность) до стопроцентного преобразования (максимальная ортогональность).
Термин "ортогональность" довольно успешно применяется в литературе для обозначения степени несоответствия различных представлений (см. например, []). Уточнение термина и сопоставление предыдущими понятиями введено исключительно с целью более однозначного понимания дальнейших рассуждений.
Исходное и целевое представления в преобразовании можно назвать ортогональными в том смысле, что они не имеют точек сопоставления. Это означает, что конкретная реализация (диаграмма, модель), выполненная в исходном представлении, может быть отображена в несколько практически эквивалентных по качеству реализаций в целевом представлении. Причем, количество возможных эквивалентов может быть и неограниченным, поскольку зависит только от разнообразия мышления выполняющих это преобразование специалистов. Степень ортогональности двух представлений соответствует степени приближения их отображения к преобразованию.
Примером трансляции может быть компиляция программного кода в язык ассемблера: элементы исходного представления - языка программирования - имеют соответствующие аналоги (элементы, или их совокупности) в целевом представлении - языке ассемблера. Пример преобразования - разработка структуры классов, когда исходным представлением являются функциональные требования к проектируемой системе: на сегодняшний день не существует однозначного соответствия между элементами требований и элементами структуры классов.
Теперь можно сформулировать еще одну характеристику качества CASE-инструмента применительно к рассматриваемой области: в процессе разработки программных средств количество отображений типа преобразование должно быть минимальным, в идеале - отсутствовать, в то время как количество отображений типа трансляция ограничивается только практическими соображениями.
Возвращаясь к UML и с учетом вышесказанного, отметим, что многообразие представлений, кроме положительного эффекта в виде более полного представления, создает и дополнительные проблемы. С одной стороны, требуется формирование, воплощение этих представлений в модели. То есть трудоемкость моделирования умножается на их (представлений) количество. С другой стороны, создание кода по спецификациям сразу нескольких различных представлений - гораздо более трудоемкая задача, нежели прямое программирование. К тому же некоторые из этих работ требуют преобразования, что по определению является искусством, то есть, задачей значительной трудоемкости. Если еще учесть итеративность разработки, которая представляет собой множитель для всех работ по моделированию, то мы получим весьма впечатляющие значения дополнительной трудоемкости. Эти суждения вполне согласуются с оценками сложности внедрения CASE-средств, приведенными в многочисленной литературе (см. например, [], []). Только причиной здесь, как мы видим, является не столько сложность проектируемой системы, сколько сложность инструмента, умноженная на специфику проектирования программных средств.
Еще одна особенность UML - то, что в нем сложно моделировать просто алгоритмы, обычные последовательности действий. Специального вида диаграмм не существует, а похожие виды (например, диаграмма активностей) обладают избыточной сложностью, и не имеют некоторых аналогов элементов алгоритмических схем. Между тем, алгоритмические схемы широко используются в разработке "средних" программных средств, поскольку обладают высокой степенью адекватности программному коду. В результате, как отмечено в [], в анализе реально выполненных проектов, "В рассмотренных моделях операции практически не обладали семантикой состояний, поэтому 99% операций описывались автоматами без состояний, вырождаясь в императивную последовательность действий", то есть автоматы фактически использовались для отображения алгоритмов. Что свидетельствует о наличии серьезной потребности в таких средствах, степень адекватности которых алгоритмическому представлению, программному коду, была бы достаточно высокой.
Резюмируем изложенное: существенными особенностями UML, усложняющими проектирование, являются необходимость разработки нескольких представлений проектируемой системы, иногда ортогональных исходному либо целевому представлению, избыточное многообразие этих представлений, а также неполная адекватность инструмента фактическим потребностям разработчиков.
Все вышесказанное в той же мере относится и к основанным на UML CASE-средствам, поскольку они автоматически воспроизводят избыточную сложность языка.

Применимость CASE-средств

В [] утверждается, что сфера применения современных CASE-средств - "большие и сложные системы". В самом деле, сложность и стоимость CASE-средств оправдывается только в больших проектах. Следовательно, не стоит даже пытаться применять их в разработке "средних" программ. С этим утверждением можно полностью согласиться, но применительно только (!) к существующим на сегодняшний день на рынке средствам. По собственному опыту знаю: почти в каждой разработке попадается какая-нибудь "закавыка", справиться с которой "в рукопашную" (то есть, без моделирования) в принципе возможно, но только при крайнем напряжении интеллекта. Да и при разработке обычных объектов чрезвычайно полезны схемы, диаграммы, алгоритмы, и т.д., которые в основном рисуются на бумаге от руки. По сути, это - те же модели, только выполненные вручную. Поэтому, возможно, более справедливым будет утверждение, что современные CASE-системы не удовлетворяют некоторым критериям качества, существенным для сферы "средних" программных средств, в силу чего их применение здесь невозможно.
Но что же тогда остается разработчикам "средних" программных средств? Ручка и бумага? Как ни прискорбно будет заметить, но огромнейший класс специалистов оказался, что называется, "за бортом" автоматизации. Это явление представляется ненормальным, что собственно, и стало основным мотивом проделанной работы.
Возможны ли CASE-средства массового применения? Считаю, возможны на сто процентов. Более того, меня удивляет их отсутствие. В это мнение получит подтверждение, а сейчас в связи с этим рассмотрим следующий вопрос: почему в свое время языки высокого уровня получили широкое распространение, и, в конце концов, вытеснили низкоуровневые языки типа ассемблеров? Очевидно, потому, что имели ощутимые преимущества:

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

Более качественно отображали алгоритмы, структуру программы, и т.п.

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

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

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

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

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

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

Обратное утверждение собственно и составляет основную мысль данной статьи:

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

Рассмотрим с этой точки зрения UML как пример CASE-средства, конкретно - диаграммы состояний.

UML-диаграммы состояний

Рассмотрим наиболее характерный элемент диаграммы - состояние (Рисунок 1).

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

Входное действие.

Выходное действие.

Действие внутреннее (деятельность).

Кроме того, в соответствии со стандартом UML, состояние может содержать:

Вложенные состояния.

Входные и выходные порты.

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


Элемент диаграммы состояния Базовое понятие Нагружен понятиямиСостояние Действие Решение Событие

Состояние	Состояние	*	***
Переход	Действие		*	*	*
Решение	Решение
Событие	Событие	Не имеет специального обозначения

Таблица 1.
Как нетрудно заметить, основные элементы (кроме элемента "Решение") нагружены несколькими дополнительными понятиями. Между тем, все элементы и их "нагрузки", фактически являются производными от небольшого числа элементарных (базовых) понятий: Состояние, Действие, Решение, Событие.
В итоге, уже на этапе моделирования сложность создания представления посредством этих элементов сопоставима с прямым программированием. Но мы же еще только моделируем объект, а не программируем его! Получается, мы должны на разработку объекта затратить близкое к двойному количество труда. И ради чего? Ради получения более выразительного представления, которого к тому же зачастую бывает недостаточно для программирования объекта.
С другой стороны, такой существенный элемент модели, как событие (без которого модель состояний бессмысленна), не имеет самостоятельного графического обозначения. Событие распознается только по тексту, сопровождающему другой элемент (переход), что на наш взгляд, является существенным недостатком языка, создающим дополнительную сложность при моделировании диаграмм состояний.
Подобные качества элементов в разной степени присутствуют и в других диаграммах UML.
Резюмируем изложенное: элементы диаграмм UML обладают избыточной сложностью, имеются неявные элементы, и все это существенно затрудняет их изучение, восприятие, использование, а, соответственно, вносит избыточную трудоемкость в разработку программного обеспечения.

здесь выполнены достаточно простые действия:

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



    Работа с информацией: Cистемы - Технологии - Рынок

• Анализ информационных систем
  
• Методы информационных систем
  
• Интернет как информационная система
  
• Искусственный интеллект в информационных системах
  
• Обработка информации информационными системами
  
  
• Информационные системы в офисе
  
• Управление информационными системами
  
• Технологии информационных систем
  
• Теория информационных систем
  
• Почта - информационная система
  
  
• Outlook и информационные системы
  
  
• Информационный рынок
  
• Информационный рынок - IT
  
• Технологии информационного рынка
  
• Безопасность на информационном рынке