Сквозной структурный контроль
Сквозной структурный контроль представляет собой совокупность технологических операций контроля, позволяющих обеспечить как можно более раннее обнаружение ошибок в процессе разработки. Термин «сквозной» в названии отражает выполнение контроля на всех этапах разработки. Термин «структурный» означает наличие четких рекомендаций по выполнению контролирующих операций на каждом этапе.
Сквозной структурный контроль должен выполняться на специальных контрольных сессиях, в которых, помимо разработчиков, могут участвовать специально приглашенные эксперты. Время между сессиями определяет объем материала, который выносится на сессию: при частых сессиях материал рассматривают небольшими порциями, при редких - существенными фрагментами. Материалы для очередной сессии должны выдаваться участникам заранее, чтобы они могли их обдумать.
Одна из первых сессий должна быть организована на этапе определения спецификаций. На этой сессии проверяют полноту и точность спецификаций, при этом целесообразно присутствие заказчика или специалиста по предметной области, которые смогут определить, насколько правильно и полно определены спецификации программного обеспечения.
На этапе проектирования вручную по частям проверяют алгоритмы разрабатываемого программного обеспечения на конкретных наборах данных и сверяют полученные результаты с соответствующими спецификациями. Основная задача - убедиться в правильности понимания спецификаций и проанализировать достоинства и недостатки концептуальных решений, закладываемых в проект.
На этапе реализации проверяют план (последовательность) реализации модулей, набор тестов, а также тексты отдельных модулей.
Для всех этапов целесообразно иметь списки наиболее часто встречающихся ошибок, которые формируют по литературным источникам и исходя из опыта предыдущих разработок. Такие списки позволяют сконцентрировать усилия на конкретных моментах, а не проверять все подряд. При этом все найденные ошибки фиксируют в специальном документе, но не исправляют их.
Помимо раннего обнаружения ошибок сквозной структурный контроль обеспечивает своевременную подготовку качественной документации по проекту.
Структурный подход к проектированию.
Проблема сложности
Проблема сложности является главной проблемой, которую приходится решать при создании больших и сложных систем любой природы. Ни один разработчик не в состоянии выйти за пределы человеческих возможностей и понять огромную систему во всех деталях. Единственный эффективный подход к решению этой проблемы, который выработало человечество за всю свою историю, заключается в построении сложной системы из небольшого количества крупных частей. Каждая такая часть, в свою очередь, строится из частей меньшего размера и т. д., до тех пор, пока самые небольшие части можно будет строить из имеющегося материала. Этот подход известен под самыми разными названиями, например, иерархическая декомпозиция и др. По отношению к проектированию сложной программной системы это означает, что ее необходимо разделять(декомпозировать) на небольшие подсистемы, каждую из которых можно разрабатывать независимо от других. Это позволяет при разработке подсистемы любого уровня держать в уме информацию только о ней, а не обо всех остальных частях системы.
Структура системы должна быть таковой, чтобы все взаимодействия между ее подсистемами укладывались в ограниченные, стандартные рамки:
· каждая подсистема должна инкапсулировать свое содержимое (скрывать его от других подсистем);
· каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами.
Инкапсуляция позволяет рассматривать структуру каждой подсистемы независимо от других подсистем. Интерфейсы позволяют строить систему более высокого уровня, рассматривая каждую подсистему как единое целое и игнорируя ее внутреннее устройство.
На сегодняшний день в программной инженерии существуют два основных подхода к разработке ПО ЭИС, принципиальное различие между которыми обусловлено разными способами декомпозиции систем. Первый подход называют функционально-модульным или структурным. В его основу положен принцип функциональной декомпозиции, при которой структура системы описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами. Второй, объектно-ориентированный подход использует объектную декомпозицию. При этом структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами.
Итак, сущность структурного подхода к разработке ПО заключается в его декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, те - на задачи и так далее до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы “снизу вверх”, от отдельных задач ко всей системе, целостность теряется, возникают проблемы при описании информационного взаимодействия отдельных компонентов.
Все наиболее распространенные методы структурного подхода базируются на ряде общих принципов:
· принцип “разделяй и властвуй”;
· принцип иерархического упорядочения — принцип организации составных частей системы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
· принцип абстрагирования — выделение существенных аспектов системы и отвлечение от несущественных;
· принцип непротиворечивости — обоснованность и согласованность элементов системы;
· принцип структурирования данных - данные должны быть структурированы и иерархически организованы.
Наиболее популярные методы моделирования:
SADT – метод структурного анализа и проектирования
IDEF0 – метод функционального моделирования.(BPwin, OpenModelSphere)
IDEF1X – информационное моделированиедля БД.(ERwin, OpenModelSphere)
IDEF2 – динамическое моделирование.
IDEF3 – метод моделирования (документирования) процессов. (BPwin)
IDEF4 – методология построения объектно-ориентированных систем, позволяют отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;
IDEF5 – стандарт онтологического исследования сложных систем. Онтология системы может быть описана при помощи словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии системы в некоторый момент времени. На основе этого формируются выводы о дальнейшем развитии системы;
IDEF6 – обоснование проектных действий. Получения ответа на вопрос: «почему модель получилась такой, какой получилась?». Метод IDEF6 акцентирует внимание именно на процессе создания модели управления предприятием;
IDEF7 – аудитинформационныхсистем. Этот метод определён как востребованный, однако так и не был полностью разработан;
IDEF8 – метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). IDFE8 фокусирует внимание на трех уровнях: выполняемой операции; сценарии взаимодействия, определяемом специфической ролью пользователя; на деталях интерфейса (какие элементы управления, предлагает интерфейс);
IDEF9 – метод исследования бизнес ограничений для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие. Знания об основных ограничениях и характере их влияния, закладываемые в модели, в лучшем случае остаются неполными, несогласованными, распределенными нерационально, но часто их вовсе нет. Реализация моделей из-за этого может столкнуться с непредвиденными трудностями, в результате чего их потенциал будет не реализован;
IDEF10 – моделированиеархитектурывыполнения;
IDEF11 – моделирование информационных артефактов;
IDEF12 – организационное моделирование;
IDEF13 – трёхсхемное проектирование преобразования данных;
IDEF14 – метод проектирования компьютерных сетей, основанный на анализе требований, специфических сетевых компонентов, существующих конфигураций сетей.
DFD – моделирование потоков данных. (BPwin)
ERD –метод сущность-связь Чена или Баркера (OpenModelSphere, Visio, ERwin)
UML – универсальныйязыкмоделирования (Rational rose, Delphi ECO, OpenMS)
Часть из них работает на стадии формирования требований к разработке ПО, другие нужны на стадии проектирования и разработки. Одной моделью обычно нельзя покрыть все аспекты, поэтому используется постепенная детализация. Например при рассмотрении предметной области можно построить диаграмму ERD, а затем детализировать её в IDEF1xдля создания схемы БД.