Объектно-ориентированное проектирование

ЛЕКЦИЯ 12

Объектно-ориентированное проектирование

Если методы структурного проектирования имели целью упро­щение системной разработки на основе алго­ритмического подхода, то объектно-ориентированные методы решают аналогичную задачу, используя описания классов и объектов, т. е. выразительные сред­ства объектно-ориентированного программирования. Буч (Booch) оп­ределил объектно-ориентированное проектирование как «методо­логию проектирования, соединяющую в себе процесс объектной декомпозиции и приемы представления как логической и физичес­кой, так и статической и ди­намической моделей проектируемой системы».

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

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

• наследуемые от этапа анализа требований и развиваемые на этапе проектирования диаграммы классов и диаграммы объек­тов, являющиеся основой статической логической модели;

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

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

Реализация (программирование/адаптация)

Рекомендуемые материалы

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

Тестирование и отладка

Корректность АСУП является ее самым важным свойством и, несомненно, составляет главный предмет за­боты разработчиков. В идеальном случае под корректностью АСУП понимается отсут­ствие в ней ошибок. Од­нако для большинства сложных программ­ных продуктов достигнуть этого невозможно — «в каждой програм­ме со­держится по крайней мере одна ошибка». Поэтому под коррек­тным обычно подразумевают программный продукт, работающий в соответствии с предъявленными к нему требованиями, другими сло­вами, продукт, для которого пока еще не найдены такие условия, в которых он окажется неработоспособным.

Установление корректности является главной целью рассматри­ваемого этапа жизненного цикла. Следует отме­тить, что этап тести­рования и отладки — один из наиболее трудоемких, утомительных и непредсказуемых этапов разработки АСУП. В среднем при разра­ботке традиционными методами этот этап занимает от '/₃ до '/₂ полного времени разработки. С другой стороны, тестирование и от­ладка представляют собой серьезную проблему: в некото­рых случаях тестирование и отладка программы требуют в несколько раз больше времени, чем непосредственно программирование.

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

Различные аспекты тестирования многократно исследовались, однако полученные теоретические результаты носят почти исклю­чительно негативный характер, что создает пессимистическую кар­тину ценности получаемых при тестировании данных и в целом мо­жет быть суммировано в известном тезисе Дейкстры: «Тестирование про­грамм может служить для доказательства наличия ошибок, но никогда не докажет их отсутствия!». Тем не менее нужно констати­ровать, что на практике результаты тестовых испытаний, не выя­вившие программных ошибок, интерпретируются как свидетельство корректности этой программы.

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

  • формулировку целей тестирования;

• критерии качества тестирования, позволяющие оценить его результаты;

• стратегию проведения тестирования, обеспечивающую дости­жение заданных критериев качества;

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

Для целей тестирования программные элементы АСУП удобно представлять в виде ориентированного графа G = (N, Е),

где N = (N₁, N₂, ..., N_m) — множество узлов (вершин), соответ­ствующих выполняемым операторам тестируемой программы;

Е= (Е₁, Е₂, ..., Е_п) — множество ребер (дуг), соответствующих передачам управления между операторами.

Путем (маршрутом) называется последовательность вершин и дуг Р= (N₁, E_1,2, N₂, E_2,3 , ..., E_k-1,k, N_k), где каждая дуга E_i,i+l выходит из N_t и входит в N_i+l, причем N₁ не обязательно начальный узел. Ветвью называется путь Р, в котором N₁ — либо начальный узел, либо узел ветвления, N_k — либо узел ветвления, либо завершающий узел, все остальные N₁ не являются узлами ветвления.

Очевидно, что полное тестирование всех возможных маршрутов не реально в связи с огромными затратами труда и времени. Поэтому на практике применяются критерии выбора тестов, не гарантирую­щие полной проверки программы. Общим требованием к этим крите­риям является достижение лишь определенной степени полноты АСУП или ее компонент. Как правило, эти критерии устанавливают требо­вание по крайней мере однократной проверки всех операторов про­граммы, всех ветвей программы, либо всех подпутей специального вида (например, всех под­путей, проверяющих циклы при началь­ном, завершающем и одном из промежуточных значений перемен­ной — счетчика цикла). Самым распространенным критерием тести­рования является критерий, требующий по крайней мере однократ­ной проверки каждой из ветвей программ (критерий С₁). Так, напри­мер, тестирование при приемке программного обеспечения для ВВС США производится на основании этого критерия. По ряду независи­мых оценок использование критерия С₁ обеспечивает обнаружение от 67 до 90% ошибок.

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

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

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

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

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

Автоматизация тестирования и отладки

Система автоматизации тестирования и отладки (САТО) пред­ставляет собой сложный комплекс алгоритмиче­ских и программных средств, предназначенных для автоматизации анализа АСУП, тес­тирования, отладки и оценки ее качества, и позволяет облегчить модификацию компонент АСУП, обеспечить выявление ошибок на ранних стадиях отладки, повысить процент автоматически обнару­живаемых ошибок. На рис. 23 показано, как использование САТО влияет на цену обнаружения ошибок в течение жизненного цикла АСУП. АСУП стано­вится «работоспособной», когда цена обнару­женной ошибки меньше некоторого значения μ, которое отражает уровень терпимости пользователя к программным ошибкам. Число имеющихся ошибок (область под кривой) одно и то же в обоих случаях. Отметим, что число обнаруженных ошибок после того, как АСУП становится ра­ботоспособной, почти постоянно по следую­щим причинам:

1) влияние эффекта «ряби» — исправление ошибки служит ис­точником внесения новых ошибок (практика показывает, что такие ошибки составляют 19% всех обнаруженных ошибок);

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

Рис. 23

I - кривая тестирования с использованием САТО,

II - кривая тестирования без использования САТО

САТО значительно сокращает количество ошибок, возникаю­щих по вышеперечисленным причинам за счет предсказания влияния модификации, которые будут содержать эффект «ряби», а так­же за счет генерации и оценки тестов для тщательного и системати­ческого тестирования АСУП.

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

Средства автоматизации, включаемые в САТО, в зависимости от решаемых ими задач разбиваются на средства автоматизации тести­рования и средства автоматизации отладки.

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

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

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

3) средства автоматизированного управления тестированием (тест-мониторы), решающие задачу управления про­цессом тестирования. Тест-монитор формирует входные тестовые данные (возможно, при­нимая их от ГТД), подает их на испытываемый объект, получает результаты работы, визуализирует их и помогает проверить их пра­виль­ность;

4) средства автоматизированного контроля тестирования, позво­ляющие оценить, насколько полная и тщатель­ная проверка АСУП была осуществлена, например, на основе информации о непрове­ренных операто­рах/функциях, непроверенных маршрутах и т. п.;

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

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

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

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

1) средства анализа потоков управления, осуществляющие кон­троль структуры АСУП в целом, а также от­дельных ее конструкций на основе графовой модели. Средства данного типа позволяют авто­матически обнаружить следующие изъяны: невыполняемые опера­торы/функции, тупиковые ветви, некоторые виды бесконечных циклов и др.;

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

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

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

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

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

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

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

Средства частичной автоматизации позволяют пользователю ав­томатически получать необходимую ему инфор­мацию для дальней­шей локализации ошибок вручную. Среди таких средств наиболее распространены DDT (Di­namic Debugging Tools) — «системы для уничтожения блох« (слово «bug» в английском языке означает не только «ошибка», но и »блоха», а ДДТ — популярное в недавнее время средство борьбы с насекомыми). Управление системой DDT и, соответственно, управление отладкой осуществляются посред­ством языка отладки командного типа, его операторы имеют форму приказов (команд), состоящих из ключевого слова и списка опе­рандов, если последние необходимы. Операторы языка отладки обес­печивают взаимодействие программиста с DDT и инициируют вы­полнение соответствующих отладочных функций, согласно которым они могут быть разбиты на следующие группы:

1) управляющие операторы, обеспечивающие управление вы­полнением АСУП в отладочном режиме, а также гибкий контроль исполнения информирующих и контролирующих операторов;

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

3) контролирующие операторы, осуществляющие контроль зна­чений переменных, маршрутов и т. п. на пред­мет сравнения с зара­нее заданными;

4) операторы чтения/записи, дающие возможность форматного ввода тестовых данных и вывода результатов в протокол сеанса от­ладки в терминах исходного языка программирования;

5) служебные операторы, обеспечивающие загрузку отлаживае­мых программных и информационных компо­нент АСУП, переклю­чение режимов (пакет, диалог), ввод в протокол сеанса отладки комментариев и т. д.

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

Эксплуатация и сопровождение

Основные задачи этапа эксплуатации и сопровождения:

• обеспечение устойчивости работы системы и сохранности ин­формации — администрирование;

• своевременная модернизация и ремонт отдельных элемен­тов — техническая поддержка;

• адаптация возможностей эксплуатируемой системы к текущим

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

Особое внимание на этапе эксплуатации и сопровождения сле­дует уделить вопросам обучения персонала и, соответственно, пла­нированию инвестиций в этот процесс.

CASE-технологии — инструментарий поддержки ЖЦ

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

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

Следует отметить, что CASE — не революция в программотехни­ке, а результат естественного эволюционного развития всей отрас­ли средств, называемых ранее инструментальными или технологи­ческими. Однако это и не Confuse Array of Software that does Everything, существует ряд признаков и свойств, наличие которых позволяет классифицировать некоторый продукт как CASE-средство. Одним из ключевых признаков является поддержка структурных и/или объек­тно-ориентированных методологий. С самого начала CASE-средства развивались с целью преодоления ограничений при использовании структурных (а в настоящее время и объектно-ориентированных) методологий (сложности понимания, большой трудоемкости и сто­имости использования, трудности внесения изменений в проект­ные спецификации и т. д.) за счет их автоматизации и интеграции поддерживающих средств.

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

