Конспект лекций по предмету «ПМ.01 РАЗРАБОТКА МОДУЛЕЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ КОМПЬЮТЕРНЫХ СИСТЕМ». Конспект лекций по предмету_ «ПМ.01 РАЗРАБОТКА МОДУЛЕЙ ПРОГРАММН. Конспект лекций по предмету ПМ. 01 Разработка модулей программного обеспечения для компьютерных систем
 Скачать 363 Kb.
|
|
Конспект лекций по предмету: «ПМ.01 РАЗРАБОТКА МОДУЛЕЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ КОМПЬЮТЕРНЫХ СИСТЕМ»  Разработал: преподаватель Косяченко Наталья Петровна 2020 Введение. Требования к современным технологиям. Программное средство (ПС) – это программа или логически связанная совокупность программ на носителях данных, снабженная программной документацией. Программная документация позволяет понять, какие функции выполняет та или иная программа, как подготовить исходные данные и запустить требуемую программу в процесс ее выполнения, а также: что означают получаемые результаты (или каков эффект выполнения этой программы). Будем считать, что в ПС имеется ошибка, если оно не выполняет функции, описанные в документации по ее применению. Надежность ПС - это его способность безотказно выполнять определенные функции при заданных условиях в течение заданного периода времени с достаточно большой вероятностью. Технология программирования – это система научно-обоснованных принципов, методов и средств, обеспечивающих создание и развитие ПС, в течении всего жизненного периода (жизненного цикла) программного средства. Состав технологии программирования: принципы и методы организации труда при разработке, эксплуатации ПС; принципы и методы разработки самих программ; средства инструментальной поддержки и автоматизации, позволяющие унифицировать разработку ПС. Жизненный цикл ПС Жизненный цикл ПС - период его разработки и эксплуатации (использования), начиная от момента возникновения замысла ПС и заканчивая прекращением всех видов его использования.  Внешнее описаниеПС является описанием его поведения с точки зрения внешнего по отношению к нему наблюдателю с фиксацией требований относительно его качества. Внешнее описание ПС начинается с определения требований к ПС со стороны пользователей (заказчика). КонструированиеПС охватывает процессы: разработку архитектуры ПС, разработку структур программ ПС и их детальную спецификацию. Кодирование: создание текстов программ на языке программирования, их отладка и тестирование ПС. На этапе аттестации ПС производится оценка качества ПС, после успешного завершения которого, разработка ПС считается законченной. Программное изделие (ПИ) - экземпляр или копия, снятая с разработанного ПС. Изготовление ПИ - это процесс генерации и/или воспроизведения (снятия копии) программ и программных документов ПС с целью их поставки пользователю для применения по назначению. Производство ПИ - это совокупность работ по обеспечению изготовления требуемого количества ПИ в установленные сроки. Стадия производства ПС в жизненном цикле ПС является, по-существу, вырожденной (не существенной), так как представляет рутинную работу, которая может быть выполнена автоматически и без ошибок. Стадия эксплуатации ПС охватывает процессы хранения, внедрения и сопровождения ПС, а также транспортировки и применения ПИ по своему назначению. Она состоит из двух параллельно проходящих фаз: фазы применения ПС и фазы сопровождения ПС. Применение ПС - это использование ПС для решения практических задач на компьютере путем выполнения ее программ. Сопровождение ПС - это процесс сбора информации о его качестве в эксплуатации, устранения обнаруженных в нем ошибок, его доработки и модификации, а также извещения пользователей о внесенных в него изменениях. Понятие качества ПС. Качество ПС - это совокупность его черт и характеристик, которые влияют на его способность удовлетворять заданные потребности пользователей. Качество ПС является удовлетворительным, когда оно обладает указанными свойствами в такой степени, чтобы гарантировать успешное его использование. Критерии качества ПС: функциональность, надежность, легкость применения, эффективность, сопровождаемость, мобильность. Функциональность - это способность ПС выполнять набор функций, удовлетворяющих заданным или подразумеваемым потребностям пользователей. Набор указанных функций определяется во внешнем описании ПС. Легкость применения - это характеристики ПС, которые позволяют минимизировать усилия пользователя по подготовке исходных данных, применению ПС и оценке полученных результатов, а также вызывать положительные эмоции определенного или подразумеваемого пользователя. Эффективность - это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов. Сопровождаемость - это характеристики ПС, которые позволяют минимизировать усилия по внесению изменений для устранения в нем ошибок и по его модификации в соответствии с изменяющимися потребностями пользователей. Мобильность - это способность ПС быть перенесенным из одной среды (окружения) в другую, в частности, с одной ЭВМ на другую. Обязательные критерии качества: функциональность и надежность. Разработка структуры программы и модульное программирование Приступая к разработке каждой программы ПС, следует иметь ввиду, что она является большой системой, поэтому нужно принимать меры для ее упрощения. Для этого программу разрабатывают по частям, которые называются программными модулями. Такой метод программирования называют модульным программированием. Модуль – это самостоятельная часть программы, имеющая определенное значение и обеспечивающая заданные функции обработки автономно от других программных модулей. Каждый программный модуль программируется, компилируется и отлаживается отдельно от других модулей программы, и тем самым физически разделен с другими программными модулями. Каждый программный модуль может включаться в состав разных программ, если выполнены условия его использования, описанные в документации по ее использованию. Т.е. хорошо продуманный модуль позволяет избежать дублирования в программировании. Любое ПС имеет свою структуру, которая разрабатывается для удобства: разработки программирования отладки внесения изменений Также структуризация ПС позволяет: распределить работы по исполнителям, обеспечив их загрузку и требуемые сроки разработки построить календарные графики проектных работ и осуществлять их координацию в процессе создания ПИ. контролировать трудозатраты и стоимость проектных работ. При создании ПС выделяются многократно используемые модули, их типизируют и унифицируют, за счет чего сокращаются сроки и трудозатраты на разработку ПС в целом. Некоторые ПС используют готовые модули из библиотек стандартных процедур, функций, объектов и методов обработки данных. Типовая структура ПС:   Типы модулей:
Свойства модуля: один вход и один выход – на входе программный модуль получает определенный набор исходных данных, выполняет обработку данных и возвращает результат функциональная завершенность – модуль выполняет перечень операций для реализации каждой отдельной функции в полном составе. логическая независимость – результат работы модуля зависит только от исходных данных, и не зависит от работы других модулей. слабые информационные связи с другими программными модулями – обмен информации между модулями должен быть по возможности минимизирован. обозримый по размеру и сложности. Каждый модуль состоит из спецификации и тела модуля. Спецификация – правила использования модуля. Тело – способ реализации процесса обработки. Принцип модульного программирования ПС: Определение состава и подчиненность функций определение набора программных модулей, реализующих эти функции При составлении алгоритма необходимо учитывать: каждый модуль вызывается на выполнение вышестоящим модулем и закончив работу, возвращает управление вызвавшему модулю. Методы разработки структуры программы. В качестве модульной структуры программы принято использовать древовидную структуру, включая деревья со сросшимися ветвями. В узлах дерева размещаются модули, а стрелки показывают подчиненность модулей (т.е. в тексте модуля, из которого она исходит, имеется ссылка на модуль, в который она входит). Модульная структура программы должна включать и совокупность спецификаций модулей, образующих эту программу. Спецификация программного модуля содержит: синтаксическую спецификацию его входов, позволяющую построить обращение к нему на используемом языке программирования функциональную спецификацию модуля (описание всех функций, выполняемых этим модулем). Существуют разные методы разработки структуры программы. Обычно используют 2 метода: Метод восходящей разработки метод нисходящей разработки Метод восходящей разработки. Сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модулей самого нижнего уровня, в таком порядке, чтобы для каждого программируемого модуля были уже запрограммированы все модули, к которым он может обращаться. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в принципе в таком же (восходящем) порядке, в каком велось их программирование. На первый взгляд такой порядок разработки программы кажется вполне естественным: каждый модуль при программировании выражается через уже запрограммированные непосредственно подчиненные модули, а при тестировании использует уже отлаженные модули. Не рекомендуется, т.к.: для программирования какого-либо модуля совсем не требуется текстов используемых им модулей - для этого достаточно, чтобы каждый используемый модуль был лишь специфицирован (в объеме, позволяющем построить правильное обращение к нему), а для тестирования его возможно используемые модули заменять их имитаторами (заглушками). каждая программа в какой-то степени подчиняется некоторым внутренним для нее, но глобальным для ее модулей соображениям (принципам реализации, предположениям, структурам данных и т.п.), что определяет ее концептуальную целостность и формируется в процессе ее разработки. При восходящей разработке эта глобальная информация для модулей нижних уровней еще не ясна в полном объеме, поэтому очень часто приходится их перепрограммировать. при восходящем тестировании для каждого модуля (кроме головного) приходится создавать ведущую программу (модуль), которая должна подготовить для тестируемого модуля необходимое состояние информационной среды и произвести требуемое обращение к нему. Это приводит к большому объему "отладочного" программирования и в то же время не дает никакой гарантии, что тестирование модулей производилось именно в тех условиях, в которых они будут выполняться в рабочей программе. Метод нисходящей разработки. Сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модуля самого верхнего уровня (головного), переходя к программированию какого-либо другого модуля только в том случае, если уже запрограммирован модуль, который к нему обращается. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в таком же (нисходящем) порядке. Положительные стороны При таком порядке разработки программы вся необходимая глобальная информация формируется своевременно, т.е. ликвидируется весьма неприятный источник просчетов при программировании модулей. Существенно облегчается и тестирование модулей, производимое при нисходящем тестировании программы. Первым тестируется головной модуль программы, который представляет всю тестируемую программу и поэтому тестируется при "естественном" состоянии информационной среды, при котором начинает выполняться эта программа. При этом все модули, к которым может обращаться головной, заменяются на их имитаторы. Имитатор модуля - простой программный фрагмент, сигнализирующий, о самом факте обращения к имитируемому модулю с необходимой для правильной работы программы обработкой значений его входных параметров и с выдачей, если это необходимо, заранее запасенного подходящего результата. После завершения тестирования и отладки головного и любого последующего модуля производится переход к тестированию одного из модулей, которые в данный момент представлены имитаторами, если таковые имеются. Для этого имитатор выбранного для тестирования модуля заменяется на сам этот модуль и добавляются имитаторы тех модулей, к которым может обращаться выбранный для тестирования модуль. При этом каждый такой модуль будет тестироваться при "естественных" состояниях информационной среды, возникающих к моменту обращения к этому модулю при выполнении тестируемой программы. Таким образом большой объем "отладочного" программирования заменяется программированием достаточно простых имитаторов используемых в программе модулей. Кроме того, имитаторы удобно использовать для подыгрывания процессу подбора тестов путем задания нужных результатов, выдаваемых имитаторами. Рассмотренные методы называются классическими. В них модульная древовидная структура программы должна разрабатываться до начала программирования модулей. Однако такой подход вызывает ряд возражений: маловероятно, чтобы до программирования модулей можно было разработать структуру программы достаточно точно и содержательно. При конструктивном и архитектурном подходах к разработке программ модульная структура формируется в процессе программирования модулей. Конструктивный подход (Модификация нисходящей разработки) Модульная древовидная структура программы формируется в процессе программирования модуля. Сначала программируется головной модуль, исходя из спецификации программы в целом, причем спецификация программы является одновременно и спецификацией ее головного модуля, так как последний полностью берет на себя ответственность за выполнение функций программы. В процессе программирования головного модуля, в случае, если эта программа достаточно большая, выделяются внутренние функции, в терминах которых программируется головной модуль. Это означает, что для каждой выделяемой функции создается спецификация реализующего ее фрагмента программы, который в дальнейшем может быть представлен некоторым поддеревом модулей. Важно заметить, что здесь также ответственность за выполнение выделенной функции берет головной (может быть, и единственный) модуль этого поддерева, так что спецификация выделенной функции является одновременно и спецификацией головного модуля этого поддерева. В головном модуле программы для обращения к выделенной функции строится обращение к головному модулю указанного поддерева в соответствии с созданной его спецификацией. Таким образом, на первом шаге разработки программы (при программировании ее головного модуля) формируется верхняя начальная часть дерева, например, такая, которая показана на рис. 7.1.  Первый шаг формирования модульной структуры программы при конструктивном подходе. Аналогичные действия производятся при программировании любого другого модуля, который выбирается из текущего состояния дерева программы из числа специфицированных, но пока еще не запрограммированных модулей. В результате этого производится очередное доформирование дерева программы, например, такое, которое показано на рис. 7.2. Архитектурный подход (модификация восходящей разработки) Модульная структура программы формируется в процессе программирования модуля. Но при этом ставится другая цель разработки: повышение уровня используемого языка программирования, а не разработка конкретной программы. Это означает, что для заданной предметной области выделяются типичные функции, каждая из которых может использоваться при решении разных задач в этой области, и специфицируются, а затем и программируются отдельные программные модули, выполняющие эти функции. Так как процесс выделения таких функций связан с накоплением и обобщением опыта решения задач в заданной предметной области, то обычно сначала выделяются и реализуются отдельными модулями более простые функции, а затем постепенно появляются модули, использующие ранее выделенные функции. Такой набор модулей создается в расчете на то, что при разработке той или иной программы заданной предметной области в рамках конструктивного подхода могут оказаться приемлемыми некоторые из этих модулей. Это позволяет сократить трудозатраты на разработку конкретной программы путем подключения к ней заранее заготовленных и проверенных на практике модульных структур нижнего уровня. Так как такие структуры могут многократно использоваться в разных конкретных программах, то архитектурный подход может рассматриваться как путь борьбы с дублированием в программировании. В связи с этим программные модули, создаваемые в рамках архитектурного подхода, обычно параметризуются для того, чтобы усилить применимость таких модулей путем настройки их на параметры.  Второй шаг формирования модульной структуры программы при конструктивном подходе. Метод нисходящей реализации. Каждый запрограммированный модуль начинают сразу же тестировать до перехода к программированию другого модуля. Разработка программного модуля. Структурное программирование. Порядок разработки программного модуля.изучение и проверка спецификации модуля, выбор языка программирования; (т.е. разработчик изучая спецификацию выясняет понятна она ему или нет, достаточно ли полно она описывает модуль; затем он выбирает язык программирования, на котором будет написан модуль, хотя язык программирования может быть единым для всего ПС) выбор алгоритма и структуры данных (здесь выясняется не известны ли какие-либо алгоритмы для решения поставленной задачи и если есть, то воспользоваться им) программирование модуля (написание кода программы) шлифовка текста модуля (редактирование имеющихся комментариев, добавление дополнительных комментариев, для того чтобы обеспечить требуемое качество) проверка модуля (проверяется логика работы модуля, отлаживается его работа) Применяются следующие методы контроля программного модуля: статическая проверка текста модуля (текст прочитывается с начала до конца с целью найти ошибки в модуле. Обычно для такой проверки привлекают, кроме разработчика модуля, еще одного или даже нескольких программистов. Рекомендуется ошибки, обнаруживаемые при такой проверке исправлять не сразу, а по завершению чтения текста модуля) сквозное прослеживание (вручную прокручивается выполнение модуля (оператор за оператором в той последовательности, какая вытекает из логики работы модуля) на некотором наборе тестов) компиляция модуля. Структурное программирование.На сегодняшний день самой популярной методикой программирования является структурное программирование «сверху-вниз». Структурное программирование – это процесс пошагового разбиения алгоритма на все более мелкие части, с целью получить такие элементы, для которых можно легко написать конкретные предписания. Два принципа структурного программирования: последовательная детализация «сверху – вниз» ограниченность базового набора структур для построения алгоритмов любой степени сложности Требования структурного программирования: программа должна составлятся мелкими шагами, таким образом сложная задача разбивается на достаточно простые, легко воспринимаемые части логика программы должна опираться на минимальное число достаточно базовых управляющих структур (линейные, разветвляющиеся и циклические структуры) Основные свойства и достоинства структурного программирования: уменьшение сложности программ возможность демонстрации правильности программ на различных этапах решения задачи наглядность программ простота модификации (внесения изменения) программ. Современные средства программирования должны обеспечивать максимальную защиту от возможных ошибок разработчика. Тут можно провести аналогию с развитием методов управления автотранспортом. Сначала безопасность обеспечивалась за счет разработки правил движения. Затем появилась система разметки дорог и регулирования перекрестков. И, наконец, стали строиться транспортные развязки, которые в принципе предотвращают пересечение потоков машин и пешеходов. Впрочем, используемые средства должны определяться характером решаемой задачи: для проселочной дороги вполне достаточно соблюдения простого правила - "смотри под ноги и по сторонам". Основная идея структурного программирования: программа должна представлять собой множество блоков, объединенных в виде иерархической древовидной структуры, каждый из которых имеет один вход и один выход. Любую программу можно построить, используя лишь три основных типа блоков: функциональный блок - отдельный линейный оператор или их последовательность; блок разветвления - If <условие> Then...Else. обобщенный цикл - конструкция типа While <условие> Do <операторы> (проверка в начале цикла!);  Существенно, что каждая из этих конструкций имеет по управлению только один вход и один выход. Тем самым, и обобщенный оператор имеет только один вход и один выход. Структурное программирование иногда называют еще "программированием без GO TO". Однако дело здесь не в операторе GO TO, а в его беспорядочном использовании. Очень часто при воплощении структурного программирования на некоторых языках программирования оператор перехода (GO TO) используется для реализации структурных конструкций, не снижая основных достоинств структурного программирования. Запутывают программу как раз "неструктурные" операторы перехода, особенно переход на оператор, расположенный в тексте модуля выше (раньше) выполняемого оператора перехода. Тем не менее, попытка избежать оператора перехода в некоторых простых случаях может привести к слишком громоздким структурированным программам, что не улучшает их ясность и содержит опасность появления в тексте модуля дополнительных ошибок. Поэтому можно рекомендовать избегать употребления оператора перехода всюду, где это возможно, но не ценой ясности программы. К полезным случаям использования оператора перехода можно отнести выход из цикла или процедуры по особому условию, "досрочно" прекращающего работу данного цикла или данной процедуры, т.е. завершающего работу некоторой структурной единицы (обобщенного оператора) и тем самым лишь локально нарушающего структурированность программы. Большие трудности (и усложнение структуры) вызывает структурная реализация реакции на возникающие исключительные (часто ошибочные) ситуации, так как при этом требуется не только осуществить досрочный выход из структурной единицы, но и произвести необходимую обработку этой ситуации (например, выдачу подходящей диагностической информации). Обработчик исключительной ситуации может находиться на любом уровне структуры программы, а обращение к нему может производиться с разных нижних уровней. Вполне приемлемой с технологической точки зрения является следующая "неструктурная" реализация реакции на исключительные ситуации. Обработчики исключительных ситуаций помещаются в конце той или иной структурной единицы и каждый такой обработчик программируется таким образом, что после окончания своей работы производит выход из той структурной единицы, в конце которой он помещен. Обращение к такому обработчику производится оператором перехода из данной структурной единицы (включая любую вложенную в нее структурную единицу). Вообще говоря, главное в структурном программировании - грамотное составление правильной логической схемы программы, реализация которой языковыми средствами - дело вторичное. Стиль программирования. Выбор языка программирования. Программы должны составляться так, чтобы их могли прочитать в первую очередь люди, а не машины. Помните: программы читаются людьми, т.е. удобочитаемость программ - существенна, поэтому имеет смысл говорить о стандарте стиля программ. Легко читаемая программа создает впечатление, что ее автор хорошо знал что делал. Программа должна передавать логику и структуру алгоритма настолько, насколько это возможно. Один из аргументов против стандартизации стиля программирования звучит так: стиль программирования – это дело личного мнения и вкуса, поэтому не следует вводить на него каких – либо ограничений – этот аргумент, в сущности, утверждает, что хаос лучше порядка. Правило стандартизации стиля: если существует более одного способа сделать что – либо и выбор произвольный, остановись на одном способе и всегда его придерживайся. Легче избежать путаницы, придерживаясь стандартных приемов, хороший набор стандартных приемов позволяет сконцентрировать внимание на главной задаче. Невозможно выработать единого промышленного стандарта для всех программ, но в пределах единого проекта, задачи, разработки – это нормальное явление. Комментарии: Желательность комментариев очевидна. Программы с пояснительными комментариями значительно легче отслеживать, читая чужую программу, программисты не мало времени отслеживают логику чужой программы, т.е. не комментируемая программа – свидетельство делитанского похода. Когда следует писать комментарий? В процессе написания программы. Бессмысленно вставлять комментарии, после того, как программа завершена. Делайте комментариев больше, чем это кажется необходимым. Т.к. цель комментариев – облегчить понимание программы. Если вы затрудняетесь в написание комментария – значит “Вы не ведаете, что творите! ” Три типа комментариев: вводные оглавление пояснительные. Вводные комментарии: Каждая программа, подпрограмма или процедура, должна начинаться с комментариев, поясняющих, что она делает. Минимальная информация, содержащаяся в вводных комментариях должна включать следующие пункты: Назначение программы. Указания по вызову программы и ее использованию. Список и назначение основных переменных или массивов. Указание по вводу – выводу. Список всех файлов. Список используемых подпрограмм. Назначение применяемых математических методов. (иногда) Сведения о времени выполнения программы. Требуемый объем памяти. Специальные указания оператору. Сведения об авторе. Дату написания программы. Пояснительный комментарий: Пояснениями нужно сопровождать те части программы, которые трудно понять без комментариев. Сопровождайте комментариями те действия, которые, с вашей точки зрения, могут быть не совсем понятны другому. Комментарии не должны объяснять синтаксис языка программирования, а должны раскрывать логику программы или цель конкретного действия. Если логика программы понятна только на основании прочтения комментариев, это качественные комментарии. Расположение комментариев. Комментарии легче читаются, если они отделяются пустыми строками (до и после комментариев). Дополнительный метод выделения комментариев – заключение их в прямоугольник из специальных символов (звездочки, слеши, скобки и т.д.). Располагаются комментарии т.о., чтобы это не делало программу менее наглядной. Неправильные комментарии хуже, чем их отсутствие. Делайте пробелы для улучшения читаемости программ. |