Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

4966

.pdf
Скачиваний:
3
Добавлен:
13.11.2022
Размер:
854.74 Кб
Скачать

21

 

Структурное проектирование

Цель: описание

последовательности

и

работ, выполняемых

программирование

при создании

 

 

программных средств

Начало

 

Нисходящее функциональное

Подцель: ФСА

проектирование

 

Модульное программирование

Подцель: ФМС

 

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

Подцель: Алгоритм

 

работы функций

 

программного средства

Конец

 

ФСА – функциональная структура алгоритма приложения

ФМС – функционально-модульная структура алгоритма приложения

Рисунок 3 Структурная парадигма проектирования программных продуктов

Достоинства структурного программирования:

1)структурное программирование отражает функциональную структуру информационной системы, что снижает сложность программы и облегчает понимание её другими разработчиками;

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

3)упрощается процесс тестирования и отладки.

22

Цель 1 ( Автоматизация делопроизводства )

ПодЦель 11

ПодЦель 12

( Автоматизация регистрации

( Автоматизация регистрации

документов )

поручений )

Приложение111

 

Приложение 112

 

Приложение 113

(Автоматизация ведения

 

(Автоматизация ведения

 

( Разделение доступа и

регистрационных карт

 

списков документов)

 

защиты данных)

документов)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Отформатировано: Шрифт: 11 пт Отформатировано: Шрифт: 11 пт

Функция 1111

Функция 1112

Функция 111N

Отформатировано: Шрифт: 10 пт

(Автоматизация

(Автоматизация

 

нумерации документов)

ведения записей

)

Отформатировано: Шрифт: 11 пт

Отформатировано: Шрифт: 11 пт

Функция 11111

Функция 1111N

 

( Проверка текущего

(Увеличение

 

номера документа )

текущего номера)

Отформатировано: Шрифт: 11 пт

 

 

Отформатировано: Шрифт: 11 пт

Рисунок 4 Функциональная структура алгоритма приложения (ФСА)

23

Последовательность каскадной разработки программных средств:

1)составляется текст основной программы, который содержит вызовы процедур в виде наименований («заглушек»), и отражает функциональномодульную схему алгоритма;

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

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

4)разработка заканчивается тогда, когда не останется ни одной «заглушки», которая не была бы удалена (это гарантирует обозримость фрагментов кода отсутствие ошибок);

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

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

1.5.3. Модульное проектирование и программирование

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

24

модулями и программами. В состав модуля входит: объявление и определение доступных для обработки данных; операции обработки данных; элементы взаимосвязи с другими модулями. Модули применяются в процедурной парадигме в виде библиотек функций и подпрограмм, а в объектно-ориентированной парадигме программирования и в виде библиотек классов. В языках программирования поддержка модульной структуры программных приложений осуществляется посредством специальных деклараций области видимости для программных элементов (например, в языке Си такими декларациями служат ключевые слова для указания классов памяти: extern, static).

Для управления модулями в языке Си (равно как и в С++) существуют специальные инструкции – директивы препроцессора, которые указывают, какие именно модули будут использованы при компоновке исполняемой программы

(например: # include “Имя_файла.расширение”).

Размер модуля должен ограничиваться правилом «обозримости» программного кода, т.е. количество строк исходного программного кода модуля не должно превышать нескольких страниц. Пример структуры программного модуля приведён на рисунке 5.

Сгруппируем краткие характеристики модуля:

1)модуль представляет собой совокупность логически связанных элементов, предназначенных для использования другими модулями и программами;

2)модули предназначены для хранения готовых программ;

3)объекты модуля используются другими программными единицами (процедурами, функциями);

4)модуль получает определённый набор исходных данных, выполняет обработку набора данных и возвращает один набор в виде результата;

5)модуль выполняет полный перечень операций для реализации каждой отдельной функции;

6)результат работы модуля зависит только от исходных данных и не зависит от работы других модулей;

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

приложения, которая может описывать:

 

1)

состав и подчинённость функций (при процедурном подходе);

 