• улучшают качество создаваемой системы за счет средств авто­матического контроля (прежде всего контроля проекта);

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

• ускоряют процесс проектирования и разработки;

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

• поддерживают развитие и сопровождение разработки;

• поддерживают технологии повторного использования компо­нент разработки.

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

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

В табл. 8 приведены оценки трудозатрат по фазам ЖЦ. В табл. 9 сведены основные изменения в ЖЦ при использовании CASE по сравнению с традиционной разработкой.

Таблица 8

Таблица 9

На рис. 24 представлены преимущества разработки с применени­ем CASE-технологий.

Ниже кратко характеризуются основные функциональные воз­можности CASE-средств.

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

Рис. 24

2) Общая БД проекта. Основа CASE— использование БД проекта (репозитария) для хранения всей информации о проекте, которая мо­жет разделяться между разработчиками в соответствии с их права­ми доступа. Содержимое репозитария включает не только объекты различных типов, но и отношения между их компонентами, а также правила использования или обработки этих компонент. Репозитарий может хранить свыше 100 типов объектов, при­мерами которых явля­ются диаграммы, определения экранов и меню, проекты отчетов, описа­ния данных, логика обработки, модели данных, модели предприятия, мо­дели обработки, исходные коды, элементы данных и т. п. Каждый ин­формацион­ный объект в репозитарии описывается перечислением его свойств: идентификатор, имена-синонимы, тип, тексто­вое описание, компоненты, файл-хранилище, область значений. Кроме этого, хранят­ся все отношения с другими объектами (например, все объекты, в кото­рых данный объект используется; все перекрестные ссылки), правила формирования и редактирования объекта, а также контрольная ин­формация о времени порождения объекта, времени его последнего об­новления, кем и в каком проекте он был порожден, номере версии, воз­можности обновления и т. п.

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

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

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

6) Генерация документации. Вся документация по проекту гене­рируется автоматически на базе репозитария (как правило, на базе требований соответствующих стандартов). Несомненное достоинство CASE заключается в том, что документация всегда соответствует текущему состоянию дел, поскольку любые изменения в проекте авто­мати­чески отражаются в репозитарии. Известно, что при традици­онных подходах к разработке АСУП документация в лучшем случае запаздывает, а ряд модификаций вообще не находит в ней отражения.

7) Верификация проекта. CASE обеспечивает автоматическую верификацию и контроль проекта на полноту и состоятельность на ранних этапах разработки, что влияет на успех разработки в целом. В подтверждение этого достаточно привести следующие статисти­ческие данные, основанные на отчетах фирмы TRW по анализу пяти крупных проектов:

• ошибки проектирования и ошибки кодирования составляют соответственно 64 и 32% общего числа оши­бок;

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

• контроль синтаксиса диаграмм и типов их элементов;

• контроль полноты и состоятельности диаграмм;

Бесплатная лекция: "13. Подходы к автоматизации управления предприятием" также доступна.

• контроль декомпозиции функций;

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

8) Автоматическая кодогенерация. Кодогенерация осуществляет­ся на основе репозитария и позволяет автома­тически построить до 80—90% объектных кодов или текстов программ на языках высокого уровня. При этом раз­личными CASE-пакетами поддерживаются прак­тически все известные языки программирования, однако наиболее час­то в качестве целевых языков выступают COBOL, С и ADA. Средства кодогенерации по отношению к полноте целевого продукта разделяют­ся на средства генерации каркаса и средства генерации полного продукта. В первом случае автоматически строится откомментиро-ванная логика (потоки управления) программной системы, а также коды для баз данных, файлов, экранов, отчетов и т. п., остальные фраг­менты кодируются вручную. Во втором случае из про­ектных специфи­каций генерируется полная документированная программа, включая вы­полняемый код, пользовательскую и программную документацию, набо­ры тестов и т. д. Все эти компоненты полной программы связывают­ся в единый объ­ект, хранящийся в репозитарии для облегчения доступа и сопровождения.

Идея автоматической кодогенерации на основе модели заключает­ся в следующем. Любая программа схематически может быть пред­ставлена в виде тройки: обрабатываемые данные, логический каркас обработки, линейные участки обработки. Схема базы данных может быть легко сгенерирована на основании модели «сущность—связь», и совре­менные средства информационного моделирования (например, ERWin, Designer/2000 и др.) обеспечивают такую ге­нерацию. Логика обработки генерируется на основе диаграмм потоков данных: извест­ны алгоритмы автоматического преобразования иерархии DFD в струк­турные карты, а с задачей получения из структурных карт соответ­ствующих ко­дов легко справляется теория компиляции. Наконец, ли­нейным участкам соответствуют мини-спецификации модели. И имен­но здесь лежит ключ к высокому проценту автоматически сгенериро­ванного кода, существенно зависящего от ме­тода задания мини-специ­фикаций.

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