Файл: Учебное пособие.doc

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 04.12.2020

Просмотров: 6456

Скачиваний: 15

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

СОДЕРЖАНИЕ

Введение

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

1.1.Основные этапы развития технологии разработки

1.1.1.Первый этап – «стихийное» программирование.

1.1.2.Второй этап – структурный подход к программированию (60-70-е годы XX в)

1.1.3.Третий этап – объектный подход к программированию (с середины 80-х годов до нашего времени)

1.1.4.Четвертый этап – компонентный подход и CASE-технологии (с середины 90-х годов до нашего времени)

1.1.5.Пятый этап – разработка, ориентированная на архитектуру и CASE-технологии (с начала XXI в. до нашего времени)

1.2.Эволюция моделей жизненного цикла программного обеспечения

1.2.1.Каскадная модель

1.2.2.Спиральная модель

1.2.3.Макетирование

1.2.4.Быстрая разработка приложений

1.2.5.Компонентно-ориентированная модель

1.2.6.XP-процесс

1.3.Стандарты, регламентирующие процесс разработки программного обеспечения

1.3.1.ГОСТ Р ИСО 9000-2001. Системы менеджмента качества. Основные положения и словарь

1.3.1.1.Предисловие

1.3.1.2.Введение

1.3.1.3.Область применения

1.3.1.4.Основные положения систем менеджмента качества

1.3.2.ГОСТ Р ИСО/МЭК ТО 15504

1.3.2.1.Обзор

1.3.2.2.Область применения

1.3.2.3.Состав ИСО/МЭК ТО 15504

1.3.2.4.Связь с другими международными стандартами

1.3.3.ГОСТ Р ИСО/МЭК 12207-99. Информационная технология. Процессы жизненного цикла программных средств

1.3.3.1.Введение

1.3.3.2.Область применения

1.3.3.3.Прикладное применение настоящего стандарта

2.Анализ проблемы и постановка задачи

2.1.Введение в системный анализ

2.2.Системные ресурсы

2.3.Анализ проблемы и моделирование предметной области с использованием системного подхода

2.3.1.Основные положения

2.3.2.Этап 1. Достижение соглашения об определении проблемы

2.3.3.Этап 2. Выделение основных причин – проблем, стоящих за проблемой

2.3.3.1.Устранение корневых причин

2.3.4.Этап 3. Выявление заинтересованных лиц и пользователей

2.3.5.Этап 4. Определение границ системы-решения

2.3.6.Этап 5. Выявление ограничений, налагаемых на решение

2.4.Методология ARIS

2.4.1.Организационная модель

2.4.2.Диаграмма цепочки добавленного качества

2.4.3.Модели eEPC

2.5.Стандарты IDEF0 - IDEF3

2.5.1.Методология описания бизнес процессов IDEF3

2.5.1.1.Синтаксис и семантика моделей IDEF3

2.5.1.2.Требования IDEF3 к описанию бизнес-процессов

2.5.2.Методология функционального моделирования IDEF0

2.5.2.1.Синтаксис и семантика моделейIDEF0

2.5.2.2.Построение моделей IDEF0

3.Анализ требований и их формализация

3.1.Методы определения требований

3.1.1.Интервьюирование

3.1.1.1.Этапы проведения интервью

3.1.2.Мозговой штурм и отбор идей

3.1.2.1.Генерация идей

3.1.2.2.Отбор идей

3.1.3.Совместная разработка приложений (JAD – Joint application design)

3.1.3.1.Роли в сеансах JAD

3.1.3.2.Сеансы JAD

3.1.3.3.Результаты проведения сеанса JAD

3.1.3.4.Недостатки метода JAD

3.1.4.Раскадровка

3.1.4.1.Типы раскадровок

3.1.5.Обыгрывание ролей

3.1.5.1.Суть метода обыгрывания ролей

3.1.5.2.Сценарный просмотр

3.1.6.CRC-карточки (Class-Responsibility-Collaboration, класс-обязанность-взаимодействие)

