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

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

2) На каждом уровне абстракций ничего не известно о других уровнях абстракций и также ничего ни известно о внутреннем устройстве других уровней абстракций.

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

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

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

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

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

Метод портов

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

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

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

1) Модули выполняют слишком много функций что приводит к запутанным и сложным программам.

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

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

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

Прочность модуля - мера его внутренних связей.

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

1) Прочность модуля по совпадениям – модуль с неявно выраженными связями. Такие модули могут появляться тогда, когда в написанной программе обнаружены одинаковые последовательности части программ и которые объединены в 1 модуль. Данному модулю присуща сильная зависимость от вызываемого модуля и чувствительность к внесению изменений в данный модуль.

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

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

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

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

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

7) Функциональная прочность – это информационно прочный модуль выполняющий одну функцию.

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

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

1) Сцепление по содержимому, когда модуль А ссылается на данные модуля В использую абсолютное смещение. Любые изменения одного из модулей практически приводят программу в неработающее состояние.

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

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

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

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

6) Сцепление по данным когда модуль А вызывает модуль В и все входные и выходные данные или параметры, вызываемого модуля являются простыми элементами данных (не структурированы).

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

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

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

Структурный подход

Структурная организация модулей.

Основными объектами структуризации обычно выступает поток передач управления в программе. Именно это определяет структуру.

Что касается потока управления, то сложность программирования возникает в программе, тогда когда используется оператор goto который нарушает структуризацию любой программы. Такие языки как Фортран, Бэйсик используют данный оператор, что говорит о его главной структурированности.

Лекция 8

Технология прогр.

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

1) Последовательный оператор.

2) Условный оператор.

3) Оператор цикла это позволило обеспечить понимаемость и читаемость программ. Каждый из этих операторов имеет отдельный вход и отдельный выход, а программирование, использующее эти типы операторов, называются структурным программированием. Методы, в которых используют данные виды программирования – методы Джексона и R – технологий (методы от данных). В направлении развития структурного программирования с появлением абстрактных типов данных следует выделить следующие положения. 1) Когда описание данных разделено на 2 части: в том числе на описание действий, которые можно выполнить некоторой структурой данных, и реализация этих описаний, такое описание позволило повысить независимость работы программ со сложными структурами, от самих данных и от способов реализации этих данных (обычная инкапсуляция).

Средства представления проектной информации и структуризация ее в процессе разработки ПО

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

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

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

1) Какие объекты требуют описания.

2) Какие математические методы и модели надо использовать при описании.

3) Кто будет воспринимать данное описание.

4) Какова технологическая роль представления.

Ответы на данные вопросы позволят оценить рамки применения данной проектной информации на каждом этапе, а также средства представления проектной информации, в процессе разработки проектной информации.

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

1) Описание характеристик и параметров внешней среды как некоторой системы обработки данных, в рамках которой и должно функционировать данное ПО.

2) Параметры самого ПО.

3) Процессы взаимодействия внешней среды и ПО.

4) Функции ПО. определяемые данными процессами или поддерживающие данные процессы.

5) Критериев и показателей эффективности выполнения той или иной функции при разработке ПО.

Морфологическое описание объекта должно дать представление о строении ПО как некоторой системы.

1) Описание состава функций компонент ПО.

2) Структуры и связи ПО, т.е. отношение данных. Информационное описание должно отражать:

1) Законы изменения параметров внешней среды ПО.

2)Диапазоны изменения этих пар-ров.

3) Способы представления их в вычислительной системе (форматы).

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

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

Пользователи проектной информации. – т.е. кто будет воспринимать эту информацию на каждом этапе:

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

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

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

Технологическая роль средств представления проектной информации

1) Форма представления проектной информации.

2) Содержание проектной информации.

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

В каждом технологическом комплексе реализуется своя технология представления информации и каждый технический комплекс использует свой язык программирования или комплекс языков, поскольку разные специалисты разрабатывают данное ПО, разные среды, по - разному трактовали задание, то и в разной степени были реализованны его возможности, так в АРГУСЕ вся проектная информация задавалась в виде текста на обычном норм. языке и виде графического описания текста.

Средства представления проектной информации на каждом этапе разработки ПО будем отмечать следующие:

1) Каким объектом мы будем заниматься на данном этапе.

2) На каждом этапе мы будем оценивать кому адресована информация.

На этапе формирования требовании к будущему ПО.

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

2) Влияние функции создаваемого ПО. т.е. оценке эффективности будущего ПО производится с внешней стороны.

3) Используемыми данными, которыми будет наполняться будущее ПО.

