
- •1 Основы программной инженерии 6
- •2 Процессы жизненного цикла программного средства 33
- •3 Инструменты и методы программной инженерии 184
- •4 Качество и эффективность в программной инженерии 193
- •Введение
- •1Основы программной инженерии
- •1.1Кризисы программирования и возникновение программной инженерии
- •1.2Программная инженерия и сущность инженерного подхода к созданию программного обеспечения
- •1.3Системная инженерия программного обеспечения
- •1.4Управление жизненным циклом программных средств
- •1.4.1Понятие жизненного цикла
- •1.4.2Масштабы программных средств
- •1.4.3Классификация процессов жизненного цикла по исо/мэк 12207
- •1.4.4Стадии разработки программных средств по еспд
- •1.4.5Типичная схема управления процессом создания программного обеспечения
- •1.5Модели жизненного цикла
- •1.5.1Каскадная (водопадная) модель
- •1.5.2Итеративная и инкрементальная модель – эволюционный подход
- •1.5.3Спиральная модель
- •2Процессы жизненного цикла программного средства
- •2.1Управление требованиями к программному обеспечению
- •2.1.1Программные требования
- •2.1.1.1Пирамида требований
- •2.1.1.2Характеристики программных требований
- •2.1.2Процесс управления требованиями
- •2.1.3Извлечение требований
- •2.1.4Анализ программных требований
- •2.1.5Документирование требований
- •2.1.6Проверка требований (верификация и аттестация)
- •2.1.7Измерение программных требований
- •2.2Проектирование программных средств
- •2.2.1Принципы проектирования
- •2.2.2Структура и архитектура программного обеспечения
- •2.2.2.1Архитектурные структуры и точки зрения
- •2.2.2.2Архитектурные стили
- •2.2.2.3Шаблоны проектирования
- •2.2.2.4Семейства программ и фреймворков
- •2.2.3Анализ качества и оценка программного дизайна
- •2.2.3.1Атрибуты качества
- •2.2.3.2Анализ качества и техники оценки
- •2.2.3.3Измерения
- •2.2.4Нотации проектирования
- •2.2.4.1Структурные описания
- •2.2.4.2Поведенческие (динамические) описания
- •2.2.5Подходы и методы проектирования программного обеспечения
- •2.2.5.1Общие подходы
- •2.3Использование uml в программной инженерии
- •2.3.1Основные компоненты uml
- •2.3.2Диаграмма вариантов использования
- •2.3.3Диаграмма классов
- •2.3.4Диаграмма состояний
- •2.3.5Диаграмма деятельности
- •2.3.6Диаграмма последовательности
- •2.3.7Диаграмма кооперации
- •2.3.8Диаграмма компонентов
- •2.3.9Диаграмма развертывания
- •2.4Тестирование программного обеспечения
- •2.4.1Основы тестирования
- •2.4.2Уровни тестирования
- •2.4.2.1Над чем производятся тесты
- •2.4.2.2Цели тестирования
- •2.4.3Техники тестирования
- •3.1 Техники, базирующиеся на интуиции и опыте инженера (Based on the software engineer’s intuition and experience)
- •3.2 Техники, базирующиеся на спецификации (Specification-based techniques)
- •3.3 Техники, ориентированные на код (Code-based techniques)
- •3.4 Тестирование, ориентированное на дефекты (Fault-based techniques)
- •3.5 Техники, базирующиеся на условиях использования (Usage-based techniques)
- •3.6 Техники, базирующиеся на природе приложения (Techniques based on the nature of the application)
- •3.7 Выбор и комбинация различных техник (Selecting and combining techniques)
- •4.1 Оценка программ в процессе тестирования (Evaluation of the program under test, ieee 982.1-98)
- •2.4.4.2Оценка выполненных тестов
- •2.4.5Процесс тестирования
- •2.4.5.1Практические соображения
- •2.4.5.2Тестовые работы
- •2.5Сопровождение программного обеспечения
- •2.5.1Основы сопровождения программного обеспечения
- •2.5.1.1Определения и терминология
- •2.5.1.2Природа сопровождения
- •2.5.1.3Потребность в сопровождении
- •2.5.1.4Приоритет стоимости сопровождения
- •2.5.1.5Эволюция программного обеспечения
- •2.5.1.6Категории сопровождения
- •2.5.2Ключевые вопросы сопровождения программного обеспечения
- •2.5.2.1Технические вопросы
- •2.5.2.2Оценка стоимости сопровождения
- •2.5.2.3Измерения в сопровождении программного обеспечения
- •2.5.3Процесс сопровождения
- •2.5.3.1Процессы сопровождения
- •2.5.3.2Работы по сопровождению
- •2.5.4Техники сопровождения
- •2.5.4.1Понимание программных систем
- •2.5.4.2Реинжиниринг
- •2.5.4.3Обратный инжиниринг
- •2.6Конфигурационное управление
- •2.6.1Управление конфигурационным процессом
- •2.6.1.1Организационный контекст управления конфигурацией по
- •2.6.1.2Ограничения и правила управления конфигурацией по
- •2.6.1.3Планирование при управлении конфигурацией по
- •2.6.1.4План конфигурационного управления
- •2.6.1.5Контроль выполнения процесса управления конфигурацией по
- •2.6.2Идентификация программных конфигураций
- •2.6.2.1Идентификация элементов, требующих контроля
- •2.6.2.2Программная библиотека
- •2.6.3Контроль программных конфигураций
- •2.6.3.1Предложение, оценка и утверждение изменений
- •2.6.3.2Реализация изменений
- •2.6.3.3Отклонения и отказ от изменений
- •2.6.4Учет статусов конфигураций
- •2.6.4.1Информация о статусе конфигураций
- •2.6.4.2Отчетность по статусу конфигураций
- •2.6.5Аудит конфигураций
- •2.6.5.1Функциональный аудит программных конфигураций
- •2.6.5.2Физический аудит программных конфигураций
- •2.6.5.3Внутренние аудиты базовых линий
- •2.6.6Управление выпуском и поставкой
- •2.6.6.1Сборка программного обеспечения
- •2.6.6.2Управление выпуском программного обеспечения
- •3Инструменты и методы программной инженерии
- •3.1Инструменты
- •3.1.1Инструменты работы с требованиями
- •3.1.2Инструменты проектирования и конструирования
- •3.1.3Инструменты тестирования
- •3.1.4Инструменты сопровождения
- •3.1.5Инструменты конфигурационного управления
- •3.1.6Инструменты управления инженерной деятельностью
- •3.1.7Инструменты поддержки процессов
- •3.1.8Инструменты обеспечения качества
- •3.2Методы
- •3.2.1Эвристические методы
- •3.2.2Формальные методы
- •3.2.3Методы прототипирования
- •4Качество и эффективность в программной инженерии
- •4.1Обеспечение качества программного обеспечения
- •4.1.1Качество программного продукта
- •4.1.2Культура и этика программной инженерии
- •4.1.3Значение и стоимость качества
- •4.1.4Повышение качества пс с использованием процессного подхода
- •4.1.5Показатели качества программных средств
- •4.1.6Количественная оценка качества программного обеспечения
- •4.2Модели качества процессов конструирования
- •4.2.1Качество процессов
- •4.2.4Прочие подходы
- •4.3Процессы управления качеством программного обеспечения
- •4.3.1Подтверждение качества программного обеспечения
- •4.3.2Проверка (верификация) и аттестация
- •4.3.3Оценка и аудит
- •4.3.4Характеристика дефектов
- •4.3.5Методы управления качеством программного обеспечения
- •4.4Стандартизация качества программного обеспечения
- •4.4.1Стандарты в сфере программной инженерии
- •4.4.2Стандартизация программных продуктов в еспд
- •4.4.3Виды стандартных программных документов
- •4.4.4Действующие международные стандарты в сфере разработки программных средств и информационных технологий
- •4.5Документирование программных средств
- •4.6Сертификация программных средств
- •4.6.1Правовые акты по сертификации программных продуктов
- •4.6.2Сертификация пс
- •4.6.3Перечень объектов, подлежащих сертификации и их характеристики
- •Заключение Библиография
2.3Использование uml в программной инженерии
2.3.1Основные компоненты uml
UML представляет собой методологию или язык визуального моделирования, разработанный для описания, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем. UML является простым и мощным средством моделирования, используемым для построения концептуальных, логических и графических моделей сложных систем различного назначения. Язык вобрал в себя наилучшие подходы программной инженерии. Использование UML основывается на понимании общих принципов моделирования сложных систем и особенностей процесса объектно-ориентированного анализа и проектирования, таких как абстригирование, принцип неполноты модели и принцип её иерархического построения.
Рис. 3.1. Общая схема взаимосвязей моделей и представлений сложной системы в процессе объектно-ориентированного анализа и проектирования
Основные задачи, решаемые с помощью UML:
Реализация функционала языка визуального моделирования, предназначенного для разработки и документирования моделей сложных систем. Благодаря чему системный анализ прочно вошёл в практику проектирования и объектно-ориентированный подход постепенно стал доминирующим в программной инженерии.
Обеспечение возможности расширения и специализации UML для повышения качества моделирования систем в предметной области.
Независимость UML от конкретных языков программирования и инструментальных средств проектирования программных систем, что означает, что конструкции языка UML не должны зависеть от особенностей их реализации в применяемых языках программирования.
Наличие семантического базиса в описании UML для понимания общих особенностей ООП, что означает претензию UML на понимание общих принципов ООП.
Обеспечение развития рынка объектно-ориентированных инструментальных средств за счёт популяризации UML и распространение объектно-ориентированных технологий и соответствующих понятий ООАП.
Интеграция в UML последних достижений объектно-ориентированных технологий за счёт его дальнейшей интеграции с другими современными технологиями моделирования и методами программной инженерии.
Описание UML состоит из двух взаимодействующих частей, таких как:
семантика языка UML, представляющая собой метамодель, которая определяющую синтаксис и семантику понятий объектно-ориентированного моделирования с использованием UML;
нотация языка UML, реализуемую графической нотацией для визуального представления семантики UML.
Абстрактный синтаксис и семантика UML описываются с использованием некоторого подмножества нотации. В дополнение к этому, нотация UML описывает соответствие или отображение графической нотации в базовые понятия семантики. Таким образом, с функциональной точки зрения эти две части дополняют друг друга. При этом семантика UML описывается на основе метамодели, имеющей три отдельных представления: абстрактный синтаксис, правила корректного построения выражений и семантику. Рассмотрение семантики языка UML предполагает не полностью формализованный стиль изложения, объединяющий естественный и формальный языки для представления базовых понятий и правил их расширения.
Семантика определяется для двух видов объектных моделей: структурных моделей и моделей поведения. Структурные (статические) модели описывают структуру сущностей или компонентов некоторой системы, включая их классы, интерфейсы, атрибуты и отношения. Модели поведения (динамические модели) описывают поведение объектов системы, включая их методы, взаимодействие и связи между ними, а также процесс смены состояний компонентов и системы в целом.
Нотация UML включает в себя описание отдельных семантических элементов, которые могут применяться при построении диаграмм. Формальное описание UML основывается на общей иерархической структуре модельных представлений, состоящей из четырех уровней:
мета-метамодель;
метамодель;
модель;
объекты пользователя.
Верхний уровень является основой для всех метамодельных представлений. Назначение уровня состоит в определении языка для спецификации метамодели. Мета-метамодель определяет модель UML на самом высоком уровне абстракции и является наиболее компактным ее описанием. Мета-метамодель может описывать несколько метамоделей.
Метамодель является экземпляром мета-метамодели. Главная задача уровня метамодели – определение языка для формирования моделей. Данный уровень обладает более развитой семантикой базовых понятий. Основные понятия UML относятся как раз к уровню метамодели. Примеры таких понятий — класс, атрибут, операция, компонент, ассоциация и многие другие.
Модель в контексте UML является экземпляром метамодели в том смысле, что любая конкретная модель системы должна использовать только понятия метамодели, конкретизировав их применительно к данной ситуации. Это уровень для описания информации о конкретной предметной области. Однако если для построения модели используются понятия языка UML, то необходима полная согласованность понятий уровня модели с базовыми понятиями языка UML уровня метамодели. Примерами понятий уровня модели могут служить имена соответствующих информационных атрибутов, например, имена полей проектируемой базы данных, такие как имя и фамилия сотрудника, возраст, должность, адрес, телефон.
Конкретизация понятий модели происходит на уровне объектов. Объект является экземпляром модели, поскольку содержит конкретную информацию относительно того, чему в действительности соответствуют те или иные понятия модели. Примером объекта может служить следующая запись в проектируемой базе данных: "Илья Петров, 30 лет, иллюзионист, ул. Невидимая, 10-20, 100-0000".
Метамодель UML является больше логической моделью, чем физической или моделью реализации. Особенность логической модели заключается в том, что она концентрирует внимание на декларативной или концептуальной семантике, опуская детали конкретной физической реализации моделей. При этом отдельные реализации, использующие данную логическую метамодель, должны быть согласованы с ее семантикой, а также поддерживать возможности импорта и экспорта отдельных логических моделей.
В то же время, логическая метамодель может быть реализована различными способами для обеспечения требуемого уровня производительности и надежности соответствующих инструментальных средств. В этом заключается недостаток логической модели, которая не содержит на уровне семантики требований, обязательных для ее эффективной последующей реализации. Однако согласованность метамодели с конкретными моделями реализации является обязательной для всех разработчиков программных средств, обеспечивающих поддержку UML.
В рамках UML все представления о модели сложной системы фиксируются в виде специальных графических конструкций, получивших название диаграмм. В терминах UML определены следующие виды диаграмм:
диаграмма вариантов использования (use case diagram);
диаграмма классов (class diagram);
диаграммы поведения (behavior diagrams);
диаграмма состояний (statechart diagram);
диаграмма деятельности (activity diagram);
диаграммы взаимодействия (interaction diagrams);
диаграмма последовательности (sequence diagram);
диаграмма кооперации (collaboration diagram);
диаграммы реализации (implementation diagrams);
диаграмма компонентов (component diagram);
Диаграмма развертывания (deployment diagram).
Из перечисленных выше диаграмм некоторые служат для обозначения двух и более других подвидов диаграмм. При этом в качестве самостоятельных представлений в языке UML используются следующие диаграммы:
диаграмма вариантов использования;
диаграмма классов;
диаграмма состояний;
диаграмма деятельности;
диаграмма последовательности;
диаграмма кооперации;
диаграмма компонентов;
диаграмма развертывания.
Перечень этих диаграмм и их названия представляют собой неотъемлемую часть графической нотации языка UML. Более того, процесс ООП неразрывно связан с процессом построения этих диаграмм. При этом совокупность построенных таким образом диаграмм содержит практически всю информацию, которая необходима для реализации проекта сложной системы.
Каждая из этих диаграмм детализирует и конкретизирует различные представления о модели сложной системы в терминах языка UML.
Диаграмма вариантов использования представляет собой наиболее общую концептуальную модель сложной системы, которая является исходной для построения всех остальных диаграмм.
Диаграмма классов является, по своей сути, логической моделью, отражающей статические аспекты структурного построения сложной системы.
Диаграммы поведения также являются разновидностями логической модели, которые отражают динамические аспекты функционирования сложной системы.
Диаграммы реализации служат для представления физических компонентов сложной системы и поэтому относятся к ее физической модели.
Таким образом, интегрированная модель сложной системы в нотации UML представляется в виде совокупности указанных выше диаграмм.
Рис. 3.10. Интегрированная модель сложной системы в нотации UML