Реализация

To 1000 do f(x)

Пусть для f(x) нужно 4 регистра. А если свободны только 2? Перед каждым вызовом нужно освобождать 2 регистра, а после вызова – их восстанавливать. Получаем "толкотню" регистров.

Решение: выгружаем регистры только когда стек близок к переполнению, загружаем обратно только когда стек близок к опустошению. Временем подкачки-откачки регистров можно пренебречь.

Пример.

Пусть процедуре А нужно 7 регистров, процедуре В – 8, процедуре С – 3. Пусть из процедуры А мы вызываем В, потом из В вызываем С. Сначала свободны все 16 регистров. При вызове А, потом В занимаем 15 из них. Процедура С "видит", что ей не хватит двух регистров. Выгружаем регистры не В, а А. При возвращении из С в В все регистры В будут с стеке.

Итог:

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

1. Понятие технологии программирования

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

В ТП входит:

1. архив с контролируемым доступом (для предотвращения внесения изменений в последний момент (пусть даже и из лучших побуждений), для отчуждения «программы от её автора»)

2. Машинная документация (на машинном носителе) – должна быть актуальна, должны оперативно вноситься исправления

3. Использование инструментальных средств. (в частности программы можно писать и отлаживать на инструментальных ЭВМ, а уже затем транслировать под целевые – тогда возможна параллельная разработка)

4. Соглашение о связях (напр. все рассматривают стек слева направо, возвращают значение через регистр R10 (даже если напр. кто-то вдруг выяснит, что через R7 быстрее), каждая процедура должна сохранять регистры…).

//Нельзя всё сводить только к программному инструментарию.

1. Жизненный цикл программы

Наша задача, чтобы цикл был конечный.

Первая модель – водопадная (waterfall)(не возвращаемся к предыдущему этапу):

Разработка сист. Требований (постановка)

Разработка треб.к ПО

Анализ(Планирование (люди, ресурсы))

Проектирование (структура, связи)

Отладка

Документирование

Сдача

Сопровождение

Введено понятие прототипирования. Откат только на одну стадию назад.

Коллектив последовательно разрабатывает проект – от исходной концепции до комплексного тестирования. Эта модель требует определить опорные точки, в которых будет оцениваться сделанное и решаться вопрос о том, можно ли двигаться дальше (Так называемая оценка рисков). Такой подход хорош для проектов, в которых требования легко формулируются с самого начала, но не годится для сложных, когда требования могут неоднократно меняться. Кроме того, водопадная модель вынуждает готовить огромную массу документации и требует единообразной процедуры оценки результатов на каждом этапе. Эти две особенности часто приводят к синдрому "аналитического паралича", напряжённым отношениям между разработчиками, заказчиками и пользователями.

Циклическая модель с возвратами (если что-то не устраивает, возвращаемся к предыдущим этапам).

Спиральная модель: разработка приложения выглядит как серия последовательных итераций. На первых этапах уточняются спецификации продукта, на последующих добавляются новые возможности и функции. Цель этой модели – как можно раньше выявить риски и уже в первых версиях продукта устранить связанные с ними проблемы. В силу своей итеративной природы спиральная модель допускает корректировки по ходу работы, что способствует улучшению продукта. При большом числе итераций разработка по этой модели нуждается в глубокой автоматизации всех процессов, иначе она становится неэффективной. На практике у заказчиков и пользователей иногда возникает ощущение нестабильности продукта, так как они не успевают уследить за слишком быстрыми изменениями в нём. Наконец, во многих проектах, управляемых по спиральной модели, нет чётко определённого критерия окончания работы, поэтому разработка может длиться бесконечно, поглощая финансовые ресурсы и не давая желаемой отдачи.

Обычно также используют быстрое прототипирование(rapid prototype): создаётся начальный прототип с реализованными основными функциями, и показывается заказчику. Если последнего все устраивает, то потом из прототипа строится продукт. Данная модель позволяет уточнить постановку задачи. Хорошо бы иметь мощную технологию для этого(генерация форм например)

1. Постановка задачи, оценка осуществимости

Обычно заказчик выдаёт две-три страницы текста задания и сразу же просит оценить время исполнения заказа и его стоимость. Надо быть сумасшедшим, чтобы с этим согласиться. Не редки случаи, когда целые коллективы ошибаются в пять-десять раз и попадают в кабалу или теряют профессиональную репутацию. Чтобы избежать такой ситуации, нужно предложить заказчику оформить начальный договор на две-четыре недели, с тем, чтобы два-три системных аналитика разобрались в задаче, с помощью каких-то инструментальных средств выполнили декомпозицию системы на компоненты, прикинули возможные объёмы этих компонент и, соответственно, время их реализации. Такая начальная стадия ЖЦП называется "оценкой осуществимости". A{ST}P – проверка корректность её решения, на практике невозможно.

Постановка задачи – наиболее творческая часть ЖЦП, которая содержит в себе почти что философские проблемы.

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

Разрешают это противоречие с помощью постепенного уточнения поведения, как системы, так и её окружения (т.е. делают декомпозицию).

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

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

1. Планирование

При планировании полезно строить сетевой график. Есть 2 выдел. вершины - начало и конец. Дуги – работы (вместе с длительностью), вершины – промежуточные состояния (в вершина написаны действия в совершенном виде – «оборудование закуплено», «коллектив сформирован»). На таком графике видна последовательность работ, их длительность.

Критический путь – самый длинный путь от начала до конца.

Все ветви должны быть равнонагружены (хотя это тоже плохо – нет резерва).

Если сроки срываются, то либо увеличивать ресурсы, либо раздвигать сроки.

Планирование неразрывно связано с управлением.

Добавлять людей, деньги («стимулирование»). //У МикроМягких же за срыв сроков лишают премии весь коллектив.

Кроме сетевого графика можно также строить диаграмму Ганта:

-По вертикали выписываем работы, по горизонтали – сроки, ставим промежутки исполнения – удобно смотреть, что должно быть завершено в настоящий момент, какие работы идут. //Диаграмма Ганта более удобна при управлении, чем при планировании.

Управление должно быть постепенным, регулярным. Должен быть запас ресурсов.

Если горит работа на критическом пути, то надо сокращать сроки на последующие работы (увеличивать технологии производства).

//Основа всего – ТЕХНИЧЕСКАЯ ВООРУЖЕННОСТЬ

1. Управление

Управление – целенаправленная деятельность по достижению некоторой цели.

При управлении полезно использовать сетевой график, построенный при планировании. Дуги – работы (вместе с длительностью), вершины – промежуточные состояния (в вершина написаны действия в совершенном виде – «оборудование закуплено», «коллектив сформирован»). На таком графике видна последовательность работ, их длительность.

Критический путь – самый длинный путь от начала до конца.

Все ветви должны быть равнонагружены (хотя это тоже плохо – нет резерва).

Если сроки срываются, то либо увеличивать ресурсы, либо раздвигать сроки.

Планирование неразрывно связано с управлением.

Добавлять людей, деньги («стимулирование»). //У МикроМягких же за срыв сроков лишают премии весь коллектив.

Кроме сетевого графика можно также строить диаграмму Ганта:

-По вертикали выписываем работы, по горизонтали – сроки, ставим промежутки исполнения – удобно смотреть, что должно быть завершено в настоящий момент, какие работы идут. //Диаграмма Ганта более удобна при управлении, чем при планировании.

Управление должно быть постепенным, регулярным. Должен быть запас ресурсов.

Если горит работа на критическом пути, то надо сокращать сроки на последующие работы (увеличивать технологии производства).

//Основа всего – ТЕХНИЧЕСКАЯ ВООРУЖЕННОСТЬ