Непейвода Н.Н., Скопин И.Н. Основания программирования

Подождите немного. Документ загружается.

4.5. ИТОГИ И ПЕРСПЕКТИВЫ

235

точке (c). Особенностью анализа в данном случае является то, что он

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

рации уже выполнены;

• реализация отобранных требований или предложений на данной ите-

рации осуществляется по обычной схеме, включающей конструирова-

ние и программирование и оценку. В качестве специфики следует ука-

зать на особую роль проверочных работ — дополнительный этап про-

верки реализации, который вкладывается в этап оценки. Эти работы

обязательно должны включать повторение проверки того, что было от-

лажено ранее. Таким образом, пополнение базового окружения проекта

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

проекта;

• распространение изменений (контрольная точка 10) — деятельность,

направленная на то, чтобы сделанные исправления стали доступны для

всех пользователей обслуживаемой версии. При массовом использова-

нии программного изделия эта работа может потребовать значитель-

ных ресурсов.

Фаза завершения итерации включает этап окончания работ,содержание кото-

рого сводится к сворачиванию деятельности с данной версией программно-

го изделия. Предварительное оповещение о наступлении этапа (контрольная

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

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

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

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

разработки, вкладывая в это солидные ресурсы.

§ 4.5. ИТОГИ И ПЕРСПЕКТИВЫ

Обсуждение жизненного цикла представлено в настоящей главе как по-

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

развивающихся методов и технологий программирования. Однако из этого

не должно складываться впечатление, что столь же прямолинейна историче-

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

течение жизни программы. Напротив, начиная с семидесятых годов XX сто-

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

236

ГЛАВА 4. ЖИЗНЕННЫЙ ЦИКЛ

до наших дней варианты их моделей все множатся и множатся. Причина то-

му — особенности проектов, требующие учета и организационно-техноло-

гической поддержки. В качестве иллюстрации этого тезиса далее упоминает-

ся лишь некоторые особенности, которые нашли свое отражение в реальных

моделях жизненного цикла:

• совместная разработка программного обеспечения и оборудования (об-

щего или специального) назначения,

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

• разработка программного обеспечения по уже существующему прото-

типу,

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

типа,

• построение сетевых комплексов,

• решение задач переиспользования программного обеспечения,

• решение задачи развития программного обеспечения сообществом спе-

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

• учет требований повышенной надежности разрабатываемых программ-

но-аппаратных систем,

• разработка адаптивных систем,

• разработка систем с настраиваемым интерфейсом,

• конструирование программных инструментов,

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

стем (различные варианты моделей).

Этот список может быть продолжен. Так, обнаруживаются и отражаются в

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

длительных, средних и коротких проектов. Как показывает анализ моделей,

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

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

разделах.

4.5. ИТОГИ И ПЕРСПЕКТИВЫ

237

Среди всех мотивов моделирования жизненного цикла особое место за-

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

обеспечения. Систематизация — первый шаг на пути автоматизации любо-

го производства, и в частности, производства программ. Следующие шаги -

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

производства, выявление узких мест, доступных для автоматизации, и раз-

работка инструментов для них. Далее процесс развивается вширь и вглубь:

охватываются автоматизацией другие части технологических маршрутов, со-

вершенствуются ранее построенные инструменты, формируются методы их

эффективного применения. Последнее означает формирование новых техно-

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

деятельности, обусловленных данными технологиями. Наконец, наступает

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

и не обязательно напрямую, с первоначальной систематизацией, формирует

качественно иную потребность в комплексной автоматизации. Это время по-

явления стандартов и стандартных решений, интеграции сложившихся тех-

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

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

автоматизированного технологичного производства. Не является исключе-

нием и процесс технологизации производства программного обеспечения.

Есть, конечно, специфика, но пока еще не ясно, столь ли она значительна,

чтобы считать данное производство чем-то исключительным

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

этапа программирования. Здесь проявляется и специфика: систематизация

работ по производству программного обеспечения осуществлялась после осо-

знания того, что поддержка кодирования, хотя и способствует росту произ-

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

струирования программ. Появление на этой стадии систем программирова-

ния и всевозможных средств помощи в наборе текстов предшествовало пери-

оду, когда начинали внедряться разного рода отладочные средства. Именно

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

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

ного цикла.

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

Хотя уже отмечены некотрые принципиальные отличия программистских задач от стан-

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

на инженерных задачах методики решения проблем, такие, как ТРИЗ.

238

ГЛАВА 4. ЖИЗНЕННЫЙ ЦИКЛ

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

другой — невозможность сведения оценочных работ к тестированию. По су-

ществу это две стороны одной медали: нечеткость постановок задач на про-

граммирование влечет за собой большую часть трудностей этапа проверки.

В результате сформулированной потребности в строгих спецификациях про-

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

нологически регламентирован. И удачные организационные технологии ста-

ли появляться. Чаще это специализированные технологии, предназначенные

для разработки программ особого рода, но иногда и общие технологии, не-

которые из них впоследствии стали автоматизированными (в качестве кон-

кретного примера из этого ряда уместно указать на

IDEF

-технологию). Позд-

нее стали формироваться регламентирующие методики работы с требовани-

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

допускающих полные автоматические проверки, в аналитической части до-

биться так и не удалось (что свидетельствует об объективной трудности дан-

ной области), прогресс заметен: сегодня можно говорить о поддержке накоп-

ления первичных требований и их систематизации, об отслеживании связей

между требованиями и их реализациями в проекте и др.

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

ше. В огромной мере на него влияли языкотворчество и тщетные надежды на

то, что появление очередного “самого хорошего” языка или “самой прогрес-

сивной” техенологии приведет к “решению всех проблем”. Для становления

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

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

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

GNU

технология движения

Open Source

. Пер-

вая из них позволила опять осознать ограниченность способностей человека,

на этот раз в связи с разработкой больших программ. Вторая — дала тол-

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

сложности. Третья — показала, как можно организовать технологию рабо-

ты без привычной для производства централизации (это, видимо, громадный

общепроизводственный и общекультурный вклад современной информати-

ки в развитие общества, пока еще недооцениваемый в других отраслях про-

изводства). Итеративная разработка привела к необходимости модернизации

основополагающих принципов проектирования программ и, в частности, к

новому понятию жизненного цикла.

Но, несмотря на это и другие влияния, стадия комплексной автомати-

зации технологий программирования стала возможной только при соответ-

ствующем уровне развития техники, который позволил эффективно приме-

4.5. ИТОГИ И ПЕРСПЕКТИВЫ

239

нять выразительные графические возможности при выполнении технологи-

ческих процедур конструирования программного обеспечения и поддержи-

вать надежные и хорошо структурированные депозитарии понятий. Немало-

важным обстоятельством, позволившим перейти к комплексной автоматиза-

ции, стало осознание того, что нельзя говорить реально о промышленном

программировании без поддержки технологических функций на всех этапах

жизни программ. Во 80-х годах XX века появился термин

CASE

-технология

(

Computer Aided Software Engineering

— компьютерная поддержка разработ-

ки программ),которым стали обозначать использование систем,обладающих

комплексными автоматизированными средствами поддержки разработки и

сопровождения программ.

Замечено, что, впрочем, вполне объяснимо, что наиболее удачным ока-

залось использование

CASE

-систем в тех специальных областях, в которых

уже были успехи и опыт технологичной практической работы, пусть даже

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

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

очередь здесь следует упомянуть о

CASE

-системах разработки баз данных

в развитых реляционных СУБД (к примеру,

Oracle Designer 2000

в системе

Oracle

). Успехи

CASE

-систем общего назначения скромнее, скорее всего по

причине отсутствия универсальных методов, пригодных для развития лю-

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

является основой технологии, это еще раз подтверждает правомерность по-

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

Сегодня универсальные

CASE

-системы строятся из расчета не всеобщего

назначения, а в рамках применения развитых, но все-таки специальных ме-

тодологий. Несомненный прогресс в данной сфере достигнут для проекти-

рования, ориентированного на моделирование на этапах анализа и констру-

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

цированный язык моделирования

UML

(Uniﬁed Modeling Language), который

претендует на роль основы проектирования в методологии итеративного на-

ращивания возможностей программных систем (и является таковой для ны-

нешнего ООП). На базе этого языка построен ряд

CASE

-систем общего на-

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

Rational Rose

фирмы

Rational Software

, предложившей на рынок не только

инструментарий для использования

UML

, но и комплексную методику произ-

водства систем —

Rational Uniﬁed Process

(

RUP

). Данная методика, конечно

же, претендует на охват всех аспектов технологий современного программи-

рования, но Вы уже знаете, как необходимо относиться к таким претензи-

240

ГЛАВА 4. ЖИЗНЕННЫЙ ЦИКЛ

ям. Уместно отметить, что в качестве

CASE

-системы

Rational Rose

облада-

ет множеством средств, полезных для поддержки связи первых этапов про-

ектирования с этапом составления программ (кодирования), а также с эта-

пом оценки. В частности, проверяется, что моделирование на разных эта-

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

элементов моделей и их взаимосвязи непротиворечивы. Уровень автомати-

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

лям так называемые реализации по умолчанию. Это заготовки программного

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

можно извлечь из моделей. Программист дополняет заготовки фрагментами,

детализирующими конкретную реализацию.

Построение реализации по умолчанию — не нововведение

Rational Rose

До этой системы оно активно применялось и в рамках систем визуально-

го программирования, и еще раньше в специализированных

CASE

-системах,

используемых,например,в развитых СУБД. Последнее примечательно: имен-

но для СУБД удалось связать реализацию по умолчанию с графическими мо-

делями информационных систем (

-диаграммы). В

Rational Rose

и других

UML CASE

-системах поддерживается построение реализаций по умолчанию

по моделям общего, а не специального назначения.

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

связей между этапами жизненного цикла разработки программного обеспе-

чения с использованием

RationalRose

.Именно идея комплексной поддержки

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

рые появлялись и ранее,— главное для данной

CASE

-системы.Программное

воплощение этой идеи, пусть даже с существенными недоработками, следует

отнести к явным достоинствам данного инструментария.

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

RUP

на охват «всех рациональных технологий». Делается попытка механи-

ческого объединения средств, инструментов и методов довольно многих «ра-

циональных» подходов, но это приводит к эклектике, а для пользователя — к

нефиксированной технологии, что по сути своей означает одно —отсутствие

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

регламенты: когда, как и в каком качестве будут применяться те или иные

средства, методы, инструменты. Если эти регламенты окажутся технологич-

ными, то можно рассчитывать на поддержку

Rational Rose

, но, к сожалению,

не в части проверки принимаемых для формируемой технологии соглаше-

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

целесообразно применение

RUP

, от тех, где оно противопоказано:

RUP

ори-

4.5. ИТОГИ И ПЕРСПЕКТИВЫ

241

ентировано прежде всего на задачи, где заказчику важнее форма, чем содер-

жание, и где успех проекта зависит в первую очередь от упаковки, и лишь во

вторую — от качества начинки.

Вопросы,которые затрагивались в настоящей главе,освещены в многочи-

сленных публикациях, посвященных технологии программирования. Боль-

шинство из них соответствуют скорее текущей конъюнктуре, чем сути про-

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

жавшую испытание времением,можно указать на книгу Ф.Брукса “TheMythical

Man-Month. Essay on Software Engineering” (русский перевод первого изда-

ния, вышедшего в 1975г., см. в [14], юбилейного издания 1995г. —в [15]). Эта

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

тематике, но и по программированию вообще. Сопоставление двух ее изда-

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

влении программными проектами, почти не изменились со времени перфо-

карт. Меняется только техническая поддержка.

Из ранних работ, не потерявших своей актуальности, прежде всего сле-

дует обратить внимание на монографию Гантера [23], содержащую, кроме

представленной выше модели, много полезной информации для организа-

ции работ над программными проектами. Систематизированные сведения о

понятии жизненного цикла и его применении в промышленном программи-

ровании можно найти в книге [52], которая к тому же дает представление о

состоянии дел в этой области в СССР к началу восьмидесятых годов. Весь-

ма обстоятельное исследование задач и методов проектирования и разработ-

ки программного обеспечения выполнено Боэмом. Его книга [11] постоянно

цитируется и в наши дни.

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

систем прочно связано с методологией объектно-ориентированного програм-

мирования. Всестороннее изложение данного подхода, его концепций, а так-

же общих методов разработки проектов в объектно-ориентированном стиле

можно найти в книге Буча [16].

UML

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

ческой разработке программных проектов хорошо изложены авторами это-

го языка в монографии [17]. Понятия, связанные с

CASE

-технологиями, до-

статочно четко излагаются в работах [64, 18]. В частности, в последней из

упомянутых публикаций достаточно подробно освещаются вопросы

CASE

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

Следующие ссылки помогут получить сведения об упомянутых выше кон-

кретных разработках.Книга [70]дает наиболее полное представление о СУБД

Oracle

, в частности, об

Oracle Designer 2000

и его месте в системе.

IDEF

-тех-

242

ГЛАВА 4. ЖИЗНЕННЫЙ ЦИКЛ

нология хорошо представлена в документе [85]. Информацию о

RUP

в целом

Rational Rose

в частности можно найти на сайте [88].

Задания для самопроверки

1. Модели традиционного представления о жизненном цикле: мотивация

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

рационная модели.

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

рификации и аттестации. Строгая каскадная модель.

3. Модель фазы-функции Гантера, ее мотивация и особенности. Понятие

технологической функции и интенсивности ее выполнения. Расщепле-

ние линии жизненного цикла.

4. Принципы итеративного проектирования в сопоставлении с последо-

вательным подходом. Этапы жизненного цикла при итеративном про-

ектировании.

5. Модификация модели фазы-функции и ее мотивация. Особенности на-

чальной и завершающей фаз. Переиспользование рабочих продуктов

проекта.Интенсивности технологических функций при объектно-ориентированном

проектировании.

6. Параллельное выполнение итераций. Виды технологического паралле-

лизма.Области совмещения работ.Спиралевидные модели жизненного

цикла.

7. Проблемы определения требований. Трассировка требований и поня-

тие трансформации требований. Схема трассировки требований. Ти-

пизация требований. Глоссарий проекта.

8. Учет трассировки требований в модели жизненного цикла. Результаты

анализа требований.

9. Особенности начальной итерации. Метод проектирования «Сначала в

глубину» и его модель.

10. Фаза завершения проекта (итерации) и моделирование обработки тре-

бований в период эксплуатации системы.

4.5. ИТОГИ И ПЕРСПЕКТИВЫ

243

11. Мотивация множественности моделей жизненного цикла. Модель жиз-

ненного цикла как основа построения технологии проектирования.

12. Специальные и универсальные модели и технологии.

CASE

-системы.

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

UML

и мето-

дология

RUP

Часть II

Структуры программирования

244