3.1.7.Быстрое прототипирование

3.2.Формализация требований

3.2.1.Метод вариантов использования и его применение

3.2.1.1.Построение модели вариантов использования

3.2.1.2.Спецификация вариантов использования

3.2.1.3.Преимущества

3.2.2.Псевдокод

3.2.3.Конечные автоматы

3.2.4.Графические деревья решений

3.2.5.Диаграммы деятельности

3.3.Техническое задание (ГОСТ 34.602-89)

3.3.1. Общие сведения

3.3.2.Назначение и цели создания (развития) системы

3.3.2.1.Назначение системы

3.3.2.2.Цели создания системы

3.3.3.Характеристики объекта автоматизации

3.3.4.Требования к системе

3.3.4.1.Требования к системе в целом

3.3.4.2.Требования к функциям (задачам)

3.3.4.3.Требования к видам обеспечения

3.3.5.Состав и содержание работ по созданию системы

3.3.6.Порядок контроля и приемки системы

3.3.7.Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

3.3.8.Требования к документированию

3.3.9.Источники разработки

4.Архитектуры программных систем

4.1.Планирование архитектуры

4.1.1.Архитектурно-экономический цикл

4.1.2.Программный процесс и архитектурно-экономический цикл

4.1.2.1.Этапы разработки архитектуры

4.1.3.Суть программной архитектуры

4.1.3.1.Архитектурные образцы, эталонные модели и эталонные варианты архитектуры

4.1.3.2.Архитектурные структуры и представления

4.2.Проектирование архитектуры

4.2.1.Атрибутный метод проектирования

4.2.1.1.Этапы ADD

4.2.2.Создание макета системы

4.3.Документирование программной архитектуры

4.3.1.Варианты применения архитектурной документации

4.3.2.Представления

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

4.3.3.Документирование представления

4.3.3.1.Документирование поведения

4.3.3.2.Документирование интерфейсов

4.4.Методы анализа архитектуры

4.4.1.Метод анализа компромиссных архитектурных решений – комплексный подход к оценке архитектуры

4.4.1.1.Этапы АТАМ

4.4.2.Метод анализа стоимости и эффективности — количественный подход к принятию архитектурно-проектных решений

4.4.2.1.Контекст принятия решений

4.4.2.2.Реализация СВАМ

5.Технология MDA.

5.1.Использование архитектуры, управляемой моделью

5.1.1.Концепция архитектуры, управляемой моделью

5.1.2.Модельные точки зрения и модели MDA

5.2.Язык объектных ограничений OCL

5.2.1.Типы данных и операции OCL

5.2.2.Инфиксная форма записи выражений OCL

5.2.3.Последовательности доступа к объектам в языке OCL

5.2.4.Операции над коллекциями

5.2.4.1.Стандартные операции

5.2.4.2.Операция select

5.2.4.3.Операция reject

5.2.4.4.Выделение элементов коллекции

5.2.4.5.Упорядочение набора

5.2.4.6.Логические итераторы

5.2.4.7.Операции для работы со строками

5.2.4.8.Работа с датами

5.3.Возможности технологии ECO

5.3.1.Введение в технологию ЕСО

5.3.2.Модель ЕСО

5.3.3.Пространство имен ЕСО

5.4.Разработка приложений на основе ECO

5.4.1.Этапы создания приложения по технологии ECO

5.4.2.Создание простого MDA-приложения

5.4.2.1.Создание модели UML

5.4.2.2.Создание интерфейса

5.4.2.3.Связывание интерфейса с моделью

5.4.2.4.Создание логики на OCL

6.Документирование программных систем в соответствии с ГОСТ

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

6.1.1.Предисловие

6.1.2.Область применения

6.1.3.Роль руководителей

6.1.4.Функции программной документации

6.1.4.1.Информация для управления

6.1.4.2.Связь между задачами

6.1.4.3.Обеспечение качества

6.1.4.4.Инструкции и справки