4) Требованиями к ограничениям, касающихся количественной части будущего проекта, т.е. количественной части параметров, если не удается описать объект с его предметной стороны, т.е. достаточно формально, то принимают подход из вне, определяются границы, цели. В известных технологиях разработки ПО этап формирования требований разрабатывается различными средствами, использующие различные языки описания. Языки описания – это языки RSL и PSL, язык АКТ, язык суперформат,HIPO- диаграммы, диаграммы SAMM, а также взаимосвязный набор шаблонов и бланков, которые. обычно используются в таких системах как ARGUS, TRIAT, SOFTING, суперформат.

Наиболее полное представление разнообразных объектов описания, которые позволяют в полной форме интерпретировать требования это язык АКТ, а также языки RSL и PSL, построенные на концепции структуризации информации, т.е. на технологии ERA(объект- связь- атрибут. Эти языки позволяют представить практически все компоненты описания требований, т.е. на них можно описать:

1)цели разработки.

2) описание функции и данных.

3) Описание характеристик

4) Описание ограничений.

На этапе разработки архитектуры (проектирования) ПО, где основными объектами анализа являются внутренняя. структура объекта

1) Состав подсистем и общие данные, которые требуются для функционирования данных подсистем.

2) Связи между этими подсистемами, т.е. описание действий этих подсистем представленного в виде функций.

3) Описание функций каждой из подсистем.

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

Способы реализации подразделяются:

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

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

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

В этих комплексах используется язык псевдокодов.

Лекция 9

Этап детального проектирования

Основным представлением объектов на этом этапе являются алгоритмы и структура данных, разрабатываемых модулей, поскольку они используются самими разработчиками программного обеспечения, то они представляются в форме, ориентированной на программистов профессионалов. Алгоритмы, как правило, описываются блок-схемами, диаграммами HIPO; SAD; SAM, диаграммы – Шнайдера.

Модификация проектной информации и повторное использование результатов разработки

Понять с какого уровня начать, чтобы не потерять прибыль.

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

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

Проблемы, которые возникают при модификации проектной информации.

1) Как определить всю совокупность изменений проектной информации, т.е. задача сводится к тому на каком этапе начать проводить изменения модификации проектной информации. Проблема достаточно сложная и в полном объеме не решена.

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

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

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

Модификация ПО как улучшение эксплуатационных характеристик

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

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

В этом направлении есть 2 течения:

1) оптимизация

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

CDL2LAB - в которой реализуется процедура глобальной оптимизации. Работает по следующим принципам: цель расширить узкие места.

Проблема применения готовой проектной информации.

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

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

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

1)что для разработки сложного объекта сложно найти подходящие модули среди ограниченного числа модулей.

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

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

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

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

1) АСУ - линейное программирование.

2) Линейные и нелинейные.

3) Расчет упругости.

Эта прибыль была достигнута за счет

1) Правильная организация модуля при вставке в программу.

2) Однотипная организация задач.

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

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

Это явление объясняется:

1) Стремлением к минимизации размера каждого модуля.

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

Основные принципы подхода разработчиков к системе …..

1) Надо создавать программу, выполняющую единственное дело, т.е. лучше написать новую программу, чем добавлять существующую процедуру, оператора.

2) Следует предполагать, что выходные данные каждой программы могут поступать на вход другой программы.

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

В системе UNIX существует язык ШЭЛ, который управляет заданиями системы (диспетчер), который предоставляет простые и мощные средства комплексирования, независимо от разработанных модулей.

Комплексирование позволило:

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

2) Все программы объединится в данные только через последовательные файлы. Унификация структуры позволяет уменьшить вероятность того, что различные программы не будут стыковаться. Единообразный вызов программ и командных файлов на языке ШЭЛ упрощает объединение программ, выстраивается конвейер. Примерами команд обычно не встречающихся в других операционных системах является сортировка файлов, форматизация и вывод текстовых файлов, сравнение текстовых файлов и многое др, в системе форд.

Лекция 10

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

Распространенные методы и средства разработки ПО

Вариантные сети, операционные маршруты и вертикальные слои.

1)Вариантные сети.

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

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

Среди полезных средств документальных фиксации выбранных решений отмечают следующие:

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

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

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

Фиксация представляется в виде вариантного сектора, который включает в себя:

1) Четкая постановка вопроса, требующего решения.

2) возможные варианты решения поставленного вопроса.

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

4) Матрица оценок вариантов.

5) Аргументация этих оценок, т.е. обоснование их.

6) Выбранный на основе этих оценок вариант.

Матица оценок представляет. собой двумерную таблицу, в которой столбцы соответствуют свойствам, а строки вариантам. На пересечении i строки и j столбца располагаются целые числа от 0 до 10, которые характеризуют относительную оценку проявления j -го свойства в i -ом варианте. Кроме того, с каждым свойством поставляется величина значимости этого свойства (весовой параметр), характеризующий важность этого свойства, с точки зрения целей проекта, в рамках которого и должен функционировать наш проект.

	С1	С2	С3	С4	С5	С6	Полная оценка
			10(1)
			0(2)

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