Студопедия

Главная страница Случайная лекция


Мы поможем в написании ваших работ!

Порталы:

БиологияВойнаГеографияИнформатикаИскусствоИсторияКультураЛингвистикаМатематикаМедицинаОхрана трудаПолитикаПравоПсихологияРелигияТехникаФизикаФилософияЭкономика



Мы поможем в написании ваших работ!




Постановка задач. Функциональная модуляризация

Читайте также:
  1. Вероятностная постановка принятия решений
  2. Вопрос 2. Первоначальная постановка на воинский учет и медицинское освидетельствование граждан при постановке на воинский учет.
  3. Выбор метода численного решения многокритериальных задач.
  4. ВЫЯВЛЕНИЕ ЛАДОВЫХ ФУНКЦИЙ МАЖОРО-МИНОРНОЙ СИСТЕМЫ ОТДЕЛЬНЫМИ АККОРДАМИ. ФУНКЦИОНАЛЬНАЯ РОЛЬ ТОНА
  5. Выявление существующих проблем и постановка медсестринских диагнозов
  6. Лекция 7. Менеджмент безопасности, правовое обеспечение и организационно-функциональная структура защиты населения
  7. Линейная и функциональная организационные структуры управления: преимущества, недостатки, сферы применения.
  8. Линейно - функциональная структура управления
  9. Линейно-функциональная структура управления
  10. Линейно-функциональная структура управления организацией, ее достоинства и недостатки

 

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

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

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

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

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

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

 


<== предыдущая страница | следующая страница ==>
Жизненный цикл ППП | Регламент модуляризации функционального наполнения

Дата добавления: 2014-03-04; просмотров: 386; Нарушение авторских прав




Мы поможем в написании ваших работ!
lektsiopedia.org - Лекциопедия - 2013 год. | Страница сгенерирована за: 0.004 сек.