Программная инженерия Пример проектирования ИС продолжение Лекция 11

Программная инженерия Пример проектирования ИС (продолжение) Лекция 11 (файл «Лекция 11 - эскизный проект ИС ЛОМБАРД. doc» , стр. 49 -66)

Шаблон для описания Use Cases Диаграмма системных Use Cases показывает: • Какие пользователи к каким функциям ИС обращаются • Какие связи есть между Use Cases Описание системных Use Cases: (детальный шаблон для Use Cases со средними и высокими рисками) 1. Наименование варианта использования (как в диаграмме) Вид (бизнес/системный) Тип (базовый, расширение, обобщение, специализированный) 1. 1. Краткое описание (один абзац) 1. 2. Бизнес цели и выгоды варианта использования 1. 3. Акторы 1. 3. 1. Первичные акторы (те люди или системы, которые инициализируют Use Case 1. 3. 2. Вторичные акторы (те, что получают сообщения Use Case 1. 3. 3. Заинтересованные в Use Case владельцы бизнеса

Начальная фаза (детально) Описание системных Use Cases (продолжение): 1. 4. Предусловия, необходимые для работы Use Case 1. 4. 1. Триггеры (события или условия «включающие» Use Case) 1. 4. 1. Условия включения 1. 5. Постусловия 1. 5. 1. Постусловия успешного завершения Use Case 1. 5. 2. Постусловия аварийного завершения Use Case 1. 6. Точки расширения внутреннего подпроцесса Use Case 1. 7. Приоритет Use Case 1. 8. Статус Пример: Краткое описание завершено 1. 03. 2008; Основной поток и риски завершены 10. 03. 2008; Все потоки – 17. 03. 2008; Кодирование завершено 17. 03. 2008; Тестирование-24. 03. 2008; Внутренний релиз – 26. 03. 2008; Размещение – 31. 03. 2008; 1. 9. Предполагаемое внедрение 1. 10. Фактическое внедрение 1. 11. Контекстная диаграмма (диаграмма связей Use Case)

Начальная фаза (детально) Описание системных Use Cases (продолжение): 2. Поток событий Use Case • Основной поток • 2. Х Альтернативный поток (2. Х – номер шага в основном потоке, где может начаться альтернативный поток) • 2. Y Исключительные потоки (2. Y. – номер шага в основном потоке, где может начаться исключительный поток) 3. Специальные требования (применяемые только к данному Use Case (защита информации, надежность, технологические ограничения…) 4. Диаграмма действий 5. Интерфейс пользователя (макет, прототип) 6. Диаграмма классов (для описания всех объектов Use Case ) 7. Предположения (о Use Case, согласованные с владельцами) 8. Информационные элементы (документы с правилами относительно данных, относящихся к Use Case) 9. Сообщения и подсказки (наименование + описание) 10. Бизнес правила (ссылки на те правила, которые нужны для Use Case 11. Внешние интерфейсы 12. Связанные с Use Case явления, вопросы и другие артефакты

Фаза Elaboration: Классы Класс – дескриптор множества однородных объектов (материальных и нематер. ) определяющий их структуру (атрибуты) и поведение (операции) Способы обнаружения классов: А) Прямой. Если предметная область (Пр. О) хорошо известна, то разработчики сразу могут составить для нее начальный список классов Б) По существительным Многие существительные в описаниях требований (в шаблонах Use Cases) – могут определять класс. Для их выделения к списку всех существительных применяют фильтры, отсеивающие непригодные существительные Фильтр 1 (избыточность): Заказ и Товарный заказ Фильтр 2 (нерелевантность): Если существительное не имеет отношения к Пр. О, (нерелевантно к Пр. О) его нужно отбросить. Фильтр 3(атрибуты): Отбросить существительные, являющиеся атрибутами Пр. О Проверочный вопрос – может ли иметь то, что называется проверяемым существительным структуру и поведение? Если нет – это не класс. Пример: номер кредитной карты, дата заказа

Фаза Elaboration: Классы Фильтр 4 (операции): Существительное, которое определяет ответственность какого-либо другого класса не является классом Пример: Рассчет налога. Фильтр 5 (роль): Существительное, которое определяет статус некоторой сущности или ее классификацию не является классом Пример: Предпочтительный клиент (временный статус) Фильтр 6 (событие): Существительное, которое описывает некоторый интервал времени, частоту повторения чего-то, не является классом Пример: Печатать отчет раз в неделю. (неделя не является классом) Фильтр 7 (устройство): Существительное, которое определяет техническое устройство не является классом Пример: принтер Типы классов и 1. Классы-сущности (entity classes). Представляют главное содержание Пр. О. Клиент, Заказ. Требуют сохранения информации о сущностях длительное время. 2. Интерфейсные или граничные классы (boundary classes). Выполняют задачи границы между внешними акторами, желающими поработать с приложением и классами-сущностями.

Фаза Elaboration: Классы Типы классов (продолжение) 3. Управляющие классы (control classes). Эти классы являются координаторами действий в Пр. О. Управляющие классы иногда называют контроллерами Управляющие классы – хранители (депозитории) тех свойств и поведения которые трудно поместить в классы-сущности или граничные классы Типичные роли управляющих классов: • Поведение, связанное с транзакциями • Управляющая последовательность переходов по маршрутам Use Case или управление «запуском» одного или нескольких Use Cases • Как сервис, отделяющий объекты-сущности от объектов-интерфейсов Выделение этих типов придает приложению большую приспособляемость к будущим изменениям требований, вызванным: Динамикой рынка, связанного с Пр. О Желаниями разных пользователей по разному видеть одно приложение Многие другие причины.

Фаза Elaboration: Классы Типы классов для Пр. О «Remak» Контроллер поддержки заказов Управляющий Класс Ввод заказов Заказ Поддержка заказов Клиент Поддержка запасов на складе Интерфейсные Классы Склад Классы-сущности

Фаза Elaboration: Классы Признаки отличия классов разных типов Классы-сущности: Типичные применения операций, определенных для объектов – сущностей: • Запись и чтение(извлечение) значений атрибутов сущности • Создание и удаление сущности • Обеспечение поведения, которое можно изменить по мере изменения сущности с течением времени Потенциальные классы-сущности для Пр. О «Remak» Адрес Счет Сумма заказа Доставка Комплектующие Клиент Заголовок заказа Проплата Гитара Заказ Строка заказа Товар Ноты

Фаза Elaboration: Классы Признаки отличия классов разных типов (продолжение) Интерфейсные Классы: Отличаются большей изменчивостью, чем классы-сущности, из-за внешних влиян. Со временем могут меняться: • Способы размещения заказов (по телефону, через Интернет) • Способы интерфейса с другими системами • Желания акторов видеть ту или иную информацию в том или ином виде Для сокращения затрат на модификации нужно помещать все поведение, связанное с интерфейсами в Интерфейсные Классы Потенциальные интерфейсные классы для Пр. О «Remak» Поддержка панели Заказа Запрос панели заказа Обработка панели заказа Поддержка панели отношений с клиентами Интерфейс с кредитной картой Интерфейс системы бух. учета

Фаза Elaboration: Классы Признаки отличия классов разных типов (продолжение) Управляющие Классы: Управляющие классы связывают вместе потоки событий и, таким образом, выполняют коммуникационную роль между разными объектами Пр. О Они обычно временные (transient) и не хранятся в долговременной памяти. Их жизненный цикл заканчивается как только заканчивается взаимодействие. Для каждого Use Case создается контрольный класс, в котором определен (в коде класса) порядок обмена сообщениями между объектами в процессе реализации маршрутов Use Case (основного, альтернативных, исключительных). Потенциальные управляющие классы для Пр. О «Remak» Контроллер процесса Обработки заказа Контроллер инфраструктуры Контроллер поддержки заказа Контроллер поддержки отношений с клиентами

Структурные схемы экранов На этапе создания прототипа детализация UI должна ограничиваться определением ГЛАВНЫХ групп окон и ОБЩИМ ВИДОМ UI, оставляя определение цветовых гамм, размеров элементов и шрифта и т. п. «на потом» . Действительно, по результатам специальных исследований удобство использования ИС: на 60% зависит от использованой UI «ментальной модели» пользователя на 30% зависит от интерактивных характеристик UI (скорость отклика. . ) на 10% зависит от презентационных характеристик UI (цвета, размеров. . ) Основные типы оконных операций в UI и их обозначение Amodal (или modeless) окно Не требует ответа пользователя. (Например, окно Word или Excel) Modal окно Требует ответа пользователя. (Например, окно сохранения файла в Word) Задание направления навигации по окнам (Двойная стрелка показывает, что из одного окна может открыться другое с возвратом назад

Структурные схемы экранов Пример схемы оконной навигации Окно А Окно С Окно В

Структурные схемы экранов Пример схемы оконной навигации Окно А Окно В Окно С Пример схемы Tabbed навигации (переходы по клавише Tab) Окно А Tab В Tab С Tab D

Структурная схема экранов ИС “Remak” Каркас для ввода З-в Сопр. С. Поиск товара Сопр. З. Дост-ка Вып. СФ Подд. К Под. ПР Обсл. З. Поиск Клиента Поиск Адреса