2)набор программных модулей, реализующих функции;

Формат: Список

2)

 

 

3)

состав компонент объектно-ориентированного проекта.

 

25

 

Начало модуля

Файл «func.h»

 

Объявление функции

 

(описание интерфейса или прототип функции)

Объявление локальных переменных функции

Определение функции ( рабочий код функции)

Возвращаемые функцией значения

 

Конец модуля

 

Рисунок 5 − Пример структуры программного модуля

1.5.4. Объектно-ориентированная парадигма

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

26

Всостав характеристик элементов моделируемой системы должны входить:

1)свойства объекта (атрибуты);

2)функции объекта (способы поведения объекта зависимые как от собственного состояния, так и от взаимодействия с другими объектами);

3)специфические наименования самих объектов, его атрибутов и функций. Способ взаимодействия объектов — элементов одной системы, а также пове-

дение объектов (возможно связанное с состоянием самих объектов), должны определять состояние описываемой системы. Множество состояний системы определяет траекторию системы, т.е. моделирует поведение некоторой реальной системы.

Процедурная парадигма не только не обладала возможностью адекватной программной реализации описания объектов в виде комплекса «функции + данные», но и не могла описать поведение и взаимодействие объектов системы в зависимости от событий, происходящих в системе в режиме реального времени.

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

Объектно-ориентированный анализ – это метод, основанный на объектной декомпозиции, т.е. описании предметной области в виде множества естественных понятий – объектов.

Результатом объектно-ориентированного анализа должна стать модель предметной области проектируемой системы, реализованная в виде описания объектов, для упрощения работы сгруппированных в классы. Отдельный представитель класса называется экземпляром класса. Например: «студент» – это класс, в то время как конкретный студент А.И. Иванов – экземпляр класса. Данный пример можно назвать показательным способом классификации, но никак не исчерпывающим все способы. Методы и способы классификации описаны во второй главе настоящего пособия.

«В процессе объектно-ориентированного анализа мы моделируем проблему, обнаруживая классы и объекты, которые составляют словарь проблемной области. При объектно-ориентированном проектировании мы изобретаем абстракции и механизмы, обеспечивающие поведение, требуемое моделью» [2].

27

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

Результатом объектно-ориентированного проектирования должно стать описание системы в виде иерархии классов, одна часть из которых является словарем информационной системы в виде перечня наименований и свойств групп объектов, а другая часть является созданной искусственно для описания поведения проектируемой системы. Такое описание выполняется с соблюдением определённых нотаций (правил графического изображения элементов объектноориентированной модели предметной области). Заметим, что именно графическая формализация элементов объектно-ориентированной модели в виде графических примитивов позволяет автоматизировать процесс моделирования и применять программные CASE−средства автоматизированной разработки.

Следует отметить, что способ проектирования системы в виде иерархии классов позволяет вносить требуемые изменения в проект (иерархию классов) на любом этапе разработки и даже на этапе реализации, в том числе позволяет вернуться к базовым определениям классов. Такой способ проектирования лежит в основе итерационного циклического проектирования. Каскадный подход, в отличие от итерационного циклического, не позволяет вносить изменения на любом этапе работы над проектом, кроме текущего этапа. Каждый этап при каскадном подходе является своеобразной ступенью каскада перед следующим этапом и должен быть полностью завершён и доработан. Этот способ проектирования характерен для структурной парадигмы программирования.

Описание классов и поведения системы в виде взаимодействия объектов классов является первым шагом к объектно-ориентированному программированию. Преобразование языка описания иерархии классов (нотации) в синтаксис языка программирования и разработка компонентов завершает шаг итерации объектно-ориентированного программирования.

Контрольные вопросы и задания

1.Что следует отнести к высокоуровневым методам программирования?

2.Что следует отнести к низкоуровневым методам программирования?

28

3.В чём состоит отличие высокоуровневых методов от низкоуровневых методов программирования?

4.Что такое жизненный цикл информационных систем?

5.Опишите основные процессы жизненного цикла прикладной информационной системы.