6.1.4.5.Сопровождение программного обеспечения

6.1.4.6.Исторические справки

6.1.5.Установление стратегии документирования

6.1.6.Определение стандартов и руководств по документированию

6.1.6.1.Выбор модели жизненного цикла программного обеспечения

6.1.6.2.Определение типов и содержания документов

6.1.6.3.Определение качества документов

6.1.6.4.Определение форматов документов

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

6.1.7.Установление процедуры документирования

6.1.8.Распределение ресурсов для документирования

6.1.8.1.Персонал

6.1.8.2.Средства

6.1.8.3.Финансирование

6.1.9.Планирование документирования

6.2.Требования к содержанию документов на автоматизированные системы

6.2.1.Общие положения

6.2.2.Требования к содержанию документов по общесистемным решениям

6.2.2.1.Ведомость эскизного (технического) проекта

6.2.2.2.Пояснительные записки к эскизному, техническому проектам

6.2.2.3.Схема функциональной структуры

6.2.2.4.Описание автоматизируемых функций

6.2.2.5.Описание постановки задачи (комплекса задач)

6.2.2.6.Локальная смета и локальный сметный расчет

6.2.2.7.Паспорт

6.2.2.8.Формуляр

6.2.2.9.Проектная оценка надежности системы

6.2.2.10.Общее описание системы

6.2.2.11.Программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистем, систем)

6.2.3.Требования к содержанию документов с решениями по организационному обеспечению

6.2.3.1.Описание организационной структуры

6.2.3.2.Методика (технология) автоматизированного проектирования

6.2.3.3.Технологическая инструкция

6.2.3.4.Руководство пользователя

6.2.3.5.Описание технологического процесса обработки данных

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

6.2.4.1.Описание программного обеспечения

6.2.5.Другие разделы

6.3.Принципы разработки руководства программиста

6.3.1.Общие положения

6.3.2.Содержание разделов

6.4.Разработка руководства пользователя

6.4.1.Общие замечания

6.4.2.Содержание разделов руководства

6.4.2.1.Общие сведения

6.4.2.2.Описание применения

6.4.2.3.Требования к процедурам функционирования системы

Заключение

Библиографический список

Практика перевода требований заказчика напрямую в программный код на языке программирования почти всегда страдает неполноценностью. Заказчик мыслит одними понятиями, программист — совсем другими. Поэтому они не подозревают о множестве потенциально возможных проблем. Так, заказчику какие-то моменты автоматизации выбранных процессов могут казаться очевидными. Он о них и не упоминает, считая, что программа выполнит определенный набор действий «сама». Программист, наоборот, подходит к созданию системы с узких технических позиций, программируя только очевидный набор функций, заданный в техническом задании, и редко учитывает все множество взаимосвязей между большим числом требований. В результате в середине проекта выясняется, что архитектуру решения невозможно пополнить новыми требованиями, которые заказчику кажутся простыми, естественными и подразумевавшимися с самого начала. В итоге приходится заново переделывать почти весь проект.

Технология ЕСО переводит процесс согласования требований на модельный уровень. Диаграммы 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. Они также обеспечивают доступ к ним элементов пользовательского интерфейса, а программному коду предлагают ссылки на объекты ЕСО.

5.2.Язык объектных ограничений OCL

Один из самых серьезных и справедливо критикуемых недостатков языка моделирования UML — предоставление разработчику только визуальных средств моделирования. Эти средства абстрактны и поэтому далеко не всегда способны точно и формально отразить тот или иной нюанс функционирования проектируемой системы. В результате проектировщик не находит достаточно выразительных средств, позволяющих уточнить ограничения на применение создаваемых структур, специфицировать способы и нюансы их внутреннего функционирования, ввести условия использования и так далее. Конечно, можно представить эти особенности программным кодом конкретной среды программирования. Однако язык UML нацелен, прежде всего, на создание платформно-независимых моделей. Поэтому применяемый для этого текстовый язык, связанный с моделями UML, как минимум, тоже должен быть независим от операционной системы и среды разработки.


