Вендров А.М. Проектирование программного обеспечения экономических информационных систем

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

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

Наиболее развитые современные средства управления кон-

фигурацией и изменениями ПО обладают следующими возмож-

ностями:

• хранение

в БД

управления конфигурацией полных хроноло-

гий версий каждого объекта, созданного или измененного в

процессе разработки системы (к ним относятся исходный

программный код, библиотеки, исполняемые программы,

модели, документация, тесты, web-страницы и каталоги);

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

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

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

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

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

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

же объект, давая разработчикам

то же время возможность рабо-

тать с собственными версиями общего объекта с разрешением

конфликтов между ними.

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

лексе со средствами управления требованиями. Поступающее

требование или замечание проходит четыре этапа обработки:

• регистрация

—

внесение замечания в базу данных;

• распределение

—

назначение ответственного исполнителя и

сроков исполнения;

• исполнение

—

устранение замечания, которое, в свою оче-

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

вания на дополнительные работы;

• приемка

—

приемка работ и снятие их с контроля или нап-

равление на доработку

Отчетные возможности включают множество разновиднос-

тей графиков

диафамм, отражающих состояние проекта, срезы

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

щикам. С

их

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

ты над проектом

динамику ее развития.

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

означает обеспечение целостности проекта

контроля за его сос-

тоянием, что является жизненно важным в условиях разобщен-

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

екта. Это предполагает наличие единой технологической среды

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

102 Глава 1

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

ми инструментальными средствами.

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

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

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

различные аспекты процессов деятельности разработчиков.

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

ется понятие жизненного цикла программного обеспечения (ЖЦ

ПО).

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

определяется как

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

ния о необходимости создания ПО и заканчивается в момент его

полного изъятия из эксплуатации.

Подмоделью

ЖЦ

ПО

nonvLUdi^TQ^

структура, определяющая

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

действий и задач на протяжении ЖЦ. Наиболее распространен-

ными моделями являются

каскадная и

итерационная,

Зрелость

процессов ЖЦ

ПО —

это степень

их

управляемости,

контролируемости и эффективности. Повышение технологичес-

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

устойчивости процессов

указывает на степень эффективности и

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

вождения ПО в рамках всей организации.

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

Нормативно-методическое обеспечение, жизненный цикл

профаммного обеспечения, процессы жизненного цикла, мо-

дель ЖЦ ПО, стадия процесса создания ПО, каскадная модель,

итерационная модель, зрелость процессов.

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

Что такое жизненный цикл программного обеспечения?

Чем регламентируется ЖЦ ПО?

Какие фуппы процессов входят в состав ЖЦ ПО и какие

процессы входят в состав каждой группы?

Какие из процессов, по вашему мнению, наиболее часто

используются

реальных проектах, какие

меньшей степе-

ни и почему?

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

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

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

ПО?

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

ли?

чем заключаются преимущества

недостатки каскадной

модели?

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.

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

Под

моделью

ПО в общем случае понимается формализован-

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

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

зует набор диаграмм и документов заданного формата, а также

отражает точку зрения

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

ных

людей с конкретными интересами, ролями или задачами.

Под термином

«моделирование»

понимается процесс создания

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

лей. Особенно трудным оказывается описание систем средней

сложности, таких, как система коммутаций в телефонных сетях,

управление авиаперевозками или движением подводной лодки,

сборка автомобилей, челночные космические рейсы, функциони-

рование перерабатывающих предприятий

(к таким

системам отно-

сится

ПО).

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

описать

доста-

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

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

связями, и

в то же

время недостаточно велики

для

применения об-

щих упрощающих предположений (как это принято в физике).

Неспособность дать простое описание, а, следовательно, и обеспе-

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

ние трудоемким

дорогостоящим процессом и повышает степень

их ненадежности. С ростом технического прогресса адекватное

описание систем становится все более актуальной проблемой.

Модель должна давать полное, точное и адекватное описание

системы, имеющее конкретное назначение. Это назначение, на-

зываемое

целью

модели,

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

модели:

есть модель системы

если

может быть использована

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

с точностью

А.

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

некоторую совокупность вопросов. Эти вопросы неявно присут-

ствуют (подразумеваются) в процессе анализа и, следовательно,

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

его.

Это означает,

что

сама модель должна будет дать ответы на

эти

вопросы

задан-

ной степенью точности. Если модель отвечает не на все вопросы

или ее ответы недостаточно точны, то говорят, что модель

не

дос-

тигла своей цели.

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

По мнению авторитетных специалистов

области проектиро-

вания ПО, моделирование является центральным звеном

всей

де-

ятельности по созданию систем ПО. Модели строятся для того,

чтобы понять

осмыслить структуру

поведение будущей систе-

мы,

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

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

ектные решения.

Визуальное моделирование

~ это способ восприятия проблем с

помощью зримых абстракций, воспроизводящих понятия и объ-

екты реального мира. Модели служат полезным инструментом

анализа проблем, обмена информацией между всеми заинтересо-

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

предмет-

ной области, аналитиками, проектировщиками и т.д.), проекти-

рования ПО, а также подготовки документации. Моделирование

способствует более полному усвоению требований, улучшению

качества системы и повышению степени ее управляемости.

С помощью модели можно упростить проблему, отбросив не-

существенные детали и сосредоточив внимание на

главном.

Спо-

собность к абстрагированию - это фундаментальное свойство че-

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

сложности. На протяжении тысяч лет художники, ремесленники

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

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

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

ПО.

Чтобы создать сложную программную систему, разработчи-

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

помощью точных нотаций (систем обозначений) сконструиро-

вать адекватные модели, удостовериться, удовлетворяют ли они

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

постепенно пополняя систему новыми функциями.

К моделированию сложных систем приходится прибегать

ввиду

того,

что мы не в состоянии постичь их единовременно во

всей полноте. Способность человека к восприятию сложных ве-

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

обратившись к сфере строительства и архитектуры. Если нужно

построить курятник, за работу можно приняться тотчас; если

речь идет о новом

доме,

тогда, вероятно, потребуется хотя бы эс-

киз;

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

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

и в мире программирования. Делая главную ставку на написание

110 Глава 2

строк исходного кода или даже на использование форм Visual

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

тить структуру объемного проекта

целом. Предварительное мо-

делирование,

свою очередь, позволяет проектировщику увидеть

общую картину взаимодействий компонентов проекта без необ-

ходимости анализа особых свойств каждого компонента.

Графические (визуальные) модели

представляют собой средства

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

ния архитектуры системы. Под

архитектурой

понимается набор

основных правил, определяющих организацию системы:

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

между ними;

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

ствия;

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

ты;

• архитектурный стиль (используемые методы

средства опи-

сания архитектуры, а также архитектурные образцы).

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

специалисты работают с различными ее аспектами. Например,

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

представляющие различные аспекты архитектуры:

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

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

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

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

вентиляции;

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

Архитектура ПО также предусматривает различные представ-

ления, служащие разным целям:

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

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

• описанию физической структуры программных компонен-

тов в среде реализации;

• отображению структуры потоков управления и аспектов па-

раллельной работы;

• описанию физического размещения программных компо-

нентов на базовой платформе.

Архитектурное представление —

это упрощенное описание

(абстракция) системы с конкретной точки зрения, охватывающее