Лаврищева Е.М., Петрухин В.А. Методы и средства инженерии программного обеспечения

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

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

затраты;

– инженеры службы хранения готовых компонентов;

– технологи, которые определяют инженерные методы и стандарты,

регламентирующие и регулирующие процесс построения программных проектов;

– тестировщики, которые проверяют правильность выполнения процессов, сбор

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

Инструменты поддержки разработки ПО совершили гигантский скачок в своем

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

современных визуальных и диаграммных средств UML.

Таким образом, возникновение программной инженерии определено следующими

факторами:

– появление разнообразных сложных методов анализа и моделирования ПО;

– большое количество ошибок в ПО;

– необходимость в эффективной организации работы коллективов разработчиков ПО;

– повторное использование готовых программных компонентов и

высокотехнологических средств разработки и управления ПО;

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

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

Материал данного учебного курса по программной инженерии разработан с учетом

методов и средств ядра знаний SWEBOK. Он предназначен студентам, изучающим

компьютерное дело, менеджерам коллективов программных проектов, желающих

повысить уровень своей квалификации по планированию и управлению, а также

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

Данный учебник состоит из тем по методам и средствам программной инженерии,

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

компьютерных систем. В конце каждой темы приводятся и контрольные вопросы и

задания, а также используемая литература.

Тема 1. Введение в программную инженерию и процессы жизненного цикла. Дано

определение программной инженерии, ее место в инженерной деятельности

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

знаний профессионального ядра знаний SWEBOK.

Тема 2. Модели жизненного цикла для разработки программных систем.

Описываются основные модели ЖЦ, которые используются в практике проектирования

программных систем. Дана характеристика фундаментальных моделей ЖЦ

(водопадной, спиральной, инкрементной, эволюционной) и стандартной модели.

Тема 3. Методы определения требований в программной инженерии. Приведены

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

спецификации требований. Дана классификация требований и характеристика

функциональных и нефункциональных

требований.

Тема 4. Методы анализа и построения моделей ПрО. Приведены методы анализа

предметной области и построения моделей. Рассмотрены объектно–ориентированные

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

Тема 5. Методы проектирования программных систем. Представлено описание

