SlideShare a Scribd company logo
1 of 40
Download to read offline
Практический анализ
с использованием RUP
     Николай Киреев
       ИИТ БГУИР
Цели доклада
1. Ознакомление с методологией
   унифицированного процесса разработки
   программного обеспечения (RUP) на
   конкретном примере промышленной ПС;
2. Обсуждение основных подходов и
   принципов моделирования
Список сокращений

ООПС – объектно-ориентированная программная система
ПС -- программная система
ПО – предметная область
ВИ – вариант использования, прецедент
RUP – Rational Unified Process
ЭФ – экранная форма
МК – металлический компонент
НМК – неметаллический компонент (кокс, известь, спецкокс)
Общие принципы моделирования
1.   Объектно-ориентированный подход. Поведение (функциональность)
     ОО ПС реализуется взаимодействующими объектами ПС, которые
     относятся к связанным между собой классам ПС [1].
2.   Взаимодействие объектов описывается клиент-серверной моделью:
     объект «клиент» посылает СООБЩЕНИЕ объекту «сервер» с целью
     вызова соответствующей операции.
3.    Итерационный подход к построению моделей.
4.   В моделях в соответствующем представлении фиксируется все, что
     прямо или косвенно связано с работой ПС.
5.   Создаваемые модели должны быть полезны заинтересованным
     сторонам: пользователям (Заказчикам), проектировщикам и другим
     разработчикам.
6.   Модели должны быть простые и читабельные.
7.   Количество создаваемых артефактов должно быть достаточным, чтобы
     отразить все важные аспекты разрабатываемой ПС и минимальным,
     чтобы максимально сократить время затрачиваемое на анализ и
     проектирование.
Аналитическая модель
Аналитическая модель – это точное, четкое представление задачи,
позволяющее отвечать на вопросы и строить решения.
На этапе проектирования вы будете ссылаться именно на аналитическую
модель, а не на исходную формулировку задачи. [1]
              Аналитическая модель включает
•Модель предметной области (domain model);
•Модель программной системы (application model).
        Представления аналитической модели
•Представление классов (Logical View). Моделируем: сущности предметной
области (business entity), классы анализа (boundary, entity, controll);
•Представление процессов & состояний (Proсess View). Моделируем:
бизнес-процессы, последовательности действий в вариантах использования,
алгоритмы операций;
•Представление прецедентов (Use Case View). Моделируем: варианты
использования (use case), пользователей (actor), объекты классов анализа, их
связи и взаимодействие.
Начало. Организационная
              структура проекта
   Без четкой организационной структуры любой проект
может превратиться в хаос.
   Каждый артефакт должен хранится в своей папке и легко
находится всеми заинтересованными участниками проекта.

1.   В соответствии с принятой аналитической моделью при помощи пакетов
     создаем организационную структуру проекта. При этом можно
     использовать предоставляемый в Rational Rose шаблон „rational unified
     process“, либо создавать в соответствующих представлениях свои папки.
2.   Пакеты помещаем на организационных диаграммах соответствующих
     представлений.
3.   К пакету представления Use Case View подсоединяем исходные
     материалы (концепцию ПС, анкеты, опросные листы и т.д.)
Начало. Организационная
   структура проекта
Моделирование
          предметной области (ПО)
•   Моделирование предметной области является в RUP опциональной и
    выполняется для самих разработчиков, Заказчик является экспертом
    предметной области и не нуждается в ее моделировании.
•   Целью моделирования предметной области является выработка точной,
    четкой, доступной для понимания и, наконец, корректной модели
    реального мира [2].
•   В зависимости от конкретного проекта по усмотрению бизнес-
    аналитиков при анализе ПО могут создаваться следующие артефакты:
    глоссарий терминов предметной области, диаграмма бизнес-сущностей
    (классов ПО), диаграммы взаимодействия объектов ПО (моделирование
    связей), диаграммы бизнес-процессов или состояний, диаграммы
    функционеров (бизнес-актеров) и их функциональные обязанности,
    модели, описывающие состояния и условия перехода из одного в
    другое.
Артефакты бизнес-анализа
   Глоссарий – текстовой документ, разъясняющий разработчикам
специфические термины в том числе жаргонные, встречающиеся в данной
предметной области.
   В глоссарии также документируются синонимы, омонимы и факты
смены терминологии.
    Глоссарий не должен дублировать информацию введенную в других
артефактах. Информация вводится в систему однократно.
    Цель глоссария – это НЕ повышение IQ участников проекта, а
разъяснение терминов с точки зрения работы ПС.

                                 ПРИМЕР
    Шихтовка (процесс шихтовки) – это процесс составления
плавильной смеси, в котором обеспечивается заданная пропорция МК и
соответствующее набранному суммарному весу МК количество кокса,
извести и спецкокса.
Моделирование сущностей ПО
Цель: выявление и документирование бизнес-сущностей
  (классов ПО) и их атрибутов.
Бизнес-сущность — некий объект ПО или концептуальное
  понятие ПО, характеризуемое набором данных
  (существенных признаков), прямо или косвенно связанное с
  проектируемой программной системой.
Бизнес-сущности – это кандидаты в классы и объекты ПС,
  которые отвечают за ввод, изменение, удаление и хранение
  данных (атрибутов).
Методика выявления бизнес-сущностей: чтение текста
  концепции и анализ имен существительных.
ПРИМЕР анализа текста:
     Инструментом для этого служит КРАН, который забирает
МЕТАЛЛИЧЕСКИЕ КОМПОНЕНТЫ (МК) своим магнитом и потом опускает в
дозировочный КОНТЕЙНЕР. В соответствии с ВЕСОМ НАБРАННЫХ МК
подаются КОКС, ИЗВЕСТЬ, СПЕЦКОКС. По заполнении контейнера его
содержание со всеми занесенными в него металлическими компонентами
направляется в ЧАН для плавления, в который добавляются ЛЕГИРУЮЩИЕ
ДОБАВКИ. В конце рабочего дня чан направляется в ПЛАВИЛЬНУЮ ПЕЧЬ.
Так как в процессе плавления должны использоваться определенные
соотношения веса различных МК, программа должна обеспечить
требуемый состав ПЛАВИЛЬНОЙ СМЕСИ. Этот контроль и составление
смеси компонентов для плавки называется ШИХТОВКОЙ.
     Программная система устанавливается на рабочем месте
КРАНОВЩИКА и используется им для контроля над процессом шихтовки.
Кроме того, она позволяет ТЕХНОЛОГУ задать определенную ПРОПОРЦИЮ
МК в конечном СПЛАВЕ и осуществлять сохранение информации о составе
и свойствах полученных сплавов в базе данных.
Моделирование сущностей ПО
Моделирование бизнес-актеров
Модель бизнес-актеров и их функциональных обязанностей (бизнес-
   функций) строится в представлении Use Case View в папке Business Use
   Case Model (при вызове шаблона rational unified process) на диаграмме
   ВИ.
Цель моделирования: изучение действующих лиц ПО и их функциональных
   обязанностей для понимания бизнес-процессов, выявления
   пользователей системы, уточнения высокоуровневых бизнес-целей.
Business Actor — это штатная единица (действующее лицо, функционер) в
   предметной области, который взаимодействует с ПС, либо не
   взаимодействует, но является участником бизнес-процесса. Чаще всего
   это штатный работник предприятия или должность (генеральный
   директор, главный инженер, экономист, зам. директора по производству
   и т.д.), но может быть и обособленной штатной системой, исполняющей
   определенные функциональные обязанности (например: кран, весы-
   транспортеры и т.д.).
Business Use Case — это функциональные (должностные) обязанности,
   возложенные на данного функционера. Фиксируются только те из них,
   которые прямо или косвенно связаны с работой программной системы.
Моделирование бизнес-актеров
Моделирование бизнес-процессов
Если проектируемая ПС должна обеспечивать некий бизнес-
  процесс, то его необходимо изучить и смоделировать.
