исполнения, конечно, зависят от разработчика). Нередко первый проход компилятора (лексический анализ кода) выполняется параллельно с редактированием кода исходной программы.

2.13 Общие принципы генерации кода

Генерация объектного кода – это перевод компилятором внутреннего представления исходной программы в цепочку символов выходного языка. Генерация объектного кода порождает результирующую объектную программу на языке машинных команд. Внутреннее представление программы может иметь любую структуру в зависимости от реализации компилятора, в то время как результирующая программа всегда представляет собой линейную последовательность команд. Поэтому генерация объектного кода (объектной программы) в любом случае должна выполнять действия, связанные с преобразованием сложных синтаксических структур в линейные цепочки.

Генерация объектного кода выполняется после того, как выполнен синтаксический анализ программы и все необходимые действия по подготовке к генерации кода: распределено адресное пространство под функции и переменные, проверено соответствие имен и типов переменных, констант.

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

Как правило, компилятор выполняет генерацию результирующего кода поэтапно, на основе законченных синтаксических конструкций входной программы:

1) компилятор выделяет законченную синтаксическую конструкцию из текста входной программы,

2) порождает для нее фрагмент результирующего кода и помещает его в текст выходной программы.

3) Затем он переходит к следующей синтаксической конструкции.

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

2.14 Синтаксически управляемый перевод (СУ-схемы).

Работает на базе грамматик V+ α β → ∈ λ Ɐ

Чтобы компилятор мог построить код результирующей программы для синтаксической конструкции входного языка, часто используется метод, называемый синтаксически управляемым переводом – СУ-переводом.

---

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

T( VN, VT₁, VT₂, R, S) – схема СУ-перевода

S ∈ VN

G₁ (VT₁, VN, P_1, S) – входная грамматика

P: A → α

A ∈ VN, α ∈ (VN∪VT₁)*

G₂ (VT₂, VN, P₂, S) – выходная грамматика

P: A → B, B∈ (VN∪VT₂)*

С помощью СУ-перевода можно одновременно с кусочком входной цепочки получать кусочек выходной цепочки.

Пример.

T = {( x, y)}

X ∈ VT₁*, y ∈ VT₂*

T={0ⁿ,1ⁿ, a²ⁿ, b^n-1, n>0}

R: S→ 0S1, aaSb

S→ 01, aa

Таким образом, одновременно с формированием цепочки, состоящей из 0 и 1, будет формироваться выходная цепочка, представляющая собой перевод.

T ({S}, {0,1}, {a,b}, R, S) – схема СУ-перевода

Нетерминалы должны использоваться одни и те и в одинаковом количестве в правилах вывода (слева) и в элементов перевода (справа)

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

1. Определение технологии конструирования программного обеспечения (ПО).

2. Классический жизненный цикл.

3. Макетирование, инкрементная модель, быстрая разработка приложений.

4. Модели качества процессов конструирования.

5. Процесс руководства проектом.

6. Планирование проектных задач.

7. Размерно-ориентированные метрики.

8. Функционально-ориентированные метрики.

9. Выполнение оценки проекта на основе LOC- и FP метрик.

10. Классические методы анализа.

11. Структурный анализ.

12. Диаграммы потоков данных и их описание. - http://poznayka.org/s19868t1.html

13. Методы анализа, ориентированные на структуры данных.

14. Основы проектирования и его особенности, структурирование системы, модульность.

15. Виды связности модулей.

16. Сцепление модулей.

17. Понятие сложности программной системы.

18. Метод структурного проектирования.

19. Типы информационных потоков (преобразование, запрос).

20. Метод проектирования Джексона. - http://lektsii.com/2-19268.html

http://elab.pro/pluginfile.php/999/mod_resource/content/1/06.%20Лекция.%20Проектирование.pdf

https://studfiles.net/preview/1444532/page:31/

21. Унифицированный язык моделирования (UML).

22. Модели реализации объектно-ориентированных программных систем. Компонентные диаграммы и их использование.

23. Автоматизация конструирования визуальной модели программных систем.

1. Определение технологии конструирования программного обеспечения (ПО).

