Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

Вопросы с ответами(2008-2009) - файл 1.doc


Вопросы с ответами(2008-2009)
скачать (456.5 kb.)

Доступные файлы (1):

1.doc457kb.17.11.2011 10:56скачать

содержание

1.doc

1   2   3

^ 60. Структурное программирование. Определение подхода, цель и принципы.*

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

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

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




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

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

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





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



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

в) цикл

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



  1. с постусловием



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



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



^ 61. Нотации для представления структурных алгоритмов.*

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

Псевдокод – формализованное текстовое описание алгоритма(текстовая нотация).


^ 62. Нисходящая стратегия разработки программ.*

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

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


^ 63. Принципы модульного программирования.* *

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

Что в теории понимается под модулем? Модуль – это замкнутая программа, которую можно вызвать из другого модуля и самостоятельно откомпилировать. Другое определение: программный модуль – это любой фрагмент описания процесса, оформляемый как самостоятельный программный продукт, пригодный для использования в описаниях процесса.

Модуль – это программа, обладающая тремя основными атрибутами:

он выполняет одну или несколько функций;

модуль реализует некоторую логику (алгоритм).

используется в одном или нескольких контекстах.

При этом функция – это то, что делает модуль, а не то, как он это делает. А вот логика характеризует, как модуль выполняет свои функции. Контекст описывает конкретное применение.

^ 64. Классы прочности модулей.*

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

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

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

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

Пример: библиотека стандартных программ, реализующих численные методы.

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

3. Прочность по классу – модуль выполняет несколько функций, отнесенных разработчиком к одному классу. Например: autoexec.bat.

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

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

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

5. Коммуникационно- прочный модуль. Это процедурно прочный модуль, в котором все функции модуля связаны по данным.

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

6. Информационная прочность – модуль выполняет несколько функций над одной и той же строкой данных, но каждая функция представляется отдельным входом в модуль.

7. Функциональная прочность – это когда модуль выполняет одну функцию – это то, к чему следует стремиться при проектировании модульной структуры ПО. Информационно - прочные модули следует рассматривать как физическое соединение нескольких функционально – прочных модулей.

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


^ 65. Виды сцепления модулей.*

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

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

1. Сцепление по содержимому – модуль ссылается на данные (содержимое) другого модуля. Большинство языков программирования высокого уровня делает такое сцепление практически невозможным.

2. Сцепление по общей области – модули ссылаются на одну и ту же глобальную структуру данных.

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

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

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

4. Сцепление по формату – модули ссылаются на одну и ту же структуру данных. Если модуль А вызывает модуль В и передает ему запись анкетных данных служащего и при этом как А так и В чувствительны к изменению структуры или формата записи, то А и В сцеплены по формату.Такого сцепления, по возможности, следует избегать, поскольку оно создает ненужные связи между модулями.

5. Сцепление по данным – передаваемые параметры – простые (неструктурированные) данные.

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


^ 66. Модульный стиль программирования.*

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

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


^ 67. Основные понятия объектно-ориентированного программирования.*

Основными понятиями ООП являются объект (экземпляр класса), класс, метод и сообщение (запрос)

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

Объектом или экземпляром класса называется переменная объектного типа ( или переменная типа класс).

Методы – операции обработки.

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


^ 68. Достоинства и недостатки объектно-ориентированного программирования.*

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

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

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

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

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


^ 69. CASE-технологии как результат эволюционного развития инструментальных средств.*

CASE-системами или CASE-технологиями называют реализованные в виде программных продуктов технологические системы, ориентированные на создание сложных программных систем и поддержку их полного жизненного цикла или его основных этапов.

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

В качестве инструментальных средств в эти периоды использовались:

  • ассемблеры, дампы памяти, анализаторы;

  • компиляторы, интерпретаторы, трассировщики;

  • символические отладчики, пакеты программ;

  • системы анализа и управления исходными текстами;

  • CASE-средства анализа требований, проектирования спецификаций и структуры, редактирования интерфейсов (1-ая генерация CASE-1);

CASE-средства генерации исходных текстов и реализации интегрированного окружения поддержки полного ЖЦ разработки ПО (2-ая генерация CASE-II).

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


^ 70. Сравнение этапов жизненного цикла в CASE-технологиях и при традиционной разработке ПО.*

При использовании CASE-технологий изменяются фазы жизненного цикла ПП как показано ниже:

