SlideShare une entreprise Scribd logo
1  sur  21
Télécharger pour lire hors ligne
ПРАКТИЧЕСКИЙ АНАЛИЗ И
ВИЗУАЛЬНОЕ МОДЕЛИРОВАНИЕ
НА 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/

Contenu connexe

Tendances

STRATOPLAN. Efficient Object-Oriented Design and Structured Quality of Softwa...
STRATOPLAN. Efficient Object-Oriented Design and Structured Quality of Softwa...STRATOPLAN. Efficient Object-Oriented Design and Structured Quality of Softwa...
STRATOPLAN. Efficient Object-Oriented Design and Structured Quality of Softwa...Alex V. Petrov
 
Специфика работы бизнес-аналитика в зависимости от типов проектов и методологий
Специфика работы бизнес-аналитика в зависимости от типов проектов и методологийСпецифика работы бизнес-аналитика в зависимости от типов проектов и методологий
Специфика работы бизнес-аналитика в зависимости от типов проектов и методологийSQALab
 
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
 
Введение в моделирование бизнес процессов
Введение в моделирование бизнес процессовВведение в моделирование бизнес процессов
Введение в моделирование бизнес процессовNatalia Zhelnova
 
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
 
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
 
ITGM #5. What Is Enterprise Architecture [1.0, RUS]
ITGM #5. What Is Enterprise Architecture [1.0, RUS]ITGM #5. What Is Enterprise Architecture [1.0, RUS]
ITGM #5. What Is Enterprise Architecture [1.0, RUS]Alex V. Petrov
 
Domain-Driven Design: Модель вместо требований
Domain-Driven Design: Модель вместо требованийDomain-Driven Design: Модель вместо требований
Domain-Driven Design: Модель вместо требованийCUSTIS
 
Domain Driven Design: модель вместо требования
Domain Driven Design: модель вместо требованияDomain Driven Design: модель вместо требования
Domain Driven Design: модель вместо требованияCUSTIS
 
Понятия технологии разработки объектно-ориентированных информационных систем ...
Понятия технологии разработки объектно-ориентированных информационных систем ...Понятия технологии разработки объектно-ориентированных информационных систем ...
Понятия технологии разработки объектно-ориентированных информационных систем ...Aimurat Adilbekov
 
Модель системы — архитектура для Agile-разработки
Модель системы — архитектура для Agile-разработкиМодель системы — архитектура для Agile-разработки
Модель системы — архитектура для Agile-разработкиCUSTIS
 
Денис Бесков. Как обеспечивать полноту требований
Денис Бесков. Как обеспечивать полноту требованийДенис Бесков. Как обеспечивать полноту требований
Денис Бесков. Как обеспечивать полноту требованийDenis Beskov
 
DDD: проблемы и решения при отражении модели предметной области в код
DDD: проблемы и решения при отражении модели предметной области в кодDDD: проблемы и решения при отражении модели предметной области в код
DDD: проблемы и решения при отражении модели предметной области в кодCUSTIS
 
Практика применения Enterprise Architect и T4-шаблонов для разработки систем...
Практика применения Enterprise Architect и T4-шаблонов для разработки систем...Практика применения Enterprise Architect и T4-шаблонов для разработки систем...
Практика применения Enterprise Architect и T4-шаблонов для разработки систем...CUSTIS
 
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
 
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
 
Ddd happy dev-2013-tsepkov
Ddd happy dev-2013-tsepkovDdd happy dev-2013-tsepkov
Ddd happy dev-2013-tsepkovMaxim Tsepkov
 
тестирование программного обеспечения
тестирование программного обеспечениятестирование программного обеспечения
тестирование программного обеспеченияNatalia Zhelnova
 

Tendances (20)

STRATOPLAN. Efficient Object-Oriented Design and Structured Quality of Softwa...
STRATOPLAN. Efficient Object-Oriented Design and Structured Quality of Softwa...STRATOPLAN. Efficient Object-Oriented Design and Structured Quality of Softwa...
STRATOPLAN. Efficient Object-Oriented Design and Structured Quality of Softwa...
 
Babich Presentation
Babich PresentationBabich Presentation
Babich Presentation
 
