УПРАВЛЕНИЕ

Определение и управление производственными процессами.

Группа требования состоит из:

• Руководитель проекта (отвечает за достижение целей по срокам, бюджету и содержанию)

• Куратор проекта (оценка планов и исполнения проекта)

• Системный архитектор (разработка технической концепции системы, ключевых проектных решений)

• Руководитель группы тестирования (определяет цели, стратегию и управляет тестированием)

• Ответственный за управление изменениями, конфигурациями, за сборку и поставку программного продукта

3. ПРОИЗВОДСТВО

Проектирование и разработка ПО.

В производственную группу входят:

• Проектировщик (проектирование компонентов и подсистем в соответствии с общей архитектурой и разработка архитектурно-значимых модулей)

• Проектировщик баз данных

• Проектировщик интерфейса пользователя

• Разработчик (проектирование, реализация, отладка отдельных модулей).

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

4. ТЕСТИРОВАНИЕ

Тестирование ПО.

Группа тестирования в проекте состоит из ролей:

• Проектировщик тестов (разработка тестовых сценариев)

• Разработчик автоматизированных тестов

• Тестировщик (тестирование продукта, анализ и документирование)

5. ОБЕСПЕЧЕНИЕ

Производство дополнительных продуктов и услуг

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

• Технический писатель (работа по ведению документации, написание инструкций и т.п.)

• Переводчик

• Дизайнер графического интерфейса

• Разработчик учебных курсов

• Тренер (обучение пользователей)

• Продажа и маркетинг (продвижение)

• Системный администратор

• Специалист по инструментальным средствам и др.

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

Один человек может исполнять несколько ролей. Возможно такое совмещение:

• Руководитель проекта + системный аналитик (системный архитектор)

• Системный архитектор + разработчик

• Системный аналитик + проектировщик тестов (+ технический писатель)

• Системный аналитик + проектировщик интерфейса пользователя

15.02.10

Лекция 2. Язык UML

Список сокращений:

UML (Unified Modeling Language) – язык (система обозначений), используемый при объектно-ориентированном анализе и проектировании для моделирования свойств создаваемой системы

ОО – объектно-ориентированный

UP (Unified Process) – унифицированный процесс

OMG (Object Management Group) – группа управления объектами

MDA (Model Driven Architecture) – архитектура, управляемая моделью

CIM (Computer-Independent Model) – абстрактная управляемая моделью

PIM (Platform-Independent Model) – платформонезависимая модель

PSM (Platform-specific Model) – платформозависимая модель

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

Существует три способа использования UML:

• UML как эскиз, при котором используется схематическое изображение диаграмм, помогающее визуализировать программную систему. Условно: проект «на салфетке», VISIO и т.п.

• UML как модель. Более формальный и точный подход, при котором составляется подробное описание программной системы. Это как набор архитекторских планов или чертеж машины. Такой подход требует использования настоящего инструмента моделирования. Rational Software Modeling

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

UML

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

Рождение uml

До 1994 года существовало несколько конкурирующих языков и методологий визуального моделирования. Очевидные лидеры: Гради Бутч, Джеймс Рамбо, Джекапсон, объединив свои усилия, создали язык UML, который стал открытым промышленным стандартом. Rational Corporation.

UML постоянно расширяется и модифицируется, как промышленный стандарт. Унификация UML заключается в следующем:

• Жизненный цикл разработки ПО поддерживается визуальным синтаксисом UML (от постановки требований до реализации)

• UML используется в различных областях приложений (от аппаратных встроенных систем реального времени до систем поддержки принятия решений)

• UML является независимым от языков и платформ

• UML последовательно сохраняет применение небольшого набора своих диаграмм

Объекты uml

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

В UML-модели есть два аспекта:

• Статическая структура (описывает какие типы объектов важны для моделирования системы, и как они взаимосвязаны)

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

UML моделирует мир, как систему взаимодействующих объектов. Объект – это цельный блок, состоящий из данных и функциональности.

Структура uml

Как визуальный язык UML имеет структуру:

