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

Логическая  связность

Элементы логически  связного модуля принадлежат к действиям  одной категории, и из этой категории  клиент выбирает выполняемое действие.

Логически связный модуль - мешок доступных действий. Действия вынуждены совместно использовать один и тот же интерфейс модуля. В строке вызова модуля значение каждого параметра зависит от используемого действия. При вызове отдельных действий некоторые параметры должны иметь значение пробела, нулевые значения и т. д. (хотя клиент все же должен использовать их и знать их типы).

Действия в  логически связном модуле попадают в одну категорию, хотя имеют не только сходства, но и различия. К сожалению, это заставляет программиста «завязывать  код действий в узел», ориентируясь на то, что действия совместно используют общие строки кода. Поэтому логически  связный модуль имеет:

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

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

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

Чтобы клиент мог  воспользоваться модулем Разные функции, этот модуль (подобно всем связным по совпадению модулям) должен быть «белым ящиком», чья реализация полностью видима. Такие модули делают системы менее понятными и  труднее сопровождаемыми, чем системы  без модульности вообще!

К счастью, связность  по совпадению встречается редко. Среди  ее причин можно назвать:

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

Сцепление модулей

Сцепление (Coupling) - мера взаимозависимости модулей поданным. Сцепление - внешняя характеристика модуля, которую желательно уменьшать.

Количественно сцепление измеряется степенью сцепления (СЦ). Выделяют 6 типов сцепления.

1. Сцепление по данным (СЦ=1). Модуль А вызывает модуль В.

Все входные  и выходные параметры вызываемого модуля - простые элементы данных.

2. Сцепление по образцу (СЦ=3). В качестве параметров используются структуры данных.

3. Сцепление по управлению (СЦ=4). Модуль А явно управляет функционированием модуля В (с помощью флагов или переключателей), посылая ему управляющие данные.

4. Сцепление по внешним ссылкам (СЦ=5). Модули А и В ссылаются на один и тот же глобальный элемент данных.

5. Сцепление по общей области (СЦ=7). Модули разделяют одну и ту же глобальную структуру данных.

6. Сцепление по содержанию (СЦ=9). Один модуль прямо ссылается на содержание другого модуля (не через его точку входа). Например, коды их команд перемежаются друг с другом.

Сложность программной системы 

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

Например, М. Холстед (1977) предложил меру длины N модуля:

N » n₁log₂ (n₁) + n₂log₂(n₂),

где n₁ - число различных операторов, п₂ - число различных операндов.

В качестве второй метрики М. Холстед рассматривал объем V модуля (количество символов для записи всех операторов и операндов текста программы):

V = N x log₂ (n₁+ n₂).

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

Том МакКейб (1976) при оценке сложности ПС предложил  исходить из топологии внутренних связей. Для этой цели он разработал метрику цикломатической сложности:

V(G) = E-N + 2,

где Е - количество дуг, a N - количество вершин в управляющем графе ПС. Это был шаг в нужном направлении. Дальнейшее уточнение оценок сложности потребовало, чтобы каждый модуль мог представляться как локальная структура, состоящая из элементов и связей между ними.

Таким образом, при комплексной оценке сложности  ПС необходимо рассматривать меру сложности  модулей, меру сложности внешних  связей (между модулями) и меру сложности  внутренних связей (внутри модулей). Традиционно со внешними связями сопоставляют характеристику «сцепление», а с внутренними связями - характеристику «связность». 

ГЛАВА 2. ОПИСАНИЕ РЕАЛИЗАЦИИ ПРАКТИЧЕСКОГО ЗАДАНИЯ. Игра «PAH-TUM».

2.1 Техническое задание  ПС

2.1.1. Введение

Игра  «Pah-tum» - программный продукт, реализована  на основе игры «Крестики-нолики». Области  применения очень широки: от домашних пользователей, до офисных работников.

2.1.2. Основание для  разработки

Основанием  для разработки программного продукта «Pah-tum» является обязательное требование ко всем студентам Тюменского Государственного Университета, Института Математики Естественных Наук и Технологий, Кафедры  Программного Обеспечения по дисциплине "Разработка и Стандартизация Программных  Средств и Информационных Технологий" к практической части курсовой работы.

2.1.3. Назначение разработки

