">
Информатика Программирование
Информация о работе

Тема: Методы и искусство программирования

Описание: Машинно-ориентированное, процедурное, структурное, модульное, объектно-ориентированное программирование. Обобщенные технологии разработки приложений. Основные характеристики программного модуля. Методы разработки структуры. Пример комментария.
Предмет: Информатика.
Дисциплина: Программирование.
Тип: Курсовая работа
Дата: 25.08.2012 г.
Язык: Русский
Скачиваний: 52
Поднять уникальность

Похожие работы:

Курсовая работа

по дисциплине:

«Технология разработки программных продуктов »

на тему: «Методы и искусство программирования»

Выполнил:

Проверил:

2012

Содержание

1. Ведение……………………………………………………………………....3

2. Методы и искусство программирования…………………………………..5

2.1. Модульное программирование…………………………………..……5

2.1.1. Основные характеристики программного модуля……………..6

2.1.2. Методы разработки структуры модульной программы….…....9

2.1.3. Метод восходящей разработки……………………..……….…..10

2.1.4. Метод нисходящей разработки…………………………...….....11

2.2. Структурное программирование………….…………………....….…..12

2.3.Объектно-ориентированное программирование…………………..…15

2.4.Основные методы разработки приложений……..……………….……18

3. Практическая часть………………………………………………….........20

4.Заключение…………………………………………………………….......32

5.Литература…………………………………………….……………..….…33

1.Введение

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

Машинно-ориентированное программирование появилось одновременно с созданием электронных вычислительных машин. Сначала это были программы в машинных кодах, затем появился язык программирования Assembler (Автокод), который немного «очеловечил» написание программы в машинном коде. Этот стиль программирования предполагает доскональное знание возможностей конкретной архитектуры ЭВМ и операционной системы и используется до сих пор тогда, когда другие стили бессильны, или нужно получить максимальное быстродействие в рамках той или иной операционной системы с использованием архитектуры данной ЭВМ.

Процедурное программирование. Основная идея этого стиля – алгоритмизация процесса решения задачи и выбор наилучшего алгоритма (по расходу памяти или по быстродействию). Реализация этой идеи началась с 1957 года с появлением алгоритмических языков Fortran и затем Algol-60, когда все большее и большие число специалистов занялось решением достаточно сложных инженерных и научных задач. И нужен был стиль программирования максимально близкий к человеческому (математическому) стилю. При этом знание тонкостей архитектуры ЭВМ не требовалось. Программа на алгоритмическом языке (при наличии соответствующих трансляторов) должна была в идеале работать на ЭВМ любой архитектуры. Но это были программы прикладные. Разработку же системных программ (самих трансляторов, систем ввода-вывода) по-прежнему надо было делать на Ассемблере.

Структурное программирование. Здесь основная идея прекрасно выражена Н. Виртом в его книге "Алгоритмы + структуры данных = программы".Это был ответ на кризис в области программирования, начавшийся в середине 60-х годив, когда объем исходного программного кода перешел рубеж в 1000 строк. В 1971 году появился алгоритмический язык Pascal и немного позже, в 1972 году, язык С. Алгоритмические языки стали более мощными, более "интеллектуальными", на них уже можно было писать элементы трансляторов (компиляторов) и драйверов (подпрограмм обработки ввода-вывода). Компиляторы с языков С и Fortran выдают, например, по требованию программиста и листинг программы на Ассемблере. Знающий Ассемблер программистможет его проанализировать, что-то подправить и перекомпилировать, но уже на Ассемблере. В этом случае можно достаточно быстро и эффективно получать системные программы.

Модульное программирование. Здесь основная идея заключалась в том, чтобы "спрятать" данные и процедуры внутри независимых программных единиц - модулей. Эту идею впервые реализовал Н. Вирт в алгоритмическом языке Modula (1975-1979 годы), а затем "подхватили" и остальные, распространенные в то время языки программирования. Например, известные системы программирования TurboPascal и Turbo С.

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

Объектно-ориентированное программирование. С середины 80-х годов объем исходного программного кода перешел рубеж в 100 000 строк. Нужно было сделать не случайное объединение данных и алгоритмов их обработки в единое целое, а - смысловое. То есть необходимо было создать модульное программирование нового уровня,когда основной акцент делается на смысловую связь структур данных и алгоритмов их обработки. Сейчас практически все основные языки программирования (их более 100, в том числе такие распространенные, как ObjectPascal, C++, Smalltalk) базируются на этой идее, а предком их является язык Simula, созданный еще в 1960 году.

