maran program engineering (Маран Программная инженерия), страница 5

Далее выполняется разделение заданной задачи на подзадачи. Каждая подзадачадолжна быть логически целой, иметь четко фиксированные вход и результат.В результате получится иерархическая диаграмма, представленная на рис. 2.1.Рекомендуется выделить при декомпозиции 2–8 (лучше 3–5) подзадач.Исходные данныеРезультатЗадача1.1.1.1.11.21.31.1.2Рис.

2.1Любая задача уровня 1 должна свестись к решению подзадач уровня 2.В противном случае допущена ошибка декомпозиции. Необязательно, чтобывсе подзадачи уровня 2 были задействованы при решении всех задач уровня 1.По таким же принципам продолжаем декомпозицию.Вопрос о вводе исходных данных и выводе результата всей программы.Часто это возлагается на главный модуль. Если в каком-то модуле нужны специфические данные (только для него), то их ввод (вывод) можно возлагать и наэтот модуль.

В принципе можно предусмотреть и специальный модуль ввода(вывода).21Когда заканчивать? Существуют два критерия:1. «Счастливые случаи»:• выделена подзадача, которая представляет собой хорошо изученнуюклассическую задачу, методы решения которой известны (например, решить систему линейных алгебраических уравнений);• выделена подзадача, для решения которой уже имеется программноеобеспечение (например, сделанное в ходе предыдущих разработок).2. «Обычный случай» — подзадаче нижнего уровня соответствует программа «разумных размеров», которыми считается объем 1–2 экрана.Другим необходимым документом метода функциональной декомпозиции являются диаграммы «ввод — обработка — вывод», которые должны бытьсоставлены для каждого узла иерархической диаграммы.

Примерный внешнийвид такой диаграммы показан на рис. 2.2.Номер: например 1.1 Имя:Комментарий:ВводОбработкаВыводОписание исходных Описание процесса Описание результатаданных модуляпреобразованияввод Æ вывод,включая обращения кмодулям более низкого уровняРис. 2.2Процесс проектирования всегда итеративный: на начальных этапах ввод ивывод отдельных модулей могут быть заданы на естественном языке, в ходепроектирования должны быть определены язык и среда реализации, и к концупроектирования они должны быть заданы с использованием типов и структурданных выбранного языка.

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

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

Простой пример: преобразование числа в символьную строку удастся всегда, и сигнальная переменная не нужна; перевод символьной строки в число — не всегда. Говорят, чтопрограмма должна либо выдать ответ, либо сообщить, по какой причине ответполучить не удалось — чем точнее, тем лучше.22После завершения проектирования написание программ для разных модулей можно распараллелить.В данном пункте рассмотрена функциональная декомпозиция «сверху —вниз». В принципе возможно и проектирование «снизу — вверх», когда всяпрограмма решения сложной задачи компонуется из уже имеющихся модулейрешения отдельных задач.2.1.2. Метод анализа потоков данныхВ основе анализа потоков данных лежит диаграмма потоков данных(DFD–Data Flow Diagram). Она может быть успешно применена при автоматизации офисной деятельности, проектирования простых информационных систем.

Более современным средством является язык UML, который будет подробно рассмотрен в данном пособии позже. Но и DFD имеют будущее из-за своейпростоты и наглядности. Для рисования DFD применяют две нотации: Иордана — де Марко и Гейна — Сарсона. Они по существу ничем не отличаются, ограничимся рассмотрением первой из них. Применяемые обозначения и примердиаграммы приведены на рис. 2.3.Источник илипотребитель даныхОбработка данныхФайл или база данныхПоток данных1573264Рис. 2.323Данные из источников 1 и 2 обрабатываются процессом 3, и результатбудет записан в базу данных 4 и передан потребителю 5. Данные от потребителя 5 с привлечением данных из базы данных 4 обрабатываются в 6, результатдля 7.

