Технологии программирования (Software Engineering)

Технологии программирования (Software Engineering)

Классические технологические процессы

Начнем знакомство с " девятки" классических технологических процессов.

• 2.1. Возникновение и исследование идеи
• 2.1.1. Возникновение идеи решения проблемы
• 2.1.2. Постановка задачи
• 2.1.3. Принятие решения о начале работы над проектом
• 2.2. Управление
• 2.2.1. Управление проектом
• 2.2.2. Эволюция менеджмента
• 2.2.3. Методы управления проектами
• 2.2.4. Современные подходы к управлению проектом

Сначала неизбежно идут: мысль, фантазия, сказка. За ними следует научный расчет, и уже, в конце концов, исполнение венчает мысль. К. Э. Циолковский

• 2.3. Анализ требований и проектирование
• 2.3.1. Введение в анализ требований и проектирование
• 2.3.2. Отступление " о спецификациях"
• 2.3.3. Отступление " об архитектуре"
• 2.3.4. Отступление " о классификации всего сущего"
• 2.3.5. Проектирование архитектуры (проектирование " в большом" )
• 2.3.6. Проектирование модулей (проектирование " в малом" )
• 2.3.7. Методы анализа и построения спецификаций
• 2.3.8. Подходы к ведению анализа и проектирования
• 2.4. Программирование (реализация)
• 2.4.1. Стиль программирования
• 2.4.2. Защитное программирование
• 2.4.3. Выбор языка программирования
• 2.5. Тестирование и отладка
• 2.5.1. Введение в тестирование и отладку
• 2.5.2. Тестирование программных продуктов
• 2.5.3. Отладка программных продуктов
• 2.6. Ввод программы в действие
• 2.7. Эксплуатация и сопровождение
• 2.8. Завершение эксплуатации

Возникновение и исследование идеи

Погоня за идеей - занятие столь же захватывающее, как и погоня за китом.
Генри Норрис Рассел

Этот классический процесс имеет следующие действия:

• собственно возникновение и первичное исследование идеи, носящее максимально творческий и неформальный характер;
• детальное исследование идеи. Выработка концепции. Постановка задачи. Создание " одностраничного описания проекта" и разработка его расширенной версии;
• экспертиза идеи специалистами. Принятие решения о начале процесса планирования.

Заметим, что идея может привести либо к развитию уже существующего программного продукта, либо к созданию нового.

2.1.1. Возникновение идеи решения проблемы

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

• препятствует созданию или развитию программного продукта;
• приводит к ошибкам в программном продукте.

Наиболее интересными являются инновационные решения. Инновация - нововведение, изменяющее уже существующую результативную систему, как правило, с положительным эффектом или предлагающее новое решение некоторой проблемы в обозначенные время и месте [Косовский, Хитров 1997]. Инновация включает в себя и изобретения, и открытия, и просто новшества. Результативная инновация - это инновация, изменяющая уже существующее решение с улучшением некоторых его характеристик, либо предлагающая к ранее не решенной проблеме решение, приносящее положительный эффект. Примеры результативных инноваций в программировании - создание глобальной сети Интернет и разработка интегрированной среды программирования.

В научном творческом поиске [Шевчук, Харахоркина, Журавлев, Армен 1998] отрицательный результат, как правило, также имеет существенное значение. С самого начала научного поиска следует понять - где проходит граница между знанием и незнанием. Научный поиск отличает определенное достоинство, заключающееся в верности критерию сдержанности и проверки идей, систематичности объяснений.