Программный продукт «Pah-tum» предназначен для  развития у игрока мышления, тактических  навыков и внимания.

2.1.4. Требования к программе

• Функциональные  характеристики: Многоуровневая сложность  игры, сохранение и очистка результатов, возможность сохранения и загрузки игры.
• Требования к информационной и программной совместимости: Написание программы на языке программирования Delphi. В качестве интегрированной среды разработки программы используется среда Borland Delphi.

2.1.5. Технико-экономические  показатели

• Экономическая эффективность и годовая потребность  не рассчитываются

2.1.6. Стадии и этапы  разработки

• Этапы разработки:

1. планирование (постановка задачи, определение функций ПС);
2. Реализация (программирование и отладка);
3. Тестирование (поиск недочетов, проверка оптимальности);
4. Разработка документации(составление технической документации, подготовка руководства пользователя);

 

2.2 Функциональная модель

2.3. Описание программы

2.3.1. Общие сведения

Игра  «Pah-tum» - программа, не требующая дополнительного программного обеспечения для ее функционирования. Игра написана в среде разработки Borland Delphi 7, на языке программирования Object Pascal.

2.3.2. Функциональное назначение

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

  2.3.3. Описание логической структуры

Алгоритм  программы:

Структура программы:

Project1.dpr – основной проект программы,  связывающий все формы с модулями  и отвечающий за выполнение  их алгоритмов;

Project1.exe – исполняемый файл программы;

Unit1.pas –  модуль главной формы(поле);

Unit3.pas –  модуль формы «Таблица рекордов»;

Unit4.pas –  модуль формы «Помощь»;

Unit5.pas –  модуль формы «Регистрация»;

Также в папке «Puh-Tum» имеется папка  «Img» где хранятся картинки. Файл «Rezultatiki.txt» - текстовый файл с информацией  о рекордах.

2.3.4. Вызов и загрузка

Чтобы вызвать на запуск программу, необходимо в  папке «Puh-Tum» запустить файл Project1.exe.

2.3.7. Руководство пользователя

Чтобы вызвать на запуск программу, необходимо в  папке «Puh-Tum» запустить файл Project1.exe.

Перед вами появится основная форма игры (Рис. 2.3.1. Основная форма)

 

Для того чтобы начать игру нажмите кнопку, где изображен темный шарик, без  изображения (Рис. 2.3.2. Начать игру ).

Или можете зайти в Меню, нажать на кнопочку Рекорды, из выпадающего списка выберете Новую игру (Рис. 2.3.3).

Появляется  поле для регистрации. В поле вы можете ввести свое имя. Нажимаете «окей» (Рис. 2.3.4 Регистрация).

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

Ваша  задача собрать в горизонтальный или вертикальный ряд три ячейки. Чем больше вы наберете очком, тем  больше шанс выиграть (Рис. 2.3.5 Игра).

Играете до тех пор, пока поле не будет полностью  заполнено. После чего появляется уведомление  о результате вашей игры (Рис.2.3.6 Результат).

Теперь  вы можете сыграть ещё раз.

В любое  время игры вы можете посмотреть таблицу  рекордов (Рис.2.3.7.Рекорды).

 

Так же вы можете вызвать справку (Рис. 2.3.8.Справка).

 

ЛИТЕРАТУРА

1. Боэм Б. У. Инженерное проектирование программного обеспечения. М.: ДМК, 1985.- 511 с.
2. Липаев В. В. Отладка сложных программ: Методы, средства, технология. М.: ДМК, 1993.- 384 с.
3. Майерс Г. Искусство тестирования программ. М.: ДМК, 1982.- 176с.
4. Ковалев А.Д., Никитин С.В. Организация работы с множествами в инструментальной среде разработки программных модулей//Вычислительные методы и программирование.-2000. №1.-  с.31-36.
5. Арушанян О.Б., Богомолов Н.А., Ковалев А.Д. Об одном подходе к автоматизации создания приложений, ориентированных на работу со сложными структурами данных// Вычислительные методы и программирование.-2005. №6.- с.1-9.
6. Коллекция учебников по информационным технологиям, 2009, [on-line]:

http://www.uchi-it.ru/7/6/10.html

7. Технологии разработки программных продуктов, 2011,[on-line]: