Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
CASE- средства17
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО.
Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями:
мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;
интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;
использование специальным образом организованного хранилища проектных метаданных (репозитория).
Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты;
репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;
средства разработки приложений, включая языки 4GL и генераторы кодов;
средства конфигурационного управления;
средства документирования;
средства тестирования;
средства управления проектом;
средства реинжиниринга.
Автоматизированные средства разработки ПО16
Разрабо́тка програ́ммного обеспе́чения— это род деятельности (профессия) и процесс, направленный на создание и поддержание работоспособности, качества и надежности программного обеспечения, используя технологии, методологию и практики из информатики, управления проектами, математики, инженерии и других областей знания.
Информатика как научная дисциплина предлагает и использует на базе методов структурного программирования технологию надежной разработки программного обеспечения, используя тестирование программ и их верификацию на основе методов доказательного программирования для систематического анализа правильности алгоритмов и разработки программ без алгоритмических ошибок.
Методология структурного проектирования программного обеспечения может использоваться с применением самых различных языков и средств программирования для разработки надёжных программ самого различного назначения.При выборе методологии разработки программного обеспечения следует руководствоваться тем, что сложность методологии сравнима со сложностью структуры программного продукта, и неоправданная для продукта данной сложности сложность методологии только неоправданно увеличит стоимость разработки. Примером современной методологии проектирования может быть проблемно-ориентированное проектирование.
Автономная отладка и тестирования программного средства.44
При автономной отладке ПС каждый модуль на самом деле тестируется в некотором программном окружении, кроме случая, когда отлаживаемая программа состоит только из одного модуля. Это окружение состоит из других модулей, часть которых является модулями отлаживаемой программы, которые уже отлажены, а часть ? модулями, управляющими отладкой (отладочными модулями, см. ниже). Таким образом, при автономной отладке тестируется всегда некоторая программа (тестируемая программа), построенная специально для тестирования отлаживаемого модуля. Эта программа лишь частично совпадает с отлаживаемой программой, кроме случая, когда отлаживается последний модуль отлаживаемой программы. В процессе автономной отладки ПС производится наращивание тестируемой программы отлаженными модулями: при переходе к отладке следующего модуля в его программное окружение добавляется последний отлаженный модуль. Такой процесс наращивания программного окружения отлаженными модулями называется интеграцией программы. Отладочные модули, входящие в окружение отлаживаемого модуля, зависят от порядка, в каком отлаживаются модули этой программы, от того, какой модуль отлаживается и, возможно, от того, какой тест будет пропускаться.
При восходящем тестировании это окружение будет содержать только один отладочный модуль (кроме случая, когда отлаживается последний модуль отлаживаемой программы), который будет головным в тестируемой программе. Такой отладочный модуль называют ведущим (или драйвером). Ведущий отладочный модуль подготавливает информационную среду для тестирования отлаживаемого модуля (т. е. формирует ее состояние, требуемое для тестирования этого модуля, в частности, путем ввода некоторых тестовых данных), осуществляет обращение к отлаживаемому модулю и после окончания его работы выдает необходимые сообщения. При отладке одного модуля для разных тестов могут составляться разные ведущие отладочные модули.
При нисходящем тестировании окружение отлаживаемого модуля в качестве отладочных модулей содержит отладочные имитаторы (заглушки) некоторых еще не отлаженных модулей. К таким модулям относятся, прежде всего, все модули, к которым может обращаться отлаживаемый модуль, а также еще не отлаженные модули, к которым могут обращаться уже отлаженные модули (включенные в это окружение). Некоторые из этих имитаторов при отладке одного модуля могут изменяться для разных тестов.
На практике в окружении отлаживаемого модуля могут содержаться отладочные модули обоих типов, если используется смешанная стратегия тестирования. Это связано с тем, что как восходящее, так и нисходящее тестирование имеет свои достоинства и свои недостатки.
К достоинствам восходящего тестирования относятся:
• простота подготовки тестов,
• возможность полной реализации плана тестирования модуля.
Это связано с тем, что тестовое состояние информационной среды готовится непосредственно перед обращением к отлаживаемому модулю (ведущим отладочным модулем).
Недостатками восходящего тестирования являются следующие его особенности:
• тестовые данные готовятся, как правило, не в той форме, которая рассчитана на пользователя (кроме случая, когда отлаживается последний, головной, модуль отлаживаемой программ);
• большой объем отладочного программирования (при отладке одного модуля приходится составлять много ведущих отладочных модулей, формирующих подходящее состояние информационной среды для разных тестов);
• необходимость специального тестирования сопряжения модулей.
К достоинствам нисходящего тестирования относятся следующие его особенности:
• большинство тестов готовится в форме, рассчитанной на пользователя;
• во многих случаях относительно небольшой объем отладочного программирования (имитаторы модулей, как правило, весьма просты и каждый пригоден для большого числа, нередко ? для всех, тестов);
• отпадает необходимость тестирования сопряжения модулей.
Недостатком нисходящего тестирования является то, что тестовое состояние информационной среды перед обращением к отлаживаемому модулю готовится косвенно ? оно является результатом применения уже отлаженных модулей к тестовым данным или данным, выдаваемым имитаторами. Это, во-первых, затрудняет подготовку тестов и требует высокой квалификации тестовика (разработчика тестов), а во-вторых, делает затруднительным или даже невозможным реализацию полного плана тестирования отлаживаемого модуля. Указанный недостаток иногда вынуждает разработчиков применять восходящее тестирование даже в случае нисходящей разработки. Однако чаще применяют некоторые модификации нисходящего тестирования, либо некоторую комбинацию нисходящего и восходящего тестирования. Исходя из того, что нисходящее тестирование, в принципе, является предпочтительным, остановимся на приемах, позволяющих в какой-то мере преодолеть указанные трудности.
Часто применяют также комбинацию восходящего и нисходящего тестирования, которую называют методом сандвича. Сущность этого метода заключается в одновременном осуществлении как восходящего, так и нисходящего тестирования, пока эти два процесса тестирования не встретятся на каком-либо модуле где-то в середине структуры отлаживаемой программы. Этот метод при разумном порядке тестирования позволяет воспользоваться достоинствами как восходящего, так и нисходящего тестирования, а также в значительной степени нейтрализовать их недостатки.
Автономное тестирование модуля целесообразно осуществлять в четыре последовательно выполняемых шага.
Шаг 1. На основании спецификации отлаживаемого модуля подготовьте тесты для каждой возможности и каждой ситуации, для каждой границы областей допустимых значений всех входных данных, для каждой области изменения данных, для каждой области недопустимых значений всех входных данных и каждого недопустимого условия.
Шаг 2. Проверьте текст модуля, чтобы убедиться, что каждое направление любого разветвления будет пройдено хотя бы на одном тесте. Добавьте недостающие тесты.
Шаг 3. Проверьте текст модуля, чтобы убедиться, что для каждого цикла существуют тесты, обеспечивающие, по крайней мере, три следующие ситуации: тело цикла не выполняется ни разу, тело цикла выполняется один раз и тело цикла выполняется максимальное число раз. Добавьте недостающие тесты.
Шаг 4. Проверьте текст модуля, чтобы убедиться, что существуют тесты, проверяющие чувствительность к отдельным особым значениям входных данных. Добавьте недостающие тесты.
Алгоритм программы62
Структурная блок-схема, граф-схема алгоритма — графическое изображение алгоритма в виде схемы связанных между собой с помощью стрелок (линий перехода) блоков — графических символов, каждый из которых соответствует одному шагу алгоритма. Внутри блока дается описание соответствующего действия. Графическое изображение алгоритма широко используется перед программированием задачи вследствие его наглядности, так как зрительное восприятие обычно облегчает процесс написания программы, ее корректировки при возможных ошибках, осмысливание процесса обработки информации.
Можно встретить даже такое утверждение: "Внешне алгоритм представляет собой схему — набор прямоугольников и других символов, внутри которых записывается, что вычисляется, что вводится в машину и что выдается на печать и другие средства отображения информации ".
Аттестация программных систем14
Завершающим этапом разработки ПС является аттестация ПС, подводящая итог всей разработке. Аттестация (certification) ПС - это авторитетное подтверждение качества ПС . Обычно для аттестации ПС создается аттестационная комиссия из экспертов, представителей заказчика и представителей разработчика. Эта комиссия проводит приемо-сдаточные испытания ПС с целью получения необходимой информации для оценки его качества. Под испытанием ПС здесь понимают процесс проведения комплекса мероприятий, исследующих пригодность ПС для успешной его эксплуатации (применения и сопровождения) в соответствии с требованиями заказчика. В этом процессе проверяется полнота и исследуется качество представленной программной документации, производится необходимое тестирование программ, входящих в состав ПС, а также исследуются и другие свойства ПС, декларированные в его спецификации качества. На основе полученной информации комиссия должна установить, в какой степени ПС выполняет декларированные функции и в какой степени ПС обладает декларированными примитивами и критериями качества. Решение аттестационной комиссии о произведенной оценке качества ПС фиксируется в соответствующем документе (сертификате), который подписывается членами комиссии.
Таким образом, оценка качества ПС является основным содержанием процесса аттестации. Аттестация ПС похожа на смотр различных компонент ПС в процессе управления качеством ПС, однако, имеются и существенные различия . Во-первых, смотр проводится менее представительной группой специалистов. Во-вторых, в процессе смотра не производится полной оценки качества ПС, а выявляются лишь отдельные просчеты и нарушения требований относительно качества ПС, связанные с обозреваемой компонентой (документом), при этом не требуется немедленного устранения выявленных недостатков, если они не мешают проведения последующих работ. Целью же аттестации является проверка и фиксация реальных показателей качества предъявленного ПС . Если аттестационная комиссия подтверждает, что предъявленное ПС соответствует всем требованиям относительно его качества, сформулированным во внешнем описании этого ПС, то считается, что его разработка завершена успешно и заказчик обязан принять это ПС. Если же будут обнаружены отступления от этих требований, то должны приниматься определенные решения о продолжении или прекращении разработки предъявленного ПС, но это уже вопрос взаимоотношений между заказчиком и разработчиками. Таким образом, аттестационная комиссия, подписывая документ о произведенной оценке качества ПС, принимает на себя определенную ответственность за гарантию качества этого ПС. Но здесь имеются определенные правовые проблемы, обсуждение которых выходит за рамки темы этой лекции.
Виды версий ПО68
Интеграцио́нное тести́рование (англ. Integration testing, иногда называется англ. Integration and Testing, аббревиатура англ. I&T) — одна из фаз тестирования программного обеспечения, при которой отдельные программные модули объединяются и тестируются в группе. Обычно интеграционное тестирование проводится после модульного тестирования и предшествует системному тестированию.
Интеграционное тестирование в качестве входных данных использует модули, над которыми было проведено модульное тестирование, группирует их в более крупные множества, выполняет тесты, определённые в плане тестирования для этих множеств, и представляет их в качестве выходных данных и входных для последующего системного тестирования.
Целью интеграционного тестирования является проверка соответствия проектируемых единиц функциональным, приёмным и требованиям надежности. Тестирование этих проектируемых единиц — объединения, множества или группы модулей — выполняется через их интерфейс, с использованием тестирования «чёрного ящика».
Модульное тестирование - это тестирование программы на уровне отдельно взятых модулей, функций или классов. Цель модульного тестирования состоит в выявлении локализованных в модуле ошибок в реализации алгоритмов, а также в определении степени готовности системы к переходу на следующий уровень разработки и тестирования. Модульное тестирование проводится по принципу "белого ящика", то есть основывается на знании внутренней структуры программы, и часто включает те или иные методы анализа покрытия кода.
Модульное тестирование обычно подразумевает создание вокруг каждого модуля определенной среды, включающей заглушки для всех интерфейсов тестируемого модуля. Некоторые из них могут использоваться для подачи входных значений, другие для анализа результатов, присутствие третьих может быть продиктовано требованиями, накладываемыми компилятором и сборщиком.
Виды документов программного средства.35
К программным относят документы, содержащие сведения, необходи мые для разработки, сопровождения и эксплуатации программного обеспе чения. Документирование программного обеспечения осуществляется в со ответствии с Единой системой программной документации (ГОСТ 19.ХХХ). Так ГОСТ 19.101-77 устанавливает виды программных документов для про граммного обеспечения различных типов. Ниже перечислены основные про граммные документы по этому стандарту и указано, какую информацию они должны содержать.
Спецификация должна содержать перечень и краткое описание назначе ния всех файлов программного обеспечения, в том числе и файлов докумен тации на него, и является обязательной для программных систем, а также их компонентов, имеющих самостоятельное применение.
Ведомость держателей подлинников (код вида документа - 05) должна содержать список предприятий, на которых хранятся подлинники программ ных документов. Необходимость этого документа определяется на этапе раз работки и утверждения технического задания только для программного обес печения со сложной архитектурой.
Текст программы (код вида документа - 12) должен содержать текст программы с необходимыми комментариями. Необходимость этого докумен та определяется на этапе разработки и утверждения технического задания.
Описание программы (код вида документа - 13) должно содержать све дения о логической структуре и функционировании программы. Необходи мость данного документа также определяется на этапе разработки и утверж дения технического задания.
Ведомость эксплуатационных документов (код вида документа - 20) должна содержать перечень эксплуатационных документов на программу, к которым относятся документы с кодами: 30, 31, 32, 33, 34, 35, 46. Необходи мость этого документа также определяется на этапе разработки и утвержде ния технического задания.
Формуляр (код вида документа - 30) должен содержать основные харак теристики программного обеспечения, комплектность и сведения об эксплу атации программы.
Описание применения (код вида документа - 31) должно содержать све дения о назначении программного обеспечения, области применения, приме няемых методах, классе решаемых задач, ограничениях для применения, ми нимальной конфигурации технических средств.
Руководство системного программиста (код вида документа - 32) должно содержать сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения.
Руководство программиста (код вида документа - 33) должно содер жать сведения для эксплуатации программного обеспечения.
Руководство оператора (код вида документа - 34) должно содержать сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программного обеспечения.
Описание языка (код вида документа - 35) должно содержать описание синтаксиса и семантики языка.
Руководство по техническому обслуживанию (код вида документа - 46) должно содержать сведения для применения тестовых и диагностических программ при обслуживании технических средств.
Программа и методика испытаний (код вида документа - 51) должны содержать требования, подлежащие проверке при испытании программного обеспечения, а также порядок и методы их контроля.
Пояснительная записка (код вида документа -81) должна содержать ин формацию о структуре и конкретных компонентах программного обеспече ния, в том числе схемы алгоритмов, их общее описание, а также обоснование принятых технических и технико-экономических решений. Составляется на стадии эскизного и технического проекта.
Прочие документы (коды вида документа - 90-99) могут составляться на любых стадиях разработки, т. е. на стадиях эскизного, технического и ра бочего проектов.
Допускается объединять отдельные виды эксплуатационных докумен тов, кроме формуляра и ведомости. Необходимость объединения указывает ся в техническом задании, а имя берут у одного из объединяемых документов. Например, в настоящее время часто используется эксплуатационный до кумент, в который отчасти входит руководство системного программиста, программиста и оператора. Он называется «Руководство пользователя»
Виды моделей программного средства.41
Виды программного обеспечения компьютера
В соответствии с принципом программного управления любой компьютер можно рассматривать как совокупность аппаратной (или технической) и программной частей.
К настоящему моменту выделяют три вида программных продуктов:
1. системное, или общее, ПО;
2. пакеты прикладных программ (ППП);
3. инструментарий технологии программирования.
Системное программное обеспечение
Это совокупность программ для обеспечения работы компьютера и сетей ЭВМ. Часть этих программных средств изучается в лабораторном практикуме по информатике.
Данный класс программного обеспечения делится на следующие виды:
1. базовое ПО, содержащее операционные системы (ОС) и операционные оболочки;
2. сервисное ПО, или утилиты. Содержит программы диагностики работоспособности компьютера, антивирусные программы, программы обслуживания дисков, программы архивирования данных, программы обслуживания сетей.
Операционные системы используются для управления выполнением пользовательских программ, планирования и управления вычислительными и другими ресурсами ЭВМ. Это комплекс программ и данных, предназначенных для увеличения пропускной способности ЭВМ, расширения сферы ее применения, автоматизации подготовки прикладных программ к выполнению. ОС являются обязательной составляющей ПО любого компьютера, без чего он превращается в груду металла, пластика и электроники.
Наиболее популярными ОС для компьютеров класса IBM PC являются ОС семейства Windows'xx и MS DOS. Причем эти ОС не являются взаимоисключающими: они взаимодействуют в процессе функционирования компьютера и MS DOS, как правило, встроена в ОС Windows'xx. Сетевая ОС не имеет фундаментальных отличий от ОС автономного компьютера. Ее отличительной чертой являются развитые средства защиты от несанкционированного доступа, применяющие, в частности, идеи криптографического кодирования, рассмотренные ранее.
Операционные оболочки - это специальные программы, предназначенные для облегчения общения пользователя с командами ОС. Имеют текстовый и графический варианты интерфейса конечного пользователя. Примерами являются Norton Commander (NC) для ОС MS DOS, Far для ОС Windows'xx. В настоящий момент, когда операционные системы облагают высокоразвитым графическим интерфейсом (иконки Windows и т.п.) и имеют встроенные очень удобные средства для выполнения системных операций, наличие операционных оболочек скорее дань традиции, чем необходимость.
Пакеты прикладных программ
Это комплекс взаимосвязанных программ для решения задач определенного класса. Выделяются следующие виды ППП:
1. проблемно-ориентированные. Используются для тех проблемных областей, в которых возможна типизация функций управления, структур данных и алгоритмов обработки. Например, это ППП автоматизации бухучета, финансовой деятельности, управления персоналом и т.д.;
Проблемно-ориентированные пакеты
Используются в тех предметных областях, для которых возможна типизация функций управления, структур данных и алгоритмов обработки. Типичным примером является серия программ 1С:, позволяющая автоматизировать решение задач управления предприятием, например, 1С:Бухгалтерия, 1С: Предприятие, 1С: Кадры и т.д. К пакетам этого класса относятся и программы, реализующие дистанционное обучение, например пакет SunRav_BookOffice для создания и работы с электронным учебником, с помощью которого был разработан данный электронный учебник.
2. автоматизации проектирования (или САПР). Используются в работе конструкторов и технологов, связанных с разработкой чертежей, схем, диаграмм;
Инструментарий технологии программирования
Это совокупность программ, обеспечивающих технологию разработки, отладки и внедрения программных продуктов.
Инструментарий технологии программирования делится на два больших класса инструментальных средств: для создания отдельных приложений (программ) и для создания информационных систем и технологий.
Средства для создания отдельных приложений включают локальные средства (языки программирования, системы программирования, инструментальные среды пользователя) и интегрированные среды разработки программ, основное назначение которых - повышение производительности труда программистов за счет автоматизации создания кодов программ, обеспечивающих интерфейс пользователя графического типа, а также автоматизации разработки запросов и отчетов (например, Delphi).
В свою очередь языки программирования делятся на следующие виды:
1. операторные. Используются для кодирования алгоритмов, а потому также называются алгоритмическими. Имеют в составе:
· машинно-зависимые (ассемблер). Применяются для написания программ, явно использующих специфику конкретной аппаратуры. Каждый компьютер имеет такую систему программирования, которая изготавливается и поставляется фирмой-изготовителем вместе с компьютером;
· машинно-ориентированные (язык С). Объединяет идеи ассемблера и алгоритмического языка. Программы компактны и работают очень быстро.
· универсальные (Турбо-Паскаль, Бэйсик). Приближены максимально, насколько это возможно, к естественному английскому языку: название каждой команды - английское слово;
2. функциональные. Применяются, как правило, для машинного моделирования той или иной проблематики. Имеют в составе:
· проблемно-ориентированные (GPSS). Моделируют систему с помощью последовательности событий. Применяются, в частности, при проектировании вычислительных комплексов;
· объектно-ориентированные (Форт). Имеют встроенные средства для моделирования новых объектов программирования;
· логико-ориентированные (Prolog). Отдельно описываются правила предметной области, по которым затем выводятся новые факты.
Системы программирования включают:
1. интегрированную среду разработчика программы, состоящую, в частности, из текстового редактора, позволяющего создавать и корректировать исходные тексты программ, средств поддержки интерфейса программиста с системными средствами для выполнения различных сервисных функций (например, сохранения или открытия файла);
2. транслятор - программу, переводящую исходный текст во внутреннее представление компьютера;
3. отладчик - программу для трассировки и анализа выполнения прикладных программ. Позволяет отслеживать выполнение программы в пооператорном режиме, идентифицировать место и вид ошибок в программе, наблюдают за изменением значений переменных, выражений и т.д.;
4. компоновщик - программа для подготовки прикладной программы к работе в конкретных адресах основной памяти компьютера;
5. справочные системы.
Инструментальная среда пользователя - это специальные программные средства, встроенные в ППП:
1. библиотеки функций, процедур, объектов и методов обработки;
2. макрокоманды;
3. программные модули-вставки;
4. конструкторы экранных форм и отчетов;
5. языки запросов высокого уровня.
Даталогическая модель структуры базы данных ПО63
Датологическое проектирование – организация данных, выделенных на предыдущем этапе проектирования в форму, принятую в выбранной СУБД.
Исходные данные для даталогического проектирования
Любая СУБД оперирует с допустимыми для нее логическими единицами данных, а также допускает использование определенных правил композиции логических структур более высокого уровня из составляющих информационных единиц более низкого уровня. Кроме того, многие СУБД накладывают количественные и иные ограничения на структуру базы данных. Поэтому прежде чем приступить к построению даталогической модели, необходимо детально изучить особенности СУБД, определить факторы, влияющие на выбор проектного решения, ознакомиться с существующими методиками проектирования, а также провести анализ имеющихся средств автоматизации проектирования, возможности и целесообразности их использования.
Хотя даталогическое проектирование является проектированием логической структуры базы данных, на него оказывают влияние возможности физической организации данных, предоставляемые конкретной СУБД. Поэтому знание особенностей физической организации данных является полезным при проектировании логической структуры.
Логическая структура базы данных, а также сама заполненная данными база данных являются отображением реальной предметной области. Поэтому на выбор проектных решений самое непосредственное влияние оказывает специфика отображаемой предметной области, отраженная в инфологической модели.
Результат даталогического проектирования
Конечным результатом даталогического проектирования является' описание логической структуры базы данных на ЯОД. Однако если проектирование выполняется «вручную», то для большей наглядности сначала строится схематическое графическое изображение структуры базы данных. При этом должно быть обеспечено однозначное соответствие между конструкциями языка описания данных и графическими обозначениями информационных единиц и связей между ними. Графическое представление используется и при автоматизированном проектировании структуры базы данных как интерфейсное средство общения с проектировщиком, и при документировании проекта.
Спроектировать логическую структуру базы данных означает определить все информационные единицы и связи между ними, задать их имена; если для информационных единиц возможно использование разных типов, то необходимо определить их тип. Следует также задать некоторые количественные характеристики, например длину поля.
Диаграмма классов UML18
Диаграммы классов используются при моделировании ПС наиболее часто. Они являются одной из форм статического описания системы с точки зрения ее проектирования, показывая ее структуру. Диаграмма классов не отображает динамическое поведение объектов изображенных на ней классов. На диаграммах классов показываются классы, интерфейсы и отношения между ними.
Класс – это основной строительный блок ПС. Это понятие присутствует и в ОО языках программирования, то есть между классами UML и программными классами есть соответствие, являющееся основой для автоматической генерации программных кодов или для выполнения реинжиниринга. Каждый класс имеет название, атрибуты и операции. Класс на диаграмме показывается в виде прямоугольника, разделенного на 3 области. В верхней содержится название класса, в средней – описание атрибутов (свойств), в нижней – названия операций – услуг, предоставляемых объектами этого класса.
Стереотипы классов
При создании диаграмм классов часто пользуются понятием «стереотип». Стереотип класса – это элемент расширения словаря UML, который обозначает отличительные особенности в использовании класса. Стереотип имеет название, которое задается в виде текстовой строки. При изображении класса на диаграмме стереотип показывается в верхней части класса в двойных угловых скобках. Есть четыре стандартных стереотипа классов, для которых предусмотрены специальные графические изображения (см. рис.5).
Стереотип используется для обозначения классов-сущностей (классов данных), стреотип описывает пограничные классы, которые являются посредниками между ПС и внешними по отношению к ней сущностями – актерами, обозначаемыми стереотипом <>. Наконец, стереотип описывает классы и объекты, которые управляют взаимодействиями. Применение стереотипов позволяет, в частности, изменить вид диаграмм классов.
Жизненный цикл программного продукта50
Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл — процесс построения и развития ПО.
Идеология и цель разработки программного обеспечения54
Идеология разработки ПО - система взглядов и идей, в которых раскрывается концепция и глобальная цель, ориентированная на перспективу будущего
Функция идеологии состоит не в том, чтобы предложить нам способ ускользнуть от действительности, а в том, чтобы представить саму действительность как укрытие от некой травматической, реальной сущности.
Разработка Интернет-магазина
Улучшение качества сервиса предоставления товаров и услуг с помощью компьютера через Интернет.
Разработка Антивируса
Защита компьютеров от вирусов, путем сравнения их с базой данных вредоносных кодов.
Разработка информационного обеспечения системы по выдачи напитков (система вендинга)
Автоматизация продажи, доступность, сервис за счет независимости от человеческого фактора
Инкапсуляция3
Инкапсуляция — это свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе и скрыть детали реализации от пользователя. механизм языка программирования, ограничивающий доступ к составляющим объект компонентам (методам и свойствам), делает их приватными, то есть доступными только внутри объекта.
Инструменты разработки ПО48
В процессе разработки программных средств в той или иной мере используется компьютерная поддержка процессов разработки ПС. Это достигается путем представления хотя бы некоторых программных документов ПС (прежде всего, программ) на компьютерных носителях данных (например, дискетах) и предоставлению в распоряжение разработчика ПС специальных ПС или включенных в состав компьютера специальных устройств, созданных для какой-либо обработки таких документов. В качестве такого специального ПС можно указать компилятор с какого-либо языка программирования. Компилятор избавляет разработчика ПС от необходимости писать программы на языке компьютера, который для разработчика ПС был бы крайне неудобен, - вместо этого он составляет программы на удобном ему языке программирования, которые соответствующий компилятор автоматически переводит на язык компьютера. В качестве специального устройства, поддерживающего процесс разработки ПС, может служит эмулятор какого-либо языка. Эмулятор позволяет выполнять (интерпретировать) программы на языке, отличном от языка компьютера, поддерживающего разработку ПС, например на языке компьютера, для которого эта программа предназначена.
ПС, предназначенное для поддержки разработки других ПС, будем называть программным инструментом разработки ПС, а устройство компьютера, специально предназначенное для поддержки разработки ПС, будем называть аппаратным инструментом разработки ПС.
Инструменты разработки ПС могут использоваться в течении всего жизненного цикла ПС для работы с разными программными документами. Так текстовый редактор может использоваться для разработки практически любого программного документа. С точки зрения функций, которые инструменты выполняют при разработке ПС, их можно разбить на следующие четыре группы: ·
редакторы,·
анализаторы,·
преобразователи,·
инструменты, поддерживающие процесс выполнения программ.
Редакторы поддерживают конструирование (формирование) тех или иных программных документов на различных этапах жизненного цикла. Как уже упоминалось, для этого можно использовать один какой-нибудь универсальный текстовый редактор. Однако, более сильную поддержку могут обеспечить специализированные редакторы: для каждого вида документов - свой редактор. В частности, на ранних этапах разработки в документах могут широко использоваться графические средства описания (диаграммы, схемы и т.п.). В таких случаях весьма полезными могут быть графические редакторы. На этапе программирования (кодирования) вместо текстового редактора может оказаться более удобным синтаксически управляемый редактор, ориентированный на используемый язык программирования.
Анализаторы производят либо статическую обработку документов, осуществляя различные виды их контроля, выявление определенных их свойств и накопление статистических данных (например, проверку соответствия документов указанным стандартам), либо динамический анализ программ (например, с целью выявление распределения времени работы программы по программным модулям).
Преобразователи позволяют автоматически приводить документы к другой форме представления (например, форматеры) или переводить документ одного вида к документу другого вида (например, конверторы или компиляторы), синтезировать какой-либо документ из отдельных частей и т.п.
Инструменты, поддерживающие процесс выполнения программ, позволяют выполнять на компьютере описания процессов или отдельных их частей, представленных в виде, отличном от машинного кода, или машинный код с дополнительными возможностями его интерпретации. Примером такого инструмента является эмулятор кода другого компьютера. К этой группе инструментов следует отнести и различные отладчики. По-существу, каждая система программирования содержит программную подсистему периода выполнения, которая выполняет наиболее типичные для языка программирования программные фрагменты и обеспечивает стандартную реакцию на возникающие при выполнении программ исключительные ситуации (такую подсистему мы будем называть исполнительной поддержкой), - также можно рассматривать как инструмент данной группы.
Итерационные модели создания ПО11
Итеративная разработка (англ. iteration — повторение) — выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование — Реализация — Проверка — Оценка (англ. plan-do-check-act cycle).
В ходе разработки всегда выявляются дополнительные требования или изменяются выявленные ранее. Также появляются новые ограничения, связанные с принятыми техническими решениями. В наиболее полной мере их удается учесть именно в итерационной разработке, поскольку именно при таком подходе руководство проекта в полной мере готово к изменениям. Итеративный подход сейчас является наиболее распространенным из-за своих очевидных преимуществ и различные его вариации используеются в компании ДПГруп.
Комплексная отладка и тестирование программного средства.38
Отладка П.О. - это деятельность, направленная на обнаружение и ис-правление ошибок в П.О. с использованием процессов выполнения его про-грамм. Тестирование П.О. - это процесс выполнения его программ на некото-ром наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Указанный набор данных назы-вается тестовым или просто тестом. Таким образом, отладку можно пред-ставить в виде многократного повторения трех процессов: тестирования, в результате которого может быть констатировано наличие в П.О. ошибки, по-иска места ошибки в программах и документации П.О. и редактирования про-грамм и документации с целью устранения обнаруженной ошибки. Другими словами:
Отладка = Тестирование + Поиск ошибок + Редактирование
В зарубежной литературе отладку часто понимают только как процесс поиска и исправления ошибок (без тестирования), факт наличия которых устанавливается при тестировании. Иногда тестирование и отладку считают синонимами. В нашей стране в понятие отладки обычно включают и тестирование, поэтому мы будем следовать сложившейся традиции.
Тестирование – процесс многократного повторения программы с це-лью обнаружения ошибок. Тестирование – составная часть отладки.
Отладка имеет место тогда, когда программа со всей очевидностью работает неправильно. Поэтому отладка начинается всегда в предвидении отказа программы. Если же оказывается, что программа работает верно, то она тестируется. Часто случается так, что после прогона тестов программа вновь подвергается отладке. Таким образом, тестирование устанавливает факт наличия ошибки, а отладка выявляет ее причину.
Основная цель выделения отладки и тестирования как отдельных эта-пов создания программы заключается в том, чтобы обратить внимание обяза-тельности обеих стадий и на необходимость специального планирования временных затрат по каждой из них в отдельности.
Нельзя гарантировать, что тестированием можно установить наличие каждой имеющейся в П.О. ошибки. Поэтому возникает две задачи. Первая за-дача: подготовить такой набор тестов и применить к ним П.О., чтобы обнару-жить в нем по возможности большее число ошибок. Однако чем дольше про-должается процесс тестирования (и отладки в целом), тем большей становит-ся стоимость П.О.. Отсюда вторая задача: определить момент окончания от-ладки П.О. (или отдельной его компоненты). Признаком возможности оконча-ния отладки является полнота охвата пропущенными через П.О. тестами (т.е. тестами, к которым применено П.О.) множества различных ситуаций, возни-кающих при выполнении программ П.О., и относительно редкое проявление ошибок в П.О. на последнем отрезке процесса тестирования. Последнее опре-деляется в соответствии с требуемой степенью надежности П.О., указанной в спецификации его качества.
Заповеди, предложенные Майерсом, по тестированию П.О..
Заповедь 1. Считайте тестирование ключевой задачей разработки П.О., поручайте его самым квалифицированным и одаренным программистам; нежелательно тестировать свою собственную программу.
Заповедь 2. Хорош тот тест, для которого высока вероятность обна-ружить ошибку, а не тот, который демонстрирует правильную работу про-граммы.
Заповедь 3. Готовьте тесты как для правильных, так и для неправиль-ных данных.
Заповедь 4. Документируйте пропуск тестов через компьютер; деталь-но изучайте результаты каждого теста; избегайте тестов, пропуск которых нельзя повторить.
Заповедь 5. Каждый модуль подключайте к программе только один раз; никогда не изменяйте программу, чтобы облегчить ее тестирование.
Заповедь 6. Пропускайте заново все тесты, связанные с проверкой ра-боты какой-либо программы П.О. или ее взаимодействия с другими програм-мами, если в нее были внесены изменения (например, в результате устране-ния ошибки).
Существуют следующие методы тестирования П.О.:
1) Статическое тестирование – ручная проверка программы за сто-лом.
2) Детерминированное тестирование – при различных комбинациях исходных данных.
3) Стохастическое – исходные данные выбираются произвольно, на выходе определяется качественное совпадение результатов или примерная оценка.
Имеется два подхода к тестированию:
1) Структурное тестирование – метод «белого ящика», тестируется логика программы, внутренняя структура программы.
2) Функциональное тестирование – метод «черного ящика»- тести-руется спецификация, т.е. вход/выход без учета знаний о ее структуре.
В нашей стране различаются два основных вида отладки (включая тестирование): автономную и комплексную отладку П.О..
Автономная отладка П.О. означает последовательное раздельное тес-тирование различных частей программ, входящих в П.О., с поиском и исправ-лением в них фиксируемых при тестировании ошибок. Она фактически включает отладку каждого программного модуля и отладку сопряжения мо-дулей.
Комплексная отладка означает тестирование П.О. в целом с поиском и исправлением фиксируемых при тестировании ошибок во всех документах (включая тексты программ П.О.), относящихся к П.О. в целом. К таким доку-ментам относятся определение требований к П.О., спецификация качества П.О., функциональная спецификация П.О., описание архитектуры П.О. и тексты про-грамм П.О.
Методы разработки программного обеспечения65
Экстремальное программирование - пожалуй, наиболее известная из гибких методологий. Состоит из 12 основных принципов: игра в планирование, переработки кода (refactoring), короткие релизы, метафоры, простой дизайн, разработка «тестами вперед», коллективное владение кодом, парное программирование, 40-часовая рабочая неделя, постоянное присутствие заказчика и стандарты кода. При использовании XP тщательное планирование разработки ПО заменяется на постоянной присутствие заказчика, готового ответить на любые вопросы разработчиков и постоянную переработку (рефакторинг) кода. Низкая формализация разработки обычно не идет дальше хорошего комментирования кода, что позволяет сократить большое количество времени разработки, а следовательно, снизить общую стоимость разработки. При этом существенное внимание уделяется тестированию. Зачастую для каждого модуля системы сначала пишется тест, который продолжает выполняться на протяжении всей разработки после любого изменения кода. Впрочем, не все принципы являются строго обязательными. Например 40-часовая рабочая неделя и парное программирование носят второстепенный характер.
Crystal Clear - методология, позволяющая менять степень формализации процесса разработки в зависимости от критичности задач и количества участников разработки. Основные особенности: итеративная инкрементная разработка, автоматическое регрессионное тестирование, пользователи привлекаются к активному участию в проекте, состав документации определяется участниками проекта, как правило, используются средства контроля версий кода. Ориентирована на поддержание естественных привычек разработчиков. Считается, что если в организации не используется какая-то определенная методология, то достаточно квалифицированный коллектив рано или поздно сам естественным образом придёт к этой Crystal Clear.
Feature Driven Development (FDD) - функционально-ориентированная разработка. Разработка состоит из 5 основных этапов: разработка общей модели, составление списка необходимых функций системы, планирование работы над каждой функцией, проектирование функций, конструирование функций. Работа над проектом происходит итеративно, частый выпуск версий, каждая из которых реализует определенный набор функций.
SCRUM - методология, предназначенная для небольших команд (до 10 человек). Весь проект делится на итерации (спринты) продолжительностью 30 дней каждый. Выбирается список функций системы, которые планируется реализовать в течении следующего спринта. Самые важные условия - неизменность выбранных функций во время выполнения одной итерации и строгое соблюдение сроков выпуска очередного релиза, даже если к его выпуску не удастся реализовать весь запланированный функционал. Руководитель разработки проводит ежедневные 20 минутные совещания, которые так и называют - scrum, результатом которых является определение какие функции системы были реализованы за предыдущий день, с какими сложностями столкнулись и что планируется сделать за следующий день. Такие совещания позволяют постоянно отслеживать ход проекта, быстро выявлять возникшие проблемы и оперативно на них реагировать.
Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software. В основе методологии лежат 6 основных принципов:
Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.
Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.
Ранняя идентификация и непрерывное устранение возможных рисков.
Концентрация на выполнении требований заказчиков к исполняемой программе.
Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.
Постоянное обеспечение качества на всех этапах разработки проекта.
Использование методологии RUP направлено на итеративную модель разработки. Полных жизненный цикл программы состоит из 4 фаз:
Inception (начало)
Elaboration (проектирование)
Construction (построение)
Transition (внедрение)
Особенность методологии состоит в том, что степень формализации может меняться в зависимости от потребностей проекта.
Методы разработки структуры программ.39
В качестве модульной структуры программы принято использовать древовидную структуру, включая деревья со сросшимися ветвями. В узлах такого дерева размещаются программные модули, а направленные дуги (стрелки) показывают статическую подчиненность модулей, т.е. каждая дуга показывает, что в тексте модуля, из которого она исходит, имеется ссылка на модуль, в который она входит. Другими словами, каждый модуль может обращаться к подчиненным ему модулям, т.е. выражается через эти модули. При этом модульная структура программы, в конечном счете, должна включать и совокупность спецификаций модулей, образующих эту программу. Спецификация программного модуля содержит, во-первых, синтаксическую спецификацию его входов, позволяющую построить на используемом языке программирования синтаксически правильное обращение к нему (к любому его входу), и, во-вторых, функциональную спецификацию модуля (описание семантики функций, выполняемых этим модулем по каждому из его входов). Функциональная спецификация модуля строится так же, как и функциональная спецификация ПС. В процессе разработки программы ее модульная структура может по-разному формироваться и использоваться для определения порядка программирования и отладки модулей, указанных в этой структуре. Поэтому можно говорить о разных методах разработки структуры программы. Обычно в литературе обсуждаются два метода [7.1, 7.7]: метод восходящей разработки и метод нисходящей разработки. Метод восходящей разработки заключается в следующем. Сначала строится модульная структура программы в виде дерева. Затемпоочередно программируются модули программы, начиная с модулей самого нижнего уровня (листья дерева модульной структуры программы), в таком порядке, чтобы для каждого программируемого модуля были уже запрограммированы все модули, к которым он может обращаться. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в принципе в таком же (восходящем) порядке, в каком велось их программирование. На первый взгляд такой порядок разработки программы кажется вполне естественным: каждый модуль при программировании выражается через уже запрограммированные непосредственно подчиненные модули, а при тестировании использует уже отлаженные модули. Однако, современная технология не рекомендует такой порядок разработки программы. Во-первых, для программирования какого-либо модуля совсем не требуется текстов используемых им модулей - для этого достаточно, чтобы каждый используемый модуль был лишь специфицирован (в объеме, позволяющем построить правильное обращение к нему), а для тестирования его возможно (и даже, как мы покажем ниже, полезно) используемые модули заменять их имитаторами (заглушками). Во-вторых, каждая программа в какой-то степени подчиняется некоторым внутренним для нее, но глобальным для ее модулей соображениям (принципам реализации, предположениям, структурам данных и т.п.), что определяет ее концептуальную целостность и формируется в процессе ее разработки. При восходящей разработке эта глобальная информация для модулей нижних уровней еще не ясна в полном объеме, поэтому очень часто приходится их перепрограммировать, когда при программировании других модулей производится существенное уточнение этой глобальной информации (например, изменяется глобальная структура данных). В-третьих, при восходящем тестировании для каждого модуля (кроме головного) приходится создавать ведущую программу (модуль), которая должна подготовить для тестируемого модуля необходимое состояние информационной среды и произвести требуемое обращение к нему. Это приводит к большому объему "отладочного" программирования и в то же время не дает никакой гарантии, что тестирование модулей производилось именно в тех условиях, в которых они будут выполняться в рабочей программе. Метод нисходящей разработки заключается в следующем. Как и в предыдущем методе сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модуля самого верхнего уровня (головного), переходя к программированию какого-либо другого модуля только в том случае, если уже запрограммирован модуль, который к нему обращается. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в таком же (нисходящем) порядке. При таком порядке разработки программы вся необходимая глобальная информация формируется своевременно, т.е. ликвидируется весьма неприятный источник просчетов при программировании модулей. Существенно облегчается и тестирование модулей, производимое при нисходящем тестировании программы. Первым тестируется головной модуль программы, который представляет всю тестируемую программу и поэтому тестируется при "естественном" состоянии информационной среды, при котором начинает выполняться эта программа. При этом все модули, к которым может обращаться головной, заменяются на их имитаторы (так называемые заглушки [7.5]). Каждый имитатор модуля представляется весьма простым программным фрагментом, сигнализирующим, в основном, о самом факте обращения к имитируемому модулю с необходимой для правильной работы программы обработкой значений его входных параметров (иногда с их распечаткой) и с выдачей, если это необходимо, заранее запасенного подходящего результата. После завершения тестирования и отладки головного и любого последующего модуля производится переход к тестированию одного из модулей, которые в данный момент представлены имитаторами, если таковые имеются. Для этого имитатор выбранного для тестирования модуля заменяется на сам этот модуль и добавляются имитаторы тех модулей, к которым может обращаться выбранный для тестирования модуль. При этом каждый такой модуль будет тестироваться при "естественных" состояниях информационной среды, возникающих к моменту обращения к этому модулю при выполнении тестируемой программы. Таким образом большой объем "отладочного" программирования заменяется программированием достаточно простых имитаторов используемых в программе модулей. Кроме того, имитаторы удобно использовать для подыгрывания процессу подбора тестов путем задания нужных результатов, выдаваемых имитаторами. Некоторым недостатком нисходящей разработки, приводящим к определенным затруднениям при ее применении, является необходимость абстрагироваться от базовых возможностей используемого языка программирования, выдумывая абстрактные операции, которые позже нужно будет реализовать с помощью выделенных в программе модулей. Однако способность к таким абстракциям представляется необходимым условием разработки больших программных средств, поэтому ее нужно развивать. В рассмотренных методах восходящей и нисходящей разработок (которые мы будем называть классическими) модульная древовидная структуру программы должна разрабатываться до начала программирования модулей. Однако такой подход вызывает ряд возражений: представляется сомнительным, чтобы до программирования модулей можно было разработать структуру программы достаточно точно и содержательно. На самом деле это делать не обязательно: так при конструктивном и архитектурном подходах к разработке программ [7.3] модульная структура формируется в процессе программирования модулей.
Методы разработки структуры программы59
Как уже отмечалось выше, в качестве модульной структуры программы принято использовать древовидную структуру, включая деревья со сросшимися ветвями. В узлах такого дерева размещаются программные модули, а направленные дуги (стрелки) показывают статическую подчиненность модулей, т.е. каждая дуга показывает, что в тексте модуля, из которого она исходит, имеется ссылка на модуль, в который она входит. Другими словами, каждый модуль может обращаться к подчиненным ему модулям, т.е. выражается через эти модули. При этом модульная структура программы, в конечном счете, должна включать и совокупность спецификаций модулей, образующих эту программу. Спецификация программного модуля содержит, во-первых, синтаксическую спецификацию его входов, позволяющую построить на используемом языке программирования синтаксически правильное обращение к нему (к любому его входу), и, во-вторых, функциональную спецификацию модуля (описание семантики функций, выполняемых этим модулем по каждому из его входов). Функциональная спецификация модуля строится так же, как и функциональная спецификация ПС. В процессе разработки программы ее модульная структура может по-разному формироваться и использоваться для определения порядка программирования и отладки модулей, указанных в этой структуре. Поэтому можно говорить о разных методах разработки структуры программы. Обычно в литературе обсуждаются два метода [7.1, 7.7]: метод восходящей разработки и метод нисходящей разработки. Метод восходящей разработки заключается в следующем. Сначала строится модульная структура программы в виде дерева. Затемпоочередно программируются модули программы, начиная с модулей самого нижнего уровня (листья дерева модульной структуры программы), в таком порядке, чтобы для каждого программируемого модуля были уже запрограммированы все модули, к которым он может обращаться. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в принципе в таком же (восходящем) порядке, в каком велось их программирование. На первый взгляд такой порядок разработки программы кажется вполне естественным: каждый модуль при программировании выражается через уже запрограммированные непосредственно подчиненные модули, а при тестировании использует уже отлаженные модули. Однако, современная технология не рекомендует такой порядок разработки программы. Во-первых, для программирования какого-либо модуля совсем не требуется текстов используемых им модулей - для этого достаточно, чтобы каждый используемый модуль был лишь специфицирован (в объеме, позволяющем построить правильное обращение к нему), а для тестирования его возможно (и даже, как мы покажем ниже, полезно) используемые модули заменять их имитаторами (заглушками). Во-вторых, каждая программа в какой-то степени подчиняется некоторым внутренним для нее, но глобальным для ее модулей соображениям (принципам реализации, предположениям, структурам данных и т.п.), что определяет ее концептуальную целостность и формируется в процессе ее разработки. При восходящей разработке эта глобальная информация для модулей нижних уровней еще не ясна в полном объеме, поэтому очень часто приходится их перепрограммировать, когда при программировании других модулей производится существенное уточнение этой глобальной информации (например, изменяется глобальная структура данных). В-третьих, при восходящем тестировании для каждого модуля (кроме головного) приходится создавать ведущую программу (модуль), которая должна подготовить для тестируемого модуля необходимое состояние информационной среды и произвести требуемое обращение к нему. Это приводит к большому объему "отладочного" программирования и в то же время не дает никакой гарантии, что тестирование модулей производилось именно в тех условиях, в которых они будут выполняться в рабочей программе. Метод нисходящей разработки заключается в следующем. Как и в предыдущем методе сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модуля самого верхнего уровня (головного), переходя к программированию какого-либо другого модуля только в том случае, если уже запрограммирован модуль, который к нему обращается. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в таком же (нисходящем) порядке. При таком порядке разработки программы вся необходимая глобальная информация формируется своевременно, т.е. ликвидируется весьма неприятный источник просчетов при программировании модулей. Существенно облегчается и тестирование модулей, производимое при нисходящем тестировании программы. Первым тестируется головной модуль программы, который представляет всю тестируемую программу и поэтому тестируется при "естественном" состоянии информационной среды, при котором начинает выполняться эта программа. При этом все модули, к которым может обращаться головной, заменяются на их имитаторы (так называемые заглушки [7.5]). Каждый имитатор модуля представляется весьма простым программным фрагментом, сигнализирующим, в основном, о самом факте обращения к имитируемому модулю с необходимой для правильной работы программы обработкой значений его входных параметров (иногда с их распечаткой) и с выдачей, если это необходимо, заранее запасенного подходящего результата. После завершения тестирования и отладки головного и любого последующего модуля производится переход к тестированию одного из модулей, которые в данный момент представлены имитаторами, если таковые имеются. Для этого имитатор выбранного для тестирования модуля заменяется на сам этот модуль и добавляются имитаторы тех модулей, к которым может обращаться выбранный для тестирования модуль. При этом каждый такой модуль будет тестироваться при "естественных" состояниях информационной среды, возникающих к моменту обращения к этому модулю при выполнении тестируемой программы. Таким образом большой объем "отладочного" программирования заменяется программированием достаточно простых имитаторов используемых в программе модулей. Кроме того, имитаторы удобно использовать для подыгрывания процессу подбора тестов путем задания нужных результатов, выдаваемых имитаторами. Некоторым недостатком нисходящей разработки, приводящим к определенным затруднениям при ее применении, является необходимость абстрагироваться от базовых возможностей используемого языка программирования, выдумывая абстрактные операции, которые позже нужно будет реализовать с помощью выделенных в программе модулей. Однако способность к таким абстракциям представляется необходимым условием разработки больших программных средств, поэтому ее нужно развивать. В рассмотренных методах восходящей и нисходящей разработок (которые мы будем называть классическими) модульная древовидная структуру программы должна разрабатываться до начала программирования модулей. Однако такой подход вызывает ряд возражений: представляется сомнительным, чтобы до программирования модулей можно было разработать структуру программы достаточно точно и содержательно. На самом деле это делать не обязательно: так при конструктивном и архитектурном подходах к разработке программ [7.3] модульная структура формируется в процессе программирования модулей.
Модели процесса создания ПО10
Процесс разработки программного обеспечения (англ. software development process, software process) — структура, согласно которой построена разработка программного обеспечения (ПО).
Существует несколько моделей такого процесса (методологий разработки ПО), каждая из которых описывает свой подход, в виде задач и/или деятельности, которые имеют место в ходе процесса.
Выделяют следующие основные модели процесса или методологии разработки ПО:
Каскадная разработка или модель водопада (англ. waterfall model) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки
Итеративная разработка (англ. iteration — повторение) — выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование — Реализация — Проверка — Оценка
Гибкая методология разработки (англ. Agile software development).
Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся одну-две недели.
Моделирование программного обеспечения в UML56
UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но в средствах выполнения UML-моделей как интерпретируемого кода возможна кодогенерация.
Диаграммы
В UML используются следующие виды диаграмм (для исключения неоднозначности приведены также обозначения на английском языке):
|
Structure Diagrams: Class diagram Component diagram Composite structure diagram Collaboration (UML2.0) Deployment diagram Object diagram Package diagram Profile diagram (UML2.2) Behavior Diagrams: Activity diagram State Machine diagram Use case diagram Interaction Diagrams: Communication diagram (UML2.0) / Collaboration (UML1.x) Interaction overview diagram (UML2.0) Sequence diagram Timing diagram (UML2.0) |
Структурные диаграммы: Диаграмма классов Диаграмма компонентов Композитной/составной структуры Диаграмма кооперации (UML2.0) Диаграмма развёртывания Диаграмма объектов Диаграмма пакетов Диаграмма профилей (UML2.2) Диаграммы поведения: Диаграмма деятельности Диаграмма состояний Диаграмма прецедентов Диаграммы взаимодействия: Диаграмма коммуникации (UML2.0) / Диаграмма кооперации (UML1.x) Диаграмма обзора взаимодействия (UML2.0) Диаграмма последовательности Диаграмма синхронизации (UML2.0) |
Диаграмма классов (Static Structure diagram) — статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами.
Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:
концептуальная точка зрения — диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;
точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;
точка зрения реализации — диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).
Диаграмма компонентов (Component diagram) — статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонент могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.
Диаграмма композитной/составной структуры (Composite structure diagram) — статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса.
Подвидом диаграмм композитной структуры являются диаграммы кооперации (Collaboration diagram, введены в UML 2.0), которые показывают роли и взаимодействие классов в рамках кооперации. Кооперации удобны при моделировании шаблонов проектирования.
Диаграммы композитной структуры могут использоваться совместно с диаграммами классов.
Диаграмма развёртывания (Deployment diagram) — служит для моделирования работающих узлов (аппаратных средств, англ. node) иартефактов, развёрнутых на них. В UML 2 на узлах разворачиваются артефакты (англ. artifact), в то время как в UML 1 на узлах разворачивались компоненты. Между артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость манифестации.
Диаграмма объектов (Object diagram) — демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.
Диаграмма пакетов (Package diagram) — структурная диаграмма, основным содержанием которой являются пакеты и отношения между ними. Жёсткого разделения между разными структурными диаграммами не проводится, поэтому данное название предлагается исключительно для удобства и не имеет семантического значения (пакеты и диаграммы пакетов могут присутствовать на других структурных диаграммах). Диаграммы пакетов служат, в первую очередь, для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы.
Диаграмма деятельности (Activity diagram) — диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (англ. activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий (англ. action), соединённых между собой потоками, которые идут от выходов одного узла к входам другого.
Диаграммы деятельности используются при моделировании бизнес-процессов, технологических процессов, последовательных и параллельных вычислений.
Аналогом диаграмм деятельности являются схемы алгоритмов по ГОСТ 19.701-90.
Диаграмма автомата (State Machine diagram, диаграмма конечного автомата, диаграмма состояний) — диаграмма, на которой представлен конечный автомат с простымисостояниями, переходами и композитными состояниями.
Конечный автомат (англ. State machine) — спецификация последовательности состояний, через которые проходит объект или взаимодействие в ответ на события своей жизни, а также ответные действия объекта на эти события. Конечный автомат прикреплён к исходному элементу (классу, кооперации или методу) и служит для определения поведения его экземпляров.
Диаграмма вариантов использования (Use case diagram) — диаграмма, на которой отражены отношения, существующие между акторами и вариантами использования.
Основная задача — представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.
Диаграммы коммуникации и последовательности
Диаграммы коммуникации и последовательности транзитивны, выражают взаимодействие, но показывают его различными способами и с достаточной степенью точности могут быть преобразованы одна в другую.
Диаграмма коммуникации (Communication diagram, в UML 1.x — диаграмма кооперации, collaboration diagram) — диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).
Диаграмма последовательности (Sequence diagram) — диаграмма, на которой изображено
упорядоченное во времени взаимодействие объектов. В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются.
Диаграмма сотрудничества — Этот тип диаграмм позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта и типы этих сообщений.
По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм.
Диаграмма обзора взаимодействия (Interaction overview diagram) — разновидность диаграммы деятельности, включающая фрагменты диаграммы последовательности и конструкции потока управления.
Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.
Диаграмма синхронизации (Timing diagram) — альтернативное представление диаграммы последовательности, явным образом показывающее изменения состояния на линии жизни с заданной шкалой времени. Может быть полезна в приложениях реального времени.
Модель системы как упрощенное представление реальности57
Моде́ль (фр. modèle, от лат. modulus — «мера, аналог, образец») — это система, исследование которой служит средством для получения информации о другой системе[1], это упрощённое представление реального устройства и/или протекающих в нём процессов, явлений.
Построение и исследование моделей, то есть моделирование, облегчает изучение имеющихся в реальном устройстве (процессе, …) свойств и закономерностей. Применяют для нужд познания (созерцания, анализа и синтеза).
Моделирование является обязательной частью исследований и разработок, неотъемлемой частью нашей жизни, поскольку сложность любого материального объекта и окружающего его мира бесконечна вследствие неисчерпаемости материи и форм её взаимодействия, — как внутри себя, так и с внешней средой.
Одни и те же устройства, процессы, явления и т. д. (далее — «системы») могут иметь много разных видов моделей. Как следствие, существует много названий моделей, большинство из которых отражает решение некоторой конкретной задачи. Ниже приведена классификация и дана характеристика наиболее общих видов моделей.
Моделирование всегда предполагает принятие допущений той или иной степени важности. При этом должны удовлетворяться следующие требования к моделям:
адекватность, то есть соответствие модели исходной реальной системе и учет, прежде всего, наиболее важных качеств, связей и характеристик. Оценить адекватность выбранной модели, особенно, например, на начальной стадии проектирования, когда вид создаваемой системы ещё неизвестен, очень сложно. В такой ситуации часто полагаются на опыт предшествующих разработок или применяют определённые методы, например, метод последовательных приближений;
точность, то есть степень совпадения полученных в процессе моделирования результатов с заранее установленными, желаемыми. Здесь важной задачей является оценка потребной точности результатов и имеющейся точности исходных данных, согласование их как между собой, так и с точностью используемой модели;
универсальность, то есть применимость модели к анализу ряда однотипных систем в одном или нескольких режимах функционирования. Это позволяет расширить область применимости модели для решения большего круга задач;
целесообразная экономичность, то есть точность получаемых результатов и общность решения задачи должны увязываться с затратами на моделирование. И удачный выбор модели, как показывает практика, — результат компромисса между отпущенными ресурсами и особенностями используемой модели;
и др.
Выбор модели и обеспечение точности моделирования считается одной из самых важных задач моделирования.
Основные виды моделей
Эвристические модели
Натурные модели
Математические модели
Промежуточные виды моделей (графические, аналоговые)
Модульное программирование.58
Программный модуль - это любой фрагмент описания процесса, оформляемый как самостоятельный программный продукт, пригодный для использования в описаниях процесса. Это означает, что каждый программный модуль программируется, компилируется и отлаживается отдельно от других модулей программы, и тем самым, физически разделен с другими модулями программы. Более того, каждый разработанный программный модуль может включаться в состав разных программ, если выполнены условия его использования, декларированные в документации по этому модулю. Таким образом, программный модуль может рассматриваться и как средство борьбы со сложностью программ, и как средство борьбы с дублированием в программировании (т.е. как средство накопления и многократного использования программистских знаний). Модульное программирование является воплощением в процессе разработки программ обоих общих методов борьбы со сложностью (см. лекцию 3, п. 3.5): и обеспечение независимости компонент системы, и использование иерархических структур. Для воплощения первого метода формулируются определенные требования, которым должен удовлетворять программный модуль, т.е. выявляются основные характеристики "хорошего" программного модуля. Для воплощения второго метода используют древовидные модульные структуры программ (включая деревья со сросшимися ветвями).
Надежность программного средства45
Альтернативой правильного ПС является надежное ПС. Надежность ПС — это его способность безотказно выполнять определенные функции при заданных условиях в течение заданного периода времени с достаточно большой вероятностью [5]. При этом под отказом в ПС понимают проявление в нем ошибки [2]. Таким образом, надежная ПС не исключает наличия в ней ошибок — важно лишь, чтобы эти ошибки при практическом применении этого ПС в заданных условиях проявлялись достаточно редко. Убедиться, что ПС обладает таким свойством можно при его испытании путем тестирования, а также при практическом применении. Таким образом, фактически мы можем разрабатывать лишь надежные, а не правильные ПС.
Разрабатываемая ПС может обладать различной степенью надежности. Как измерять эту степень? Так же как в технике, степень надежности можно характеризовать [2] вероятностью работы ПС без отказа в течении определенного периода времени. Однако в силу специфических особенностей ПС определение этой вероятности наталкивается на ряд трудностей по сравнению с решением этой задачи в технике. Позже мы вернемся к более обстоятельному обсуждению этого вопроса.
При оценке степени надежности ПС следует также учитывать последствия каждого отказа. Некоторые ошибки в ПС могут вызывать лишь некоторые неудобства при его применении, тогда как другие ошибки могут иметь катастрофические последствия, например, угрожать человеческой жизни. Поэтому для оценки надежности ПС иногда используют дополнительные показатели, учитывающие стоимость (вред) для пользователя каждого отказа.
Назначения и цели создания программного обеспечения53
Наследование5
Наследование — это свойство системы, позволяющее описать новый класс на основе уже существующего с частично или полностью заимствующейся функциональностью. Класс, от которого производится наследование, называется базовым, родительским или суперклассом. Новый класс — потомком, наследником или производным классом. механизм языка, позволяющий описать новый класс на основе уже существующего (родительского, базового) класса. Класс-потомок может добавить собственные методы и свойства, а также пользоваться родительскими методами и свойствами. Позволяет строить иерархии классов.
Обеспечение защищенности программного продукта55
Обеспечение защищенности программного продукта
1.Защита авторских прав
Свидетельство АП и форма в ПО об авторе с контактной информацией.
2.Защита информации
2.1.Способы защиты (метод защиты)
2.2.Алгоритм защиты
Конкретный алгоритм защиты информации и методы шифрования
2.3.Защита от вирусов
Ативирусное ПО
2.4.Защита от атак
Метод (алгоритм) защиты ПО от атак.
2.5.Защита от взлома
Метод защиты ПО от взлома.
Обеспечение легкости применения программного средства.34
Обеспечение от несанкционированного доступа к программным средствам и защиты от взлома защиты.37
Различают следующие виды защиты ПС от искажения информации:
защита от сбоев аппаратуры;
защита от влияния "чужой" программы;
защита от отказов "своей" программы;
защита от ошибок оператора (пользователя);
защита от несанкционированного доступа;
защита от защиты.
Защита от сбоев аппаратуры в настоящее время является не очень злободневной задачей (с учетом уровня достигнутой надежности компьютеров). Но все же полезно знать ее решение. Это обеспечивается организацией так называемых "двойных-тройных просчетов". Для этого весь процесс обработки данных, определяемый ПС, разбивается по времени на интервалы так называемыми "опорными точками". Длина этого интервала не должна превосходить половины среднего времени безотказной работы компьютера. Копия состояния изменяемой в этом процессе памяти каждой опорной точке записывается во вторичную память с некоторой контрольной суммой (числом, вычисляемым как некоторая функция от этого состояния) в том случае, когда будет считаться, что обработка данных от предыдущей опорной точки до данной (т.е. один "просчет") произведена правильно (без сбоев компьютера). Для того, чтобы это выяснить, производится два таких "просчета". После первого "просчета" вычисляется и запоминается указанная контрольная сумма, а затем восстанавливается состояние памяти для предыдущей опорной точки и делается второй "просчет". После второго "просчета" вычисляется снова указанная контрольная сумма, которая затем сравнивается с контрольной суммой первого "просчета". Если эти две контрольные суммы совпадают, второй просчет считается правильным, в противном случае контрольная сумма второго "просчета" также запоминается и производится третий "просчет" (с предварительным восстановлением состояния памяти для предыдущей опорной точки). Если контрольная сумма третьего "просчета" совпадет с контрольной суммой одного из первых двух "просчетов", то третий просчет считается правильным, в противном случае требуется инженерная проверка компьютера.
Защита от влияния "чужой" программы относится прежде всего к операционным системам или к программам, выполняющим частично их функции. Различают две разновидности этой защиты: защита от отказов, защита от злонамеренного влияния "чужой" программы.
При появлении мультипрограммного режима работы компьютера в его памяти может одновременно находится в стадии выполнения несколько программ, попеременно получающих управление в результате возникающих прерываний (так называемое квазипараллельное выполнение программ). Одна из таких программ (обычно: операционная система) занимается обработкой прерываний и управлением мультипрограммным режимом. В каждой из таких программ могут возникать отказы (проявляться ошибки), которые могут повлиять на выполнение функций другими программами. Поэтому управляющая программа (операционная система) должна обеспечить защиту себя и других программ от такого влияния. Для этого аппаратура компьютера должна реализовывать следующие возможности: защиту памяти, два режима функционирования компьютера: привилегированный и рабочий (пользовательский), два вида операций: привилегированные и ординарные, корректную реализацию прерываний и начального включения компьютера, временное прерывание.
Защита памяти означает возможность программным путем задавать для каждой программы недоступные для нее участки памяти. В привилегированном режиме могут выполняться любые операции (как ординарные, так и привилегированные), а в рабочем режиме - только ординарные. Попытка выполнить привилегированную операцию, а также обратиться к защищенной памяти в рабочем режиме вызывает соответствующее прерывание. Причем к привилегированным операциям относятся операции изменения защиты памяти и режима функционирования, а также доступа к внешней информационной среде. Начальное включение компьютера и любое прерывание должно автоматически включать привилегированный режим и отмену защиты памяти. В этом случае управляющая программа (операционная система) может полностью защитить себя от влияния других программ, если все точки передачи управления при начальном включении и прерываниях будут принадлежать этой программе, если она никакой другой программе не позволит работать в привилегированном режиме (при передаче управления любой другой программе будет включаться только рабочий режим) и если она полностью защитит свою память (содержащую, в частности, всю ее управляющую информацию, включая так называемые вектора прерываний) от других программ. Тогда никто не помешает ей выполнять любые реализованные в ней функции защиты других программ (в том числе и доступа к внешней информационной среде). Для облегчения решения этой задачи часть такой программы помещается в постоянную память, т.е. неотделима от самого компьютера. Наличие временного прерывания позволяет управляющей программе защититься от зацикливания в других программах (без такого прерывания она могла бы просто лишиться возможности управлять).
Защита от отказов "своей" программы обеспечивается надежностью этой программы, на что ориентирована вся технология программирования, обсуждаемая в настоящем курсе лекций.
Защита от ошибок пользователя (помимо ошибок входных данных, см. обеспечение устойчивости ПС) обеспечивается выдачей предупредительных сообщений о попытках изменить состояние внешней информационной среды с требованием подтверждения этих действий, а также возможностью восстановления состояния отдельных компонент внешней информационной среды. Последнее базируется на осуществлении архивирования изменений состояния внешней информационной среды.
Защита от несанкционированного доступа обеспечивается использованием секретных слов (паролей). В этом случае каждому пользователю предоставляются определенные информационные и процедурные ресурсы (услуги), для использования которых требуется предъявления ПС некоторого пароля, ранее зарегистрированного в ПС этим пользователем. Другими словами, пользователь как бы "вешает замок" на выделенные ему ресурсы, "ключ" от которого имеется только у этого пользователя. Однако, в отдельных случаях могут быть предприняты настойчивые попытки взломать такую защиту, если защищаемые ресурсы представляют для кого-то чрезвычайную ценность. Для такого случая приходится предпринимать дополнительные меры для защиты от взлома защиты.
Защита от взлома защиты связана с использованием в ПС специальных программистских приемов, затрудняющих преодоление защиты от несанкционированного доступа. Использование обычных паролей оказывается недостаточной, когда речь идет о чрезвычайно настойчивом стремлении (например, преступного характера) добиться доступа к ценной информации. Во-первых, потому, что информацию о паролях, которую использует ПС для защиты от несанкционированного доступа, "взломщик" этой защиты относительно легко может достать, если он имеет доступ к самому этому ПС. Во-вторых, используя компьютер, можно осуществлять достаточно большой перебор возможных паролей с целью найти подходящий для доступа к интересующей информации. Защититься от такого взлома можно следующим образом. Секретное слово (пароль) или просто секретное целое число X знает только владелец защищаемой информации, а для проверки прав доступа в компьютере хранится другое число Y=F(X), однозначно вычисляемое ПС при каждой попытке доступа к этой информации при предъявлении секретного слова. При этом функция F может быть хорошо известной всем пользователям ПС, однако она обладает таким свойством, что восстановление слова X по Y практически невозможно: при достаточно большой длине слова X (например, в несколько сотен знаков) для этого требуется астрономическое время. Такое число Y будем называть электронной (компьютерной) подписью владельца секретного слова X (а значит, и защищаемой информации).
Другая разновидность такой защиты связана с защитой сообщений, пересылаемых по компьютерным сетям, преднамеренных (или злонамеренных) искажений. Такое сообщения может перехватываться на "перевалочных" пунктах компьютерной сети и подменяться другим сообщением от автора перехваченного сообщения. Такая ситуация возникает прежде всего при осуществлении банковских операций с использованием компьютерной сети. Путем подмены такого сообщения, являющего распоряжением владельца банковского счета о выполнении некоторой банковской операции деньги с его счета могут быть переведены на счет "взломщика" защиты (своеобразный вид компьютерного ограбления банка). Защиту от такого взлома защиты можно осуществить следующим образом [11.4]. Наряду с функцией F, определяющей компьютерную подпись владельца секретного слова X, которую знает адресат защищаемого сообщения (если только ее владелец является клиентом этого адресата), в ПС определена другая функция Stamp, по которой отправитель сообщения должен вычислить число S=Stamp(X,R), используя секретное слово X и текст передаваемого сообщения R. Функция Stamp также считается хорошо известной всем пользователям ПС и обладает таким свойством, что по S практически невозможно ни восстановить число X, ни подобрать другое сообщение R с соответствующей компьютерной подписью. Само передаваемое сообщение (вместе со своей защитой) должно иметь вид:
R Y S ,
причем Y (компьютерная подпись) позволяет адресату установить истинность клиента, а S как бы скрепляет защищаемое сообщение Rс компьютерной подписью Y. В связи с этим будем называть число S электронной (компьютерной) печатью. В ПС определена еще одна функция Notary, по которой получатель защищаемого сообщения проверяет истинность передаваемого сообщения:
Notary(R,Y,S).
Эта позволяет однозначно установить, что сообщение R принадлежит владельцу секретного слова X.
Защита от защиты необходима в том случае, когда пользователь забыл (или потерял) свой пароль. Для такого случая должна быть предусмотрена возможность для особого пользователя (администратора ПС), отвечающего за функционирования системы защиты, производить временное снятие защиты от несанкционированного доступа для хозяина забытого пароля с целью дать ему возможность зафиксировать новый пароль.
Обеспечение эффективности программного средства.43
Эффективность ПС обеспечивается принятием подходящих решений на разных этапах его разработки, начиная с разработки его архитектуры. Особенно сильно на эффективность ПС (особенно по памяти) влияет выбор структуры и представления данных. Но и выбор алгоритмов, используемых в тех или иных программных модулях, а также особенности их реализации (включая выбор языка программирования) может существенно повлиять эффективность ПС. При этом постоянно приходится разрешать противоречие между временной эффективностью и эффективностью по памяти. Поэтому весьма важно, чтобы в спецификации качества было явно указано количественное соотношение между показателями этих примитивов качества или хотя бы заданы количественные границы для одного из этих показателей. И все же разные программные модули по-разному влияют на эффективность ПС в целом: и по вкладу в общие затраты ПС по времени и памяти, и по влиянию на разные примитивы качества (одни модули могут сильно влиять на достижение временной эффективности и практически не влиять на эффективность по памяти, а другие могут существенно влиять на общий расход памяти, не оказывая заметного влияния на время работы ПС). Более того, это влияние (прежде всего в отношении временной эффективности) заранее (до окончания реализации ПС) далеко не всегда можно правильно оценить.
С учетом сказанного, рекомендуется придерживаться следующих принципов для обеспечения эффективности ПС:
сначала нужно разработать надежное ПС, а уж потом добиваться требуемой его эффективности в соответствии со спецификацией качества этого ПС ;
для повышения эффективности ПС используйте прежде всего оптимизирующий компилятор - это может обеспечить требуемую эффективность;
если достигнутая эффективность ПС не удовлетворяет спецификации его качества, то найдите самые критические модули с точки зрения требуемой эффективности ПС (в случае временнoй эффективности для этого потребуется получить распределение по модулям времени работы ПС путем соответствующих измерений во время выполнения ПС); эти модули и попытайтесь оптимизировать в первую очередь путем их ручной переделки ;
не занимайтесь оптимизацией модуля, если этого не требуется для достижения требуемой эффективности ПС.
12.4. Обеспечение сопровождаемости.
С-документированность, информативность и понятность определяют состав и качество документации по сопровождению (см. следующую лекцию). Кроме того, относительно текстов программ (модулей) можно сделать следующие рекомендации.
используйте в тексте модуля комментарии, проясняющие и объясняющие особенности принимаемых решений; по-возможности, включайте комментарии (хотя бы в краткой форме) на самой ранней стадии разработки текста модуля ;
используйте осмысленные (мнемонические) и устойчиво различимые имена (оптимальная длина имени - 4-12 литер, цифры - в конце), не используйте сходные имена и ключевые слова ;
соблюдайте осторожность в использовании констант (уникальная константа должна иметь единственное вхождение в текст модуля: при ее объявлении или, в крайнем случае, при инициализации переменной в качестве константы );
не бойтесь использовать не обязательные скобки (скобки обходятся дешевле, чем ошибки ;
размещайте не больше одного оператора в строке; для прояснения структуры модуля используйте дополнительные пробелы (отступы) в начале каждой строки ;
избегайте трюков, т.е. таких приемов программирования, когда создаются фрагменты модуля, основной эффект которых не очевиден или скрыт (завуалирован), например, побочные эффекты функций .
Расширяемость обеспечивается созданием подходящего инсталятора.
Структурированность и модульность упрощают как понимание текстов программ, так и их модификацию.
Общие принципы разработки программных средств47
Программы различаются по назначению, выполняемым функциям, формам реализации. Однако можно полагать, что существуют некоторые общие принципы, которые следует использовать при разработке программ.
Частотный принцип
Принцип основан на выделении в алгоритмах и данных особых групп по частоте использования. Для действий, наиболее часто встречающихся при работе программ, создаются условия их быстрого выполнения. К часто используемым данным обеспечивается наиболее быстрый доступ. «Частые» операции стараются делать более короткими. Следует отметить, что лишь не более 5 % операторов программы оказывают ощутимое влияние на скорость выполнения программы. Этот факт позволяет значительную часть операторов программы кодировать без учета скорости вычислений, обращая основное внимание при этом на «красоту» и наглядность текстов.
Принцип модульности
Под модулем в данном контексте понимают функциональный элемент рассматриваемой системы, имеющий оформление, законченное и выполненное в пределах требований системы, и средства сопряжения с подобными элементами или элементами более высокого уровня данной или другой системы. Способы обособления составных частей программ в отдельные
модули могут различаться существенно. В значительной степени разделение системы на модули определяется используемым методом проектирования программ.
Принцип функциональной избирательности
Этот принцип является логическим продолжением частотного и модульного принципов и используется при проектировании программ. В программах выделяется некоторая часть важных модулей, которые постоянно должны быть в состоянии готовности для эффективной организации вычислительного процесса. Эту часть в программах называют ядром или монитором. При формировании состава монитора требуется учесть два противоречивых требования. В состав монитора, помимо чисто управляющих модулей, должны войти наиболее часто используемые модули. Количество модулей должно быть таким, чтобы объем памяти, занимаемой монитором, был не слишком большим. Программы, входящие в состав монитора, постоянно хранятся в оперативной памяти. Остальные части программ постоянно хранятся во внешних запоминающих устройствах и загружаются в оперативную память только при необходимости, перекрывая друг друга также при необходимости.
Принцип генерируемости
Основное положение этого принципа определяет такой способ исходного представления программы, который бы позволял осуществлять настройку на конкретную конфигурацию технических средств, круг решаемых проблем, условия работы пользователя.
Принцип функциональной избыточности
Этот принцип учитывает возможность проведения одной и той же работы различными средствами. Особенно важен учет этого принципа при разработке пользовательского интерфейса для выдачи одних и тех же данных разными способами вызова из-за психологических различий в восприятии информации.
Принцип «по умолчанию»
Применяется для облегчения организации связей с системой как на стадии генерации, так и при работе с уже готовыми программами. Принцип основан на хранении в системе некоторых базовых описаний структур, модулей, конфигураций оборудования и данных, определяющих условия работы с программой. Эту информацию программа использует в качестве заданной по умолчанию, если пользователь забудет или сознательно не конкретизирует ее.
Определение требований к программному средству.32
Определение требования к ПС являются исходным документом разработки ПС - заданием, выражающем в абстрактной форме потребности пользователя. Они в общих чертах определяют замысел ПС, характеризуют условия его использования. Неправильное понимание потребностей пользователя трансформируются в ошибки внешнего описания. Поэтому разработка ПС начинается с создания документа, достаточно полно характеризующего потребности пользователя и позволяющего разработчику адекватно воспринимать эти потребности.
Определение требований представляет собой смесь фрагментов на естественном языке, различных таблиц и диаграмм. Такая смесь, должна быть понятной пользователю, не знающего специальных программистских обозначений. Обычно в определении требований не содержится формализованных фрагментов, кроме случаев достаточно для этого подготовленных пользователей (например, математически) - формализация этих требований составляет содержание дальнейшей работы коллектива разработчиков.
Неправильное понимание требований заказчиком, пользователями и разработчиками связано обычно с различными взглядами на роль требуемого ПС в среде его использования [4.1]. Поэтому важной задачей при создании определения требований является установление контекста использования ПС, включающего связи между этим ПС, аппаратурой и людьми. Лучше всего этот контекст в определении требований представить в графической форме (в виде диаграмм) с добавлением описаний сущностей используемых объектов (блоков ПС, компонент аппаратуры, персонала и т.п.) и характеристики связей между ними.
Известны три способа определения требований к ПС [4.2]:
· управляемый пользователем,
· контролируемый пользователем,
· независимый от пользователя.
В управляемой пользователем разработке определения требований к ПС определяются заказчиком, представляющим организацию пользователей. Это происходит обычно в тех случаях, когда организация пользователей (заказчик) заключает договор на разработку требуемого ПС с коллективом разработчиков и требования к ПС являются частью этого договора. Роль разработчика ПС в создании этих требований сводится, в основном, в выяснении того, насколько понятны ему эти требования с соответствующей критикой рассматриваемого документа. Это может приводить к созданию нескольких редакций этого документа в процессе заключения указанного договора.
В контролируемой пользователем разработке требования к ПС формулируются разработчиком при участии представителя пользователей. Роль пользователя в этом случае сводится к информированию разработчика о своих потребностях в ПС и контролю за тем, чтобы формулируемые требования действительно выражали его потребности в ПС. В конечном счете разработанные требования, как правило, утверждаются представителем пользователя.
В независимой от пользователя разработке требования к ПС определяются без какого-либо участия пользователя (на полную ответственность разработчика). Это происходит обычно тогда, когда разработчик решает создать ПС широкого применения в расчете на то, разработанное им ПС найдет спрос на рынке программных средств.
С точки зрения обеспечения надежности ПС наиболее предпочтительным является контролируемая пользователем разработка.
Основные принципы ООП2
Объе́ктно-ориенти́рованное, или объектное, программи́рование (в дальнейшем ООП) — парадигма программирования, в которой основными концепциями являются понятия объектов и классов. В случае языков спрототипированием вместо классов используются объекты-прототипы. Объектно-ориентированное программирование основано натрех важнейших принципах, придающих объектам новые свойства. Этими принципами являются инкапсуляция, наследование и полиморфизм.
Инкапсуляция — это свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе и скрыть детали реализации от пользователя.
Полиморфизм — это свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта. то есть возможность объектов с одинаковой спецификацией иметь различную реализацию.
Наследование — это свойство системы, позволяющее описать новый класс на основе уже существующего с частично или полностью заимствующейся функциональностью.
Основные характеристики программного модуля60
С момента своего возникновения программирование боролось за возможность решать все более сложные задачи, создавать все более сложные программные системы и делать это как можно быстрее. В процессе разработки программ модульное программирование явилось воплощением общих методов борьбы со сложностью, обеспечения независимости компонент системы и использования иерархических структур.
Метод разработки программ по частям называют модульным программированием.
Программный модуль - это любой фрагмент описания процесса, оформляемый как самостоятельный программный продукт, пригодный для использования в других описаниях процесса.
Критерии приемлемости выделенного модуля (по Хольту):
-хороший модуль снаружи проще, чем внутри;
-хороший модуль проще использовать, чем построить.
Критерии приемлемости выделенного модуля (по Майерсу):
-размер модуля,
-прочность модуля,
-сцепление с другими модулями,
-рутинность модуля (независимость от предыстории обращений к нему).
Размер модуля измеряется числом содержащихся в нем операторов или строк. Обычно рекомендуются программные модули размером от нескольких десятков до нескольких сотен операторов.
Прочность модуля - это мера его внутренних связей. Чем выше прочность модуля, тем больше связей он может спрятать от внешней по отношению к нему части программы и, следовательно, тем больший вклад в упрощение программы он может внести. Для оценки степени прочности модуля Майерс предлагает упорядоченный по степени прочности набор из семи классов модулей. Для использования рекомендуются только два высших по прочности класса модулей. Функционально прочный модуль - это модуль, реализующий одну какую-либо определенную функцию. При реализации этой функции такой модуль может использовать и другие модули. Информационно прочный модуль - это модуль, выполняющий (реализующий) несколько операций (функций) над одной и той же структурой данных (информационным объектом), которая считается неизвестной вне этого модуля. Для каждой из этих операций в таком модуле имеется свой вход со своей формой обращения к нему.
Сцепление модуля - это мера его зависимости по данным от других модулей. Характеризуется способом передачи данных. Единственным видом сцепления модулей, который рекомендуется для использования современной технологией программирования, является параметрическое сцепление (сцепление по данным по Майерсу) - данные передаются модулю либо при обращении к нему как значения его параметров, либо как результат его обращения к другому модулю для вычисления некоторой функции. Такой вид сцепления модулей реализуется на языках программирования при использовании обращений к процедурам (функциям).
Рутинность модуля - это его независимость от предыстории обращений к нему. Модуль будем называть рутинным, если результат (эффект) обращения к нему зависит только от значений его параметров (и не зависит от предыстории обращений к нему).
Модуль будем называть зависящим от предыстории, если результат (эффект) обращения к нему зависит от внутреннего состояния этого модуля, изменяемого в результате предыдущих обращений к нему.
Приемлема следующая рекомендация:
всегда следует использовать рутинный модуль, если это не приводит к плохим (не рекомендуемым) сцеплениям модулей;
зависящие от предыстории модули следует использовать только в случае, когда это необходимо для обеспечения параметрического сцепления;
в спецификации зависящего от предыстории модуля должна быть четко сформулирована эта зависимость таким образом, чтобы было возможно прогнозировать поведение (эффект выполнения) данного модуля при разных последующих обращениях к нему.
Полиморфизм4
Полиморфизм — это свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта. то есть возможность объектов с одинаковой спецификацией иметь различную реализацию
Полнофункциональность и целостность ПО67
Понятие архитектуры программного средства.28
Архитектура ПС - это его строение как оно видно (или должно быть видно) из-вне его, т.е. представление ПС как системы, состоящей из некоторой совокупности взаимодействующих подсистем. В качестве таких подсистем выступают обычно отдельные программы. Разработка архитектуры является первым этапом борьбы со сложностью ПС, на котором реализуется принцип выделения относительно независимых компонент.
Основные задачи разработки архитектуры ПС:
· выделение программных подсистем и отображение на них внешних функций (заданных во внешнем описании) ПС;
· определение способов взаимодействия между выделенными программными подсистемами.
С учетом принимаемых на этом этапе решений производится дальнейшая конкретизация и функциональных спецификаций.
Понятие жизненного цикла программы.31
Под жизненным циклом ПС понимают весь период его разработки и эксплуатации (использования), начиная от момента возникновения замысла ПС и кончая прекращением всех видов его использования [3.1 - 3.4]. Жизненный цикл включает все процессы создания и использования ПС
Различают следующие стадии жизненного цикла ПС: разработку ПС, производство программных изделий (ПИ) и эксплуатацию ПС.
Стадия разработки (development) ПС состоит из этапа его внешнего описания, этапа конструирования ПС, этапа кодирования (программирование в узком смысле) ПС и этапа аттестации ПС. Всем этим этапам сопутствуют процессы документирования и управление (management) разработкой ПС. Этапы конструирования и кодирования часто перекрываются, иногда довольно сильно. Это означает, что кодирование некоторых частей программного средства может быть начато до завершения этапа конструирования.
Внешнее описание (Requirements document) ПС является описанием его поведения с точки зрения внешнего по отношению к нему наблюдателю с фиксацией требований относительно его качества. Внешнее описание ПС начинается с определения требований к ПС со стороны пользователей (заказчика).
Конструирование (design) ПС охватывает процессы: разработку архитектуры ПС, разработку структур программ ПС и их детальную спецификацию.
Кодирование (coding ) создание текстов программ на языках программирование, их отладку с тестированием ПС.
На этапе аттестации ПС производится оценка качества ПС, после успешного завершения которого разработка ПС считается законченной.
Программное изделие (ПИ) - экземпляр или копия, снятая с разработанного ПС. Изготовление ПИ - это процесс генерации и/или воспроизведения (снятия копии) программ и программных документов ПС с целью их поставки пользователю для применения по назначению. Производство ПИ - это совокупность работ по обеспечению изготовления требуемого количества ПИ в установленные сроки [3.1]. Стадия производства ПС в жизненном цикле ПС является, по-существу, вырожденной (не существенной), так как представляет рутинную работу, которая может быть выполнена автоматически и без ошибок. Этим она принципиально отличается от стадии производства различной техники. В связи с этим в литературе эту стадию, как правило, не включают в жизненный цикл ПС.
Стадия эксплуатации ПС охватывает процессы хранения, внедрения и сопровождения ПС, а также транспортировки и применения (operation) ПИ по своему назначению. Она состоит из двух параллельно проходящих фаз: фазы применения ПС и фазы сопровождения ПС [3.4, 3.5].
Применение (operation) ПС - это использование ПС для решения практических задач на компьютере путем выполнения ее программ.
Сопровождение (maintenance) ПС - это процесс сбора информации о его качестве в эксплуатации, устранения обнаруженных в нем ошибок, его доработки и модификации, а также извещения пользователей о внесенных в него изменениях
Понятие защищенности программного средства.25
Защищенность - свойство, характеризующее способность ПС противостоять преднамеренным или нечаянным деструктивным (разрушающим) действиям пользователя.
Понятие инструментальной среды разработки и сопровождения программных средств.30
В настоящее время с каждой системой программирования связываются не отдельные инструменты (например, компилятор), а некоторая логически связанная совокупность программных и аппаратных инструментов поддерживающих разработку и сопровождение ПС на данном языке программирования или ориентированных на какую-либо конкретную предметную область. Такую совокупность будем называть инструментальной средой разработки и сопровождения ПС. Для таких инструментальных сред характерно, во-первых, использование как программных, так и аппаратных инструментов, и, во-вторых, определенная ориентация либо на конкретный язык программирования, либо на конкретную предметную область.
Инструментальная среда не обязательно должна функционировать на том компьютере, на котором должно будет применяться разрабатываемое с помощью ее ПС. Часто такое совмещение бывает достаточно удобным (если только мощность используемого компьютера позволяет это): не нужно иметь дело с компьютерами разных типов, в разрабатываемую ПС можно включать компоненты самой инструментальной среды. Однако, если компьютер, на котором должно применяться ПС, недоступен для разработчиков этого ПС (например, он постоянно занят другой работой, которую нельзя прерывать, или он находится еще в стадии разработки), либо неудобен для разработки ПС, либо мощность этого компьютера недостаточна для обеспечения функционирования требуемой инструментальной среды, то применяется так называемый инструментально-объектный подход. Сущность его заключается в том, что ПС разрабатывается на одном компьютере, называемым инструментальным, а применяться будет на другом компьютере, называемым целевым (илиобъектным).
Различают три основных класса [16.1] инструментальных средразработки и сопровождения ПС (рис. 16.1): ·
среды программирования, ·
рабочие места компьютерной технологии,·
инструментальные системы технологии программирования.
Среда программирования предназначена в основном для поддержки процессов программирования (кодирования), тестирования и отладки ПС. Рабочее место компьютерной технологии ориентировано на поддержку ранних этапов разработки ПС (спецификаций) и автоматической генерации программ по спецификациям. Инструментальная система технологии программирования предназначена для поддержки всех процессов разработки и сопровождения в течение всего жизненного цикла ПС и ориентирована на коллективную разработку больших программных систем с длительным жизненным циклом. Для таких систем стоимость сопровождения обычно превышает стоимость разработки.
Понятие качества программного обеспечения69
Понятие качества программного средства.22
Ка́чество програ́ммного средства — характеристика программного обеспечения (ПО) как степени его соответствия требованиям. При этом требования могут трактоваться довольно широко, что порождает целый ряд независимых определений понятия. Чаще всего используется определение ISO 9001, согласно которому качество есть «степень соответствия присущих характеристик требованиям».
Фактор качества ПО — это нефункциональное требование к программе, которое обычно не описывается в договоре с заказчиком, но, тем не менее, является желательным требованием, повышающим качество программы.
Некоторые из факторов качества:
понятность
Назначение ПО должно быть понятным, из самой программы и документации.
полнота
Все необходимые части программы должны быть представлены и полностью реализованы.
краткость
Отсутствие лишней, дублирующейся информации. Повторяющиеся части кода должны быть преобразованы в вызов общей процедуры. То же касается и документации.
портируемость
Лёгкость в адаптации программы к другому окружению: другой архитектуре, платформе, операционной системе или её версии.
согласованность
По всей программе и в документации должны использоваться одни и те же соглашения, форматы и обозначения.
сопровождаемость
Насколько сложно изменить программу для удовлетворения новых требований. Это требование также указывает, что программа должна быть хорошо документирована, не слишком запутана, и иметь резерв роста по использованию ресурсов (память, процессор).
тестируемость
Позволяет ли программа выполнить проверку приёмочных характеристик, поддерживается ли возможность измерения производительности.
удобство использования
Простота и удобство использования программы. Это требование относится прежде всего к интерфейсу пользователя.
надёжность
отсутствие отказов и сбоев в работе программ, а также простота исправления дефектов и ошибок.
структурированность
эффективность
Насколько рационально программа относится к ресурсам (память, процессор) при выполнении своих задач.
безопасность
Понятие мобильности программного средства.23
Мобильность - это свойство программы, выражающееся в возможности ее адаптации для работы в различных окружениях. Можно говорить о высокой или низкой мобильности программ, понимая при этом большую или меньшую степень легкости ее адаптации к вычислительной среде. Высокая мобильность облегчает использование ранее созданного прикладного программного обеспечения и перенос программы с одной платформы на другую, что приводит к существенному уменьшению времени разработки и стоимости программного обеспечения. Мобильность программного обеспечения зависит от многих факторов. Мобильность в значительной степени зависит от распространенности используемого языка программирования, его стандартизации, точности и строгости эталонного описания, а также от имеющихся в языке специальных средств написания мобильных программ. Мобильность программ косвенно зависит от богатства выразительных средств языка. Мобильность программ во многом определяется также дисциплиной и технологией программирования, реализацией языка, качеством документации и другими факторами. Мобильность программного обеспечения зависит и от ряда других факторов.
Понятие модели программного средства.42
Модель - упрощенное представление о реальном объекте, процессе или явлении.
Модель - это, как правило, искусственно созданный объект в виде схемы, математических формул, физической конструкции, наборов данных и алгоритмов их обработки и т.п.
Модель воспроизводит в специально оговоренном виде строение и свойства исследуемого объекта. Исследуемый объект, по отношению к которому изготавливается модель, называется оригиналом, образцом, прототипом.
Модель - это объект, используемый вместо другого объекта с какой-то целью.
Моделирование — это метод познания, состоящий в создании и исследовании моделей.
Каждый объект имеет большое количество различных свойств. В процессе построения модели выделяются главные, наиболее существенные, свойства. Так, модель самолета должна иметь геометрическое подобие оригиналу, модель атома — правильно отражать физические взаимодействия, архитектурный макет города – ландшафт и т.д.
Цели моделирования.
понять сущность изучаемого объекта,
научиться управлять объектом и определять наилучшие способы управления,
прогнозировать прямые или косвенные последствия,
решать прикладные задачи.
Разные науки исследуют объекты и процессы под разным углом зрения и строят различные типы моделей. В физике изучаются процессы взаимодействия и движения объектов, в химии — их внутреннее строение, в биологии — поведение живых организмов и т.д.
Возьмем в качестве примера человека, в разных науках он исследуется в рамках различных моделей. В рамках механики его можно рассматривать как материальную точку, в химии — как объект, состоящий из различных химических веществ, в биологии — как систему, стремящуюся к самосохранению и т.д.
С другой стороны, разные объекты могут описываться одной моделью. Так, в механике различные материальные тела (от планеты до песчинки) могут рассматриваться как материальные точки.
Один и тот же объект может иметь множество моделей, а разные объекты могут описываться одной моделью.
Классификация моделей
Основные признаки классификации моделей:
Область использования;
Учет в модели временного фактора (динамики);
Отрасль знаний;
Способ представления моделей.
Классификация по области использования
|
Модели |
||||
|
Учебные |
Опытные |
Научно - технические |
Игровые |
Имитационные |
|
Тренажеры, наглядные пособия, обучающие программы |
Модели корабля, машины (для исследования будущих характеристик) |
Синхрофазотрон, прибор, имитирующий разряд молнии |
Деловые, военные, экономические, спортивные игры, |
Новое лекарство испытывают на мышах, чтобы выявить побочные явления, уточнить дозировки |
Опытные модели — это уменьшенные или увеличенные копии проектируемого объекта. Их называют также натурными и используют для исследования объекта и прогнозирования его будущих характеристик.
Научно-технические модели создают для исследования процессов и явлений.
Имитационные модели не просто отражают реальность с той или иной степенью точности, а имитируют ее. Эксперимент либо много кратно повторяется, чтобы изучить и оценить последствия каких-либо действий на реальную обстановку, либо проводится одновременно со многими другими похожими объектами, но поставленными в разные условия. Подобный метод выбора правильного решения называется методом проб и ошибок.
2. Классификация с учетом фактора времени: статическая и динамическая модели.
Статическая модель — это как бы одномоментный срез информации по объекту. Например, обследование учащихся в стоматологической поликлинике дает картину состояния их ротовой полости на данный момент времени: число молочных и постоянных зубов, пломб, дефектов и т. п.
Динамическая модель позволяет увидеть изменения объекта во вре мени. В примере с поликлиникой карточку школьника, отражающую изменения, происходящие с его зубами за многие годы, можно считать динамической моделью.
Как видно из примеров, один и тот же объект, возможно, изучать, применяя и статическую и динамическую модели.
3. Классификация по способу представления
Материальные и информационные модели
|
Модели |
|||
|
Материальные |
Информационные |
||
|
Знаковые |
Вербальные |
||
|
Компьютерные |
Некомпьютерные |
Материальные модели иначе можно назвать предметными, физическими. Они воспроизводят геометрические и физические свойства оригинала и всегда имеют реальное воплощение.
Самые простые примеры материальных моделей — детские игрушки. По ним ребенок получает первое представление об окружающем мире. Двухлетний малыш играет с плюшевым медвежонком. Когда, спустя годы, ребенок увидит в зоопарке настоящего медведя, он без труда узнает его.
Материальные модели — это, к примеру, чучела птиц в кабинете биологии, карты при изучении истории и географии, схемы солнечной системы и звездного неба на уроках астрономии, макет многоступенчатой ракеты и еще многое другое.
Информационные модели нельзя потрогать или увидеть воочию, они не имеют материального воплощения, потому что они строятся только на информации. В основе этого метода моделирования лежит информационный подход к изучению окружающей действительности.
|
Информационная модель – совокупность информации, характеризующая свойства и состояние объекта, процесса, явления, а также взаимосвязь с внешним миром. |
Знаковые и вербальные информационные модели
К информационным моделям можно отнести вербальные (от лат. «verbalize» — устный) модели, полученные в результате раздумий, умозаключений. Они могут так и остаться мысленными или быть выражены словесно. Примером такой модели может стать наше поведение при переходе улицы. Человек анализирует ситуацию на дороге (что показывает светофор, как далеко находятся машины, с какой скоростью они движутся и т. п.) и вырабатывает свою модель поведения. Если ситуация смоделирована правильно, то переход будет безопасным, если нет, то может произойти авария. К таким моделям можно отнести и идею, возникшую у изобретателя, и музыкальную тему, промелькнувшую в голове композитора, и рифму, прозвучавшую пока еще в сознании поэта.
Вербальная модель – информационная модель в мысленной или разговорной форме.
Знаковая модель – информационная модель, выраженная специальными знаками, т. е. средствами любого формального языка.
Знаковые модели окружают нас повсюду. Это рисунки, тексты, графики и схемы... Вербальные и знаковые модели, как правило, взаимосвязаны. Мысленный образ, родившийся в мозгу человека, может быть облечен в знаковую форму. И наоборот, знаковая модель помогает сформировать в сознании верный мысленный образ.
По форме представления можно выделить следующие виды информационных моделей:
геометрические модели — графические формы и объемные конструкции;
словесные модели — устные и письменные описания с использованием иллюстраций;
математические модели — математические формулы, отображающие связь различных параметров объекта или процесса;
структурные модели — схемы, графики, таблицы и т. п.;
логические модели — модели, в которых представлены различные варианты выбора действий на основе умозаключений и анализа условий;
специальные модели — ноты, химические формулы и т. п.;
компьютерные и некомпьютерные модели.
Компьютерные и некомпьютерные модели
Если модель выражена в абстрактной, умозрительной форме, то нужны некоторые знаковые системы, позволяющие описать ее — специальные языки, чертежи, схемы, графики, таблицы, алгоритмы, математические формулы и т. п. Здесь могут быть использованы два варианта инструментария: либо традиционный набор инженера или конструктора (карандаш, линейка), либо самый совершенный в наши дни прибор — компьютер.
4. Классификации информационных знаковых моделей: по способу реализации:
компьютерные и некомпьютерные модели.
Понятие модульности программного средства.27
Модульность - свойство, характеризующее ПС с точки зрения организации его программ из таких дискретных компонент, что изменение одной из них оказывает минимальное воздействие на другие компоненты.
Модульность в языках программирования — принцип, согласно которому программное средство (ПС, программа, библиотека, веб-приложение и др.) разделяется на отдельные именованные сущности, называемые модулями. Модульность часто является средством упрощения задачи проектирования ПС и распределения процесса разработки ПС между группами разработчиков. При разбиении ПС на модули для каждого модуля указывается реализуемая им функциональность, а также связи с другими модулями.[1]
Роль модулей могут играть структуры данных, библиотеки функций, классы, сервисы и др. программные единицы, реализующие некоторую функциональность и предоставляющие интерфейс к ней.
Понятие надежности программного средства.20
Надежность программного обеспечения - способность программного продукта безотказно выполнять определенные функции при заданных условиях в течение заданного периода времени с достаточно большой вероятностью.
Степень надежности характеризуется вероятностью работы программного продукта без отказа в течение определенного периода времени.
Существует ^ 4 основные составляющие функциональной надежности программных систем:
безотказность - свойство программы выполнять свои функции во время эксплуатации;
работоспособность - свойство программы корректно (так как ожидает пользователь) работать весь заданный период эксплуатации;
безопасность - свойство программы быть не опасной для людей и окружающих систем;
защищенность - свойство программы противостоять случайным или умышленным вторжениям в нее.
Факторы, влияющие на надежность ПО
К числу основных факторов, влияющих на надежность ПО отнесены:
взаимодействие ПО с внешней средой (программно-аппаратная средства, трансляторы, ОС). Этот фактор вносит наименьший вклад в надежность ПО при современном уровне надежности аппаратуры, ОС и компиляторов;
взаимодействие с человеком (разработчиком и пользователем) (см. например метрику Холстеда);
организация ПО (проектирование, постановка задачи и способы их достижения и реализации) и качество его разработки. Этот фактор вносит наибольший вклад в надежность;
тестирование.
Понятие программного модуля.29
Программный модуль - это любой фрагмент описания процесса, оформляемый как самостоятельный программный продукт, пригодный для использования в других описаниях процесса.
Критерии приемлемости выделенного модуля (по Хольту):
хороший модуль снаружи проще, чем внутри;
хороший модуль проще использовать, чем построить.
Критерии приемлемости выделенного модуля (по Майерсу):
размер модуля,
прочность модуля,
сцепление с другими модулями,
рутинность модуля (независимость от предыстории обращений к нему).
Размер модуля измеряется числом содержащихся в нем операторов или строк. Обычно рекомендуются программные модули размером от нескольких десятков до нескольких сотен операторов.
Прочность модуля - это мера его внутренних связей. Чем выше прочность модуля, тем больше связей он может спрятать от внешней по отношению к нему части программы и, следовательно, тем больший вклад в упрощение программы он может внести. Для оценки степени прочности модуля Майерспредлагает упорядоченный по степени прочности набор из семи классов модулей. Для использования рекомендуются только два высших по прочности класса модулей. Функционально прочный модуль - это модуль, реализующий одну какую-либо определенную функцию. При реализации этой функции такой модуль может использовать и другие модули. Информационно прочный модуль - это модуль, выполняющий (реализующий) несколько операций (функций) над одной и той же структурой данных (информационным объектом), которая считается неизвестной вне этого модуля. Для каждой из этих операций в таком модуле имеется свой вход со своей формой обращения к нему.
Сцепление модуля - это мера его зависимости по данным от других модулей. Характеризуется способом передачи данных. Единственным видом сцепления модулей, который рекомендуется для использования современной технологией программирования, является параметрическое сцепление (сцепление по данным по Майерсу) - данные передаются модулю либо при обращении к нему как значения его параметров, либо как результат его обращения к другому модулю для вычисления некоторой функции. Такой вид сцепления модулей реализуется на языках программирования при использовании обращений к процедурам (функциям).
Рутинность модуля - это его независимость от предыстории обращений к нему. Модуль будем называть рутинным, если результат (эффект) обращения к нему зависит только от значений его параметров (и не зависит от предыстории обращений к нему).
Модуль будем называть зависящим от предыстории, если результат (эффект) обращения к нему зависит от внутреннего состояния этого модуля, изменяемого в результате предыдущих обращений к нему.
Понятие расширяемости программного средства.26
Расширяемость - свойство, характеризующее способность ПС к использованию большего объема памяти для хранения данных или расширению функциональных возможностей отдельных компонент.
Понятие сопровождения программного средства.21
Сопровожде́ние программного средства — процесс улучшения, оптимизации и устранения дефектов программного обеспечения (ПО) после передачи в эксплуатацию. Сопровождение ПО — это одна из фаз жизненного цикла программного обеспечения, следующая за фазой передачи ПО в эксплуатацию. В ходе сопровождения в программу вносятся изменения, с тем, чтобы исправить обнаруженные в процессе использования дефекты и недоработки, а также для добавления новой функциональности, с целью повысить удобство использования (юзабилити) и применимость ПО.
В модели водопада, сопровождение ПО выделяется в отдельную фазу цикла разработки. В спиральной модели, возникшей в ходе развития объектно-ориентированного программирования, сопровождение не выделяется как отдельный этап. Тем не менее, эта деятельность занимает значительное место, учитывая тот факт, что обычно около 2/3 жизненного цикла программных систем занимает сопровождение.
Сопровождаемость программного обеспечения — характеристики программного продукта, позволяющие минимизировать усилия по внесению в него изменений:
для устранения ошибок;
для модификации в соответствии с изменяющимися потребностями пользователей.
Понятие устойчивости программного средства.24
Устойчивость - свойство, характеризующее способность ПС продолжать корректное функционирование, несмотря на задание неправильных (ошибочных) входных данных.
Понятия программного средства, программного обеспечения (ПО) и программного продукта19
Проектирование и реализация ПО13
На этапе проектирования ПО определяется его структура, данные, которые являются частью системы, интерфейсы взаимодействия системных компонентов и иногда исполь зуемые алгоритмы. Проектировщики сразу никогда не получают законченный результат — процесс проектирования обычно проходит через разработку нескольких промежуточных версий ПО. Проектирование предполагает последовательную формализацию и детализа цию создаваемого ПО с возможностью внесения изменении в решения, принятые на бо лее ранних стадиях проектирования.
Процесс проектирования может включать разработку нескольких моделей системы различных уровней обобщения. Поскольку проектирование — это процесс декомпозиции, такие модели помогают выявить ошибки, допущенные на ранних стадиях проектирова ния, а следовательно, позволяют внести изменения в ранее созданные модели.
Ниже перечислены отдельные этапы процесса проектирования.
1. Архитектурное проектирование. Определяются и документируются подсистемы и взаимосвязи между ними.
2. Обобщенная спецификация. Для каждой подсистемы разрабатывается обобщенная спецификация на ее сервисы и ограничения.
3. Проектирование интерфейсов. Для каждой подсистемы определяется и доку ментируется ее интерфейс. Спецификации на эти интерфейсы должны быть точно выраженными и однозначными, чтобы использование подсистем не требовало знаний о том, как они реализуют свои функции. На этом этапе можно применить методы формальных спецификаций.
4. Компонентное проектирование. Проводится распределение системных функций (сер висов) по различным компонентам и их интерфейсам.
5. Проектирование структур данных. Детально разрабатываются структуры данных, не обходимые для реализации программной системы.
6. Проектирование алгоритмов. Детально разрабатываются алгоритмы, предназна ченные для реализации системных сервисов.
Работа с файлами7
Для работы с файлами используются специальные типы данных, называемые потоками.
Поток данных (англ. stream) в программировании — абстракция, используемая для чтения или записи файлов, сокетов и т. п. в единой манере.
Потоки являются удобным унифицированным программным интерфейсом для чтения или записи файлов
Поток ifstream служит для работы с файлами в режиме чтения, а ofstream в режиме записи. Для работы с файлами в режиме как записи, так и чтения служит поток fstream.
В программах на C++ при работе с текстовыми файлами необходимо подключать библиотеки iostream и fstream
Современные технологии программирования1
Tехнология связывания и внедрения объектов OLE
OLE позволяет передавать часть работы от одной программы редактирования к другой и возвращать результаты назад.Основное преимущество использования технологии OLE (кроме уменьшения размера файла) в том, что она позволяет создать главный файл, картотеку функций, к которой обращается программа. Этот файл может оперировать данными из исходной программы, которые после обработки возвращаются в исходный документ.
Tехнология COM (Component Object Model), DCOM
COM и DCOM - технологии, обеспечивающие взаимодействие между компонентами приложения и позволяющие развертывать распределенное приложение на платформе Windows. COM является моделью программирования на основе объектов, которая упрощает взаимодействие различных приложений и компонентов, а DCOM - это своего рода "клей", связывающий воедино разнообразные технологии, применяемые в распределенных приложениях. DCOM дает возможность двум или нескольким компонентам легко взаимодействовать друг с другом независимо от того, когда и на каком языке программирования они были написаны,
Tехнология OLE DB
OLE DB, Object Linking and Embedding, Database - набор интерфейсов, основанных на COM, которые позволяют приложениям обращаться к данным, хранимым в разных источниках информации или хранилищах данных с помощью унифицированного доступа.
Tехнология ActiveX
ActiveX - технология Microsoft, предназначенная для написания сетевых приложений. Она предоставляет программистам наборы стандартных библиотек, значительно облегчающих процесс кодирования.
5. Технология Open Database Connectivity
ODBC (англ. Open Database Connectivity) — это программный интерфейс (API) доступа к базам данных
6.Технологии .NET Framework и Mono
.NET Framework — программная платформа, мобильная бинарная среда, выпущенная компанией Microsoft в 2002 году и позволяющая работать скомпилированным приложениям на любой аппаратной платформе в среде Windows. Основой платформы является исполняющая (бинарная) среда Common Language Runtime (CLR), способная выполнять как обычные программы, так и серверные веб-приложения. NET Framework поддерживает создание программ, написанных на разных языках программирования.
7.Tехнология визуального программирования
Визуальное программирование позволяет программировать, используя графические или символьные элементы, которыми можно манипулировать интерактивным образом согласно некоторым правилам, причем пространственное графических объектов использовать в качестве элементов синтаксиса программы.
8.Технология CUDA, Compute Unified Device Architecture
CUDA SDK позволяет программистам реализовывать на специальном упрощённом диалекте языка программирования Си алгоритмы, выполнимые на графических процессорах NVIDIA, и включать специальные функции в текст программы на Cи.
Спецификация качества программного средства.33
Разработка спецификации качества сводится, по-существу, к построению своеобразной модели качества разрабатываемой ПС [4.2, 4.3]. В этой модели должен быть перечень всех тех достаточно элементарных свойств, которые требуется обеспечить в разрабатываемом ПС и которые в совокупности образуют приемлемое для пользователя качество ПС. При этом каждое из этих свойств должно быть в достаточной степени конкретизировано с учетом определения требований к разрабатываемому ПС и возможности оценки его наличия у разработанного ПС или необходимой степени обладания им этим ПС.
Для конкретизации качества ПС по каждому из критериев используется стандартизованный набор достаточно простых свойств ПС [4.3-4.6], однозначно интерпретируемых разработчиками. Такие свойства мы будем называть примитивами качества ПС. Некоторые из примитивов могут использоваться по нескольким критериям. Ниже приводится зависимость критериев качества от примитивов качества ПС.
Функциональность: завершенность.
Надежность: завершенность, точность, автономность, устойчивость, защищенность.
Легкость применения: П-документированность, информативность (только применительно к документации по применению), коммуникабельность, устойчивость, защищенность.
Эффективность: временнaя эффективность, эффективность по памяти, эффективность по устройствам.
Сопровождаемость. С данным критерием связано много различных примитивов качества. Однако их можно распределить по двум группам, выделив два подкритерия качества: изучаемость и модифицируемость. Изучаемость - это характеристики ПС, которые позволяют минимизировать усилия по изучению и пониманию программ и документации ПС. Модифицируемость - это характеристики ПС, которые упрощают внесение в него необходимых изменений и доработок.
Изучаемость: С-документированность, информативность (здесь применительно и к документации по сопровождению), понятность, структурированность, удобочитаемость.
Модифицируемость: расширяемость, структурированность, модульность.
Мобильность: независимость от устройств, автономность, структурированность, модульность.
Ниже даются определения используемых примитивов качества ПС [4.3-4.5].
Завершенность - свойство, характеризующее степень обладания ПС всеми необходимыми частями и чертами, требующимися для выполнения своих явных и неявных функций.
Точность - мера, характеризующая приемлемость величины погрешности в выдаваемых программами ПС результатах с точки зрения предполагаемого их использования.
Автономность - свойство, характеризующее способность ПС выполнять предписанные функции без помощи или поддержки других компонент программного обеспечения.
Устойчивость - свойство, характеризующее способность ПС продолжать корректное функционирование, несмотря на задание неправильных (ошибочных) входных данных.
Защищенность - свойство, характеризующее способность ПС противостоять преднамеренным или нечаянным деструктивным (разрушающим) действиям пользователя.
П-документированность - свойство, характеризующее наличие, полноту, понятность, доступность и наглядность учебной, инструктивной и справочной документации, необходимой для применения ПС.
Информативность - свойство, характеризующее наличие в составе ПС информации, необходимой и достаточной для понимания назначения ПС, принятых предположений , существующих ограничений, входных данных и результатов работы отдельных компонент, а также текущего состояния программ в процессе их функционирования.
Коммуникабельность - свойство, характеризующее степень, в которой ПС облегчает задание или описание входных данных, а также обеспечивает выдачу полезных сведений в форме и с содержанием, простыми для понимания.
Временнaя эффективность - мера, характеризующая способность ПС выполнять возложенные на него функции за определенный отрезок времени.
Эффективность по памяти - мера, характеризующая способность ПС выполнять возложенные на него функции при определенных ограничениях на используемую память.
Эффективность по устройствам - мера, характеризующая экономичность использования устройств машины для решения поставленной задачи.
С-документировапнность - свойство, характеризующее с точки зрения наличия документации, отражающей требования к ПС и результаты различных этапов разработки данной ПС, включающие возможности, ограничения и другие черты ПС, а также их обоснование.
Понятность - свойство, характеризующее степень в которой ПС позволяет изучающему его лицу понять его назначение, сделанные допущения и ограничения, входные данные и результаты работы его программ, тексты этих программ и состояние их реализации. Этот примитив качества синтезирован нами из таких примитивов ИСО [4.4], как согласованность, самодокументированность, четкость и, собственно, понятность.
Структурированность - свойство, характеризующее программы ПС с точки зрения организации взаимосвязанных их частей в единое целое определенным образом (например, в соответствии с принципами структурного программирования).
Удобочитаемость - свойство, характеризующее легкость восприятия текста программ ПС (отступы, фрагментация, форматив-
ность).
Расширяемость - свойство, характеризующее способность ПС к использованию большего объема памяти для хранения данных или расширению функциональных возможностей отдельных компонент.
Модульность - свойство, характеризующее ПС с точки зрения организации его программ из таких дискретных компонент, что изменение одной из них оказывает минимальное воздействие на другие компоненты.
Независимость от устройств - свойство, характеризующее способность ПС работать на разнообразном аппаратном обеспечении (различных типах, марках, моделях ЭВМ).
Спецификация ПО12
Результатом его вы полнения является разработка документации, формализующей требования, предъяв ляемые к системе, т.е. создание системной спецификации. В этой документации тре бования обычно представлены на двух уровнях детализации. На самом верхнем уров не представлены требования, определяемые конечными пользователями пли заказчи ками ПО; по для разработчиков необходима более детализированная системная спе цификация.
Процесс разработки требований включает четыре основных этапа.
1. Предварительные исследования. Оценивается степень удовлетворенности пользовате лей существующими программными продуктами и аппаратными средствами, а так же экономическая эффективность будущей системы и возможность уложиться в существующие бюджетные ограничения при ее разработке. Этот этап должен быть по возможности коротким и дешевым.
2. Формирование и анализ требований. Формируются системные требования путем изучения существующих аналогичных сметем, обсуждения будущей системы с по тенциальными пользователями и заказчиками, анализа задач, которые должна решать система, и т.п. Этот этап может включать разработку нескольких моделей системы и ее прототипов, что помогает сформировать функциональные требо вания к системе.
3. Специфицирование требовании. Осуществляется перевод всей совокупности информации, собранной на предыдущем этапе, в документ, определяющий множество требований. Этот документ обычно содержит два типа требований: пользовательские — обобщенные представления заказчиков и конечных пользователей о системе; системные - детальное описание функциональных показателей системы.
4. Утверждение требований. Проверяется выполнимость, согласованность и полнота множества требований. В процессе формирования ограничений неизбежно воз никновение каких-либо ошибок. На этом этапе они должны быть по возможности выявлены и устранены.
Конечно, процесс разработки требований трудно уложить в описанную последова тельность этапов. Например, анализ требований выполняется на протяжении всего про цесса их разработки, поэтому внесение новых или изменение уже сформулированных требований возможно на любом этапе. Как правило, этапы разработки требований пере крываются во времени.
Стадии и этапы разработки программного обеспечения49
Пре-альфа. Начальная стадия разработки — Период времени со старта разработки до выхода стадии Альфа (или до любой другой, если стадии Альфа нет).
Альфа. Внутреннее тестирование — Стадия начала тестирования программы в целом специалистами-тестерами, обычно не разработчиками программного продукта, но, как правило, внутри организации или сообществе разрабатывающих продукт.
Бета. Публичное тестирование — Стадия активного бета-тестирования и отладки программы, прошедшей альфа-тестирование (если таковое было). Программы этого уровня могут быть использованы другими разработчиками программного обеспечения для испытания совместимости.
Релиз-кандидат или RC (англ. release candidate), Пре-релиз или Pre — стадия-кандидат на то, чтобы стать стабильной. Программы этой стадии прошли комплексноетестирование, благодаря чему были исправлены все найденные критические ошибки.
Релиз или RTM (англ. release to manufacturing промышленное издание) — издание продукта, готового к тиражированию. Это стабильная версия программы, прошедшая все предыдущие стадии, в которых исправлены основные ошибки, но существует вероятность появления новых, ранее не замеченных, ошибок.
Стандартная библиотека шаблонов. Алгоритмы9
Стандартная библиотека шаблонов (STL) — подмножество стандартной библиотеки C++ и содержит контейнеры, алгоритмы, итераторы, объекты-функции и т. д. Ядро библиотеки составляют три группы шаблонных классов: контейнеры ,алгоритмы,итераторы. Алгоритм - это функция для манипулирования объектами, содержащимися в контейнере. Типичные примеры алгоритмов - сортировка и поиск. В STL реализовано порядка 60 алгоритмов, которые можно применять к различным контейнерам, в том числе к массивам, встроенным в язык C++.
Все стандартные алгоритмы описаны в файле algorithm, в пространстве имен std.
Основные виды алгоритмов:
-Математические (расчет сумм, произведений, генерация случайных значений)
-Поиска (минимальное значение, поиск последовательности, подсчет числа значений)
-Сортировки
Работы с последовательностями (объединение последовательностей, сравнения,обработки последовательности типовой операцией)
Стандартная библиотека шаблонов. Типы данных8
Стандартная библиотека шаблонов (STL) — подмножество стандартной библиотеки C++ и содержит контейнеры, алгоритмы, итераторы, объекты-функции и т. д. Ядро библиотеки составляют три группы шаблонных классов: контейнеры,алгоритмы,итераторы.
Контейнеры (containers) - это объекты, предназначенные для хранения других элементов. Например, вектор, линейный список, множество. Алгоритмы (algorithms) выполняют операции над содержимым контейнера. Существуют алгоритмы для инициализации, сортировки, поиска, замены содержимого контейнеров. Многие алгоритмы предназначены для работы с последовательностью (sequence), которая представляет собой линейный список элементов внутри контейнера.
Итераторы (iterators) - это объекты, которые по отношению к контейнеру играют роль указателей. Они позволяют получить доступ к содержимому контейнера примерно так же, как указатели используются для доступа к элементам массива.
STL строится на основе шаблонов классов, и поэтому входящие в нее алгоритмы и структуры применимы почти ко всем типам данных.
Структура и архитектура ПО61
Под архитектурой ПО обычно понимают набор внутренних структур ПО, состоящих из компонентов, связей и возможных взаимодействий между ними, а также видимых извне свойств этих компонентов.
Под компонентом в этом определении имеется в виду достаточно произвольный структурный элемент ПО, который можно выделить путем определения интерфейса взаимодействия между этим компонентом и всем, что его окружает. Термин «компонент» в разработке ПО чаще всего (далее, при обсуждении UML и технологии EJB) имеет несколько другой, более узкий смысл — это единица сборки системы, ее развертывания и конфигурационного управления, то, что не может быть разделено на более мелкие элементы при развертывании или поставке системы. Там, где возможны недоразумения, будет указано, в первом, широком или во втором, узком смысле употребляется этот термин.
Точно так же архитектура ПО представляет собой набор структур или представлений, имеющих различные уровни абстракции (аналог масштаба географических карт) и показывающих разные аспекты (структуру классов ПО, структуру развертывания, т.е. привязки компонентов ПО к физическим машинам, возможные сценарии взаимодействий компонентов и пр.), объединяемых привязкой всех представленных данных к структурным элементам ПО.
Архитектура важна прежде всего потому, что именно она определяет большинство характеристик качества ПО в целом. Архитектура служит также основным средством общения между разработчиками, а также и между всеми лицами, заинтересованными в данном ПО.
Выбор архитектуры определяет способ реализации требований на высоком уровне абстракции. Именно архитектура почти полностью определяет такие характеристики ПО как надежность, переносимость и удобство сопровождения. Архитектура значительно влияет и на удобство использования и эффективность ПО, которые определяются также и реализацией отдельных компонентов. Значительно меньше влияние архитектуры на функциональность — обычно для реализации заданной функциональности можно использовать различные архитектуры.
Поэтому выбор между той или иной архитектурой определяется прежде всего именно нефункциональными требованиями и необходимыми свойствами ПО в аспектах удобства сопровождения и переносимости. При этом для построения хорошей архитектуры надо учитывать возможные противоречия между требованиями к различным характеристикам и уметь выбирать компромиссные решения, дающие приемлемые значения по всем показателям.
Так, для повышения эффективности в общем случае выгоднее использовать монолитные архитектуры, в которых выделено небольшое число компонентов (в пределе — единственный компонент) — этим обеспечивается экономия как памяти, поскольку каждый компонент обычно имеет свои данные, а здесь число компонентов минимально, так и времени работы, поскольку возможность оптимизировать работу алгоритмов обработки данных имеется также, обычно, только в рамках одного компонента.
С другой стороны, для повышения удобства сопровождения, наоборот, лучше разбивать систему на большое число отдельных компонентов, с тем, чтобы каждый из них решал свою небольшую, но четко определенную часть общей задачи. При этом, если возникают изменения в требованиях или проекте, их обычно можно свести к изменению одной-нескольких таких подзадач, и, соответственно, изменять только отвечающие за решение этих подзадач компоненты.
С третьей стороны, для повышения надежности лучше использовать дублирование функций, т.е. сделать несколько компонентов ответственными за решение одной подзадачи. Причем, поскольку ошибки в ПО чаще всего носят неслучайный характер (т.е. они повторяемы, в отличии от аппаратного обеспечения, где ошибки связаны прежде всего со случайными изменениями характеристик среды и могут быть преодолены простым дублированием компонентов, без изменения их внутренней реализации), лучше использовать достаточно сильно различающиеся способы решения одной и той же задачи в разных компонентах.
Тестирование – способ обеспечение качества программного продукта.71
Тести́рование програ́ммного обеспе́чения — процесс исследования, испытания программного обеспечения (ПО) с целью получения информации о качестве продукта.
Существующие на сегодня методы тестирования ПО не позволяют однозначно и полностью выявить все дефекты и установить корректность функционирования анализируемой программы, поэтому все существующие методы тестирования действуют в рамках формального процесса проверки исследуемого или разрабатываемого ПО.
Такой процесс формальной проверки, или верификации, может доказать, что дефекты отсутствуют с точки зрения используемого метода. (То есть нет никакой возможности точно установить или гарантировать отсутствие дефектов в программном продукте с учётом человеческого фактора, присутствующего на всех этапах жизненного цикла ПО).
Существует множество подходов к решению задачи тестирования и верификации ПО, но эффективное тестирование сложных программных продуктов — это процесс в высшей степени творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых.
С точки зрения ISO 9126, качество программного обеспечения можно определить как совокупную характеристику исследуемого ПО с учётом следующих составляющих:
Надёжность
Сопровождаемость
Практичность
Эффективность
Мобильность
Функциональность
Более полный список атрибутов и критериев можно найти в стандарте ISO 9126 Международной организации по стандартизации. Состав и содержание документации, сопутствующей процессу тестирования, определяется стандартом IEEE 829-1998 Standard for Software Test Documentation.
Тестировщики используют тестовые скрипты на разных уровнях: как в модульном, так и в интеграционном и системном тестировании. Тестовые скрипты, как правило, пишутся для проверки компонентов, в которых наиболее высока вероятность появления отказов или вовремя не найденная ошибка может быть дорогостоящей.
Тестирование и отладка программного обеспечение70
Определение и принципы тестирования
Тестирование программного средства (ПС) - это процесс выполнения программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Указанный набор данных называется тестовым или просто тестом. Тестирование программ является одной из составных частей более общего понятия - «отладка программ». Под отладкой по нимается процесс, позволяющий получить программу, функциони рующую с требующимися характеристиками в заданной области изменения входных данных.
Процесс отладки включает:
действия, направленные на выявление ошибок (тестирование);
диагностику и локализацию ошибок (определение характера ошибок и их местонахождение);
внесение исправлений в программу с целью устранения ошибок.
Тестирование оказывается довольно необычным процессом (поэтому и считается трудным), так как этот процесс разрушительный. Ведь цель проверяющего (тестовика) - заставить программу сбиться.
Программы, как объекты тестирования, имеют ряд особенно стей, которые отличают процесс их тестирования от общепринято го, применяемого при разработке аппаратуры и других технических изделий. Особенностями тестирования ПС являются:
отсутствие эталона (программы), которому должна соответ ствовать тестируемая программа;
высокая сложность программ и принципиальная невозможность исчерпывающего тестирования;
практическая невозможность создания единой методики тестирования (формализация процесса тестирования) в силу большого разнообразия программных изделий (ПИ) по их сложности, функциональному назначению, области использования и т.д.
Тестирование - это процесс многократного выполнения программы с целью выявления ошибок. Целью тестирования является обнаружение максимального числа ошибок. Поэтому тестовый прогон, в результате которого не выявлено ошибок, считается неудач ным (неэффективным).
Технические требования разработки ПО 66
Требования к программному обеспечению — совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации. Создаются в процессе разработки требований к программному обеспечению, в результате анализа требований.
Требования могут выражаться в виде текстовых утверждений и графических моделей.
В классическом техническом подходе совокупность требований используется на стадии проектирования ПО. Требования также используются в процессе проверки ПО, так как тесты основываются на определённых требованиях.
Этапу разработки требований, возможно, предшествовало технико-экономическое обоснование, или концептуальная фаза анализа проекта. Фаза разработки требований может быть разбита на выявление требований (сбор, понимание, рассмотрение и выяснение потребностей заинтересованных лиц), анализ (проверка целостности и законченности), спецификация (документирование требований) и проверка правильности.
Виды требований по уровням
Бизнес-требования — определяют назначение ПО, описываются в документе о видении (vision) и границах проекта (scope).
Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе. Пользовательские требования могут выражаться в виде фраз утверждений, в виде способов применения (use case), пользовательских историй (user story), сценариев взаимодействия (scenario).
Функциональные требования — охватывают предполагаемое поведение системы, определяя действия, которые система способна выполнять. Описывается в системной спецификации (англ. system requirement specification, SRS).
Виды требований по характеру[править | править исходный текст]
Функциональный характер — требования к поведению системы
Бизнес-требования
Пользовательские требования
Функциональные требования
Нефункциональный характер — требования к характеру поведения системы
Бизнес-правила — определяют ограничения, проистекающие из предметной области и свойств автоматизируемого объекта (предприятия)
Системные требования и ограничения — определения элементарных операций, которые должна иметь система, а также различных условий, которым она может удовлетворять. К системным ограничениям относятся ограничения на программные интерфейсы, требования к атрибутам качества, требования к применяемому оборудованию и ПО.
Атрибуты качества
Внешние системы и интерфейсы
Ограничения
Техническое задание, как этап разработки программного обеспечения51
Техническое задание, как этап разработки программного обеспечения
- исходный документ для разработки информационных систем, стандартов либо проведения научно-исследовательских работ (НИР).
ТЗ содержит основные технические требования, предъявляемые к ПП; в ТЗ указываются назначение объекта, область его применения, стадии разработки конструкторской (проектной, технологической, программной и т.п.) документации, её состав, сроки исполнения и т. д., а также особые требования, обусловленные спецификой самого объекта либо условиями его эксплуатации.
ТЗ разрабатывается заказчиком для разработчика
Технологии доступа к данным64
Технологией доступа к данным называется система интерфейсов, обеспечивающая взаимодействие между приложением и базой данных. Во многих системах управления базами данных имеются библиотеки, содержащие интерфейсы прикладного программирования (application programming interface — API), представляющие собой функции, при помощи которых можно выполнять сданными те или иные действия.
Для того чтобы наиболее полно использовать возможности того или иного сервера баз данных, необходимо работать снам напрямую, через API. Однако это означает полную зависимость приложения от того пли иного сервера и сложность перехода на другую платформу, так как будет необходимо переписывать большое количество кода.
Этот вопрос призваны решить различные технологии доступа к данным. Они являются прослойкой между API конкретного сервера и приложением пользователя, предоставляя программисту простой унифицированный механизм работы с данными. На сегодняшний день существует множество технологий доступа к данным, таких как BDE, OLE, ODBC, ADO, и до сих пор разрабатываются новые, более надежные, удобные в работе и более быстродействующие технологии.
BDE
Фирма Borland разработала собственную технологию доступа к данным SQL Links, имеющую возможность взаимодействовать с ODBC через специальные «интерфейсы-мосты». Технология BDE является набором динамических библиотек, которые предоставляют интерфейсы, позволяющие передавать запросы на получение или модификацию данных из приложения в нужную базу данных и получать результат обработки. В процессе работы библиотеки используют вспомогательные файлы языковой поддержки и информацию о настройках среды.
Для разработчика BDE предоставляет множество преимуществ:
- непосредственный доступ к локальным базам данных (dBase, Paradox, текстовые файлы);
- доступ к SQL-серверам (Oracle, Sybase, MS SQL Server, InterBase, Informix,DB2) с помощью набора драйверов Borland SQL Links;
- доступ к любым источникам данных, имеющим драйвер ODBC (Open Data-Base Connectivity), например к файлам электронных таблиц (Excel, Lotus1-2-3), и серверам баз данных, не имеющим драйверов SQL Links (например, Gupta/Centura);
- создание приложений «клиент—сервер», использующих разнородные данные;
- использование SQL (Structured Query Language — язык запросов к серверным СУБД), в том числе и при работе с локальными данными;
- изоляцию приложения от средств языковой поддержки.
Технологии разработки кроссплатформенных приложений6
Разработка кроссплатформенных приложений предполагает однократное написание приложения и его развертывание на различных платформах.
Технология программирования как технология разработки надежного ПО46
В соответствии с обычным значением слова «технология» [6] под технологией программирования будем понимать совокупность производственных процессов, приводящую к созданию требуемого ПС, а также описание этой совокупности процессов. Другими словами, технологию программирования мы будем понимать здесь в широком смысле как технологию разработки программных средств, включая в нее все процессы, начиная с момента зарождения идеи этого средства, и, в частности, связанные с созданием необходимой программной документации. Каждый процесс этой совокупности базируется на использовании каких-либо методов и средств, например, компьютер (в этом случае будем говорить об компьютерной технологии программирования).
В литературе имеются и другие, несколько отличающиеся, определения технологии программирования. Эти определения обсуждаются в работе [7]. Используется в литературе и близкое к технологии программирования понятие программной инженерии, определяемой как систематический подход к разработке, эксплуатации, сопровождению и изъятию из обращения программных средств [7]. Именно программной инженерии (Software Engineering) посвящена упомянутая работа [3]. Главное различие между технологией программирования и программной инженерией как дисциплинами для изучения заключается в способе рассмотрения и систематизации материала. В технологии программирования акцент делается на изучении процессов разработки ПС (технологических процессов) и порядке их прохождения - методы и инструментальные средства разработки ПС используются в этих процессах (их применение и образуют технологические процессы). Тогда как в программной инженерии изучаются прежде всего методы и инструментальные средства разработки ПС с точки зрения достижения определенных целей — они могут использоваться в разных технологических процессах (и в разных технологиях программирования); как эти методы и средства образуют технологические процессы — здесь вопрос второстепенный.
Не следует также путать технологию программирования с методологией программирования [8]. Хотя в обоих случаях изучаются методы, но в технологии программирования методы рассматриваются «сверху» (с точки зрения организации технологических процессов), а в методологии программирования методы рассматриваются «снизу» (с точки зрения основ их построения). В работе [9, стр. 25] методология программирования определяется как совокупность механизмов, применяемых в процессе разработки программного обеспечения и объединенных одним общим философским подходом.
Имея ввиду, что надежность является неотъемлемым атрибутом ПС, мы будем обсуждать технологию программирования как технологию разработки надёжных ПС. Это означает, что, во-первых, мы будем обсуждать все процессы разработки ПС, начиная с момента возникновения замысла ПС. Во-вторых, нас будут интересовать не только вопросы построения программных конструкций, но и вопросы описания функций и принимаемых решений с точки зрения их человеческого (неформального) восприятия, и, наконец, в качестве продукта технологии мы будем принимать надежную (а не правильную) ПС. Все это будет существенно влиять на выбор методов и инструментальных средств в процессах разработки ПС.
Требования, предъявляемые к разработке технического задания52
Требования к автоматизированным функциям
При описании автоматизированных функций важно учесть полный перечень, того что должна делать система. Описание функций в техническом задании не является частью технического проекта, поэтому нужно описывать требования, а не алгоритм как это должно работать.
Требования к информационному обеспечению.
В некоторых проектах Заказчику важно, чтобы программное обеспечение обрабатывало определенные структуры данных или формировало отчеты четко определенного вида. Эти требования могут быть ключевыми в ходе выполнения проекта.
Требования к эргономике и технической эстетики
При практической работе очень часто возникает вопрос дизайна или пользовательского интерфейса. Некоторые заказчики ставят это на первое место в своей работе, так как иногда важна скорость работы оператора или внешний вид распространяемого программного продукта.
Требования к Программному обеспечению.
В этом пункте указываются требования к среде, где будет функционировать программное обеспечение: операционная система, сервер приложений, сервер баз данных. Это важно указывать для клиентского и серверного программного обеспечения.
Требования к лингвистическому обеспечению.
Часто бывает необходимость реализовать программное обеспечение на нескольких языках. Важно отметить, что могут различать требования к интерфейсу, хранению данных и документации. Часто можно разрабатывать программное обеспечение на нескольких языках, а данные хранятся только на одном языке.
Требования к надежности.
В Техническом Задании важно указывать предполагаемую нагрузку: количество пользователей, документов в системе, объема информации и так далее. Это позволяет более тщательно подойти к разработке архитектуры системы. Важно определить скорость работы системы параметром отклика системы.
Функциональная спецификация программного средства.40
С учетом назначения функциональной спецификации ПС и тяжелых последствий неточностей и ошибок в этом документе, функциональная спецификация должна быть математически точной. Это не означает, что она должна быть формализована настолько, что по ней можно было бы автоматически генерировать программы, решающие поставленную задачу. А означает лишь, что она должна базироваться на понятиях, построенных как математические объекты, и утверждениях, однозначно понимаемых разработчиками ПС. Достаточно часто функциональная спецификация формулируется на естественном языке. Тем не менее, использование математических методов и формализованных языков при разработке функциональной спецификации весьма желательно, поэтому этим вопросам будет посвящена отдельная лекция.
Функциональная спецификация состоит из трех частей:
описания внешней информационной среды, к которой должны применяться программы разрабатываемой ПС;
определение функций ПС, определенных на множестве состояний этой информационной среды (такие функции будем называть внешними функциями ПС);
описание нежелательных (исключительных) ситуаций, которые могут возникнуть при выполнении программ ПС, и реакций на эти ситуации, которые должны обеспечить соответствующие программы.
В первой части должны быть определены на концептуальном уровне все используемые каналы ввода и вывода и все информационные объекты, к которым будет применяться разрабатываемое ПС, а также существенные связи между этими информационными объектами. Примером описания информационной среды может быть концептуальная схема базы данных или описание сети датчиков и приборов, которой должна управлять разрабатываемая ПС.
Во второй части вводятся обозначения всех определяемых функций, специфицируются все входные данные и результаты выполнения каждой определяемой функции, включая указание их типов и заданий всех соотношений (или ограничений), которым должны удовлетворять эти данные и результаты. И, наконец, определяется семантика каждой из этих функций, что является наиболее трудной задачей функциональной спецификации ПС. Обычно эта семантика описывается неформально на естественном языке - примерно так, как это делается при описании семантики многих языков программирования. Эта задача может быть в ряде случаев существенно облегчена при достаточно четком описании внешней информационной среды, если внешние функции задают какие-либо манипуляции с ее объектами.
В третьей части должны быть перечислены все существенные с точки зрения внешнего наблюдателя (пользователя) случаи, когда ПС не сможет нормально выполнить ту или иную свою функцию (например, при обнаружении ошибки во время взаимодействия с пользователем, или при попытке применить какую-либо функцию к данным, не удовлетворяющим соотношениям, указанным в ее спецификации, или при получении результата, нарушающего заданное ограничение). Для каждого такого случая должна быть определена (описана) реакция ПС.
Эволюция программных систем15
Эволюция архитектур управляющих систем начиналась с однопользовательских настольных приложений, когда информационная система работала под управлением одного компьютера и использовала собственную систему управления базами данных, интегрированную в код программы. Одновременная работа нескольких пользователей с такой системой была невозможна. Кроме того, при увеличении объемов данных такая система становилась неработоспособной, т.к. использование простых СУБД не позволяло эффективно управлять данными.
Время шло, такие однопользовательские системы уже не могли удовлетворять растущие запросы большого бизнеса. Решить проблему одновременной работы нескольких пользователей были призваны двухуровневые клиент-серверные системы. В таких системах приложение разбивается на 2 части: систему управления базами данных (СУБД) и собственно клиентское приложение. СУБД обычно ставилась на выделенный компьютер - сервер, к которому по сети (локальной или глобальной) подключались клиентские приложения. При этом «общение» между клиентом и СУБД происходило на языке SQL – языке управления данными.
Дальнейшее развитие требований к управляющим системам привело к возникновению трехуровневой архитектуры клиент-сервер:
Презентация – используется для формирования графического интерфейса пользователя.
Сервер приложений – используется для выполнения программ бизнес-логики.
СУБД – используется для управления базами данных.
Все программы бизнес-логики выполняются на сервере приложений. Написанные на каком либо языке, эти программы обращаются к СУБД, получают данные, обрабатывают их, а затем формируют графический интерфейс и отсылают его на уровень презентации. Использование внутреннего языка позволяет сосредоточиться на проблемах бизнес-логики, а не на вопросах взаимодействия между компонентами системы. Это понижает трудоемкость решаемой задачи, уменьшает время создания законченного решения и, в конечном итоге, снижает совокупную стоимость владения системой.
Языки программирования, классификация, назначение.36
Существуют различные классификации языков программирования.По наиболее распространенной классификации все языки программирования, в соответствии с тем, в каких терминах необходимо описать задачу, делят на языки низкого и высокого уровня.Если язык близок к естественному языку программирования, то он называется языком высокого уровня, если ближе к машинным командам, – языком низкого уровня.В группу языков низкого уровня входят машинные языки и языки символического кодирования: Автокод, Ассемблер. Операторы этого языка – это те же машинные команды, но записанные мнемоническими кодами, а в качестве операндов используются не конкретные адреса, а символические имена. Все языки низкого уровня ориентированы на определенный тип компьютера, т. е. являются машинно–зависимыми.Машинно–ориентированные языки – это языки, наборы операторов и изобразительные средства которых существенно зависят от особенностей ЭВМ (внутреннего языка, структуры памяти и т.д.).К языкам программирования высокого уровня относят Фортран (переводчик формул – был разработан в середине 50–х годов программистами фирмы IBM и в основном используется для программ, выполняющих естественно – научные и математические расчеты), Алгол, Кобол (коммерческий язык – используется, в первую очередь, для программирования экономических задач), Паскаль, Бейсик (был разработан профессорами Дармутского колледжа Джоном Кемени и Томасом Курцом.), Си (Деннис Ритч – 1972 году), Пролог (в основе языка лежит аппарат математической логики) и т.д.Эти языки машинно–независимы, т.к. они ориентированы не на систему команд той или иной ЭВМ, а на систему операндов, характерных для записи определенного класса алгоритмов. Однако программы, написанные на языках высокого уровня, занимают больше памяти и медленнее выполняются, чем программы на машинных языках.Программу, написанную на языке программирования высокого уровня, ЭВМ не понимает, поскольку ей доступен только машинный язык. Поэтому для перевода программы с языка программирования на язык машинных кодов используют специальные программы – трансляторы.Существует три вида транслятора: интерпретаторы (это транслятор, который производит пооператорную обработку и выполнение исходного кода программы), компиляторы (преобразует всю программу в модуль на машинном языке, после чего программа записывается в память компьютера и лишь потом исполняется) иассемблеры (переводят программу, записанную на языке ассемблера, в программу на машинном языке).Языки программирования также можно разделять на поколения:
– языки первого поколения: машинно–ориентированные с ручным управлением памяти на компьютерах первого поколения.– языки второго поколения: с мнемоническим представлением команд, так называемые автокоды.– языки третьего поколения: общего назначения, используемые для создания прикладных программ любого типа. Например, Бейсик, Кобол, Си и Паскаль.– языки четвертого поколения: усовершенствованные, разработанные для создания специальных прикладных программ, для управления базами данных.– языки программирования пятого поколения: языки декларативные, объектно–ориентированные и визуальные. Например, Пролог, ЛИСП (используется для построения программ с использованием методов искусственного интеллекта), Си++, Visual Basic, Delphi.Языки программирования также можно классифицировать на процедурные и непроцедурные.В процедурных языках программа явно описывает действия, которые необходимо выполнить, а результат задается только способом получения его при помощи некоторой процедуры, которая представляет собой определенную последовательность действий.Среди процедурных языков выделяют в свою очередь структурные и операционные языки. В структурных языках одним оператором записываются целые алгоритмические структуры: ветвления, циклы и т.д. В операционных языках для этого используются несколько операций. Широко распространены следующие структурные языки: Паскаль, Си, Ада, ПЛ/1. Среди операционных известны Фортран, Бейсик, Фокал.Непроцедурное (декларативное) программирование появилось в начале 70-х годов 20 века, К непроцедурному программированию относятся функциональные и логические языки.В функциональных языках программа описывает вычисление некоторой функции. Обычно эта функция задается как композиция других, более простых, те в свою очередь делятся на еще более простые задачи и т.д. Один из основных элементов функциональных языков – рекурсия. Оператора присваивания и циклов в классических функциональных языках нет.В логических языках программа вообще не описывает действий. Она задает данные и соотношения между ними. После этого системе можно задавать вопросы. Машина перебирает известные и заданные в программе данные и находит ответ на вопрос. Порядок перебора не описывается в программе, а неявно задается самим языком. Классическим языком логического программирования считается Пролог. Программа на Прологе содержит, набор предикатов–утверждений, которые образуют проблемно–ориентированную базу данных и правила, имеющие вид условий.Можно выделить еще один класс языков программирования – объектно–ориентированные языки высокого уровня. На таких языках не описывают подробной последовательности действий для решения задачи, хотя они содержат элементы процедурного программирования. Объектно–ориентированные языки, благодаря богатому пользовательскому интерфейсу, предлагают человеку решить задачу в удобной для него форме.Первый объектно-ориентированный язык программирования Simula был создан в 1960-х годах Нигаардом и Далом.Ява – язык для программирования Internet, позволяющий создавать безопасные, переносимые, надежные, объектно–ориентированные интерактивные программы. Язык Ява жестко связан с Internet, потому, что первой серьезной программой, написанной на этом языке, был браузер Всемирной паутины.В последнее время, говоря о программировании в Internet, часто имеют в виду создание публикаций с использованием языка разметки гипертекстовых документов HTML. Применение специальных средств (HTML–редакторов) позволяет не только создавать отдельные динамически изменяющиеся интерактивные HTML–документы, используя при этом данные мультимедиа, но и редактировать целые сайты.