• Строительные блоки (основные элементы, отношения и диаграммы)

• Сущности – это сами элементы модели. Это существительные UML-модели. Все UML-сущности можно разделить на:

• Структурные сущности – это существительные, такие как:

  • класс,

  • интерфейс,

  • прецедент,

  • компонент,

  • узел

• Поведенческие сущности – это глаголы, такие как:

  • Взаимодействие

  • Деятельности

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

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

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

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

Модель – это хранилище всех сущностей и отношений. Существует 13 различных типов диаграмм:

Структурные диаграммы:

• Пакетов

• Классов

• Компонентов

• Развертывания

• Объектов

• Композитных структур

Диаграммы поведения:

• Прецедентов использования

• Деятельности

• Конечных автоматов

Диаграммы взаимодействий:

• Последовательностей

• Коммуникации

• Обзоров взаимодействий

• Синхронизации

• Общие механизмы – пути достижения определенных целей

• Архитектура, как представление архитектуры будущей системы

Объектно-ориентированное моделирование

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

Индивидуальность означает, что данные делятся на дискретные сущности, хорошо отличимые друг от друга. Эти сущности называются ОБЪЕКТАМИ. Объекты могут быть конкретными, например: файл в составе файловой системы, или концептуальными, например: концепция домашней страницы для каждого студента.

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

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

Класс – это абстракция, описывающая свойства, важные для конкретного приложения и игнорирующая все остальные свойства. Любой выбор классов произволен и зависит от приложения. Каждый класс описывает множество индивидуальных объектов. Каждый объект этого множества называется ЭКЗЕМПЛЯРОМ класса. Объект имеет свои собственные значения атрибутов, но названия атрибутов и операции являются общими для всех экземпляров класса.

Объект всегда содержит неявную ссылку на свой класс.

Наследование – наличие у разных классов, образующих иерархию общих атрибутов и операций.

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

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

Операция – это процедура или трансформация, которую объект выполняет сам или которая осуществляется с данным объектом.

Реализация операций в конкретном классе называется методом.

В реальном мире операция является абстрагированием похожего поведения у объектов одного рода.

Объектно-ориентированная разработка

Разработка включает:

• Анализ

• Проектирование

• Реализацию

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

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

Объектно-ориентированная методология включает в себя этапы:

1. Концептуализация системы

Разработка ПО начинается с бизнес-аналитиков и пользователи, которые придумывают приложения и формулируют первичные требования к ним.

2. Анализ

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

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

• Модели предметной области – описание объектов реального мира, отражаемых системой

• Модели приложения – описание видимых пользователю частей самого приложения

3. Проектирование системы

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

4. Проектирование классов

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

5. Реализация

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

21.02.10

Три модели

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

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

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

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

  • Диаграмма последовательности изображает взаимодействие объектов во времени.

  • Диаграмма деятельности уточняет важные этапы обработки

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

Объектно-ориентированные концепции

Существуют базовые концепции:

• АБСТРАКЦИЯ. Означает выделение важнейших аспектов приложения. Сначала принимается решение, что представляет собою объект, и что он делает, лишь затем, подбирается способ его реализации. Использование абстракции позволяет сохранять свободу принятия решения как можно дольше так, что детали не фиксируются раньше времени

• ИНКАПСУЛЯЦИЯ. Сокрытие информации. Состоит в отделении внешних аспектов объекта от деталей внутренней реализации. Инкапсуляция исключает возникновение взаимозависимости участков программы

• ОБЪЕДИНЕНИЕ ДАННЫХ И ПОВЕДЕНИЯ. При вызове операции полиморфизм операторов определяет выбор подходящей реализации на иерархию классов

• СОВМЕСТНОЕ ИСПОЛЬЗОВАНИЕ. Объектно-ориентированная разработка позволяет повторно использовать проекты и код в последующих программах. Помогают строить библиотеки повторно используемых компонентов

Лекция 3. Итеративный, эволюционный и гибкий процесс

