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

Автор работы: Пользователь скрыл имя, 17 Декабря 2014 в 02:02, курс лекций

Краткое описание

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

Прикрепленные файлы: 1 файл

Tehnologiq_programmirovaniq2_lections.doc

— 394.00 Кб (Скачать документ)

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

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

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