Специфика работы бизнес-аналитика в зависимости от типов проектов и методологий
Специфика работы бизнес-аналитика в зависимости от типов проектов и методологийСпецифика работы бизнес-аналитика в зависимости от типов проектов и методологий
Специфика работы бизнес-аналитика в зависимости от типов проектов и методологий
 
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]
 
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]
 
ITGM #5. What Is Enterprise Architecture [1.0, RUS]
ITGM #5. What Is Enterprise Architecture [1.0, RUS]ITGM #5. What Is Enterprise Architecture [1.0, RUS]
ITGM #5. What Is Enterprise Architecture [1.0, RUS]
 
Domain-Driven Design: Модель вместо требований
Domain-Driven Design: Модель вместо требованийDomain-Driven Design: Модель вместо требований
Domain-Driven Design: Модель вместо требований
 
Domain Driven Design: модель вместо требования
Domain Driven Design: модель вместо требованияDomain Driven Design: модель вместо требования
Domain Driven Design: модель вместо требования
 
Понятия технологии разработки объектно-ориентированных информационных систем ...
Понятия технологии разработки объектно-ориентированных информационных систем ...Понятия технологии разработки объектно-ориентированных информационных систем ...
Понятия технологии разработки объектно-ориентированных информационных систем ...
 
Модель системы — архитектура для Agile-разработки
Модель системы — архитектура для Agile-разработкиМодель системы — архитектура для Agile-разработки
Модель системы — архитектура для Agile-разработки
 
Денис Бесков. Как обеспечивать полноту требований
Денис Бесков. Как обеспечивать полноту требованийДенис Бесков. Как обеспечивать полноту требований
Денис Бесков. Как обеспечивать полноту требований
 
DDD: проблемы и решения при отражении модели предметной области в код
DDD: проблемы и решения при отражении модели предметной области в кодDDD: проблемы и решения при отражении модели предметной области в код
DDD: проблемы и решения при отражении модели предметной области в код
 
Практика применения Enterprise Architect и T4-шаблонов для разработки систем...
Практика применения Enterprise Architect и T4-шаблонов для разработки систем...Практика применения Enterprise Architect и T4-шаблонов для разработки систем...
Практика применения Enterprise Architect и T4-шаблонов для разработки систем...
 
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...
 
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]
 
Nfr and quality-models
Nfr and quality-modelsNfr and quality-models
Nfr and quality-models
 
Ddd happy dev-2013-tsepkov
Ddd happy dev-2013-tsepkovDdd happy dev-2013-tsepkov
Ddd happy dev-2013-tsepkov
 
тестирование программного обеспечения
тестирование программного обеспечениятестирование программного обеспечения
тестирование программного обеспечения
 

En vedette

Почему UML — плохой выбор для обучения аналитиков
Почему UML — плохой выбор для обучения аналитиковПочему UML — плохой выбор для обучения аналитиков
Почему UML — плохой выбор для обучения аналитиковSQALab
 
Как задавать требования к качеству ПО в цифрах
Как задавать требования к качеству ПО в цифрахКак задавать требования к качеству ПО в цифрах
Как задавать требования к качеству ПО в цифрахSQALab
 
Управление требованиями
Управление требованиямиУправление требованиями
Управление требованиямиIvan Shamaev
 
Babok v2.0 перевод на русский язык свод знаний по бизнес анализу
Babok v2.0 перевод на русский язык свод знаний по бизнес анализуBabok v2.0 перевод на русский язык свод знаний по бизнес анализу
Babok v2.0 перевод на русский язык свод знаний по бизнес анализуIvan Shamaev
 
ТРИЗ. Применение в бизнес-анализе
ТРИЗ. Применение в бизнес-анализеТРИЗ. Применение в бизнес-анализе
ТРИЗ. Применение в бизнес-анализеАндрей Курьян
 
Контрольный список для проверки требований
Контрольный список для проверки требованийКонтрольный список для проверки требований
Контрольный список для проверки требованийIvan Shamaev
 
