TRPO

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

Выход – материал или информация, которая производится работой. Механизм – ресурсы, которые выполняют работу.

Процесс моделирования может быть разделен на несколько этапов: опрос экспертов, создание диаграмм и моделей, распространение документации, оценка адекватности моделей и принятие их для дальнейшего использования.

Полномочия в SADT:

-Авторы. Разработчики, занятые изучением требований и ограничений системы и их описаний с помощью SADT.

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

-Читатели. Лица, занятые анализом проектов, разрабатываемых другими специалистами, но не обязанные их комментировать.

-Технический комитет. Группа опытных технических специалистов, анализирующих проект на высших уровнях его описания.

-Библиотекарь проекта. Лицо, отвечающее за ведение файлов проекта.

-Руководитель проекта. Лицо, несущее ответственность за техническую разработку проекта.

-Главный аналитик. Основной консультант по использованию SADT. Он хорошо понимает особенности использования системы и выдает рекомендации по ее применению.

С точки зрения SADT модель может быть сосредоточена либо на функциях системы, либо на

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

Достоинства:

-система способствует организации коллективной работы, а также установлению соглашений относительно спецификаций на ранних этапах проектирования;

-письменные отчеты технических комитетов позволяют проводить непрерывный контрольный анализ системы, что немаловажно при осуществлении испытаний системы;

-эффективным средством получения специальной информации являются доклады экспертов;

-система позволяет на ранних этапах принять основные решения высокого уровня, что создает прочный фундамент для вырабатывания последующих решений более низкого уровня;

-использование SADT дает возможность осмыслить разрабатываемую систему лицам, не являющимся специалистами по программному обеспечению;

-предусмотрены легко доступные средства контроля хода проектирования.

Недостатки:

-слишком общее определение примитивов моделирования;

-изолированность методологии от современных процессов разработки ПО;

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

10.Структурное проектирование. Методика Джексона.

В основе структурного проектирования лежит последовательная декомпозиция, целенаправленное структурирование на отдельные составляющие. Начало развития структурного проектирования алгоритмов и программ падает на 60-е годы. Методы структурного проектирования представляют собой комплекс технических и организационных принципов системного проектирования.

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

Типичными методами структурного проектирования являются:

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

1.Определяются цели автоматизации предметной области и их иерархия;

2.Устанавливается состав приложений (задач обработки), обеспечивающих реализацию поставленных целей.

3.Уточняется характер взаимосвязи приложений и их основные характеристики.

4.Определяются необходимые для решения задач функции обработки данных.

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

Рис 1. Нисходящий метод.

-Модульное программирование. Основано на понятии модуля – логически взаимосвязанной совокупности функциональных элементов, оформленных в виде отдельных программных модулей. Каждый модуль состоит из спецификации и тела. Спецификации определяют правила использования модуля, а тело – способ реализации процесса обработки. Модуль характеризует:

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

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

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

4.слабые информационные связи с другими программными модулями – обмен информацией между модулями должен быть по возможности минимизирован.

5.обозримый по размеру и сложности программный элемент.

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

-функционально-ориентированные методы – последовательное разложение задачи или целостной проблемы на отдельные, достаточно простые составляющие, обладающие функциональной определенностью;

-методы структурирования данных.

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

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

Структурный подход проектирования использует:

-диаграммы потоков данных (информационно-технологические схемы) – показывают процессы и информационные потоки между ними с учетом «событий», инициирующих процессы обработки;

-интегрированную структуру данных предметной области (инфологическая модель, ER-

модель);

-диаграммы декомпозиции – структура и декомпозиция целей, функций управления, приложений;

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

Методика Джексона.

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

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

Конструкции содержащиеся в нотациях:

-Конструкция последовательности. Показывает, что стоящий выше по иерархии объект состоит из объектов, лежащих ниже, в указанном порядке слева направо.

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

-Конструкция повторения. Показывает, что объект состоит из нуля или более объектов, лежащих ниже по иерархии. Конструкция повторения включает одну и только одну конструкцию второго уровня.

Этапы выполнения по методике Джексона:

-изобразить структуры входных и выходных данных.

-идентифицировать связи обработки со структурами данных.

-сформировать структуру программы на основании структур данных и соответствий.

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

-написать программу в структурированном изложении.

11.Стратегия объединения различных методов проектирования.

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

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

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

2.выполнение испытаний. На каждом шаге совершенствования модуля осуществляется его аттестация.

3.осуществление строгого контроля нал ходом разработки. Вся выходная документация – проекты программ, исходные программы, инструкции пользователю и т. д.- должна быть формально утверждена. Внесение любых изменений в документацию и библиотеки программ должно строго контролироваться и осуществляться лишь с разрешения соответствующих должностных лиц.

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

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

6.использование немногочисленного штата, укомплектованного квалифицированными работниками. Хорошие результаты работы дает использование принципа организации бригады главного программиста.

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

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

- дефицит специалистов; - нереалистичные сроки и бюджет;

- реализация несоответствующей функциональности; - разработка неправильного пользовательского интерфейса;

- «золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей; - непрекращающийся поток изменений;

- нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию;

- недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами;

-недостаточная производительность получаемой системы;

-«разрыв» в квалификации специалистов разных областей знаний.

Рис.1 Оригинальная спиральная модель жизненного цикла разработки по Боэму.

Спиральная модель обладает рядом преимуществ:

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

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

3.Модель предоставляет механизмы достижения необходимых параметров качества как составную часть процесса разработки программного продукта. Эти механизмы строятся на основе идентификации всех типов целей (требований) и ограничений на всех “циклах” спирали разработки. Например, ограничения по безопасности могут рассматриваться как риски на этапе специфицирования требований.

