Лекции по "Технология программирования"

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

Инструментальный комплекс позволяет разрабатывать параллельно ряд слоев независимыми разработчиками. Экспериментальная версия данного подхода была разработана в 60 –х годах для ES ЭВМ. В последнее время разработка больших машин возвращается.

SADT диаграммы.

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

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

SADT-диаграммы были разработаны  Россом, и являются собственностью sotteach.

Диаграммы – это наглядное представление процессов обработки данных для реализации графических диаграмм. Был предложен язык SA при этом единственным назначением этого языка является связывание, структуризация и передача фрагментов  замысла, выражения на любом другом языке.

Россом отмечены следующие характерные особенности языка:

1) Язык включает в себя любой  другой язык, а его область  представления универсальная и  неограниченна.

2) Его единственной задачей является упорядоченная организация  (хорошо структурированная  декомпозиция описываемого предмета.

3) Размеры единиц  декомпозиции выбираются в соответствии с  пониманием и характером мышления пользователя в этой  предметной области, т.е. использование языка пользователя.

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

5) Такую структурную декомпозицию можно проверить до любой степени глубины.

6) Язык SA улучшает эффективную и точную передачу понимания предметной области в качественном и количественном отношении и позволяет преодолеть ограничения,  накладываемые в нем некоторым формальным аппаратом.

Язык SA включает простой набор графических элементов, используя который разработчик ПО может отобразить любую структуру.

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

Стрелки отображают интерфейс между частями целого. Само целое представляется диаграммой, которая конструируется из блоков, стрелок и названий на естественном  языке. Описание сложного объекта на языке SA называется  SA - моделью объекта. SA – модель - иерархически организованная совокупность диаграмм, каждая из которых отражает лишь ограниченную часть объекта (целого).

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

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

Графические элементы

управление

…..График  …   

вход выход

 

  механизм

Стрелки и блок поддерживаются названиями, поясняющими смысл действия.

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

Механизм поддержки -   устройство, которое поддерживает механизм поддержки

Языки описания требований   PSL и RSL.

Эти языки оказались производными и  стали  независимыми – на  основе ряда технологического комплекса.

PSL это один из первых языков предназначенных для описания требований к системе программного обеспечения и был разработан в составе систем технологических комплексов    RSL и REV’S, в которых была реализована данная технология. Применение данных языков. вышло далеко за рамки использования  техническими комплексами и приобрело самостоятельное направление, как отдельный программный продукт он использовался в технологическом комплексе таком, как  ARGUS, SD, UDS и стали  олицетворением языков идеологии. формирования требований реализации.

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

1) Описать потоки входных и  выходных данных системы.

2) Описать структуру системы, т.е. описать иерархию объектов системы.

3) Описать структуру данных и связи между ними.

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

5) Описать размеры и объем системы (конкретные значения).

6) Выявить динамику системы, т.е. оценить как поведет себя система во времени.

7) Свойства системы (оценить каждый атрибут системы.)

8) Описать систему с позиции управления проектом. (Управление проектом. Он позволяет определить конкретные сроки  и контрольные точки разработки системы.)

 

Язык RSL, также как и язык  PSL содержит некоторый набор определенных типов объектов. В RSL их обычно  называют элементами: типов объектов и атрибутов, однако в отличие от языка PSL, язык RSL является расширяющим и допускает определение новых типов объектов отношений и атрибутов, и последующее использование их как новых объектов или базисных объектов. Описание новых типов объектов отношений и атрибутов выполняется точно также как например в Паскале, СИ, Бейсике. Разница состоит лишь в том, что в системе   RSL информация о вновь созданных  типах объектов отношений и атрибутов сохраняется в базе данных системы.

Характеристики языков   PSL и RSL

RSL имеет: 19 типов объектов, 20 отношений  и 20 атрибутов.

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

 

Прототипирование, как метод определения требований к ПО

 

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

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

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

 

Лекция 12

 

Технология программирования

 

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

1) Система жесткого реального  времени, в котором не эффективность или возможная ошибка приводит к аварии объекта, который описывает наш прототип. Например – управление ракетой, управление в ядерной отрасли.

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

В этом прототипе проводится полное игнорирование эффективности программ, используются как правило простые методы ( ПО возможности используются   выразительные средства).

Метод прототипирования возник только тогда, когда появились некоторые выразительные возможности описания алгоритмов, т.е. в 80-х годах этот метод не применялся из-за  средств.

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

Язык NOMAD является языком 4-го  поколения и объединяет в себе технологию процедурных и не процедурных языков. Он содержит в себе ряд обычных языков и включает в себя системы управления базами данных. Язык NOMAD высоко интерактивен   и позволяет использовать режим команды в любом из указанных режимов, процедур, позволяет расширять  систему команд.  Пользователь языка NOMAD  может, применяя простые команды выполнять разнообразные действия по формированию различной сложности отчетов, таблиц, графиков, определять и изменять  структуру базы данных, обновлять ее, генерировать статистические. данные базы данных. Существуют проблемы, которые продиктованы языком NOMAD. Он не дает эффекта  в конкретных проблемных областях, т.к. он не имеет выразительных средств, позволяющих кратко и понятно описать определенные  (базовые) термины проблемной области. Для этого существуют другие языки. которые адекватно отображают понятия предметной области. Например: язык PROLOG, который подходит для проблемных областей связанных с  логическим оформлением результатов. Проблемная область здесь некоторая математико-логическая область. В ряде технологических комплексах RADA, ARGUS в них есть язык прототипирования RРL, который не в большей степени зависит от проблемной области и представляет пользователям средства для проектирования,  ориентирования на конкретную область программирования. Язык RРL имеет некоторые свойства – язык сильно расширяющий, очень высокого уровня. Пользователь может включить в язык проблемно - ориентированные типы данных,  связать их с системой,  подцепить к ним определенные действия и сформировать систему разработки, которая носит название среды RPL. Он может:

1) добавлять новые типы данных 

2) вводить операции над объектами новых типов

3) определять взаимодействие объектов

4) определять  приоритеты операций 

5) вводить новые типы констант.

 

Псевдокоды

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

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

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

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