Лекция Жизненный цикл программы
Работа добавлена на сайт bukvasha.net: 2015-10-29Поможем написать учебную работу
Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
от 25%
Подписываем
договор
Лекция по ТРПП
Жизненный цикл программы.
Жизненным циклом программы называется процесс его создания и применения от начала до конца.
1. Анализ требований предлагаемых программ. На нем определяются требования, выполнения которых позволяет получить приемленное решение данной проблемы или задачи. Анализ требований сосредоточен на интерфейсе между человеком и инструментом создание программы. До принятия решения необходимо определить время обработки информации, стоимость обработки, вероятность возникновения ошибок и преднамеренных действий. Анализ требований способствуют лучшему пониманию решаемой проблемы, что помогает выбору наилучшего решения. Надо выявить просперанственно временные ограничения налагаемые на всю систему создания проекта, средства системы. Необходимо определять ресурсы требуемые для реализации программы (деньги).
2. Определение спецификации и программы . На этом этапе задается структура входимых и выходимых данных, разрабатывается документ, отражает предлагаемую реализацию программы с помощью ПК. В документе отражается спецификация. Чем подробнее составлены спецификации, тем меньше вероятность возникновения ошибок. В соответствие со спецификацией данных для тестирования должны быть предусмотрены ошибки на ранних этапах разработки программы. Этап документа можно использовать для начальных оценок временных затрат числа специалистов и других ресурсов. Спецификация определяет только не функции, которая вся система должна выполнять не указывая каким образом это достигается. На этом этапе нежелательно составление подробных алгоритмов реализации функции программы так как может вызвать нежелательные осложнения.
3. Проектирование. На нем разрабатываются алгоритмы разрабатываемые спецификацией и формируется общая структура вычислительной техники, обеспечивающая создание системы разработки проектирования. Система создания программ должна быть разбита на части так, чтобы ответственность за реализацию каждой можно было возложить на одного разработчика или группу, при этом для каждого такого модуля системы должны быть сформированы:
1) Реализуемые функции.
2) Размеры.
3) Время выполнения объекта.
4. Кодирование . На этом этапе для кодирования используется автоматические языки разного уровня и методы структурного программирования. (создается треть ошибок).
5. Тестирование. В процессе тестирования используется данные характерные для системы в рабочем состоянии. Тестирование проходит 3 стадии:
1) Автономная – выполняется программистом.
2) Комплексная – выполняется оппонентами с помощью тестов. Желательна разработка тестов с заказчиком.
3) Системная – проводится с помощью независимых тестов, создаваемых заказчиком.
6. Сопровождение – включает внесение изменений и поддержание и в рабочем состоянии.
Классификация ПО.
Под системным базовым ПО понимается такое, которое включает ОС, сетевое ПО, сервисные программы, средства разработки программ. Прикладное ПО может использоваться в различных сферах деятельности человека: научные исследования, инженерская практика и конструктирование, издательская деятельность, организация дело – производства.
Характеристика программного продукта.
ПП- комплекс взаимосвязанных программ для решения определенных проблем массового спроса подготовленных к реализации, как любой вид программной продукции.
Схема взаимодействия разработчиков программ.
| ||||||||||||||||||
Основные характеристики программ:
1) Алгоритмическая сложность (логика алгоритмов обработки информации).
2) Состав и глубина проработки реализованных функций обработки.
3) Системность функций обработки.
4) Объем файловых программ.
5) Требования к ОС и техническим средствам со стороны программы.
6) Объем дисковой памяти.
7) Объем ОП для запуска программ.
8) Тип процессора.
9) Версия ОС.
10 )Наличие вычислительной сети.
ПП имеют показатели качества, которое отражают: насколько просто, надежно, эффективно можно использовать программный продукт; насколько легко эксплуатировать.
Дерево характеристик качества ПП.
1. Мобильность означает независимость от технического комплекта системы обработки данных, ОС, сетевой технологии обработки данных, специфики предметной области, т.е. ПП может быть установлен на различных моделях компьютера и ОС без ограничений на его эксплуатацию в сети. Функции обработки ПП пригодны для массового использования без каких либо изменений.
2.1 Надежность определяется бесперебойностью и устойчивостью в работе, точностью выполнения предписанных функций обработки, возможностью диагностики возникающих ошибок.
2.2 Эффективность оценивается, как с позиции прямого назначения (требования пользователя) так и с точки зрения расхода вычислительных ресурсов необходимых для его эксплуатации.
2.3 Учет человеческого фактора означает обеспечение дружеского интерфейса, наличие контексно зависимой подсказки или обучающей системы в составе ПП, хорошей документации и средств выполняющих анализ и диагностику ошибок.
3.1 Модифицируемость – способность к внесению изменений, переход на другую техническую базу обработки.
3.2 Коммуникативность – основано на максимальной возможности их интеграции с другими программами, обеспечение обмена данными в одинаковых форматах.
Экономические характеристики программ.
1) Стоимость.
2) Количество продаж.
3) Время нахождения на рынке.
4) Известность фирмы разработчика и программы.
5) Наличие ПП аналогичного по назначению.
Вопросы маркетинга относительно ПП.
1) Формирование политики цен для завоевания рынка.
2) Широкая рекламная компания ПП.
3) Создание торговой сети для реализации ПП (дилерские и дистрибьюторские центры).
4) Обеспечения сопровождения и гарантийного обслуживания пользователя ПП, создание горячей линии.
5) Обучение пользователей ПП.
Спецификой всех ПП является то, что их эксплуатация должна выполняться на правовой основе – лицензионное соглашение между разработчиком и пользователем с соблюдением авторских прав разработчиков программного продукта.
5 Приметивы качества.
1. Точность- мера характеризующая применение величин надежности выдаваемых программами в результатах с точки зрения их предлагаемого использования.
2. Автономность - -свойство характеризующее способность ПС выполнять предписанные функции без помощи или поддержки других компонент ПС.
3. Устойчивость – свойство характеризующее способность ПС продолжать правильную работу несмотря на ввод неправильных данных.
4. Защищенность – свойство характеризующее способность ПС противостоять преднамеренным действиям пользователя.
5. П- документированность – свойство характеризующее наличие полноты понятности, доступности, наглядности учебной справочной документации.
6. Информативность – свойство характеризующее наличие в составе ПС информации необходимой и достаточной для понимания назначения ПС, принятых ограничений на входные и выходные данные, работу отдельных компонентов, общее техническое состояние программ.
7. Коммуникабельность – свойство характеризуещее степень в ком. программа обеспичивает выполнение задания и способна выдавать информацию в простой форме и простым для понимания содержания.
8. Временная мера характеризует способность ПС выполнять функции в течении определенного времени.
9. Эффективность по ресурсам – мера характеризуящая способность ПС выполнять необходимые функции при определенном ограничении на использовании ресурсов.
10. Эффективность по устройствам – мера характеризующая экономность использования устройств ПК для решения задач.
11. С – документируемость – свойство характеризующее, с точки зрения наличия документального отражения, требований к ПС, включает возможные ограничения и их обоснования.
12. Понятность – примитив интезированный из других: самодокументируемость, четкость, согласованность. Свойство характеризующее степень в ком. ПС позволяет изучающему его лицу понять его назначение, сделанных допущений, результаты работы, тесты программ и состояние их реализации.
13. Структурированность – свойство характеризующее программу с точки зрения организации взаимосвязи ее частей в единое целое опредленным образом.
14. Удобочитаемость – свойство характеризующее легкость восприятие тескта программ ПС.
15. Расширимость – свойство характеризующее способность ПС к использованию большого объема памяти для хранения данных и расширение функциональных возможностей отдельных компонентов.
16. Модифицируемость – мера характеризующая ПС с точки зрения простоты внесения необходимых изменений и доработок на всех этапах жизненного цикла.
17. Модульность – свойство характеризующее ПС с точки зрения организации, что изменение одной из них оказывает минимальное воздействие на другие компоненты.
Основные примитивы влияющие на критерии качества ПС.
1. Функциональность : влияет завершенность.
2. Надежность : влияют n. 1-4
3. Легкость : влияют п. 5-7
4. Эффективность : 8 – 10
5. Сопровождаемость : 5, 11 – 17
6. Мобильность : 2,13,17 независимоть от уст.
Обеспечение легкости применение ПС определяется пользовательской документацией с ком. связанны примитивы 5,6,11.
Данные примитивы влияют на принципы разработки пользовательского интерфейса :
1. Он должен базироваться на терминах и понятиях знаемых пользователем.
2. Он должен быть единообразным.
3. Должен тпозволять получение справочной информации как по его запросу так и интерируемой ПС.
Командный пользовательский интерфейс продоставляет пользователю возможность общения с ПС только текстом. Этот режим требует изучение языковых команд, поэтому высокая вероятность ошибок.
Обеспечение эффективности.
При обеспечении эффективности необходимо разрешить противоречия между временной эффективностью и эффективностью ОЗУ.
Существуют принципа обеспечения эффективности:
1. Сначало разработать надежное ПС, затем довести его эффективность до требуемого уровня.
2. Использование оптимизируещего компилятора. Если эффективность неудов. Специфическим качествам.
3. Не надо оптимизировать модуль, если это не требуется для эффективность.
Обеспечение сопровождаемости и управления конфигураций ПС.
1. Использование в тексте модуля, хотел бы кратко примечание с самой ранней стадией разработки.
2. Использовать устойчивые и различне имена для переменных, неиспользовать входные имена и ключевые слова.
3. Осторожно использовать const., должно быть уникальное объявление и единственное вхождение в текст модуля.
4. Не надо боятся использования необязательно скобки.
5. Размещать не более одной операционной строки, использовать отступы и пробелы в одной строке.
6. Избегать приемов программирвоания создающих фрагменты модуля
эффективность которых неочевыдна и скрыта.
Аппаратно-операционоое платформы и обеспечение мобильности ПС.
Независимоть можно обеспечить выполнением отдельных частей программ с помощью компьютерно-аппаратных средств. Можно строить ПС в рамках конкретной ОС, которая “спрячет” специфику от устройства.
Показатели надежности ПС.
Надежность ПС – вероятность того, что программа в течении одного времени будет работать без сбоев с учетом степени их влияния на выходные результаты.
Программные ошибки – работа программы не в соответствии со своими спецификациями. Надежность ПС обуславливается отказом или сбоем.
Показатели надежности.
Показатель надежности – величина или совокупность характеризующая количественно или качественно приспособленность ПС к выполнению задачи:
1. Качественные – показатели которых не могут быть выражены в виде числа и не содержат информацию позволяющую обосновать предпочтение одного из вариантов. Они позволяют отличать одни системы от других, но не позволяют сравнивать их по степени выолнения поставленных задач.
2. Порядковые – содержат информацию позволяющую обосновать предпочтение одного из вариантов ПС при их сравнении без колличественной оценки степени предпочтения. Они дают возможность раположив ПС в ряд по степени возрастания надежности.
3. Колличественные – выражают надежность в виде числа, измеряются принятой шкалой оценок в абсолютных или относительных оценках, определенных путем непосредственных статистических наблюдейний на основе обработки результатов применения или испытания ПС, с помощью аналитических расчетов моделирования процессаа работы ПС.
Задачи проэктирования ПС с заданным уровнем надежности.
1. Включает обоснования требований по надежности, решается на начальном этапе проектирования и предусматривает предворительную проработку ПС.
2. Включает такие задачи проектирования, кот. Проявляеются на каждом этапе надежности. При решении этих задач необходимо исследовать эффективность возможных способов обеспечения надежности с целью выбора наиболее приеммного.
а) применение типовых проектных решений.
б) использование модульной структуры.
в) соблюдение стандартов программирования и документации.
г) организация которая функционирования системы путем взаимной межмодульной проверки.
3. Включает задачи колличественной оценки надежности выбранного варианта.
К ним относится:
а) выбор исходных данных
б) структурный анализ надежности
в) расчет достигнутого уровня надежности
г) оценка точности полученных результатов.
Факторы определяющие надежность ПП.
Группа общих факторов.
1. Управление разработкой включает методы использования ЭВМ, языки программирования, планирование задания, нализ сущесвенности программ, контроль качества работы, автоматический контроль, режим разделения времени.
Правила при осущесвления контроля:
А) проверка справедливости расчетов далжна быть отделена от проверки логики программ.
Б) если программа разбита по модулям, то проверку надо проводить по каждому.
В) результаты проверок должны фиктироваться в док. Предусмотренным данным видом контроля.
При управлении разработки программы выделяют 3 группы:
А) контролируемость программы (находятся в использовании)
Б) неконтролируемые и не используемые программы ( пока еще находятся в использовании)
В) неконтролируемые и не используемые программы (находятся в архиве или мало используется)
2. Подготовка и повышение квалификации персонала, обеспечивает разработку и эксплуатацию ПС.
Акцент делается на фундаментальную общую подготовку. Специалист далжен пройти самостоятельной работы, постоянно совершенствовать знания.
3. Архитектура ЭВМ и надежность: оказывает косвенное влияние, при разработки надо избегать неэффективность использования компонентов. Надежность ПО зависит от быстродействия аппаратуры и стоимоти.
4. Языки программирования и надежность должны удовлетворяться следующим целям: читаемость программы, отсутствие тенденции к ошибкам, легкость изучение и использования, эффективность компеляции.
Факторы связанные с разработкой ПП.
1. Конструктивные факторы (проявляются на стадии начального проектирования)
Включают:
а) размеры и стоимость разработки
б) степень сложности разработки
в) структурное построение
г) наличие отчета разработки у персонала
д) степень выполнения, технологии разработки.
2. Технологические факторы (опред.надежность, как следствие организации трудового коллектива выполняющего спец.умственную работу)
Включают:
А) управление надежностью в процессе разработки.
Б) степень обучаемости персонала
В) степень информативности персонала, включая всех участников разрабокти должна быть высокой; информация должна быть адаптирована ко всем требованиям, изложенным в спецификации.
Г) Микроклимат в группе, умение и жедание сотрудничать, взаимопомощь на каждом этапе разработки.
Д) ограничения изложения в спецификации не должны влиять на выполнение рабьоты.
Достижение заданного уровня надежности зависит и от руководителя разработки.
При организации работ жалательно сформировать следующие группы:
1. Группа с главным программистом.
2. Группа специалистов.
3. Демократическая группа.
Эксплуатационные факторы:
1. Полнота и качество документации.
2. 2 степень адаптации документации
3. Простота изучения и использования систем ПП.
4. Качество обучение пользователей
5. Степень выполнения стандартов.
6. Защищенность информационной программы.
Метрики оценки качества ПО.
Чтобы оценить качество с помощью метрик необходимо определить измеряемые характеристики:
Боэм, Броун, Лайпоу. Описание нерархического дерева указывает логическое следование.
Характеристики самого нижнего уровня представляют собой примитивы, комбинации которых образуют характеристики среднего уровня. Они разработали 51 возможную метрику оценки примитивных характеристик и провели сравнения этих теорий по степени их компеляции с качеством программы.
Предположенная схема опиралась на практический опыт и не предлагала четкой демонстрации ее эфектов, поэтому их лучшеиспользовать для рецензирования, чем как руководство для разработки.
Метрики ПО Джелба.
Он считает, что каждая разработка требует введение собственных понятий и инструментов и излагая основные из них, от которогых мог отталкнуться разработчик.
Для оценки надежности используется выражение:
1
общее число запусков
В качестве меры точности (свободы от ошибок относение колличества правильных данных ко всем данным)
Прецизионность – определяется, как мера того на сколько часть ошибки обусловлена одинаковыми причинами.
Джелб оценивает ее дробью в числителе – число фактических ошибок на в ходе, а в знаменателе – общее число наблюдаемых ошибок, причинами которых явились эти причины на входе.
Н-р. Если одна ошибка в течении опред. Периода времени вызывает 100 сообщений об ошибках, то ее прецинзчонность равна 0,01.
Гибкость ПО включает: логическую сложность, внутреннию гибкость, открытость (адаптируемость), универсальность, удобство переноса, совместимость.
В качестве меры логической сложности Джелб предложил число логических “двоичных принятий решений”, такая оценка может быть получена вручную или автоматически.
Абсолютная логическая сложность задается числом нестрандартных выходов из адаптеров, в котором происходит принятии решений.
Компьютерная поддержка разработки и сопровождения ПС.
Инструменты разработки ПС.
ПС преднозначенные для поддержки разработки других ПС называются прог. инструментом, а устройства ПК предназначена для поддержки разработки ПС – аппаратными инструментами:
Инструменты разработки могут использоваться в течении всего жизненного цикла ПС, для работы с разными программными инструментами. Например текстовый редактор можно использовать для разработки любого программного документа.
С точки зрения функций, кот. инструменты выполняют при разработке ПС их можно разбить на группы:
1. Редакторы (поддерживают конструктирование программных документов универсальный, текстовый, графический)
2. Анализаторы (производят либо статистическую обработку документа, осущаствляя различные виды контроля, выявление определеного на св-в и накопление статистических данных, либо динамический анализ программ, например с целью выявления распределения времени работы программы по программному модулю)
3. Преобразователи (поволяют автоматически приводить документ к другой форме предсталения)
4. Инструменты поддерживающие процесс выполнения программ (позволяют выполнять на ПК описание процессов или отдельных их частей, например эмулятор кода другого компьютера, различные отладчики)
Инструменталиные среды разработки и сопровождение ПС.
С каждой системой программирования связываются не отдельные инструменты, например компьютор, а логически связанная совокупность программных и аппаратных инструментов, поддерживающих разработку и сопровождения ПС на данном языке программирования или ориентированных на конкретную предметную область – инструментальная среда разработки и сопровождения ПС.
Различают 3 основных класса среды:
1. Инструментыльные среды программирования (содержит текстовый редактор, инструменты, позволяющие комплировать и отлаживать их. Возможно наличие инструментов для статистического и динамического анализа программ) Различают следующие классы ИСП: среды общего назначения; языкоориентированные среды подразделяемые на 2 подкласса: интерпритирующие среды, синтаксические управляемые среды.
2. Инструментальные среды технологии программирования (это интегрированная совокупность программных и аппаратных инструментов, поддерживающая все процессы разработки и сопровождение больших ПС, обладающая следующими чертами: комплексность, ориентированность на кол-ую разработку, интегрированность.)
Единая система программной документации (ЕСПД)
ЕСПД – комплекс гос. Стандартов, устанавливающих взаимосвязанные правила разработки, обращеня и и обнавление программ и программной документации. В ЕСПД устанавливаются требования, регламентирующиеся разработку, сопровождение, изготовление и эксплуатацию программы. Правила и положения ЕСПД распространяются на программы и программноую документацию, для вычислительной техники, комплексов и систем и на область их применения.
Программное изделие – программа на носителе является продуктом промышленного производства.
Программный документ – документ содержащий сведения необходимые для разработки, изготовления, эксплуатации и сопровождения программного изделия.
Эксплуатационные программные документы – такой ПД которые содержит сведения необходимые для обеспечения функционирования и эксплуатации ПИ.
Проверка программы – проверка правильности реализации заданного алгоритма путем выполнения программы на ЭВМ.
Отладка программы – обнаружение, локализация, устраниение ошибок в программе.
Испытание программы – установление соответствия программы заданным требованиям и программным документам.
Сопровождение программы – процесс кладификации ПС обусловленный необходимостью устранения выявленных в ней ошибок и изменения ее функциональных возможностей.
Виды программных документов.
1. Спецификация – включает состав программы и документации на нее.
2. Ведомость держателей подлинников – включает перечень предприятий на котором хранят подлинники ПД.
3. Текст программы – запись программы с необходимымикомментариями.
4. Описание программы – включает сведения о логической структуре и функционировании программы.
5. Порядок и методика испытаний – требования подлежащие проверки, порядок и методы их контрам.
6. Техническое задание:
А) назначение и область применения программ
Б) технические, технико-экономические, специальные требования предъявленные программе.
В) необходимые стадии и строки разработки.
Г) видыиспытаний
7. пояснительная записка – включает схему алгоритма, общее описание алгоритма и функционирования программы и обоснования технических и технико-экономических решений печении функционирования и эксплуатации.
Виды эксплуатационных документов.
1. Ведомость ЭД – перечень ЭД на программу.
2. Формуляр – основные характеристики программы, комплекстность, сведения об эксплуатации программы.
3. Описание применения – сведения об эксплуатации программы.
4. Руководство системного программиста – сведения для проверки обеспечения функционирования, настройки программы на условие конкретного применения.
5. Руководство программиста – сведения на эксплуатацию программы в целом.
6. Руководство оператора – сведения для эксплуатации и процедур общения оператора с ЭВМ.
7. Описание языка – включает описание синтаксиса и симантики языка.
8. Руководство техническому обслуживанию – включает сведения по применению тестовых и диагностических программ при обслуживании ЭВМ.
Общие требования к ПД.
Каждый ПД состоит из нескольких частей, каждая из которых имеет свое название: 1 титуальная часть (содержит лист утверждения и сам тетуальный лист. Лист утверждения содержит информацию о вопросах целесообразности и необходимости создания программы и вопросах ее применения); 2 информационная часть (включает аннотацию и содержание данного документа. В аннотации приводят сведения в назначении данного документа и краткое изложение его основной части);
Содержании включает перечень записей о структурных документах основной части документов, в каждую из которых входит:
А) обозначение структурногоэлемента (номер раздела, подраздела)
Б) наименование структурного элемента
В) адрес структурного элемента на носители.
3. основная часть – содержит все информацию о программе, саму программу (текст), структуру отдельных частей, модулей.
Регистрация изменений – о каждом изменении ПД делается запись.
Стандарты ЕСП.
1.стандарт по гост 19.101-77 он устанавливает требования к содержанию и оформлению программного документа и руководство системного программиста. Согласно гост оно должно содержать следующие разделы: а общие сведения о программе, в которой указывается назначение и функции программы.
2) сведения о технических и программых средствах обеспечивающих ее работу.
3) структура программы – сведения о структуре программы, ее составных частях, о связях между ними и связях с другими программами.
4) настройка программы – описание действий по настройке программы на условие конкретного применения.
5) проверка программы – описание способов проверки работоспособности (контрольные примеры, методы прогона результат.)
6) дополнительные возможности – описание дополнительных функциональных возможностей программы и способов их выбора.
Сообщение системному программисту – указанны тексты сообщений, выдаваемых в ходе проверки программы, в ходе ее работы, действий предпринятых по этим сообщениям.
7)Приложения – примеры, юллюстрации, таблицы, графики.
2. стандарт по гост 19.101-77, “руководство программиста” . согласно стандарту руководство долно содержать разделы:
Назначение и условия применения программы – назначение и функции, объем ОЗУ, требования к составу и параметрам ПУ.
Характеристикипрограмм – описание основных характеристик и особенностей (временные, режимработы, средства контроли правильности и самовостанавливаюсти)
Обращение к программ – описание процедур ее вызова (способы передачи управления и параметров данных)
Входные и выходные данные – описание организации В/В информации и при необходимости ее кодирования.
Сообщения – см.выше.
Приложение – см.выше
Виды контроля программ.
Программный комплекс –совокупность программных модулей предназначенных для решения одной задачи и составляющих одно целое.
1. Визуальный контроль – это проверка программы «за столом» без компьютера, осуществляется чтение программы, изучаются:
А) комментарии и их соответствие тексту программы.
Б) условия в операторах выявления, выбора и цикла.
В) сложные логические выражения.
Г) возможность незовершения итерационных циклов.
После чтения выполняется сквозной контроль программы на подобранных простых тестах.
2. Статический контроль – это проверка программы по ее тесту (без выполнения) с помощью инструментальных средств. Например; синтаксический контроль программы с помощью компилятора. – при котором определяется соответствие текста программы систем. Правилам языка программирования.
Сообщения компилятора делится на несколько групп взависимости от уровня тяжести нарушение синтаксиса языка программирования:
А) информационные сообщения и предупреждения, при которых возможна построение корректного объективного кода и дальнейшая работа с программой.
Б) сообщение об ошибках, которое компилятор пытается исправить , корректность кода маловероятна работа с ним скорее невозможна.
В) сообщения о серьезных ошибках – код заведомо не верен и его использование невозможно.
Г) сообщение об ошибках, обнаружение которых привело к прекращению синтаксического контроля и построение кода.
Возможно, что компилятор пропустит некоторые виды синтаксических ошибок. Во время статического контроля осущ. И контроль структурированности программы, т.е. проверка выполнения соглашений и ограничений структурного программирования. (не применять оператор безусловного перехода для организации цикла) статический контроль должен выяснить правдоподобие программы.
1. Использование в программе не инециализированных переменных (переменные не получившие начального значения)
2. Наличие в программе описаний элементов, переменных, процедур, меток, файлов, в дальнейшем не используемых в ее тексте.
3. Наличие в тексте программы фрагментов никогда не выполняющихся.
4. Наличие в тексте программы переменных не разу не используемых для чтения после присваивания им значений.
5. Наличие в тексте программы заведомо бесконечных цикл.
Неправдоподобность может не приводить к неправильной работе программы, то ее исправление повысит ясность и эффективность программы, т.е. улучшит ее качество.
Для проведения контроля правдоподобие используется специально инструментальные средства, возможности которых частично заложены в отладочных и обычных компиляторах.
Принципы создания средств контроля правдоподобия программы:
1. Проведение дополнительных форм статического контроля после завершения компиляции и только для синтаксически корректных программ.
2. Максимальное использование результатов компиляции программы.
3. В место синтаксического разбора текста проверяемой программы построения для нее списка идентификаторов и операторов, а указанное всех их необходимых признаков.
При отсутствии инструментальных средств контроля правдоподобия эта фаза статического контроля может объединяться с визуальным контролем.
Следующий формой статического контроля программы является их верификация, т.е. аналитическое доказательство их корректности.
Корректность – свойства программы свидетельствующие об отсутствие в ней ошибок запущенных разработчиком на различных этапах проектирования (спецификации, проектирование алгоритма и структур данных, кодирование); корректность самой программы по отношению к целям поставленным перед ее разработкой.
Отличие понятие корректности и надежности.
Надежность характеризует как программу так и качество аппаратуры, квалификацию пользователя. Надежность допускает небольшую долю ошибок в программе и оценивает вероятность их появления. Надежность объединяет следующие характеристики: целостность, живучесть, завершенность, работоспособность.
Корректность характеризует семантические свойства программы так как не всякая синтаксически правильная программы является корректной. С учетом специфики появление ошибок в программе можно выделить две стороны понятие корректности:
1. Корректность, как точное соответствие целям разработки программы, отраженных в спецификации при условии ее завершения (частичная корректность)
2. Завершение программы, т.е. достижение программной в процессе ее выполнения своей конечной точки.
Задачи анализа корректность (зависит от выполнения сторон корректности)
1. Доказательство частичной корректности.
2. Доказательство частичной некорректности
3. Завершение программы 9доказательство)
4. Доказательство незавершения программы
5. Доказательство полной корректности (1+3)
6. Доказательство некорректности (2+4)
Методы доказательства частичной корректности программ опираются на аксиоматический подход к формализации семантики языков программирования.
Динамический контроль программ – проверка правильности программы при ее выполнении на компьютере (тестирование).
Тестирование
Тестирование – процесс выполнения программы с целью обнаружения в ней ошибок.
Принципы организации тестирование (Майерс)
1. Необходимой частью каждого текста должны являться описания ожидаемых результатов работы программы, чтобы можно было быстро выяснить наличие или отсутствие ошибки в ней.
2. Следующим по возможности избегать тестирования программы ее автором т.к. обнаружение недостатков в своей деятельности противоречит человеческой психологии, но отладку выполняет автор.
3. Организации разработчик ПО недолжна единолично его тестировать.
4. Должны являться правилом доскональное изучение результатов каждого теста, что бы не пропустить малозаметную ошибку.
5. Необходимо тщательно подбирать тест не только для правильных предусмотренных входных данных но и для неправильных непредусмотренных.
6. При анализе результатов каждого теста необходимо проверять не делает ли программа того, что она не должна делать.
7. Следует сохранять использованные тесты, для повышения после ее модификации или установки у заказчика.
8. Тестирование не должно планироваться исходя из предположения, что в программе не будут обнаружены ошибки, следует выделять достаточные временные и материальные ресурсы.
9. Следует учитывать “принцип вставления ошибок”.
10. ] следует всегда помнить, что тестирование творческий процесс, а не относится к нему как к рутинному занятию.
Существует 2 основных вида тестирования: функциональное и структурное.
При функциональном тестировании программа рассматривается как “черный ящик” то есть ее текст не используется. Происходит проверка соответствие поведение программы ее внешней спецификации, в этом случае тестирование будет полным если выполняется полный перебор всех возможных значений входных данных. Так как исчерпывающее функциональное тестирование невозможно, то надо разработать методы позволяющие подбирать тесты не вслепую, а с большей вероятностью обнаружения ошибок в программе.
При структурном тестировании программа рассматривается как “белый ящик” т.е. текст открыт для пользования, происходит проверка логики программы. Полным тестированием в этом случае будет такое, которое приведет к перебору всех возможных путей на графе передач управления программы. Количество возможных путей может быть очень большие и так как даже если ограничится перебором только линейных независимых путей при котором все равно не возможно подобрать тесты так что бы перекрыть все.
Не структурное не функциональное тестирование может быть исчерпывающим.
Основные этапы тестирования программных комплексов:
1. Тестирование отдельных модулей.
2. Совместное тестирование модулей.
3. Тестирование функций программного комплекса, т.е. поиск различий между разработанной программной и ее внешней спецификации.
4. Тестирование всего комплекса в целом, т.е. поиск различий между созданным продуктам и целями отраженными в техническом задании.
На этапах 1,2 используется методы структурного тестирования, а на этапах 3,4 они не применяются из за больших размеров проверяемого ПО, эти этапы ориентированы на обнаружение ошибок различного типа, которые не обязательно связаны с логикой программы.
При тестировании как отдельных модулей так и их комплексов должны быть решены задачи:
1. Построение эффективного множества тестов.
2. Выбор способа комбинирования (сборки) модулей при создании тестированного варианта программы.
Структурное тестирование.
Так как исчерпывающее структурное тестирование невозможно, необходимо выбрать такие критерии его полноты, которые допускали бы их простую проверку и облегчали бы целенаправленный подбор тестов.
Наиболее слабыми из критериев полноты структурного тестирования являются требование хотя бы однократного выполнения каждого оператора программы.
Более сильных критерием является критерий С1: каждая ветвь алгоритма (каждый переход) должна быть пройдена (выполнена) хотя бы один раз. Для большинства языков программирования проход переходов обеспечивает и выполнение операторов, но не для всех.
Использование критерия выполнения условий может вызвать подбор теста обеспечивающих переход в программе, который пропускается при использовании критерия с1. Например: в программе на языке Pascal использующей конструкцию цикла while x AND y Do применение критерия выполнения условий требует проверки обоих вариантов выхода из цикла: NOT x u Noty. С другой стороны выполнение условий может не обеспечивать прохода всех переходов. Например: конструкцию IF A AND B THEN… требует по критерию выполнение условий 2х тестов, например: A=тчие, B=False и A=False B=тчие , при которых может не выполнятся оператор, расположенный в THEN ветви оператора IF/
Практически единственным средствам предоставляемым современными системами программирование является возможность определения частоты выполнения различных операторов программы (и профилизации). Но с помощью этого инструмента поддержки тестирования можно проверить выполнение только слабейшего из критериев полноты- выполнение всех операторов.
С помощью этого же инструмента можно проверить и выполнение критериев С1, но для этого предварительно текст программы должен быть преобразован так, что бы все конструкции условного выбора (IF или Case) содержали ветви Else, хотел бы и пустые.
Совместное тестирование модулей.
Существует 2 подхода:
1. Монолитное тестирование, при котором сначала по отдельности тестируются все модули программного комплекса, а затем все они объединяются в рабочую программу для комплексного тестирования.
2. Пошаговое тестирование, при котором каждый модуль для своего тестирования подключается к набору для своего тестирования подключается к набору уже проверенных модулей.
Для автономного тестирования каждого модуля требуется модуль – драйвер, т.е. вспомогательный модуль имитирующий вызов тестируемого модуля, и один или несколько модулей-заглушек, .т.е. вспомогательных модулей имитирующих работу модулей вызываемых из тестируемого.
При пошаговом тестировании модуля проверяются не изомерованно друг от друга поэтому требуется либо только драйверы, либо только заглушки.
Преимущества пошагового тестирования:
1. Меньшая трудоемкость.
2. Более раннее обнаружение ошибок в интерфейсах между модулями т.к. их сборка начинается раньше чем при монолитном тестировании.
3. Легче отладка, т.е. локализация ошибок, .т.к. они в основном связаны с последним из подключенных модулей.
4. Более совершенные результаты тестирования, т.к. более тщательная проверка совместного использования модулей.
Преимущества монолитного тестирования:
1. Меньший расход машинного времени (может исчезнуть, если очень сложная отладка
2. Предоставляется большей возможностей для организации параллейной работы на начальном этапе тестирования.
Более целесообразным является выбор пошагового тестирования. При его использовании возможно две стратегии подключения. При его использовании возможно две стратегии подключения модулей:
=1 Нисходящая -начинается с главного или верхнего модуля программы, а выбор следующего подключаемого модуля происходит из числа модулей вызываемых из уже протестированных. Основная проблема при этом- создание заглушек. Так как после тестирования главного модуля процесс может разветвляться, надо модули содержащие операции ввода вывода подключать к тестированию как можно раньше; критические для программы в целях модули так же тестировать в первую очередь.
Достоинства нисходящего тестирования:
1. Уже на ранее стадии тестирование есть возможность получить работающий вариант разрабатываемой программы.
2. Быстро могут быть выявлены ошибки связанные с организацией взаимодействия с пользователем.
При нисходящем тестировании возможно совмещение нисходящего проектирования с тестированием, что неразумно, т.к. при проектировании возможен возврат и исправление принятых решений, что обесценивает результаты тестирования; можем возникнуть желание перейти к тестированию следующего модуля до окончания тестирования предыдущего по объективным причинам.
=2 Восходящая – при восходящем тестировании проверка программы начинается с проверки терминальных модулей, т.е. тех которые не вызывают никаких других модулей программы. Эта стратегия во многом противоположна нисходящему тестированию (преимущества становится недостатками) . В этой стратегии нет проблемы выбора следующего подключаемого модуля – учитывается лишь то, что бы он вызывал уже протестированные модули. В отличие от заглушек драйверы не должны иметь несколько версий, поэтому их разработка проще. При восходящем тестировании нет совмещения проектирования с тестированием, нет трудностей вызывающих желание перейти к тестированию след.модуля не завершив проверки предыдущего. Основным недостатком восходящего тестирования является то что проверка всей структуры разрабатываемого комплекса возможна только на завершающей стадии тестирования. Несмотря на то, что нельзя сделать выводы о преимуществе одной из стратегий пошагового тестирования, предпочтительнее – восходящее.
На третьем этапе тестирования комплексов при тестировании функций используется прежде всего методы функционального тестирования.
Функциональное тестирование.
Методы эквивалентного разбиения.
Проводится в 2 этапах:
1. Выделение по внешней спецификации классов эквивалентности. На нем происходит выбор из спецификации каждого входного условия и разбиения его на группы, соответствующие правильным и неправильным классам эквивалентности (ПКЭ, НКЭ), т.е. областям допустимых для программы и недопустимых значений входных данных. Этот процесс зависит от вида входного условия. Например, если входное условие описывает область (х<= 0,5) или количества, размер массива А=50, допустимых значений входных данных, то определяется один ПКЭ (х<0,5) или размер А<50 и 2 НКЭ (х< -0,5), x.0.5 или размер А<50, А>50. Если входное условие описывает дискретное множество допустимых значений входных данных. Например В={-1;0;1} то определяется ПКЭ для каждого значения из множества, и один НКЭ: В<= -1,8. Если входное условие описывает ситуацию ”Ложно быть”. Например N>0, то определяется один ПКЭ и один НКЭ –N<=0.
2. Построение множества тестов:
А) каждому классу присваивается свой номер.
Б) проектируются тесты для ПКЭ таким образом, что каждый тест покрывает как можно больше еще непокрытых ПКЭ до тех пор пока все ПКЭ не будут покрыты.
В) проектируются тесты для НКЭ, таким образом что каждый тест покрывает только один НКЭ до тех пор пока все НКЭ не будут покрыты. Нарушение этого условия проводят к тому, что некоторые тесты с недопустимыми значениями входных данных проверяют только одну ошибку и скрывают реакцию программы на другие ошибки.
Метод эквивалентности разбиения значительно лучше случайного подбора тестов, но и он имеет недостатки, основной – пропуск высоко эффективных тестов.
Метод анализа граничных условий.
Он отличается тем, что выбор любого представителя класса эквивалентности осуществляется таким образом, что бы проверить тестом каждую границу этого класса; при построении тестов рассматриваются не только входные условия, но и выходные, т.е. определенные на значения входных данных.
Общие правила метода:
1. Построить тесты для границ области допустимых значений входными данными и тесты с нед. Значениями, соответствующими незначительную выходу за границы этой области. Например, для области [-1;1] строят тесты: -1; 1; -1,001; 1,001.
2. Построить тесты для минимального и максимального значений входных условий определяющих дискретное множество допустимых значений данных. И тесты для значений больших или меньших этих величин. Например, если входной файл может содержать от 1 до 255 записей, то выбираются тесты для пустого файла, содержащего одну, 255, 256 записей.
3. Использовать правило 1 для каждого выходного условия: например, программа вычисляет ежемесячный расход лица или предприятия минимум которого 0,00$ максимум 1165,50$ тогда необходимо построить тесты вызывающие отрицательный расход, расходы 0 и 1165,5 и больший.
4. Использовать правило 2 для каждого выходного условия. Например, программа ищет и отображает на экране подходящие зависимости от условия рефераты статей, но не более 4х, тогда необходимо построить тесты приводящие к отображению 0;1;4 рефератов и попытке ошибочного отражения 5 рефератов.
5. Если входные и выходные данные программы представляют собой упорядочное множество последовательный файл, линейный список, таблицу, то при тестировании надо обратить внимание на первом и последнем элементе множества.
6. Попытаться найти и проверить тесты другими граничными условиями
Важность проверки границ выходных условий объяняется тем, что не всегда граничными значением входных данных соответствуют граничные значения результатов работы программ.
Метод анализа граничных условий может быть не эффективным, т.к. может быть трудно определить граничные условия.
Общим недостатком методов функционального тестирования является то, что при их применение исследуются возможные комбинации входных условий, что трудоемко, если их много. Избежать этого позволяет метод функциональных диаграмм.
Методы тестирования.
1. Статистический (символический) – базируется на правилах структурного построения программ и обработке данных .
2. Детерминированный – требует многократного выполнение программы на ЭВМ с использованием тестовых наборов данных.
3. Стохастический – использование в качестве входных данных случайных величин.
4. Проверяются результаты обработки данных с учетом времени их поступления, длительности и приоритетности обработки, динамики использования памяти и взаимодействия с другими программами. (в реальном маштабе времени)
Проектирование программ.
При постановке задачи для крупных программ необходимо выполнить работы: выработать требования (свойства, качества, возможности ) необходимые для достижения цели; разработать спецификации включающие цель программы, граничные условия, описание функций системы, спецификации входных и выходных данных, верификационные требования (установление тестовых случаев)4 типы и количество документов.
Требования к тестовым данным.
Тестовые данные должны обеспечить проверку всех возможных условий возникновения ошибок:
1. Должна быть испытана каждая ветвь алгоритма.
2. Очередной тестовый прогон должен контролировать то, что не было проверено ранее.
3. Первый тест должен быть максимально прост, что бы проверить работает ли программы вообще.
4. Арифметические операции в тестах должны предельно упрощаться для уменьшения объема вычисления.
5. Кол-ва элементов последовательности, точность для итерационных вычеслений, кол-во проходов цикла должны задаваться из
соображений сокращения объемов вычисления.
6. Минимизация вычислений не должна снижать надстности контроля.
7. Тестирование должно быть целенаправленным и систематизированным.
8. Усложнение тестовых данных должно происходить постепенно.
Пример:
Система тестов для задачи нахождения квад. Ур-ня ах2+вх+с=0
Процесс тестирования можно разделить на три этапа:
1. Проверка в нормальных условиях, предполагает тестирование на основе данных, которые характерны для реальных условий работы программы.
2. Проверка в экстремальных условиях. Тестовые данные включают граничные значения области изменения входных переменных, в котором должны восприниматься программы таких значений явл. Очень маленькие или очень большие числа и отсутствие данных. Возможен экстремальный тип условий – граничные объемы данных когда массивы состоят из слишком малого или слишком большого числа элементов.
3. Проверка в исключительных ситуациях. Проводится с использованием данных, значение которого лежат за пределами дополнительной области изменений.
Т.к. программы разрабатываются в расчете на обработку ограниченного набора данных, то важно получить ответы на вопросы: что произойдет если не предполагать обработка отрицательных и нулевых значений элементов, а в результате ошибки они появятся как будет вести себя программа работающая с массивами, если количество элементов будет больше объявленного; что произойдет если числа будут слишком малыми или слишком большими.
Наихудшая ситуация – когда программа воспринимает неверные данные как правильные и выдает не верный, но правдоподобный результат.
Разновидности ошибок программирования:
1. Неправильная постановка задач – правильное решение неверно сформулированной задачи.
2. Не верный алгоритм – выбор алгоритма приводящего к неточному или не эффективному решению задач.
3. Ошибка анализа – не полный учет ситуаций, которые могут возникнуть; логические ошибки.
4. Симантические ошибки – не понимание порядка выполнения операторов.
5. Синтаксические ошибки – нарушение правил, определяемых языком программирования.
6. Ошибки при выполнении операций – слишком большое число, деление на ноль, извлечение корня из отрицательного числа.
7. Ошибки в данных – не удачное определение возможного диапазона изменения данных.
8. Опечатки – перепутаны близкие по написанию символы
9. Ошибки ввода – вывода – наверное считывания входных данных, наверное задание форматов данных.
Синтаксические ошибки выявляются на этапе трансляции, их отсутствие является необходимым, но не достаточным условием, что бы считать программу правильной.
Примеры синтаксических ошибок:
1. Пропуск знака пунктуации.
2. Несогласованность скобок.
3. Неправильное формирование оператора.
4. Неверное написание служебных слов.
5. Неверное образование имен переменных
6. Отсутствие условий окончания цикла.
7. Отсутствие описание массива.
Ошибки обнаруживаемые тестированием.
(не обнаруживаются на этапе трансляции)
1. Логические ошибки: неверное указание ветви алгоритма после проверки условия; не полный учет возможных условий; пропуск в программе одного или нескольких блоков алгоритма.
2. Ошибки в циклах: неправильное указание начала цикла, условий окончания цикла, числа повторений цикла; бесконечный цикл.
3. Ошибки ввода/вывода и ошибки при работе с данными: неправильно задан тип данных считывается меньше или больше данных чем требуется, неправильное редактирование данных.
4. Ошибки в использовании переменных: нет начальных значений, одна используется вместо другой.
5. Ошибки при работе с массивами: массивы предварительно не обнулены; неправильно описаны;
6. Индексы следуют в неправильном порядке.
7. Ошибки арифметических операций: неверное указание типа переменной; порядка действий; деление на ноль; потери значащих разрядов числа; корень из отрицательного числа.
Оценка экономической эффективности разработки ПС.
В зависимости от темы дипломного проекта расчеты должны содержать:
I Проектирование новых, модернизации существующих моделей, агрегатов, механизмов, … программа.
1. Расчет производительности и выбор базы для сравнения.
2. Расчет себестоимости изготовления и оптовой цены.
3. Расчет капитальных вложений у потребителя.
4. Расчет эксплуатационных расходов.
5. Расчет показателей эконом. Эффективности.
II Научно – исследовательские разработки.
1. Обоснование выработанного выполнения исследования.
2. Расчет смены – затрат на проведение работы.
3. Оценка экономической эффективности применения результатов НИР.
В заключении делаются выводы об экономической целесообразности и степени риска принятия и внедрение разработок, исследованных в дипломной работе.
Калькуляция темы:
Осуществляется по следующими статьями расходов:
1. расходные материалы (бумага, чернила)
2. основная зарплата разработчиков.
3. Дополнительная зарплата разработчиков.
4. отчисления на соц. страхование.
5. накладные расходы.
6. Прочее расходы.
Оценка экономической эффективности.
Экономический эффект от использования ПП за расчетный период Т определяются по формулам:
Эт=Рт-3т, где Рт – стоимостная оценка результатов применения ПП в течении периода Т в рублях; Зт – стоимостная оценка затрат на создание и сопровождение ПП.
т
Рт=∑ pt x Lt где Рт – стоимостная оценка результатов t расчетного периода, Lt
f=0 дисконтирующая функция. Lt=1/(1+p)t
P= Eh=0.2 (Eh- нормативный коэффициент капитал вложений ), тогда
t
t- Pt= Pт/1,2t
f=0
Если ПП заменяет ручной труд, следовательно набор полезных результатов не меняется. В качестве оценки результатов применения ПП в год берется разница (экономия издержек, возникающая в результате использования ПП, т.е Pt = Эу – эта экономия от замены ручной обработки информации на автоматизированную образуется в результате снижения затрат на обработку Эу=3р-3а .)
3р = Он х Цм Х Гд/ Нв t=0 где Jy – объем информационной обрабатываемой вручную в мегабайте. Ц – стоимость одного часа работы в руб. Гд- коэ-нт учитывающий доп. Затраты времени на логические операции при ручной обработки Нв—норма выработки в Мб/ч.
3а=ta x Цм + to x (Цн + Цо), -где
ta – время автоматической обработки.
Цм- стоимость одного часа машинного времени.
to – время работы оператора.
Цо – стоимость одного часа работы оператора.
Экономический эффект от использования ПП за год:
Эг=Эу-Енх3к, а эффективность разработки:
Эр=Эг х 0,4 /3к
3к=3т
Расчет цены ПП
Цена ПП формируется на базе экономические обоснованной (нормативной) себестоимости ее производства и прибыли:
Цпп= С+Пн+Нэ, где
С- себестоимость ПП (можно использовать 3к)
Пн – нормативная прибыль
Нэ- надбавка к цене, если годовой экономический эффект от применения ПП составляет более 10 тыс. рублей.
Нормативная прибыль:
Пн=Уп х Фзп, где
Уп- уровень прибыли % к фонду з/п разработчиков,
Фзп – фонд з/п. разработчиков.
Уп = Руn + Pn, где
Pyn – расчетный уровень прибыли (=90 -100% к Фзп)
Pn – предложение разработчиков по 1 повышению Pyn на основе анализа эффективности ПП.
Пример расчета.
Задачей составляемой автоматизированной системы являются автоматизация регистрации несчастных случаев на производстве. Экономическая целесообразность разработки заключается в экономии трудозатрат по сравнению с ручной обработкой и получение достоверной информации за более короткое время.
Дополнительная зарплата разработчиков составляет 20% от основной:
0.2 * 6512,25 =1302,45
Фонд зарплаты (основная + доп. Зарплата)
6512,25+13,02,45=7814,70
Отчисление на соц. Нужды составляют 35% от фонда оплаты труда.
0,35*7814,70=2735,14накладные расходы составляют 250% от основной з.п.
2,5*6512,25=16280,63прочее расходы включают: расходы на машинное время (= 3 мес на разработку, отладку и тестирование, 700 часов, по 2р. час)
Калькуляция темы.
Оценка экономической эффективности ПП.
В данном случаи:
On=25мб (общий размер обрабатываемых данных, вводимых для регистрации за год с последующим подсчетом статистики.),
Ц=800/22/8=4,55 руб/час
Гд=2,50 (установлен экспериментально)
Нв=0,004 мб/час, поэтому затраты на ручную обработку информации: зр=25*4,5*2,5/0,004=71,093,75 руб.
Для данного ПП.
ta=18 часов
Цм= 2 руб
To=83,3 часа
Цо=750/22/8=4,26 (для ввода данных оператором регистрации одного случая =5 тысяч минут = 83.3 часа; для автоматической обработки введенных данных если получать по 10 справок в неделю, время получения справки = 2 минуты, понадобится 1080 минут = 18 часов в год.)
Поэтому затрат на автоматизированную обработку инф.
3а=18*2+83,3*(2+4,26)=557,46.
Таким образом годовая экономия от ПП
Эу=71,093,75-557,46=70536,29
Экономический эффект от использования ПП за год
Эг=70536,29-0,2*36780,48=0,68
Т.к. Эр>0,20, наша разработка является экономически целесообразной.
Предполагается что данный ПП без изменений и доработок будет использоваться в течении 5 лет, тогда стоимостная оценка результатов применение ПП (экономия) за расчетный период
Т=5 лет составляет
5
P5=∑ 70536.29 / 1.2t = 70536.29 + 58780.24 + 489.83.53 + 40819.6 + 34015.34 + 28346.95 = 281482.95.
Экономический эффект от использования ПП за расчетный период Т=5 лет составляет
Эт= 281482,95 – 36780,48 =244,702,47
Очевидно, что разработка нашей автоматизированной системы является абсолютно эффективной.
Расчеты цены ПП.
=90% Hn
Регистрация программы.
Производится федеральным министерством пром.
Свойством ФИПС.
Для регистрации необходимо док:
1. Заявка на регистрацию прог. на спец. Бланке. Заявки указывается: наименование программы, автор или группы разработчиков и право обладателя.
2. Описание в краткой форме о программе, с указанием средств разработки (должны иметь официальные ключи)
3. Фрагмент исходного текста программы с ключевым авторским моментами (обычно не более 50 листов)
4. Документ об оплате регистрационного сбора, он составляет в среднем 4 мин. Размера оплаты труда + оплата каждого авторского свидетельства, кот стоит 1 МРОТ (эти деньги идут на оплату публикации о регистрации вашего п.п.
5. Процесс регистрации после подачи всех документов занимает 2 месяца. Сущ. Ускоренные регистрации, но стоит дороже. Выдается свидетельство.)
Качество п.п.
Это совокупность свойств этой продукции, кот обуславливает ее способность удовлетворять опред. Потребности в соответствии с ее назначением. Чем сложнее изделие, тем больше приходится описывать число характеристик. Для каждого показателя или критерия качества опред. По метрике или методом измерения.
Основные критерии качества:
1. Формализация показателей качества программ обеспечивает группу стандартов.
В базовом международном стандарты сказано, что при отборе минимум станд. Показателей выдвигались и учитывались следующие принципы:
1. Ясность измерения значения.
2. Отсутствие перекрытий между показателем.
3. Соответствие понятиям терминологии.
4. Возможность последующего уточнения и детализации
В стандарте описаны хар-ки, которые позволяют оценивать программы с позиции пользователя.
1. Функциональная пригодность.
А) пригодность для применения.
Б) точность
В) защищенность
Г) способность к взаимодействию
Д) согласованность со стандартами и правилами проектирования
2. надежность.
А) уровень завершен
Б) отсутствие ошибок
В) устойчивость к ошибкам.
Г) перезапускаемость
3. применимость
А) понятность
Б) обучаемость
В) простота использования.
4. эффективность
А) ресурсная
Б) временная
В) по устройствам
5. споровождаемость
А) удобство для анализа
Б) изменяемость
В) стабильность
Г) тестируемость
6. переносимость
А) адактируемость
Б) структурируемость
В) замешаемость
Г) внедряемость
Модели конкретной разработки компании MS.
1. Менеджер продукта – должен реагировать на потребности заказчиков. Его задача сформировать общие представления о пред. Задаче и о том как ее решать. Основная цель – удовлетворение требований заказчика.
2. Менеджер программ – его задача вести процесс разработки с учетом всех ограничений, является руководителем проекта. Го цель повысить авторитет каждого сотрудника в своей фирме, но при этом является главным авторитетом для всех (подтверждается значениями предметной области.) главная обязанность выполнить все стадии разработки так, что бы нужный продукт был выполнен в назначенное время.
3. Разработчики – должны уметь оценивать свою работу, разрабатывать продукт.
4. Тестеры – отвечают за работоспособность продукта тестируют ее.
5. Инструктор – представляет интерес служб заказчиков, активно участвует в создании пользователей интерфейса.
6. Логистик – пред. Интересы служб, поддержки сопровождения, справочных служб.
Главный принцип коллективной разработки выпустить продукт. В нужное время. Для эффективной работы коллективной разработки требуется соблюдение следующих правил:
1. Доверие (мы делаем то, что обещаем сделать)
2. Уважение (каждый из нас необходим нам)
3. Согласие (мы верим в успех проекта.)
4. Ответственность (я обязан довести все до конца.)
Общинная модель разработки.
1. Децентрализованность разработки (как правило не существует ограничения по кол-ву людей занятых в проекте.)
2. Разработка ведется на базе открытых исходных кодов, по ним можно разобраться в сути задачи и в любой момент подключится к работе.
3. Большое кол-во беттотестировщиков, кот. Позволяют обнаружить ошибки и проблемы в программе…
Стандартизация процесса разработки программ…
Разработка программы исторически считалась прикладным искусством включающим более поэтому введение каких либо ограничений на приемы и технику программирования рассматривалась как мера на сужение творческого программирования.
В настоящее время большая сложность многих современных комплексов из-за их массивности универсальности, многогранности и динамичности их развития требует определенного уровня дисциплины и стандартизации в процессе создания программ.
Введение стандартов на разработку программы, направленные на достижение след. Результатов:
1. Упрощение процесса в разработке программы (улучшение качества прог. регулирования, стоимостей оценки затрат на разработку)
2. Обеспечение чтения и понимания программы посторонними лицами (это ведет к уменьшению кол-ва ошибок, повышает надежность, упрощает эксплуатацию)
Стандарты бывают международные (ISO, DOS, ANSI), национальные и отраслевые.
1. Жизненный цикл
2. Определение качества программы
3. Оперативная система (стандарты)
4. Стандартизированные языки программирования
5. Инструментальные системы (среды)
6. Стандарты пользовательского интерфейса.
7. Форматы данных.
8. Сети (стандартизированные протоколы).
9. Стандарты о документации.
10. Стандарты тестирования.
Стандарты по документации:
1. ЕСПД оперд. Какие док. Должны быть определены для разработки.
2. Документы по оформлению документации.
Тщательно продуманная стандартизация процесса разработки программы позволяет программисту концентрировать внимание на более сложном моменте, а техническую работу по написанию кодов, выбора управляющих структур, выполнение контроля проводить без особых усилий, опираясь на принятые стандарты. Это позволяет избегать технических ошибок и описок, повысить производительность труда.
Работа программиста, как валкий интеллектуальный труд трудно поддается контролю оценки. Введение стандартов наталкивается на определенное сопротивление со стороны программиста. В стандартах обобщаются опыт и исследований множества специалистов.
В стандартах сосредотачиваются наиболее эффективные и современные методы и процессы, а так же методическая база для их автоматизации. Стандарты приводят к снижению затрат на разработку программы.
Пользовательский интерфейс.
Устанавливает серверную связь с пользовательскими. Пользователи бывают разные, разные поэтому и требования.
Рассмотрим следующие виды потенциальных пользователей:
1. Пользователи далеки от программирования (не имеющие опыта работы)
2. Пользователи далеки от прог-ия, но имеющие опыт работы с компьютерной техникой.
3. Прикладные программисты, т.е. не те кто хорошо знает тонкости построения программной системы, может ее модифицировать, кто знает метрологию проектирования, кто может разрабатывать алгоритмы и разбираться в них.
4. Системные программисты – специалисты в области применения ПК, способны разработать базовые методы и оснащение ПО. Осуществляет настройку ПО при условии конкретного применения.
Чтобы интерфейс оказался удобным он должен выполнять базовые требования: быть простым, предсказуемым, надежным, а так же вместить в себя возможность без потерь адаптироваться к изменению, по запросу пользователя.
В основе хорошего интерфейса лежат несколько принципов, которые тесно взаимосвязаны, а иногда даже противоречивы:
1. Детали реализации
2. Ограничьтесь независимым набором независимых примитивов.
3. Интерфейс должен быть само достаточным.
4. Все элементы должны быть стандартны и похожи друг на друга.
5. Обнаруживаете ошибки на низком уровне.
6. Используйте исключения только для критических ситуаций.
Для работы с программой существует 2 вида пользовательского интерфейса:
1. Диалоговый или интерактивный.
2. Пакетный режим
Диалоговый режим (интерактивный)
Пользователь вводит команды и получает результат .
Элементами диалога являются:
1. Меню
2. Окна ввода данных
3. Окна вывода данных
4. Окна справочников.
Особенности режима:
1. Применяется в современных программах.
2. Предназначены для пользователей, а не для программистов.
3. Ресурсы не сильно израсходываются .
Пакетный режим.
Действие пользователя ограничивает задание, пользователю, не обязательно присуствовать при работе в программе.
Особенности:
1. Применение широко применяется в О.С. как классический пример MSDOS.
2. Предназначены для более опытных пользователей.
3. Ресурсы тратятся меньше, чем при другом режиме.
Эффективность и оптимизация программы.
Она определяется временными характеристиками и задействованными ресурсами.
Программа неэффективна когда:
1. Работает медленно
2. Решает узкую задачу
3. Выдает не полную информацию.
4. Велика по объему не использует предоставленные возможности ПК.
Программа оптимальна тогда, когда в ней уравновешены время и используемые ресурсы. Разработка эффективна когда на нее затрачено минимальное время, а предоставленные ресурсы, (время, кадры и технологии) использованы целесообразно.
Эффективный алгоритм – экономии памяти, времени, простота и легкость.
Чтобы добиться эффективности нужно проводить оптимизацию программы, она бывает 2х видов:
1. Глобальная оптимизация – это оптимизация при которой экономии ресурсов достигается путем изменения алгоритма всей или большей части программы.
2. Локальная оптимизация – это оптимизация при которой экономия ресурсов достигается путем изменения участка программы.
Способы локальной оптимизации:
1. Чистка программы.
2. Разгрузка участков повторения.
3. Реализация действий.
4. Упрощение действий
5. Экономия памяти
6. Сокращение программы.
Чистка программы – способы повышения качества за счет удаления ненужных объектов и конструкции.
Разгрузка участков повторения – если в цикле имеются элементы, которые не изменяются в цикле, то их выносят за пределы цикла.
Реализация действий – это способы повышения качества программы за счет выполнения определенных вычислений на этапе трансляции, набор преобразований включает в себя действия над константами, замена условных операторов на переключатели.
Упрощение действий – он ориентирован на улучшении программы за счет замены групп операторов, как правило на др. группу операторов, которые выполняют те же действия, операторов, кот. Выполняют те же действия, но с меньшим количеством операторов.
Экономия паняти – способ уменьшения программы за счет уменьшения объема памяти.
Сокращение программы – это способы улучшения программы за счет сокращения ее размеров, т.е. чистка и создание процедуры.
Достоинства: сразу можно преступить к разработке.
Недостатки:
1. Уход от цели
2. Трудно поддается планированию и контроля.
3. Самая тяжелая работа в конце разработки.
Вывод: программа имеет низкое качество, справится могут только классификационные программисты.
Нисходящий подход (декомпозиция) структурирован сверху вниз.
Достоинства:
1. Постепенное погружение задач
2. Поддается планированию и контролю
3. Самая тяжелая работа вначале
4. Качество программы на порядок выше, чем восход. поход.
5. Проект выполняется сущ. Быстрее.
Недостатки: сложность работы вначале.
Внешнее проектирование.
Это процесс описания планированного поведения разрабатываемой программы с точки зрения потенциального пользователя.
Существует 3 вида программных проектов:
1. Управляемые пользователем
2. Утверждаемые пользователями
3. Независимые от пользователей.
Цель:
Цель: конкретизация внешних взаимодействий будущей программы без детализации внутреннего устройства.
Результатом внешнего проектирования является документ, разрабатываемый разработчиком и согласуемый с заказчиком программы, который носит название внешней спецификации.
Внешним проектированием решается 3 проблемы.
1. Доведение до минимума ошибок пользователя.
2. Обнаружение ошибок пользователя в случаи их возникновения.
3. Доведение до минимума сложности разрабатываемых программ.
Содержание разделов внешних спецификаций.
1. Описание входных данных (формат данных, доп. Значение области изменения ограничений, диапазон)
2. Описание выходных данных (таблица, график, бланк и т.д.)
3. Описание задачи (сценарий, правила, игры)
4. Характеристика надежности (описывается внешние всех возможных отказов.)
5. Эффективность (ограничения - память)
6. Замечание по применению:
А) описание задач
Б) описание входных и выходных данных.
В) метод решения задач
Г) методы программирования
Д) разрабатываются тесты
Е) контроль целостности данных
Ж) замечание по программированию
Внутреннее проектирование.
На этом этапе разрабатываются структура данных и структура программы.
Цель: создать ясную и четкую структуру программы, данных и пользовательского интерфейса.
Результатом внутреннего проектирования является схемы, алгоритмы и пояснительная записка.
Список схем:
1. Функциональная схема - в схеме отражаются декомпозиция задачи на составленные части, сохраняя при этом ее физ. Смысл. Предоставление зависит от предметной области задач и используемого языка программирования. При традиц. Прог-ни схема представляет собой иерархическую структуру.
При объектно – ориенторованном прогр. Составляется схема иерархии объектов и таблица, поясняющая схему. В таблице приводятся данне каждого объекта (имя, физ. смысл)
2. Структурная схема – иерархическая схема связи модулей к котором прилагаются поясняющие таблицы (например, имя блока, ф-ция блока)
3. Схема данных б.д. – описание структур (таблиц)
4. Схема пользовательского интерфейса – маршрутработы программы (новегация)
5. Укрупненный алгоритм – словесный и графический в виде блок. Схемы.
Модульное программирование.
Модульные программы – это программы в котором модульная часть логической структуры можно извличить, не внося изменения в основную часть программы, этот метод является воплощением одного из метода борьбы со сложностями (ошибки).
Модуль – это объектный файл или именованная часть программы, которая создается средствами языка программирования и его настройками.
Основное свойство модуля – независимость.
Так же модуль обладает 3 характеристиками:
1. Функция (что делает программа)
2. Логика (как делает программа)
3. Связь (потоки информации – внутренняя и внешняя.)
Внутренние связи модуля характеризуется понятием прочности модуля чем больше внутр. Связей, тем модуль более неуязвим.
Существует 7 классов прочности:
Функционально- прочный модуль опред. На стадии разработки функц. Схемы.
Внешние связи или сцепление хар-ются степенью к данным. Использование глобальных переменных, способов передачи данных и кол-ва, то на сколько они структурированы.
При проектировании нужно стремится, что бы все модули были независимыми.
1. Библиотека- это набор откампимерованных программ, собранных в специально форматированный файл. Библиотека создается используя программу управления библиотек путем объединения объектных файлов в один файл.
Подключение библиотек производит редактор связи. Он подключает только то, что нужно.
Библиотека является главным местом для того, что бы поместить программы, кот. Используются в различных приложениях. При этом экономится память, все подпрограммы хранятся в одном месте, это ускоряет комновку.
2. Подпрограмма – это средства языка программирования служащие для увеличения уровня языка программирования. Что бы изменить структуру распределения данных для подпрограмм данные делят на глобальные и локальные (для лучшей работы над ошибками )
Механизм – это то что происходит при вызове.
1. Запоминается в сетевой области адрес ячейки, куда нужно обратиться после выполнения программы.
2. Запоминаются все регистры которые будут использоваться в этой подпрограмме.
3. Отводится место в стековой области для лок. Переменных, по необходимости инициализируются данные.
4. Выполнение программы.
Так как работа команд со списком является самой долгой то работа с подпрограммами нуждается в доп. Времени, поэтому подпрограммы выполняются дольше несмотря на то, что размер их меньше. При работе с подпрограммами данные бывают локальные и глобальные, с кот. Связаны понятие видимости, времени жизни и листа хранения. А так же выделяют данные обмена (формальные и фактические параметры функций)
Данные могут передаваться как по ссылке так и по значению.
3. Объектный модуль – это модуль спец. Структуры, созданный компилятором, бывают двух типов:
А) с расширением *obj (MS)
Б) *fpu (bohlanol)
4. модуль исходного текста – это обычный текстовый фоайл с нужным расширением
Загрузочный модуль - *.exe – это фактически отдельная программа, явл. Самым независимым модулем.
Макро-команды – они ярко выражены в ассемблере. Представляются собой фактически часть текста программы, которая подставляется при каждом вызове, это увеличивает ее.
Системы программирования.
Системы программирования делят:
1. Автономные (ассембле)
2. Среды программирования
Системы программирования включают в себя:
1. Язык программирования
2. Редактор
3. Транслятор
4. Компилятор/интерпритатор
5. Компоновщик
6. Отладочные средства
7. Библиотеки станд. Программ
8. Итератор кодов для объектно – ориентированного прог.
9. Библиотеки визуальных компонентов.
10. Дополнительные утилиты.
Язык программирования – это система обозначения позволяющая описывать задачи.
Языки программирования делят:
1. По уровням
А) низкие
Б) высокие (алгоритмы)
В) сверхвысокие (задачи)
2. по подходам
А) алгоритмические Pascal, Ci
Б) функциональные Rabol, lisp
В) объектно ориентированные Ci+, Delphi.
Г)логические Pholog
Д) параллейные – язык OKAN.
Транслятор – средство переводов текстов в формат языка программирования.
Интерпретатор – последовательно выполняющий функции: поиск ошибок, перевод в машинный код и выполнение.
Его преимущество – это удобство для отладки.
Недостаток: медленная работа.
Компилятор – осущ. Преобразование текста программы в промежуточный код, а затем компоновщик преобразует в маш. Код.
Архитектура программного средства.
Архитек4тура ПС – это его строение, т.е. представление п.с. как системы взаимодействующих небольших подсистем.
Основными задачами разработки архитектуры ПС:
1. Выделение программных подсистем и отображение на них внешних функций (заданных во внешнем описании)
2. Определение способов взаимодействия между выделенными прог. подсистемами.
Основные классы архитектур ПС:
1. Цельная программа – представляет собой п.с. которое должно выполнять одну ярко выраженную функцию (несложную)
2. Комплекс автономно выполняемых программ.
Он состоит из напора программ таких, что:
А) любая из напора программ может быть сективизирована пользователем.
Б) при выполнении программы другие прог. не могут быть активизированы.
В) все прог. этого набора применяются к одной и той же информационной среде.
Таким образом, прог. этого набора по управлению не взаимодействуют друг с другом, но при этом находятся в одной инф. Среде.
3. Слоистая прог. система – состоит из некоторой упорядочной совокупности прог. подсистем у, кот. Называется слои.
Слои должны быть:
А) на слое ничего не должно быть известно и свойствах других слоев (как правило более высокого уровня)
Б) каждый слой может взаимодействовать по управлению (обращаться к компоненту) более низкого слоя через заранее определенный интерфейс
Любой из слоев знает только один предшествующий ему слой.
В) каждый слой располагает опред. Ресурсам, которые он скрывает от других слоев, либо предоставляет через интерфейс верхнему слою.
Таким образом в сложной прог. системе каждый слой может реализовывать некоторую абстракцию данных (интерфейс).
В качестве примера рассмотрим архитектуру О.С. такую архитектуру применения. Дейстер. (THE) она состоит из четырех слоев. На нулевом слое производится обработка всех прерываний и выделение процессорного времени в пакетном режиме. На первом слое осуществляется управление страничной организации памяти. На втором слое осущ. Связь с консолью оператора.
На третьем слое осуществляется буферизация входных и выходных данных и организуется в интерфейсе входов и выходов.
Архитектура O.C. THE
|
4. Коллектив параллейно-действующих программ представляет собой набор программ способных взаимодействовать между собой находясь одновременно в стадии выполнения. Т.е. в оперативной памяти могут быть разделены, активизированы несколько потоков инф. Простейшей разновидностью такой архитектуры является конвейер. Возможности для организации конвейера (реализация в О.С. UNIX):
Конвейер обрабатывает некоторый потом сообщений
Контроль архитектуры п.с.
Для контроля архитектуры используется смежный контроль и ручная имитация.
Смежный контроль архитектуры п.с. – это ее контроль разработчиками внешнего описания. Выполняется разработчиками спец-ии качества (контроль идет сверху вниз). Смежный контроль архитектуры п.с. который индекс снизу вверх контролирует разработчики подпрограммных систем.
Ручная имитация.
Производится аналогично ручной функциональной спецификации. Только цель этого контроля является проверка взаимодействия между программ. Подсистемами.
Архитектурные функции.
Для обеспечения взаимодействия между подсистемами в ряде случаев не требует создавать какие-либо дополнительные прог. документы.
Помимо реализаций внешних функций для этого может быть достаточно заранее зафиксировать соглашение. (т.е. стандартных возможностей базового п.о.) так как к примеру в комплексе автономной выполненных программ, для обеспечения, взаимодействия достаточно описания общей, внешней инф. Среды или возможности О.С. для запуска может оказаться достаточным описания каждого из слоев.
В программном конвейере взаимодействие между программами так же может обеспечивать операц. Система UNIX. Хотел обычно требуется создание дополнительных программных компонентов, т.к. для управления работой комплекса автономно-выполняемых проектов очень часто создают специализированный команд. Интерпретатор, который является долее удовлетворительным для подготовки требуемой внешней инф. Среды.
В коллективе параллейно действующих программ для управлениями сообщениями требуется специальная проектная подсистема. Такие проектные компоненты реализуют не внешний функции ПС, а функции возникшие в результате архитектуры этого ПС. В связи с этим так же функции называются архитектурной.
Отладка программных средств.
Это деятельность направленное на обнаружение и исправление ошибок в проектном средстве. П.О. отладку можно представить в виде повторения 3х процессов: тестирование, в результате которого могут быть обнаружены ошибки, поиска метода ошибки в программах и документациях; редактирование программ и документаций с целью исправить ошибки.
Другими словами: отладка = тестирование +поиск ошибки + редактирование.
Успех отладки ПС в значительной степени предопределяет рациональная организация тестирования. Ошибки в основном исправляются те, которые определяются при тестировании, при этом сразу можно утверждать, что существует 2 недостатка:
1. Даже самый полный набор тестов не может дать 100% гарантию в том, что он найдет ошибки.
2. Затраты на отладку ПС увеличиваются пропорционального времени тестирования.
Общие рекомендации по организации отладки ПС.
1. Считается, что тестирование программного средства является ключевой задачей. Поручать его самым квалифицитированным или одаренным прог. желательно, что бы это были люди со стороны.
2. Хорош, тот тест, для которого высока вероятность обнаруживать ошибку, а не тот который демонстрирует правильную работу программы.
3. Готовый тест для всех тестов данных
4. Документируйте каждый тест, иногда тест стоит повторить
5. Каждый модуль подключайте к программе только один раз. Иногда изменяйте прог., что бы облегчить ее тестирование.
6. Пускайте заново все тесты еще раз. Если в программу были внесены дали незначет. Изменения.
Комплексная отладка программного средства.
В основном тестируется программное средство целиком:
1. Тестирование архитектуры происходит в самом начале, при этом осущ. Поток между соответствием архитектуры ПС. Совокупностью прог. ПС.
2. Тестирование внешних функций является поиск между функциями спецификацией и совокупностью программы ПС.
3. Тестирование качества ПС – осущ. Поиск нарушений требований качества, сформулир. Спецификацией ПС.
4. Тестирование документа по применению ПС.
5. Тестирование окр. Требований ПС. Целью тестирования является внесение несоответствия
6. Требований предъявляемых к работе ПС.
Программные средство, их характеристика и классификация.
1. Программно-ориентированные пакеты – это самый большой класс, в основном используется для создания АЗЬ и делятся по типам предметных областей.
2. Методоориентированные пакеты. Используется в узких специализированных областях.
3. Программные средства общего назначения. Используется как СУБД.
4. Пакеты для автоматизированного проектирования. Необходимы для создания чертежей и т.д. чаще всего применяются в Case-технологии проектирования.
5. Офисные пакеты. MS Office, Open Office (электронные таблицы, лок. СУБД, текстовые редакторы, пакеты для создания призентаций).
6. Программные средства multimedia (графические пакеты, мультимедийных проекты)
7. Настолько-издательские системы (Page Maler)7.0
8. Интеллектуальные или экспетные системы
Объектный подход к разработке ПС.
Окруж. Нас мир состоит из объектов и отношений между ними. Таким образом объект вопращает некоторую сущность и имеет некоторое состояние. Оно может изменяться с течением времени. В основном изменения с объектном происходят из-за воздействия (взаимодействия)
Других объектов с ним. Так же объект может иметь свою структуру, т.е. подразделяться на более мелкие объекты. Некоторые объекты, при этом можно считать, что объединение этих объектов обладает некот. Свойствам. Если отношения связывают N объектов, то оно называется n-местное. Одноместные отношения называются простым свойством объекта. На каждом месте объединение объектов, которые могут быть связаны отношениями друг с другом, такие объекты называются объекты определенного класса. Множество всех объектов которое обладают каким – либо общим набором свойств называется классом объектов. Состояние объекта и его многоместное отношение называется ассоциативным свойством объекта (только если этот объект участвует в отношениях)
В любом случае представление отношения определяет нет. Действия по обработке данных.
Основной подход к изучению модельного мира провоцировал функциональный (реллиционный подход) сущность этого подхода состоит в том, что систематически используется диколекозиция функций. (отношений) для описания структуры построения ПС, кроме того сами объекты модельного мира с кот. Связаны опред. Функции представляются фрагментарно. В том объеме, кот. Необходим для работы функции.
Тем самым можем получить эффективную реализацию требований функции.
С точки зрения разработки ПС следует различать следующие категории объектов (их классы)
1. Объекты модельного (вещественного или умственного мира)
2. Информационные модели объектов реального мира
3. Объекты процесса выполнения программы.
4. Объекты процесса разработки ПС (технологии объекты прог.)
Кроме того в зависимости от способа представления в компьютере модельного мира и характера взаимодействия с ним пользователем след. Различать.
Когда говорят об объектно-ориентир. Подходе к разработке ПС имеют в виду объектный подход с ориентацией на описание объектом модельного мира и их отношений чаще всего используется активные объекты.
Многие процессы разработки ПС приобретают специф. Черты:
1. Использование системы понятий, позволяющие прописывать объекты и их классы.упращения
2. Декомпозиция объектов является основным средством упращенияПС.
3. Использование внепрограммных абстракций для упращения разработки ПС.
4. Предпочтение разработки структуры данных перед реализацией функций.
Особенности объектного подхода к разработке описания ПС, пример отношение между классами объектов.
Определение требований по сравнению с реализационным подходом описывается при помощи спецификации модельного мира, кот. Пользователь собирается изучать или просто использоваться. Существенно изменяется содержание процесса спецификации требований вместо разработки функциональной части ПС. Создается формальное описание модельного мира, состоящая из 3х частей:
1. Объектная модель
2. Динамическая модель
3. Функциональная модель
Обычно класс объектов в объектной модуле представляется в виде тройки наименований (имя класса, список атрибутов, список операций) каждый атрибут представляется некоторым именем и может принимать значение определенного типа данных, т.е. атрибут класса выражает некоторое простое свойство объектов этого класса.
Основные отношения, используемые в объектной модели является одноместным (атрибуты) и двуместные. Отношения между двумя и более объектами называются связями, а их обобщение называется ассоциациями.
Виды ассоциаций:
1. Взаимодействие состояний объектов.
2. Агрегирование (структурирование)
3. Абстрагирование(порождение классов)
