ПРАКТИЧЕСКИЙ АНАЛИЗ И ВИЗУАЛЬНОЕ МОДЕЛИРОВАНИЕ

НА UML

ПРЕЗЕНТАЦИЯ КУРСА ONLINE-ТРЕНИНГОВ

www. school.system-analysis.ru

www.webmax.by

Студия ИТ WebMax.BY, г. Минск

Школа Системного Анализа, г. Москва

Историческая справка

В 1996 г. OMG (Object Management Group) обратилась к

объектно-ориентированному сообществу с предложением

создать стандартную нотацию для объектно-ориентированного

анализа

В ноябре 1997 г. первая версия UML (UML 1.0), созданная в

компании Rational Software была утверждена OMG и принята

на вооружение крупнейшими производителями ПО

1998 г. одновременный выпуск компанией Rational Software

версии языка UML 1.3, инструментального CASE-средства

Rational Rose 98i и продукта Rational Unified Process 5.0,

представляющего собой одновременно методологию и

базу знаний

2005 г. завершена спецификация UML 2.0

2011 г. UML 2.4.1 принят в качестве международного

стандарта ISO/IEC 19505-1, 19505-2

Идея тренинга

С середины 90-х годов мне довелось работать в Германии на

компании “ULTRAKUST electronic GmbH“, которая занималась

разработкой автоматизированных измерительных систем, а также в

рамках небольшого собственного предприятия “НИКМА ПК сервис”.

По роду деятельности я общался с немецкими заказчиками, выяснял

требования, ставил задачи небольшой группе программистов в РБ, и

сдавал готовый продукт.

В конце 90-х годов программные системы усложнились, стали

информационными с развитой структурой данных, а описательные

методики, которые я применял, оказались не эффективными. Остро

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

Так в 2000 году я попал на стенд компании “Rational Software” на

выставке “CeBIT“ в г. Ганновер. После многочасового общения с

менеджерами и демонстрации возможностей инструмента, мне

был вручен диск с лицензионной “Rational Rose 98i”, а через

несколько месяцев в Минске посчастливилось купить русское

издание книги У. и М. Боггс “UML, Rational Rose 98i”.

Идея тренинга

Вернувшись в Германию, я перечитал несколько раз эту книгу и мне

казалось, что я смогу смоделировать ВСЁ…

НО, первые же проекты показали: НОТАЦИЯ и ИНСТРУМЕНТ – это

слишком мало для построения адекватных моделей. Модели

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

множество вопросов. Оказалось, нужно ещё понимать принципы

ООП и “клиент-серверной модели”, разбираться в процессах

разработки и в представлениях архитектуры. Годы ушли на

совершенствование навыков.

Когда я стал преподавать, возник вопрос: как за короткий курс обучить

этому слушателей? Ответ нашёл у Г. Буча. Он объяснял принципы

проектирования на примере гидропонной системы.

Итак, на примере небольшого, но показательного проекта, из моей

практики, приглашаю Вас вместе пройти все этапы от бизнес-целей

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

практические вопросы, ранее не отражённые в литературе.

Николай Киреев

Вопросы тренинга

Анализ требований и разработка архитектуры с помощью

визуальных UML-моделей – это миф или реальность?

Как UML моделирует окружающий мир (domain model) и

программную систему (application model)?

Что такое представления архитектуры и как они позволяют

структурировать проект?

Как читать и анализировать vision? На что влияют бизнес-

цели? Кому нужен глоссарий, как правильно его писать?

Бизнес-аналитик, аналитик требований и системный

аналитик: как распределяются их обязанности и какие

артефакты они создают (в рамках RUP)?

Есть ли общие практические правила для построения

аналитических моделей?

Нужно ли аналитикам понимать принципы ООП и «клиент-

серверную модель»? Чем системный аналитик отличается от

проектировщика?

Вопросы тренинга

Сущности предметной области: как лучше моделировать

(классами или объектами)? Как на практике разграничить

сущности, атрибуты и пользователей? Показывать ли

отношения между сущностями и какие? Что писать в

documentation?

Как моделировать бизнес-процессы? Чем activity

отличается от actions? Как показать решающие правила и

ограничения? Когда нужна диаграмма состояний?

Модели прецедентов: какие требования они

отображают? Как создавать эффективные use case-

модели? От чего зависит уровень их детализации? Смысл

стереотипов с приставкой business? Как избегать

функциональной декомпозиции.

Что такое сценарии использования? Кому, для чего и

какие нужны сценарии? Что дают wireframes?

Вопросы тренинга

Что такое аналитическая модель? Стереотипы классов

анализа (entity, control и boundary): что они описывают,

на что влияют, в каких моделях используются? Что такое

база данных с точки зрения ООП?

Как выявлять и моделировать объекты системного

анализа, их связи и поведение? Кем и для чего

используются эти модели?

Как моделировать классы анализа? Чем они будут

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

показывать структуру связей между классами. Какие

виды отношений классов (ассоциация, наследование,

агрегация, зависимость) имеются, чем они отличаются,

на что влияют. Чем отличаются диаграммы классов,

созданные аналитиками от аналогичных, созданных

проектировщиками?

Программа занятий

Занятие 1. Цели и область применения разрабатываемого

ПО. Глоссарий предметной области. Бизнес-сущности, их

атрибуты, выявление, отличия и моделирование.

Занятие 2. Три круга заинтересованных лиц. Модель

действующих лиц и их функциональных обязанностей.

Моделирование бизнес-процессов: решающие правила,

граничные условия, потоки событий.

Занятие 3. Пользовательские и функциональные требования

к ПО. Их выявление, детализация, трассирование.

Занятие 4. Принципы построения Use Case-диаграмм.

Пользователи и их типы, связи на Use Case-диаграммах.

Занятие 5. Сценарии и особенности их описания. Использование wireframes.

Занятие 6. Архитектура системного анализа: объекты и

классы (entity, control, boundary). Динамическая, статическая

объектные модели, модель классов анализа построение и

особенности.

6 занятий по 4 часа* практической работы над

проектом в online

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

материалам и ссылкам

Продолжительность курса

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

В занятиях используются современные инструменты

коллективной удалённой работы и обмена файлами

(GoToMeeting, Dropbox и т. д.), благодаря которым

осуществляется инструктаж и обсуждение результатов

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

построения UML-моделей, методические пособия, статьи,

концепция (vision) и html-прототип разрабатываемого ПО

Перед каждым занятием участники самостоятельно изучают

теорию (рекомендуемая литература) и выполняют работы в

рамках учебного проекта

Каждое занятие начинается с обсуждения результатов и с

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

В процессе занятия коллективно решаются и обсуждаются

многочисленные задачи, как в рамках разрабатываемого

проекта, так и из других предметных областей

Занятия проходят на русском языке, в артефактах частично

используется английская лексика.

Формат обучения

Индивидуальный подход

Каждый участник предлагает свои идеи и решения, создаёт свои модели,

которые обсуждаются с тренером

Каждое занятие — это определённый этап деятельности аналитика от работы

над концепцией до создания архитектуры приложения

Особенности курса

Уникальность проекта — в основе реальный проект, выполненный автором для немецкого заказчика

Нетрадиционная бизнес-область.Основной бизнес-процесс — контроль составления смеси из различных компонентов

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

Особенности курса

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

Предоставляются все материалы и инструменты, необходимые для работы над данным проектом

Возможно использование собственного инструментария для моделирования, вплоть до рисования на салфетках…

Так тоже можно, но CASE-средства делают модели лучше!

CASE (англ. Computer-Aided Software Engineering)

Что в этом курсе главное?

НЕ специфика предметной области — аналитик должен уметь „входить“ в любую новую для себя область бизнеса. Сегодня литьё металлов, завтра обеспечение платных медицинских услуг, виртуальная реальность и статистика туристического бизнеса…

НЕ инструмент визуального моделирования или управления требованиями — инструменты меняются быстро и в каждой компании предпочитают свои. Одни используют Visio, другие Sparx-EA, третьи MagicDraw, но стандарт языка UML один!

Что в этом курсе главное?

ГЛАВНОЕ — практическое освоение методологии моделирования

Её можно использовать в анализе любой предметной области, применяя при этом

любой инструмент моделирования, действуя в рамках любого процесса разработки

ГЛАВНОЕ — возможность обсуждения созданных моделей

Совместное обсуждение моделей позволяет понять их достоинства и недостатки, даёт опыт и повышает

навыки в моделировании

Особенности проекта

• неопределённость части функциональных требований;

• наличие скрытых функций;

• необходимость разработки пользовательских сценариев

Чему научит курс?

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

Методологии проектирования на основе визуальных моделей (принцип MDA — Model Driven Architecture)

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

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

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

Для кого предназначен?

полезен всем, кто ведёт самостоятельную деятельность по разработке ПО;

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

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

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

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

Кратко о тренере

Опыт разработки электронных систем и прикладного ПО — с 1982 г.;

Опыт аналитика ПО (анализ требований, бизнес- и системный анализ) — с 1990 г.;

Разработка ПО для иностранных заказчиков (Германия, Голландия, Польша, Латвия, Россия), работа в Германии («Ultrakust electronic GmbH») — с 1992 г.;

Применение UML, методологии RUP и Rational Rose в разработке ПО — с 2000 г.;

Преподавание дисциплины «Анализ и проектирование ПО» на факультете переподготовки и повышения квалификации БГУИР г. Минск — с 2002 г.

Проведение тренингов для разработчиков ПО на «EPAM Systems», «АСКОН Бел», «Образовательный центр ПВТ» и др. — с 2004 г.

Разработка методики реверсивного анализа требований с использованием интерактивных html-прототипов, созданных средством Axure RP Pro — c 2013 г.

НИКОЛАЙ КИРЕЕВ — практикующий аналитик, PM, тренер,старший преподаватель ИИТ БГУИР, владелец ресурса „Студия ИТ WebMax.BY”, автор методических пособий и статей, участник международных конференций аналитиков и разработчиков ПО, индивидуальный предприниматель (разработка ПО, ИТ-консалтинг)

Контакты

Вопросы к тренеру

e-Mail: info@webmax.by

Skype: nousy123

Тел.: +375 (25) 633-76-78

Сайт: www.webmax.by

Запись на тренинг по ссылке:

http://school.system-analysis.ru/uml-online/