Линии показывают передвижение данных между узлами. Для дальнейшей работы над процессами 3 и 6 может применяться метод функциональнойдекомпозиции: заданы ввод/вывод и описание обработки. Для реализации 4 —методы проектирования баз данных. Для 1, 2, 3, 7 необходимо разработать интерфейсы пользователя, позволяющие запустить нужные для них задачи и выполнить ввод/вывод. Представленная диаграмма может иметь и иерархическуюструктуру: на верхнем уровне источники (потребители) могут быть структурными подразделениями организации, но более низком уровне — сотрудники, накоторых возложены те или иные обязанности.2.2.

Объектно-ориентированный подходИзучению объектно-ориентированного подхода посвящена основнаячасть данного пособия, поэтому ограничимся здесь краткой характеристикой.Базовые понятия: объект и класс. Объект — это реально существующий предмет со всеми его индивидуальными особенностями. Класс — это множествообъектов с одинаковыми свойствами и одинаковым поведением. Любой сложный объект может принадлежать многим классам. Например, в аудитории вовремя учебного процесса каждый студент — представитель класса «Студентывуза», и у них совершенно одинаковые характеристики.

Но каждый из них является и представителем других классов: клуба по интересам, своей семьии т. д. В языках программирования под классом понимается структура данных,состоящая из данных и методов их обработки. Если дать значения даннымкласса, то он превратится в объект. Объект на языке программирования — этопеременная типа класс.Проектирование программного обеспечения заключается в определенииклассов и отношений между ними таким образом, чтобы, создавая объекты этихклассов, решить поставленные задачи. В ходе работы программа, построеннаяпо объектно-ориентированной методике, объекты обмениваются сообщениями(Message).

С программистской точки зрения передача сообщения от одногообъекта другому означает вызов функции объекта-адресата. Наиболее распространенной методологией разработки по объектно-ориентированной методикеявляется унифицированный процесс (УП), в оригинале именуемый RUP (Rational Unified Process; Rational — название фирмы, проповедующей ее).2.3. Agile-методикиПеречисленные выше методы разработки программного обеспечения относятся к так называемым «тяжелым» методикам.

Это означает, что результатывсех стадий жизненного цикла должны быть документированы, и они выполняются строго последовательно. В 1990-х годах стали развиваться гибкие методики, в которых весь процесс разработки программного обеспечения заключается в тесном взаимодействии заказчика и разработчика. Будут разработаны24версия за версией (на разработку новой версии от нескольких дней до нескольких недель), каждая версия тут же тестируется с участием заказчика, и намечаются пути их усовершенствования.Базовые принципы гибкой методики изложены в Agile-манифесте [3]:1. Нашим наивысшим приоритетом является удовлетворение клиента посредством ранней и непрерывной поставки ценного программного обеспечения.2. Приветствуем изменение требований даже на поздних стадиях разработки.3. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.4. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары дней до пары месяцев.5.

На протяжении всего проекта разработчики и представители бизнесадолжны ежедневно работать вместе.6. Над проектом должны работать мотивированные профессионалы. Чтобыработа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.7. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутрикоманды.8. Работающий продукт — основной показатель прогресса.9. Инвесторы, разработчики и пользователи должны иметь возможностьподдержать постоянный ритм бесконечно. Agile помогает наладить такойустойчивый процесс разработки.10.

Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.11. Простота — искусство минимизации лишней работы — крайне необходима.12. Самые лучшие требования, архитектурные и технические решения раждаются у самоорганизующхся команд.13. Команда должна систематически анализировать возможные способыулучшения эффективности и соответственно корректировать стиль своейработы.Наиболее распространенными гибкими методиками являются SCRAMтехнология и экстремальное (XP) программирование. Коротко суть этих подходов заключается в следующем:• Постоянное сотрудничество заказчика и разработчика — от постановкизадачи до тестирования.• Разработка маленькими шагами, результаты которых тут же тестируютсяи будут предъявлены заказчику.• Пожелания заказчика по усовершенствованию по возможности тут жебудут реализованы.• Разработку ведет относительно малочисленная группа специалистов, которые друг другу полностью доверяют, могут договориться.