Разработка программных модулей приложения

Лекция 7. Разработка структуры программы и модульное программирование

Цель разработки структуры программы. Понятие программного модуля. Основные характеристики программного модуля. Методы разработки структуры программы. Спецификация программного модуля. Контроль структуры программы.

7.1. Цель модульного программирования.

Приступая к разработке каждой программы ПС, следует иметь в виду, что она, как правило, является большой системой, поэтому мы должны принять меры для ее упрощения. Для этого такую программу разрабатывают по частям, которые называются программными модулями [7.1, 7.2]. А сам такой метод разработки программ называют модульным программированием [7.3]. Программный модуль  это любой фрагмент описания процесса, оформляемый как самостоятельный программный продукт, пригодный для использования в описаниях процесса. Это означает, что каждый программный модуль программируется, компилируется и отлаживается отдельно от других модулей программы, и тем самым, физически разделен с другими модулями программы. Более того, каждый разработанный программный модуль может включаться в состав разных программ, если выполнены условия его использования, декларированные в документации по этому модулю. Таким образом, программный модуль может рассматриваться и как средство борьбы со сложностью программ, и как средство борьбы с дублированием в программировании (т.е. как средство накопления и многократного использования программистских знаний).

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

7.2. Основные характеристики программного модуля.

Не всякий программный модуль способствует упрощению программы [7.2]. Выделить хороший с этой точки зрения модуль является серьезной творческой задачей. Для оценки приемлемости выделенного модуля используются некоторые критерии. Так, Хольт [7.4] предложил следующие два общих таких критерия:

• хороший модуль снаружи проще, чем внутри;
• хороший модуль проще использовать, чем построить.

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

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

Источник

Разработка программных модулей

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

3. Модели ЖЦ ПО

• каскадная модель;
• процессная или поэтапная модель с
промежуточным контролем;
• спиральная модель.

4. Каскадная модель

5. Поэтапная модель с возвратами

6. Спиральная модель

7. Технология структурного программирования

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

8.

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

9. Проектирование программы

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

10. Проектирование программы

• Абстрагирование – это процесс обобщения,
при котором внимание концентрируется на
сходстве явлений и предметов и они
объединяются в группы на основе этого
сходства.
• Уровни абстракции определяют уровни
модулей.

11. Разработка схемы иерархии

12. Конец этапа проектирования

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

13. Планирование

На этапе планирования решаются две задачи:
• планирование порядка разработки модуля;
• планирование тестов.

14. Иерархический подход.

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

15. Операционный подход

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

16. Планирование тестов

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

17. Реализация

Этап реализации включает:
• фактическую подготовку тестов;
• программирование и тестирование
модулей.

18. Структурное программирование

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

19. Тестирование программного обеспечения

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

20. Средства автоматизации разработки программм (CASE-средства)

• инструментарий для системных аналитиков,
разработчиков и программистов, позволяющий
автоматизировать процесс проектирования и
разработки программного обеспечения.
• программное средство, поддерживающее процессы
жизненного цикла программного обеспечения,
включаяанализ требований к системе,
проектирование прикладного ПО и баз данных,
генерацию кода, тестирование, документирование,
обеспечение качества, управление конфигурацией
ПО и управление проектом, а также другие
процессы (согласно стандарту ISO/IEC 14102:1995).

21. Особенности средств автоматизации разработки программ:

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

22. CASE-средствам присущи основные особенности

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

23. Интегрированное CASE-средство (комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты:

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

24. Алгоритм

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

25. Свойства алгоритма

26. Алгоритмы

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

27. Сложность алгоритма

• Это количественная характеристика
необходимых алгоритму ресурсов для
успешного решения задачи.
К ресурсам относятся:
• Время (временная сложность);
• Объем памяти (емкостная сложность).

28. Сложность алгоритма

• Оценка роста сложности: n→∞: T=O(f(n))
• Фактическая сложность (время работы в
секундах) зависит не только от алгоритма,
но и от скорости работы компьютера.
• Порядок роста сложности ограничивает
размер решаемых задач.

29. Классификация задач по классам сложности:

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

Источник