Обобщенные технологии разработки приложений. Идеология объектно-ориентированного программирования породила CASE-технологии разработки и сборки программ на основе уже известных программных моделей, содержащих интерфейсы и прототипы (шаблоны — template) данных: COM (ComponentObjectModel), STL (StandardTemplateLibrary), ATL (ActiveTemplateLibrary). Все эти новшества поддерживают визуальныесреды разработки, например, такие известные, как Visual C++, Borland C++ Builder, BorlandDelphi.

Теперь подробно рассмотрим технологию модульного , структурного, объектно-ориентированного программирования.

2.1. Модульное программирование

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

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

2.1.1. Основные характеристики программного модуля

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

хороший модуль снаружи проще, чем внутри;

хороший модуль проще использовать, чем построить.

Майерс предлагает для оценки приемлемости программного модуля использовать более конструктивные его характеристики:

размер модуля;

прочность модуля;

сцепление с другими модулями;

рутинность модуля (независимость от предыстории обращений к нему).

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

Прочность модуля - это мера его внутренних связей. Чем выше прочность модуля, тем больше связей он может спрятать от внешней по отношению к нему части программы и, следовательно, тем больший вклад в упрощение программы он может внести. Для оценки степени прочности модуля Майерс [5] предлагает упорядоченный по степени прочности набор из семи классов модулей. Самой слабой степенью прочности обладает модуль, прочный по совпадению. Это такой модуль, между элементами которого нет осмысленных связей. Такой модуль может быть выделен, например, при обнаружении в разных местах программы повторения одной и той же последовательности операторов, которая и оформляется в отдельный модуль. Необходимость изменения этой последовательности в одном из контекстов может привести к изменению этого модуля, что может сделать его использование в других контекстах ошибочным. Такой класс программных модулей не рекомендуется для использования. Вообще говоря, предложенная Майерсом упорядоченность по степени прочности классов модулей не бесспорна. Однако, это не очень существенно, так как только два высших по прочности класса модулей рекомендуются для использования. Эти классы я рассмотрю подробнее.

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

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

В модульных языках программирования как минимум имеются средства для задания функционально прочных модулей (например, модуль типа FUNCTION в языке ФОРТРАН). Средства же для задания информационно прочных модулей в ранних языках программирования отсутствовали. Эти средства появились только в более поздних языках. Так в языке программирования Ада средством задания информационно прочного модуля является пакет .

Сцепление модуля - это мера его зависимости по данным от других модулей. Характеризуется способом передачи данных. Чем слабее сцепление модуля с другими модулями, тем сильнее его независимость от других модулей. Для оценки степени сцепления Майерс предлагает упорядоченный набор из шести видов сцепления модулей. Худшим видом сцепления модулей является сцепление по содержимому. Таким является сцепление двух модулей, когда один из них имеет прямые ссылки на содержимое другого модуля (например, на константу, содержащуюся в другом модуле). Такое сцепление модулей недопустимо. Не рекомендуется использовать также сцепление по общей области - это такое сцепление модулей, когда несколько модулей используют одну и ту же область памяти. Такой вид сцепления модулей реализуется, например, при программировании на языке ФОРТРАН с использованием блоков COMMON. Единственным видом сцепления модулей, который рекомендуется для использования современной технологией программирования, является параметрическое сцепление (сцепление по данным по Майерсу ) - это случай, когда данные передаются модулю либо при обращении к нему как значения его параметров, либо как результат его обращения к другому модулю для вычисления некоторой функции. Такой вид сцепления модулей реализуется на языках программирования при использовании обращений к процедурам (функциям).

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

всегда следует использовать рутинный модуль, если это не приводит к плохим (не рекомендуемым) сцеплениям модулей;

зависящие от предыстории модули следует использовать только в случае, когда это необходимо для обеспечения параметрического сцепления;

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

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

2.1.2 Методы разработки структуры модульной программы

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

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

функциональную спецификацию модуля (описание семантики функций, выполняемых этим модулем по каждому из его входов).

В процессе разработки программы ее модульная структура может по-разному формироваться и использоваться для определения порядка программирования и отладки модулей, указанных в этой структуре. Поэтому можно говорить о разных методах разработки структуры программы. Обычно в литературе обсуждаются два метода [1, 7]: метод восходящей разработки и метод нисходящей разработки.

2.1.3. Метод восходящей разработки

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

2.1.4. Метод нисходящей разработки

Метод нисходящей разработки заключается в следующем. Как и в предыдущем методе сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модуля самого верхнего уровня , переходя к программированию какого-либо другого модуля только в том случае, если уже запрограммирован модуль, который к нему обращается. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в таком же порядке. При этом первым тестируется головной модуль программы, который представляет всю тестируемую программу и поэтому тестируется при «естественном» состоянии информационной среды, при котором начинает выполняться эта программа. При этом те модули, к которым может обращаться головной, заменяются их имитаторами . Каждый имитатор модуля представляется весьма простым программным фрагментом, который, в основном, сигнализирует о самом факте обращения к имитируемому модулю, производит необходимую для правильной работы программы обработку значений его входных параметров и выдает, если это необходимо, заранее запасенный подходящий результат. После завершения тестирования и отладки головного и любого последующего модуля производится переход к тестированию одного из модулей, которые в данный момент представлены имитаторами, если таковые имеются. Для этого имитатор выбранного для тестирования модуля заменяется самим этим модулем и, кроме того, добавляются имитаторы тех модулей, к которым может обращаться выбранный для тестирования модуль. При этом каждый такой модуль будет тестироваться при «естественных» состояниях информационной среды, возникающих к моменту обращения к этому модулю при выполнении тестируемой программы. Таким образом, большой объем «отладочного» программирования при восходящем тестировании заменяется программированием достаточно простых имитаторов используемых в программе модулей. Кроме того, имитаторы удобно использовать для того, чтобы подыгрывать процессу подбора тестов путем задания нужных результатов, выдаваемых имитаторами. При таком порядке разработки программы вся необходимая глобальная информация формируется своевременно, т.е. ликвидируется весьма неприятный источник просчетов при программировании модулей. Некоторым недостатком нисходящей разработки, приводящим к определенным затруднениям при ее применении, является необходимость абстрагироваться от базовых возможностей используемого языка программирования, выдумывая абстрактные операции, которые позже нужно будет реализовать с помощью выделенных в программе модулей. Однако способность к таким абстракциям представляется необходимым условием разработки больших программных средств, поэтому ее нужно развивать.

2.2. Структурное программирование

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

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

Однако представление о структурном программировании, как о программировании без использования оператора GOTO, является ошибочным. Например, Хоор определяет структурное программирование как "систематическое использование абстракции для управления массой деталей и способ документирования, который помогает проектировать программу".

Структурное программирование можно толковать как "проектирование, написание и тестирование программы в соответствии с заранее определенной дисциплиной".

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

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

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

Наконец, структурное программирование призвано улучшить эффективность программ.

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

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

1. Функциональный блок, который на блок-схеме изображается в виде прямоугольников с одним входом и одним выходом:

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

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

2. Условная конструкция. Этот блок включает проверку некоторого логического условия (P), в зависимости от которого выполняется либо один (S1), либо другой (S2) операторы:

На языке TP:

if<условие>then<оператор1>else<оператор2>;

3. Блок обобщенного цикла. Этот блок обеспечивает многократное повторение выполнения оператора S пока выполнено логическое условие P:

На языке TP циклы реализуются 2 способами. Цикл с параметром:

for<параметр> := <нач.значение>to<кон.значение>;

. . begin

<оператор1>

. . <оператор2>

. . ...

. end;

Цикл с предусловием:

. while<условие>

. .begin

<оператор1>

. . <оператор2>

. . ...

. end;

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

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

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

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

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

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

Объектно-ориентированное программирование

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

Инкапсуляция. Комбинирование записей с процедурами и функциями, манипулирующими полями этих записей, формирует новый тип данных - объект.

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

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


Языковые расширения BorlandPascal предоставляют вам все средства объектно-ориентированного программирования: большую структурированность и модульность, большую абстрактность и встроенную непосредственно в язык возможность повторного использования. Все эти характеристики соответствуют коду, который является более структурированным, более гибким и более легким для обслуживания.

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

Метод объектно-ориентированного программирования являются одними из наиболее примечательных атрибутов программирования и требуют некоторой практики перед использованием. Вернемся сначала к исходному вопросу о тщетной попытке структурного программирования, связанной с