6.Опишите вспомогательные процессы жизненного цикла прикладной информационной системы.

7.Дайте определение каскадной модели жизненного цикла.

8.Опишите основные этапы каскадной модели жизненного цикла.

9.Каково назначение каскадной модели жизненного цикла?

10.Дайте определение спиральной модели жизненного цикла.

11.Опишите основные этапы спиральной модели жизненного цикла.

12.Каково назначение спиральной модели жизненного цикла?

13.Опишите основные этапы итерационной модели жизненного цикла.

14.Каково назначение итерационной модели жизненного цикла?

15.В чём заключатся принципиальная разница между итерационной, спиральной и каскадной моделями?

16.Что такое парадигма программирования?

17.Перечислите все виды парадигм программирования.

18.Что такое функциональная структура алгоритма?

19.Что такое программный модуль, каково его назначение?

20.Объясните суть и назначение структурного программирования.

21.Перечислите базовые элементы структурного программирования.

22.Перечислите достоинства и недостатки структурного программирования.

23.Объясните назначение модульного программирования.

24.Чем обосновано появление объектно-ориентированного подхода?

25.Перечислите основные преимущества объектно-ориентированного подхода.

2.Объектно-ориентированные технологии

2.1. Объектно-ориентированный анализ

Целью объектно-ориентированного анализа предметной области является построение инфологической модели, т.е. формального описания предметной области в виде системы объектов. Задачами объектно-ориентированного анализа являются:

1) выявление понятий предметной области – сущностей, с точки зрения их участия в информационных процессах;

29

2)выявление абстрактных понятий – объектов из перечня выявленных сущностей;

3)создание новых совокупностей абстрактных понятий – классов, на базе выявленных объектов.

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

4)отсутствие универсального механизма реализации;

5)наличие творческого подхода к процессу анализа;

6)наличие информации о данной предметной области;

7)наличие опыта у аналитика.

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

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

Расширим формулировку цели объектно-ориентированного анализа, данную в начале этого раздела: целью объектной декомпозиции является создание системы, элементы которой обладают свойствами и способностью реагировать на

30

события, изменяющие состояние элементов системы. Причём под событиями следует понимать реальные изменения состояния элементов системы, тождественные реальным изменениям состояния сущностей в исследуемой предметной области. Например, факт поступления заявки на ремонт оборудования переводит сущность «приёмщик заказов» из состояния «ожидание» в состояние «обработка заявки». Следовательно, формализованная сущность «приёмщик заказов» как результат объектной декомпозиции, должна иметь в своём арсенале некоторые действия, адекватные происходящим событиям (факт поступления заявки). Такие действия можно назвать реакцией на события, касающиеся конкретного объекта. На этапе анализа все упомянутые возможные реакции объекта, направленные на получение одного конкретного результата, должны быть учтены и описаны. Возникает вопрос о способе, позволяющем каждому отдельному объекту реагировать строго определённым образом и только на «свои» события. Этот способ детерминированной реакции объектов на события носит название «полиморфизм», т.е. «способность к изменчивости формы реакции» и является одним из базовых принципов объектно-ориентированной парадигмы.

Таким образом, если рассматривать некоторый объект в качестве отражения некоторой сущности реальной предметной области, то этому объекту следует придать свойства реального объекта (например, способность самостоятельно выполнять некоторые действия, присущие реальному объекту). Другими словами – объект должен что-то знать и уметь. В таком случае мы приходим к необходимости понимания объекта как некоторой совокупности данных (т.е. качественных характеристик конкретного объекта) и действий, т.е. различных способов реакции объекта на изменяющуюся внешнюю среду. Следовательно, если объект (как представитель сущности информационной системы) должен иметь своё отражение в программной системе, то и средство составления программ, т.е. язык программирования, должен также иметь способы описания объектов как совокупностей данных и функций. Такие совокупности носят название «классы», а правила описания состава классов называются «правилами инкапсуляции классов».

Процедурные языки программирования не имеют средств для инкапсуляции классов, такими средствами обладают только объектно-ориентированные языки программирования.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]