Автор работы: Пользователь скрыл имя, 17 Ноября 2011 в 23:07, курсовая работа
Проектирование — итерационный процесс, при помощи которого требования к ПС транслируются в инженерные представления ПС.
Аннотация 3
ГЛАВА 1. ОСНОВЫ ПРОЕКТИРОВАНИЯ ПРОГРАММНЫХ СРЕДСТВ. Этапы проектирования и его место в жизненном цикле конструирования программных систем. 5
1.1. Основные этапы технологического процесса разработки программ. 5
Постановка задачи. 5
Выбор алгоритма. 7
1.2. Особенности этапа проектирования 8
Модульность 10
Информационная закрытость 11
Связность модуля 12
Функциональная связность 13
Информационная связность 14
Процедурная связность 15
Логическая связность 17
Определение связности модуля 19
Сложность программной системы 20
Характеристики иерархической структуры программной системы 21
ГЛАВА 2. ОПИСАНИЕ РЕАЛИЗАЦИИ ПРАКТИЧЕСКОГО ЗАДАНИЯ. Игра «PAH-TUM». 24
2.1 Техническое задание ПС 24
2.1.1. Введение 24
2.1.2. Основание для разработки 24
2.1.3. Назначение разработки 24
2.1.4. Требования к программе 24
2.1.5. Технико-экономические показатели 24
2.1.6. Стадии и этапы разработки 24
2.2 Функциональная модель 26
2.3. Описание программы 27
2.3.1. Общие сведения 27
2.3.2. Функциональное назначение 27
2.3.3. Описание логической структуры 27
2.3.4. Вызов и загрузка 28
2.3.7. Руководство пользователя 28
ЛИТЕРАТУРА 29
Элементы логически связного модуля принадлежат к действиям одной категории, и из этой категории клиент выбирает выполняемое действие.
Логически связный модуль - мешок доступных действий. Действия вынуждены совместно использовать один и тот же интерфейс модуля. В строке вызова модуля значение каждого параметра зависит от используемого действия. При вызове отдельных действий некоторые параметры должны иметь значение пробела, нулевые значения и т. д. (хотя клиент все же должен использовать их и знать их типы).
Действия в логически связном модуле попадают в одну категорию, хотя имеют не только сходства, но и различия. К сожалению, это заставляет программиста «завязывать код действий в узел», ориентируясь на то, что действия совместно используют общие строки кода. Поэтому логически связный модуль имеет:
В итоге модуль
становится сложным как для понимания,
так и для сопровождения.
Связность
по совпадению
Связный по совпадению модуль похож на логически связный модуль. Его элементы-действия не связаны ни потоком данных, ни потоком управления. Но в логически связном модуле действия, по крайней мере, относятся к одной категории; в связном по совпадению модуле даже это не так. Словом, связные по совпадению модули имеют все недостатки логически связных модулей и даже усиливают их. Применение таких модулей вселяет ужас, поскольку один параметр используется для разных целей.
Чтобы клиент мог воспользоваться модулем Разные функции, этот модуль (подобно всем связным по совпадению модулям) должен быть «белым ящиком», чья реализация полностью видима. Такие модули делают системы менее понятными и труднее сопровождаемыми, чем системы без модульности вообще!
К счастью, связность по совпадению встречается редко. Среди ее причин можно назвать:
Сцепление модулей
Сцепление (Coupling) - мера взаимозависимости модулей поданным. Сцепление - внешняя характеристика модуля, которую желательно уменьшать.
Количественно сцепление измеряется степенью сцепления (СЦ). Выделяют 6 типов сцепления.
1. Сцепление по данным (СЦ=1). Модуль А вызывает модуль В.
Все входные и выходные параметры вызываемого модуля - простые элементы данных.
2. Сцепление по образцу (СЦ=3). В качестве параметров используются структуры данных.
3. Сцепление по управлению (СЦ=4). Модуль А явно управляет функционированием модуля В (с помощью флагов или переключателей), посылая ему управляющие данные.
4. Сцепление по внешним ссылкам (СЦ=5). Модули А и В ссылаются на один и тот же глобальный элемент данных.
5. Сцепление по общей области (СЦ=7). Модули разделяют одну и ту же глобальную структуру данных.
6. Сцепление по содержанию (СЦ=9). Один модуль прямо ссылается на содержание другого модуля (не через его точку входа). Например, коды их команд перемежаются друг с другом.
В простейшем случае сложность системы определяется как сумма мер сложности ее модулей. Сложность модуля может вычисляться различными способами.
Например, М. Холстед (1977) предложил меру длины N модуля:
N » n1log2 (n1) + n2log2(n2),
где n1 - число различных операторов, п2 - число различных операндов.
В качестве второй метрики М. Холстед рассматривал объем V модуля (количество символов для записи всех операторов и операндов текста программы):
V = N x log2 (n1+ n2).
Вместе с тем известно, что любая сложная система состоит из элементов и системы связей между элементами и что игнорировать внутрисистемные связи неразумно.
Том МакКейб (1976) при оценке сложности ПС предложил исходить из топологии внутренних связей. Для этой цели он разработал метрику цикломатической сложности:
V(G) = E-N + 2,
где Е - количество дуг, a N - количество вершин в управляющем графе ПС. Это был шаг в нужном направлении. Дальнейшее уточнение оценок сложности потребовало, чтобы каждый модуль мог представляться как локальная структура, состоящая из элементов и связей между ними.
Таким образом,
при комплексной оценке сложности
ПС необходимо рассматривать меру сложности
модулей, меру сложности внешних
связей (между модулями) и меру сложности
внутренних связей (внутри модулей). Традиционно
со внешними связями сопоставляют характеристику
«сцепление», а с внутренними связями
- характеристику «связность».
Игра «Pah-tum» - программный продукт, реализована на основе игры «Крестики-нолики». Области применения очень широки: от домашних пользователей, до офисных работников.
Основанием для разработки программного продукта «Pah-tum» является обязательное требование ко всем студентам Тюменского Государственного Университета, Института Математики Естественных Наук и Технологий, Кафедры Программного Обеспечения по дисциплине "Разработка и Стандартизация Программных Средств и Информационных Технологий" к практической части курсовой работы.
Программный продукт «Pah-tum» предназначен для развития у игрока мышления, тактических навыков и внимания.
Игра «Pah-tum» - программа, не требующая дополнительного программного обеспечения для ее функционирования. Игра написана в среде разработки Borland Delphi 7, на языке программирования Object Pascal.
Данная
программа решает такой класс
задач как обучение: пользователь
учится рационально правильно мыслить,
строить выгодные комбинации, шаги
наперед при использовании
Структура программы:
Project1.dpr
– основной проект программы,
связывающий все формы с
Project1.exe – исполняемый файл программы;
Unit1.pas – модуль главной формы(поле);
Unit3.pas –
модуль формы «Таблица
Unit4.pas – модуль формы «Помощь»;
Unit5.pas – модуль формы «Регистрация»;
Также
в папке «Puh-Tum» имеется
Чтобы вызвать на запуск программу, необходимо в папке «Puh-Tum» запустить файл Project1.exe.
Чтобы вызвать на запуск программу, необходимо в папке «Puh-Tum» запустить файл Project1.exe.
Перед вами появится основная форма игры (Рис. 2.3.1. Основная форма)
Для того чтобы начать игру нажмите кнопку, где изображен темный шарик, без изображения (Рис. 2.3.2. Начать игру ).
Так же вы можете вызвать справку (Рис. 2.3.8.Справка).
http://www.uchi-it.ru/7/6/10.