В Rational Rose отсутствует отдельное представление Proсess
   View, однако, можно присоединить диаграмму
   деятельности (activity diagram) к любому элементу в
   браузере проекта.
Моделирование бизнес-процессов
        (действия технолога)
Моделирование
бизнес-процессов
 (действия крановщика)
Анализ требований
         Выясняем ЧТО должна делать система
          и строим ее концептуальную модель
Требование (requirement) -- желательное свойство,
  характеристика или условие, которым должна удовлетворять
  система в процессе своей эксплуатации.
Применительно к ПС используется следующая классификация
  требований, которая получила название модели FURPS+, что
  соответствует первым буквам соответствующих категорий
  требований на английском языке:
   •   функциональные требования (Functionality)
   •   требования удобства использования (Usability)
   •   требования надежности (Reliability)
   •   требования производительности (Performance)
   •   требования возможности сопровождения (Supportability)
Анализ требований
символом "+" обозначены дополнительные условия, к которым относятся:
   • проектные ограничения
   • требования управления системой
   • требования к графическому интерфейсу пользователя
   • физические требования
   • юридические требования
Функциональное требование -- желаемое поведение системы с точки зрения
  ее пользователя.
Функциональные требования реализуются функциями ПС.
Функция системы — поведение, которое необходимо реализовать в
  разрабатываемой программной системе.
Если Х действительно является функцией системы, то
  имеет смысл следующее предложение: система должна
  выполнять «Х»
Формулировка пожеланий (требований) заказчика может быть
  неконкретной, расплывчатой и не однозначной.
Анализ требований
Формат записи требований по [4] :
<id> <имя системы>должна (shall)<действие, которое должно быть
выполнено>

Классификация функциональных требований по [3]:
Анализ требований
Каждое функциональное требование необходимо выявить, зафиксировать,
   уточнить, конкретизировать его смысл и поставить ему в соответствие одну
   или несколько функций системы. Некоторые требования могут быть
   абстрактными, т.е. им не будет соответствовать ни одна функция системы
   и они из дальнейшего рассмотрения исключаются.
Функциональные требования в RUP моделируются при помощи вариантов
   использования.
Вариант использования (Use Case, прецедент) — внешняя спецификация
   последовательности действий, которые система может выполнять в
   процессе взаимодействия с действующими лицами (actor) с целью
   получения значимого для них результата [2].




Читая текст концепции (vision), фиксируем в функциональные требования,
   детализируем их в виде функций (бизнес-логики), каждую функцию
   отображаем соответствующим вариантом использования и сводим в
   трассировочную таблицу (матрицу).
Анализ требований
Анализ требований
          Построение модели вариантов использования
Модель вариантов использования (use case model) — это модель, которая
   описывает функциональные требования к системе в терминах вариантов
   использования.
Диаграмма вариантов использования (use case diagram) — это диаграмма, на
   которой изображены отношения, существующие между актерами (actor) и
   вариантами использования системы (use case).
Актер (actor), синонимы актант, действующее лицо — это абстрактное
   понятие, которое характеризует внешнего пользователя (или нескольких
   пользователей), взаимодействующего с системой. Каждый актер
   соответствует одной роли в которой выступает пользователь,
   взаимодействуя с системой.
Каждый актер использует свои для него предназначенные сервисы,
   предоставляемые программной системой.
Анализ требований
        Построение модели вариантов использования
1. Определяем актеров
Если некая штатная единица (Business Actor) выполняет хотя бы часть своих
    функциональных обязанностей с помощью ПС, то она может выступать
    в одной или нескольких ролях.
Анализ требований
          Построение модели вариантов использования

2. Создаем организационную структуру (папки) модели ВИ
•   Для каждого актера должна быть предусмотрена отдельная папка;
•   Общие для нескольких актеров сервисы помещаются в отдельную папку.

3. Строим модель вариантов использования
•   Используя трассировочную матрицу, модель бизнес-процессов и
    диаграмму бизнес-актеров для каждого актера определяем набор
    базовых ВИ, общих сервисов (функциональные или пользовательские
    требования), которые инициируются непосредственно актерами, а к ним
    отношениями «включение» («include») и «расширение» («extend»)
    добавляем функции ПС;
•   В отдельной папке показываем ВИ, связанные с визуализацией данных.
Анализ требований
     Построение модели вариантов использования
Основные правила построения модели ВИ:
• каждый ВИ должен быть инициирован актером или вступать в отношения
  «include», «extend» к другим ВИ;
• ВИ должны концентрироваться на том «ЧТО», а не «КАК» должна делать
  система;

                                              • необходимо избегать
                                                функциональной
                                                декомпозиции. Она
                                                не подходит для
                                                модели ВИ [2].
                                              • предпочтительнее
                                                простая модель ВИ
                                                без отношений
                                                «include» и «extend».
Анализ требований
Построение модели вариантов использования
Анализ требований
Построение модели вариантов использования
Анализ требований
Построение модели вариантов использования
Анализ требований
                           Сценарии
4. Написание сценариев для базовых ВИ
Для базовых ВИ создаются прототипы ЭФ и пишутся сценарии.

Сценарий — это текстовое описание потока событий при выполнении
   конкретного варианта использования, выражающее некий аспект
   поведения системы.
Сценарии служат для перехода от вариантов использования к объектам
   программной системы. Анализируются имена-существительные в тексте
   сценария. Некоторые из них будут действующими лицами, другие —
   объектами, а третьи — атрибутами объекта.
Для текстового описания сценария в RUP имеется специальный шаблон.
   Каждый сценарий начинается главного раздела, далее описываются
   типовой и альтернативные потоки событий, для актеров – физических лиц
   должны быть предусмотрены ошибочные потоки событий.
Сценарии с прототипами ЭФ являются первой действующей моделью ПС,
   которую необходимо согласовать с Заказчиком.
Анализ требований
    Прототип ЭФ
Анализ требований
                  Сценарии. Главный раздел




Далее, после описания главного раздела описывается типовой поток
событий, результат которого и является целью выполнения данного
варианта использования.
Анализ требований
Сценарии. Типовой поток событий
Диаграммы системного анализа
Диаграмма последовательности (sequence diagram) описывает
  временную последовательность обмена сообщений между объектами
  ПС одном из потоков событий варианта использования. По сути это
  последовательность вызова операций.

Все объекты в системном анализе относятся к классам трех типов, каждый
   из которых обозначается своим стереотипом:
• класс сущность (entity) — описывает объекты ПС, отвечающие за
   хранение данных (значений атрибутов). Объекты сущности не могут
   инициировать взаимодействия;
• граничный класс (boundary) — описывает те объекты ПС, которые
   являются посредниками между системой и действующими лицами. В
   случае, если актер физическое лицо, то с помощью объектов-boundary
   моделируются экранные формы;
• класс управления (control) — описывает объекты ПС, которые управляют
   взаимодействиями, реализуют математические методы и т.д. В этих
   объектах главное — это их методы.
Диаграммы системного анализа
Диаграмма последовательности (sequence diagram)
Диаграммы системного анализа
Кооперативная диаграмма (collaboration diagram) показывает структуру
взаимосвязей между объектами программной системы в одном из потоков
событий варианта использования.
Диаграммы системного анализа
                диаграмма классов (class diagam)

Диаграмма классов, отображающая классы   На основе комплекта
и связи между ними для типового потока   кооперативных диаграмм
событий ВИ «Ввод списка МК»              (collaboration diagram) строится
                                         диаграмма классов анализа
                                         (class diagram), при этом
                                         выявленные связи между
                                         объектами и направления
                                         посылки сообщений позволят
                                         определить связи и их
                                         направления на диаграмме
                                         классов ПС, а каждое
                                         сообщение должно
                                         соответствовать методам
                                         объекта к которому оно
                                         направлено.