инициализацией структур данных. Рассмотрим задачу инициализации

записи со следующим определением:

TEmployee = object

Name: string[25];

Title: string[25];

Rate: Real;

end;

Большинство программистов использовали бы оператор with для

присвоения полям Name, Title и Rate начальных значений:

var

MyEmployee: Employee;

withMyEmployee do

begin

Name := Sanderson, Arthur;

Title := Word processor;

Rate := 9.45;

end;

Это тоже неплохо, но здесь мы жестко ограничены одной специ-

фическим экземпляром записи - MyEmployee. Если потребуется иници-

ализировать более одной записи типа Employee, то вам придется ис-

пользовать большее число операторов with, которые выполняют в

точности те же действия. Следующим естественным шагом является

создание инициализирующей процедуры, которая обобщает оператор

with применительно к любому экземпляру типа TEmployee, пересылае-

мойвкачествепараметра:

procedureInitTEmployee(var Worker: TEmployee; AName,

ATitle: String; ARate: Real);

begin

with Worker do

begin

Name :=NewName ;

Title :=NewTitle;

Rate := NewRate;

end;

end;

Это будет работать, все в порядке, однако если вы почувству-

ете, что при этом тратите больше времени, чем необходимо, то вы

почувствуете то же самое, что чувствовал ранний сторонник объект-

но-ориентированного программирования.

Это чувство значит, что, ну, скажем, вы разрабатываете про-

цедуруInitTEmployee специально для обслуживания типа TEmployee.

Тогда почему вы должны помнить, какой тип записи и какой его эк-

земпляр обрабатывает InitTEmployee? Должен существовать некоторый

путь объединения типа записи и обслуживающего кода в одно единое

целое.

Такой путь имеется и называется методом. Метод - это проце-

дура или функция, объединенная с данным типом столь тесно, что

метод является как бы окруженным невидимым оператором with, что

делает экземпляр данного типа доступными изнутри для метода. Оп-

ределение типа включает заголовок метода. Полное определение ме-

тода квалифицируется в имени типа. Тип объекта и метод объекта

являются двумя лицами этой новой разновидности структуры, именуе-

мойметодом.

type

TEmployee = object

Name, Title: string[25];

Rate: Real;

procedureInit (NewName, NewTitle: string[25];

NewRate: Real);

end;

procedureTEmployee.Init (NewName, NewTitle: string[25];

NewRate: Real);

begin

Name :=NewName ; { Поле Name объектаTEmployee }

Title :=NewTitle; { ПолеTutleобъектаTEmployee }

Rate :=NewRate; { Поле Rate объектаTEmployee }

end;

Теперь для инициализации экземпляра типа TEmployee вы просто

вызываете его метод, словно метод является полем записи, что име-

ет вполне реальный смысл:

var

AnEmployee: TEmployee;

AnEmployee.Init(Sara Adams, Account manager, 15000);

{пpосто, не так ли?}

Основные методы разработки приложений

Комментарии должны добавляться на всех трех основных уровнях приложения: мо-

дуля, процедуры и отдельных разделов или фрагментов кода. Ниже приведены коммен-

тарии для каждого уровня приложения.

Комментарии уровня модуля

Если вы используете соглашения об именовании модулей, описанные ранее в этой гла-

ве, то любой разработчик, просматривающий ваш код, будет иметь примерное представле-

ние о назначении кода, содержащегося в каждом модуле. Вам нужно добавить короткий

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

Пример комментария уровня модуля

Описание: Краткое описание назначения кода в данном модуле

OptionExplicit

Комментарии уровня процедуры

Комментарии уровня процедуры в коде приложения, как правило, более подробны. В

блоке комментария уровня процедуры вы описываете назначение процедуры и приводи-

те инструкции по ее использованию, указываете все аргументы и их назначение, а также

указываете возвращаемые значения в случае функции.

Комментарии уровня процедуры могут также служить для примитивного отслежи-

вания изменений, позволяя указывать в коде дату и описание правок, внесенных в про-

цедуру. Корректный комментарий уровня процедуры, как показано в листинге 3.3, поме-

щается над верхней строкой кода процедуры. Комментарий из листинга 3.3 приведен для

функции. Единственное различие между блоком комментария для функции и блоком

