- •Оглавление
- •Глава 1. Жизненный цикл программного обеспечения ……………………………………………43
- •Глава 2. Методические аспекты
- •Глава 3. Моделирование бизнес-процессов
- •Глава 4. Анализ и проектирование
- •Глава 5. Технологии создания программного
- •Глава 6. Оценка трудоемкости создания
- •Глава 7. Особенности современных проектов ........527
- •Предисловие
- •Введение
- •Глава 1 жизненный цикл программного обеспечения
- •Нормативно-методическое обеспечение создания по
- •Стандарт жизненного цикла по
- •Основные процессы жц по
- •Вспомогательные процессы жизненного цикла по
- •Организационные процессы жизненного цикла по
- •Взаимосвязь между процессами жц по
- •Модели жизненного цикла по
- •Каскадная модель жц
- •Итерационная модель жизненного цикла
- •Методика spmn
- •Пример процесса «управление требованиями»
- •Пример процесса «управление конфигурацией по»
- •Общие принципы проектирования систем
- •Визуальное моделирование
- •Структурные методы анализа и проектирования по
- •Метод функционального моделирования
- •Описание типов связей
- •Моделирования процессов idef3
- •Типы связей idef3
- •Типы соединений
- •Моделирование потоков данных
- •Количественный анализ диаграмм
- •Сравнительный анализ sadt-моделей и диаграмм потоков данных
- •Моделирование данных
- •Объектно-ориентированные методы анализа и проектирования по
- •Основные принципы построения объектной модели
- •Основные элементы объектной модели
- •Значения мощности
- •Унифицированный язык моделирования uml
- •Диаграммы вариантов использования
- •Диаграммы взаимодействия
- •Диаграммы классов
- •Диаграммы состояний
- •Диаграммы деятельности
- •Диаграммы компонентов
- •Диаграммы размещения
- •Механизмы расширения uml
- •Количественный анализ диаграмм uml
- •Основные элементы языка uml
- •Основные типы связей языка uml
- •Диапазоны оценок для диаграмм uml
- •Образцы
- •Сопоставление и взаимосвязь структурного и объектно-ориентированного подходов
- •Структурный (процессный) подход к моделированию бизнес-процессов
- •Принципы процессного подхода
- •Применение диаграмм потоков данных
- •Система моделирования aris
- •Метод ericsson-penker21
- •Пример использвания процессного подхода
- •История болезни пациента
- •Спецификация структур данных
- •Построение диаграмм потоков данных нулевого и последующих уровней
- •Объектно-ориентированный подход к моделированию бизнес-процессов
- •Методика моделирования
- •Пример использования объектно-ориентированного подхода
- •Пример спецификации требований к программному обеспечению
- •Пример структурного проектирования по
- •Построение диаграмм системных процессов и диаграмм последовательностей экранных форм
- •Объектно-ориентированный анализ
- •Архитектурный анализ
- •Анализ вариантов использования
- •Объектно-ориентированное проектирование
- •Проектирование архитектуры системы
- •Проектирование элементов системы
- •Глава 5 технологии создания программного обеспечения
- •Определение технологии
- •Общие требования, предъявляемые
- •Внедрение тс по в организации
- •Общие сведения
- •Определение потребностей в тс по
- •Оценка и выбор тс по
- •Критерии оценки и выбора тс по
- •Выполнение пилотного проекта
- •Практическое внедрение тс по
- •Примеры тс по
- •Технология rup (rational unified process)
- •Технология oracle
- •Технология borland
- •Технология computer associates
- •Глава 6 оценка трудоемкости создания программного обеспечения
- •Методы оценки и их классификация
- •Методика оценки трудоемкости разработки по на основе функциональных точек
- •Определение функциональных типов
- •Определение количества и сложности функциональных типов по данным
- •Сложность ilf и eif
- •Определение количества и сложности транзакционных функциональных типов
- •Подсчет количества функциональных точек
- •Зависимость количества fp от сложности функционального типа
- •Коммуникации данных
- •Распределенная обработка данных
- •Сложность ei
- •Сложность ео
- •Производительность
- •Эксплуатационные ограничения
- •Частота транзакций
- •Ввод данных в режиме «онлайн»
- •Эффективность работы конечных пользователей1
- •Онлайновое обновление
- •Сложная обработка31
- •Повторное использование
- •Простота установки
- •Простота эксплуатации
- •Количество возможных установок на различных платформах
- •Гибкость32
- •Оценка трудоемкости разработки
- •Размер программного обеспечения в fp и loc
- •Распределение временных затрат по стадиям для маленьких и больших проектов
- •Статистические данные
- •Статистические (регрессионные) модели
- •Группа процессов
- •Определение весовых показателей вариантов использования
- •Определение технической сложности проекта
- •Определение уровня квалификации разработчиков
- •Оценка трудоемкости проекта
- •Методы, основанные на экспертных оценках
- •Метод дельфи
- •Метод декомпозиции работ
- •Средства оценки трудоемкости
- •Планирование итерационного процесса создания по
- •Глава 7 особенности современных проектов
- •Категории «безнадежных» проектов
- •Причины, порождающие «безнадежные» проекты
- •Причины разногласий между участниками проекта
- •Переговоры в «безнадежном» проекте
- •Человеческий фактор в «безнадежных» проектах
- •Процессы в «безнадежных» проектах
- •Динамика процессов
- •Контроль над продвижением проекта
- •Технология и инструментальные средства «безнадежных» проектов
- •Дополнительная литература
- •Краткий словарь терминов
- •Список основных сокращений
Образцы
Образцы (patterns) — это одни из важнейших составных частей объектно-ориентированной технологии разработки ПО. Они широко применяются в инструментах анализа, подробно описываются в книгах20 и часто обсуждаются на конференциях семинарах по объектно-ориентированному проектированию. Существует множество групп и курсов по их изучению. Изучение образцов помогает лучше понять объектно-ориентированный анализ и проектирование.
Объектно-ориентированное проектирование ПО — достаточно сложный процесс, который еще больше усложняется в случае необходимости повторного использования проектных решений. 11еобходимо подобрать подходящие объекты, отнести их к различным классам, соблюдая разумную степень детализации, определить интерфейсы классов и иерархию наследования и установить существенные связи между классами. Проектное решение должно, с одной стороны, соответствовать решаемой задаче, а с другой — быть достаточно общим, чтобы удалось учесть все требования, которые могут возникнуть в будущем. Желательно также избежать или, по крайней мере, свести к минимуму необходимость перепроектирования. Опытные разработчики знают, что обеспечить «правильное», т.е. в достаточной мере гибкое и пригодное для повторного использования решение, с первого раза очень трудно, если вообще возможно. Прежде чем считать цель достигнутой, они обычно пытаются опробовать найденное решение на нескольких задачах и каждый раз модифицируют его.
И все же опытному разработчику удается создать хороший проект системы. Прежде всего ему понятно, что не нужно решать каждую новую задачу с нуля. Вместо этого он старается повторно воспользоваться теми решениями, которые оказались удачными в прошлом. Отыскав хорошее решение один раз, он будет прибегать к нему снова и снова. Именно благодаря накопленному опыту проектировщик и становится экспертом в своей области. Во многих объектно-ориентированных системах можно встретить повторяющиеся проектные решения (образцы), состоящие из классов и взаимодействующих объектов. С их помощью решаются конкретные задачи проектирования, в результате чего решение становится более гибким, и им можно воспользоваться повторно. Проектировщик, знакомый с образцами, может сразу же применять их к решению новой задачи, не пытаясь каждый раз «изобретать велосипед».
В 1970-х годах Кристофер Александер, профессор архитектуры Калифорнийского университета написал несколько книг, документируя образцы в гражданском строительстве и архитектуре. Разработчики ПО впоследствии заимствовали идею образцов, основываясь на его трудах, тем более, что к тому времени среди программистов уже присутствовал растущий интерес к этим идеям.
По словам Кристофера Александера, «любой образец описывает задачу, которая снова и снова возникает в нашей работе, а также принцип ее решения, причем таким образом, что это решение можно потом использовать миллион раз, ничего не изобретая заново». Хотя Александер имел в виду образцы, возникающие при проектировании зданий и городов, но его слова верны и в отношении образцов объектно-ориентированного проектирования. Решения относительно ПО выражаются в терминах объектов и интерфейсов, а не стен и дверей, но в обоих случаях образец можно определить как общее решение некоторой проблемной ситуации в заданном контексте. Образец состоит из четырех основных элементов:
имя;
проблема;
решение;
следствия.
Сославшись на имя образца, можно сразу описать проблему проектирования, ее решения и их последствия. Присваивание образцам имен позволяет проектировать на более высоком уровне абстракции. С помощью словаря образцов можно вести обсуждение с коллегами, упоминать образцы в документации, в тонкостях представлять проект системы.
Проблема — это описание решаемой задачи. Необходимо сформулировать задачу и ее контекст. Может описываться конкретная проблема проектирования, например способ представления алгоритмов в виде объектов. Также может включаться перечень условий, при выполнении которых имеет смысл применять данный образец.
Решение — это описание элементов проектного решения, связей между ними ц функций каждого элемента. Конкретное решение или реализация не имеются в виду, поскольку образец — это шаблон, применимый в самых разных ситуациях. Обычно дается абстрактное описание задачи проектирования и того, как она может быть решена с помощью некоего весьма обобщенного сочетания элементов (классов и объектов).
Следствия — это описание области применения, достоинств и недостатков образца. Хотя при описании проектных решений о следствиях часто не упоминают, знать о них необходимо, чтобы можно было выбрать между различными вариантами и оценить преимущества и недостатки применения данного образца. Поскольку в объектно-ориентированном проектировании повторное использование зачастую является важным фактором, то к результатам следует относить и влияние на степень гибкости, расширяемости и переносимости системы.
Образцы могут рассматриваться на различных уровнях абстракции и в различных предметных областях. Наиболее общими категориями образцов ПО являются;
образцы бизнес-моделирования;
образцы анализа;
образцы поведения;
образцы проектирования;
архитектурные образцы;
образцы программирования.
Даже в этом кратком списке категорий присутствует большое количество уровней абстракции и ортогональных систем классификации. Например, под образцом проектирования понимается описание взаимодействия объектов и классов, адаптированных для решения обшей задачи проектирования в конкретном контексте.
В языке UML образец представляется с помощью кооперации со стереотипом «pattern». Кооперация (collaboration) определяется как описание совокупности взаимодействующих объектов, реализующих некоторое поведение (например, в рамках варианта использования или операции класса). Кооперация имеет статическую и динамическую части. В статической части (на диаграмме классов) описываются роли, которые могут играть объекты и связи в экземпляре данной кооперации. Динамическая часть состоит из одной или более диаграмм взаимодействия, показывающих потоки сообщений, которыми обмениваются участники кооперации. Кроме того, любой образец содержит стандартную диаграмму классов под названием «Participants» («Участники»), на которой изображается сам образец в виде кооперации с его именем и набор классов, участвующих в реализации образца.
В качестве примера приведем образец бизнес-моделирования под названием Employment (Занятость).
Проблема заключается в моделировании различных форм занятости в пределах организации. Данная задача решается в контексте системы планирования ресурсов предприятия.
Решение: занятость моделируется как контракт между личностью и организацией, указывающий выполняемые обязанности, контрактные условия, даты начала и конца работы. Личность характеризуется набором атрибутов (имя, адрес и дата рождения), может занимать более чем одну должность в одной и той же организации.
На рис. 2.60 приведена диаграмма «Участники» для данного образца. Она содержит кооперацию Employment и набор из пяти классов.
Employee Profile (Служащий) — описание служащего с набором атрибутов.
Organization Profile (Организация) — описание самой организации.
Employment (Занятость) — описание связи между служащим и организацией.
Position (Должность) — описание должности со своими атрибутами (такими, как должностной оклад и должностные инструкции).
Position Assignment (Назначение на должность) — описание связи между служащим и занимаемыми должностями.
Рис. 2.60. Диаграмма «Участники» для образца Employment
Статическая часть образца (диаграмма классов) показана на рис. 2.61.
Достоинства применения образцов при проектировании ПО заключаются в следующем:
Возможность многократного использования. Повторное использование решений из уже завершенных успешных проектов позволяет быстро приступить к решению новых проблем и избежать типичных ошибок. Разработчик получает прямую выгоду от использования опыта других разработчиков, избежав необходимости вновь и вновь «изобретать велосипед».
Применение единой терминологии. Профессиональное общение и работа в группе (команде разработчиков) требует наличия единого базового словаря и единой точки зрения на проблему.
Рис. 2.61. Статическая часть образца Employment
Образцы предоставляют подобную общую точку зрения как на этапе анализа, так и при реализации проекта.
Повышение эффективности труда отдельных исполнителей и всей группы в целом. Это происходит из-за того, что начинающие члены группы видят на примере более опытных разработчиков, как образцы проектирования могут применяться и какую пользу они приносят. Совместная работа дает новичкам стимул и реальную возможность быстрее изучить и Освоить эти новые концепции.
Создание модифицируемого и гибкого ПО. Причина состоит в том, что образцы уже испытаны временем, поэтому их использование позволяет создавать структуры, допускающие модификацию в большей степени, чем это возможно в случае решения, первым пришедшего на ум.
Ограничение пространства решений. Использование образцов создает границы в рамках пространства решений проектирования и реализации. Таким образом, образец настоятельно рекомендует проектировщику границы, которых должна придерживаться реализация. Выход за эти границы нарушает строгое соблюдение образца и проектных решений и может привести к нежелательным последствиям. Тем не менее, образцы не подавляют творчество. Напротив, они описывают структуру или форму на некотором уровне абстракции. Проектировщики и разработчики все еще располагают многими возможностями для реализации образцов в этих границах.
2.7.
