- •Учебное пособие по теоретической подготовке «Технологии разработки программного обеспечения»
- •Оглавление
- •Введение
- •Введение в технологии разработки программного обеспечения
- •Основные этапы развития технологии разработки
- •Первый этап – «стихийное» программирование.
- •Второй этап – структурный подход к программированию (60-70-е годыXXв)
- •Третий этап – объектный подход к программированию (с середины 80-х годов до нашего времени)
- •Четвертый этап – компонентный подход иCase-технологии (с середины 90-х годов до нашего времени)
- •Пятый этап – разработка, ориентированная на архитектуру иCase-технологии (с началаXxIв. До нашего времени)
- •Эволюция моделей жизненного цикла программного обеспечения
- •Каскадная модель
- •Спиральная модель
- •Макетирование
- •Быстрая разработка приложений
- •Компонентно-ориентированная модель
- •Xp-процесс
- •Стандарты, регламентирующие процесс разработки программного обеспечения
- •Гост р исо 9000-2001. Системы менеджмента качества. Основные положения и словарь
- •Предисловие
- •Введение
- •Принципы менеджмента качества
- •Область применения
- •Основные положения систем менеджмента качества Обоснование необходимости систем менеджмента качества
- •Требования к системам менеджмента качества и требования к продукции
- •Подход к системам менеджмента качества
- •Процессный подход
- •Политика и цели в области качества
- •Роль высшего руководства в системе менеджмента качества
- •Документация
- •Оценивание систем менеджмента качества
- •Постоянное улучшение
- •Роль статистических методов
- •Направленность систем менеджмента качества и других систем менеджмента
- •Взаимосвязь между системами менеджмента качества и моделями совершенства
- •Гост р исо/мэк то 15504
- •Область применения
- •Состав исо/мэк то 15504
- •Принцип 1 – Ориентация организации на потребителя (Customer-FocusedOrganization)
- •Принцип 2 – Лидерство (Leadership)
- •Принцип 3 – Вовлечение персонала (Involvement of People)
- •Принцип 4 – Процессный подход (Process Approach)
- •Принцип 5 – Системный подход к административному управлению (System Approach to Management)
- •Принцип 6 – Непрерывное усовершенствование (Continual Improvement)
- •Принцип 7 – Основанный на фактах подход к принятию решений (FactualApproachtoDecisionMaking)
- •Принцип 8 – Взаимовыгодные отношения с поставщиками (Mutually beneficial supplier relationship)
- •Гост р исо/мэк 12207-99. Информационная технология. Процессы жизненного цикла программных средств
- •Введение
- •Область применения Назначение
- •Область распространения
- •Адаптация настоящего стандарта
- •Соответствие
- •Ограничения
- •Прикладное применение настоящего стандарта
- •Построение стандарта
- •Анализ проблемы и постановка задачи
- •Введение в системный анализ
- •Системные ресурсы
- •Анализ проблемы и моделирование предметной области с использованием системного подхода
- •Основные положения
- •Этап 1. Достижение соглашения об определении проблемы
- •Этап 2. Выделение основных причин – проблем, стоящих за проблемой
- •Устранение корневых причин
- •Этап 3. Выявление заинтересованных лиц и пользователей
- •Этап 4. Определение границ системы-решения
- •Этап 5. Выявление ограничений, налагаемых на решение
- •МетодологияAris
- •Организационная модель
- •Диаграмма цепочки добавленного качества
- •МоделиeEpc
- •Стандарты idef0 - idef3
- •Методология описания бизнес процессовIdef3
- •Синтаксис и семантика моделей idef3 Модели idef3
- •Диаграммы
- •Единица работы. Действие
- •Соединения
- •Декомпозиция действий
- •Требования idef3 к описанию бизнес-процессов
- •Определение сценария, границ моделирования, точки зрения
- •Определение действий и объектов
- •Последовательность и параллельность
- •Методология функционального моделированияIdef0
- •Синтаксис и семантика моделейIdef0 Модели idef0
- •Действия
- •Границы и связи
- •Туннели
- •Построение моделей idef0
- •Диаграммы
- •Цикл "эксперт-аналитик"
- •Построение моделей
- •Точка зрения
- •Границы моделирования
- •Выбор наименования контекстного блока
- •Определение стрелок на контекстной диаграмме
- •Нумерация блоков и диаграмм
- •Связь между диаграммой и ее родительским функциональным блоком
- •Два подхода к началу моделирования ("в ширину" и "в глубину")
- •Анализ требований и их формализация
- •Методы определения требований
- •Интервьюирование
- •Этапы проведения интервью
- •Мозговой штурм и отбор идей
- •Генерация идей
- •Отбор идей
- •Совместная разработка приложений (jad –Jointapplication design)
- •Роли в сеансах jad
- •Недостатки метода jad
- •Раскадровка
- •Типы раскадровок
- •Обыгрывание ролей
- •Суть метода обыгрывания ролей
- •Сценарный просмотр
- •Crc-карточки (Class-Responsibility-Collaboration, класс-обязанность-взаимодействие)
- •Быстрое прототипирование
- •Формализация требований
- •Метод вариантов использования и его применение
- •Построение модели вариантов использования
- •Спецификация вариантов использования Определение потока событий
- •Альтернативный поток событий.
- •Выявление пред- и постусловий
- •Преимущества
- •Псевдокод
- •Конечные автоматы
- •Графические деревья решений
- •Диаграммы деятельности
- •Техническое задание (гост 34.602-89)
- •Общие сведения
- •Назначение и цели создания (развития) системы
- •Требования к численности и квалификации персонала на ас
- •Требования к защите информации от несанкционированного доступа
- •Дополнительные требования
- •Требования к функциям (задачам)
- •Требования к видам обеспечения
- •Требования к математическому обеспечению системы
- •Требования к информационному обеспечению
- •Требования к лингвистическому обеспечению
- •Требования к программному обеспечению
- •Требования к техническому обеспечению
- •Требования к метрологическому обеспечению
- •Требования к организационному обеспечению
- •Требования к методическому обеспечению сапр
- •Состав и содержание работ по созданию системы
- •Порядок контроля и приемки системы
- •Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
- •Требования к документированию
- •Источники разработки
- •Архитектуры программных систем
- •Планирование архитектуры
- •Архитектурно-экономический цикл
- •Программный процесс и архитектурно-экономический цикл
- •Этапы разработки архитектуры
- •Создание экономической модели системы
- •Выявление требований
- •Создание или выбор архитектуры
- •Распространение сведений об архитектуре
- •Анализ или оценка архитектуры
- •Суть программной архитектуры
- •Архитектурные образцы, эталонные модели и эталонные варианты архитектуры
- •Архитектурные структуры и представления
- •Программные структуры
- •Компонент и соединитель
- •Распределение
- •Проектирование архитектуры
- •Атрибутный метод проектирования
- •Этапы add
- •Создание макета системы
- •Документирование программной архитектуры
- •Варианты применения архитектурной документации
- •Представления
- •Выбор значимых представлений
- •Документирование представления
- •Документирование поведения
- •Документирование интерфейсов
- •Шаблон для документирования интерфейсов
- •Методы анализа архитектуры
- •Метод анализа компромиссных архитектурных решений – комплексный подход к оценке архитектуры
- •Этапы атам
- •Метод анализа стоимости и эффективности — количественный подход к принятию архитектурно-проектных решений
- •Контекст принятия решений
- •Реализация свам
- •Технология mda.
- •Использование архитектуры, управляемой моделью
- •Концепция архитектуры, управляемой моделью
- •Модельные точки зрения и моделиMda
- •Язык объектных ограниченийOcl
- •Типы данных и операцииOcl
- •Инфиксная форма записи выраженийOcl
- •Последовательности доступа к объектам в языкеOcl
- •Операции над коллекциями
- •Стандартные операции
- •Операция select
- •Операция reject
- •Выделение элементов коллекции
- •Упорядочение набора
- •Логические итераторы
- •Операции для работы со строками
- •Работа с датами
- •Возможности технологииEco
- •Введение в технологию есо
- •Модель есо
- •Пространство имен есо
- •Разработка приложений на основеEco
- •Этапы создания приложения по технологииEco
- •Создание простого mda-приложения
- •Создание модели uml
- •Создание интерфейса
- •Связывание интерфейса с моделью
- •Создание логики на ocl
- •Документирование программных систем в соответствии с гост
- •Управление документированием программного обеспечения
- •Предисловие
- •Область применения
- •Роль руководителей
- •Функции программной документации
- •Информация для управления
- •Связь между задачами
- •Обеспечение качества
- •Определение стандартов и руководств по документированию
- •Выбор модели жизненного цикла программного обеспечения
- •Определение типов и содержания документов
- •Документация разработки
- •Документация продукции
- •Документация управления проектом
- •Определение качества документов
- •Определение форматов документов
- •Определение системы обозначения документов
- •Установление процедуры документирования
- •Распределение ресурсов для документирования
- •Персонал
- •Средства
- •Финансирование
- •Планирование документирования
- •Требования к содержанию документов на автоматизированные системы
- •Общие положения
- •Требования к содержанию документов по общесистемным решениям
- •Ведомость эскизного (технического) проекта
- •Пояснительные записки к эскизному, техническому проектам
- •Описание автоматизируемых функций
- •Описание постановки задачи (комплекса задач)
- •Локальная смета и локальный сметный расчет
- •Паспорт
- •Формуляр
- •Проектная оценка надежности системы
- •Общее описание системы
- •Программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистем, систем)
- •Требования к содержанию документов с решениями по организационному обеспечению
- •Описание организационной структуры
- •Методика (технология) автоматизированного проектирования
- •Технологическая инструкция
- •Руководство пользователя
- •Описание технологического процесса обработки данных
- •Требования к содержанию документов с решениями по программному обеспечению
- •Описание программного обеспечения
- •Другие разделы
- •Принципы разработки руководства программиста
- •Общие положения
- •Содержание разделов
- •Разработка руководства пользователя
- •Общие замечания
- •Содержание разделов руководства
- •Общие сведения
- •Описание применения
- •Требования к процедурам функционирования системы
- •Заключение
- •Библиографический список
Шаблон для документирования интерфейсов
Ниже изложен один из вариантов стандартной структуры документации интерфейса. Некоторые ее элементы, если они оказываются бесполезными в конкретном применении, можно выкинуть, другие, наоборот, ввести. Значительно более важными, чем сама стандартная структура, представляются нам способы ее применения. Ваша цель должна заключаться в том, чтобы в точности изложить все внешне видимые взаимодействия интерфейсов, предусмотренных в проекте.
Индивидуальность интерфейса. Если у элемента несколько интерфейсов, их нужно как-то отличать друг от друга. Как правило, для этого интерфейсам присваиваются имена, в некоторых случаях сопровождающиеся указанием номера версии.
Предоставляемые ресурсы, Основным предметом документирования любо го интерфейса должны быть предоставляемые им ресурсы. Они определяются синтаксисом, семантикой (описывающей следствия их применения) и ограничениями по использованию. Существует ряд нотаций, предназначенных для документирования синтаксиса интерфейса. Одна из них — язык описания интерфейсов (interface definition language, IDL), разработанный рабочей группой OMG, — применяется в сообществе CORBA. С помощью специальных языковых конструкций этого языка описываются типы данных, операции, атрибуты и исключения. Семантическую информацию можно выразить только в комментариях. В большинстве программных языков есть встроенные средства спецификации сигнатур элементов, примером чему — заголовочные файлы (.h) в С и спецификации пакетов в Ada. Наконец, на языке UML синтаксическая информация об интерфейсе выражается через стереотип «interface». Для интерфейса необходимо хотя бы ввести имя; кроме того, архитектор волен составить для него сигнатуру.
Синтаксис ресурса. Здесь указывается сигнатура ресурса. Содержащейся в сигнатуре информации должно быть достаточно для того, чтобы любая сторонняя программа смогла корректно с точки зрения синтаксиса обратиться к программе, использующей данный ресурс. Таким образом, в сигнатуру входят имя ресурса, имена и логические типы данных его аргументов (если таковые имеются) и т. д.
Семантика ресурса. Здесь приводится описание результатов вызова ресурса, в частности:
присваивание значений данным, к которым может обращаться актер, вызывающий рассматриваемый ресурс, — от простого задания значения возвращаемого аргумента до обновления центральной базы данных;
события и сообщения, сигнализируемые/отправляемые в результате обращения к ресурсу;
предполагаемое поведение других ресурсов как результат обращения к рассматриваемому ресурсу (к примеру, если данный ресурс уничтожит некий объект, то последующие попытки обращения к этому объекту будут приводить к новому результату — ошибке);
результаты, наблюдаемые пользователем (встречающиеся в основном во встроенных системах: скажем, вызов программы, ответственной за включение бортового индикатора, приводит к наблюдаемому результату).
Кроме того, семантика должна прояснять вопросы, связанные с исполнением ресурса: будет ли оно носить элементарный характер, можно ли его приостановить или прервать. Как правило, семантическая информация выражается средствами естественного языка. Для фиксации предусловий и постусловий — сравнительно простого и эффективного метода выражения семантики — специалисты во многих случаях прибегают к булевой алгебре. Еще одним средством передачи семантической информации являются следы — записи последовательностей операций и взаимодействий, описывающих реакцию элемента на тот или иной вариант использования.
Ограничения на использование ресурсов. В каких обстоятельствах возможно обращение к рассматриваемому ресурсу? Существует ли необходимость в предваряющей его считывание инициализации данных? Обусловливается ли вызов одного метода вызовом другого? Не установлены ли какие-то ограничения относительно количества актеров, имеющих возможность одномоментного взаимодействия с ресурсом? Возможно, в силу принадлежности элемента определенному актеру, он единственный, кто обладает полномочиями по модификации элемента, а все остальные актеры ограничиваются лишь считыванием. Не исключено также, что, согласно многоуровневой схеме безопасности, каждый актер может обращаться к строго определенным ресурсам или интерфейсам. Если рассматриваемый ресурс отталкивается от каких-либо допущений о своем окружении (например, требует наличия других ресурсов), их следует задокументировать.
Определения типов данных. Если какой-либо ресурс интерфейса задействует тип данных, отличный от предусмотренного соответствующим языком программирования, архитектор должен привести определение типа данных. Если он определен в другом элементе, достаточно установить ссылку на его документацию. Как бы то ни было, программисты, которые пишут элементы, обращаясь к такому ресурсу, должны знать: а) как объявлять переменные и константы типа данных; б) как в рамках этого типа данных записывать литеральные значения; в) какие операции и сравнения применимы к членам типа данных; и г) как преобразовывать значения этого типа данных в данные других типов.
Определения исключений. Здесь предполагаются описания исключений, которые могут порождать ресурсы на данном интерфейсе. Поскольку одни и те же исключения во многих случаях характерны для множества ресурсов, имеет смысл отделять список исключений каждого ресурса от их определений, причем последние размещать в специальном словаре. Настоящий раздел как раз исполняет роль словаря. Здесь же допустимо определять стандартное поведение обработки ошибок.
Характерная для интерфейса изменчивость. Предполагает ли данный интерфейс возможность конфигурирования элемента? Подобные параметры конфигурации (configuration parameters), а также их воздействие на семантику интерфейса подлежат документированию. В качестве примеров изменчивости можно привести емкость видимых структур данных и рабочие характеристики соответствующих алгоритмов. Для каждого параметра конфигурации архитектор должен зафиксировать имя, диапазон значений и время связывания его фактических значений.
Характеристики атрибутов качества интерфейса. Архитектор должен задокументировать характеристики атрибутов качества (например, производительность или надежность), предоставляемых интерфейсом конечным пользователям. Эти сведения можно выразить в форме ограничений на реализацию составляющих интерфейс элементов. Выбор атрибутов качества, на которых предполагается сконцентрироваться и принять обязательства, проводится в зависимости от контекста.
Требования к элементам. Среди требований элемента может значиться наличие конкретных именованных ресурсов других элементов. Документация в данном случае составляется так же, как и в отношении ресурсов, — указываются синтаксис, семантика и ограничения по использованию. В некоторых случаях подобного рода информацию удобнее документировать в форме ряда допущений о системе, принятых проектировщиком элемента. В таком случае требования можно представить на суд экспертов, которые уже на ранних стадиях процесса проектирования смогут подтвердить или опровергнуть принятые допущения.
Логическое обоснование и соображения о проекте. Как и в случае с логическим обоснованием архитектуры в целом (или архитектурных представлений), архитектор должен документировать факторы, обусловившие принятие тех или иных проектных решений относительно интерфейса. В логическом обосновании необходимо указать мотивацию принятия этих решений, ограничения и компромиссы, обрисовать рассмотренные, но впоследствии забракованные решения (не забыв попутно изложить причины отказа от них), и изложить соображения архитектора касательно дальнейших изменений интерфейса.
Руководство по использованию. В некоторых случаях требуется анализ семантики с позиции связей между множеством отдельных взаимодействий. Если это так, в дело вступает протокол (protocol), документировать который следует согласно последовательности взаимодействий. Протоколы отражают комплексное поведение при взаимодействии тех образцов использования, которые, по мысли архитектора, должны встречаться с определенной регулярностью. Сложность взаимодействия с элементом через его интерфейс следует компенсировать статической поведенческой моделью (например, схемой состояний) или примерами проведения отдельных видов взаимодействия (в форме диаграмм последовательностей).