Итеративная и эволюционная разработка предполагает раннее программирование и тестирование системы в многократно повторяемых циклах работы над проектом.

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

Процесс разработки ПО включает:

• Построение

• Развертывание и, возможно,

• Поддержку системы

Итеративная разработка

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

Важно:

• командная работа (часть сотрудников может работать попарно),

• возможно выполнить: прямое проектирование (моделирование информационной системы) и обратное

• показывается заинтересованным лицам

• планируются следующие итерации

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

Замечание: проектирование и визуальное моделирование с помощью UML осуществляется в течение одного дня. Для выполнения этого разработчики обычно разбиваются на пары. В результате каждой итерации получается работающая, но не полнофункциональная система. Товарный вид приобретает система только после 10-15 итераций.

Управление изменениями

Девизом итеративной разработки может быть лозунг: ДОПУСКАЙТЕ ИЗМЕНЕНИЯ!

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

Преимущества итеративной разработки

• Меньший риск неудачного завершения проекта или получения некачественного программного кода. Большая производительность

• Своевременное (раннее) осознание возможных технических рисков, осмысление требований, задач проекта и удобств использования системы

• Быстрый и заметный прогресс

• Ранняя обратная связь и возможность учета пожеланий пользователей

• Так называемая «управляемая сложность». Пример: команда разработчиков не перегружена лишней работой на этапе анализа и проектирования и не перегружена лишком долгими и сложными задачами

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

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

Длительность итерации

Рекомендуется, устанавливать длительность итерации в пределах от 2 до 6 недель. Если меньше двух, то разработчикам не остается времени для выполнения существенной части работ и получении обратной связи. Если итерация более 6 недель, то поставленные задачи могут оказаться слишком сложными, откладывается обратная связь. Длительность итераций должна быть фиксированной.

Замечание: для больших проектов процент изменяющихся требований достаточно высок

Рис. 3. Процент изменений для проектов различного размера

Функциональная точка – это любой из следующих элементов разрабатываемой системы:

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

  • Экранная форма – стандартная электронная форма для различных типов документов

• Выходной документ. Например: отчет, документ, экранная форма

• Запрос. Пара: вопрос-ответ

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

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

Любой анализ, моделирование или управление проектом говорит о нестабильности создаваемых артефактов¹.

Итеративное планирование на основе рисков и с учетом потребностей пользователей

На ранних итерациях цели проектирования должны обеспечить:

• Идентификацию и учет наибольших рисков

• Реализацию наиболее важных для пользователей свойств системы

Существуют наиболее распространенные риски программного проекта:

• Дефицит специалистов

• Нереалистичные сроки и бюджет

• Реализация несоответствующей функциональности

• Разработка неправильного пользовательского интерфейса

• Перфекционизм – ненужная оптимизация

• Непрекращающийся поток изменений

• Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию

• Недостаточная производительность получаемой системы

• Разрыв в квалификации специалистов разных областей знаний

Другие специалисты приводят другой список:

• Изъяны календарного планирования

• Текучесть кадров

• Раздувание требований

• Нарушение спецификаций

• Низкая производительность

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

Гибкие методы разработки

Среди гибких методов разработки выделяют:

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

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

Основные принципы подходы гибкого процесса:

• Люди и взаимодействие, а не процессы и средства

• Работоспособное программное обеспечение, а не исчерпывающая документация

• Сотрудничество с потребителями (beta-тестирование – пользователями)

• Реакция на изменения

Некоторые практические советы для анализа и моделирования

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

• Не нужно строить модели или применять UML для описания всех или большей части проектных решений. Простые и очевидные проблемы можно отложить на стадию программирования и тестирования

• Пользуйтесь простыми средствами насколько возможно (рисование диаграмм на обычной доске)

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

• Создавайте модели параллельно. Например, динамическая диаграмма взаимодействия и статическая диаграмма классов

• Ограничьтесь простыми, наиболее часто используемыми элементами UML

• Необходимо учитывать, что модели могут оказаться неточными, а программные коды и проектные решения совсем другими. Моделирование – это предварительные исследования