комментария для обычной процедуры состоит в том, что блок комментария для проце-

дуры не содержит раздела Возвращаемое значение, поскольку процедуры значение не

возвращают.

Пример комментария уровня процедуры

Комментарии: Размещает изменяемую диаграмму или

предлагает пользователю выбрать диаграмму из множества

уже размещенных.

Аргументы: chtChart Эта функция возвращает

ссылку на объект изменяемой

диаграммы или значение

Nothing в случае ее

отмены пользователем.

Возвращаемые значения: True -- в случае успешного выполнения

или False -- в случае ошибки или отмены

пользователем.

Дата Разработчик Действие

----------------------------------------------------------

07/04/02 Роб БоувиСоздана

10/14/03 Роб Боуви Получение ошибки для диаграмм

без рядов данных

11/18/03 Роб Боуви Получение ошибки при неактивной

рабочей книге

Практическая часть

1.Программа - это

1.упорядоченная последовательность команд , инструкций компьютера для решения задач.

2.Совокупность программ обработки данных и необходимость для их эксплуатации документов.

3.программная реализация на компьютере решения задачи.

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

2

2.Программное обеспечение - это

1.упорядоченная последовательность команд , инструкций компьютера для решения задач.

2.Совокупность программ обработки данных и необходимых для их эксплуатации документов

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

4.программная реализация на компьютере решения задачи."

1

3.Задачи - это

1.упорядоченная последовательность команд , инструкций компьютера для решения задач.

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

3.программная реализация на компьютере решения задачи

4.проблема подлежащая решению

1

4.Приложение - это

1.программная реализация на компьютере решения задач

2.проблема подлежащая решению

3.упорядоченная последовательность команд , инструкций компьютера для решения задач.

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

1

5.Предметная область - это

1.программная реализация на компьютере решения задач

2.проблема подлежащая решению

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

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

1

6.Эффективность программного продукта

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

2.основано на максимально возможной их интеграции с другими программами.

3.оценивается как с позиции прямого его назначения - требования пользователя так и сточки зрения расхода вычислительных ресурсов необходимых для его эксплантаций

4.программная реализация на компьютере решения задач

1

7.Коммуникативность программного продукта

1.основано на максимально возможной их интеграции с другими программами

2.программная реализация на компьютере решения задач

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

4.оценивается как с позиции прямого его назначения - требования пользователя так и сточки зрения расхода вычислительных ресурсов необходимых для его эксплантаций

1

8.Лицензия - это

1.лицензиат представляет право лицензиату использовать ПП или БД оставляя за собой право применять их и предоставлять за собой право после предоставлять на аналогических условиях неограниченному числу лиц

2.передача всех лицензионных прав на ПП или БД , покупателю лицензии предоставляется исключительное право на её использование , а автор патента отказывается от согласованного их применения

3.оценивается как с позиции прямого его назначения - требования пользователя так и сточки зрения расхода вычислительных ресурсов необходимых для его эксплантаций

4.договор на передачу одним лицом , лицензиаром другому лицу лицензиату право на использование услуг и технологий.

4

9.Исключительная лицензия - это

1.оценивается как с позиции прямого его назначения - требования пользователя так и сточки зрения расхода вычислительных ресурсов необходимых для его эксплантаций

2.передача всех лицензионных прав на ПП или БД , покупателю лицензии предоставляется исключительное право на её использование , а автор патента отказывается от согласованного их применения

3.лицензиат представляет право лицензиату использовать ПП или БД оставляя за собой право применять их и предоставлять за собой право после предоставлять на аналогических условиях неограниченному числу лиц

4.договор на передачу одним лицом , лицензиаром другому лицу лицензиату право на использование услуг и технологий

2

10.Простая лицензия - это

1.лицензиат представляет право лицензиату использовать ПП или БД оставляя за собой право применять их и предоставлять за собой право после предоставлять на аналогических условиях неограниченному числу лиц

2.оценивается как с позиции прямого его назначения - требования пользователя так и сточки зрения расхода вычислительных ресурсов необходимых для его эксплантаций

3.договор на передачу одним лицом , лицензиаром другому лицу лицензиату право на использование услуг и технологий

4.передача всех лицензионных прав на ПП или БД , покупателю лицензии предоставляется исключительное право на её использование , а автор патента отказывается от согласованного их применения

1 2