- •Учебное пособие по теоретической подготовке «Технологии разработки программного обеспечения»
- •Оглавление
- •Введение
- •Введение в технологии разработки программного обеспечения
- •Основные этапы развития технологии разработки
- •Первый этап – «стихийное» программирование.
- •Второй этап – структурный подход к программированию (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
- •Документирование программных систем в соответствии с гост
- •Управление документированием программного обеспечения
- •Предисловие
- •Область применения
- •Роль руководителей
- •Функции программной документации
- •Информация для управления
- •Связь между задачами
- •Обеспечение качества
- •Определение стандартов и руководств по документированию
- •Выбор модели жизненного цикла программного обеспечения
- •Определение типов и содержания документов
- •Документация разработки
- •Документация продукции
- •Документация управления проектом
- •Определение качества документов
- •Определение форматов документов
- •Определение системы обозначения документов
- •Установление процедуры документирования
- •Распределение ресурсов для документирования
- •Персонал
- •Средства
- •Финансирование
- •Планирование документирования
- •Требования к содержанию документов на автоматизированные системы
- •Общие положения
- •Требования к содержанию документов по общесистемным решениям
- •Ведомость эскизного (технического) проекта
- •Пояснительные записки к эскизному, техническому проектам
- •Описание автоматизируемых функций
- •Описание постановки задачи (комплекса задач)
- •Локальная смета и локальный сметный расчет
- •Паспорт
- •Формуляр
- •Проектная оценка надежности системы
- •Общее описание системы
- •Программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистем, систем)
- •Требования к содержанию документов с решениями по организационному обеспечению
- •Описание организационной структуры
- •Методика (технология) автоматизированного проектирования
- •Технологическая инструкция
- •Руководство пользователя
- •Описание технологического процесса обработки данных
- •Требования к содержанию документов с решениями по программному обеспечению
- •Описание программного обеспечения
- •Другие разделы
- •Принципы разработки руководства программиста
- •Общие положения
- •Содержание разделов
- •Разработка руководства пользователя
- •Общие замечания
- •Содержание разделов руководства
- •Общие сведения
- •Описание применения
- •Требования к процедурам функционирования системы
- •Заключение
- •Библиографический список
Модельные точки зрения и моделиMda
Когда разработчик взаимодействует с создаваемой системой в рамках подхода MDA, ему доступны три модельные точки зрения на систему.
Точка зрения, независимая от вычислительных особенностей Computation Independent Viewpoint (CIV), нацелена на анализ системной среды и системных требований. Логика работы пока что не рассматривается — возможно, она еще не определена. В CIV учитываются программные, аппаратные и другие технологические ограничения, которые не связаны напрямую с внутренней архитектурой разрабатываемой программы.
Точка зрения, независимая от программно-аппаратной платформы Platform Independent Viewpoint (PIV), задает конкретные функциональные элементы системы, не зависящие от платформы. В ее рамках используются языки моделирования наподобие UML.
Точка зрения, зависящая от платформы Platform Specific Viewpoint (PSV), задает детали реализации, зависящие от используемых платформ и язы ков программирования. Она сочетает платформенно-независимую логику с дополнительными особенностями, вызванными использованием конкретной платформы или системы.
Каждая из этих точек зрения предлагает разные средства построения соответствующих моделей. Бизнес-аналитики, не знакомые с особенностями программной разработки, вырабатывают свои требования к системе на уровне CIV — с помощью так называемых вычислительно-независимых моделей (Computation Independent Model, CIM). Модели CIM задают основные требования к проекту и включают словари предметной области. Никакие технические характеристики в этих моделях не фиксируются.
Методология MDA описывает не столько моделирование, сколько метамоделирование, предусматривающее большую гибкость в конкретных, прикладных походах к моделированию.
Метамоделирование — способ описания моделей, определяющий механизмы построения конкретных моделей программных систем с помощью базового словаря и набора ограничений, налагаемых на создаваемые модели. Сегодня вместо термина BMDA корпорация Borland применяет новый термин ЕСО. Технология ECO {Enterprise Core Objects) — ключевые корпоративные объекты, — реализующая концепцию MDA, стала наиболее важным улучшением последних версий среды Delphi. Она представлена в Delphi 2006 в виде третьей версии ЕСО III. Каждый компонент ЕСО представляет собой своеобразную программную «обертку» положений концепции MDA. Он является промежуточным слоем между средствами визуального проектирования программных моделей и их конкретной реализацией на языках программирования Delphi и С#.
Практика перевода требований заказчика напрямую в программный код на языке программирования почти всегда страдает неполноценностью. Заказчик мыслит одними понятиями, программист — совсем другими. Поэтому они не подозревают о множестве потенциально возможных проблем. Так, заказчику какие-то моменты автоматизации выбранных процессов могут казаться очевидными. Он о них и не упоминает, считая, что программа выполнит определенный набор действий «сама». Программист, наоборот, подходит к созданию системы с узких технических позиций, программируя только очевидный набор функций, заданный в техническом задании, и редко учитывает все множество взаимосвязей между большим числом требований. В результате в середине проекта выясняется, что архитектуру решения невозможно пополнить новыми требованиями, которые заказчику кажутся простыми, естественными и подразумевавшимися с самого начала. В итоге приходится заново переделывать почти весь проект.
Технология ЕСО переводит процесс согласования требований на модельный уровень. Диаграммы UML обычно хорошо воспринимаются и заказчиком, и исполнителем. Поэтому, хотя использование визуального языка моделирования в MDA не обязательно, почти 100% проектов MDA создаются с применением языка UML.
Построение готового приложения происходит в несколько этапов. Сначала строятся модели PIM, затем выполняется их перенос в модели PSM. Доступные па сегодняшний день продукты автоматизируют эти шаги на 50-70%. Перенос моделей PSM в код конкретного языка программирования автоматизирован почти на 100%.
Еще один подход, настоятельно рекомендуемый группой OMG при использовании подхода MDA, заключается в выделении логики приложения в отдельную, по возможности платформно-независимую структуру. Достигается это использованием языка объектных ограничений OCL, который сегодня считается частью языка UML. Команды OCL встраиваются непосредственно в модель UML, описывая и уточняя аспекты ее работы. Удобство OCL еще и в том, что его выражения напоминают естественный язык (предложения, записанные на английском). Это позволяет сохранять при построении моделей контакт с людьми (например, представителями заказчика), не являющимися специалистами в области программирования.
При реализации сложной логики далеко не всегда удается обойтись стандартными возможностями языков OCL и UML. Всевозможные манипуляции с наборами объектов, их фильтрация и сортировка решают до 70-90% потребностей современных проектов. Такие задачи характерны для многих задач автоматизации деятельности организаций. Технология ЕСО позволяет быстро создавать работающие прототипы, но 10-30% требований все равно приходится программировать нручную5. Для этого используется исходный код на языке Delphi, в который отображается модель UML, сформированная в среде Delphi. Можно выполнить и обратное преобразование: на основе измененного исходного текста получить готовую модель UML.
Физические объекты, структура которых описана с помощью языка UML, a особенности существования — с помощью языка OCL, функционируют в процессе работы приложения в специально выделенной области оперативной памяти, так называемом объектном пространстве. Технология ЕСО способна автоматически отображать модель не только в программный код, но и в код на языке SQL. Он генерируется для построения схемы базы данных, хранящей копию объектного пространства. Поддержка разных СУБД является в ЕСО одной из ключевых технологий. С ее помощью удается сохранять текущее состояние объектного пространства приложения в базе данных и затем, после перезапуска приложения, загружать его и продолжать работу с прерванного места.
Среда Delphi на основе подготовленной модели автоматически формирует схему базы данных с учетом версии и специфики конкретной СУБД. Она автоматически создает в ней все таблицы, нужные для хранения объектного пространства и взаимосвязей между классами, даже если это требует введения дополнительных таблиц. По мере совершенствования модели следует периодически синхронизировать схему базы данных с внесенными в модель модификациями — для этого достаточно нажать одну кнопку. Такой процесс называется в технологии ЕСО эволюционным развитием базы данных.
Стыковка объектного пространства с пользовательским интерфейсом реализуется в ЕСО с помощью дескрипторов. Дескриптор ЕСО — это стыковочная точка (компонент промежуточного уровня), связывающая с помощью выражений OCL элементы модели UML (классы) с программным кодом и внутренней структурой обычного приложения Delphi. Дескрипторы задают способы формирования наборов объектов в объектном пространстве по критериям, заданным выражениями OCL. Они также обеспечивают доступ к ним элементов пользовательского интерфейса, а программному коду предлагают ссылки на объекты ЕСО.