Технология конструирования программного обеспечения (ТКПО)-система инженерных принципов для создания экономичного ПО, которое надежно и эффективно работает в реальных компьютерах.

Термин «конструирование программного обеспечения» описывает детальное создание рабочей программной системы посредством комбинации кодирования, верификации (проверки), модульного тестирования, интеграционного тестирования и отладки.

Данная область знаний связана с другими областями. Наиболее сильная связь существует с проектированием (Software Design) и тестированием (Software Testing). Причиной этого является то, что сам по себе процесс конструирования программного обеспечения затрагивает важные аспекты деятельности по проектированию и тестированию. Кроме того, конструирование отталкивается от результатов проектирования, а тестирование (в любой своей форме) предполагает работу с результатами конструирования. Достаточно сложно определить границы между проектированием, конструированием и тестированием, так как все они связаны в единый комплекс процессов жизненного цикла и, в зависимости отвыбранной модели жизненного цикла и применяемых методов (методологии), такое разделение может выглядеть по-разному.

---

Различают: методы, средства и процедуры ТКПО.

Методы обеспечивают решение задач:

• планирования и оценки проекта;

• анализа системных и программных требований;

• проектирования алгоритмов, структур данных и программных структур;

• кодирования;

• тестирования;

• сопровождения.

Средства (утилиты) ТКПО обеспечивают автоматизированную или автоматическую поддержку методов

Процедуры–соединяют методы и средства в непрерывную технологическую цепь разработки.

Процедуры определяют:

порядок применения методов и средств;

формирование отчетов в соответствии с требованиями;

контроль качества и координирование изменений;

формирование “вех” (промежуточных этапов) для оценки прогресса.

Таким образом, процесс конструирования ПО состоит из последовательности шагов, использующих:

• методы;

• утилиты;

• процедуры.

2. Классический жизненный цикл.

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

Жизненный цикл ПО:

1. Анализ

2. Проектирование

3. Разработка

4. Тестирование

5. Развёртывание

6. Использование

Эмпирический закон:

30% - анализ и проектирование

40% - реализация проекта

30% - откладка и тестирование

Задачи этапа анализа: Составление списка требований к разрабатываемой системе и среде её функционирования. (должны понять, для кого мы должны создать ПО, для специалистов или для широкого круга пользователей, должны понять, к какой платформе мы создаём ПО и т.д)

Ранжировать список требований: реализовать первоочередные требования. Так же выявить несовместимые требования (Например, чтоб одновременно компьютер не был подключён к сети и показывал прогноз погоды в браузере).

Задачи этапа проектирования: Фиксируются методы и методики, используемые для реализации намеченной функциональности, фиксируются необходимые для реализации проекта технологии, определяется состав оборудования, определяется необходимость прототипирования отдельных модулей системы, составления финансового и календарного плана.

Этап разработки:

Проектирование структуру ПО – структуры классов, структуру данных и т.д.

Проектирование интерфейса

Проектирования структуры документации

Тестирование – это, посвящённый обнаружению и устранению ошибок, однако уровень качества проекта закладывается в процессе разработки.

Сопровождение – это внесение изменений в эксплуатируемое

ПО, а так же

• Обучение пользователей

• Информационная поддержка пользователей

• Служба технической поддержки

• Создание новых версий ПО

Плюсы:

• Позволяет предсказать затраты на проект

• Управляемость проекта

• Чёткие сроки сдачи

• Минусы:

---

Минусы:

• Отсутствие гибкости (может измениться внешняя среда, требования заказчика, могут быть обнаружены ошибки в анализе)

• Получается задуманная, а не необходимая система

3. Макетирование, инкрементная модель, быстрая разработка приложений.

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

Основная цель макетирования — снять неопределенности в требованиях заказчика.

Макетирование (прототипирование) — это процесс создания модели требуемого программного продукта.

Основная цель макетирования – снять неопределённости в требованиях заказчика. Макетирование (прототипирование) – это процесс создания моделитребуемого программного продукта. Модель может принимать одну из трёх форм: 1) бумажный макет или макет на основе ПК (изображает или рисует человеко-машинный диалог); 2) работающий макет (выполняет некоторую часть требуемых функций); 3) существующая программа (характеристики которой затем должны быть улучшены). Макетирование начинается со сбора и уточнения требований к создаваемому ПО. Разработчик и заказчик встречаются и определяют все цели ПО, устанавливают, какие требования известны, а какие предстоит доопределить. Затем выполняется быстрое проектирование. В нём внимание сосредоточивается на тех характеристиках ПО, которые должны быть видимы пользователю. Быстрое проектирование приводит к построению макета. Макет оценивается заказчиком и используется для уточнения требований к ПО. Достоинство макетирования: обеспечивает определение полных требований к ПО. Недостатки макетирования: - заказчик может принять макет за продукт; - разработчик может принять макет за продукт. Инкрементная модель является классическим примером инкремент-ной стратегии конструирования. Она объединяет элементы последовательной водопадной модели с итерационной философией макетирования. Каждая линейная последовательность здесь вырабатывает поставляемый инкремент ПО. Например, ПО для обработки слов в 1-м инкременте реализует функции базовой обработки файлов, функции редактирования и документирования; во 2-м инкременте – более сложные возможности редактирования и документирования; в 3-м инкременте – проверку орфографии и грамматики; в 4-м инкременте – возможности компоновкистраницы. Первый инкремент приводит к получению базового продукта, реализующего базовые требования (правда, многие вспомогательные требования остаются нереализованными). План следующего инкремента предусматривает модификацию базового продукта, обеспечивающую дополнительные характеристики ифункциональность. По своей природе инкрементный процесс итеративен, но в отличие от макетирования, инкрементная модель обеспечивает на каждом инкременте работающий продукт.

---

Модель быстрой разработки приложений (Rapid Application Development) — второй пример применения инкрементной стратегии конструирования, концепция,  созданная для достижения более высокой скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию.  Технология RAD предусматривает активное привлечение заказчика уже на ранних стадиях, а также получение качественной документации, обеспечивающей удобство эксплуатации и сопровождения системы. Это означает, что дополнительные затраты на сопровождение сразу после поставки будут значительно меньше. Таким образом, полное время от начала разработки до получения приемлемого продукта при использовании этого метода значительно сокращается. Быстрое выполнение проекта позволяет создать систему, отвечающую требованиям сегодняшнего дня

Принципы RAD технологии направлены на обеспечение трёх основных её преимуществ — высокой скорости разработки, низкой стоимости и высокого качества. Достигнуть высокого качества программного продукта весьма непросто и одна из главных причин возникающих трудностей заключается в том, что разработчик и заказчик видят предмет разработки (ПО) по-разному.

• Инструментарий должен быть нацелен на минимизацию времени разработки.

• Создание прототипа для уточнения требований заказчика.

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

• Минимизация времени разработки версии, за счёт переноса уже готовых модулей и добавления функциональности в новую версию.

• Команда разработчиков должна тесно сотрудничать, каждый участник должен быть готов выполнять несколько обязанностей.

• Управление проектом должно минимизировать длительность цикла разработки

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

4. Модели качества процессов конструирования.

В современных условиях, условиях жесткой конкуренции, очень важно гарантировать высокое качество вашего процесса конструирования ПО. Такую гарантию дает сертификат качества процесса, подтверждающий его соответствие принятым международным стандартам. Каждый такой стандарт фиксирует свою модель обеспечения качества. Наиболее авторитетны модели стандартов ISO 9001:2000, ISO/ IEC 15504 и модель зрелости процесса конструирования ПО (Capability Maturity Model — СММ) Института программной инженерии при американском университете Карнеги-Меллон.

Модель стандарта ISO 9001:2000 ориентирована на процессы разработки из любых областей человеческой деятельности. Стандарт ISO/IEC 15504 специализируется на процессах программной разработки и отличается более высоким уровнем детализации. Достаточно сказать, что объем этого стандарта превышает 500 страниц. Значительная часть идей ISO/IEC 15504 взята из модели СММ.

---

Смотрите также файлы

• Рабочая тетрадь по теоретической механике 3.pdf

• Информационные технологии. Лекции.docx

• Инструктаж по технике безопасности на уроках информатики.docx

• Тема 1.1 Основные понятия теории множеств.docx

• ЧМ Контрольная работа 1.docx