Аналитическое моделирование имеет стратегически важное значение, поскольку на этом этапе делается попытка смоделировать основное поведение системы.
Цель рабочего потока анализа (с точки зрения ОО-анализа) – создание аналитической модели. Данная модель фокусируется на том, что должна делать система. Детали того, как система будет это делать, предоставляются потоку проектирования.
Граница между анализом и проектированием довольно неопределенная, и до известной степени все зависит от аналитика.
В рабочем потоке анализа создаются два ключевых артефакта:
• классы анализа – ключевые понятия в бизнес сфере;
• реализации прецедентов – иллюстрируют, как экземпляры классов анализа могут взаимодействовать для реализации поведения системы, описанного прецедентами.
• Анализ прецедента
• Анализ класса
• Анализ пакета
• Создаваемые модели должны «рассказывать историю». Каждая диаграмма должна раскрывать некоторые важные части поведения системы. Иначе зачем они нужны?
• Необходимо сосредоточиться на отображении основной картины. Не надо углубляться в детали того, как будет работать система. Для этого отводится достаточно времени при проектировании.
• Необходимо четко различать предметную область (бизнес требования) и область решения (детальные конструктивные соображения). Основное внимание всегда должно быть направлено на абстракции предметной области. Например, при моделировании системы электронной торговли в аналитической модели должны присутствовать классы Customer (клиент), Order (заказ) и ShoppingBasket (корзина покупок). Здесь не должно быть классов доступа к базе данных или классов для установления соединений, поскольку они – артефакты области решения.
• Всегда необходимо стремиться минимизировать связанность (coupling). Каждая ассоциация между классами увеличивает их связанность.
• Если присутствует естественная и очевидная иерархия абстракций, должна быть рассмотрена возможность применения наследования. При анализе иерархия никогда не должна применяться просто для повторного использования кода. Наследование – самая сильная форма связанности классов.
• Всегда должен задаваться вопрос: «Модель полезна для всех заинтересованных сторон?» Нет ничего хуже, чем создавать аналитическую модель, которая игнорируется пользователями или проектировщиками и разработчиками. Пока что это происходит очень часто, особенно с неопытными аналитиками. Основная превентивная стратегия при этом – сделать аналитическую модель и процесс моделирования максимально открытыми, по возможности привлечь в него заинтересованные стороны, проводить частые и публичные обзоры.
Цель рабочего потока анализа (с точки зрения ОО-анализа) – создание аналитической модели. Данная модель фокусируется на том, что должна делать система. Детали того, как система будет это делать, предоставляются потоку проектирования.
Граница между анализом и проектированием довольно неопределенная, и до известной степени все зависит от аналитика.
• классы анализа – ключевые понятия в бизнес сфере;
• реализации прецедентов – иллюстрируют, как экземпляры классов анализа могут взаимодействовать для реализации поведения системы, описанного прецедентами.
Задачи рабочего потока
• Архитектурный анализ• Анализ прецедента
• Анализ класса
• Анализ пакета
Аналитическая модель – практические правила:
• Аналитическая модель всегда создается на языке соответствующей сферы деятельности. Абстракции аналитической модели должны формировать часть словаря бизнес сферы.• Создаваемые модели должны «рассказывать историю». Каждая диаграмма должна раскрывать некоторые важные части поведения системы. Иначе зачем они нужны?
• Необходимо сосредоточиться на отображении основной картины. Не надо углубляться в детали того, как будет работать система. Для этого отводится достаточно времени при проектировании.
• Необходимо четко различать предметную область (бизнес требования) и область решения (детальные конструктивные соображения). Основное внимание всегда должно быть направлено на абстракции предметной области. Например, при моделировании системы электронной торговли в аналитической модели должны присутствовать классы Customer (клиент), Order (заказ) и ShoppingBasket (корзина покупок). Здесь не должно быть классов доступа к базе данных или классов для установления соединений, поскольку они – артефакты области решения.
• Всегда необходимо стремиться минимизировать связанность (coupling). Каждая ассоциация между классами увеличивает их связанность.
• Если присутствует естественная и очевидная иерархия абстракций, должна быть рассмотрена возможность применения наследования. При анализе иерархия никогда не должна применяться просто для повторного использования кода. Наследование – самая сильная форма связанности классов.
• Всегда должен задаваться вопрос: «Модель полезна для всех заинтересованных сторон?» Нет ничего хуже, чем создавать аналитическую модель, которая игнорируется пользователями или проектировщиками и разработчиками. Пока что это происходит очень часто, особенно с неопытными аналитиками. Основная превентивная стратегия при этом – сделать аналитическую модель и процесс моделирования максимально открытыми, по возможности привлечь в него заинтересованные стороны, проводить частые и публичные обзоры.
Комментариев нет:
Отправить комментарий