Заключение
В данном докладе на примере разработки небольшой
промышленной системы показан процесс анализа,
выполненный в рамках стандартного RUP, включающий:
     •  анализ предметной области;
     •  анализ требований;
     •  системный анализ.
     Строгое следование стандартному процессу не является
        самоцелью, важнее как можно быстрее получить
        работающую ПС, поэтому процесс можно изменять и
        минимизировать количество создаваемых артефактов,
        оценивая при этом возрастающие риски.
ИСПОЛЬЗУЕМАЯ ЛИТЕРАТУРА
•   Г. Буч и д.р.«Объектно-ориентированный анализ и проектирование с
    примерами приложений», Москва, «Вильямс», 2008 г., 3-е издание.
•   Дж. Арлоу, А. Нейштадт, «UML-2 и Унифицированный процесс.
    Практический объектно-ориентированный анализ и проектирование».
    Санкт-Петербург, «Символ-Плюс», 2007 г., 2-е издание.
•   Основы программной инженерии (по SWEBOK, 2004 г.), перевод
    С.Орлик, 2004-2010 г.
•   Дж. Рамбо, М. Блаха «UML-2 Объектно-ориентированное
    моделирование и разработка» Санкт-Петербург, «Питер», 2007 г., 2-е
    издание.
Спасибо за внимание
    Николай Киреев
      ИИТ БГУИР
 e-Mail: nousy@mail.ru
    Skype: nousy123

More Related Content

What's hot

ITGM #5. System Duality and Its Practical Effect on Business Analysis [1.0, RUS]
ITGM #5. System Duality and Its Practical Effect on Business Analysis [1.0, RUS]ITGM #5. System Duality and Its Practical Effect on Business Analysis [1.0, RUS]
ITGM #5. System Duality and Its Practical Effect on Business Analysis [1.0, RUS]Alex V. Petrov
 
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]Alex V. Petrov
 
Специфика работы бизнес-аналитика в зависимости от типов проектов и методологий
Специфика работы бизнес-аналитика в зависимости от типов проектов и методологийСпецифика работы бизнес-аналитика в зависимости от типов проектов и методологий
Специфика работы бизнес-аналитика в зависимости от типов проектов и методологийSQALab
 
ISUCT & BSUIR. Successful Communication of the Process Architecture [1.0, RUS]
ISUCT & BSUIR. Successful Communication of the Process Architecture [1.0, RUS]ISUCT & BSUIR. Successful Communication of the Process Architecture [1.0, RUS]
ISUCT & BSUIR. Successful Communication of the Process Architecture [1.0, RUS]Alex V. Petrov
 
Введение в моделирование бизнес процессов
Введение в моделирование бизнес процессовВведение в моделирование бизнес процессов
Введение в моделирование бизнес процессовNatalia Zhelnova
 
CEE-SECR 2015. Systems Engineering for Software Engineers in Top-Ranking Tech...
CEE-SECR 2015. Systems Engineering for Software Engineers in Top-Ranking Tech...CEE-SECR 2015. Systems Engineering for Software Engineers in Top-Ranking Tech...
CEE-SECR 2015. Systems Engineering for Software Engineers in Top-Ranking Tech...Alex V. Petrov
 
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]HTP. Business Requirements Elicitation & Documentation [1.01, RUS]
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]Alex V. Petrov
 
Domain-Driven Design: Модель вместо требований
Domain-Driven Design: Модель вместо требованийDomain-Driven Design: Модель вместо требований
Domain-Driven Design: Модель вместо требованийCUSTIS
 
DDD: проблемы и решения при отражении модели предметной области в код
DDD: проблемы и решения при отражении модели предметной области в кодDDD: проблемы и решения при отражении модели предметной области в код
DDD: проблемы и решения при отражении модели предметной области в кодCUSTIS
 
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...Alex V. Petrov
 
Понятия технологии разработки объектно-ориентированных информационных систем ...
Понятия технологии разработки объектно-ориентированных информационных систем ...Понятия технологии разработки объектно-ориентированных информационных систем ...
Понятия технологии разработки объектно-ориентированных информационных систем ...Aimurat Adilbekov
 
SPb BA & SA Night. Stakeholder Management Essentials [1.01, RUS]
SPb BA & SA Night. Stakeholder Management Essentials [1.01, RUS]SPb BA & SA Night. Stakeholder Management Essentials [1.01, RUS]
SPb BA & SA Night. Stakeholder Management Essentials [1.01, RUS]Alex V. Petrov
 
Domain Driven Design: модель вместо требования
Domain Driven Design: модель вместо требованияDomain Driven Design: модель вместо требования
Domain Driven Design: модель вместо требованияCUSTIS
 
Базовые принципы и понятия технологии разработки объектно-ориентированных инф...
Базовые принципы и понятия технологии разработки объектно-ориентированных инф...Базовые принципы и понятия технологии разработки объектно-ориентированных инф...
Базовые принципы и понятия технологии разработки объектно-ориентированных инф...DEVTYPE
 
Введение в моделирование бизнес процессов
Введение в моделирование бизнес процессовВведение в моделирование бизнес процессов
Введение в моделирование бизнес процессовNatalia Zhelnova
 
Babok v2.0 перевод на русский язык свод знаний по бизнес анализу
Babok v2.0 перевод на русский язык свод знаний по бизнес анализуBabok v2.0 перевод на русский язык свод знаний по бизнес анализу
Babok v2.0 перевод на русский язык свод знаний по бизнес анализуIvan Shamaev
 
Модель системы — архитектура для Agile-разработки
Модель системы — архитектура для Agile-разработкиМодель системы — архитектура для Agile-разработки
Модель системы — архитектура для Agile-разработкиCUSTIS
 
Онтологические стандарты организационной модели
Онтологические стандарты организационной моделиОнтологические стандарты организационной модели
Онтологические стандарты организационной моделиAnatoly Levenchuk
 
Практика применения Enterprise Architect и T4-шаблонов для разработки систем...
Практика применения Enterprise Architect и T4-шаблонов для разработки систем...Практика применения Enterprise Architect и T4-шаблонов для разработки систем...
Практика применения Enterprise Architect и T4-шаблонов для разработки систем...CUSTIS
 
Архитектурное описание для корпоративных и инженерных информационных систем
Архитектурное описание для корпоративных и инженерных информационных системАрхитектурное описание для корпоративных и инженерных информационных систем
Архитектурное описание для корпоративных и инженерных информационных системMarcus Akoev
 

What's hot (20)

ITGM #5. System Duality and Its Practical Effect on Business Analysis [1.0, RUS]
ITGM #5. System Duality and Its Practical Effect on Business Analysis [1.0, RUS]ITGM #5. System Duality and Its Practical Effect on Business Analysis [1.0, RUS]
ITGM #5. System Duality and Its Practical Effect on Business Analysis [1.0, RUS]
 
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]
 
Специфика работы бизнес-аналитика в зависимости от типов проектов и методологий
Специфика работы бизнес-аналитика в зависимости от типов проектов и методологийСпецифика работы бизнес-аналитика в зависимости от типов проектов и методологий
Специфика работы бизнес-аналитика в зависимости от типов проектов и методологий
 
ISUCT & BSUIR. Successful Communication of the Process Architecture [1.0, RUS]
ISUCT & BSUIR. Successful Communication of the Process Architecture [1.0, RUS]ISUCT & BSUIR. Successful Communication of the Process Architecture [1.0, RUS]
ISUCT & BSUIR. Successful Communication of the Process Architecture [1.0, RUS]
 
Введение в моделирование бизнес процессов
Введение в моделирование бизнес процессовВведение в моделирование бизнес процессов
Введение в моделирование бизнес процессов
 
CEE-SECR 2015. Systems Engineering for Software Engineers in Top-Ranking Tech...
CEE-SECR 2015. Systems Engineering for Software Engineers in Top-Ranking Tech...CEE-SECR 2015. Systems Engineering for Software Engineers in Top-Ranking Tech...
CEE-SECR 2015. Systems Engineering for Software Engineers in Top-Ranking Tech...
 
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]HTP. Business Requirements Elicitation & Documentation [1.01, RUS]
HTP. Business Requirements Elicitation & Documentation [1.01, RUS]
 