Глава 9 методы и техники бизнес-анализа (babok 2.0 на русском скачать)
Глава 9 методы и техники бизнес-анализа (babok 2.0 на русском скачать)Глава 9 методы и техники бизнес-анализа (babok 2.0 на русском скачать)
Глава 9 методы и техники бизнес-анализа (babok 2.0 на русском скачать)Ivan Shamaev
 
05 задачи эксперта в работе аналитика
05 задачи эксперта в работе аналитика05 задачи эксперта в работе аналитика
05 задачи эксперта в работе аналитикаNatalya Sveshnikova
 
Лекция 11. Вычислительная модель Pregel
Лекция 11. Вычислительная модель PregelЛекция 11. Вычислительная модель Pregel
Лекция 11. Вычислительная модель PregelTechnopark
 
Введение в моделирование бизнес процессов
Введение в моделирование бизнес процессовВведение в моделирование бизнес процессов
Введение в моделирование бизнес процессовNatalia Zhelnova
 
09 - Практика UML. Use Case диаграммы
09 - Практика UML. Use Case диаграммы09 - Практика UML. Use Case диаграммы
09 - Практика UML. Use Case диаграммыRoman Brovko
 
04 - Практика UML. Описание прецедентов
04 - Практика UML. Описание прецедентов04 - Практика UML. Описание прецедентов
04 - Практика UML. Описание прецедентовRoman Brovko
 
13 - Практика UML. Переход к разработке
13 - Практика UML. Переход к разработке13 - Практика UML. Переход к разработке
13 - Практика UML. Переход к разработкеRoman Brovko
 
12 - Практика UML. Создание wireframe
12 - Практика UML. Создание wireframe12 - Практика UML. Создание wireframe
12 - Практика UML. Создание wireframeRoman Brovko
 
01 - Практика UML. Нужен ли UML?
01 - Практика UML. Нужен ли UML?01 - Практика UML. Нужен ли UML?
01 - Практика UML. Нужен ли UML?Roman Brovko
 
02 - Практика UML. Уровни приложения
02 - Практика UML. Уровни приложения02 - Практика UML. Уровни приложения
02 - Практика UML. Уровни приложенияRoman Brovko
 
03 - Практика UML. Прецеденты
03 - Практика UML. Прецеденты03 - Практика UML. Прецеденты
03 - Практика UML. ПрецедентыRoman Brovko
 
Обзор сертификаций для ИТ-аналитиков (и не только)
Обзор сертификаций для ИТ-аналитиков (и не только)Обзор сертификаций для ИТ-аналитиков (и не только)
Обзор сертификаций для ИТ-аналитиков (и не только)Denis Beskov
 
Обучение IT-аналитиков
Обучение IT-аналитиковОбучение IT-аналитиков
Обучение IT-аналитиковNatalia Zhelnova
 
Minute Of Eclipse Papyrus Pre-Committing
Minute Of Eclipse Papyrus Pre-CommittingMinute Of Eclipse Papyrus Pre-Committing
Minute Of Eclipse Papyrus Pre-CommittingBENOIS Jérôme
 

En vedette (20)

Почему UML — плохой выбор для обучения аналитиков
Почему UML — плохой выбор для обучения аналитиковПочему UML — плохой выбор для обучения аналитиков
Почему UML — плохой выбор для обучения аналитиков
 
Как задавать требования к качеству ПО в цифрах
Как задавать требования к качеству ПО в цифрахКак задавать требования к качеству ПО в цифрах
Как задавать требования к качеству ПО в цифрах
 
Управление требованиями
Управление требованиямиУправление требованиями
Управление требованиями
 
Babok v2.0 перевод на русский язык свод знаний по бизнес анализу
Babok v2.0 перевод на русский язык свод знаний по бизнес анализуBabok v2.0 перевод на русский язык свод знаний по бизнес анализу
Babok v2.0 перевод на русский язык свод знаний по бизнес анализу
 
ТРИЗ. Применение в бизнес-анализе
ТРИЗ. Применение в бизнес-анализеТРИЗ. Применение в бизнес-анализе
ТРИЗ. Применение в бизнес-анализе
 
Контрольный список для проверки требований
Контрольный список для проверки требованийКонтрольный список для проверки требований
Контрольный список для проверки требований
 