Фазы унифицированного процесса

В рамках унифицированного процесса работа над проектом включает 4 основные фазы:

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

1. НАЧАЛО. Определение начального видения проблемы, прецедентов, оценка сложности задачи

2. РАЗВИТИЕ. Может содержать несколько итераций. Формирование более полного видения проблемы, итеративная реализация базовой архитектуры. Создание наиболее критичных компонентов, определение основных требований.

3. конструирование. Итеративная реализация всех оставшихся элементов, подготовка к развертыванию

4. ПЕРЕДАЧА. Beta-тестирование и развертывание

Дисциплины унифицированного процесса

Унифицированный процесс предполагает выполнение различных видов деятельности

Начало (inception)

Развитие (elaboration)

Конструирование (construction)

Передача (transition)

Бизнес-моделирование – подразумевает разработку модели предметной области. Это визуальное представление наиболее важных сущностей из предметной области и их взаимосвязь

Требования – создание модели прецедентов и дополнительных спецификаций

Проектирование – модель проектирования, отражающая программные объекты

Реализация – программирование и построение системы

Таблица 2. Примерный набор инструментов унифицированного процесса (н — начало, р — развитие)

Описание прецедента

Прецеденты – повествовательные истории об использовании системы, которые широко используются для осмысления и формулировки требований

POS-система (Point Of Sale system).

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

Исполнитель (актер) – Actor – сущность, обладающая поведением. Например, человек (идентифицируемый по роли, к примеру, кассира), компьютерная система или организация.

Сценарий – scenario – специальная последовательность действий или взаимодействий между исполнителями и системой. Сценарий иногда называют экземпляром прецедента.

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

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

• Кто является пользователем системы?

• Каковы типичные сценарии использования системы?

• Каковы цели и задачи пользователей?

• Какой ожидается результат?

Три типа исполнителей

Все сущности, включая разрабатываемую систему, могут играть различные роли:

• Основной исполнитель – его задачи выполняются с использованием системы (кассир)

• Вспомогательный исполнитель – обслуживает систему (например, предоставляет информацию). Служба авторизации платежей

• Закулисный исполнитель – заинтересован в реализации прецедента. Например: налоговая служба

Основные форматы прецедентов

Выделяют несколько уровней

1. СЖАТЫЙ. Аннотация в виде одного абзаца. Применяется на стадии анализа требований и быстрого определения задач и масштабов системы

2. СВОБОДНЫЙ. Неформальный стиль описания. Охватывает различные сценарии

3. РАЗВЕРНУТЫЙ. Наиболее подробный, детально описываются все шаги и варианты развития сценария, а также предусловия и результаты. Применяют после определения основных задач системы, когда множество прецедентов уже описаны в сжатом формате. В развернутом формате представляют примерно 10% наиболее важных для приложения прецедентов. Шаблон для развернутого описания прецедентов имеет вид:

Основной успешный сценарий: (первый тип описания)

1. Покупатель подходит к кассовому аппарату POS-системы с выбранными товарами.

2. Кассир открывает новую продажу.

3. Кассир вводит идентификатор товара.

4 Кассир повторяет действия, описанные в пп. 3-4, для каждого наименования товара.

5....

Существует другой формат описания прецедентов

Выделение прецедентов

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

1. Определяются рамки системы (включает отдельного пользователя или своих пользователей, или всю организацию):

• Программное приложение

• Аппаратно-программный комплекс

2. Основные исполнители, цели которых удовлетворяются пользованием системы

3. Для каждого исполнителя определите его задачи

4. Определите прецеденты, которые удовлетворяют потребности каждого исполнителя, и определите их имена (прецедентов)

При определении исполнителей и задач часто возникают вопросы, на которые нужно ответить:

• Кто запускает и выключает систему

• Кто является системным администратором

• Кто осуществляет управление пользователями и безопасностью

• Должна ли система выполнять какие-либо действия в ответ на события времени (время – исполнитель?)

• Существует ли процесс мониторинга

15.03.10

Диаграмма прецедентов

Рис. 2. Пример диаграммы прецедентов

Рис. 3. Некоторые обозначения диаграммы прецедентов

Модели предметной области

Модель предметной области – это самая важная модель объектно-ориентированного анализа.

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

Модель предметной области – это визуальное представление концептуальных классов или объектов реального мира в терминах предметной области. Эти модели связаны с моделями взаимоотношений концептуальных сущностей. Модели используются как модели данных для разработки баз данных.

*Замечание: модели предметной области не описывают программные классы или программные объекты с их обязанностями.

Модель предметной области – это конкретизация модели бизнес-объектов. На языке UML модель предметной области представляется в виде набора диаграмм-классов, на которых не определены никакие операции, в ее состав входят

• объекты предметной области

• ассоциации между ними

• атрибуты концептуальных классов

Концептуальные классы

Концептуальный класс – это представление идеи или объекта.

Пример: для события «Осуществление покупки» концептуальный класс – ПРОДАЖА. Содержанием этого понятия является осуществление покупки в определенный день и определенное время.

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

Создание модели предметной области

Для создания:

1. Выделить концептуальные классы

2. Отобразить их на диаграмме

3. Добавить необходимые ассоциации и атрибуты

1. Выделение концептуальных классов.

Существует три стратегии определения концептуальных классов.

• Повторное использование или модификация существующих моделей. Наилучший и простой подход. Искать описание в литературе.

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

• Определение концептуальных классов на основе выделения существительных.

  • Производится на основе лингвистического анализа.

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

  • Удобно использовать развернутые описания прецедентов

  • Некоторые авторы рекомендуют использовать данный метод с осторожностью, так как не всегда существительные совпадают с концептуальными классами

ПРИМЕР

Оформление продажи.

Основной успешный сценарий (или основной процесс)

1. Покупатель подходит к кассовому аппарату POS-системы с выбранными товарами.

2. Кассир открывает новую продажу.

3. Кассир вводит идентификатор товара.

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

5. Система вычисляет общую стоимость покупки с налогом.

6. Кассир сообщает покупателю общую стоимость и предлагает оплатить покупку.

7. Покупатель оплачивает покупку, система обрабатывает платеж.

8. Система регистрирует продажу и отправляет информацию о ней внешней бухгалтерской системе (для обновления бухгалтерских документов и начисления комиссионных) и системе складского учета (для обновления данных).

9. Система выдает товарный чек.

10. Покупатель покидает магазин с чеком и товарами (если он что-то купил).

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

Рис. 1. Диаграмма концептуальных классов

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

• Чек – это своеобразный отчет о покупке. В модель предметной области не следует включать объекты отчета

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

Рекомендации:

1. При построении модели предметной области следует использовать применяемые на данной территории названия

2. Исключать несущественные детали и не добавлять объекты, которые отсутствуют на данной территории

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

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

Использование классов описаний

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

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

Ассоциации

Ассоциации – это отношения между классами, отражающими некоторые значимые и полезные связи между ними

Рис. 2. Пример ассоциации

Целесообразно в модель предметной области включать:

• Ассоциации, знания о которых необходимо сохранять в течение некоторого периода (важные ассоциации). Чтобы избежать «визуального шума»

• Ассоциации, производные от списка стандартных ассоциаций

Обозначение ассоциаций в UML

Рис. 3. Обозначение ассоциации в UML

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

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

Кратность

Кратность определяет сколько экземпляров класса А может быть ассоциировано с одним экземпляром класса Б.

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

Атрибуты

Атрибут – логическое значение данных объекта.

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

Например,

Рис. 5. Два способа представления типа свойства объектов

В модели предметной области атрибуты должны быть типами данных. К стандартным типам атрибутов относятся: Boolean, string, integer, real. Другими часто используемыми типами являются: address, color, phone number, social security number, universal product number, post code.

Список стандартных ассоциаций

А, B – классы из модели предметной области

Рис. 6. Фрагмент модели предметной области