Domain-Driven Design: Модель вместо требований
Domain-Driven Design: Модель вместо требованийDomain-Driven Design: Модель вместо требований
Domain-Driven Design: Модель вместо требований
 
DDD: проблемы и решения при отражении модели предметной области в код
DDD: проблемы и решения при отражении модели предметной области в кодDDD: проблемы и решения при отражении модели предметной области в код
DDD: проблемы и решения при отражении модели предметной области в код
 
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...
DEV Labs 2013. Can C++ Code Effeciency Be Comparable to That of Middle-Level ...
 
Понятия технологии разработки объектно-ориентированных информационных систем ...
Понятия технологии разработки объектно-ориентированных информационных систем ...Понятия технологии разработки объектно-ориентированных информационных систем ...
Понятия технологии разработки объектно-ориентированных информационных систем ...
 
SPb BA & SA Night. Stakeholder Management Essentials [1.01, RUS]
SPb BA & SA Night. Stakeholder Management Essentials [1.01, RUS]SPb BA & SA Night. Stakeholder Management Essentials [1.01, RUS]
SPb BA & SA Night. Stakeholder Management Essentials [1.01, RUS]
 
Domain Driven Design: модель вместо требования
Domain Driven Design: модель вместо требованияDomain Driven Design: модель вместо требования
Domain Driven Design: модель вместо требования
 
Базовые принципы и понятия технологии разработки объектно-ориентированных инф...
Базовые принципы и понятия технологии разработки объектно-ориентированных инф...Базовые принципы и понятия технологии разработки объектно-ориентированных инф...
Базовые принципы и понятия технологии разработки объектно-ориентированных инф...
 
Введение в моделирование бизнес процессов
Введение в моделирование бизнес процессовВведение в моделирование бизнес процессов
Введение в моделирование бизнес процессов
 
Babok v2.0 перевод на русский язык свод знаний по бизнес анализу
Babok v2.0 перевод на русский язык свод знаний по бизнес анализуBabok v2.0 перевод на русский язык свод знаний по бизнес анализу
Babok v2.0 перевод на русский язык свод знаний по бизнес анализу
 
Модель системы — архитектура для Agile-разработки
Модель системы — архитектура для Agile-разработкиМодель системы — архитектура для Agile-разработки
Модель системы — архитектура для Agile-разработки
 
Онтологические стандарты организационной модели
Онтологические стандарты организационной моделиОнтологические стандарты организационной модели
Онтологические стандарты организационной модели
 
Практика применения Enterprise Architect и T4-шаблонов для разработки систем...
Практика применения Enterprise Architect и T4-шаблонов для разработки систем...Практика применения Enterprise Architect и T4-шаблонов для разработки систем...
Практика применения Enterprise Architect и T4-шаблонов для разработки систем...
 
Архитектурное описание для корпоративных и инженерных информационных систем
Архитектурное описание для корпоративных и инженерных информационных системАрхитектурное описание для корпоративных и инженерных информационных систем
Архитектурное описание для корпоративных и инженерных информационных систем
 

Viewers also liked

Основы разработки требований по К.Вигерсу
Основы разработки требований по К.ВигерсуОсновы разработки требований по К.Вигерсу
Основы разработки требований по К.ВигерсуOlya Kollen, PhD
 
Как стать CBAP: советы и рекомендации
Как стать CBAP: советы и рекомендацииКак стать CBAP: советы и рекомендации
Как стать CBAP: советы и рекомендацииSQALab
 
Причины совершения покупок и причины отказа от них, среди покупателей в интер...
Причины совершения покупок и причины отказа от них, среди покупателей в интер...Причины совершения покупок и причины отказа от них, среди покупателей в интер...
Причины совершения покупок и причины отказа от них, среди покупателей в интер...Vladimir Kozlov
 
Зачем использовать наружную рекламу
Зачем использовать наружную рекламуЗачем использовать наружную рекламу
Зачем использовать наружную рекламуGalleryMedia
 
Аудитория интернета в России: еще один год. Взгляд со стороны
Аудитория интернета в России: еще один год. Взгляд со стороныАудитория интернета в России: еще один год. Взгляд со стороны
Аудитория интернета в России: еще один год. Взгляд со стороныSergey Galyonkin
 
MarketingPeople - proposal to investors
MarketingPeople - proposal to investorsMarketingPeople - proposal to investors
MarketingPeople - proposal to investorsOleg Mikhalevich
 
100 лучших способов получения клиентов из интернета
100 лучших способов получения клиентов из интернета100 лучших способов получения клиентов из интернета
100 лучших способов получения клиентов из интернетаAndrei Builov
 
Рынок мониторинга социальных медиа в странах СНГ (Q3 2011), отраслевой профиль
Рынок мониторинга  социальных медиа  в странах СНГ (Q3 2011), отраслевой профильРынок мониторинга  социальных медиа  в странах СНГ (Q3 2011), отраслевой профиль
Рынок мониторинга социальных медиа в странах СНГ (Q3 2011), отраслевой профильsmm3
 
Анализ рекламных кампаний в интернете. Что и как нужно измерять
Анализ рекламных кампаний в интернете. Что и как нужно измерятьАнализ рекламных кампаний в интернете. Что и как нужно измерять
Анализ рекламных кампаний в интернете. Что и как нужно измерятьNetpeak
 