Глава 9 методы и техники бизнес-анализа (babok 2.0 на русском скачать)
Глава 9 методы и техники бизнес-анализа (babok 2.0 на русском скачать)Глава 9 методы и техники бизнес-анализа (babok 2.0 на русском скачать)
Глава 9 методы и техники бизнес-анализа (babok 2.0 на русском скачать)
 
05 задачи эксперта в работе аналитика
05 задачи эксперта в работе аналитика05 задачи эксперта в работе аналитика
05 задачи эксперта в работе аналитика
 
Лекция 11. Вычислительная модель Pregel
Лекция 11. Вычислительная модель PregelЛекция 11. Вычислительная модель Pregel
Лекция 11. Вычислительная модель Pregel
 
Введение в моделирование бизнес процессов
Введение в моделирование бизнес процессовВведение в моделирование бизнес процессов
Введение в моделирование бизнес процессов
 
09 - Практика UML. Use Case диаграммы
09 - Практика UML. Use Case диаграммы09 - Практика UML. Use Case диаграммы
09 - Практика UML. Use Case диаграммы
 
04 - Практика UML. Описание прецедентов
04 - Практика UML. Описание прецедентов04 - Практика UML. Описание прецедентов
04 - Практика UML. Описание прецедентов
 
13 - Практика UML. Переход к разработке
13 - Практика UML. Переход к разработке13 - Практика UML. Переход к разработке
13 - Практика UML. Переход к разработке
 
12 - Практика UML. Создание wireframe
12 - Практика UML. Создание wireframe12 - Практика UML. Создание wireframe
12 - Практика UML. Создание wireframe
 
01 - Практика UML. Нужен ли UML?
01 - Практика UML. Нужен ли UML?01 - Практика UML. Нужен ли UML?
01 - Практика UML. Нужен ли UML?
 
02 - Практика UML. Уровни приложения
02 - Практика UML. Уровни приложения02 - Практика UML. Уровни приложения
02 - Практика UML. Уровни приложения
 
03 - Практика UML. Прецеденты
03 - Практика UML. Прецеденты03 - Практика UML. Прецеденты
03 - Практика UML. Прецеденты
 
Обзор сертификаций для ИТ-аналитиков (и не только)
Обзор сертификаций для ИТ-аналитиков (и не только)Обзор сертификаций для ИТ-аналитиков (и не только)
Обзор сертификаций для ИТ-аналитиков (и не только)
 
Обучение IT-аналитиков
Обучение IT-аналитиковОбучение IT-аналитиков
Обучение IT-аналитиков
 
Minute Of Eclipse Papyrus Pre-Committing
Minute Of Eclipse Papyrus Pre-CommittingMinute Of Eclipse Papyrus Pre-Committing
Minute Of Eclipse Papyrus Pre-Committing
 

Similaire à Практический анализ и визуальное моделирование на UML

рит2007 требования и состав работ бесков доронин
рит2007   требования и состав работ   бесков доронинрит2007   требования и состав работ   бесков доронин
рит2007 требования и состав работ бесков доронинMedia Gorod
 
Конспект лекций по курсу "Шаблоны разработки ПО"
Конспект лекций по курсу "Шаблоны разработки ПО"Конспект лекций по курсу "Шаблоны разработки ПО"
Конспект лекций по курсу "Шаблоны разработки ПО"Sergey Nemchinsky
 
Ситуационная инженерия методов
Ситуационная инженерия методовСитуационная инженерия методов
Ситуационная инженерия методовAnatoly Levenchuk
 
Симуляционное моделирование и семантические технологии
Симуляционное моделирование и семантические технологииСимуляционное моделирование и семантические технологии
Симуляционное моделирование и семантические технологииSergey Gorshkov
 
UML: Первое знакомство
UML: Первое знакомствоUML: Первое знакомство
UML: Первое знакомствоAlexander Babich
 
Сбор и анализ данных для моделирования деятельности организации
Сбор и анализ данных для моделирования деятельности организацииСбор и анализ данных для моделирования деятельности организации
Сбор и анализ данных для моделирования деятельности организацииOlya Kollen, PhD
 
