Denis Pasechnik
advertisement
Denis Pasechnik Microsoft UML Моделирование в VS2012 Denis Pasechnik Certified PMP Level B, MSFP depa@microsoft.com Содержание доклада: Часть 1 • Проведение "Мозгового-Штурма" с использованием Visual Studio 2012 • Организация основных функциональных возможностей системы в виде Use Case Моделей. • Моделирование бизнес содержания в виде концептуальной диаграммы классов. • Описание бизнес процессов с использованием диаграмм активности. Проведение "Мозгового-Штурма" с использованием Visual Studio 2012 Начинаем с Бизнес Контекста Tailspin Toys •Небольшой магазин по продаже разнообразных моделей самолетов для коллекционеров. (Собираемых или уже Готовых) •Необходим Онлайн ресурс через который можно существенно расширить канал продаж. Что необходимо учесть в оценке Формируем Vision • Определиться с границами нашего решения • Кто будет влиять на наше решение • Что будет автоматизировано в рамках решения • Идентифицировать существующие ограничения для нашего решения Далее - > Стартуем с процессом сбора требований и формируем функциональную спецификацию Модель – первый вариант Модель Замечания •Стараться ограничивать время сессии проведения до 1 часа. •Всегда стартовать с Vision нашего решения (Контекста) •Четко идентифицировать, ”кто живет внутри системы а кто снаружи” (Scope) •Описание целей с пользовательской точки зрения (Бизнес Ценности) •Стараться сгенерировать как можно больше идей и охватить все. Организация основных функциональных возможностей системы в виде Use Case Модели Базовые принципы: •Разбиваем пользовательские цели и задачи на раздельные небольшие по размеру и соответственно легко воспринимаемые диаграммы •Используем диаграммы, как структурное руководство для описания требований в виде use case документов Несколько слов о Актерах •Актеры всегда ВНЕШНИЕ участники •Актеры взаимодействуют НАПРЯМУЮ с системой •Актеры представляют РОЛИ •Use Cases ВСЕГДА инициируется актером Модель Замечания •Думайте о актерах как о ролях, а не названиях должностей •Используйте специфичную для бизнеса терминологию •Фокусируйтесь на целях актеров, а не на деталях реализации •Используйте продуманные глагольные формы в наименованиях •Фокусируйтесь на одной конкретной “функциональной области” в каждой диаграмме •Упорядочивайте use cases на диаграммах для отображения идентифицированной последовательности •Используйте при документировании важных моментов и деталей Моделирование бизнес содержания в виде концептуальной диаграммы классов domain model или analysis class model •Анализ предметной области и определение ответственностей •Выработка согласованного целостного словаря терминов предметной области • Используемого в модели требований • Используемого в коммуникационной модели между приложением и пользователями •Описать типы информации используемые в системе и те которыми она обменивается с другими системами •Независимый механизм сбора требований Шаги анализа •Идентифицировать ключевые термины используемые как данные или типы элементов •Использовать “существительные” в описании требований как классы •Использовать enumerations для определения литеральных значений или состояний в которых может находиться обьект в рамках бизнес процесса •Итерируем и уточняем в случае появления или выявления новых требований Модели Замечания • Используйте адекватные названия ( без абревиатур ) • Отражайте только те классы которые нужны для описания требований • Фокус на именах и простых связях (ассоциациях) • Не волнуемся о агрегировании или композиции – это мы выявим позднее в рамках детального проектирования • Выявляйте множественность в рамках связей • Добавляем атрибуты и типы только если они нужны для повышения прозрачности восприятия требования • Придерживаемся стандартных типов для атрибутов: Boolean, Integer, String • Добавляем специфичные только если это повышает понимание (Temperature : Celsius, Duration : Weeks) • Оставаться имплементационно независимыми • Не уточнять видимость – это в рамках детального дизайна • Избегать моделирования - keys или IDs – это детали реализации • А также - verbs/actions/operations/functions Описание бизнес процессов с использованием диаграмм активности. •Следующее поколение блок-схем •Используется для отображения процессов •Бизнес процессов •Работо-потоков •Алгоритмов •Расширяет использование use cases •Показывает поток задач вместо структуры Модели Рекомендации •Используем их для идентификации и валидации бизнес процессов •Думаем в терминах пользовательских действий •Фокусируемся на действиях которые видны извне по отношению к системе •Используем для отображения потока активностей который охватывает несколько use cases •Наилучшая диаграмма для отображения параллельных операций •Фокусировка только на одной “активности” в рамках каждой диаграммы Вопросы?