Роль социальных медиа в выводе нового бренда на рынок (на примере Tele2 в Каз...
Роль социальных медиа в выводе нового бренда на рынок (на примере Tele2 в Каз...Роль социальных медиа в выводе нового бренда на рынок (на примере Tele2 в Каз...
Роль социальных медиа в выводе нового бренда на рынок (на примере Tele2 в Каз...Sergey Andriyashkin
 
Как попасть под фильтры поисковых систем.
Как попасть под фильтры поисковых систем.Как попасть под фильтры поисковых систем.
Как попасть под фильтры поисковых систем.DeltaClick
 
Garin Studio маркетинг в социальных сетях
Garin Studio маркетинг в социальных сетяхGarin Studio маркетинг в социальных сетях
Garin Studio маркетинг в социальных сетяхGarin Studio
 
Маркетинг в социальных сетях для книжной индустрии
Маркетинг в социальных сетях для книжной индустрииМаркетинг в социальных сетях для книжной индустрии
Маркетинг в социальных сетях для книжной индустрииSMM Специалист
 
Social Media Week Copenhagen - Contentworkshop
Social Media Week Copenhagen - ContentworkshopSocial Media Week Copenhagen - Contentworkshop
Social Media Week Copenhagen - ContentworkshopMaria Andersen
 
Креативный обзор рынка Out Of Home / 2 квартал 2014
Креативный обзор рынка Out Of Home / 2 квартал 2014Креативный обзор рынка Out Of Home / 2 квартал 2014
Креативный обзор рынка Out Of Home / 2 квартал 2014Alexey Dotsenko
 
RTB. Несколько слов и цифр (Iplace)
RTB. Несколько слов и цифр (Iplace)RTB. Несколько слов и цифр (Iplace)
RTB. Несколько слов и цифр (Iplace)Dmytro Lysiuk
 
РИК: Курс "Маркетинг в социальных сетях"
РИК: Курс "Маркетинг в социальных сетях"РИК: Курс "Маркетинг в социальных сетях"
РИК: Курс "Маркетинг в социальных сетях"Vladimir Ryzhkov
 
Современная реклама в интернете и способы анализа эффективности
Современная реклама в интернете и способы анализа эффективностиСовременная реклама в интернете и способы анализа эффективности
Современная реклама в интернете и способы анализа эффективностиДмитрий Салко
 
The Top Trends in Marketing in 2017
The Top Trends in Marketing in 2017The Top Trends in Marketing in 2017
The Top Trends in Marketing in 2017Bader Rutter
 

Viewers also liked (20)

Основы разработки требований по К.Вигерсу
Основы разработки требований по К.ВигерсуОсновы разработки требований по К.Вигерсу
Основы разработки требований по К.Вигерсу
 
Как стать CBAP: советы и рекомендации
Как стать CBAP: советы и рекомендацииКак стать CBAP: советы и рекомендации
Как стать CBAP: советы и рекомендации
 
Причины совершения покупок и причины отказа от них, среди покупателей в интер...
Причины совершения покупок и причины отказа от них, среди покупателей в интер...Причины совершения покупок и причины отказа от них, среди покупателей в интер...
Причины совершения покупок и причины отказа от них, среди покупателей в интер...
 
Зачем использовать наружную рекламу
Зачем использовать наружную рекламуЗачем использовать наружную рекламу
Зачем использовать наружную рекламу
 
Аудитория интернета в России: еще один год. Взгляд со стороны
Аудитория интернета в России: еще один год. Взгляд со стороныАудитория интернета в России: еще один год. Взгляд со стороны
Аудитория интернета в России: еще один год. Взгляд со стороны
 
MarketingPeople - proposal to investors
MarketingPeople - proposal to investorsMarketingPeople - proposal to investors
MarketingPeople - proposal to investors
 
100 лучших способов получения клиентов из интернета
100 лучших способов получения клиентов из интернета100 лучших способов получения клиентов из интернета
100 лучших способов получения клиентов из интернета
 
Рынок мониторинга социальных медиа в странах СНГ (Q3 2011), отраслевой профиль
Рынок мониторинга  социальных медиа  в странах СНГ (Q3 2011), отраслевой профильРынок мониторинга  социальных медиа  в странах СНГ (Q3 2011), отраслевой профиль
Рынок мониторинга социальных медиа в странах СНГ (Q3 2011), отраслевой профиль
 
Анализ рекламных кампаний в интернете. Что и как нужно измерять
Анализ рекламных кампаний в интернете. Что и как нужно измерятьАнализ рекламных кампаний в интернете. Что и как нужно измерять
Анализ рекламных кампаний в интернете. Что и как нужно измерять
 
Социальные сети для журналиста
Социальные сети для журналистаСоциальные сети для журналиста
Социальные сети для журналиста
 
Роль социальных медиа в выводе нового бренда на рынок (на примере Tele2 в Каз...
Роль социальных медиа в выводе нового бренда на рынок (на примере Tele2 в Каз...Роль социальных медиа в выводе нового бренда на рынок (на примере Tele2 в Каз...
Роль социальных медиа в выводе нового бренда на рынок (на примере Tele2 в Каз...
 
Как попасть под фильтры поисковых систем.
Как попасть под фильтры поисковых систем.Как попасть под фильтры поисковых систем.
Как попасть под фильтры поисковых систем.
 
Garin Studio маркетинг в социальных сетях
Garin Studio маркетинг в социальных сетяхGarin Studio маркетинг в социальных сетях
Garin Studio маркетинг в социальных сетях
 
Маркетинг в социальных сетях для книжной индустрии
Маркетинг в социальных сетях для книжной индустрииМаркетинг в социальных сетях для книжной индустрии
Маркетинг в социальных сетях для книжной индустрии
 
Social Media Week Copenhagen - Contentworkshop
Social Media Week Copenhagen - ContentworkshopSocial Media Week Copenhagen - Contentworkshop
Social Media Week Copenhagen - Contentworkshop
 
Креативный обзор рынка Out Of Home / 2 квартал 2014
Креативный обзор рынка Out Of Home / 2 квартал 2014Креативный обзор рынка Out Of Home / 2 квартал 2014
Креативный обзор рынка Out Of Home / 2 квартал 2014
 
RTB. Несколько слов и цифр (Iplace)
RTB. Несколько слов и цифр (Iplace)RTB. Несколько слов и цифр (Iplace)
RTB. Несколько слов и цифр (Iplace)
 
РИК: Курс "Маркетинг в социальных сетях"
РИК: Курс "Маркетинг в социальных сетях"РИК: Курс "Маркетинг в социальных сетях"
РИК: Курс "Маркетинг в социальных сетях"
 
Современная реклама в интернете и способы анализа эффективности
Современная реклама в интернете и способы анализа эффективностиСовременная реклама в интернете и способы анализа эффективности
Современная реклама в интернете и способы анализа эффективности
 
The Top Trends in Marketing in 2017
The Top Trends in Marketing in 2017The Top Trends in Marketing in 2017
The Top Trends in Marketing in 2017
 

Similar to Практический анализ по RUP

лекция 3
лекция 3лекция 3
лекция 3cezium
 
лекция 3
лекция 3лекция 3
лекция 3cezium
 
2012 04 05_моделирование бизнес-процессов
2012 04 05_моделирование бизнес-процессов2012 04 05_моделирование бизнес-процессов
2012 04 05_моделирование бизнес-процессовReshetnikov Alexander
 
лекция 6
лекция 6лекция 6
лекция 6cezium
 
Проектирование_и_архитектура_ПС_2022_L06.ppt
Проектирование_и_архитектура_ПС_2022_L06.pptПроектирование_и_архитектура_ПС_2022_L06.ppt
Проектирование_и_архитектура_ПС_2022_L06.pptdinarium2016
 
Практика построения проектных офисов часть 1
Практика построения проектных офисов часть 1 Практика построения проектных офисов часть 1
Практика построения проектных офисов часть 1 ProjectPractice2013
 
моделирование бизнес процессов с B pwin 4.0
моделирование бизнес процессов с B pwin 4.0моделирование бизнес процессов с B pwin 4.0
моделирование бизнес процессов с B pwin 4.0vaha1411
 
Проектирование_и_архитектура_ПС_2022_L07s.ppt
Проектирование_и_архитектура_ПС_2022_L07s.pptПроектирование_и_архитектура_ПС_2022_L07s.ppt
Проектирование_и_архитектура_ПС_2022_L07s.pptdinarium2016
 
Conception
ConceptionConception
Conceptionbiv63
 
моделисущностей
моделисущностеймоделисущностей
моделисущностейNikolai Kireev
 
Практический подход к систематизации требований при проектировании информацио...
Практический подход к систематизации требований при проектировании информацио...Практический подход к систематизации требований при проектировании информацио...
Практический подход к систематизации требований при проектировании информацио...Anatoly Simkin
 
Ситуационная инженерия методов
Ситуационная инженерия методовСитуационная инженерия методов
Ситуационная инженерия методовAnatoly Levenchuk
 
лекция 4
лекция 4лекция 4
лекция 4cezium
 
лекция 4
лекция 4лекция 4
лекция 4cezium
 
Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...
Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...
Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...Dakiry
 
BPM: Почему надо говорить о системе курсов для всех заинтересованных лиц орга...
BPM: Почему надо говорить о системе курсов для всех заинтересованных лиц орга...BPM: Почему надо говорить о системе курсов для всех заинтересованных лиц орга...
BPM: Почему надо говорить о системе курсов для всех заинтересованных лиц орга...ABPMP Russian Chapter
 
Getting Started to the System Design
Getting Started to the System DesignGetting Started to the System Design
Getting Started to the System DesignAnatoly Simkin
 

Similar to Практический анализ по RUP (20)

лекция 3
лекция 3лекция 3
лекция 3
 
лекция 3
лекция 3лекция 3
лекция 3
 
2012 04 05_моделирование бизнес-процессов
2012 04 05_моделирование бизнес-процессов2012 04 05_моделирование бизнес-процессов
2012 04 05_моделирование бизнес-процессов
 
лекция 6
лекция 6лекция 6
лекция 6
 
Проектирование_и_архитектура_ПС_2022_L06.ppt
Проектирование_и_архитектура_ПС_2022_L06.pptПроектирование_и_архитектура_ПС_2022_L06.ppt
Проектирование_и_архитектура_ПС_2022_L06.ppt
 
Практика построения проектных офисов часть 1
Практика построения проектных офисов часть 1 Практика построения проектных офисов часть 1
Практика построения проектных офисов часть 1
 
моделирование бизнес процессов с B pwin 4.0
моделирование бизнес процессов с B pwin 4.0моделирование бизнес процессов с B pwin 4.0
моделирование бизнес процессов с B pwin 4.0
 
Проектирование_и_архитектура_ПС_2022_L07s.ppt
Проектирование_и_архитектура_ПС_2022_L07s.pptПроектирование_и_архитектура_ПС_2022_L07s.ppt
Проектирование_и_архитектура_ПС_2022_L07s.ppt
 
Conception
ConceptionConception
Conception
 
моделисущностей
моделисущностеймоделисущностей
моделисущностей
 
Практический подход к систематизации требований при проектировании информацио...
Практический подход к систематизации требований при проектировании информацио...Практический подход к систематизации требований при проектировании информацио...
Практический подход к систематизации требований при проектировании информацио...
 
Present architect
Present architectPresent architect
Present architect
 
п7
п7п7
п7
 
Ситуационная инженерия методов
Ситуационная инженерия методовСитуационная инженерия методов
Ситуационная инженерия методов
 
лекция 4
лекция 4лекция 4
лекция 4
 
лекция 4
лекция 4лекция 4
лекция 4
 
Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...
Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...
Аліна Петренко: “Майстер-клас: Виявлення ключових вимог на предпроектній фазі...
 
BPM: Почему надо говорить о системе курсов для всех заинтересованных лиц орга...
BPM: Почему надо говорить о системе курсов для всех заинтересованных лиц орга...BPM: Почему надо говорить о системе курсов для всех заинтересованных лиц орга...
BPM: Почему надо говорить о системе курсов для всех заинтересованных лиц орга...
 
Getting Started to the System Design
Getting Started to the System DesignGetting Started to the System Design
Getting Started to the System Design
 
IT Project Life cycle
IT Project Life cycleIT Project Life cycle
IT Project Life cycle
 

More from SQALab

Готовим стажировку
Готовим стажировкуГотовим стажировку
Готовим стажировкуSQALab
 
Куда приводят мечты? или Искусство развития тестировщика
Куда приводят мечты? или Искусство развития тестировщикаКуда приводят мечты? или Искусство развития тестировщика
Куда приводят мечты? или Искусство развития тестировщикаSQALab
 
Оптимизация Selenium тестов и ускорение их поддержки
Оптимизация Selenium тестов и ускорение их поддержкиОптимизация Selenium тестов и ускорение их поддержки
Оптимизация Selenium тестов и ускорение их поддержкиSQALab
 
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Автоматизация 0.0: 0 - бюджет, 0 - опыт программированияАвтоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Автоматизация 0.0: 0 - бюджет, 0 - опыт программированияSQALab
 
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...SQALab
 
Continuous performance testing
Continuous performance testingContinuous performance testing
Continuous performance testingSQALab
 
Конфиги вместо костылей. Pytestconfig и зачем он нужен
Конфиги вместо костылей. Pytestconfig и зачем он нуженКонфиги вместо костылей. Pytestconfig и зачем он нужен
Конфиги вместо костылей. Pytestconfig и зачем он нуженSQALab
 
Команда чемпионов в ИТ стихии
Команда чемпионов в ИТ стихииКоманда чемпионов в ИТ стихии
Команда чемпионов в ИТ стихииSQALab
 
API. Серебряная пуля в магазине советов
API. Серебряная пуля в магазине советовAPI. Серебряная пуля в магазине советов
API. Серебряная пуля в магазине советовSQALab
 
Добиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестовДобиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестовSQALab
 
Делаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIsДелаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIsSQALab
 
Вредные привычки в тест-менеджменте
Вредные привычки в тест-менеджментеВредные привычки в тест-менеджменте
Вредные привычки в тест-менеджментеSQALab
 
Мощь переполняет с JDI 2.0 - новая эра UI автоматизации
Мощь переполняет с JDI 2.0 - новая эра UI автоматизацииМощь переполняет с JDI 2.0 - новая эра UI автоматизации
Мощь переполняет с JDI 2.0 - новая эра UI автоматизацииSQALab
 
Как hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качествеКак hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качествеSQALab
 
Стили лидерства и тестирование
Стили лидерства и тестированиеСтили лидерства и тестирование
Стили лидерства и тестированиеSQALab
 
"Давайте не будем про качество"
"Давайте не будем про качество""Давайте не будем про качество"
"Давайте не будем про качество"SQALab
 
Apache.JMeter для .NET-проектов
Apache.JMeter для .NET-проектовApache.JMeter для .NET-проектов
Apache.JMeter для .NET-проектовSQALab
 
Тестирование геолокационных систем
Тестирование геолокационных системТестирование геолокационных систем
Тестирование геолокационных системSQALab
 
Лидер или босс? Вот в чем вопрос
Лидер или босс? Вот в чем вопросЛидер или босс? Вот в чем вопрос
Лидер или босс? Вот в чем вопросSQALab
 
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...SQALab
 

More from SQALab (20)

Готовим стажировку
Готовим стажировкуГотовим стажировку
Готовим стажировку
 
Куда приводят мечты? или Искусство развития тестировщика
Куда приводят мечты? или Искусство развития тестировщикаКуда приводят мечты? или Искусство развития тестировщика
Куда приводят мечты? или Искусство развития тестировщика
 
Оптимизация Selenium тестов и ускорение их поддержки
Оптимизация Selenium тестов и ускорение их поддержкиОптимизация Selenium тестов и ускорение их поддержки
Оптимизация Selenium тестов и ускорение их поддержки
 
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Автоматизация 0.0: 0 - бюджет, 0 - опыт программированияАвтоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
 
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
 
Continuous performance testing
Continuous performance testingContinuous performance testing
Continuous performance testing
 
Конфиги вместо костылей. Pytestconfig и зачем он нужен
Конфиги вместо костылей. Pytestconfig и зачем он нуженКонфиги вместо костылей. Pytestconfig и зачем он нужен
Конфиги вместо костылей. Pytestconfig и зачем он нужен
 
Команда чемпионов в ИТ стихии
Команда чемпионов в ИТ стихииКоманда чемпионов в ИТ стихии
Команда чемпионов в ИТ стихии
 
API. Серебряная пуля в магазине советов
API. Серебряная пуля в магазине советовAPI. Серебряная пуля в магазине советов
API. Серебряная пуля в магазине советов
 
Добиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестовДобиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестов
 
Делаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIsДелаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIs
 
Вредные привычки в тест-менеджменте
Вредные привычки в тест-менеджментеВредные привычки в тест-менеджменте
Вредные привычки в тест-менеджменте
 
Мощь переполняет с JDI 2.0 - новая эра UI автоматизации
Мощь переполняет с JDI 2.0 - новая эра UI автоматизацииМощь переполняет с JDI 2.0 - новая эра UI автоматизации
Мощь переполняет с JDI 2.0 - новая эра UI автоматизации
 
Как hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качествеКак hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качестве
 
Стили лидерства и тестирование
Стили лидерства и тестированиеСтили лидерства и тестирование
Стили лидерства и тестирование
 
"Давайте не будем про качество"
"Давайте не будем про качество""Давайте не будем про качество"
"Давайте не будем про качество"
 
Apache.JMeter для .NET-проектов
Apache.JMeter для .NET-проектовApache.JMeter для .NET-проектов
Apache.JMeter для .NET-проектов
 
Тестирование геолокационных систем
Тестирование геолокационных системТестирование геолокационных систем
Тестирование геолокационных систем
 
Лидер или босс? Вот в чем вопрос
Лидер или босс? Вот в чем вопросЛидер или босс? Вот в чем вопрос
Лидер или босс? Вот в чем вопрос
 
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
 

Практический анализ по RUP

  • 1. Практический анализ с использованием RUP Николай Киреев ИИТ БГУИР
  • 2. Цели доклада 1. Ознакомление с методологией унифицированного процесса разработки программного обеспечения (RUP) на конкретном примере промышленной ПС; 2. Обсуждение основных подходов и принципов моделирования
  • 3. Список сокращений ООПС – объектно-ориентированная программная система ПС -- программная система ПО – предметная область ВИ – вариант использования, прецедент RUP – Rational Unified Process ЭФ – экранная форма МК – металлический компонент НМК – неметаллический компонент (кокс, известь, спецкокс)
  • 4. Общие принципы моделирования 1. Объектно-ориентированный подход. Поведение (функциональность) ОО ПС реализуется взаимодействующими объектами ПС, которые относятся к связанным между собой классам ПС [1]. 2. Взаимодействие объектов описывается клиент-серверной моделью: объект «клиент» посылает СООБЩЕНИЕ объекту «сервер» с целью вызова соответствующей операции. 3. Итерационный подход к построению моделей. 4. В моделях в соответствующем представлении фиксируется все, что прямо или косвенно связано с работой ПС. 5. Создаваемые модели должны быть полезны заинтересованным сторонам: пользователям (Заказчикам), проектировщикам и другим разработчикам. 6. Модели должны быть простые и читабельные. 7. Количество создаваемых артефактов должно быть достаточным, чтобы отразить все важные аспекты разрабатываемой ПС и минимальным, чтобы максимально сократить время затрачиваемое на анализ и проектирование.
  • 5. Аналитическая модель Аналитическая модель – это точное, четкое представление задачи, позволяющее отвечать на вопросы и строить решения. На этапе проектирования вы будете ссылаться именно на аналитическую модель, а не на исходную формулировку задачи. [1] Аналитическая модель включает •Модель предметной области (domain model); •Модель программной системы (application model). Представления аналитической модели •Представление классов (Logical View). Моделируем: сущности предметной области (business entity), классы анализа (boundary, entity, controll); •Представление процессов & состояний (Proсess View). Моделируем: бизнес-процессы, последовательности действий в вариантах использования, алгоритмы операций; •Представление прецедентов (Use Case View). Моделируем: варианты использования (use case), пользователей (actor), объекты классов анализа, их связи и взаимодействие.
  • 6. Начало. Организационная структура проекта Без четкой организационной структуры любой проект может превратиться в хаос. Каждый артефакт должен хранится в своей папке и легко находится всеми заинтересованными участниками проекта. 1. В соответствии с принятой аналитической моделью при помощи пакетов создаем организационную структуру проекта. При этом можно использовать предоставляемый в Rational Rose шаблон „rational unified process“, либо создавать в соответствующих представлениях свои папки. 2. Пакеты помещаем на организационных диаграммах соответствующих представлений. 3. К пакету представления Use Case View подсоединяем исходные материалы (концепцию ПС, анкеты, опросные листы и т.д.)
  • 7. Начало. Организационная структура проекта
  • 8. Моделирование предметной области (ПО) • Моделирование предметной области является в RUP опциональной и выполняется для самих разработчиков, Заказчик является экспертом предметной области и не нуждается в ее моделировании. • Целью моделирования предметной области является выработка точной, четкой, доступной для понимания и, наконец, корректной модели реального мира [2]. • В зависимости от конкретного проекта по усмотрению бизнес- аналитиков при анализе ПО могут создаваться следующие артефакты: глоссарий терминов предметной области, диаграмма бизнес-сущностей (классов ПО), диаграммы взаимодействия объектов ПО (моделирование связей), диаграммы бизнес-процессов или состояний, диаграммы функционеров (бизнес-актеров) и их функциональные обязанности, модели, описывающие состояния и условия перехода из одного в другое.
  • 9. Артефакты бизнес-анализа Глоссарий – текстовой документ, разъясняющий разработчикам специфические термины в том числе жаргонные, встречающиеся в данной предметной области. В глоссарии также документируются синонимы, омонимы и факты смены терминологии. Глоссарий не должен дублировать информацию введенную в других артефактах. Информация вводится в систему однократно. Цель глоссария – это НЕ повышение IQ участников проекта, а разъяснение терминов с точки зрения работы ПС. ПРИМЕР Шихтовка (процесс шихтовки) – это процесс составления плавильной смеси, в котором обеспечивается заданная пропорция МК и соответствующее набранному суммарному весу МК количество кокса, извести и спецкокса.
  • 10. Моделирование сущностей ПО Цель: выявление и документирование бизнес-сущностей (классов ПО) и их атрибутов. Бизнес-сущность — некий объект ПО или концептуальное понятие ПО, характеризуемое набором данных (существенных признаков), прямо или косвенно связанное с проектируемой программной системой. Бизнес-сущности – это кандидаты в классы и объекты ПС, которые отвечают за ввод, изменение, удаление и хранение данных (атрибутов). Методика выявления бизнес-сущностей: чтение текста концепции и анализ имен существительных.
  • 11. ПРИМЕР анализа текста: Инструментом для этого служит КРАН, который забирает МЕТАЛЛИЧЕСКИЕ КОМПОНЕНТЫ (МК) своим магнитом и потом опускает в дозировочный КОНТЕЙНЕР. В соответствии с ВЕСОМ НАБРАННЫХ МК подаются КОКС, ИЗВЕСТЬ, СПЕЦКОКС. По заполнении контейнера его содержание со всеми занесенными в него металлическими компонентами направляется в ЧАН для плавления, в который добавляются ЛЕГИРУЮЩИЕ ДОБАВКИ. В конце рабочего дня чан направляется в ПЛАВИЛЬНУЮ ПЕЧЬ. Так как в процессе плавления должны использоваться определенные соотношения веса различных МК, программа должна обеспечить требуемый состав ПЛАВИЛЬНОЙ СМЕСИ. Этот контроль и составление смеси компонентов для плавки называется ШИХТОВКОЙ. Программная система устанавливается на рабочем месте КРАНОВЩИКА и используется им для контроля над процессом шихтовки. Кроме того, она позволяет ТЕХНОЛОГУ задать определенную ПРОПОРЦИЮ МК в конечном СПЛАВЕ и осуществлять сохранение информации о составе и свойствах полученных сплавов в базе данных.
  • 13. Моделирование бизнес-актеров Модель бизнес-актеров и их функциональных обязанностей (бизнес- функций) строится в представлении Use Case View в папке Business Use Case Model (при вызове шаблона rational unified process) на диаграмме ВИ. Цель моделирования: изучение действующих лиц ПО и их функциональных обязанностей для понимания бизнес-процессов, выявления пользователей системы, уточнения высокоуровневых бизнес-целей. Business Actor — это штатная единица (действующее лицо, функционер) в предметной области, который взаимодействует с ПС, либо не взаимодействует, но является участником бизнес-процесса. Чаще всего это штатный работник предприятия или должность (генеральный директор, главный инженер, экономист, зам. директора по производству и т.д.), но может быть и обособленной штатной системой, исполняющей определенные функциональные обязанности (например: кран, весы- транспортеры и т.д.). Business Use Case — это функциональные (должностные) обязанности, возложенные на данного функционера. Фиксируются только те из них, которые прямо или косвенно связаны с работой программной системы.
  • 15. Моделирование бизнес-процессов Если проектируемая ПС должна обеспечивать некий бизнес- процесс, то его необходимо изучить и смоделировать. В Rational Rose отсутствует отдельное представление Proсess View, однако, можно присоединить диаграмму деятельности (activity diagram) к любому элементу в браузере проекта.
  • 16. Моделирование бизнес-процессов (действия технолога)
  • 18. Анализ требований Выясняем ЧТО должна делать система и строим ее концептуальную модель Требование (requirement) -- желательное свойство, характеристика или условие, которым должна удовлетворять система в процессе своей эксплуатации. Применительно к ПС используется следующая классификация требований, которая получила название модели FURPS+, что соответствует первым буквам соответствующих категорий требований на английском языке: • функциональные требования (Functionality) • требования удобства использования (Usability) • требования надежности (Reliability) • требования производительности (Performance) • требования возможности сопровождения (Supportability)
  • 19. Анализ требований символом "+" обозначены дополнительные условия, к которым относятся: • проектные ограничения • требования управления системой • требования к графическому интерфейсу пользователя • физические требования • юридические требования Функциональное требование -- желаемое поведение системы с точки зрения ее пользователя. Функциональные требования реализуются функциями ПС. Функция системы — поведение, которое необходимо реализовать в разрабатываемой программной системе. Если Х действительно является функцией системы, то имеет смысл следующее предложение: система должна выполнять «Х» Формулировка пожеланий (требований) заказчика может быть неконкретной, расплывчатой и не однозначной.
  • 20. Анализ требований Формат записи требований по [4] : <id> <имя системы>должна (shall)<действие, которое должно быть выполнено> Классификация функциональных требований по [3]:
  • 21. Анализ требований Каждое функциональное требование необходимо выявить, зафиксировать, уточнить, конкретизировать его смысл и поставить ему в соответствие одну или несколько функций системы. Некоторые требования могут быть абстрактными, т.е. им не будет соответствовать ни одна функция системы и они из дальнейшего рассмотрения исключаются. Функциональные требования в RUP моделируются при помощи вариантов использования. Вариант использования (Use Case, прецедент) — внешняя спецификация последовательности действий, которые система может выполнять в процессе взаимодействия с действующими лицами (actor) с целью получения значимого для них результата [2]. Читая текст концепции (vision), фиксируем в функциональные требования, детализируем их в виде функций (бизнес-логики), каждую функцию отображаем соответствующим вариантом использования и сводим в трассировочную таблицу (матрицу).
  • 23. Анализ требований Построение модели вариантов использования Модель вариантов использования (use case model) — это модель, которая описывает функциональные требования к системе в терминах вариантов использования. Диаграмма вариантов использования (use case diagram) — это диаграмма, на которой изображены отношения, существующие между актерами (actor) и вариантами использования системы (use case). Актер (actor), синонимы актант, действующее лицо — это абстрактное понятие, которое характеризует внешнего пользователя (или нескольких пользователей), взаимодействующего с системой. Каждый актер соответствует одной роли в которой выступает пользователь, взаимодействуя с системой. Каждый актер использует свои для него предназначенные сервисы, предоставляемые программной системой.
  • 24. Анализ требований Построение модели вариантов использования 1. Определяем актеров Если некая штатная единица (Business Actor) выполняет хотя бы часть своих функциональных обязанностей с помощью ПС, то она может выступать в одной или нескольких ролях.
  • 25. Анализ требований Построение модели вариантов использования 2. Создаем организационную структуру (папки) модели ВИ • Для каждого актера должна быть предусмотрена отдельная папка; • Общие для нескольких актеров сервисы помещаются в отдельную папку. 3. Строим модель вариантов использования • Используя трассировочную матрицу, модель бизнес-процессов и диаграмму бизнес-актеров для каждого актера определяем набор базовых ВИ, общих сервисов (функциональные или пользовательские требования), которые инициируются непосредственно актерами, а к ним отношениями «включение» («include») и «расширение» («extend») добавляем функции ПС; • В отдельной папке показываем ВИ, связанные с визуализацией данных.
  • 26. Анализ требований Построение модели вариантов использования Основные правила построения модели ВИ: • каждый ВИ должен быть инициирован актером или вступать в отношения «include», «extend» к другим ВИ; • ВИ должны концентрироваться на том «ЧТО», а не «КАК» должна делать система; • необходимо избегать функциональной декомпозиции. Она не подходит для модели ВИ [2]. • предпочтительнее простая модель ВИ без отношений «include» и «extend».
  • 27. Анализ требований Построение модели вариантов использования
  • 28. Анализ требований Построение модели вариантов использования
  • 29. Анализ требований Построение модели вариантов использования
  • 30. Анализ требований Сценарии 4. Написание сценариев для базовых ВИ Для базовых ВИ создаются прототипы ЭФ и пишутся сценарии. Сценарий — это текстовое описание потока событий при выполнении конкретного варианта использования, выражающее некий аспект поведения системы. Сценарии служат для перехода от вариантов использования к объектам программной системы. Анализируются имена-существительные в тексте сценария. Некоторые из них будут действующими лицами, другие — объектами, а третьи — атрибутами объекта. Для текстового описания сценария в RUP имеется специальный шаблон. Каждый сценарий начинается главного раздела, далее описываются типовой и альтернативные потоки событий, для актеров – физических лиц должны быть предусмотрены ошибочные потоки событий. Сценарии с прототипами ЭФ являются первой действующей моделью ПС, которую необходимо согласовать с Заказчиком.
  • 31. Анализ требований Прототип ЭФ
  • 32. Анализ требований Сценарии. Главный раздел Далее, после описания главного раздела описывается типовой поток событий, результат которого и является целью выполнения данного варианта использования.
  • 34. Диаграммы системного анализа Диаграмма последовательности (sequence diagram) описывает временную последовательность обмена сообщений между объектами ПС одном из потоков событий варианта использования. По сути это последовательность вызова операций. Все объекты в системном анализе относятся к классам трех типов, каждый из которых обозначается своим стереотипом: • класс сущность (entity) — описывает объекты ПС, отвечающие за хранение данных (значений атрибутов). Объекты сущности не могут инициировать взаимодействия; • граничный класс (boundary) — описывает те объекты ПС, которые являются посредниками между системой и действующими лицами. В случае, если актер физическое лицо, то с помощью объектов-boundary моделируются экранные формы; • класс управления (control) — описывает объекты ПС, которые управляют взаимодействиями, реализуют математические методы и т.д. В этих объектах главное — это их методы.
  • 35. Диаграммы системного анализа Диаграмма последовательности (sequence diagram)
  • 36. Диаграммы системного анализа Кооперативная диаграмма (collaboration diagram) показывает структуру взаимосвязей между объектами программной системы в одном из потоков событий варианта использования.
  • 37. Диаграммы системного анализа диаграмма классов (class diagam) Диаграмма классов, отображающая классы На основе комплекта и связи между ними для типового потока кооперативных диаграмм событий ВИ «Ввод списка МК» (collaboration diagram) строится диаграмма классов анализа (class diagram), при этом выявленные связи между объектами и направления посылки сообщений позволят определить связи и их направления на диаграмме классов ПС, а каждое сообщение должно соответствовать методам объекта к которому оно направлено.
  • 38. Заключение В данном докладе на примере разработки небольшой промышленной системы показан процесс анализа, выполненный в рамках стандартного RUP, включающий: • анализ предметной области; • анализ требований; • системный анализ. Строгое следование стандартному процессу не является самоцелью, важнее как можно быстрее получить работающую ПС, поэтому процесс можно изменять и минимизировать количество создаваемых артефактов, оценивая при этом возрастающие риски.
  • 39. ИСПОЛЬЗУЕМАЯ ЛИТЕРАТУРА • Г. Буч и д.р.«Объектно-ориентированный анализ и проектирование с примерами приложений», Москва, «Вильямс», 2008 г., 3-е издание. • Дж. Арлоу, А. Нейштадт, «UML-2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование». Санкт-Петербург, «Символ-Плюс», 2007 г., 2-е издание. • Основы программной инженерии (по SWEBOK, 2004 г.), перевод С.Орлик, 2004-2010 г. • Дж. Рамбо, М. Блаха «UML-2 Объектно-ориентированное моделирование и разработка» Санкт-Петербург, «Питер», 2007 г., 2-е издание.
  • 40. Спасибо за внимание Николай Киреев ИИТ БГУИР e-Mail: nousy@mail.ru Skype: nousy123