В начале 1990-х годов в корпорации IBM разрабатывалась методика объектно-ориентированного анализа и проектирования Syntropy. Она включала математический язык текстовых описаний элементов визуальных моделей, который оказался сложен для массового практического использования.

Впоследствии на его основе был создан язык объектных ограничений ОСЬ (Object Constraint Language), который применялся тогда как язык моделирования. Сильной стороной языка OCL оказалась независимость от платформы реализации и легкая адаптация к разным средам программирования. Он активно применялся для описания особенностей объектных информационных систем и в 1997 году вошел в стандарт языка UML 1.1.

До появления языка OCL в системах визуального моделирования при уточнении ограничений на диаграммах UML применялись комментарии или рекомендации на естественном языке. Они нередко трактовались неоднозначно.

Язык OCL снял множество проблем при проектировании моделей UML. Он предоставил разработчику набор формальных средств взаимодействия с объектами создаваемого приложения. Со временем язык OCL перерос границы стандарта UML. Он нередко задействуется как универсальный и, главное, платформ-но-независимый язык описания бизнес-логики. Например, сценарии OCL можно выделять и настраивать в проекте независимо от программного кода на конкретном языке.

Язык OCL не является языком программирования. Он предназначен для формального определения выражений, обрабатывающих объекты. Выражение OCL обычно привязано к определенному классу UML и задает множество экземпляров этого класса. Команды OCL выполняют также фильтрацию этого множества или, например, определяют число его элементов.

Язык OCL содержит развитые средства манипуляции над множествами объектов, поэтому он хорошо подходит для решения задач, где обычно применяется язык запросов к реляционным базам данных SQL. Язык OCL позволяет организовывать запросы с большей эффективностью и на более высоком, модельном уровне абстракции, нежели язык SQL.

Выражение OCL фактически задает условие, которому должны удовлетворять все экземпляры соответствующего объекта UML. Результатом выполнения выражения OCL является множество объектов, удовлетворяющих этому условию. Условие, которое задается выражением OCL, называется инвариант. Оно представляет собой набор правил или шаблон, накладываемый на описание объекта. Значением инварианта является логическая величина (True или False). Выражения OCL встраиваются в модели UML или задаются в сопроводительной документации.

Язык OCL надежен и безопасен. Стандартом гарантируется, что любое его выражение будет вычислено без побочных эффектов и не окажет влияния на части модели (ни на какие ее состояния, значения или связи). Среда, вычисляющая выражение OCL, просто определяет результирующее значение, которое может впоследствии использоваться (хотя это и не обязательно). Сам язык OCL может применяться для реализации бизнес-логики, управления процессами и других задач только в качестве средства расчета выражений.


Привязка выражения OCL к объекту UML происходит через так называемое объявление контекста. В начале выражения задействуется наименование нужного класса объекта. Может также указываться ключевое слово self (ссылка на текущий объект). Оно допускается, если контекст вычисляемого выражения однозначен, очевиден и может быть связан с выражением автоматически.

5.2.1.Типы данных и операции OCL

В языке OCL используется четыре основных типа данных — значения могут быть целыми, вещественными (с плавающей запятой), логическими и строковыми. Над числами определены стандартные арифметические операции: сложение (знак +), вычитание (-), умножение (*), деление (/). Над значениями всех типов допускаются операции сравнения: меньше (<), больше (>), меньше или равно (<=), больше или равно (>=), не равно (<>), равно (=). Значения логических типов можно обрабатывать с помощью логических операций or (ИЛИ), and (И), not (HE), хоr (исключающее ИЛИ), а также операции implies. Операция implies представляет собой особую форму логической операции И, результат которой зависит от порядка операндов: X implies Y – это не всегда то же самое, что Y implies X.

5.2.2.Инфиксная форма записи выражений OCL