Rational Software Modeler – визуальный инструмент моделирования и проектирования (фирма IBM).

Создан на основе технологии Eclipce

29.03.10

Диаграммы взаимодействия

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

CRC cards— Class-Responsibility-Collaborator cards

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

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

Диаграммы взаимодействия включают два типа:

• Диаграммы последовательностей (sequence diagram)

• Диаграммы коммуникации (communication diagram)

Диаграммы последовательностей иллюстрируют взаимодействие

Рис. 1. Диаграмма последовательности

(диаграмму следует рассматривать слева направо, сверху вниз)

Класс А содержит метод doOne и атрибут типа B (класса B).

Класс В, в свою очередь, содержит методы doTwo и doThree.

Диаграмма коммуникации

Рис. 2. Диаграмма коммуникации

Взаимодействие А и В представлено в форме графа.

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

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

ОСНОВНЫЕ ОБОЗНАЧЕНИЯ ДЛЯ ДИАГРАММ ПОСЛЕДОВАТЕЛЬНОСТИ

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

• объекты,

• классы,

• экземпляры классов

Между ними существуют передаваемые сообщения. Стандартный синтаксис для обозначения сообщений:

получатель = сообщение (параметр: типПараметра): типПолучателя

Типичными примерами участников взаимодействия являются:

Рис. 3. Примеры участников взаимодействия

1 – неименованный экземпляр класса Sale

2 – именованный экземпляр класса Sale

3 – экземпляр метакласса (Font – описание шрифтов)

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

СООБЩЕНИЯ

Рис. 4. Сообщения и фокус управления с блоком выполнения

Сообщения изображаются в виде соединяющих вертикальные линии жизни – линии с заштрихованными стрелками (черненькая).

Линия сообщений с открытыми стрелками – это асинхронное сообщение.

Возврат сообщения может быть показан с использованием возвратной линии сообщения, исходящей из блока выполнения (блока активации).

Рис. 5. Два способа отображения возврата значения

Сообщения могут передаваться самому себе, отображается с помощью вложенных блоков активации

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

Рис. 7. Уничтожение объекта

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

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

Рис. 8. Пример фрейма

Основные операторы, изображаемые с помощью фреймов

• alt – альтернативный фрагмент для взаимоисключающих условий

• loop – фрагмент цикла, выполняемый в случае истинности условного выражения

• opt – необязательный фрагмент, которые выполняется в случае истинности условного выражения

• par – фрагменты, выполняемые параллельно

• interactive – диалоговый, после ввода команды пользователя

Рис. 12. Условное сообщение

Взаимоисключающее условное сообщение имеет вид:

Рис. 9. Взаимоисключающие условные сообщения.

Фреймы могут быть вложенными

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

ДИАГРАММЫ КОММУНИКАЦИИ

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

Рис. 10. Сообщения

Сообщение может передаваться объектом самому себе. Начальное сообщение может не нумероваться.

Рис. 11. Нумерация последовательности сообщений

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

Рис. 12. Условное сообщение

В квадратных скобках указывается условное сообщение.

Сообщение передается только в случае, когда его значение истина.

Взаимоисключающие условные маршруты

Рис. 13. Взаимоисключающие сообщения

Итерационный процесс или цикл.

Рис. 14. Итерационный процесс или цикл

Цифра 1 – номер сообщения

Символ * – цикл

В скобках параметр – цикл изменяется от 1 до N

12.04.10

Требования и бизнес-правила

Для описания требований диаграммы прецедентов недостаточно. Существуют и другие артефакты требований:

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

• Словарь терминов (Включает термины и определения и может служить словарем данных)

• Документ-видение (Определяет видение проекта, описывает важнейшие идеи, положенные в основу разработки системы)

• Бизнес-правила (Устойчивые правила или политики, применяемые в предметной области – правила налогообложения, торговая политика и т.д.)

Ценность документов Видение и Дополнительная спецификация состоит в формировании первого приближения требований к системе и определение главных идей проекта.

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

Пример Дополнительной спецификации (фрагмент)

1. Введение