При традиционной технологии: При CASE-технологии:

Анализ Прототипирование

Проектирование Проектирование спецификаций

Контроль проекта

Кодирование Кодогенерация

Тестирование Системное тестирование

Сопровождение Сопровождение


^ 71. Спиральная модель жизненного цикла программных продуктов.*

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


^ 72. Классификация CASE-технологий.*

Анализ и проектирование. Средства данной группы применяют для создания спецификаций системы и ее проектирования, они поддерживают методологии SE и IE:

  • CASE- аналитик (Эйтекс);

  • POSE (Computer Systems Advisers);

  • Design/IDEF (Meta Software);

  • BPWin (Logic Works);

  • SELECT (Select Software Tools);

  • CASE/4.0 (micro TOOl GmbH)

и ряд других средств.

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

  • ERWin (Logic Works);

  • S-Designor (SPD);

  • Designеr/2000 (Oracle);

  • Sillverrun (Computer Systems Advisers).

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

  • COBOL 2/Workbench (Miсro Focus);

  • ^ DECASE (DEC);

  • NETRON/CAP (Netron);

  • APS (Sage Softwаre).

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

Сопровождение и реинжениринг. Сюда относят документаторы, анализаторы программ, средства реструктурирования:

  • Adpac CASE Tools (Adpac);

  • Scan/COBOL и SuperStructure (Computer Data Systems):

  • Insреctor/Recoder (language Tecnologe).



^ 73. Приведите нотации цикла “до” для отображения структурных алгоритмов.*


74. Дайте определение модели жизненного цикла ПП. Приведите каскадную и спиральную модели ЖЦ и дайте краткие пояснения. *


Модель ЖЦ ПП определяет перечень этапов преобразования программа -> программное средство -> программный продукт, порядок выполнения этапов, а также критерии перехода от этапа к этапу. Традиционная модель ЖЦ ПО строится по каскадному принципу, суть которого в том, что переход на следующий этап происходит после окончания предыдущего. Единственным недостатком такой простой модели ЖЦ является то, что на практике очень часто принятые на предыдущем этапе (или на предыдущих этапах) решения приходится пересматривать из-за неверной интерпретации требований заказчика. Другая модель ЖЦ ПП строится по поэтапному принципу с промежуточным контролем. Критерием перехода на следующий этап является готовность документов, о которых было упомянуто выше. Такая модель является более жизнеспособной по сравнению с каскадной моделью, но наличие циклов обратных связей растягивает все этапы ЖЦ ПП на весь период разработки, что, в свою очередь, затрудняет планирование работ по созданию и внедрению программных продуктов. CASE-технология базируется на спиральной модели ЖЦ ПП, суть которой в следующем. Делается упор на начальные этапы ЖЦ: анализ требований, проектирование спецификаций, предварительное и детальное проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов. Все эти этапы выполняются на каждом витке спирали ЖЦ. Каждый виток спирали соответствует некоторому уровню детализации проекта. Каждый следующий виток характеризуется более высокой степенью детализации создаваемого ПО. Каждый виток заканчивается тем, что уточняются цели и характеристики проекта и планируются работы следующего витка спирали. Тем самым реализуется нисходящий принцип проектирования.


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


^ 75. Назовите приемы уменьшения объемов памяти для программы.*

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

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

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

Передавать данные “по ссылке” как неизменяемые.


^ 76. Назовите приемы уменьшения времени выполнения программы.*

Первый способ связан с учетом времени выполнения операций в ЭВМ:

• сложение и вычитание выполняются быстрее, чем умножение и деление (в связи с чем Х+Х выполнясгся быстрее, чем ^ 2*Х)

• целочисленная арифметика быстрее арифметики вещественных чисел (поэтому (i+i+j)* 0,5 быстрее» чем i+0,5*j, так как в первом варианте одна операция с вещественными числами, а во втором – две)

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

• обращение к функции требует больших временных затрат, чем умножение и деление.

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

При их написании необходимо по возможности:

1) выносить вычисление константных, т.е. не зависящих от параметров цикла выражений из циклов.

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

3) минимизировать преобразования типов в выражениях

4) оптимизировать запись условных выражений – исключать лишние проверки.

5) исключать многократные обращения к элементам массивов по индексам

6) избегать использования различных типов в выражении и т.п.
1   2   3



Скачать файл (456.5 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации