1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom

Жизненный цикл программного обеспечения

101

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

•хранение в БД управления конфигурацией полных хроноло­ гий версий каждого объекта, созданного или измененного в процессе разработки системы (к ним относятся исходный программный код, библиотеки, исполняемые программы, модели, документация, тесты, web-страницы и каталоги);

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

•контроль изменений, вносимых во все объекты системы;

•сборка версий ПО из компонентов проекта.

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

Средства контроля изменений обычно используются в комп­ лексе со средствами управления требованиями. Поступающее требование или замечание проходит четыре этапа обработки:

•регистрация — внесение замечания в базу данных;

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

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

•приемка — приемка работ и снятие их с контроля или нап­ равление на доработку

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

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

102

Глава 1

программно-технологическими интерфейсами между отдельны­ ми инструментальными средствами.

!Следует запомнить

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

2.Одним из базовых понятий программной инженерии явля­ ется понятие жизненного цикла программного обеспечения (ЖЦ

ПО). Жизненный цикл программного обеспечения определяется к период времени, который начинается с момента принятия реше­ ния о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.

3.Подмоделью ЖЦПО nonvLUdi^TQ^ структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ. Наиболее распространен­ ными моделями являются каскадная и итерационная,

4.Зрелость процессов ЖЦПО — это степень их управляемости, контролируемости и эффективности. Повышение технологичес­ кой зрелости означает потенциальную возможность возрастания устойчивости процессов и указывает на степень эффективности и согласованности использования процессов создания и сопро­ вождения ПО в рамках всей организации.

^ Основные понятия

Нормативно-методическое обеспечение, жизненный цикл профаммного обеспечения, процессы жизненного цикла, мо­ дель ЖЦ ПО, стадия процесса создания ПО, каскадная модель, итерационная модель, зрелость процессов.

?Вопросы для самоконтроля

1.Что такое жизненный цикл программного обеспечения? 2. Чем регламентируется ЖЦ ПО?

3. Какие фуппы процессов входят в состав ЖЦ ПО и какие процессы входят в состав каждой группы?

4.Какие из процессов, по вашему мнению, наиболее часто используются в реальных проектах, какие в меньшей степе­ ни и почему?

Жизненный цикл программного обеспечения

103

5.Какие стадии входят в процесс создания ПО?

6.Каково соотношение между стадиями и процессами ЖЦ ПО?

7.Каковы принципиальные особенности каскадной моде­ ли?

8.В чем заключаются преимущества и недостатки каскадной модели?

9.Каковы принципиальные особенности итерационной мо­ дели?

10.В чем состоят преимущества и недостатки итерационной модели?

11.Каким образом можно добиться повышения уровня зре­ лости процессов создания ПО?

12.Какую роль в повышении уровня зрелости ифают процес­ сы управления требованиями и управления конфигура­ цией ПО?

I «f l#%E#jr^ mm

i.-^4^**4 V«K!4V-. .

МЕТОДИЧЕСКИЕ АСПЕКТЫ ПРОЕКТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Прочитав эту главу, вы узнаете:

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

•Что представляет собой структурный подход к анализу и про­ ектированию ПО,

•В чем заключается метод функционального моделирования SADT.

•Как строятся диаграммы потоков данных и диаграммы «сущ­ ность — связь».

•Что представляет собой объектно-ориентированный подход к анализу и проектированию ПО.

•В чем заключаются основные особенности языка моделирова­ ния UML.

•Как строятся модели и диаграммы, входящие в состав UML.

•Что представляют собой образцы.

2 . 1 . ОБЩИЕ ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ СИСТЕМ

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

Методические аспекты проектирования ПО

105

тей меньшего размера, и т.д., до тех пор, пока самые небольшие части можно будет строить из имеющегося материала. Этот под­ ход известен под самыми разными названиями, среди них такие, как «разделяй и властвуй» {divide et impera), иерархическая деком­ позиция и др. По отношению к проектированию сложной прог­ раммной системы это означает, что ее необходимо разделить (де­ композировать) на небольшие подсистемы, каждую из которых можно разрабатывать независимо от других. Это позволяет при разработке подсистемы любого уровня иметь дело только с ней, а не со всеми остальными частями системы. Правильная декомпо­ зиция является главным способом преодоления сложности раз­ работки больших систем ПО. Понятие «правильная» по отноше­ нию к декомпозиции означает следующее:

•количество связей между отдельными подсистемами долж­ но быть минимальным (принцип «слабой связанности» — Low Coupling);

•связность отдельных частей внутри каждой подсистемы должна быть максимальной (принцип «сильного сцепле­ ния» - High Cohesion).

Более подробно эти принципы будут рассмотрены в рамках объектно-ориентированного анализа (подразд. 4.3.2).

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

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

•каждая подсистема должна иметь четко определенный ин­ терфейс с другими подсистемами.

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

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

элементами. Второй, объектно-ориентированный подход, исполь-

106

Глава 2

зует объектную декомпозицию. При этом структура системы описывается в терминах объектов и связей между ними, а поведе­ ние системы описывается в терминах обмена сообщениями меж­ ду объектами.

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

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

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

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

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

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

Методические аспекты проектирования ПО

107

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

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

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

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

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

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

108

Глава 2

2.2. ВИЗУАЛЬНОЕ МОДЕЛИРОВАНИЕ

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

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

Модель должна давать полное, точное и адекватное описание системы, имеющее конкретное назначение. Это назначение, на­ зываемое целью модели, вытекает из формального определения модели:

М есть модель системы S, если М может быть использов для получения ответов на вопросы относительно S с точност

Таким образом, целью модели является получение ответов на некоторую совокупность вопросов. Эти вопросы неявно присут­ ствуют (подразумеваются) в процессе анализа и, следовательно, они руководят созданием модели и направляют его. Это означает, что сама модель должна будет дать ответы на эти вопросы с задан­ ной степенью точности. Если модель отвечает не на все вопросы или ее ответы недостаточно точны, то говорят, что модель не дос­ тигла своей цели.

Методические аспекты проектирования ПО

109

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

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

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

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

110

Глава 2

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

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

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

•поведение элементов системы в процессе их взаимодей­ ствия;

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

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

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

•планы этажей;

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

•планы монтажа кабельной проводки;

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

•вид здания на фоне местности (эскизы).

Архитектура ПО также предусматривает различные представ­ ления, служащие разным целям:

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

•отображению логической организации системы;

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

•отображению структуры потоков управления и аспектов па­ раллельной работы;

•описанию физического размещения программных компо­ нентов на базовой платформе.

Архитектурное представление — это упрощенное описани (абстракция) системы с конкретной точки зрения, охватывающее