базовых основ методов систематического (структурного, компонентного, аспектно–

ориентированного и др.) и теоретического (алгебраического, композиционного и

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

практикой проектирования ПС.

Тема 6. Инженерия приложений и инженерия предметной области. Излагаются

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

производства одиночных ПС из ПИК и инженерии ПрО с многоразовым применением

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

Тема 7. Методы верификации и тестирования программ и систем. Посвящена

описанию методов проверки правильности программ: формальным методам

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

ПС на этапах ЖЦ.

Тема 8. Методы интеграции, преобразования и изменения компонентов и данных.

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

методы изменения (реинженерия, реверсная инженерия и рефакторинга) компонентов

и систем.

Тема 9. Модели качества и надежности в программной инженерии. Посвящена

представлению моделей качества ПС, метрикам и методам достижения и измерения

качества ПС. Рассмотрен основной показатель качества – надежность, дано описание

математических моделей надежности и способов их применения на практике.

Тема 10. Методы управления проектом, риском и конфигурацией. Проведен анализ и

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

управления программным проектом, рисками и формированием версий ПС.

Тема 11. Средства и инструменты программной инженерии. Дан обзор современных

средств

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

(Project Management, Rational Rose, MSF, RUP, CORBA, DCOM и др.), при объектно–

ориентированном проектировании ПС.

Приложение 1. Набор основных терминов, используемых в программной инженерии.

Приложение 2. Характеристика стандартов разработки автоматизированных систем.

Приложение 3. Жизненный цикл компонентной разработки ПС.

Приложение 4. Кодекс этики в программной инженерии.

Приложение 5. Стандарты в программной инженерии.

Тема 1

ВВЕДЕНИЕ В ПРОГРАММНУЮ ИНЖЕНЕРИЮ И ЖИЗНЕННЫЙ ЦИКЛ

ПО

Разработка и использование компьютерных программ в настоящее время стало

массовой деятельностью. Более семи миллионов человек занимаются их разработкой,

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

[1]. Практически нет ни одной сферы деятельности (экономика, медицина, бизнес,

коммерция, промышленность и

т.д.), где бы программное обеспечение (ПО) не

использовалось для автоматизации и улучшения этой деятельности. Спрос на ПО

постоянно увеличивается, его сложность растет, а ошибки в ПО остаются.

Знания разработчиков ПО отличаются большим разнообразием, и, как правило, они

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

реализацию разных предметных областей

, начиная от ОС и кончая современными

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

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

поспевают программисты.

Примерно каждые 10 лет происходит смена языков программирования и

операционных сред для описания и функционирования программ. Это предполагает

изменение ранее изготовленных и функционирующих программ в новые языки и

операционные среды. На это тратятся огромные людские и финансовые ресурсы. Так,

при изменении формата даты (2000 год) в программах и микросхемах на десятках

млн. компьютеров участвовало более 2 млн. программистов, а затраты составили

сотни млн. долларов. Переделка (реинженерия) ранее созданных прикладных Фортран

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

капиталовложений и привлечения программистов из третьих стран и СНГ.

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

компьютеров, а также Фреймворков с усовершенствованными ОС и средствами

интероперабельности в программистском мире возникли большие сложности,

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

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

и поступают на рынок, как продукт для продажи (сидиромы, кассеты и т.п.).

Процесс формирования знаний в информатике и Computer Science послужил толчком

для формирования самого претенциозного проекта 90-х годов в истории развития

вычислительной техники – японский проект ЭВМ 5 поколения, который должен был

сделать переворот в области проектирования и программирования ПО [2]. В этом

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

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

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

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

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

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

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

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

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

автоматизации постановок задач.

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

компонентов (Reusing) и систем, теоретически и практически осуществляется с учетом

современных возможностей платформ и распределенных сред, в которых компоненты

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

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

объектно-ориентированный, компонентный, аспектный, визуальный – UML, агентно-

ориентированный, сервисный и др. [3-13].

Разработано огромное количество разнообразных инструментальных средств

поддержки процесса проектирования ПО и методов оценки качества,

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

продукта, процессов ЖЦ стандартизованы (ISO/IEC 12207 [14], 15504 [15], ISO

9126[16-18] и др.). Все это способствует повышению уровня проектирования,

тестирования, прогнозирования надежности и

оценки качества ПО.

Вместе с тем, новый программный проект разрабатывается 1-2 года, а

эволюционирует 6-7лет. На его сопровождение тратиться 61% затрат против 39% на его

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

в отношении 20:200, отсюда требуется повышать уровень знаний разработчиков ПО.

На сегодня ядро стабильных знаний по программной инженерии составляет 75% от тех

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

В связи с этим мировое компьютерное сообщество пришло к необходимости

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

знаний (Body of Knowledge – BOK) для разных областей информатики [19]. Для

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

объединении компьютерных специалистов ACM (Association for Computing

Machinery) и институте инженеров по электронике и электротехнике IEEE Computer

Society. В комитет вошли специалисты мирового уровня в области информатики и

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

накопленные разнородные знания и определили (1999г., 2001г., 2004г.) ядро

профессиональных знаний SWEBOK (Software Engineering Body Knowledge)

программной инженерии [20], как основы проектирования ПО. Ядро включает сумму

знаний, распределенную по 10 специализированным областям, которые отражают

отдельные процессы проектирования ЖЦ ПО и методы их поддержки.

Программная инженерия (Software Engineering) является отраслью Computer science,

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

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

регламентации инженерной деятельности разработчиков ПО. В этом определении

важно рассмотреть два основных аспекта.

1. Инженерная дисциплина, по которой инженеры применяя теоретические идеи,

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

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

2. Аспекты создания ПО. Программная инженерия рассматривает такие аспекты ПО

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

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

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

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

творческий неформальный подход к созданию ПО.

Как инженерная дисциплина, она охватывает все аспекты создания ПО, начиная от

формирования требований до создания, сопровождения и снятия с эксплуатации ПО, а

также включает инженерные методы оценки трудозатрат, стоимости,

производительности и качества. Т.е. речь идет именно об инженерной деятельности в

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

деятельности в толковом словаре [2]:

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

свойств материалов и источников энергии;

2) как деятельность по созданию машин для предоставления полезных услуг.

В программной инженерии, инженеры – это специалисты, выполняющие практические

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

компьютерной науки. Компьютерная наука (computer science) охватывает теорию и

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

инженерия рассматривает вопросы практического построения ПО. Знание

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

так же, как знание физики – инженерам-электронщикам. Если для решения конкретных

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

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

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

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

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

В отличие от науки, целью которой есть получение знаний, для инженерии знание –

это способ получения некоторой пользы. Как говорил известный специалист в области

программой техники Ф.Брукс], «ученый строит, чтобы научиться, инженер учится,

чтобы строить».

Таким образом, разработка программных систем можно считать инженерной

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

которой:

– ветви инженерии имеют высокую степень специализации, а у программной

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

операционные системы, трансляторы);

– объекты хорошо определены и манипуляции с ними происходят в узком контексте

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

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

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

– отдельные готовые решения классифицированы и каталогизированы, а в

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

довольно тяжело рассмотреть аналогию с ранее разработанными системами.

Указанные отличия требуют проведения организационных и технических работ для

превращения ее в специальность. В настоящее время мировая компьютерная

общественность объединились в профессиональные комитеты и проводят такие

работы: разработка ядра знаний SWEBOK, этического кодекса программиста [13],

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

сертификация специалистов в области программной инженерии и др.

Следующим шагом деятельности этих организаций и комитетов является создание

общей компьютерной программы обучения – Curricula 2001 [8]. В ней содержатся

рекомендации по структуре и преподаванию 15 учебных курсов по информатике

(дискретные системы, программирование, теория сложности, ОС и др.) в том числе и

по программной инженерии, как дисциплины, изучающей теорию, знания и практику

эффективного построения ПО на всех этапах ЖЦ, которым соответствуют области

знаний в SWEBOK.

В разработке больших программных проектов, кроме программистов, принимают

участие:

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

затраты;

– инженеры службы хранения готовых компонентов в библиотеках и репозитариях;

– технологи, которые определяют инженерные методы и стандарты,

регламентирующие и регулирующие процесс реализации проекта;

– тестировщики (контролеры), которые проверяют правильность выполнения процесса

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

измерения разных характеристик качества, включая оценку надежности ПО.

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

ПО определено следующими важными факторами:

– накопленным значительным объемом интеллектуальных знаний в области создания

ПО;

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

проектирования ПО;

– необходимостью совершенствования методов обнаружения ошибок в ПО;

– потребностями эффективной организации коллективов разработчиков ПО и оценки

их деятельности;

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

средств и инструментов разработки ПО;

– реинженерией компонентов и систем для их адаптации к новым изменяющимся

условиям сред и сетей

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

повышение качества и производительности ПО за счет применения новых и

усовершенствованных: методов проектирования ПО; готовых компонентов и методов

их генерации; методов эволюции ПО; методов верификации и тестирования ПО;

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

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

п.; стандартизации процессов

разработки ПО (ISO/IEC 12207, ISO/IEC 15504, ISO 9126 и др.), регламентирующих

этапы ЖЦ; подходов к оценке продуктов и процессов.

В данном разделе темы лекций дается систематическое изложение следующих

взаимосвязанных аспектов в инженерии проектировании ПО:

– теоретический и интеллектуальный базис (методы, принципы, средства и

методологии и др.) проектирования, представленный в ядре SWEBOK,

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

удовлетворяющих заданным заказчиком функциональных и нефункциональных

требований;

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

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

разработчиков ПО и организационные мероприятия по выполнению процессов

верификации, валидации, тестирования, метрического анализа и оценки

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

– концепции обучения разработчиков ПО методам и средствам программной

инженерии, стандартным процессам ЖЦ с целью научить их методологии

проектирования ПО, использующей знания в области программной инженерии и

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

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

проекта.

1. Анализ и характеристика областей знаний SWEBOK

Ядра знаний SWEBOK [20] является основополагающим документом, отображает

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

инженерии [3-13] и согласуется с современными регламентированными процессами

ЖЦ ПО стандарта ISO/IEC 12207. В этом ядре знаний содержится описание 10

областей, каждая

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

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

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

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

должен практически использоваться на соответствующих процессах ЖЦ с учетом

приведенного стандарта.

Для наглядного представления понятийного аппарата

областей SWEBOK проведено

условное разбиение областей (рис. 1.а, б.) на основные (пять процессов

проектирования ПС) и дополнительные, организационные методы и подходы, которые

отображают инженерию управления проектированием ПС (конфигурацией, проектами,

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

проектирования разных типов ПС. Данное разбиение областей на главные и

вспомогательные области соответствует структуре процессов стандарта ISO/IEC 12207

(см. подраздел 2), выполнение которых определяется знаниями, содержащимися в

ядре SWEBOK и изученными разработчиками ПС.

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

SWEBOK, их назначение и роль при проектировании и реализации программных

продуктов.

В некоторых разделах данной главы показана связь с положениями соответствующих

стандартов, которые регламентируют и регулируют выполнение процессов

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

1.1. Основы программных требований (Software Requirements)

Требования – это свойства, которыми должно обладать ПО для адекватного задания

функций, а также условия и ограничения на ПО, данные, среду выполнения и технику.

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

заинтересованных в создании ПО. Заказчик и разработчик совместно проводят сбор

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

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

функциональные и нефункциональные требования, системные требования.

Программные требования определяют требования к процессу, ОС, режиму выполнения

ПО, выбору платформы и т.п.

Функциональные требования задают назначение системы, а нефункциональные –

условия выполнения ПО. Системные требования описывают требования к

программной системе, состоящей из взаимосвязанных программных и аппаратных

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

(например, количество запросов в сек., средний показатель ошибок не должен

превышать 1.5% от объема вводимой информации и т.п.). Значительная часть

требований относится к атрибутам качества: безотказность, надежность и др.

Область знаний «Требования к ПО (Software Requirements)» состоит из следующих

разделов:

– инженерия требований (Requirement Engineering),

– выявление требований (Requirement Elicitation),

– анализ требований (Requirement Analysis),

– спецификация требований (Requirement Specification).

– проверка требований (Requirement validation),

– управление требованиями (Requirement Menegement).

Инженерия требований к ПО – это дисциплина анализа и документирования

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

требований к системе в описание требований к ПО, их спецификация и верификация.

Она базируется на модели процесса определения требований, процессах актеров –

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

на процессах повышения качества.

Модель процесса – это схема процессов ЖЦ, которые выполняются от начала проекта

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

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

проекте.

Управление требованиями к ПО заключается в планировании и контроле выполнения

требований и проектных ресурсов в процессе разработки компонентов на этапах ЖЦ.

Качество и процесс улучшения требований – это

процесс формулировки характеристик

и атрибутов качества (надежность, реактивность и др.), которыми должна обладать

система и ПО, методы их достижения на этапах ЖЦ и адекватности процессов работы с

требованиями.

Выявление требований – это процесс извлечения информации из разных источников

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

проведения

технических мероприятий (собеседований, собраний и др.) для

формирования отдельных требований на разработку. Требования согласуются с

заказчиком и исполнителем.

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

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

установление и разрешение конфликтов между требованиями, определение

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

функционирования. Требования могут быть функциональные и нефункциональные,

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

системы. Функциональные требования характеризуют функции системы или ее ПО,

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

преобразования входных данных в результаты. Нефункциональные требования

определяют условия и среду выполнения функций (например, защита и доступ к БД,

секретность, взаимодействие компонентов и др.). Разработка требований и их

локализация завершается на этапе проектирования архитектуры и отражается в

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

достижения взаимопонимания между заказчиком и разработчиком.

Спецификация требований к ПО – процесс формализованного описания

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

качества в соответствии со стандартом качества ISO/IEC 9126-94, которые будут

отрабатываться на этапах ЖЦ ПО. В спецификации требований отражается структура

ПО, требования к функциям, качеству и документации, а также задается в общих

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

Специфицируются также системные требования, нефункциональные требования и

требования к взаимодействию с другими компонентами и платформами (БД, СУБД,

маршаллинг данных, сеть и др.).

Валидация (аттестация) требований - это проверка требований, изложенных в

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

отслеживание источников требований. Заказчик и разработчик ПО проводят

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

проводить разработку ПО. Верификация требований – это процесс проверки

правильности спецификаций требований на их соответствие, непротиворечивость,

полноту и выполнимость, а также на соответствие стандартам. В результате проверки

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

корректность требований к ПО, а также возможность продолжить проектирование ПО.

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

отдельных требований на конкретном инструменте и исследование масштабов

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

создание моделей оценки зрелости требований.

Управление требованиями – это руководство процессами формирования требований

на всех этапах ЖЦ, которое включает управление изменениями и атрибутами

требований, отражающими программный продукт, а также проведение мониторинга –

восстановления источника требований. Неотъемлемой составляющей процесса

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

задания и реализации требований к системе и ПО на этапах ЖЦ и обратный процесс

отслеживания от полученного продукта к требованиям.

Таким образом, приведено краткое изложение сущности определения требований к

ПО, базовых понятий и процессов их формирования, подходов к их оценке на предмет

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

достижения их качества.

1. 2. Проектирование ПО (Software design)

Проектирование ПО – процесс определения архитектуры, компонентов, интерфейсов,

других характеристик системы и конечного результата.

Область знаний «Проектирование ПО (Software Design)» состоит из следующих

разделов:

– базовые концепции проектирования ПО (Software Design Basic Concepts),

– ключевые вопросы проектирования ПО (Key Issue in Software Design),

– структура и архитектура ПО (Software Structure and Architecture),

– анализ и оценка качества проектирования ПО (Software Design Quality Analysis and

Evaluation),

– нотации проектирования ПО (Software Design Notations),

– стратегия и методы проектирования ПО (Software Design Strategies and Methods).

К базовым концепциям проектирования ПО относятся процессы ЖЦ (стандарт

ISO/IEC 12207), процесс проектирования архитектуры с использованием разных

принципов (объектного, компонентного и др.) и техник: абстракции, декомпозиции,

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

компоненты, выбираются необходимые артефакты (нотации, методы и др.)

программной инженерии и строится архитектура ПО.

К ключевым вопросам проектирования ПО относятся: декомпозиция на

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

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

собой, механизмы обеспечения качества и живучести системы и др.

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

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

подсистем, компонентов и связей между ними.

Архитектура проекта – высокоуровневое представление структуры, задаваемое с

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

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

проведения работ по кодированию, и связей между ними. Существуют и другие виды

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

их каркасов.

Паттерн – это конструктивный элемент ПО, который задает взаимодействие объектов

(компонентов) проектируемой системы, определение ролей и ответственности

исполнителей. Основным языком задания этого элемента является UML.

Паттерн может быть: структурным, в котором определяются типовые композиции

структур из объектов и классов диаграммами классов, объектов, связей и др.;

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

поведение диаграммами активностей, взаимодействия, потоков управления и др.;

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

объектов диаграммами взаимодействия, кооперации и др.

Анализ и оценка качества проектирования ПО включает мероприятия по анализу

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

– размера и структуры ПО, функций и качества проектирования с помощью

формальных метрик (функционально-ориентированных, структурных и объектно-

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

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

Нотации проектирования позволяют представить артефакты ПО и его структуру, а

также поведение системы.

Существует два типа нотаций: структурные, поведенческие

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

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

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

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