Системная инженерия как технология мышления
Системная инженерия как технология мышленияСистемная инженерия как технология мышления
Системная инженерия как технология мышленияAnatoly Levenchuk
 
Системное мышление -- материалы курса (2016)
Системное мышление -- материалы курса (2016)Системное мышление -- материалы курса (2016)
Системное мышление -- материалы курса (2016)Anatoly Levenchuk
 
Основы концептуального проектирования
Основы концептуального проектированияОсновы концептуального проектирования
Основы концептуального проектированияAnton Tyukov
 
Современна Программная инженерия. Системная инженерия
Современна Программная инженерия. Системная инженерияСовременна Программная инженерия. Системная инженерия
Современна Программная инженерия. Системная инженерияMarcus Akoev
 
А.Левенчук -- SysArchi
А.Левенчук -- SysArchiА.Левенчук -- SysArchi
А.Левенчук -- SysArchiAnatoly Levenchuk
 
Преподавание архитектуры предприятия в университетах РФ
Преподавание архитектуры предприятия в университетах РФПреподавание архитектуры предприятия в университетах РФ
Преподавание архитектуры предприятия в университетах РФMaxim Arzumanyan
 
моделисущностей
моделисущностеймоделисущностей
моделисущностейNikolai Kireev
 
Бизнес и системный анализ весна 2013 лекция 5
Бизнес и системный анализ весна 2013 лекция 5Бизнес и системный анализ весна 2013 лекция 5
Бизнес и системный анализ весна 2013 лекция 5Technopark
 
О концептуальном моделировании
О концептуальном моделированииО концептуальном моделировании
О концептуальном моделированииОтшельник
 
Проектирование больших ИС в Agile (статья)
Проектирование больших ИС в Agile (статья)Проектирование больших ИС в Agile (статья)
Проектирование больших ИС в Agile (статья)Andrey Bibichev
 
Практика построения проектных офисов часть 1
Практика построения проектных офисов часть 1 Практика построения проектных офисов часть 1
Практика построения проектных офисов часть 1 ProjectPractice2013
 

Similaire à Практический анализ и визуальное моделирование на UML (20)

рит2007 требования и состав работ бесков доронин
рит2007   требования и состав работ   бесков доронинрит2007   требования и состав работ   бесков доронин
рит2007 требования и состав работ бесков доронин
 
Конспект лекций по курсу "Шаблоны разработки ПО"
Конспект лекций по курсу "Шаблоны разработки ПО"Конспект лекций по курсу "Шаблоны разработки ПО"
Конспект лекций по курсу "Шаблоны разработки ПО"
 
Ситуационная инженерия методов
Ситуационная инженерия методовСитуационная инженерия методов
Ситуационная инженерия методов
 
Симуляционное моделирование и семантические технологии
Симуляционное моделирование и семантические технологииСимуляционное моделирование и семантические технологии
Симуляционное моделирование и семантические технологии
 
UML: Первое знакомство
UML: Первое знакомствоUML: Первое знакомство
UML: Первое знакомство
 
лаф 2014
лаф 2014лаф 2014
лаф 2014
 
Сбор и анализ данных для моделирования деятельности организации
Сбор и анализ данных для моделирования деятельности организацииСбор и анализ данных для моделирования деятельности организации
Сбор и анализ данных для моделирования деятельности организации
 
UML: Kinds of Diagram
UML:  Kinds of DiagramUML:  Kinds of Diagram
UML: Kinds of Diagram
 
Системная инженерия как технология мышления
Системная инженерия как технология мышленияСистемная инженерия как технология мышления
Системная инженерия как технология мышления
 
Системное мышление -- материалы курса (2016)
Системное мышление -- материалы курса (2016)Системное мышление -- материалы курса (2016)
Системное мышление -- материалы курса (2016)
 
Основы концептуального проектирования
Основы концептуального проектированияОсновы концептуального проектирования
Основы концептуального проектирования
 
Современна Программная инженерия. Системная инженерия
Современна Программная инженерия. Системная инженерияСовременна Программная инженерия. Системная инженерия
Современна Программная инженерия. Системная инженерия
 
семинар Uml
семинар Umlсеминар Uml
семинар Uml
 
