Case-технлогии
хороша в первую очередь для
относительно небольших проектов, разрабатываемых для конкретного заказчика.
Если же разрабатывается типовая система, которая не является законченным
продуктом, а представляет собой комплекс типовых компонент, централизованно
сопровождаемых, адаптируемых к программно-техническим платформам, СУБД,
средствам телекоммуникации, организационно-экономическим особенностям
объектов внедрения и интегрируемых с существующими разработками, на первый
план выступают такие показатели проекта, как управляемость и качество,
которые могут войти в противоречие с простотой и скоростью разработки. Для
таких проектов необходимы высокий уровень планирования и жесткая дисциплина
проектирования, строгое следование заранее разработанным протоколам и
интерфейсам, что снижает скорость разработки.
Методология RAD неприменима для построения сложных расчетных программ,
операционных систем или программ управления космическими кораблями, т.е.
программ, требующих написания большого объема (сотни тысяч строк)
уникального кода.
Не подходят для разработки по методологии RAD приложения, в которых
отсутствует ярко выраженная интерфейсная часть, наглядно определяющая
логику работы системы (например, приложения реального времени) и
приложения, от которых зависит безопасность людей (например, управление
самолетом или атомной электростанцией), так как итеративный подход
предполагает, что первые несколько версий наверняка не будут полностью
работоспособны, что в данном случае исключается.
Оценка размера приложений производится на основе так называемых
функциональных элементов (экраны, сообщения, отчеты, файлы и т.п.) Подобная
метрика не зависит от языка программирования, на котором ведется
разработка. Размер приложения, которое может быть выполнено по методологии
RAD, для хорошо отлаженной среды разработки ИС с максимальным повторным
использованием программных компонентов, определяется следующим образом:
|< 1000 функциональных |один человек |
|элементов | |
|1000-4000 функциональных |одна команда разработчиков |
|элементов | |
|> 4000 функциональных |4000 функциональных элементов на одну |
|элементов |команду разработчиков |
В качестве итога перечислим основные принципы методологии RAD:
разработка приложений итерациями;
необязательность полного завершения работ на каждом из этапов жизненного
цикла;
обязательное вовлечение пользователей в процесс разработки ИС;
необходимое применение CASE-средств, обеспечивающих целостность проекта;
применение средств управления конфигурацией, облегчающих внесение изменений
в проект и сопровождение готовой системы;
необходимое использование генераторов кода;
использование прототипирования, позволяющее полнее выяснить и удовлетворить
потребности конечного пользователя;
тестирование и развитие проекта, осуществляемые одновременно с разработкой;
ведение разработки немногочисленной хорошо управляемой командой
профессионалов;
грамотное руководство разработкой системы, четкое планирование и контроль
выполнения работ.
2. Структурный подход к проектированию ИС
2.1. Сущность структурного подхода
Сущность структурного подхода к разработке ИС заключается в ее декомпозиции
(разбиении) на автоматизируемые функции: система разбивается на
функциональные подсистемы, которые в свою очередь делятся на подфункции,
подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть
до конкретных процедур. При этом автоматизируемая система сохраняет
целостное представление, в котором все составляющие компоненты
взаимоувязаны. При разработке системы "снизу-вверх" от отдельных задач ко
всей системе целостность теряется, возникают проблемы при информационной
стыковке отдельных компонентов.
Все наиболее распространенные методологии структурного подхода [9,11,12,13]
базируются на ряде общих принципов [3]. В качестве двух базовых принципов
используются следующие:
принцип "разделяй и властвуй" - принцип решения сложных проблем путем их
разбиения на множество меньших независимых задач, легких для понимания и
решения;
принцип иерархического упорядочивания - принцип организации составных
частей проблемы в иерархические древовидные структуры с добавлением новых
деталей на каждом уровне.
Выделение двух базовых принципов не означает, что остальные принципы
являются второстепенными, поскольку игнорирование любого из них может
привести к непредсказуемым последствиям (в том числе и к провалу всего
проекта). Основными из этих принципов являются следующие:
принцип абстрагирования - заключается в выделении существенных аспектов
системы и отвлечения от несущественных;
принцип формализации - заключается в необходимости строгого методического
подхода к решению проблемы;
принцип непротиворечивости - заключается в обоснованности и согласованности
элементов;
принцип структурирования данных - заключается в том, что данные должны быть
структурированы и иерархически организованы.
В структурном анализе используются в основном две группы средств,
иллюстрирующих функции, выполняемые системой и отношения между данными.
Каждой группе средств соответствуют определенные виды моделей (диаграмм),
наиболее распространенными среди которых являются следующие:
SADT (Structured Analysis and Design Technique) модели и соответствующие
функциональные диаграммы (подраздел 2.2);
DFD (Data Flow Diagrams) диаграммы потоков данных (подраздел 2.3);
ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь" (подраздел
2.4).
На стадии проектирования ИС модели расширяются, уточняются и дополняются
диаграммами, отражающими структуру программного обеспечения: архитектуру
ПО, структурные схемы программ и диаграммы экранных форм.
Перечисленные модели в совокупности дают полное описание ИС независимо от
того, является ли она существующей или вновь разрабатываемой. Состав
диаграмм в каждом конкретном случае зависит от необходимой полноты описания
системы.
2.2. Методология функционального моделирования SADT
Методология SADT разработана Дугласом Россом и получила дальнейшее развитие
в работе [4]. На ее основе разработана, в частности, известная методология
IDEF0 (Icam DEFinition), которая является основной частью программы ICAM
(Интеграция компьютерных и промышленных технологий), проводимой по
инициативе ВВС США.
Методология SADT представляет собой совокупность методов, правил и
процедур, предназначенных для построения функциональной модели объекта
какой-либо предметной области. Функциональная модель SADT отображает
функциональную структуру объекта, т.е. производимые им действия и связи
между этими действиями. Основные элементы этой методологии основываются на
следующих концепциях:
графическое представление блочного моделирования. Графика блоков и дуг SADT-
диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода
представляются дугами, соответственно входящими в блок и выходящими из
него. Взаимодействие блоков друг с другом описываются посредством
интерфейсных дуг, выражающих "ограничения", которые в свою очередь
определяют, когда и каким образом функции выполняются и управляются;
строгость и точность. Выполнение правил SADT требует достаточной строгости
и точности, не накладывая в то же время чрезмерных ограничений на действия
аналитика. Правила SADT включают:
ограничение количества блоков на каждом уровне декомпозиции (правило 3-6
блоков);
связность диаграмм (номера блоков);
уникальность меток и наименований (отсутствие повторяющихся имен);
синтаксические правила для графики (блоков и дуг);
разделение входов и управлений (правило определения роли данных).
отделение организации от функции, т.е. исключение влияния организационной
структуры на функциональную модель.
Методология SADT может использоваться для моделирования широкого круга
систем и определения требований и функций, а затем для разработки системы,
которая удовлетворяет этим требованиям и реализует эти функции. Для уже
существующих систем SADT может быть использована для анализа функций,
выполняемых системой, а также для указания механизмов, посредством которых
они осуществляются.
2.2.1. Состав функциональной модели
Результатом применения методологии SADT является модель, которая состоит из
диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга.
Диаграммы - главные компоненты модели, все функции ИС и интерфейсы на них
представлены как блоки и дуги. Место соединения дуги с блоком определяет
тип интерфейса. Управляющая информация входит в блок сверху, в то время как
информация, которая подвергается обработке, показана с левой стороны блока,
а результаты выхода показаны с правой стороны. Механизм (человек или
автоматизированная система), который осуществляет операцию, представляется
дугой, входящей в блок снизу (рисунок 2.1).
Одной из наиболее важных особенностей методологии SADT является постепенное
введение все больших уровней детализации по мере создания диаграмм,
отображающих модель.
Рис. 2.1. Функциональный блок и интерфейсные дуги
На рисунке 2.2, где приведены четыре диаграммы и их взаимосвязи, показана
структура SADT-модели. Каждый компонент модели может быть декомпозирован на
другой диаграмме. Каждая диаграмма иллюстрирует "внутреннее строение" блока
на родительской диаграмме.
2.2.2. Иерархия диаграмм
Построение SADT-модели начинается с представления всей системы
| |  скачать работу |
Case-технлогии |
