1. Проектирование
1.1. Основы проектирования
1.1.1. Общие концепции проектирования
1.1.1.1. К ним относятся: цель архитектуры, ее ограничения, возможные альтернативы, используемые представления и решения.
1.1.2. Контекст проектирования
1.1.2.1. Это жизненный цикл программной инженерии, в котором проектирование напрямую связано с результатами анализа требований, конструированием программных систем и их тестированием ( описание от требований до тестов).
1.1.3. Процесс проектирования
1.1.3.1. 1. Архитектурное проектирование – декомпозиция структуры и организации компонентов; 2. Детализация архитектуры – описывает специфическое поведение и характеристики отдельных компонент. Итог - набор моделей и артефактов, содержащих результаты решений.
1.1.4. Техники применения
1.1.4.1. (Принципы проектирования)-ключевые идеи и концепции к проектированию программного обеспечения. 1. Абстракция - модель, упрощающая поставленную проблему. 2. Связанность и соединение - их сила между модулями, 3. Декомпозиция и разбиение на модули (упрощение). 4. Инкапсуляция/сокрытие информации. 5. Разделение интерфейса и реализации (определение компонента). 6. Достаточность, полнота и простота.
1.2. Ключевые вопросы проектирования
1.2.1. Параллелизм в проектировании
1.2.1.1. Охватывает вопросы, подходы и методы организации процессов, задач и потоков для обеспечения эффективности, атомарности, синхронизации и распределения (по времени) обработки информации.
1.2.2. Контроль и обработка событий
1.2.2.1. Касается неявных методов обработки событий, часто реализуемых в виде функции обратного вызова (call-back), как одной из фундаментальных концепций обработки событий. Механизм работы приложения не на основе прямого вызова методов классов, а на основе реагирования на те или иные события (корректность работы.
1.2.3. Распределение компонентов
1.2.3.1. Распределение (и выполнение) по различным узлам обработки в терминах аппаратного обеспечения, сетевой инфраструктуры и т.п. Один из важнейших вопросов данной темы – использование связующего ПО.
1.2.4. Обработка ошибок и исключительных ситуаций и обеспечение отказоустойчивости
1.2.4.1. Вопрос темы – как предотвратить сбои или, если сбой все же произошел, обеспечить дальнейшее функционирование системы.
1.2.5. Взаимодействие и представление
1.2.5.1. Тема касается вопросов представления информации пользователям и взаимодействия пользователей с системой, с точки зрения реакции системы на действия пользователей. Речь идет о реакции системы в ответ на действия пользователей и организации ее отклика.
1.2.6. Сохраняемость данных
1.2.6.1. Суть вопроса – как должны обрабатываться “долгоживущие” данные. Не сохранность данных а их дальнейшее существование
1.3. Структура и архитектура
1.3.1. Архитектурные структуры и точки зрения
1.3.1.1. С точки зрения - поведенческой, структурной, логической, физической, реализации и т.п. В результате, мы получаем различные архитектурные представления. (Применение архитектурной точки зрения и представления к конкретной системе и описания тех деталей, которые необходимы для реализации системы, но ещё отсутствуют).
1.3.2. Архитектурные стили
1.3.2.1. Это шаблон проектирования макро-архитектуры - на уровне модулей, "крупноблочного" взгляда. Например, архитектура распределенной сервисно- ориентированной системы может строится в стиле обмена сообщениями через соответствующие очереди сообщений. (Набор ограничений, определяющих семейство архитектур, которые удовлетворяют этим ограничениям).
1.3.3. Шаблоны проектирования
1.3.3.1. Это “общее решение общей проблемы в заданном контексте”. Шаблоны определяют частные аспекты деталей архитектуры. Например: 1. Шаблоны создания. 2. Структурные шаблоны. 3. Шаблоны поведения
1.3.4. Семейства программ и фреймворков
1.3.4.1. Формирование линий продуктов на основе общего дизайна -“фреймворки”, обеспечивающие решение одних и тех же задач – например, внутренней организации компонентов пользовательского интерфейса или общей логики работы распределенных систем.
1.4. Анализ качества и оценка дизайна
1.4.1. Атрибуты качества
1.4.1.1. Эти атрибуты могут описывать многие характеристики системы и элементов дизайна как такового –“тестируемость”, “переносимость”,“модифицируемость”, “производительность”, “безопасность”. Важно понимать, что обсуждаемые атрибуты касаются только дизайна (как результата), но не проектирования (как процесса). 1. Применимые к run-time, то есть ко времени выполнения системы; 2. ориентированные на design-time, то есть позволяющие оценивать качество получаемого дизайна. 3. атрибуты качества архитектурного дизайна как такового, например, концептуальная целостность, полнота, завершенность.
1.4.2. Анализ качества и техники оценки
1.4.2.1. 1. Обзор дизайна; например, неформальный обзор архитектуры членами проектной команды; 2.Статический анализ; например, трассировка с требованиями (их происхождение, связь); 3. симуляция и прототипирование – динамические техники проверки дизайна в целом или отдельных его атрибутов качества;например, для оценки производительности используемых архитектурных решений при симуляции нагрузки
1.4.3. Измерения
1.4.3.1. Могут быть использованы для количественной оценки ожиданий в отношении различных аспектов конкретного дизайна, например, размера <проекта>, структуры (ее сложности) или качества.
1.5. Нотации проектирования
1.5.1. Структурные описания, статический взгляд
1.5.1.1. Следующие нотации, в основном являются графическими, описывая и представляя структурные аспекты программного дизайна. Чаще всего они касаются основных компонентов и связей между ними (например, таких как отношения “один-ко-многим”). Диаграммы классов и объектов, языки описания архитектуры и т.д.
1.5.2. Поведенческие описания, динамический взгляд
1.5.2.1. Следующие нотации и языки (часть из которых – графические, часть - текстовые) используются для описания динамического поведения программных систем и их компонентов. Многие из этих нотаций успешно используются для проектирования деталей дизайна, но не только для этого. Диаграммы сотрудничества, блок-схемы и структурированные блок-схемы и т.д.
1.6. Стратегии и методы проектирования
1.6.1. Общие стратегии
1.6.1.1. Общепринятые стратегии: 1. “разделяй-и-властвуй” и пошаговое уточнение (разделение задачи на две или более подзадачи того же типа), 2. проектирование “сверху-вниз” и “снизу-вверх”. 3. Абстракция данных и сокрытие информации (лавное отличие между сокрытием данных и абстракцией является то, что сокрытие данных помогает защитить данные, а абстракция помогает скрыть сложность системы). 4. Итеративный (не имеет определенное количество шагов, а развитие осуществляется в циклах) и инкрементальный подход (не имеет определенное количество шагов, а развитие осуществляется в циклах) и др
1.6.2. Функционально-ориентированное или структурное проектирование
1.6.2.1. Это один из классических методов проектирования, в котором декомпозиция сфокусирована на идентификации основных программных функций и, затем, детальной разработке и уточнении этих функций “сверху-вниз”. Структурное проектирование, обычно, используется после проведения структурного анализа с применением диаграмм потоков данных и связанным описанием процессов. (передача функций от объекта к объекту)
1.6.3. Объектно-ориентированное проектирование
1.6.3.1. Представляет собой множество методов проектирования, базирующихся на концепции объектов. Основывается на понятиях объекта (сущности), метода (действия) и атрибута (характеристики). Декомпозиция уже существующих объектов
1.6.4. Проектирование на основе структур данных
1.6.4.1. В данном подходе фокус сконцентрирован в большей степени на структурах данных, которыми управляет система, чем на функциях системы. Инженеры по программному обеспечению часто вначале описывают структуры данных входов и выходов, а, затем, разрабатывают структуру управления этими данными. Содержание системы.
1.6.5. Компонентное проектирование
1.6.5.1. Данный подход призван решить задачи использования, разработки и интеграции программных компонентов (независимых единиц), с целью повышения повторного использования активов (как архитектурных, так и в форме кода). Каждый компонент отвечает за свою функцию не завися от других объектов.
1.6.6. Другие методы
1.6.6.1. Другие интересные, но менее распространенные подходы, в основном, представляют собой формальные и точные (строгие) методы, а также, методы трансформации.
2. Конструирование
2.1. Основы конструирования
2.1.1. Минимизация сложности
2.1.1.1. Уменьшение сложности в конструировании программного обеспечения достигается при уделении особого внимания созданию простого и легко читаемого кода, пусть и в ущерб стремлению сделать его идеальным. Придание большей значимости читаемости кода, простоте тестирования и т.д.
2.1.2. Ожидание изменений
2.1.2.1. Большинство программных систем изменяются с течением времени. Более того, программные системы являются частью изменяющейся среды и должны меняться вместе с ней, а, иногда, и быть источником изменений самой среды.
2.1.3. Конструирование с возможностью проверки
2.1.3.1. Предполагает, что построение программных систем должно вестись таким образом, чтобы сама программная система помогала вести поиск причин сбоев, будучи прозрачной для применения различных методов проверки, как на стадии независимого тестирования, так и в процессе операционной деятельности - эксплуатации. (Обзор, оценка кода, модульное тестирование, выявление ошибок и т.д.)
2.1.4. Стандарты в конструировании
2.1.4.1. Коммуникационные методы, языки программирования и соответствующие стили кодирования, платформы 1. Конструирование зависит от внешних стандартов, связанных с языками программирования, используемым инструментальным обеспечением, техническими интерфейсами и взаимным влиянием Конструирования ПО. 2. Внутренние, созданы внутри организации или даже проектной команды. Эти стандарты поддерживают координацию между определенными видами деятельности, группами операций, минимизируют сложность, могут быть связаны с вопросами ожидания и обработки изменений, рисков и вопросами конструирования.
2.2. Управление конструированием
2.2.1. Модели конструирования
2.2.1.1. Модели конструирования определяют комплекс операций, включающих последовательность, результаты (например, исходный код и соответствующие unit-тесты) и другие аспекты, связанные с общим жизненным циклом разработки. К ним относятся, например, водопадная и поэтапная модели жизненного цикла. Эти модели рассматривают конструирование как деятельность только после завершения определенных работ, включающих детальное определение требований, подробный дизайн и детальное планирование. Другие модели более итеративны – эволюционное прототипирование, экстремальное программирование, Scrum (определение требований,проектиров-е, планирование)
2.2.2. Планирование конструирования
2.2.2.1. Выбор метода (методологии) конструирования. Например, модульное тестирование в ряде методов является частью работ, после написания соответствующего функционального кода. Планирование определяет порядок, в котором создаются компоненты и другие активы данной области знаний, проводятся работы по обеспечению качества получаемого ПО, распределяются* задачи и соответствующие ресурсы, в том числе, определяются назначения работ конкретным инженерам.
2.2.3. Измерения в констуировании
2.2.3.1. Большая часть результатов, да и самой деятельности по конструированию ПО, может быть измерена, в том числе - количественно. Это и исходный разработанный код, и модифицированный объем кода, и степень повторного использования, и многие другие характеристики. Эти измерения, или как их еще принято называть – результаты аудита кода и метрики кода, несут большую пользу как для оценки рисков и качества, так и для управления конструированием и программными проектами, в целом.
2.3. Практические соображения
2.3.1. Проектирование в конструировании
2.3.1.1. Некоторые проекты предполагают больший объем работ по проектированию именно на стадии конструирования. Практически всегда на стадии конструирования приходится заниматься и вопросами детального дизайна системы. Такие проектные работы имеют стремление к следованию устойчивым ограничениям, навязываемым конкретными проблемами, решение которых должно быть обеспечено использованием конструируемой программной системы.
2.3.2. Язык конструирования
2.3.2.1. Языки конструирования включают все формы коммуникаций, с помощью которых человек может задать решение проблемы, выполняемое на компьютере. Конфигурационный язык - задает параметры выполнения программной системе. Инструментальный язык – язык констр-ния из повторно используемы элементов. Язык программирования – наиболее гибкий тип языков констр-ния. Содержит минимальный объем информации о конкретных областях приложения и процессе разработки, но требует наработку опыта.
2.3.3. Кодирование
2.3.3.1. Процесс написания программного кода, скриптов, с целью реализации определённого алгоритма на определённом языке программир-ия (организация исходного текста, использование классов и переменных, тонкая настройка кода, понимаемость.
2.3.4. Тестирование в конструировании
2.3.4.1. Главная цель тестирования в конструировании уменьшить временной разрыв между моментом проявления ошибок, имеющихся в коде, и моментом их обнаружения. Во многих случаях, тестирование в конструировании производится после того, как код написан. В ряде случаев, тесты пишутся до того, как создается код.
2.3.5. Повторное использование
2.3.5.1. Оно требует формализации практики повторного использования на основе интеграции процессов и деятельности по повторному использованию в сам жизненный цикл программного обеспечения. (Выбор единиц, баз данных тестовых процедур, данных <полученных в результате> тестов, подлежащих повторному использованию. Оценку потенциала повторного использования кода и тестов. Отслеживание информации и создание отчетности по повторному использованию в новом коде,
2.3.6. Качество конструироания
2.3.6.1. Деятельность по обеспечению качества в конструировании отличается от других операций по обеспечению качества. Основное отличие заключается в фокусе на программном (исходном) коде и других артефактах (активах), тесно связанных с кодом, в частности, детальных моделях. Тех. обзор и оценка, пошаговое кодирование, тесты и отладка.
2.3.7. Интеграция
2.3.7.1. Интеграция отдельно сконструированных операций (процедур), классов, компонентов и подсистем (модулей). В дополнение к этому, некоторые программные системы нуждаются в специальной интеграции с другим программным и аппаратным обеспечением.
3. Требования
3.1. Основы требований
3.1.1. Определение требований
3.1.1.1. Дается само понятие “требования”, как такового, и отмечаются его основные характеристики, например, верифицируемость (проверяемость) требования, какие либо условия.
3.1.2. Требования к продукту и процессу
3.1.2.1. Требования как свойство продукта, все то что требуется для его создания и бесперебойной работы каких либо процессов, неверные программные требования порождают другие требования к процессам работе продукта
3.1.3. Функциональные и нефункциональные требования
3.1.3.1. функциональные требования задают “что” система должна делать; нефункциональные – с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции)
3.1.4. Независимые свойства
3.1.4.1. Эти свойства обозначают требования, которые адресованы к системе в целом, и не могут быть соотнесены с отдельными ее элементами.
3.1.5. Количественные требования
3.1.5.1. Требования, поддающиеся количественному определению/измерению, например, система должна обеспечить пропускную способность “столько-то запросов в секунду”.
3.1.6. Системные и программные требования
3.1.6.1. “Комбинация взаимодействующих элементов <созданная> для достижения определенных целей; аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы”.
3.2. Процесс работы с требованиями
3.2.1. Модели процессов
3.2.1.1. Не является дискретным; это постоянно действующий процесс на всех этапах жизненного цикла программного обеспечения.
3.2.1.2. Идентифицирует программные требования и контролирует их с использованием тех же практик управления, что и для других активов программных проектов (например, файлов или запросов на изменения).
3.2.1.3. Требует адаптации к проектному или организационному контексту, в рамках которого ведется соответствующий программный проект.
3.2.2. Участники процессов
3.2.2.1. Пользователи, заказчики, аналитики, регуляторы, Инженеры по программному обеспечению, инженеры-программисты
3.2.3. Управление и поддержка процессов
3.2.3.1. Вопросы распределения ресурсов, необходимых для осуществления проектной деятельности, “Инициация и определение содержания” области знаний “Управление в программной инженерии”. Основная цель – обеспечение связи между процессами и деятельностью.
3.2.4. Качество и улучшение процессов
3.2.4.1. Оценка качества процессов работы с программными требованиями и улучшением этих процессов. Улучшение процессов и в частности процессов разработки и управления требованиями должно предваряться формулировкой проблемы.
3.3. Извлечение требований
3.3.1. Источники требований
3.3.1.1. Источники требований, значимые для решения задач проекта. Данная тема фокусируется на: Целях. Знании предметной области. Заинтересованных лицах. Операционном окружении. Организационной среде.
3.3.2. Техники сбора требований
3.3.2.1. Интервьюирование, сценарии, прототипы, "разъясняющие встречи"(встречи участников проекта), наблюдение.
3.4. Анализ требований
3.4.1. Классификация требований
3.4.1.1. Функциональные и нефункциональные требования. Внутренние (с другими требованиями) или внешние зависимости. Требования к процессу или продукту. Приоритет требований. Содержание требований в отношении конкретных подсистем создаваемого программного обеспечения. Изменяемость/стабильность требований.
3.4.2. Концептуальное моделирование
3.4.2.1. Сбор, анализ и редактирование требований к данным о предметной области. Цель моделирования – понимание проблемы, задачи и методов их решения до того, как начнется решение проблемы.
3.4.3. Архитектурное проектирование и распределение требований
3.4.3.1. Создание архитектуры программных решений. Архитектурное проектирование перекрывается с программным и системным дизайном (проектированием) и иллюстрирует насколько сложно провести четкую грань между различными аспектами проектирования.
3.5. Спецификация требований
3.5.1. Документ определений системы
3.5.1.1. Описывает системные требования. Содержание документа определяет высокоуровневые требования, часто – стратегические цели, для достижения которых создается программная система. Такой документ описывает требования к системе с точки зрения области применения.
3.5.2. Спецификация системных требований
3.5.2.1. Документ описывает программную систему в контексте системной инженерии. Строго говоря, спецификация системных требований описывает деятельность системных инженеров.
3.5.3. Спецификация программных требований
3.5.3.1. Программные требования устанавливают основные соглашения между пользователями (заказчиками) и разработчиками (исполнителями) в отношении того, что будет делать система и чего от нее не стоит ожидать. Документ может включать процедуры проверки получаемого ПО на соответствие предъявляемым ему требованиям, характеристики, определяющие качество и методы его оценки, вопросы безопасности и др.
3.6. Проверка требований
3.6.1. Обзор требований
3.6.1.1. Ряд лиц, вовлеченных в проект “вычитывают” требования в поисках необоснованных предположений, описаний требований, допускающих множественные интерпретации, противоречий, несогласованности, недостаточной степени детализации, отклонений от принятых стандартов.
3.6.2. Прототипирование
3.6.2.1. Прототипирование подразумевает проверку инженерной интерпретации программных требований и извлечение новых требований, неопределенных или неясных на ранних итерациях сбора требований. Прототипы создаются для оценки способа реализации пользовательского интерфейса и проверки архитектурных подходов и решений.
3.6.3. Утверждение модели
3.6.3.1. Утверждение или аттестация модели связана с вопросами обеспечения приемлемого качества продукта. Уверенность в соответствии модели заданным требованиям может быть закреплена формально со стороны пользователей/заказчика.
3.6.4. Приемочные тесты
3.6.4.1. Это последний тест перед развертыванием программного обеспечения. Приемочное тестирование делается для проверки готовности программного обеспечения выполнять задачи и функции, поставленные при разработке. Требования должны быть верифицируемы (проверены).
3.7. Практические соображения
3.7.1. Интерактивная природа процесса работы с требованиями
3.7.1.1. Это процесс создания программного обеспечения, который осуществляется небольшими этапами, в ходе которых ведется анализ полученных промежуточных результатов, выдвигаются новые требования и корректируются предыдущие этапы работы.
3.7.2. Управление изменениями
3.7.2.1. Одна из ключевых тем управления требованиями. Это управление всеми активами проекта, включая код, требования, запросы на изменения, задачи и т.п.
3.7.3. Атрибуты требований
3.7.3.1. Требования, состоящие из описания того, что необходимо сделать, и содержащие информацию, необходимую для интерпретации требований и управления ими. например, приоритет, уникальный идентификатор, источник и тип требования, статус и т.д.
3.7.4. Трассировка требоаний
3.7.4.1. Трассировка требований обеспечивает связь между требованиями и отслеживанием источников требований. Это основа проведения анализа влияния при изменении требований, помогая предсказывать эффект от внесения таких изменений. Предполагает связь между требованиями, то есть зависимость.
3.7.5. Измерения требований
3.7.5.1. Определение “объема” требований для заданного (создаваемого) программного продукта. Это число полезно для исследования “масштабов” изменений в требованиях, оценки стоимостных характеристик разработки и поддержки программной системы, оценки продуктивности разработки и эффективности поддержки требований и внесения изменений