Модели жизненного цикла программного обеспечения.
Русский | English   поискrss RSS-лента

Главная  → Книги и компьютерная пресса  → Новосибирская школа программирования. Перекличка времен.  → Модели жизненного цикла программного обеспечения

Модели жизненного цикла программного обеспечения

часть 2

3. Требования к программному изделию
и жизненный цикл

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

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

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

3.1. Проблемы определения и анализа требований

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

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

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

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

3.2. Трассировка требований

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

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

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

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

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

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

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

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


Рис. 14. Схема трансформации требований

Иерархия типов требований представлена на рисунке следующим образом. Верхний уровень — это абстрактный тип, свойства которого присущи требованиям всех типов (они сводятся к стандартизованному набору операций объединения, пересечения атрибутов, сравнения значений атрибутов и др.). Можно сказать, что Т абстр задает регламент, которого следует придерживаться при оперировании с требованиями. Следующий уровень содержит четыре обязательных типа: Т экон, Т функ , Т инт и Т эфф , которые объединяют требования экономического характера (пределы стоимости, рентабельность и пр.), функциональные требования, требования к интерфейсу и эффективности. Многоточием обозначены типы, которые, добавляются из-за специфики проекта. Т a ( a 1,…, an a ), Т b ( b 1,…, bn b ), Т c ( c 1,…, cn c ), …, Т z ( z 1,…, zn z ) — это конкретные типы, к которым приписываются элементарные составляющие требований (в скобках указаны их атрибуты).

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

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

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

3.3. Учет трассировки требований в модели жизненного цикла

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

Первый вариант полностью укладывается в схему модифицированной модели фазы — функции (рис. 9, 10). Если требование (группа требований) принимается для данной итерации и используется при разработке сценария, который будет реализовываться (контрольные точки 2, 8), то указанные на схеме трассировки работы включаются в аналитическую и конструкторскую деятельность. В противном случае оно либо откладывается до последующих итераций, либо отклоняется.

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

На рис. 15 показано фазовое измерение модифицированной матрицы Гантера (рис. 9, 10), дополненное мини-циклом обработки одного требования или группы требований, обрабатываемых совместно. Контрольные точки (события) в данной модели те же, что и в прежней матрице фазы — функции. При построении модели используется прием, который ранее (при учете итеративности в модели — см. п. 2.4) был назван расщеплением линии жизненного цикла. Следует обратить внимание на прерывистую часть линии, ведущей от точки принятия решения к линии итеративного зацикливания. Она выделена, чтобы отразить тот факт, что для анализируемого требования, реализация которого отложена до одной из последующих итераций, работы этапа программирования не проводятся. Возобновление непрерывности линии указывает, что на этапе оценки для данного требования начинаются работы по обоснованию включения его в планы реализации одной из будущих итераций.


Рис. 15. Фазовое измерение модели жизненного цикла при
объектно-ориентированном развитии проекта, дополненное
обработкой требования в мини-цикле

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

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

3.4. Особенности первой итерации

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

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

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

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

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

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

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

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

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

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


Рис. 16. Фазовое измерение модели жизненного цикла при
объектно-ориентированном развитии проекта
методом «Сначала в глубину»

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

Из приведенной модели видно, что метод «Сначала в глубину» дает вполне приемлемое представление о том, как происходит объектно-ориенти­рованное проектирование. Разработчики могут рассматривать мини-циклы в качестве прототипа итеративного наращивания, а поскольку каждый из мини-циклов обозрим, к концу первой итерации достигается решение задачи, о которой шла речь выше: доказательство того, что данная команда, используя данный метод в конкретных условиях, в дальнейшем приведет проект к успешным результатам.

3.5. Фаза завершения

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

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

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

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


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

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

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

Заключение

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

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

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

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

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

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

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

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

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

Сегодня универсальные CASE -системы строятся из расчета не всеобщего назначения, а в рамках применения развитых, но все-таки специальных методологий. Несомненный прогресс в данной сфере достигнут для проектирования, ориентированного на моделирование на этапах анализа и конструирования. В рамках объектно-ориентирован­ного подхода разработан специальный унифицированный язык моделирования UML ( Unified Modeling Language ), который рассматривается как основа проектирования в методологии итеративного наращивания возможностей объектно-ориентированных программных систем. На базе этого языка построен ряд CASE -систем общего назначения с весьма развитыми средствами. Наиболее заметной из них является Ration Rose фирмы Ration Software , предложившей на рынок не только инструментарий для использования UML , но и комплексную методологию производства систем — Ration Unified Processing ( RUP ). Данная методология претендует на охват всех аспектов технологий современного программирования. Не вдаваясь в детали того, насколько эти претензии обоснованы, уместно отметить, что в качестве CASE -сис­те­мы Ration Rose обладает множеством средств, очень полезных для поддержки связи первых этапов проектирования с этапом составления программ (кодирования), а также с этапом оценки. В частности, проверяется, что моделирование на разных этапах согласовано, что модельные соглашения, определения классов, других элементов моделей и их взаимосвязи непротиворечивы. Уровень автоматического анализа высок настолько, что позволяет строить по моделям так называемые реализации по умолчанию. Это заготовки программного кода, включающие в себя описания классов и их методов в том виде, который можно извлечь из моделей. Программист дополняет заготовки фрагментами, детализирующими конкретную реализацию.

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

