Разработка программного модуля

При разработке программного модуля целесообразно придерживаться следующего порядка :

• изучение и проверка спецификации модуля, выбор языка  программирования;
• выбор алгоритма и структуры данных;
• программирование модуля;
• шлифовка текста модуля;
• проверка модуля;
• компиляция модуля.

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

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

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

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

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

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

6.3. Пошаговая детализация и понятие о псевдокоде.

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

Для начального периода развития программотехники, когда программы были штучным продуктом, характерен стиль программирования, который впоследствии получил название “хаотическое” программирование. Суть его в том, чтобы из операторов языка программирования сконструировать программу, выполняющую некоторое (заданное) преобразование данных. Ни набор операторов, ни порядок их применения никак не регламентировался.

Главный недостаток разработанного таким образом ПО – большие трудности его сопровождения. В конце 60-х начале 70-х годов в сфере ПО обозначились трудности, порожденные расширением области применения компьютеров. Возросшая мощность вычислительной техники и появление языков высокого уровня позволили приступить к автоматизации процессов, с которыми люди перестали справляться или к которым еще не приступали из-за их высокой вычислительной сложности. Примерами таких задач могут служить автоматизированные системы управления безопасностью полетов или управления движением по железнодорожным магистралям. Такие системы разрабатывались в течение месяцев и лет. Стоимость ПО доходила до 80% всех затрат, однако обеспечить требуемый уровень их надежности не всегда удавалось.

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

Перечислим эти принципы:

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

Это позволяет максимально упростить стыковку модулей в программе.

1. В программах рекомендуется применять  4 типа конструкций:

а)  последовательность (модулей, операторов)

б)  разветвление (условный оператор)

Перечеркивание означает, что Q может отсутствовать.

в)  цикл

1)       с предусловием

2)       с постусловием

г)  выбор из нескольких альтернатив (или переключатель)

3)        разработку программ рекомендуется вести сверху – вниз или по нисходящей стратегии.

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

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

Объектно-ориентированный стиль программирования основан на объектном моделировании задачи. Здесь происходит поворот “от процедуры и от структур данных к объекту”, представляющему собой целостную модель и естественную имитацию деятельности некоторого элемента реального мира. Он во многом снимает недостатки предшествующих стилей программирования, обеспечивает компактность текстов и кодов программ, устойчивость и эволюционное развитие программ через видовую специализацию программных объектов без их изменения и позволяет преодолеть новый уровень сложности разрабатываемых систем. Следует отметить, что этот стиль является логическим продолжением развития процедурно- и потоко-ориентированного программирования, получившего широкое распространение в начале 90-х годов.

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

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

Понятия ООП

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

ПЕРЕМЕННАЯ         ТИП           ПРОЦЕДУРА         ВЫЗОВ ПРОЦЕДУРЫ

ОБЪЕКТ                КЛАСС        МЕТОД                    СООБЩЕНИЕ

Итак, ООП – это подход, в котором данные и поведение (методы обработки данных) жестко связаны. Данные и поведение представлены в виде классов, экземпляры которых – объекты. ООП позволяет пользователю вводить собственные типы данных, расширяя тем самым набор встроенных в язык типов данных.

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

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

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

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

Сокрытие данных обеспечивается ключевым словом class и ключевыми словами, связанными с правами доступа: public, private и protected. Класс - это способ инкапсуляции типов данных и связанных с ними функций. Разрешение частной (private) и общей (public) видимости для членов класса дает программисту возможность управлять тем, какие части структуры данных будут модифицируемы. Private части скрыты от кода пользователя, a public – доступны. Члены класса со статусом доступа protected занимают промежуточное положение: они доступны как внутри класса, так и во всех производных от него классах.

Достоинства и недостатки ООП

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

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

• Данные и операции вместе образуют определенную сущность, и они не «размываются» по всей программе, как это нередко бывает в случае процедурного программирования.

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

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

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