Анализ правильности проектной информации 3 страница

Зависимый вариантный сектор граф вариантной сети вар-ая сеть

…….

Среди функций программной поддержки или вариантных сетей выделяют следующее:

1) ввод информации.

2) Хранение и пополнение сети.

3) Контроль правильности и полноты сети.

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

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

Операционные маршруты пишутся на языке АКТ в одноименном технологическом комплексе АКТ.

2. Вертикальное слоение программ

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

Для начальной систематизации используются следующие принципы:

1) это членение или разделение проекта на составные части.

2) Обеспечение функциональности и независимости этих частей.

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

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

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

График…..

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

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

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

Основа:

Задача:

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

Необходимо ввести расширяющие функции:

1) Учет и печать полного набора сведений о сотрудниках.

2) Частота изменение требований к сотрудникам,

3) отбор анкет по значению атрибутов.

4) Печать части требования от сотрудниках.

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

6) Контроль ошибок входной информации.

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

1) Для реализации учета полного набора сведений о сотрудниках.

2) Для печати.

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

Координаты вставки как правило представляют собой имя процедуры, номер строки программы и номер символа в этой строке, за которым вставляется этот фрагмент.

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

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

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

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

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

Лекция 11

Технология вертикального слоения имеет ряд недостатков:

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

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

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

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

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

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

Как только создан каркас системы и созданы базисные элементы, применяется технология низходящего моделирования.

Технология низходящего проектирования лишена недостатков.

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

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

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

3) Фиксация версии, создаваемой системы, т.е. передача ее в эксплуатацию.

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

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

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

SADT диаграммы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

…..График …

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

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

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

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

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

PSL это один из первых языков предназначенных для описания требований к системе программного обеспечения и был разработан в составе систем технологических комплексов PSL и RSА, в которых была реализована данная технология. Применение данных языков. вышло далеко за рамки использования техническими комплексами и приобрело самостоятельное направление, как отдельный программный продукт он использовался в технологическом комплексе таком, как 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) псевдокоды

2)терминальные языки

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

Псевдотерминальный язык является полностью формализованным и в отличие от терминальных языков (Фортран, Бейсик, СИ и тд.) позволяет использовать структуры управления и данных языка. При таком подходе невозможно приспособится к конкретной проблемной области. Зато обеспечивает автоматизацию самого процесса пошаговой детализации, где учитывается связь объектов между собой и программой, где в качестве языка псевдокода может использоваться любой процедурный язык.

RD - технология (рассредоточенное действие)

В основе RD - технологии лежит основополагающая концепция Фуксмана: сосредоточенное описание, рассредоточенных действий.

Эта концепция реализована в технологии вертикального слоения и развивает технологию вертикального слоения в 2-х направлениях.

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

2) вводится понятие RD - модуля или модуля рассредоточенных действий, который обобщает вертикальный слой Фуксмана и наделяет его главным атрибутом классического модуля - это автономное проектирование, его познаваемость разработки и тестирования, т.е. все те свойства, которые принадлежат обычному программному модулю, также и этап отладки.

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

RD - модуль представляет собой последовательность разделов:

1) тело

2) интерфейс

3) локлы

4) импорт

5) интеграция.

Тело RD -модуля – объединение моделей с именами действий, реализующих рассредоточенные функции.

В разделе интерфейса, содержится описание интерфейса по данным между вершинами и действиями RD -модуля.

График

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

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

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

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

Лекция 13

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

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

Однако существуют операции, когда нужно и лучше его использовать.

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

1) Понимать программу.

2) тестировать ее

3) программа начинает становиться прозрачной и не зависеть от объема.

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

Построение программы от данных

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

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

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

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

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

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

Дата добавления: 2015-07-02