Реализация по умолчанию является лишь одним из приемов поддержки связей между этапами жизненного цикла разработки программного обеспечения с использованием Ration Rose . Именно идея комплексной поддержки связанности рабочих продуктов разных этапов, а не отдельные приемы, которые появлялись и ранее, — главное для данной CASE -системы. Программное воплощение этой идеи, пусть даже с существенными недоработками следует отнести к явным достоинствам данного инструментария. Что же касается претензий RUP на охват «всех рациональных технологий», то в ней больше рекламы, чем фактического результата. Делается попытка механического объединения средств, инструментов и методов довольно многих «рациональных» подходов, но это приводит к эклектике, а для пользователя — к нефиксированной технологии, что по сути своей означает одно — отсутствие технологии. Применяя данную систему, пользователь обязан выстроить свои регламенты: когда, как и в каком качестве будут применяться те или иные средства, методы, инструменты. Если эти регламенты окажутся технологичными, то можно рассчитывать на поддержку Ration Rose , но, к сожалению, не в части проверки принимаемых для формируемой технологии соглашений.

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

Вопросы, которые затрагивались в настоящей работе, освещены в многочисленных публикациях, посвященных технологии программирования. Не все из них выдержали испытание временем. В этой связи в качестве приятного исключения можно указать на работу Ф. Брукса « The Mythical Man - Month . Essay on Software Engineering » (русский перевод первого издания, вышедшего в 1975г., см. в [1], юбилейного издания 1995г. — в [2]). Эта монография по праву считается одной из лучших книг не только по данной тематике, но и по программированию вообще. Сопоставление двух ее изданий явно показывает, что проблемы, которые приходится решать при управлении программными проектами, почти не изменились со времени перфокарт. Меняется только техническая поддержка.

Из ранних работ, не потерявших своей актуальности, прежде всего следует обратить внимание на монографию Гантера [3], содержащую, кроме представленной выше модели, много полезной информации для организации работ над программными проектами. Систематизированные сведения о понятии жизненного цикла и его применении в промышленном программировании можно найти в книге [4], которая, к тому же, дает представление о состоянии дел в этой области в СССР к началу восьмидесятых годов. Весьма обстоятельное исследование задач и методов проектирования и разработки программного обеспечения выполнено Боэмом. Его книга [5] постоянно цитируется и в наши дни.

Современное представление о технологии проектирования программных систем прочно связано с методологией объектно-ориентированно­го программирования. Всестороннее изложение данного подхода, его концепций, а также общих методов разработки проектов в объектно-ориентирован­ном стиле можно найти в книге Буча [6]. UML и методы его использования в практической разработке программных проектов хорошо изложены авторами этого языка в монографии [7]. Понятия, связанные с CASE -технологиями, достаточно четко излагаются в работах [8,   9]. В частности, в последней из упомянутых публикаций достаточно подробно освещаются вопросы CASE -техно­ло­­гий, связанных с проектированием информационных систем.

Следующие ссылки помогут получить сведения об упомянутых выше конкретных разработках. Книга [10] дает наиболее полное представление о СУБД Oracle , в частности, об Oracle Designer 2000 и его месте в системе. I DEF -технология хорошо представлена в документе [11]. Информацию о RUP в целом и Ration Rose в частности можно найти на сайте [12].

Примечания

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

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

Литература

  1. Брукс Ф.П. Как проектируются и создаются программные комплексы. — М.: Мир, 1979.
  2. Брукс Ф.П. Мифический человеко-месяц, или как создаются программные системы. — СПб: Символ-Плюс, 1999.
  3. Гантер Р. Методы управления проектированием программного обеспечения. — М.: Мир, 1981.
  4. Липаев В.В. и др. Технология проектирования комплексов программ АСУ. — М.: Радио и связь, 1983.
  5. Боэм Б.У. Инженерное проектирование программного обеспечения. — М.: Радио и связь, 1985.
  6. Буч Г. Объектно-ориентированное проектирование с примерами применения. — М.: Конкорд, 1992.
  7. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя. — М.: ДМК, 2000.
  8. Новоженов Ю.В. и др. Объектно-ориентированные CASE -средства // СУБД. — 1966, № 5-6. С. 119-125
  9. Вендров А.М. CASE -технологии. Современные методы и средства проектирования информационных систем. — М.: Финансы и статистика, 1998.
  10. Ричардс и др. Oracle ® 7.3. Энциклопедия пользователя. — Киев: «ДиаСофт», 1997.
  11. IEEE IDEF0. “Standard Users Manual for the ICAM Function Modeling Method — IDEF0”. — IEEE draft standard P1320.1.1. 1997.
  12. Rational Unified Process. — Copyright © 2001 Rational Software Corporation. http://www.rational.com/products/rup/index.jsp

Следующая статья сборника

Из сборника "Новосибирская школа программирования. Перекличка времен". Новосибирск, 2004 г.
Перепечатываются с разрешения редакции.

Проект Эдуарда Пройдакова
© Совет Виртуального компьютерного музея, 1997 — 2019