В язык OCL входит ряд операций, которые являются своеобразными аналогами стандартных функций языка Delphi. Только записываются они не как функции Delphi (имя идентификатора и параметры в круглых скобках), а в так называемой инфиксной записи, которая напоминает форму записи обычных арифметических выражений.

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

Типичное выражение OCL представляет собой цепочку элементов, ссылок и вызовов операций, которые последовательно, начиная с левого края выражения и до его правого края, обрабатывают значение, полученное к моменту их вызова. Функциональные элементы и операции языка OCL применяются к аргументу, расположенному левее. Они записываются справа от него, через точку. Вторым аргументом операции или вторым параметром функции OCL считается элемент, расположенный правее — его заключают в круглые скобки.

Так, для действительных чисел можно использовать операцию abs для определения модуля числа, или операцию round для округления. Однако эта операция записывается не слева, как принято в языках программирования, а справа от обрабатываемого значения и через точку. Само значение, соответственно, указывается слева от имени функции и считается ее первым аргументом. Так как второй параметр для данной операции не нужен, результат ее работы можно передать далее, поставив еще одну точку, вслед за которой можно записать очередную функцию.

Пусть, например, требуется округлить число 123,45 с помощью функции round. Соответствующее выражение OCL записывается следующим образом:


123 .45.round

Получить модуль отрицательного числа -123 с помощью функции abs можно так:

-123.abs

Если операция OCL использует два аргумента, второй из них заключается в круглые скобки, как обычный параметр. Например, операция max по выбору максимального из значений х и у запишется следующим образом:

х.mах(у)

Для логической обработки язык OCL предлагает несложную форму условного оператора. Такой оператор фактически представляет собой вычисляемое выражение и записывается следующим образом:

if условие then выражение-1 else выражение-2 endif

Если условие истинно, то вычисляется выражение-l, и результатом условного оператора считается его значение. В противном случае вычисляется выражение-2 и результатом считается уже его значение.

5.2.3.Последовательности доступа к объектам в языке OCL

Выражение OCL возвращает результат, который может быть: экземпляром одного из базовых типов; экземпляром одного из классов модели; метаинформацией (сведениями об определенном типе данных); набором или коллекцией экземпляров одного класса. Элементы такой коллекции могут быть упорядочены или неупорядочены. Внутри коллекции допускаются одинаковые экземпляры. Если к обычным, скалярным, значениям операции OCL применяются через точку (символ .), то к коллекциям — через комбинацию символов ->.

Для доступа к полям определенного объекта в языке OCL применяется запись, в которой сначала следует имя объекта, затем точка и имя поля объекта. Например, если имеется объект computer (экземпляр класса Computer), а в этом классе описано поле Mouse, то обращение к полю Mouse записывается следующим образом:

Computer.Mouse

Если у поля Mouse (экземпляра класса Mouse) в свою очередь имеются внутренние поля, то и к ним можно обращаться, продолжая запись через точку:

Computer.Mouse.Position

Поля объектов в выражении OCL могут быть не скалярными значениями, а коллекциями. Для того чтобы получить (выбрать) все существующие в программе на данный момент экземпляры определенного типа, используется стандартная операция allinstances. Например, все созданные в приложении экземпляры класса Computer можно получить следующим выражением:

Computer.allIinstances

Результатом такого выражения будет не один объект, а коллекция, набор экземпляров класса computer. Соответственно, запись:

Computer.allInstances.Mouse

формирует коллекцию значений — экземпляров класса Mouse, входящих, в свою очередь, в состав класса Computer (физически — в текущее множество экземпляров этого класса).

5.2.4.Операции над коллекциями

Рассмотрим основные операции языка OCL, которые можно применять к коллекциям. Такие операции иногда называют итераторами. Они чаще всего задействуются в моделях ЕСО для описания логики работы программ и формирования наборов записей, отображаемых на экране. Эти операции записываются с использованием операции ->.

5.2.4.1.Стандартные операции

Для выполнения операций над коллекциями язык OCL предлагает ряд стандартных функций: