возможности case средств для автоматической генерации программного кода

Возможности case средств для автоматической генерации программного кода

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

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

Содержание

Основные концепции

Большинство CASE-средств основано на парадигме методология/метод/нотация/средство:

Отличия CASE от традиционной разработки

Модель жизненного цикла ПО

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

Простейшая модель ЖЦ:

Классификация CASE-средств

Все CASE-средства делятся на типы, категории и уровни.

Классификация по типам

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

Классификация по категориям

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

Классификация по уровням

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

Источник

Выбор CASE-средства: критерии и методика сравнения

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

Подходы к проектированию

Сравнение средств

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

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

Сравнение наиболее популярных в России CASE-средств

Среди индивидуальных особенностей каждого из средств можно охарактеризовать: возможность выдачи тремя способами проектной информации во внешние файлы для Silverrun, ориентацию на каскадную модель средства от компании Westmount – Vantage Team Builder, преимущество быстрого прототипирования, при взаимодействии этого средства с Uniface. Средства компании Oracle (Designer/Developer) обеспечивают полную поддержку ЖЦ. ERwin и BPwin, являясь средствами локальной автоматизации, имеют упрощенную структуру и имеют целевую направленность, в результате представляются одним из самых простых и удобный решений автоматизации. Объектно-ориентированные средства, такие как Rational Rose на сегодняшний день наиболее полно удовлетворяют задачам групповой работы.

В результате сравнения продуктов, можно сделать вывод о том, что средства, отвечающие структурному подходу (ERwin, BPwin), в основном находят свое применение на этапах определения требований к ИС. Такие средства подходят для осуществления глубокого анализа рассматриваемых процессов (Vantage Team Builder), позволяют максимально рационально расходовать ресурсы, вследствие независимости отельных компонент ПО (Oracle). Что касается объектно-ориентированных средств, стоит отметить, что методика их применения позволяет осуществлять проектирование любого типа, по средству универсальности и наглядности языка UML, который используется в рамках Rational Rose и Power Designer и является достаточно удобным инструментом для оперирования специалистами любого уровня подготовки.

Позиционирование подходов также можно провести по отношению к решению задачи моделирования бизнес-процессов на этапе анализа и проектирования (в соответствии с проведенным выше анализом) следующим образом:

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

Источник

CASE-средства

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

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

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

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

· средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на структурированном языке запросов SQL) для наиболее распространенных СУБД;

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

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

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

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

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

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

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

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

· организация хранилища проектных метаданных (репозитария).

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

Графические средства ориентированы на обеспечение:

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

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

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

Во многих CASE-средствах основу репозитария образует объектно-ориентированная база данных.

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

При выборе CASE-средств используют ряд критериев:

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

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

· независимость средств от программно-аппаратной платформы и СУБД как на этапе разработки проекта, так и на этапе эксплуатации приложений;

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

· возможность реализации в разрабатываемых приложениях современных информационных технологий, включая технологию “клиент-сервер”;

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

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

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

Процесс внедрения CASE-средств включает следующие этапы:

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

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

· выполнение пилотного (первого в конкретной области) проекта;

· практическое внедрение CASE-средств.

Успешное внедрение CASE-средств должно обеспечить:

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

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

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

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

Дата добавления: 2015-03-07 ; просмотров: 3357 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ

Источник

Возможности case средств для автоматической генерации программного кода

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В итоге сложность понятия «состояние» получается настолько высокой, что становится сопоставимой со сложностью соответствующего ему кода.

Результаты аналогичного рассмотрения других элементов диаграммы состояний сведены в Таблицу 1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Определение состава элементов уже в значительной степени выполнено выше: колонка «Базовое понятие» Таблицы 1 содержит все необходимое: Состояние, Событие, Действие, и Решение. Именно такой состав элементов, с небольшой коррекцией, содержится и в нашем методе. Рассмотрим их подробнее.

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

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

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

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

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

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

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

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

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

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

Заключение

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

Источник