Структурный подход к проектированию




Проблема сложности является главной проблемой, которую приходится решать при создании больших и сложных систем любой природы, в том числе и ЭИС. Ни один разработчик не в состоянии выйти за пределы человеческих возможностей и понять всю систему в целом. Единственный эффективный подход к решению этой проблемы, который выработало человечество за всю свою историю, заключается в построении сложной системы из небольшого количества крупных частей, каждая из которых, в свою очередь, строится из частей меньшего размера и т.д., до тех пор, пока самые небольшие части можно будет строить из имеющегося материала. Этот подход известен под самыми разными названиями, среди них такие, как "разделяй и властвуй" (divide et impera), иерархическая декомпозиция и др. По отношению к проектированию сложной программной системы это означает, что ее необходимо разделять (декомпозировать) на небольшие подсистемы, каждую из которых можно разрабатывать независимо от других. Это позволяет при разработке подсистемы любого уровня держать в уме информацию только о ней, а не обо всех остальных частях системы. Правильная декомпозиция является главным способом преодоления сложности разработки больших систем ПО. Понятие "правильная" по отношению к декомпозиции означает следующее:

количество связей между отдельными подсистемами должно быть минимальным;

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

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

каждая подсистема должна инкапсулировать свое содержимое (скрывать его от других подсистем);

каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами.

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

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

1) повышается надежность программ (благодаря хорошему структурированию при проектировании, программа легко поддается тестированию и не создает проблем при отладке);

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

3) уменьшается время и стоимость программной разработки;

4) улучшается читабельность программ.

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

К недостаткам относятся

- усложнение методологии. Применение объектно-ориентированного подхода требует введения дополнительных способов представления информации о предметной области и методов ее анализа. Язык UML включает более 100 различных условных обозначений. Для успешного использования подобного механизма требуется наличие определенного уровня квалификации у специалистов. Для небольших проектов более эффективным может оказаться применение классических методов разработки. Разработка проектов, для которых важнейшей задачей является описание предметной области и для которых невозможно найти человека, понимающего эту предметную область в целом, также требует использования традиционных подходов в виду их большей доступности для неспециалистов;

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

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

- диаграммы переходов состояний (SDT — State Transition Diagrams), характеризующие поведение системы во времени;

- функциональные диаграммы (SADT — Structured Analisis and Design Technique);

- диаграммы потоков данных (DFD — Data Flow Diagrams), описывающие взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе;

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

Функциональная модель

Методология SADT разработана Дугласом Россом. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition). Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях:

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

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

-ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

-связность диаграмм (номера блоков);

-уникальность меток и наименований (отсутствие повторяющихся имен);

-синтаксические правила для графики (блоков и дуг);

-разделение входов и управлений (правило определения роли данных).

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

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

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

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

Рис 1. Функциональный блок и интерфейсные дуги



Поделиться:




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

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2019-04-03 Нарушение авторских прав и Нарушение персональных данных


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