Учебное пособие по выполнению и оформлению курсовых, дипломных и квалификационных работ москва 2002 icon

Учебное пособие по выполнению и оформлению курсовых, дипломных и квалификационных работ москва 2002


1 чел. помогло.
Смотрите также:
Методические указания по выполнению выпускных квалификационных работ и выпускных...
И. Н. Кузнецов: «Рефераты, курсовые и дипломные работы»: методика подготовки и оформления...
Методические рекомендации по оформлению рефератов...
Методические рекомендации по оформлению рефератов...
Методические рекомендации по выполнению курсовых и выпускных квалификационных работ для...
З. Ф. Коврига Уголовный процесс России...
Настоящее пособие является коллективным трудом преподавателей географического факультета...
Методические указания по оформлению рефератов...
Методические рекомендации по подготовке и оформлению дипломных и курсовых работ по юриспруденции...
Темы выпускных квалификационных работ министерство образования и науки российской федерации...
Методические рекомендации по выполнению выпускных квалификационных (дипломных) работ уфа 2009...
Методические указания по выполнению курсовых проектов...



Загрузка...
страницы: 1   2   3   4   5   6   7   8   9   10   ...   15
вернуться в начало
скачать
^

4.3.Структурные карты Константайна


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

Различают четыре типа вершин:

  • модуль – подпрограмма;

  • подсистема – программа;

  • библиотека – совокупность подпрограмм, размещенных в отдельном модуле;

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

Обозначения соответствующих вершин приведены на рис. 4.6. (Обозначения даны в соответствии со стандартами IBM, ISO и ANSI.)

Если стрелка, изображающая вызов касается блока, то обращение происходит к модулю целиком, а если входит в блок, то – к элементу внутри модуля.

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

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

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

Пример 4.2. Представим в виде структурной карты Константайна полную структурную схему, полученную в предыдущем примере (рис. 4.5).

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

Для остальных подпрограмм покажем особые условия вызова и типы связей (рис. 4.9).

Модули Расчет значений функции, Вывод таблицы и Построение графика связаны с основной программой по образцу, так как параметры X и Y структурные (массивы), следовательно, программа считается сцепленной по образцу.

Примечание. Анализ показывает, что количество сцеплений по образцу в программе можно уменьшить, если подпрограмму Расчет значений функции перенести на следующий уровень и вызывать из функций Вывод таблицы и Построение графика. Однако в этом случае мы при смене вида результата лишний раз будем считать таблицу значений.

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

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

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

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

5.Анализ требований и определение спецификаций программного обеспечения при объектном подходе

5.1.UML – стандартный язык описания разработки программных продуктов с использование объектного подхода


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

Таким образом, на этапе анализа ставятся две задачи:

  • уточнить требуемое поведение разрабатываемого ПО;

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

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

Разрабатываемое с помощью объектного подхода программное обеспечение, как правило, очень сложно, поэтому для описания разработки в настоящее время используют специальный язык – универсальный язык моделирования UML. Этот язык, авторами которого являются Г. Буч, Д. Рамбо и А. Джакобсон [1], недавно был признан стандартным средством описания объектных разработок.

Полное описание разработки с использованием UML включает несколько моделей, характеризующих определенный аспект проектируемой системы (рис. 5.2):

  • модель использования – представляет собой описание функциональности ПО с точки зрения пользователя;

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

  • модель реализации – определяет реальную организацию программных модулей;

  • модель процессов – отображает организацию вычислений и оперирует понятиями «процессы» и «нити». Она позволяет оценить производительность, масштабируемость и надежность ПО;

  • модель развертывания – показывает особенности размещения программных компонентов на конкретном оборудовании.

Всего UML предлагает девять дополняющих друг друга диаграмм, входящих в различные модели:

  • диаграммы вариантов использования;

  • диаграммы классов;

  • диаграммы пакетов:

  • диаграммы последовательностей действий;

  • диаграммы кооперации:

  • диаграммы деятельностей:

  • диаграммы состояний объектов:

  • диаграммы компонентов:

  • диаграммы размещения.

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

UML и предлагаемая теми же авторами методика разработки ПО названная Rational Unified Process поддерживаются пакетом ^ Rational Rose фирмы Rational Software Corporation. Ряд диаграмм можно получить также средствами программы Microsoft Visual Modeler и других CASE-средств.




Скачать 0,94 Mb.
оставить комментарий
страница7/15
Дата29.09.2011
Размер0,94 Mb.
ТипУчебное пособие, Образовательные материалы
Добавить документ в свой блог или на сайт

страницы: 1   2   3   4   5   6   7   8   9   10   ...   15
отлично
  1
Ваша оценка:
Разместите кнопку на своём сайте или блоге:
rudocs.exdat.com

Загрузка...
База данных защищена авторским правом ©exdat 2000-2017
При копировании материала укажите ссылку
обратиться к администрации
Анализ
Справочники
Сценарии
Рефераты
Курсовые работы
Авторефераты
Программы
Методички
Документы
Понятия

опубликовать
Загрузка...
Документы

Рейтинг@Mail.ru
наверх