Принципы структурного программирования

1. Модульное программирование – процесс разбиения программы на отдельные программные модули (базовые классы, процедуры, функции, ActiveX – элементы, COM/DCOM–компоненты и др.).

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

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

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

Обычно для больших проектов применяется метод «сэндвича». Для одних частей используется метод нисходящего, а для других – метод восходящего проектирования.

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

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

Этапы тестирования:

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

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

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

4. Наглядность исходных текстов программ - Стиль программирования, который позволяет получать удобные для применения и легко читаемые программы.

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

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

5. Гибкость и эффективность программ. Выносите изменяемые константы, адреса и имена файлов, баз данных в отдельные файлы настройки. Оптимизируйте программу после ее отладки. Используйте именованные константы вместо обычных. Минимизируйте применение глобальных переменных, вложенных структур и команд перехода Goto. Огра­ни­чи­вай­те дей­ствия над параметрами под­прог­рамм (например, для Visual Basic – ByVal, ByRef; для Pascal – Optional, Var, Out, Const). Рекомендации: тексты программ должны быть легко чи­таемы­ми и понятными. Используйте вводные комментарии. Распола­гай­те ком­мен­тарии в программе таким образом, чтобы это не делало ее менее наглядной. Одного оператора в строке достаточно. Для выделения структуры ис­поль­зуйте отступы (начало и конец структуры сдвинуты на три позиции влево относительно тела структуры). Фиксируйте соответствие букв кирил­лицы и латинского алфавита (например, Щ (H), И (I), B (V)). Стремитесь к простоте и уни­вер­сальности (например, программа имеет средства настройки на форматы и значения данных). Унифи­цируй­те форматы ввода и вывода ин­фор­мации. Обеспечивайте макси­маль­но удобный интерфейс пользователю. Интересуйтесь, как эксплуатируется программа (поработайте со своей прог­рам­мой в качестве пользователя). Устанавливайте более скромные цели (рабо­тающие программы гораздо полезнее и важнее незаконченных громадных проектов). Общая схема упроще­ния – разбиение прог­рам­мы на модули и оформление каждого из них в виде процедуры, функции, класса, ActiveX–элемента, компонента. Рекомендуется заменять циклы или вложенные конструкции на функции.

Сущность структурного подхода к проектированию программных и информационных систем, основные понятия, принципы и модели.

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

Базовыми принципами структурного подхода являются:

· принцип «разделяй и властвуй» – принцип решения сложных проблем путем их разбиения на множество меньших независи­мых задач, легких для понимания и решения;

· принцип иерархического упорядочения – принцип организации составных частей проблемы в иерархические древовидные струк­туры с добавлением новых деталей на каждом уровне;

· принцип абстрагирования – выделение существенных аспектов сис­те­мы и отвлечение от несущественных;

· принцип формализации – необходимость строгого методическо­го под­хо­да к решению проблемы;

· принцип непротиворечивости – обоснованность и согласован­ность эле­ментов;

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

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

1) DFD (Data Flow Diagrams) – диаграммы потоков данных (процессов);

В основе данной методологии лежит построение модели анали­зи­ру­емой ИС – проектируемой или реально существующей. В соответствии с ме­тодологией модель системы определяется как иерархия диаграмм пото­ков данных, описывающих асинхронный процесс преобразования ин­фор­ма­ции от ее ввода в систему до выдачи пользователю. Используются для описания документо­обо­рота и обработки информации: функции обработки информации (ра­бо­ты), документы, потоки данных (стрелки), внешние ссылки на объекты вне гра­ниц модели (External References), хранилища данных (Data Store). Работы в этой модели не поддерживают управление и механизмы. Стрелки могут входить и выходить из любых сторон прямоугольника работы и быть двунаправленными для описания диалогов типа «команда–ответ».

2) SADT (Structured Analysis and Design Technique) – модели и соот­ветству­ющие функциональные диаграммы;

Методология SADT (IDEF0) представляет собой совокупность мето­дов, пра­вил и процедур, предназначенных для построения функцио­наль­ной модели объекта предметной области. Функ­циональная мо­дель SADT отображает функциональную структуру объекта, т.е. прои­зво­ди­мые им действия (бизнес–процессы) и связи между ними. Моделирование начинается с определения контекста – описания сис­те­мы в целом (субъекта, целей и точки зрения на модель), т.е. области моделирования (Scope). Под широтой области моделирования понимается граница: что будет рассматриваться внутри системы, а что снаружи. Глу­би­на модели определяет уровень детализации модели.

3) ERD (Entity–Relationship Diagrams) – диаграммы «сущность–связь».

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

Каждая сущность должна обладать некоторыми свойствами:

§ иметь уникальное имя (к одному и тому же имени должна всегда применяться одна и та же интерпретация; одна и та же интерпре­тация не может применяться к различным именам, если только они не являются псевдонимами);

§ обладать одним или несколькими атрибутами, которые либо при­надлежат сущности, либо наследуются через связь;

§ обладать одним или несколькими атрибутами, которые однознач­но идентифицируют каждый экземпляр сущности;

§ может обладать любым количеством связей с другими сущностями модели.

Связь (Relationship) – поименованная ассоциация между сущностями, при которой каж­дый экземпляр одной сущности ассоциирован с произвольным (в том числе нулевым) коли­чест­вом экземпляров второй сущности, и наоборот.

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

Экземпляр атрибута – это определенная характеристика отдель­ного элемента множества, определяется типом харак­те­рис­тики и ее значением, называемым «значение атрибута». В ER–мо­де­ли атрибуты ассоциируются с конкретными сущностями. Таким образом, экзем­пляр сущности должен об­ладать единственным определенным значе­нием для ассоциированного атрибута.