А.Левенчук -- SysArchi
А.Левенчук -- SysArchiА.Левенчук -- SysArchi
А.Левенчук -- SysArchi
 
Преподавание архитектуры предприятия в университетах РФ
Преподавание архитектуры предприятия в университетах РФПреподавание архитектуры предприятия в университетах РФ
Преподавание архитектуры предприятия в университетах РФ
 
моделисущностей
моделисущностеймоделисущностей
моделисущностей
 
Бизнес и системный анализ весна 2013 лекция 5
Бизнес и системный анализ весна 2013 лекция 5Бизнес и системный анализ весна 2013 лекция 5
Бизнес и системный анализ весна 2013 лекция 5
 
О концептуальном моделировании
О концептуальном моделированииО концептуальном моделировании
О концептуальном моделировании
 
Проектирование больших ИС в Agile (статья)
Проектирование больших ИС в Agile (статья)Проектирование больших ИС в Agile (статья)
Проектирование больших ИС в Agile (статья)
 
Практика построения проектных офисов часть 1
Практика построения проектных офисов часть 1 Практика построения проектных офисов часть 1
Практика построения проектных офисов часть 1
 

Практический анализ и визуальное моделирование на UML

  • 1. ПРАКТИЧЕСКИЙ АНАЛИЗ И ВИЗУАЛЬНОЕ МОДЕЛИРОВАНИЕ НА UML ПРЕЗЕНТАЦИЯ КУРСА ONLINE-ТРЕНИНГОВ www. school.system-analysis.ru www.webmax.by Студия ИТ WebMax.BY, г. Минск Школа Системного Анализа, г. Москва
  • 2. Историческая справка  В 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
  • 3. Идея тренинга С середины 90-х годов мне довелось работать в Германии на компании “ULTRAKUST electronic GmbH“, которая занималась разработкой автоматизированных измерительных систем, а также в рамках небольшого собственного предприятия “НИКМА ПК сервис”. По роду деятельности я общался с немецкими заказчиками, выяснял требования, ставил задачи небольшой группе программистов в РБ, и сдавал готовый продукт. В конце 90-х годов программные системы усложнились, стали информационными с развитой структурой данных, а описательные методики, которые я применял, оказались не эффективными. Остро встала необходимость в использовании визуального моделирования. Так в 2000 году я попал на стенд компании “Rational Software” на выставке “CeBIT“ в г. Ганновер. После многочасового общения с менеджерами и демонстрации возможностей инструмента, мне был вручен диск с лицензионной “Rational Rose 98i”, а через несколько месяцев в Минске посчастливилось купить русское издание книги У. и М. Боггс “UML, Rational Rose 98i”.
  • 4. Идея тренинга Вернувшись в Германию, я перечитал несколько раз эту книгу и мне казалось, что я смогу смоделировать ВСЁ… НО, первые же проекты показали: НОТАЦИЯ и ИНСТРУМЕНТ – это слишком мало для построения адекватных моделей. Модели получаются слишком абстрактными, неоднозначными, возникает множество вопросов. Оказалось, нужно ещё понимать принципы ООП и “клиент-серверной модели”, разбираться в процессах разработки и в представлениях архитектуры. Годы ушли на совершенствование навыков. Когда я стал преподавать, возник вопрос: как за короткий курс обучить этому слушателей? Ответ нашёл у Г. Буча. Он объяснял принципы проектирования на примере гидропонной системы. Итак, на примере небольшого, но показательного проекта, из моей практики, приглашаю Вас вместе пройти все этапы от бизнес-целей до архитектуры системного анализа, получив ответы на многие практические вопросы, ранее не отражённые в литературе. Николай Киреев
  • 5. Вопросы тренинга  Анализ требований и разработка архитектуры с помощью визуальных UML-моделей – это миф или реальность?  Как UML моделирует окружающий мир (domain model) и программную систему (application model)?  Что такое представления архитектуры и как они позволяют структурировать проект?  Как читать и анализировать vision? На что влияют бизнес- цели? Кому нужен глоссарий, как правильно его писать?  Бизнес-аналитик, аналитик требований и системный аналитик: как распределяются их обязанности и какие артефакты они создают (в рамках RUP)?  Есть ли общие практические правила для построения аналитических моделей?  Нужно ли аналитикам понимать принципы ООП и «клиент- серверную модель»? Чем системный аналитик отличается от проектировщика?
  • 6. Вопросы тренинга  Сущности предметной области: как лучше моделировать (классами или объектами)? Как на практике разграничить сущности, атрибуты и пользователей? Показывать ли отношения между сущностями и какие? Что писать в documentation?  Как моделировать бизнес-процессы? Чем activity отличается от actions? Как показать решающие правила и ограничения? Когда нужна диаграмма состояний?  Модели прецедентов: какие требования они отображают? Как создавать эффективные use case- модели? От чего зависит уровень их детализации? Смысл стереотипов с приставкой business? Как избегать функциональной декомпозиции.  Что такое сценарии использования? Кому, для чего и какие нужны сценарии? Что дают wireframes?
  • 7. Вопросы тренинга  Что такое аналитическая модель? Стереотипы классов анализа (entity, control и boundary): что они описывают, на что влияют, в каких моделях используются? Что такое база данных с точки зрения ООП?  Как выявлять и моделировать объекты системного анализа, их связи и поведение? Кем и для чего используются эти модели?  Как моделировать классы анализа? Чем они будут отличаться от классов проектирования? Как выявлять и показывать структуру связей между классами. Какие виды отношений классов (ассоциация, наследование, агрегация, зависимость) имеются, чем они отличаются, на что влияют. Чем отличаются диаграммы классов, созданные аналитиками от аналогичных, созданных проектировщиками?
  • 8. Программа занятий  Занятие 1. Цели и область применения разрабатываемого ПО. Глоссарий предметной области. Бизнес-сущности, их атрибуты, выявление, отличия и моделирование.  Занятие 2. Три круга заинтересованных лиц. Модель действующих лиц и их функциональных обязанностей. Моделирование бизнес-процессов: решающие правила, граничные условия, потоки событий.  Занятие 3. Пользовательские и функциональные требования к ПО. Их выявление, детализация, трассирование.  Занятие 4. Принципы построения Use Case-диаграмм. Пользователи и их типы, связи на Use Case-диаграммах.  Занятие 5. Сценарии и особенности их описания. Использование wireframes.  Занятие 6. Архитектура системного анализа: объекты и классы (entity, control, boundary). Динамическая, статическая объектные модели, модель классов анализа построение и особенности.
  • 9.  6 занятий по 4 часа* практической работы над проектом в online  самостоятельное изучение теории по предоставленным материалам и ссылкам Продолжительность курса * В отдельных случаях, по желанию участников, продолжительность курса может быть увеличена, но не более, чем на 2 занятия
  • 10.  В занятиях используются современные инструменты коллективной удалённой работы и обмена файлами (GoToMeeting, Dropbox и т. д.), благодаря которым осуществляется инструктаж и обсуждение результатов  Предоставляется удобный в использовании инструмент для построения UML-моделей, методические пособия, статьи, концепция (vision) и html-прототип разрабатываемого ПО  Перед каждым занятием участники самостоятельно изучают теорию (рекомендуемая литература) и выполняют работы в рамках учебного проекта  Каждое занятие начинается с обсуждения результатов и с дискуссии по теоретическим аспектам темы занятия  В процессе занятия коллективно решаются и обсуждаются многочисленные задачи, как в рамках разрабатываемого проекта, так и из других предметных областей  Занятия проходят на русском языке, в артефактах частично используется английская лексика. Формат обучения
  • 11. Индивидуальный подход Каждый участник предлагает свои идеи и решения, создаёт свои модели, которые обсуждаются с тренером Каждое занятие — это определённый этап деятельности аналитика от работы над концепцией до создания архитектуры приложения
  • 12. Особенности курса Уникальность проекта — в основе реальный проект, выполненный автором для немецкого заказчика Нетрадиционная бизнес-область. Основной бизнес-процесс — контроль составления смеси из различных компонентов С одной стороны, данная предметная область не позволит применять избитые шаблоны и штампы, с другой стороны — не требует узкопрофессиональных знаний и содержит минимум специфической терминологии.
  • 13. Особенности курса Уникальность материалов — используются авторское методическое пособие и программный продукт, имитирующий функционал разрабатываемого приложения Предоставляются все материалы и инструменты, необходимые для работы над данным проектом Возможно использование собственного инструментария для моделирования, вплоть до рисования на салфетках…
  • 14. Так тоже можно, но CASE-средства делают модели лучше! CASE (англ. Computer-Aided Software Engineering)
  • 15. Что в этом курсе главное?  НЕ специфика предметной области — аналитик должен уметь „входить“ в любую новую для себя область бизнеса. Сегодня литьё металлов, завтра обеспечение платных медицинских услуг, виртуальная реальность и статистика туристического бизнеса…  НЕ инструмент визуального моделирования или управления требованиями — инструменты меняются быстро и в каждой компании предпочитают свои. Одни используют Visio, другие Sparx-EA, третьи MagicDraw, но стандарт языка UML один!
  • 16. Что в этом курсе главное? ГЛАВНОЕ — практическое освоение методологии моделирования Её можно использовать в анализе любой предметной области, применяя при этом любой инструмент моделирования, действуя в рамках любого процесса разработки  ГЛАВНОЕ — возможность обсуждения созданных моделей Совместное обсуждение моделей позволяет понять их достоинства и недостатки, даёт опыт и повышает навыки в моделировании
  • 17. Особенности проекта • неопределённость части функциональных требований; • наличие скрытых функций; • необходимость разработки пользовательских сценариев
  • 18. Чему научит курс?  Приёмам извлечения и анализа информации из текста, из общения с пользователями, из визуальных моделей  Методологии проектирования на основе визуальных моделей (принцип MDA — Model Driven Architecture)  Строить адекватные UML-модели, которые будут понятны и востребованы участниками проекта, включая пользователей, заказчиков, проектировщиков и т. д.  Правильно и за минимальное время создавать артефакты: глоссарий, матрица требований, сценарии использования  Применять принципы объектно-ориентированного подхода при создании архитектуры системного анализа
  • 19. Для кого предназначен?  полезен всем, кто ведёт самостоятельную деятельность по разработке ПО;  для кого актуальны вопросы архитектуры и моделирования баз данных;  также для тех, кто работает аналитиком, но хочет повысить свою квалификацию в области визуального моделирования;  поможет начинающим аналитикам быстрее вникнуть в суть выбранной ими специальности, лучше понять принципы ООП и основы анализа требований.  для тех, кто занимается разработкой ПО и хочет попробовать себя в ролях бизнес- или системного аналитика.
  • 20. Кратко о тренере  Опыт разработки электронных систем и прикладного ПО — с 1982 г.;  Опыт аналитика ПО (анализ требований, бизнес- и системный анализ) — с 1990 г.;  Разработка ПО для иностранных заказчиков (Германия, Голландия, Польша, Латвия, Россия), работа в Германии («Ultrakust electronic GmbH») — с 1992 г.;  Применение UML, методологии RUP и Rational Rose в разработке ПО — с 2000 г.;  Преподавание дисциплины «Анализ и проектирование ПО» на факультете переподготовки и повышения квалификации БГУИР г. Минск — с 2002 г.  Проведение тренингов для разработчиков ПО на «EPAM Systems», «АСКОН Бел», «Образовательный центр ПВТ» и др. — с 2004 г.  Разработка методики реверсивного анализа требований с использованием интерактивных html-прототипов, созданных средством Axure RP Pro — c 2013 г. НИКОЛАЙ КИРЕЕВ — практикующий аналитик, PM, тренер, старший преподаватель ИИТ БГУИР, владелец ресурса „Студия ИТ WebMax.BY”, автор методических пособий и статей, участник международных конференций аналитиков и разработчиков ПО, индивидуальныйпредприниматель(разработкаПО, ИТ-консалтинг)
  • 21. Контакты  Вопросы к тренеру e-Mail: info@webmax.by Skype: nousy123 Тел.: +375 (25) 633-76-78 Сайт: www.webmax.by  Запись на тренинг по ссылке: http://school.system-analysis.ru/uml-online/