2015-04-30
1321
Нормативно-методическое обеспечение, жизненный цикл программного обеспечения, процессы жизненного цикла, модель ЖЦ ПО, стадия процесса создания ПО, каскадная модель, итерационная модель, зрелость процессов.
? Вопросы для самоконтроля
1. Что такое жизненный цикл программного обеспечения?
2. Чем регламентируется ЖЦ ПО?
3. Какие группы процессов входят в состав ЖЦ ПО и какие процессы входят в состав каждой группы?
4. Какие из процессов, по вашему мнению, наиболее часто используются в реальных проектах, какие в меньшей степени и почему?
5. Какие стадии входят в процесс создания ПО?
6. Каково соотношение между стадиями и процессами ЖЦ ПО?
7. Каковы принципиальные особенности каскадной модели?
8. В чем заключаются преимущества и недостатки каскадной модели?
9. Каковы принципиальные особенности итерационной модели?
10. В чем состоят преимущества и недостатки итерационной модели?
11. Каким образом можно добиться повышения уровня зрелости процессов создания ПО?
12. Какую роль в повышении уровня зрелости играют процессы управления требованиями и управления конфигурацией ПО?
|
|
|
ГЛАВА 2
МЕТОДИЧЕСКИЕ АСПЕКТЫ
ПРОЕКТИРОВАНИЯ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Прочитав эту главу, вы узнаете:
· В чем заключаются общие принципы проектирования систем и что такое визуальное моделирование.
· Что представляет собой структурный подход к анализу и проектированию ПО.
· В чем заключается метод функционального моделирования SADТ.
· Как строятся диаграммы потоков данных и диаграммы «сущность — связь».
· Что представляет собой объектно-ориентированный подход к анализу и проектированию ПО.
· В чем заключаются основные особенности языка моделирования UML.
· Как строятся модели и диаграммы, входящие в состав UML.
· Что представляют собой образцы.
2.1.
ОБЩИЕ ПРИНЦИПЫ ПРОЕКТИРОВАНИЯ
СИСТЕМ
Как было отмечено ранее, одной из основных проблем, которые приходится решать при создании больших и сложных систем любой природы, в том числе и ПО, является проблема сложности. Ни один разработчик не в состоянии выйти за пределы человеческих возможностей и понять всю систему в целом. Единственный эффективный подход к решению этой проблемы, который выработало человечество за всю свою историю, заключается в построении сложной системы из небольшого количества крупных частей, каждая из которых, в свою очередь, строится из частей меньшего размера, и т.д., до тех пор, пока самые небольшие части можно будет строить из имеющегося материала. Этот подход известен под самыми разными названиями, среди них такие, как «разделяй и властвуй» (divide et impera), иерархическая декомпозиция и др. По отношению к проектированию сложной программной системы это означает, что еенеобходимо разделить (декомпозировать) на небольшие подсистемы, каждую из которых можно разрабатывать независимо от других. Это позволяет при разработке подсистемы любого уровня иметь дело только с ней, а не со всеми остальными частями системы. Правильная декомпозиция является главным способом преодоления сложности разработки больших систем ПО. Понятие «правильная» по отношению к декомпозиции означает следующее:
|
|
|
· количество связей между отдельными подсистемами должно быть минимальным (принцип «слабой связанности» — Low Coupling);
· связность отдельных частей внутри каждой подсистемы должна быть максимальной (принцип «сильного сцепления» — High Cohesion).
Более подробно эти принципы будут рассмотрены в рамках объектно-ориентированного анализа (подразд. 4.3.2).
Структура системы должна быть такой, чтобы все взаимодействия между ее подсистемами укладывались в ограниченные, стандартные рамки, т.е.:
· каждая подсистема должна инкапсулировать свое содержимое (скрывать его от других подсистем);
· каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами.
Инкапсуляция (принцип «черного ящика») позволяет рассматривать структуру каждой подсистемы независимо от других подсистем. Интерфейсы позволяют строить систему более высокого уровня, рассматривая каждую подсистему как единое целое и игнорируя ее внутреннее устройство.
Существуют два основных подхода к декомпозиции систем. Первый подход называют функционально-модульным, он является частью более общего структурного подхода. В его основу положен принцип функциональной декомпозиции, при которой структура системы описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами. Второй, объектно-ориентированный подход, использует объектную декомпозицию. При этом структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами.
В 1970—1980 годах при разработке ПО достаточно широко применялись структурные методы, предоставляющие в распоряжение разработчиков строгие формализованные методы описания проектных решений — спецификаций ПО (в настоящее время такое же распространение получают объектно-ориентированные методы). Эти методы основаны на использовании наглядных графических моделей: для описания архитектуры ПО с различных точек зрения (как статической структуры, так и динамики поведения системы) используются схемы и диаграммы. Наглядность и строгость средств структурного и объектно-ориентированного анализа позволяет разработчикам и будущим пользователям системы с самого начала неформально участвовать в ее создании, обсуждать и закреплять понимание основных технических решений. Однако широкое применение этих методов и следование их рекомендациям при разработке конкретных систем ПО сдерживалось отсутствием адекватных инструментальных средств, поскольку при неавтоматизированной (ручной) разработке все их преимущества практически сведены к нулю. Действительно, вручную очень трудно разработать и графически представить строгие формальные спецификации системы, проверить их на полноту и непротиворечивость и тем более изменить. Если все же удается создать строгую систему проектных документов, то ее переработка при появлении серьезных изменений практически неосуществима. Ручная разработка обычно порождала следующие проблемы:
· неадекватная спецификация требований;
· неспособность обнаруживать ошибки в проектных решениях;
· низкое качество документации, снижающее эксплуатационные характеристики;
|
|
|
· затяжной цикл и неудовлетворительные результаты тестирования.
С другой стороны, разработчики ПО исторически всегда стояли последними в ряду тех, кто использовал компьютерные технологии для повышения качества, надежности и производительности в своей собственной работе (феномен «сапожника без сапог»).
Перечисленные факторы способствовали появлению программно-технологических средств специального класса - CASE-средств, реализующих CASE-технологию создания ПО. Понятие CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение этого понятия, ограниченное только задачами автоматизации разработки ПО, в настоящее время приобрело новый смысл, охватывающий большинство процессов жизненного цикла ПО.
Появлению CASE-технологии и CASE-средств предшествовали исследования в области программирования: разработка и внедрение языков высокого уровня, методов структурного и модульного программирования, языков проектирования и средств их поддержки, формальных и неформальных языков описаний системных требований и спецификаций и т.д. Кроме того, этому способствовали следующие факторы:
· подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;
· широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования;
· внедрение сетевой технологии, предоставившей возможность объединения усилий отдельных исполнителей в единый процесс проектирования путем использования разделяемой базы данных, содержащей необходимую информацию о проекте.
CASE-технология представляет собой совокупность методов проектирования ПО, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех стадиях разработки и сопровождения ПО и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методах структурного или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.
|
|
|
2.2.
