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

Автор работы: Пользователь скрыл имя, 11 Февраля 2011 в 10:09, контрольная работа

Описание работы

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

Файлы: 1 файл

Структурный подход к проектированию ПО3.doc

— 201.00 Кб (Скачать файл)

    1. Понятие структурного анализа и проектирования  

    Создателем  структурного подхода к программированию и проектированию является Э.Дейкста. Фактически структурное программирование – это первая законченная методология программного обеспечения.

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

    1.1 Идеи, лежащие в основе структурных методов  

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

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

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

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

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

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

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

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

    1.2 Принципы структурного анализа  

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

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

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

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

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

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

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

  1. Принцип абстрагирования - заключается в выделении существенных с некоторых позиций аспектов системы и отвлечение от несущественных с целью представления проблемы в простом общем виде.
  2. Принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы.
  3. Принцип упрятывания - заключается в упрятывании несущественной на конкретном этапе информации: каждая часть "знает" только необходимую ей информацию.
  4. Принцип концептуальной общности - заключается в следовании единой философии на всех этапах ЖЦ (структурный анализ - структурное проектирование - структурное программирование - структурное тестирование).
  5. Принцип полноты - заключается в контроле на присутствие лишних элементов.
  6. Принцип непротиворечивости - заключается в обоснованности и согласованности элементов.
  7. Принцип логической независимости - заключается в концентрации внимания на логическом проектировании для обеспечения независимости от физического проектирования.
  8. Принцип независимости данных - заключается в том, что модели данных должны быть проанализированы и спроектированы независимо от процессов их логической обработки, а также от их физической структуры и распределения.
  9. Принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы.
  10. Принцип доступа конечного пользователя - заключается в том, что пользователь должен иметь средства доступа к базе данных, которые он может использовать непосредственно (без программирования).

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

    1.3 Средства структурного анализа  

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

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

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

    Среди всего многообразия средств решения  данных задач в методологиях структурного анализа наиболее часто и эффективно применяемыми являются следующие:

  • SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;
  • DFD (Data Flow Diagrams) диаграммы потоков данных;
  • ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

    На  стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

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

 

     2 SADT - технология структурного анализа  и проектирования 

    SADT (Structured Analysis and Design Technique) - одна из  самых известных методологий анализа и проектирования систем, введенная в 1973 г. Россом (Ross). SADT успешно использовалась в военных, промышленных и коммерческих организациях для решения широкого спектра задач, таких как программное обеспечение телефонных сетей, системная поддержка и диагностика, долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, конфигурация компьютерных систем, обучение персонала, встроенное ПО для оборонных систем, управление финансами и материально-техническим снабжением и др. Данная методология широко поддерживается Министерством обороны США, которое было инициатором разработки стандарта IDEF0 как подмножества SADT. Это, наряду с растущей автоматизированной поддержкой, сделало ее более доступной и простой в употреблении.

Информация о работе Структурный подход к проектированию ПО3