4.Модель уделяет специальное внимание предотвращению ошибок и отбрасыванию ненужных, необоснованных или неудовлетворительных альтернатив на ранних этапах проекта. Это достигается явно определенными работами по анализу рисков, проверке различных характеристик создаваемого продукта (включая архитектуру, соответствие требованиям и т.п.) и подтверждение возможности двигаться дальше на каждом “цикле” процесса разработки.

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

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

7.Модель не проводит различий между разработкой нового продукта и расширением (или сопровождением) существующего. Этот аспект позволяет избежать часто встречающегося отношения к поддержке и сопровождению как ко “второсортной” деятельности. Такой подход предупреждает большого количество проблем, возникающих в результате одинакового уделения внимания как обычному сопровождению, так и критичным вопросам, связанным с расширением функциональности продукта, всегда ассоциированным с повышенными рисками.

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

12.Язык проектирования программ PDL. Операторы выбора. Операторы цикла. Операторы описания данных. Операция ввода-вывода и вызова процедур.

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

Такой язык должен быть способен выразить идеи проектирования на всех этапах разработки системы, начиная с описания системы на высоком уровне, затем на промежуточном уровне - уровне операций - и, возможно, даже на более низком уровне, если такая необходимость возникнет. Язык должен обеспечивать проектирование управляющей логики и структуры данных, а также запись комментариев. Проекты программ, записанные на этом языке, должны быть простыми в обращении. Для всех этих целей вводится множество соглашений, позволяющих представить проекты программного обеспечения в текстовой форме. Эти соглашения определяет язык проектирования программ Process Design Language, сокращенно называемый PDL.

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

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

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

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

Язык PDL включает шесть групп операторов.

Оператор выбора.

1.if expression; then action1; else action2;

2.do case (expression); /index1/ action1; /index2/ action2;

……

/indexN/ actionN; Else action n+1;

Оператор цикла.

1. do while (expression);

Набор операторов;

end;

2. do переменная=выражение1 to выражение2 by выражение3; Набор операторов;

end;

Оператор описания данных. Declare name attributes;

Имена объявляются для переменных со списками атрибутов. Атрибуты могут быть стандартными типами данных языка программирования (real, float, integer, и др.) или структурами данных высокого уровня(рис 1.).

Рис.1 структура данных PDL.

Для определения сложных структур данных используются структуры типа:

Это соответствует структуре дерева, изображенного на рисунке 1. Для ссылки на элементы подобных структур используется система уточнения имен. Таким образом, на узел С можно ссылаться как на A.B.C, хотя к С можно обращаться и непосредственно, если это имя используется однозначно.

Другие операторы.

1.переменная = выражение;

2.call имя процедуры (список аргументов);

3.return (значение);

4. имя procedure (список параметров) список операторов;

end;

5.get (список данных для ввода);

6.put (список данных для вывода).

Оператор leave.

Оператор leave обеспечивает выход из цикла, организованного с помощью оператора do. Оператор является типом управляющего оператора перехода.

13. Пошаговое совершенствование. Восходящее проектирование.

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

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

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

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

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

•достижимость модуля — наличие всех модулей в цепочке вызова данного модуля;

•зависимость по данным — модули, формирующие некоторые данные, должны создаваться раньше обрабатывающих;

•обеспечение возможности выдачи результатов — модули вывода результатов должны создаваться раньше обрабатывающих;

•готовность вспомогательных модулей — вспомогательные модули, например, модули закрытия файлов, завершения программы, должны создаваться раньше обрабатывающих;

•наличие необходимых ресурсов.

Нисходящий подход допускает нарушение нисходящей последовательности разработки

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

Нисходящий подход обеспечивает:

•максимально полное определение спецификаций проектируемого компонента и согласованность компонентов между собой;

•раннее определение интерфейса пользователя, демонстрация которого заказчику позволяет уточнить требования к создаваемому программному обеспечению;

•возможность нисходящего тестирования и комплексной отладки.

Метод, реализующий нисходящий подход, называется пошаговой детализацией.

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

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

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

Для тестирования и отладки компонентов проектируют и реализуют специальные тестирующие программы.

Подход имеет следующие недостатки:

•увеличение вероятности несогласованности компонентов вследствие неполноты спецификаций;

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

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

Исторически восходящий подход появился раньше, что связано с особенностью мышления

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

14. Подыгрывающие программы.

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

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

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

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

Например, внутри заглушки объявляется массив с набором значений и переменная со значением номера теста, которая увеличивается на единицу от вызова к вызову; возвращаемой переменной присваивается значение из массива с индексом равным номеру теста. Внутри заглушки может быть, например, проверка на правильность входного значения. Если определенное условие не выполняется, то печатается сообщение об ошибке.

После того как программа написана и протестирована, заглушка может быть или заменена, или доработана до программы, выполняющей требуемую функцию.

Заглушки используются как при восходящем, так и при нисходящем методе проектирования программных систем.

15. Скалярные и агрегативные виды данных. Массивы. Структуры. Списки. Очереди. Стеки. Множества. Графы. Деревья.

Скалярными видами данных называется данные, состоящие из элементарных типов данных. К примеру: int a. Здесь а является скалярынм видом данных, так как int относится к элементарным типам.

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

Массивы.

Массивы — это простейшие агрегативные данные в языках программирования. Массивом называется упорядоченный набор данных одного типа

declare A(10) FIXED BINARY;

Объявлен массив A из десяти двоичных переменных с фиксированной точкой с именами A(1), A(2), A(3),…, A(9), A(10). Аналогично

declare B(5:10) FIXED BINARY;

объявлен массив B из шести элементов с именами B(5), B(6), ...,B(10). Массивы могут быть как одномерными, так и многомерными.