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

По результатам анализа процессов принимается решение о количестве, составляющих ИС подсистем, поддающихся разработке одной командой разработчиков за приемлемое для RAD-проектов время — порядка 2—3 мес.

Результатом данной фазы должны быть:

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

Использование CASE-средств позволяет избежать искажения

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

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

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

---

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

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

программ, требующих написания большого объема (сотни тысяч строк) уникального кода.

Основные принципы методологии RAD:

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

---

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

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

Обзор методов объектно-ориентированного анализа и проектирования приведен в разд. 6. В данном разделе рассмотрены методы структурного проектирования. Такие методы ориентированы на формирование структуры программного средства по функциональному признаку.

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

Признаки модульности программ:

1. 
   программа состоит из модулей. Данный признак для модульной программы является очевидным;
   
2. 
   модули являются независимыми. Это значит, что модуль можно изменять или модифицировать без последствий в других модулях;
   
3. 
   условие «один вход – один выход». Модульная программа состоит из модулей, имеющих одну точку входа и одну точку выхода. В общем случае может быть более одного входа, но важно, чтобы точки входов были определены и другие модули не могли входить в данный модуль в произвольной точке.
   

Достоинства модульного проектирования:

1. 
   упрощение разработки ПС;
   
2. 
   исключение чрезмерной детализации обработки данных;
   
3. 
   упрощение сопровождения ПС;
   
4. 
   облегчение чтения и понимания программ;
   
5. 
   облегчение работы с данными, имеющими сложную структуру.
   

Недостатки модульности:

1. 
   модульный подход требует большего времени работы центрального процессора (в среднем на 5 – 10 %) за счет времени обращения к модулям;
   
2. 
   модульность программы приводит к увеличению ее объема (в среднем на 5 – 10 %);
   
3. 
   модульность требует дополнительной работы программиста и определенных навыков проектирования ПС.
   

---

Классические методы структурного проектирования модульных ПС делятся на три основные группы:

1. 
   методы нисходящего проектирования;
   
2. 
   методы расширения ядра;
   
3. 
   методы восходящего проектирования.
   

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

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

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

Таблица 2.6 – Типы и силы связности модулей

Связность	Сила связности
Функциональная	10 (сильная связность)
Последовательная	9
Коммуникативная	7
Процедурная	5
Временная	3
Логическая	1
Связность по совпадению	0 (слабая связность)

---

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

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

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

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

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

---

Смотрите также файлы

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

• Р. А.адырлов, Н.. Беристемова.docx

• Контрольная работа по дисциплине Электромагнитная совместимость и средства защиты Тема Расчет характеристик питания нагрузок в сети электроснабжения железных дорог.docx

• Цифровые компетенции Цифровая безопасность Цифровое потребление.docx

• Специальные пожарные автомобили.doc