- •Технология разработки программного обеспечения
- •Содержание
- •Введение
- •1 Краткие теоретические аспекты курса
- •1.3 Качество программного обеспечения (по)
- •1.4 Стиль программирования
- •1.5 Модульное программирование
- •1.6 Методы проектирования программных средств
- •1.7 Отладка и тестирование пс
- •1.8 Надежность пс
- •1.9 Документация пс
- •1.10 Перечень вопросов, изучаемых в курсе «Технология разработки программного обеспечения»
- •2.2 Общие требования к разработке пс
- •2.3 Организация графического интерфейса
- •2.4 Требования к программной документации
- • Виды программных документов гост 19.101-77;
- • Схемы алгоритмов, программ данных и систем гост 19.701-90;
- •2.6 Задания для курсового проектирования
- •Вариант №1
- •Вариант №6
- •Вариант №7
- •Вариант № 9
- •3 Лабораторные задания
- •3.2 Лабораторная работа № 2. Тема: «Стиль программирования»
- •Вариант № 15
- •Вариант №22
- •3.3 Лабораторная работа № 3. Тема: «Модульное проектирование пс»
- •Вариант №1
- •3.4 Лабораторная работа № 4. Тема: «Отладка и тестирование пс»
- •Вариант №9
- •Вариант №10
- •Вариант №12
- •Вариант №2
- •Вариант №3
- •Вариант № 4
- •Список использованных источников
- •Приложение а
- •Приложение в
- •Схемы, используемые при проектирование пс
- •Приложение з
- •Пример оформления списка использованных источников
- •Д.Тейлор, Дж.Мишель, Дж.Пенман, т.Гоггин, Дж.Шемитц, Delphi3, Санкт-Петербург, 1998. – 300 с.
- •Ч.Петзольд, Программирование для Windows95, Тома 1 - 2,bhv– Санкт-Петербург, 1997.
- •Джефф Когсвелл. Изучи сам Delphi2.0 сегодня, Минск, 1997.
- •А.М.Епанешников, в.А.Епанешников. Программирование в среде TruboPascal7.0, Москва, 1995.
1.4 Стиль программирования
Стиль программирования связан с удобочитаемостью программы.
Правила хорошего стиля программирования – это результат соглашения между опытными программистами.
Правило стандартизации стиля заключается в следующем: если существует более одного способа сделать что-либо и выбор произвольный, остановитесь на одном способе, и всегда его придерживайтесь. Программное средство представленное в хорошем стиле имеет комментарии (пояснительные, вводные иногда оглавления), значимые идентификаторы, хорошо воспринимаемый текст ПС.
Пользовательский интерфейс также должен быть разработан в хорошем стиле, придерживаясь следующих рекомендаций:
пользовательский интерфейс должен базироваться на терминах и понятиях, знакомых пользователю;
пользовательский интерфейс должен быть единообразным;
пользовательский интерфейс должен позволять пользователю исправлять собственные ошибки;
пользовательский интерфейс должен позволять получение пользователем справочной информации: как по его запросу, так и генерируемой ПС.
1.5 Модульное программирование
Приступая к разработке каждой программы ПС, следует иметь в виду, что она, как правило, является большой системой, поэтому мы должны принять меры для ее упрощения. Для этого такую программу разрабатывают по частям, которые называются программными модулями. А сам такой метод разработки программ называют модульнымпрограммированием.Программный модульэто любой фрагмент описания процесса, оформляемый как самостоятельный программный продукт, пригодный для использования в описаниях процесса. Это означает, что каждый программный модуль программируется, компилируется и отлаживается отдельно от других модулей программы, и тем самым, физически разделен с другими модулями программы. Более того, каждый разработанный программный модуль может включаться в состав разных программ, если выполнены условия его использования, декларированные в документации по этому модулю. Таким образом, программный модуль может рассматриваться и как средство борьбы со сложностью программ, и как средство борьбы с дублированием в программировании (т.е. как средство накопления и многократного использования программистских знаний).
Программы разбиваются на модули для того, чтобы:
упростить их разработку и реализацию;
облегчить чтение программ;
упростить их настройку и модификацию;
облегчить работу с данными, имеющими сложную структуру;
избежать чрезмерной детализации алгоритмов;
обеспечить более выгодное размещение программ в памяти ЭВМ.
Не всякий программный модуль способствует упрощению программы. Выделить хороший с этой точки зрения модуль является серьезной творческой задачей. Для оценки приемлемости выделенного модуля используются некоторые критерии. Так, Хольт предложил следующие два общих критерия:
хороший модуль снаружи проще, чем внутри;
хороший модуль проще использовать, чем построить.
Майерс предлагает для оценки приемлемости программного модуля использовать более конструктивные его характеристики:
размер модуля;
прочность модуля;
сцепление с другими модулями;
рутинность модуля (независимость от предыстории обращений к нему).
Размермодуля измеряется числом содержащихся в нем операторов или строк. Модуль не должен быть слишком маленьким или слишком большим. Маленькие модули приводят к громоздкой модульной структуре программы и могут не окупать накладных расходов, связанных с их оформлением. Большие модули неудобны для изучения и изменений, они могут существенно увеличить суммарное время повторных трансляций программы при отладке программы. Обычно рекомендуются программные модули размером от нескольких десятков до нескольких сотен операторов.
Прочность(связность)модуляэто мера его внутренних связей. Чем выше прочность модуля, тем больше связей он может спрятать от внешней по отношению к нему части программы и, следовательно, тем больший вклад в упрощение программы он может внести.
Сцеплениемодуляэто мера его зависимости по данным от других модулей. Характеризуется способом передачи данных. Чем слабее сцепление модуля с другими модулями, тем сильнее его независимость от других модулей.
Рутинностьмодуляэто его независимость от предыстории обращений к нему. Модуль будем называтьрутинным, если результат (эффект) обращения к нему зависит только от значений его параметров (и не зависит от предыстории обращений к нему). Модуль будем называтьзависящим от предыстории, если результат (эффект) обращения к нему зависит от внутреннего состояния этого модуля, изменяемого в результате предыдущих обращений к нему. Майерс не рекомендует использовать зависящие от предыстории (непредсказуемые) модули, так как они провоцируют появление в программах хитрых (неуловимых) ошибок. Однако такая рекомендация является неконструктивной, так как во многих случаях именно зависящий от предыстории модуль является лучшей реализаций информационно прочного модуля. Поэтому более приемлема следующая (более осторожная) рекомендация:
всегда следует использовать рутинный модуль, если это не приводит к плохим (не рекомендуемым) сцеплениям модулей;
зависящие от предыстории модули следует использовать только в случае, когда это необходимо для обеспечения параметрического сцепления;
в спецификации зависящего от предыстории модуля должна быть четко сформулирована эта зависимость таким образом, чтобы было возможно прогнозировать поведение (эффект выполнения) данного модуля при разных последующих обращениях к нему.
В связи с последней рекомендацией может быть полезным определение внешнего представления (ориентированного на информирование человека) состояний зависящего от предыстории модуля. В этом случае эффект выполнения каждой функции (операции), реализуемой этим модулем, следует описывать в терминах этого внешнего представления, что существенно упростит прогнозирование поведения данного модуля.