Поиск решения может включать эвристические правила. В качестве примеров укажем подход, предложенный Д. Пойа [Пойа 1957] для решения новых задач, и алгоритм решения изобретательских задач Г. С. Альтшуллера. (http: //www.triz.minsk.by/index0.htm). Роль интуиции в творческом поиске исследуется в книге " Интуиция и искусственный интеллект" [Грановская, Березная 1991].

Предложим несколько советов по организации поиска решения задачи [Косовский, Хитров 1997].

• Ждать, пока решение не придет в голову. Лишь при затянувшемся ожидании следует переходить к другим советам. Следует заметить, что особенно эффективен этот совет для ответа на следующие вопросы: " Что такое любовь? ", " Что такое старость? ".
• Следует понять - в чем смысл вопроса. Зачем вообще решать эту задачу? Здесь уместен принцип " выковыривания изюминки" - чтобы начать выковыривать изюминку, надо сначала найти булку с изюмом.
• Найти язык чертежей, формул, программ, на котором удается переформулировать задачу. Возможно, при переформулировке что-то станет яснее.
• Фиксировать внимание к произвольным мыслям и ощущениям.
• Выразить задачу на простом (детском), метафорическом языке. Поиск аналогий может привести к открытию новых фактов.

Эдвард де Боно (Edward de Bono) выделяет два типа мышления с соответствующими подходами решения задач (http: //www.edwarddebono.org),

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

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

2.1.2. Постановка задачи

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

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

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

Одностраничный документ

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

Краткий обзор

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

Введение

• Название проекта: Руководство пользователя по OpenMP.
• Дата подготовки документа: 19 августа 1998 версия 1.3.

Описание особенностей поставки

• Документ " Руководство пользователя по OpenMP" будет доступен как на сервере компании в сети Интернет, так и в бумажной копии.
• Поскольку в данной реализации проекта " Волхов" не будут включены все особенности спецификации OpenMP, необходимо четко указать, какие из них будут реализованы, а какие нет.
• Полная спецификация по OpenMP доступна в Интернете (http: //www.openrap.org/).

Пользователи документа

Пользователь - опытный программист на языках С, C++, Pascal и FORTRAN, понимающий преимущества распараллеливания программ на многопроцессорных ЭВМ.

Сравнительный анализ

Многие разработчики компиляторов (например, компании SGI, Sun, IBM) уже включили поддержку OpenMP. Описание OpenMP они включают как отдельные главы в руководство пользователя по компиляторам с языков С, C++, Pascal и FORTRAN. С нашей точки зрения, лучшим решением будет иметь единый документ для всех компиляторов.

Зависимости

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

Список основных документов

Спецификация OpenMP.

Основные даты

• Завершение проектирования " руководства" - апрель 1998 г.
• Первый вариант полного " руководства" - август 1998 г.

Ресурсы

Ресурсы, необходимые для реализации данного проекта, представлены в табл. 3.1.

Таблица 3.1. Ресурсы, необходимые для реализации проекта

Функция	Ставка	Комментарии
Инженер-разработчик	0.1	Консультирующий инженер, реализующий OpenMP
Технический писатель	1.0	Подготовка документа
Руководитель проекта	0.3	Управление, разработка плана и содержания

2.1.3. Принятие решения о начале работы над проектом

Выясните сначала факты, а потом можете извращать их по своему усмотрению.
М. Твен

Практически всегда перед принятием решения проводится экспертиза идеи и проекта, который на ней основан. Специалисты должны в течение нескольких дней изучить и проанализировать идею. В их задачу входят два основных момента [Баранов 1998].

• Подтвердить или поправить все предположения, на которых базируется проект. На основании этих предположений будут делаться все дальнейшие построения.
• Выявить и охарактеризовать все критические моменты в проекте. Специалисты должны указать - что не предусмотрено и к каким последствиям это может привести.

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

2.2. Управление

Любую техническую проблему можно преодолеть, имея достаточно времени и денег.
Закон Лермана

Вам никогда не будет хватать либо времени, либо денег.
Следствие из закона Лермана

Этот процесс длится почти весь жизненный цикл программного продукта, но поставили мы его в данном месте потому, что одним из важнейших действий управления является планирование, которое начинается вслед за принятием решения о том, что " проекту - жить".

2.2.1. Управление проектом

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

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

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

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

Предпринимательская деятельность фирмы строится исходя из этой задачи, объединяющей пять направлений [Пашкус, Мисько 1991].

• Стратегию в области исследования и развития.
• Оперативную стратегию.
• Финансовую стратегию.
• Маркетинговую стратегию.
• Стратегию человеческих отношений.

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

Определим управление (менеджмент) как систему принятия решений в области управления фирмой и поделим всех служащих компании на четыре, уровня.

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

Лидерами команд разработчиков обычно являются два специалиста, тесно работающих вместе по всем направлениям разработки.

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

Заметим, что часто в небольших проектах и командах обе задачи исполняет один человек.

Обязанности управляющего

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

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

• планирование проекта;
• распределение работ;
• выбор наилучшей стратегии.

Исключительная ответственность менеджера заключается:

• в организации взаимосвязей внутри организации;
• в управлении сотрудниками. Менеджер ищет и привлекает лучших специалистов и экспертов для решения возникающих проблем;
• в руководстве проектом и контролем его выполнения. Менеджер отвечает за ежедневное руководство данным проектом. Хороший менеджер отводит различные проблемы от группы, он " гасит" нагоняи от заказчика или вышестоящего руководства;
• в том, чтобы проект отвечал требованиям заказчика. Руководитель должен держать заказчика в курсе всех событий проекта;
• в ответственности за поступление средств.

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

Еще раз обратимся к понятию " проект" и выделим четыре характеристики, делающих деятельность - проектом [Баранов 1998].

• Направленность на достижение конкретных целей. Действительно проекты направлены на получение определенных результатов. Кстати, цели должны быть сформулированы так, чтобы всегда было ясно, что цель достигнута и проект можно заканчивать. Проект обычно предполагает наличие промежуточных целей, которые вместе образуют взаимосвязанный комплекс.
• Координированное выполнение взаимосвязанных действий. Здесь следует еще раз вспомнить сложность разработки программного продукта. Взаимосвязи в проекте не всегда очевидны. Некоторые задания должны выполняться строго последовательно, а некоторые - строго параллельно.
• Ограниченная протяженность во времени с определенным началом и концом. Проект имеет определенный срок. Иногда этот срок плавающий, например, начинающийся от некоторой еще не определенной даты вступления договора в силу. Проект существует столько времени, сколько его требуется для получения конечного результата.
• Уникальность и важность. Уникальность должна объяснять - почему надо создавать данный программный продукт, почему нельзя взять что-то готовое. Элемент важности должен демонстрировать - почему разрабатываемый продукт нужен и важен заказчику, какие нужды и потребности заказчика он покрывает.

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

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

Менеджер не должен позволять вмешиваться кому-либо другому в руководство проектом. На ежедневное руководство в среднем у него должно уходить 50% рабочего времени. Если менеджер тратит менее 50% времени на руководство, это означает, скорее всего, что он плохой руководитель и проект ждут серьезные проблемы.

О том, куда уходит время
Существует так называемый " феномен 5-го телефонного звонка". Он заключается в том, что нужный, но неизвестный пока человек находится в среднем после пятого телефонного звонка. Это объясняет, почему руководитель тратит так много времени на деятельность, связанную с осуществлением руководства.

Мотивация

А на фига?!
А. Вознесенский

Метод " Кнута и Пряника" - алгоритм, описанный в известной монографии
Кнута [Кнут 2000] и позднее модифицированный
русским программистом Пряником.
Программистский фольклор

Руководителям было издавна известно, что людей следует побуждать к действиям для достижения некоторого желательного результата. Мотивация - это процесс побуждения себя и других к деятельности для достижения некоторых целей [Овсянко 1999]. Исторически первый подход к мотивации имеет название метод " кнута и пряника". Он заключался в побуждении либо под угрозой наказания, либо с использованием поощрения, либо комбинацией этих двух методов. Существует ряд психологических принципов, лежащих в основе теории мотивации.

• Гедонизм - заинтересованность людей делать то, что им приятно и уклоняться от того, что им неприятно. Менеджер может создать приятную обстановку на работе и таким образом мотивировать подчиненных.
• Инстинкты - автоматическая предрасположенность людей вести себя определенным образом. Некоторые люди находят удовольствие в том, чтобы ходить на работу, поскольку " рождены работать".
• Концепция побуждений - формирование привычек на основе действий, которые приводили к удовлетворяющему результату в прошлом.
• Когнитивная теория - рациональное поведение людей в соответствии с тем, что они думают о будущем. Менеджер может сформировать у работников впечатление о выгодности определенного поведения у подчиненных.

Потребность - осознанная недостаточность чего-либо. Именно потребности заставляют людей действовать определенным образом. Выделяют две основные группы потребностей.

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

Потребности можно удовлетворять с помощью вознаграждения. Менеджеры могут использовать внутренние вознаграждения (которые дает сама работа) и внешние (денежные выплаты и продвижение по службе).

Абрахам Маслоу (Abraham Maslow) в 40-х годах XX века разделил потребности на пять категорий.

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

Перечисленные потребности образуют возрастающую иерархию. В каждый момент времени поведение человека определяется самой сильной из неудовлетворенных потребностей. Однако потребности высших уровней не мотивируют человека, пока не удовлетворены хотя бы частично потребности низших уровней. Менеджеры, работающие на международном уровне, должны иметь в виду, что относительная значимость различных потребностей людей может меняться в разных странах [Овсянко 1999].

Эволюция менеджмента

Наводить порядок надо тогда, когда еще нет смуты.
Лао Цзы

Основы менеджмента были заложены в начале XX века в европейской и американской науке. История менеджмента связана с древним Египтом и философами античности. В настоящее время можно говорить об особенностях европейского, американского, японского и российского менеджмента.

Методы управления проектами

В основе методов управления проектами лежат методики сетевого планирования, разработанные в конце 50-х годов XX века [Филлипс, Гарсиа-Диас 1984]. С помощью этих методик руководитель проекта может:

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

Следующие два метода были разработаны параллельно и независимо.

• Метод Критического Пути (МКП). Метод разработан фирмой " Дюпон де Немур". Первоначально назывался методом Уолкера-Келли, по именам создателей. Позже получил название МКП (СРМ - Critical Path Method).
• Метод анализа и оценки программ ПЕРТ (PERT - Program Evaluation and Review Technique). Метод был разработан корпорацией " Локхид" и консалтинговой фирмой " Буз, Аллен энд Гамильтон" и применен в военно-морских силах США для ускорения разработки баллистической ракеты " Поларис" для подводных лодок.

Для описания современных проектов, в которых связи между работами значительно сложнее, данные средства оказались недостаточными. Метод сетевого планирования описывает зависимости работ средствами теории графов [Романовский 1999].

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

Подчеркнем в виде неформальных требований необходимость наличия плана [Баранов 1998].

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

Заметим, что первое действие процесса планирования - это принятие решения о начале планирования.

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

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

В рамках планирования управляющий решает также организационные задачи:

• Анализ документации на полноту, содержание, аккуратность.
• Назначение начальной и конечной дат работ.
• Определение интерфейсов приложения и планирование работ по детальному проектированию интерфейсов.

Работа не может начаться раньше, чем будут выполнены все предшествующие ей работы. Продолжительность выполнения всего проекта не может быть меньше, чем сумма продолжительностей работ, входящих в любой путь от начального до заключительного события. Длиной пути назовем сумму продолжительностей работ, входящих в путь. Критическим путем будем называть путь наибольшей длины [Романовский 1999]. Наибольший риск в выполнении проекта будет иметь задержка в работах на критическом пути.

Распределение работ

Распределение работ включает определение уровня квалификации для исполнителей задач, составление списка потенциальных участников проекта и " отображение" исполнителей на задачи. Типичной проблемой может быть сопоставление требуемым рабочим местам тех потенциальных исполнителей, чей уровень квалификации не полностью соответствует требуемому. Существует несколько эвристических правил для персональных назначений [Conger 1994].

• Назначать опытных и квалифицированных людей на наиболее сложные задачи в критическом пути. Людей с меньшим количеством опыта - на менее сложные задачи и т. д.
• Определить последовательность работ для каждого исполнителя.
• Не перегружать исполнителей задачами, для исполнения которых потребуется больше времени, чем есть в реальности.

О важности выбора
Одного и того же можно достичь разными способами. Предложение одного единственного пути может говорить о профессиональной непригодности руководителя в условиях свободного рынка [Баранов 1998]. Он должен изложить не менее трех способов решения задачи и продемонстрировать понимание всех этих способов. Только тогда можно обсуждать достоинства и недостатки каждого из этих подходов. Только тогда можно выбрать тот, который в данной ситуации наиболее годится.

Структурная методология

Проектирование архитектуры (проектирование " в большом" ) для структурной методологии включает следующие основные методы:

• метод нисходящего проектирования;
• метод восходящего проектирования;
• метод расширения ядра.

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

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

Метод нисходящего проектирования представляет собой подход функциональной декомпозиции на основе двух стратегий.

• Пошагового уточнения - при котором на каждом следующем этапе декомпозиции определяются модули очередного, более низкого уровня.
• Анализа сообщений - при котором анализируются потоки данных, обрабатываемые модулями.

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

Метод расширения ядра - подход, при котором основное внимание уделяется выявлению множества вспомогательных модулей, а не определению функции всей программы в целом.

Структурная методология

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

• Диаграммы " сущность-связь".
• Структурные карты.
• Диаграммы деятельности.
• Диаграммы Варнье-Орра.
• Диаграммы переходов состояний.
• Блок-схемы.
• Схемы экранов.
• Псевдокод.

Диаграмма " сущность-связь" (Entity-Relation Diagram - ERD) - предназначена для разработки моделей данных и обеспечивает стандартный способ определения данных и отношений между ними.

При создании таких моделей рассматривают понятия:

• Сущность - это такая абстракция множества объектов реального мира, в которой все предметы этого множества имеют одинаковые характеристики и согласованы с одним и тем же набором правил и линий поведения. Выделяют следующие типы сущностей:
• независимая сущность представляет независимые данные, которые всегда присутствуют в системе. Отношения с другими сущностями у нее могут отсутствовать;
• зависимая сущность представляет данные, зависящие от других сущностей в системе. Она всегда имеет отношения с другими сущностями;
• ассоциированная сущность представляет данные, которые ассоциируются с отношениями между двумя и более сущностями.
• Отношение связывает две или большее количество сущностей. Отношение всегда выражается действием, и его именуют с помощью глагола. Выделяют следующие типы отношений:
• неограниченное отношение представляет собой безусловное отношение, которое существует до тех пор, пока существуют относящиеся к делу сущности;
• ограниченное отношение представляет собой условное отношение между сущностями;
• существенно-ограниченное отношение используется, когда соответствующие сущности взаимозависимы в системе.
• Связи используются для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения. Каждая связь соединяет сущность и отношение и может быть направлена только от отношения к сущности. Пара значений связей, принадлежащих одному и тому же отношению, определяет тип этого отношения. Для большинства приложений достаточно использовать следующие типы отношений:
• 1: 1 (один-к-одному);
• 1: М (один-ко-многим);
• M: N (многие-ко-многим);
• Атрибут - абстракция одной характеристики, которой обладают все абстрагируемые как объект сущности. Атрибуты бывают:
• описательные - представляющие факты, внутренне присущие каждому экземпляру объекта;
• указательные - для дачи имени или обозначения экземпляру;
• вспомогательные - для связи экземпляра одного объекта с экземпляром другого.

Разработанные диаграммы " сущность-связь" далее практически всегда следует преобразовывать в реляционную модель, которая допускает только унарные и бинарные связи. Подробно о реляционной модели рассказано в разд. 4.4.3.2.

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

Структурная методология

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

• Диаграммы потоков данных.
• Диаграммы потоков управления.
• Таблицы решений.
• Сети Петри.
• Диаграммы зависимости.
• Диаграммы декомпозиции.
• Диаграммы функционального моделирования.

Диаграмма потоков данных (Data Flow Diagram - DFD) - информационная модель, основные компоненты которой - различные потоки данных, переносящие информацию от одного модуля к другому.

Компонентами диаграммы потоков данных являются:

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

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

Диаграмма функционального моделирования (Structured Analysis and Design Technique - SADT) - модель, состоящая из диаграмм, фрагментов текста и глоссария, имеющих ссылки друг на друга.

В состав диаграммы входят:

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

Структурная методология

Итак, комбинации структурных методов образуют структурные подходы. Можно выделить три группы структурных подходов на основе порядка построения модели [Калянов 1996].

• Процедурно-ориентированные подходы, в которых первично проектирование функциональных компонентов.
• Подходы, ориентированные на данные. Для таких подходов первичны входные и выходные данные, а функциональные (процедурные) компоненты вторичны.
• Информационно-ориентированные подходы. Эта группа близка к предыдущей, но отличается тем, что работа ведется с неиерархическими структурами данных.

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

Как правило, подходы используют две основные группы средств моделирования [Вендров 2000].

123456Следующая ⇒

Поделиться: