Wondershare EdrawMind
Галерея диаграмм связей Анализ информационных систем и проектирование интеллект-карт
- 2
Анализ информационных систем и проектирование интеллект-карт
Это интеллектуальная карта анализа и проектирования информационных систем, включая системный анализ и обзор проектирования, обзор системных требований, варианты использования, модель предметной области и т. д.
Отредактировано в 2023-11-14 10:01:51
Анализ информационных систем и проектирование интеллект-карт
- Рекомендовано вам
- Структура
Информационная система Система знаний менеджера проекта (Глава 12 «Управление закупками проекта»)
- 2
Информационная система Система знаний менеджера проекта (Глава 3 Управление содержанием проекта)
- 2
Информационная система Система знаний менеджера проекта (Глава 10 Управление коммуникациями проекта и управление заинтересованными сторонами)
- 2
Информационная система Система знаний менеджера проекта (Глава 9 «Управление человеческими ресурсами проекта»)
- 3
Анализ и проектирование информационных систем
chap01 Обзор системного анализа и проектирования
Введение
Это набор спецификаций-руководств, помогающих разрабатывать информационные системы.
1.1 Разработка программного обеспечения, системный анализ и проектирование
компьютерное приложение
Компьютерная программа, выполняющая определенный набор функций на вычислительном устройстве.
Средний диапазон применения
Также называется «приложением» (app)
Информационная система
Набор взаимосвязанных компонентов, которые собирают, обрабатывают, хранят и предоставляют информацию, необходимую для выполнения бизнес-задач.
Более широкая сфера применения, чем «приложение».
Включает программное обеспечение, базы данных и соответствующие ручные процессы.
Системный анализ
Те действия, которые позволяют людям понять и указать, чего должна достичь информационная система.
Системный дизайн
Те действия, которые позволяют определить и подробно описать систему, которая удовлетворяет требованиям.
Системный анализ эквивалентен составлению чертежа, тогда как проектирование системы представляет собой подробный план.
1.2 Жизненный цикл разработки системы
проект
Запланированная задача, имеющая начало и конец и приводящая к определенному результату.
для разработки информационных систем
Требуется знание инструментов и методов системного анализа и проектирования систем.
SDLC (system development lifecycle), то есть жизненный цикл разработки системы.
Жизненный цикл разработки систем определяет весь процесс, который включает в себя все действия, необходимые для создания, запуска и обслуживания информационных систем.
Все виды деятельности включают в себя: системный анализ, проектирование системы, программирование, тестирование, обслуживание системы.
шесть основных процессов
Определить проблемы или потребности и получить одобрение
Планируйте и контролируйте проекты
Откройте для себя и поймите детали проблемы или потребности
Проектируйте компоненты системы, которые решают проблему или удовлетворяют потребность.
Сборка, тестирование и интеграция компонентов системы
Завершите тестирование системы, а затем разверните решение.
процесс разработки информационной системы
Практический подход к разработке конкретной информационной системы (также известной как методологии) путем завершения тестирования системы и последующего развертывания решения.
Например
Единый процесс (UP)
Экстремальное программирование (XP)
Итеративный инкрементный процесс разработки программного обеспечения Scrum
Большинство процессов/методов теперь используют гибкую и итеративную разработку.
Гибкая разработкаГибкая разработка
Процесс разработки информационных систем, который подчеркивает гибкость в предвидении новых требований во время разработки.
Быстро стоит на ногах; быстро реагирует на изменения.
Ни пользователи, ни члены команды полностью не понимают проблемы и сложности новой системы, поэтому планирование и реализация проекта должны учитывать непредвиденные проблемы.
Итеративная разработкаИтеративная разработка
Подход к разработке систем, при котором система постепенно «растет» посредством множества итераций.
Завершите небольшую часть системы (мини-проект), затем повторите процесс для уточнения и добавления новых, затем повторите уточнение и добавляйте еще до завершения.
Преимущество
1. Части системы можно быстро развернуть
2. Сначала вынесите на разработку небольшую часть, чтобы как можно раньше обнаружить сложные проблемы в проекте.
Шесть основных процессов итерации проекта
Площадь круга представляет рабочую нагрузку соответствующей итерации в этом процессе.
Каждая итерация будет выполнять несколько процессов с разными фокусами.
1.5 Использование торговой системы RMO в качестве примера для ознакомления с процессом разработки
1.5.1 Подготовка
Определите проблему и задокументируйте цели системы (основной процесс 1).
Предварительное расследование
Перевести результаты в документ системного видения (SVD)
Получите одобрение на запуск проекта (основной процесс 1)
Встретьтесь с ключевыми заинтересованными сторонами, включая высшее руководство
Встретьтесь с ключевыми заинтересованными сторонами, включая высшее руководство, для принятия решений и утверждения планов и бюджетов.
СВД (документ системного видения)
Документ видения системы используется для определения функций, которые принесут пользу компании, и тех, которые будут включены в систему.
Сделайте это в два шага
Разработайте первоначальное заявление о преимуществах
Добавьте подробную смету доходов и затрат
Обычно состоит из трех частей
описание проблемы
Возможности системы
преимущества для бизнеса
1.5.2 Мероприятия в первый день
Основной процесс 2: Планирование проекта
Определите основные необходимые компоненты (функциональные области)
Разделите систему на подсистемы или компоненты.
Подсистема – это часть общей системы.
Определите итерации и назначьте каждую функциональную область итерациям.
Запланируйте одну итерацию
Определить задачи, необходимые для итерации
Идентифицированные задачи компилируются и организуются в список, называемый структурой декомпозиции работ (WBS).
Пример
Содержание WBS (структура перерывов в работе)
Базис декомпозиции (название)
Основа декомпозиции зависит от следующих четырех основных процессов:
необходимое время
Порядок выполнения
Измерение необходимого времени и последовательности выполнения может помочь при построении последующей рабочей сети и расчете критического пути (PERT).
Критический путь — это самый длинный путь во всей сети. Процессы, через которые он проходит, должны строго выполняться. Процессы на других путях обладают определенной степенью гибкости.
Организуйте и систематизируйте эти задачи по дате.
Преобразование WBS в расписание
Преимущество планирования отдельных итераций состоит в том, что график является неформальным и может быть скорректирован с учетом непредвиденных обстоятельств.
Разработать проект последовательности работ
Преимущества проекта наряда на работу
1. Помогите организовать командную работу.
2. Он позволяет оценить, идет ли итерация по плану.
3. Если проект займет некоторое время по этому графику, руководитель проекта увидит, что программирование может потребовать больше времени и ресурсов, и сможет заранее организовать ресурсы, чтобы помочь с этой частью проекта.
Определить необходимые ресурсы (людей) и организовать персонал для выполнения соответствующих задач.
Определите членов команды и обязанности
1.5.3 Мероприятия второго дня
Выполните предварительные задачи по установлению фактов, чтобы понять требования. (Основной процесс 3)
Глава 2 подробно объяснит
Разработайте предварительный список вариантов использования и диаграмму вариантов использования. (Основной процесс 3)
Вариант использования
Вариант использования записывает бизнес-событие, инициированное одним пользователем, и реакцию системы на это событие.
Вариант использования относится к примеру или ситуации использования системы.
Например: Агенты по закупкам «используют» эту систему для «опроса поставщиков».
Варианты использования обычно представляют собой глаголы, соответствующие требованиям/функциям.
Пример списка вариантов использования
Пример диаграммы вариантов использования
Разработайте предварительный список классов и диаграмму классов. (Основной процесс 3)
Класс объекта
Системы идентификации классов объектов должны понимать и отслеживать эти вещи в реальном мире.
Классы объектов должны сохранять информацию в системе.
Пример списка классов
Пример диаграммы классов
Это предварительная диаграмма классов, поэтому здесь есть только свойства (статические функции).
Диаграмма классов проекта будет иметь типы данных атрибутов, методы классов и т. д.
Приведенная выше диаграмма разработана с использованием унифицированного языка моделирования UML.
1.5.4 Мероприятия третьего дня
Проведите углубленное изучение фактов, чтобы узнать подробности. (Основной процесс 3)
Понимайте и документируйте подробный рабочий процесс для каждого варианта использования. (Основной процесс 3)
Разработка описаний вариантов использования и диаграмм рабочих процессов.
Вот два способа документирования деталей варианта использования.
Разработка диаграмм рабочих процессов требует использования диаграмм деятельности, которые представляют собой диаграммы в UML.
Пример диаграммы рабочего процесса
Овалы на рисунке представляют задачи, ромбы — точки принятия решений, стрелки — поток последовательности, а стрелки, пересекающие центральную линию, — взаимодействие между пользователем и системой.
Определите взаимодействие с пользователем с помощью экранов и отчетов. (Основной процесс 3 и 4)
Определить макет экрана
1.5.5 Мероприятия четвертого дня
Спроектируйте структуру базы данных (схему). (Основной процесс 4)
дизайн стола
Ключевые слова и идентификаторы индексов
Тип недвижимости
ссылочная целостность
Пример схемы базы данных
Спроектируйте высокоуровневую структуру системы. (Основной процесс 4)
Общий архитектурный проект
Определить диаграмму классов предварительного проектирования
Предварительный пример диаграммы классов проекта
Классы проектирования включают переменные уровня класса, необходимые классу, которые также показывают имена важных методов в каждом классе. Последними элементами диаграммы классов проекта являются стрелки, которые показывают, какие классы имеют доступ к методам каких других классов.
Проектирование архитектуры подсистемы
1.5.6 Мероприятия пятого дня
Продолжить детальное проектирование (CP4)
Выполнение программирования и индивидуального тестирования (CP5)
Проектирование и программирование — это не проектирование всего объекта, а затем программирование, а проектирование части, программирование, затем проектирование части и снова программирование.
1.5.7 Мероприятия шестого дня
Полное тестирование системы (CP6)
Общее функциональное тестирование системы
Приемочное тестирование пользователей
Возможное развертывание частичных систем (CP6)
1.5.8 Обзор первой итерации
1.6 Знакомство с последующим содержанием
1.6.1 Часть первая. Введение в разработку системы.
Глава Один
1.6.2 Часть 2. Действия по системному анализу
Главы 2, 3, 4 и 5
1.6.3 Часть 3. Деятельность по проектированию системы
Глава шестая и седьмая
1.6.4 Часть 4. Проекты и управление проектами
Глава 8 и 9
1.6.5 Часть 5. Расширенные концепции и концепции развертывания
Глава 10, 11, 12
chap02 Обзор системных требований
2.1 Введение
В этой главе мы начинаем расширять объем и детали процесса SDLC, чтобы охватить более широкий спектр концепций, инструментов и методов. Хотя эта глава посвящена деятельности по системному анализу (третий из перечисленных основных процессов), в следующих главах подробно обсуждаются модели, разработанные в ходе этой деятельности по системному анализу. Последующие главы расширяют обсуждение других основных процессов SDLC.
2.2CSMS (Комплексная система продаж и маркетинга) для RMO
2.2.1Существующая информационная система и архитектура РМО
Архитектура делится на два типа.
Технологическая архитектура Технологическая архитектура
Технологическая архитектура описывает набор вычислительного оборудования, сетевого оборудования и топологии, а также системного программного обеспечения, используемого организацией (например, операционных систем и систем управления базами данных).
архитектура приложения архитектура приложения
Архитектура приложения описывает, как организованы и структурированы ресурсы программного обеспечения для реализации информационных систем организации. Он описывает организацию программного обеспечения на модули и подсистемы, включая вспомогательные технологии (такие как языки программирования и среды разработки), архитектурные подходы (такие как сервис-ориентированная архитектура) и технологии пользовательского интерфейса (такие как дисплеи мобильных компьютеров, сенсорные экраны). технологии и распознавание речи).
2.1.2 Новая CSMS
Новая интегрированная система продаж и маркетинга будет состоять из четырех подсистем.
Подсистема продаж
Подсистема реализации заказов
Подсистема учета клиентов
Маркетинговая подсистема
2.3 Деятельность по системному анализу
Есть пять основных частей
2.3.1 Сбор подробной информации
Интервью, анкеты, документация, наблюдение за бизнес-процессами, изучение поставщиков, мнения и предложения
2.3.2 Определить требования
Моделирование функциональных и нефункциональных требований
2.3.3 Приоритизация требований
2.3.4 Разработка диалоговых окон пользовательского интерфейса
Процесс взаимодействия пользователей и системы
2.3.5 Оцените потребности пользователей
Вовлеченность пользователей, обратная связь, адаптация к изменениям
2.4 Что такое спрос
Системные требования — это все действия, которые новая система должна выполнять или поддерживать, а также ограничения, которым новая система должна удовлетворять.
Системные требования делятся на
функциональные требования
Функциональные требования — это действия, которые должна выполнять система (например, бизнес, для которого будет применяться система).
Требует от пользователя выполнения
нефункциональные требования
Нефункциональные требования — это характеристики, выходящие за рамки действий, которые система должна выполнять или поддерживать.
Такие как показатели эффективности, ограничения (инструменты разработки, форматы данных и т. д.)
Вы можете использовать FURPS, чтобы просто разделить требования
функциональная функциональность
доступность удобства использования
Надежность
Производительность
Безопасность
Другие, такие как ограничительные условия
нефункциональные требования
2.5 Модели и моделирование
Модель
Модель — это представление некоторого аспекта строящейся системы.
Тип модели
текстовая модель
отчеты, документы
графическая модель
Принципиальная схема
математическая модель
формула
язык моделирования
Разработка многих графических моделей реализуется посредством UML (Unопределённый язык моделирования).
UML — это набор стандартных конструкций моделей и символов, определенных Object Management Group, некоммерческой организацией.
2.6 Заинтересованные стороны
Заинтересованные стороны – это все те, кто заинтересован в успешном внедрении системы.
Классификация заинтересованных сторон
внутренние заинтересованные стороны
Внутренние заинтересованные стороны — это люди внутри организации, которые взаимодействуют с системой или имеют значительный интерес в ее работе или успехе.
внешние заинтересованные стороны
Внешние заинтересованные стороны – это те, кто находится вне контроля и влияния организации.
оперативные заинтересованные стороны
Заинтересованные стороны — это люди, которые часто взаимодействуют с системой в своей работе или жизни.
Например: бухгалтеры, взаимодействующие с системами бухгалтерского учета или выставления счетов, заводские рабочие, взаимодействующие с системами планирования производства, клиенты, взаимодействующие с интернет-витринами, и пациенты, взаимодействующие с веб-сайтами здравоохранения, страницами Facebook или новостными лентами Twitter.
Управляйте заинтересованными сторонами
Заинтересованные стороны управления — это те, кто не взаимодействует напрямую с системой, но использует информацию, предоставляемую системой, или имеет значительную финансовую или иную заинтересованность в ее работе и успехе.
Например: высшее руководство и совет директоров организации, регулирующие и налоговые органы.
Два типа важных заинтересованных сторон
Клиент: лицо, оказывающее финансовую поддержку
Персонал технической поддержки системы
2.7 Технология сбора информации
Технологии сбора информации включают в себя
2.7.1 Проведение интервью с пользователями и другими заинтересованными сторонами
Требуются системные аналитики
Подготовьте подробные вопросы
предмет вопроса
Каким должен быть бизнес-процесс?
Как работают бизнес-процессы
Какая информация необходима
Тип вопроса
открытые вопросы
закрытые вопросы
Объект вопроса: старая система или новая система
Познакомьтесь с отдельными пользователями или группами пользователей
Получайте и обсуждайте ответы на вопросы
записать ответ
Следите за информацией, чтобы использовать ее в будущих интервью.
2.7.2 Распространение и сбор анкет
Три типа вопросов
закрытые вопросы
Посмотрите на проблемы с форматом
открытые вопросы
2.7.3 Проверка ввода, вывода и процесса
Есть два источника входных данных, выходных данных и процессов.
Деловые записи и описания процессов внутри организации
Со стороны организации – профессиональные организации и другие компании отрасли.
Проверьте существующую документацию по обработке
2.7.4 Наблюдение и запись бизнес-процессов
Это поможет вам понять функцию бизнеса.
2.7.5 Исследования решений поставщиков
Три преимущества и одна опасность
1. Изучение этих решений может помочь пользователям лучше подумать о том, как лучше выполнять бизнес-функции.
2. Некоторые решения уже являются первоклассными, и без проведения исследований сложно уследить за трендом.
3. Покупка решения менее рискованна и дешевле, чем его исследование.
Опасность: спешить с покупкой решения, не изучив всех потребностей системы.
2.7.6 Сбор активных комментариев пользователей
2.8 Используйте диаграмму действий для записи рабочего процесса
Рабочий процесс
Рабочий процесс — это серия этапов обработки, которые полностью обрабатывают бизнес-операцию или запрос клиента.
диаграмма деятельности
Диаграмма действий описывает различные действия пользователя (или системы), людей, выполняющих каждое действие, и последовательный поток этих действий.
Символы и пояснения
Эллипсы обозначают различные действия в рабочем процессе. Соединительные стрелки указывают последовательность действий. Черные круги обозначают начало и конец рабочего процесса. Ромб — это точка принятия решения, в которой процесс пойдет по тому или иному пути. Толстая сплошная линия — это полоса синхронизации, с помощью которой можно разделить путь на несколько параллельных путей или повторно объединить параллельные пути. Название дорожки для плавания представляет агента, выполняющего данное действие. Поскольку в рабочем процессе обычно участвуют разные агенты (то есть люди), выполняющие разные этапы рабочего процесса, символы плавательной дорожки делят действия рабочего процесса на группы, показывая, какой агент выполняет какое действие.
пример использования главы 03
3.1 Введение
Как и главы 4 и 5, эта глава знакомит с методами документирования функциональных требований путем создания различных моделей.
Вариант использования — это действие, которое выполняет система, обычно в ответ на запрос пользователя.
Варианты использования определяют функциональные требования
Аналитики декомпозируют систему на набор вариантов использования (функциональная декомпозиция).
Варианты использования обычно называются в честь глаголов или герундий.
3.2 Варианты использования и цели пользователей
Одним из методов определения вариантов использования является метод целей пользователя, который просит пользователей описать свои цели использования новой или обновленной системы.
Разделена на восемь шагов
Определить всех потенциальных пользователей новой системы.
Классифицировать потенциальных пользователей на основе функциональных ролей (например, транспорт, маркетинг, продажи).
Дальнейшая категоризация потенциальных пользователей по организационным уровням (например, операционные, управленческие, исполнительные).
Для каждого типа пользователей посетите их и найдите список конкретных целей, которые они будут преследовать при использовании новой системы (текущие цели и инновационные функции, которые повышают ценность).
Создайте предварительный список вариантов использования, упорядоченный по типам пользователей.
Найдите копии со схожими названиями вариантов использования и устраните несоответствия.
Определите, где разные типы пользователей требуют одних и тех же вариантов использования.
Просмотрите заполненный список вместе с каждым типом пользователей и заинтересованными сторонами.
Обычно рассматриваются только события с функциональными требованиями.
Методы таргетинга на пользователей просты, но широко используются.
3.3 Варианты использования и декомпозиция событий
Технология декомпозиции событий — наиболее полная технология выявления вариантов использования.
Метод декомпозиции событий сначала определяет все бизнес-события, которые заставят информационную систему реагировать, и каждое событие приведет к варианту использования. Начало с бизнес-мероприятий помогает аналитикам определить каждый вариант использования на нужном уровне детализации.
Для определения соответствующего уровня детализации варианта использования используется основной бизнес-процесс (EBP).
EBP — это задача, выполняемая одним человеком в одном месте, чтобы реагировать на бизнес-события, повышать измеримую ценность бизнеса и приводить систему и ее данные в стабильное и согласованное состояние.
Каждый EBP реагирует на бизнес-событие, когда оно происходит.
3.3.1 Технология декомпозиции событий
событие
События происходят в определенное время и в определенном месте, могут быть описаны и должны запоминаться системой.
3.3.2 Типы событий
внешние события
Внешние события — это события, которые происходят вне системы и обычно инициируются внешними агентами или субъектами.
Внешние агенты (или субъекты) — это отдельные лица или организационные подразделения, которые предоставляют или получают данные в систему.
Например
Различные бизнес-процессы, такие как размещение заказов пользователем и т. д.
Внешние события обычно используются для ответа на запросы пользователя (субъекта) и происходят в средах взаимодействия человека и компьютера.
Приуроченное событие/временное время
Событие, происходящее в результате достижения определенного момента времени.
Например
Регулярно отправлять статистические отчеты и т.д.
В системе происходят временные события
статусное событие
События состояния возникают, когда в системе происходит событие, вызывающее требование обработки.
Вызывается при изменении статуса
Как правило, это нефункциональные требования, и они не часто учитываются.
3.3.3 Определение событий
Событие/предварительное условие/ответ
Аналитики должны рассмотреть последовательность событий, а затем определить события, которые действительно влияют на систему.
цепочка событий
Полезно отслеживать серию событий, произошедших с конкретным внешним объектом или действующим лицом.
События зависимости от технологии и контроль системы
Иногда аналитиков интересуют события, важные для системы, но не связанные напрямую с пользователями или транзакциями. Эти события обычно связаны с выбором проекта или управлением системой. Аналитики должны временно игнорировать эти события во время анализа.
Системные меры контроля — это проверки или процедуры безопасности, предназначенные для защиты целостности системы.
Резервное копирование данных, вход в систему и т. д.
На этапе анализа мы будем использовать идеальные технические предположения.
Гипотеза идеальной технологии утверждает, что события происходят только тогда, когда система должна реагировать в идеальных условиях (например, устройство никогда не выходит из строя, мощность обработки и хранения данных неограничена, а люди, управляющие системой, абсолютно честны и никогда не допускают ошибок). включены в процесс анализа.
3.3.4 Использование технологии декомпозиции событий
1. Учитывать внешние события в системной среде, требующие реакции системы.
2. Для каждого внешнего события определите и назовите вариант использования, требуемый системой.
3. Используйте контрольный список для рассмотрения временных событий, требующих реакции системы.
4. Для каждого временного события определите и назовите варианты использования, необходимые системе, а затем установите момент времени, который запускает вариант использования.
5. Рассмотрите события состояния, на которые может реагировать система, особенно если это система реального времени, где изменения устройства или внутреннего состояния запускают варианты использования.
6. Для каждого события состояния определите и назовите вариант использования, требуемый системой, а затем определите изменение статуса.
7. После определения событий и вариантов использования проверьте, требуют ли они идеальных технических предположений. Не включайте события, включающие элементы управления системой, такие как вход в систему, выход из системы, смена пароля, а также резервное копирование или восстановление базы данных, поскольку они размещаются как элементы управления системой.
3.4 Варианты использования и CRUD
Еще одной важной технологией проверки и уточнения вариантов использования является технология CRUD.
CRUD означает
Создавать
Читай, читай
Обновление, обновление
Удалить, удалить
Это операции, связанные с управлением базой данных.
Методы CRUD наиболее полезны при использовании вместе с методами таргетинга пользователей в качестве перекрестной проверки. Вместо того, чтобы использовать его непосредственно в качестве метода определения вариантов использования, это может привести к тому, что варианты использования не будут очень хорошо отслеживать бизнес-процесс.
Можно проверить, отсутствуют ли пропущенные типы вариантов использования.
Этапы технологии CRUD
1. Определите все объекты данных или классы предметной области, участвующие в новой системе.
2. Для каждого типа данных (объекта данных или класса предметной области) убедитесь, что вы определили варианты использования для создания новых экземпляров, обновления существующих экземпляров, чтения или составления отчетов о значениях экземпляров, а также удаления (архивирования) экземпляров.
3. Если требуемый вариант использования игнорируется, добавьте новый вариант использования и определите заинтересованные стороны.
4. Для интегрированных приложений убедитесь, что ясно, какое приложение отвечает за добавление и обслуживание данных, а какая система только использует эти данные.
3.6 Диаграмма вариантов использования
Диаграммы вариантов использования — это модели UML, используемые для графического отображения вариантов использования и их связи с пользователями.
3.6.1 Варианты использования, действующие лица и символы
В большинстве случаев использования неявно подразумеваются люди, использующие систему, которых мы до сих пор называли пользователями. В UML этот человек называется актером. Актеры часто находятся за пределами автоматизации.
На диаграмме вариантов использования символ человека представляет актера, овал представляет вариант использования, прямоугольная граница представляет границу автоматизации, а связь между вариантом использования и актером показывает, какой актер в каком варианте использования участвует.
Пример
Существуют отношения не только между вариантами использования и субъектами, но также могут существовать отношения между вариантами использования.
Это зависимость между вариантами использования, которая проявляется в двух формах. Используйте пунктирные стрелки и << >>, чтобы указать
<<включить>>
Его можно понимать как отношение использования, которое относится к использованию одного варианта использования в другом варианте использования. Вариант использования, указанный стрелкой, является использованным вариантом использования (зависимым). Эти отношения требуют, чтобы один вариант использования использовался в другом варианте использования.
<<расширенный>>
Эти отношения указывают на то, что один вариант использования может использовать другой вариант использования. В этих отношениях будет нечто, называемое точкой расширения. Например, в системе управления библиотекой вариант использования возврата книг может включать в себя штрафы (тайм-ауты и т. д.). Это расширенные отношения.
Связь между ними заключается в том, что они оба являются отношениями между вариантами использования, и оба означают использование другого варианта использования в одном варианте использования. Разница между ними заключается в том, что «включение» означает, что обязательно будет использоваться другой UC, тогда как «расширение» требует оценки расширения; пункт, прежде чем решить использовать или нет
модель домена chap04
4.1 Введение
Основные понятия: Вещи в проблемной области системного пользователя.
4.2 Вещи в проблемной области
Проблемная область относится к конкретной области бизнеса пользователей, включенной в новую систему.
Классы или сущности предметной области — это то, с чем конечным пользователям приходится работать в студии. В предметной области системных проблем их часто называют «вещами».
Например
продукция, заказы, клиенты
4.2.1 Метод 1 для определения вещей в проблемной области – метод мозгового штурма
1. Определите пользователя и набор вариантов использования.
2. Проведите мозговой штурм с пользователями, чтобы определить, что задействовано в выполнении варианта использования, т. е. то, о чем система должна собирать информацию.
3. Используйте типы вещей (категории), чтобы систематически задавать вопросы о потенциальных вещах, например: Храните ли вы информацию о каких-либо материальных вещах? Есть ли какие-либо места? Чьи роли вам нужно запомнить?
4. Продолжайте работать с различными пользователями и заинтересованными сторонами, чтобы расширить список для мозгового штурма.
5. Объедините результаты, исключите дубликаты и составьте первоначальный список.
4.2.2 Способ 2 определения вещей в проблемной области – технология существительных
Перечислите все существительные, упомянутые пользователями. Существительные, используемые для описания событий, вариантов использования или действующих лиц, являются потенциальными вещами.
шаг
1. Определите все существительные, используя варианты использования, действующих лиц и другую информацию о системе (включая входные и выходные данные).
2. Используя существующие системы, текущие процедуры и другую информацию из текущих отчетов или форм, добавьте элементы или категории необходимой информации. Некоторые из этих элементов могут быть дополнительными вещами, а некоторые могут представлять собой более конкретную информацию (называемую атрибутами) о вещах, которые вы уже идентифицировали. Уточните список, а затем запишите гипотезы или вопросы, которые вы хотите изучить.
3. По мере построения этого списка существительных вам потребуется его уточнять.
Задайте следующие вопросы для каждого существительного, чтобы решить, следует ли его включать:
Это что-то уникальное, что система должна знать?
Это входит в рамки системы, которую я разрабатываю?
Необходимо ли системе запоминать более одного из вышеперечисленных элементов?
Задайте следующие вопросы о каждом существительном, чтобы решить, следует ли его исключить:
Действительно ли это синоним чего-то еще, что я определил?
Действительно ли это просто вывод системы, основанный на другой информации, которую я определил?
Действительно ли это просто ввод данных, который приводит к записи другой информации, которую я идентифицировал?
Задайте следующие вопросы о каждом существительном, чтобы решить, следует ли его изучать:
Возможно ли, что это конкретная информация (имущество) о других вещах, которые я выявил?
Если предположения изменятся, может ли мне это понадобиться?
4. Создайте общий список всех идентифицированных существительных, а затем укажите, следует ли каждое существительное включить, исключить или изучить дальше.
5. Просмотрите список вместе с пользователями, заинтересованными сторонами и членами команды, затем уточните список вещей в проблемной области.
Пример
4.2.3 Свойства вещей
Большинство систем хранят определенную информацию о транзакциях, называемую атрибутами.
Атрибут, который однозначно идентифицирует что-либо, называется идентификатором или ключевым словом (ключ/код).
Составные атрибуты состоят из нескольких связанных атрибутов, таких как адрес, полное имя и т. д.
4.2.4 Отношения между вещами
Ассоциация относится к естественным отношениям между определенными вещами.
В UML существует примерно четыре типа отношений между вещами.
ассоциация
обобщение поколений
зависимостьзависимость
осуществлять
связанные детали
имеет имя
Есть направление, и предмет, на который указывает стрелка, не может видеть другой (то есть другой зависит от предмета, на который указывает стрелка, и указанный предмет меняется на другой, но наоборот не имеет никакого эффекта)
Например, A->B называется A, зависящим от B.
Ассоциация – это множественность, то есть количественная связь между одной вещью и другой вещью.
пример
Между ассоциациями существуют ограничения по количеству элементов.
связанный элемент
Ассоциация состоит из нескольких разных типов вещей, и количество этих вещей есть арность ассоциации.
Клиент и заказ, бинарные отношения
Ассоциация между похожими вещами, один элемент
Три или более различных типа вещей связаны между собой, множественные
4.3 Диаграмма «сущность-контакт»
Это модель для моделирования базы данных
Прямоугольники представляют объекты, а линии, соединяющие прямоугольники, представляют связи между объектами.
символическое представление
Только вертикальные линии обрезаны, чтобы показать, что существует только один
Вертикальные линии обрезаны и обведены, обозначая 0 или 1.
Круг с перечеркнутой линией указывает на 0 или более
Вертикальные линии обрезаны, а раздвоенные линии обозначают одну или несколько
Направление, соответствующее числу, — от беззнакового к знаковому.
В атрибутах сущности в первой строке ставится первичный код (идентификатор) и отмечается ПК, обозначающий, что это первичный код.
Пример
Один клиент соответствует 0 нескольким заказам, один заказ соответствует одному и только одному клиенту;
4.4 Диаграмма классов модели предметной области
Класс вещей, о котором идет речь, называется классом предметной области.
В UML диаграмма классов используется для отображения классов объектов системы.
Диаграмма классов модели предметной области
Используется для отображения вещей в проблемной области пользователя.
Диаграмма классов проектирования
для дизайна
символическое представление
На диаграмме классов прямоугольники представляют классы, а прямые линии, соединяющие прямоугольники, представляют отношения между классами.
Прямоугольник состоит из двух частей (диаграмма классов модели предметной области, диаграмма классов дизайна состоит из трех частей: имя класса, атрибуты, методы), верхняя часть — имя класса, нижняя — атрибуты класса.
В именах классов и атрибутов используется верблюжий регистр. Первая буква имени класса пишется заглавной, а первая буква имени атрибута — строчной.
4.4.1 Обозначение диаграммы классов модели предметной области
символ множественности
Представляет количество связей между экземплярами классов, аналогично множеству диаграмм отношений сущностей.
Пример
Множественность здесь аналогична мощности отображения диаграммы отношений сущностей.
Применение диаграммы классов конкретной предметной области
Это диаграмма классов модели предметной области для выбора курса учащимися. Курс может иметь от 0 до нескольких разделов, но раздел может принадлежать только одному курсу и должен принадлежать только одному курсу, и разделы имеют отношение «многие ко многим», и оба могут быть; ноль Между студентами и курсами существует ассоциированный класс, отмеченный пунктирной линией, с атрибутом оценки;
4.4.2 Более сложные вопросы, касающиеся классов объектов
В предметных классах существует три типа отношений.
ассоциация
Генерация обобщения/специализации
В основе отношений обобщения/специализации лежит то, что люди классифицируют вещи на основе сходств и различий.
Отношения обобщения/специализации используются для структурирования или упорядочения этих вещей от более общего к более конкретному.
Над каждым классом в иерархии может стоять более общий класс, называемый суперклассом.
Класс может иметь более специализированный класс под ним, называемый подклассом.
Наследование позволяет подклассам использовать характеристики своего суперкласса.
Используйте треугольную стрелку, чтобы указать на суперкласс.
Пример
Используйте курсив для обозначения абстрактных классов.
Абстрактные классы не могут быть созданы и могут быть только унаследованы.
Существует также конкретный класс, который может иметь объекты-экземпляры.
Суперклассы иногда бывают конкретными или абстрактными.
Целая часть
Отношение глобальный/частичный используется для выражения связи между классом и другими классами, содержащимися в этом классе.
полимеризация
В отношениях агрегации компоненты могут существовать независимо.
Используйте полые ромбы, чтобы представить
комбинация
В комбинированных отношениях каждая часть не может существовать независимо, если она связана.
Используйте сплошной ромб, чтобы представить
Глава05 Расширение модели требований
5.2 Описание варианта использования
Описания вариантов использования описывают детали каждого варианта использования.
Простое описание варианта использования
Подходит для одиночных сценариев и меньшего количества исключений.
Пример
Полностью разработанное описание варианта использования
Для некоторых более сложных вариантов использования требуется полностью расширенное описание варианта использования.
Стандартный шаблон
Название варианта использования
Сценарии использования
триггерное событие
Краткое описание
участники
Другие варианты использования, связанные с ним, и то, как они связаны
Заинтересованные стороны
Предварительные условия
Предварительные условия определяют состояние системы в момент начала варианта использования, включая объекты, которые уже должны существовать, информацию, которая должна быть доступна, и даже условия для действующих лиц до начала варианта использования.
Последующие условия
Постусловия определяют, что должно быть истинным, когда вариант использования завершен. Самое главное, они указывают, какие новые объекты создает или обновляет вариант использования и как эти объекты должны быть связаны.
поток активности
Поток активности, включая участников (пользователей) и систему
ненормальная ситуация
Поток действий для каждого варианта использования может сильно различаться в зависимости от субъекта, вызывающего вариант использования. Различные потоки действий называются сценариями, также известными как экземпляры вариантов использования;
5.3 Диаграмма действий вариантов использования
Один из способов записи вариантов использования — использование диаграмм действий. В главе 2 мы научились использовать диаграммы действий для построения рабочих процессов. Здесь мы будем использовать диаграммы действий для записи потока действий вариантов использования.
Пример
На этой диаграмме действий показан поток действий при регистрации вариантов использования регистрации клиентов.
5.4 Схема последовательности операций в системе SSD
Диаграмма последовательности системы используется для описания потока информации в систему автоматизации и из нее.
Используйте человеческие символы для обозначения участников вариантов использования и прямоугольные границы для обозначения границ автоматизации.
Прямоугольником отмечено: система (с двоеточием), обозначающая автоматизированную систему.
Под участниками и системой находится пунктирная линия, называемая линией жизни, которая представляет жизненный цикл участников и системы, а время течет сверху вниз.
Происходит отправка и получение сообщений между участниками и линией жизни системы.
Отправка сообщений представлена сплошной линией, с направлением от участника к системе.
Полученные сообщения представлены пунктирными линиями с направлением от системы к участнику.
Полное символическое представление сообщения
(*)[Условие True/False] Возвращаемое значение:=Имя сообщения (список параметров)
* указывает на цикл
[] представляет истинные и ложные условия. Если внутри истинно, сообщение будет отправлено, в противном случае оно не будет отправлено.
Имя сообщения представляет собой описание отправленного сообщения.
Список параметров — это информация, которая должна быть передана.
Кроме того, существует несколько альтернативных фреймворков.
изменение цикла
Если несколько сообщений отправляются и принимаются в цикле, возможно, лучше использовать альтернативную структуру.
Альтернативный фрейм — использовать прямоугольную рамку для выбора части, которую нужно зациклить, и экспресс-цикл для всех элементов в верхнем левом углу.
выберите изменить
Альтернативная рамка выбора используется вместе с else. Используйте прямоугольную рамку для выбора области выбора. Используйте пунктирные линии, чтобы различать сообщения, отправленные при разных обстоятельствах, и помечайте их соответствующим образом в последней части отправленного сообщения.
5.4.2 Разработка твердотельного накопителя
1. Подтвердите введенное сообщение.
2. Используйте символы сообщений для описания информации, передаваемой в систему извне.
3. Добавьте определенные условия во входное сообщение, включая циклы и условия true/false.
4. Подтвердите и добавьте ответное сообщение.
5.5 диаграмма конечного автомата: Диаграмма конечного автомата.
Состояние объекта — это состояние, возникающее в течение его жизни при выполнении определенных условий, выполнении определенных действий или ожидании какого-либо события.
Переход состояний — это деятельность объекта, переходящего из одного состояния в другое.
функция перехода состояний
Имя преобразования (параметр,...) [условие принятия решения]/описание поведения
Выражение действия представляет собой некоторый процесс, который должен произойти, прежде чем переход будет завершен и объект достигнет целевого состояния.
Условие — это квалификатор или проверка перехода. Это просто условие «истина/ложь», которое должно быть выполнено, прежде чем переход может быть запущен.
5.5.1 Составное состояние и параллельное состояние
Нахождение в нескольких состояниях одновременно называется параллелизмом или параллельными состояниями.
Представленный с помощью параллельных путей, подобных диаграммам деятельности, путь представляет собой упорядоченный набор взаимосвязанных переходов состояний.
Состояния гнезда внутри других состояний более высокого уровня. Эти состояния более высокого уровня называются составными состояниями.
Составные состояния представлены состояниями высокого уровня, вложенными в состояния низкого уровня.
Пример
Когда принтер включен (составное состояние), он имеет два параллельных пути, а именно часть лотка для бумаги и часть печати. Эти две части независимы; при нажатии кнопки включения он включается, а при нажатии кнопки выключения. нажал, он выключается. Ограничений нет.
5.5.2 Правила разработки диаграмм конечных автоматов
Просмотрите диаграмму классов и выберите классы, которым может потребоваться состояние.
Для каждого выбранного класса в группе перечислите все условия статуса, которые вы можете определить.
Начинает построение фрагмента диаграммы конечного автомата с определения переходов, которые заставляют объект покидать идентифицированное состояние.
Расположите эти комбинации переходов состояний в правильном порядке.
Проверьте эти пути и найдите независимые параллельные пути.
Найти другие конверсии
Расширьте каждый переход соответствующими событиями сообщений, защитными условиями и выражениями действий.
Проверьте и протестируйте каждую диаграмму конечного автомата.
5.6 Интеграция моделей спроса
Взаимосвязь между различными моделями спроса
диаграмма вариантов использования
Описание варианта использования
диаграмма деятельности
SSD
Диаграмма классов модели предметной области
Схема конечного автомата
Взаимосвязь описывается следующим рисунком
Стрелка указывает в направлении от зависимого элемента к зависимому элементу.
Сплошные линии представляют первичные зависимости, пунктирные линии — вторичные зависимости, а некоторые стрелки являются двунаправленными, что указывает на взаимное влияние.
глава06 Основные моменты проектирования и проектной деятельности
6.1 Введение
На этапе анализа мы в основном обсуждаем, что делает система (например, требования), а на этапе проектирования мы в основном обсуждаем, как система достигает этих требований;
Входные и выходные данные проектирования системы не являются входными и выходными данными системы: входные данные проектирования системы являются результатом системного анализа, то есть требований и связанных с ними моделей, тогда как выходные данные проектирования системы представляют собой более детальное решение.
6.2 Элементы дизайна
6.2.1 Что такое проектирование системы?
Проектирование системы — это связующий процесс между системным анализом и реализацией с целью определения, организации и построения компонентов окончательного решения в качестве образца для построения.
6.2.2 Основные компоненты и уровни проектирования
Основные компоненты
экологический дизайн
Описывает сети, оборудование и т. д., которые соединяют систему вместе.
дизайн приложения
Компьютерная программа
Дизайн пользовательского интерфейса
Определенные экраны, отчеты и элементы управления для ввода и вывода.
Проектирование базы данных
Структура базы данных
Проектирование системного интерфейса
Описывает связь с другими системами.
Проектирование безопасности и контроля
два уровня
Архитектурный дизайн
Уточнить всю структуру и форму решения, которое представляет собой общий проект общей структуры системы.
Также называется общим дизайном или концептуальным дизайном.
детальный дизайн
Включает конкретные детали программирования
Пример
Проектирование для каждого варианта использования
Проектирование базы данных
Дизайн пользовательского интерфейса и системного интерфейса
Проектирование безопасности и контроля
6.3 Входные и выходные данные проектирования системы
Преобразование информации, такой как модели анализа и документы, полученные в результате системного анализа, в модель, представляющую систему решения.
Аналитическая модель
Диаграмма классов
Диаграмма вариантов использования UCD
Схема последовательности операций в системе SSD
Описание варианта использования
Схема конечного автомата
диаграмма деятельности
модель дизайна
Карта пакета
Граф узлов и местоположений
Диаграмма классов проектирования
Блок-схема
Схема базы данных
Пользовательский и системный интерфейс
Контроль безопасности системы
Схема сотрудничества
6.4 Проектная деятельность
Деятельность по проектированию представляет собой разработку шести вышеупомянутых компонентов. Каждая деятельность по проектированию имеет соответствующие ключевые проблемы.
экологический дизайн
Подробно ли мы описали среду, в которой будет выполняться программное обеспечение, и все возможные варианты?
Архитектура приложения и дизайн программного обеспечения
Подробно ли мы описали все элементы программного обеспечения и то, как выполняется каждый вариант использования?
дизайн пользовательского интерфейса
Подробно ли мы описали, как эта система будет взаимодействовать со всеми другими системами внутри и за пределами организации?
Дизайн интерфейса системы
Подробно ли мы описали, как пользователи будут взаимодействовать с системой для выполнения всех своих задач [варианты использования]?
Проектирование базы данных
Уточнили ли мы все требования к хранению информации, включая все элементы схемы?
Проектирование безопасности и контроля
Подробно ли мы описали все элементы, необходимые для обеспечения безопасности и защиты систем и данных?
6.4.1 Среда проектирования
Среда — это все технологии, необходимые для поддержки программного приложения.
Сервер, настольный компьютер
мобильные устройства, операционные системы
Коммуникационные способности, возможности ввода и вывода
В главе 2 мы назвали это технической архитектурой.
6.4.2 Проектирование архитектуры приложения и программного обеспечения
Разделите систему на подсистемы
Определить архитектуру программного обеспечения (архитектурный проект)
Трехуровневая архитектура MVC и т. д.
Детальное проектирование каждого варианта использования
Диаграмма классов проектирования
Блок-схема
Схема конечного автомата
6.4.3 Разработка пользовательского интерфейса
Проектирование диалогов начинается с требований
Дизайн добавляет макет экрана, внешний вид, навигацию, пользовательский опыт.
Проектируйте разные интерфейсы для разных устройств
6.4.4 Интерфейс системы проектирования
Информационные системы взаимодействуют со многими другими внутренними и внешними системами.
Системные интерфейсы подключаются к другим системам разными способами.
6.4.5 База данных проекта
Начните с диаграммы классов модели предметной области (или ERD).
Выберите структуру базы данных
Проектирование архитектуры (распределенной и т. д.)
Проектирование схемы базы данных
Таблица, столбец атрибутов
Ограничения целостности ссылок проекта
6.4.6 Проектирование безопасности и системного контроля
Целью является защита активов организации, имеющих решающее значение в Интернете и беспроводном мире.
Элементы управления пользовательским интерфейсом
контроль приложений
Управление базой данных
управление сетью
6.5 Как спроектировать среду
Проектирование локально
Существует два типа локальных программных систем.
Автономная программная система
Запуск с устройства без сети
Внутренняя веб-система
Развертывание оборудования: LAN
клиент-серверная архитектура
Система настольных приложений (клиент-сервер)
Браузерная прикладная система (браузер-сервер)
Использовать язык разметки гипертекста в качестве страницы
Использовать протокол TCP/IP в качестве транспортного протокола.
Трехуровневая архитектура клиент/сервер.
Эффективный способ проектирования программного обеспечения — разделить уровни пользовательского интерфейса и бизнес-логики, а также уровень бизнес-логики и уровень доступа к данным. Этот метод проектирования программ называется трехуровневой архитектурой. Основная идея состоит в том, чтобы разделить программное обеспечение на три уровня.
Уровень просмотра: отвечает за получение пользовательского ввода и его обработку в форматированный вывод.
Логический уровень/уровень предметной области. Уровень предметной области: отвечает за правила и процедуры, реализующие бизнес-процессы или процессы обработки.
Уровень данных: отвечает за управление сохраненными данными, которые обычно существуют в одной или нескольких базах данных.
Несколько уровней могут работать на одном компьютере, или каждый уровень может управляться отдельным компьютером. Сложные уровни можно развернуть на двух или трех, разделив функциональность уровня или реализовав балансировку нагрузки на резервных компьютерах.
Еще одна идея дизайна — MVC, то есть Модель-Представление-Контроллер.
Проектирование внешнего развертывания
Важные вопросы включают
Конфигурация для развертывания в Интернете
Защита данных осуществляется с помощью протокола передачи гипертекста (HTTPS). Веб-страницы, обслуживаемые протоколом HTTPS, передаются в зашифрованном виде, что более безопасно, чем HTTP.
Используйте многоуровневые серверные структуры и сети балансировки нагрузки и доставки контента (CDN) для повышения производительности.
Многоуровневая серверная структура включает сервер приложений и сервер базы данных.
Запросы отправляются на разные серверы центров обработки данных через компьютеры балансировки нагрузки.
При доступе к некоторым статическим изображениям или видео вы можете использовать независимый CDN для их отправки.
Варианты хостинга для развертывания в Интернете
аренда площадки
Предоставьте клиентам безопасный центр обработки данных для размещения серверных компьютеров. Преимущество заключается в отсутствии затрат на физический, безопасный и сложный центр обработки данных.
Управляемые службы
Предоставляет дополнительные услуги, включая управление операционными системами, сетевыми серверами, серверами баз данных и т. д. Преимущество заключается в том, что нет необходимости нанимать сотрудников для управления серверными системами и системным программным обеспечением.
виртуальный сервер
Клиенты могут арендовать виртуальные серверы фиксированного размера.
облачные вычисления
Клиентам необходимо приобрести только ту вычислительную мощность, которая им нужна и которую они используют, а когда вычислительная мощность вырастет, облако автоматически предоставит больше мощности. Такая схема может сэкономить затраты, поскольку нет необходимости приобретать ненужную мощность;
Для всех альтернатив существует Соглашение об уровне обслуживания (Соглашение об уровне обслуживания), которое является частью контракта между предприятием и хостинговой компанией, гарантирующего определенный уровень доступности системы.
Разнообразие клиентских устройств, развернутых для Интернета
компьютер
Планшет среднего размера
небольшое мобильное устройство
Проектирование для удаленных и распределенных сред
Удаленное развертывание через виртуальную частную сеть (VPN)
VPN — это сеть, построенная на основе общедоступной сети, такой как Интернет. Он обеспечивает безопасную и подключаемую сеть для частных групп.
chap07 Проектирование пользовательского интерфейса и системного интерфейса
7.2 Пользовательский интерфейс и системный интерфейс
Пользовательский интерфейс содержит ввод и вывод, требующие непосредственного вмешательства пользователя.
Системный интерфейс требует минимального ручного ввода и вывода.
7.3 Понимание пользовательского интерфейса
Пользовательский интерфейс состоит из трех компонентов
Физический смысл: офисные столы и стулья, лампы, клавиатуры, мыши, сенсорные экраны.
Воспринимаемое значение: цвета, формы, текстуры, шрифты, окна, меню, кнопки.
Концептуальное значение: заказчик, участник, заказ, транспортировка, обратная связь.
Дизайн пользовательского интерфейса ориентирован на пользователя, подчеркивая взаимодействие между человеком и компьютером (взаимодействие человека и компьютера).
Взаимодействие человека с компьютером — это область, которая изучает эффективность и результативность взаимодействия пользователя с компьютерными системами, человеко-ориентированные методы ввода и вывода, а также психологические аспекты пользовательских интерфейсов.
Три основных принципа дизайна, ориентированного на пользователя
Сосредоточьтесь на пользователях и их работе как можно раньше.
Оцените систему, чтобы убедиться в ее удобстве использования.
Используйте итеративную разработку
Метафоры взаимодействия человека и компьютера
Метафоры — это аналогии между функциями пользовательского интерфейса и физическими объектами, знакомыми пользователям.
Метафоры широко используются в дизайне пользовательского интерфейса в следующих ситуациях:
прямая манипуляция
Манипулируйте физическими объектами непосредственно на дисплее или объектами, которые их представляют.
Пример: Пользователь перетаскивает папку в корзину.
метафора рабочего стола
Организуйте визуальное отображение по различным областям: большое пустое рабочее пространство посередине окружено набором значков инструментов.
Пример: рабочий стол Windows.
метафора документа
Отображение данных, таких как страница или таблица
Пример: документ с инструкциями для пользователя и т. д.
разговорная метафора
Пользователи и компьютеры выполняют задачи, участвуя в общении или диалоге с помощью текста, голоса или других инструментов.
Пример: окно cmd
Первые три подчеркивают объекты, которые взаимодействуют с пользователем, а разговорная метафора подчеркивает общение, происходящее между пользователем и компьютером.
7.4 Концепции дизайна пользовательского интерфейса
7.4.1 Оперативность и наглядность
Индикативный относится к внешнему виду элемента управления, отражающему его эффективность.
Видимость означает, что элемент управления виден.
7.4.2 Согласованность
7.4.3 Ярлыки
7.4.4 Обратная связь
7.4.5 Полный диалог
7.4.6 Обработка ошибок
7.4.7 Отмена действия
7.4.8 Уменьшите нагрузку на кратковременную память
7.5 От анализа к проектированию пользовательского интерфейса
7.5.1 Варианты использования и иерархия меню
Меню — это способ организовать большое количество связанных вариантов использования или диалогов в пользовательском интерфейсе.
Дизайнер должен оценить иерархию меню на основе количества вариантов использования.
Уровень меню обычно содержит 5-10 пунктов.
7.5.2 Диалоги и раскадровки
Необходимо записывать разговоры, которые нужны пользователям
Раскадровка: отобразите эту серию эскизов экрана в разговоре.
7.6 Дизайн пользовательского интерфейса
7.6.1 Рекомендации по разработке форм и таблиц
Расположение и форматирование интерфейса
Согласованность, метки и заголовки, распределение и порядок, шрифты и цвета.
ввод данных
Текстовое поле, окно списка, поле со списком, переключатель, флажок
Руководство и контроль поддержки
Свернуть, развернуть, закрыть, полосы прокрутки, изменить размер
7.6.2 Дополнительные рекомендации по интерфейсам браузера
последовательность
Каскадные таблицы стилей (CSS) — стандарт кодирования веб-страниц, который позволяет дизайнерам веб-сайтов указывать части страницы, которые всегда выглядят одинаково, а также части, которые различаются в зависимости от задачи или аудитории.
Вопросы производительности
Чувствителен к сетевым подключениям, объему передаваемой информации, типу передаваемой информации
Картинки, видео и звуки
Будут проблемы совместимости
Особые пользователи (инвалидность)
Вспомогательные технологии – программное обеспечение, которое адаптирует пользовательские интерфейсы к особым потребностям людей с ограниченными возможностями (например, инструменты преобразования текста в речь и распознавания речи).
7.6.3 Дополнительные рекомендации по интерфейсам мобильных устройств
Проблемы проектирования пользовательского интерфейса для мобильных устройств
Маленькие экраны, клавиатуры и сенсорные экраны, ограниченная пропускная способность сети, рекомендации по разработке приложений и наборы инструментов
7.7 Определение системного интерфейса
Системные интерфейсы в широком смысле определяются как входы и выходы, которые не требуют или требуют незначительного вмешательства пользователя.
Разделены на следующие категории
Ввод и вывод из других систем
XML (расширяемый язык разметки) может использоваться для электронного обмена данными и межсистемной связи.
XML реализует встраивание пользовательских структур данных по сравнению с HTML.
Высокоавтоматизированный ввод и вывод
Ввод и вывод из внешних баз данных
7.8 Входные данные системы проектирования
7.8.1 Автоматизированные устройства ввода
Основная цель любого ввода данных — предоставить или обновить данные в системе, не содержащие ошибок. Самое главное — максимально избегать ошибок. Вот несколько способов эффективно избежать ошибок.
Используйте автоматические устройства ввода
По возможности избегайте вмешательства человека
Если входную информацию можно получить из электронной таблицы, используйте таблицу без повторного ввода данных.
Проверьте и исправьте данные
7.8.2 Определение деталей входных данных системы
7.9 Выходные данные системы проектирования
Оформление отчетов, заявлений и возвратных документов
Тип отчета
Подробный отчет: содержит подробную информацию о бизнес-процессе.
Сводный отчет. Этот тип отчета используется для обобщения поэтапных действий.
Отчет об аномальных условиях: создается, когда результаты транзакции или операции являются ненормальными.
Исполнительная отчетность: оценка общего состояния здоровья и операций
Внутренние выходные данные создаются для внутреннего использования организации или подразделения. Обсуждаемые ранее отчеты относятся к внутренним выходным данным; внешние выходные данные создаются для использования внешними членами организации, например, информация о подтверждении заказа, отчеты о ежемесячных расчетах и т. д. Поскольку это официальный деловой документ, созданный для посторонних, и требует более высокого качества.
Существует тип внешнего вывода, который называется документом возврата. Выходные данные, предоставляемые пользователю, состоят из части, которую можно оторвать и использовать в качестве входных данных в систему позже, например счет, содержащий квитанцию об оплате, которая будет возвращена вместе с документом возврата. проверять.
электронные выписки
Графика и мультимедийная презентация
chap08 метод разработки системы
8.2 Жизненный цикл разработки системы
8.2.1 Традиционные методы прогнозирования жизненного цикла разработки системы
Метод прогнозирования – это метод, позволяющий заранее планировать проекты развития организации и разрабатывать новые информационные системы в соответствии с планом.
Требования: Предполагается, что проект может быть спланирован заранее, информационная система может быть разработана в соответствии с планом, требования хорошо понятны, а технический риск низок.
модель водопада
В проекте шесть фаз жизненного цикла переходят от одной фазы к другой, и эти фазы являются последовательными.
В традиционной каскадной модели нет дублирования и итераций между различными этапами SDLC.
Модель на относительно правой стороне шкалы представляет собой улучшенную модель водопада.
Усовершенствованная водопадная модель по-прежнему сохраняет прогнозируемую последовательность этапов разработки, однако эти этапы перекрываются, влияют и зависят друг от друга.
Большая гибкость, но по-прежнему предполагает прогнозирующее планирование и последовательные этапы.
8.2.2 Адаптивный подход к жизненному циклу разработки системы
Модели адаптации могут использоваться для разработки, когда требования (требования) неясны и часто включают несколько итераций.
Проекты должны быть более гибкими и адаптироваться к меняющимся потребностям в процессе разработки, спрос неопределенен, а технические риски высоки;
спиральная модель
Относительно далеко от правого края шкалы
Используйте спираль для описания SDLC, начиная с центра и расширяясь наружу снова и снова, пока проект не будет завершен.
Более одного раза за этап
итерационная модель
Подобно методу разработки, описанному в главе 1, строки таблицы представляют собой действия по разработке, а столбцы — итерации.
Каждая итерация содержит несколько этапов, и каждый этап не будет завершен сразу, а будет постоянно улучшаться в последующих итерациях.
Дополнительные понятия об адаптивных подходах
постепенное развитие
Основная концепция заключается в том, что системы создаются небольшими шагами и органично растут.
В ходе проекта система внедряется поэтапно и частично развертывается.
Преимущество в том, что пользователи могут быстро получить часть системы, чтобы можно было как можно быстрее запустить бизнес.
ходячий скелет
Ранний подход к построению полной структуры системы, но обеспечивающий только основные функции.
Сначала создайте «скелет» всего процесса внедрения новой системы от начала до конца, а затем используйте последующие итерации для заполнения скелета.
В проектах это зачастую не крайний выбор.
8.3 Этап поддержки
Прогнозный подход SDLC включает в себя такой этап поддержки.
Адаптивный подход рассматривает этап поддержки как законченный, автономный проект.
На этапе поддержки происходят три основных действия.
Система обслуживания
Укрепить систему
Поддержка пользователей
8.4 Методы, модели, инструменты и технологии
методы разработки системы
Область применения метода самая большая.
Методология включает в себя набор методов выполнения действий и задач, включая моделирование каждого аспекта проекта.
Модель
Модель — это абстрактное представление некоторого конкретного аспекта реального мира, которое позволяет понять сложную концепцию, сосредоточив внимание только на соответствующих частях.
Каждая модель подчеркивает разную информацию.
Мы уже сталкивались с некоторыми из этих моделей: ER-диаграмма, диаграмма вариантов использования, диаграмма классов, диаграмма последовательности.
инструмент
поддержка программного обеспечения
технологии
приобретенный посредством обучения
8.5 Два метода построения и моделирования программного обеспечения
8.5.1 Структурированный подход
Структурированный метод фокусируется на процессе и потоке данных. Он предполагает, что система представляет собой совокупность процессов, которые взаимодействуют с потоком данных.
Структурированный метод — это тот же традиционный метод, что и метод прогнозирования SDLC.
Структурированный анализ
Моделирование с использованием диаграммы потока данных
Также будут использоваться ER-диаграммы.
структурированный дизайн
Проектирование программ с использованием структурных диаграмм
Требуется низкая связанность и высокая связность.
Низкая связанность означает, что разные модули максимально независимы от других модулей, поэтому изменение одного модуля не повлияет на работу других модулей.
Высокая сплоченность означает, что каждый модуль реализует четкую задачу.
структурированное программирование
Включает начало, конец и три структуры: последовательность, выбор, цикл.
Программирование сверху вниз/модульный дизайн
8.5.2 Объектно-ориентированный подход
Объектно-ориентированный подход рассматривает систему как совокупность объектов, которые работают вместе для выполнения определенного взаимодействия.
Объекты — это вещи в системе, которые реагируют на сообщения.
объектно-ориентированный анализ
Процесс идентификации и определения вариантов использования и наборов объектов (классов) в новой системе.
объектно-ориентированный дизайн
Определите все типы объектов, необходимые для общения с людьми и устройствами, и покажите, как они взаимодействуют при выполнении задач.
Используйте такие модели, как диаграммы классов и диаграммы вариантов использования.
Объектно-ориентированного программирования
Напишите инструкции для определения фактического класса и роли каждого объекта класса.
Используйте такие модели, как диаграммы последовательности и диаграммы классов проектирования.
8.6 Гибкая разработка
Разработка ведется в неизвестной и быстро меняющейся среде.
8.6.1 Теория и ценность гибкой разработки
основная теория
Сосредоточьтесь на реагировании на изменения, а не на следовании плану.
Цените людей и взаимодействие, а не процессы и инструменты.
Цените работающее программное обеспечение больше, чем обширную документацию.
Сосредоточьтесь на сотрудничестве с клиентом, а не на переговорах по контракту
Опишите концепцию гибких проектов: хаос.
Это хаос и порядок: первые две основные теории — доминирование индивидуальных ценностей над групповыми ценностями — являются причиной хаоса, и с этим хаосом можно справиться с большей гибкостью. Хаос неизбежен в непредсказуемом процессе разработки. Разработчикам необходимо смириться с хаосом, но иногда необходимо использовать другие методы и приемы, которые полезны для добавления порядка и структуры в проект.
Проще говоря, это означает допустить некоторый хаос, сохраняя при этом общий порядок.
глава09 Планирование проекта и управление проектами
Это первые два из шести основных разделов: выявление проблемы и получение одобрения, планирование и мониторинг проекта.
9.2 Принципы управления проектом
9.2.1 Требования к управлению проектом
По статистике, менее трети успешных проектов
Причины, по которым некоторые проекты терпят неудачу
Основная причина: отсутствие участия высшего руководства и управленческих навыков.
Отсутствие участия группы пользователей
9.2.2 Роль менеджера проекта
Управление проектом — это процесс организации и направления других для достижения запланированных результатов в соответствии с заранее определенным графиком и бюджетом. Его также можно определить как процесс планирования проекта, а затем его мониторинга и контроля.
Внутренние обязанности менеджера проекта
Разработать график проекта
Набирать и обучать членов команды
Координировать работу между членами команды
Оцените риски проекта
Мониторинг и контроль этапов проекта
Управляйте людьми и ресурсами
Внешние обязанности менеджера проекта
Отчет о статусе и прогрессе проекта
Работайте напрямую с клиентами и другими заинтересованными сторонами
Определить потребности в ресурсах и получить ресурсы
Координировать связи с общественностью
Менеджеры проектов работают с разными группами людей
Клиент: Лицо, финансирующее систему.
Комитет по надзору: состоит из клиента и других старших менеджеров для наблюдения за проектом.
Пользователь: человек, который непосредственно использует систему для выполнения задач.
Менеджеры проектов выполняют двойные внутренние и внешние функции.
9.2.3 Управление проектом и церемония (церемония)
Степень формальности проекта или ритуала также оказывает влияние на управление проектом.
Небольшие проекты часто выполняют низкоуровневые ритуалы.
В более крупных и сложных проектах церемонии зачастую выполняются качественно.
Ритуалы проекта различаются при использовании традиционных методов прогнозирования и адаптивных методов.
Адаптивные проекты часто могут быть более формальными или неформальными в своих методах управления: UP (унифицированный процесс) достаточно формален и имеет строгие ритуалы, тогда как итеративные методы более неформальны.
9.2.4 Система знаний по управлению проектами
PMBOK, состоит из девяти модулей.
Управление масштабом проекта
Управление временем проекта
управление стоимостью проекта
Управление качеством проекта
Управление человеческими ресурсами проекта
Управление коммуникациями проекта
управление рисками проекта
Управление закупками проекта
Управление интеграцией проекта
9.2.5 Гибкое управление проектами
Гибкое управление проектами
Объем не совсем понятен, но его необходимо контролировать.
Используйте несколько рекомендаций для определения бизнес-приоритетов
Гибкое управление временем
График должен быть гибким, чтобы учитывать изменения.
Гибкое управление затратами
Затраты сложнее оценить, поэтому контроль затрат не так важен, как при прогнозном подходе.
Гибкое управление рисками
Аспекты проекта с высоким уровнем риска выполняются в первую очередь.
Гибкое управление качеством
Проводить оценку качества после каждой итерации
9.3 Основной процесс 1: выявление проблемы и получение одобрения
9.3.1 Определите проблему
Три основные цели разработки новых систем
Реагируйте на новые возможности развития
занять долю рынка
Решить существующие проблемы бизнеса
Реагировать на внешние команды
Юридические, налоговые и т.д.
Эффективный способ определить проблему — создать документ системного видения (SVD).
Включает в себя три части
описание проблемы
Каковы проблемы и решения?
Возможности системы
Какие функции будет иметь новая система?
преимущества для бизнеса
Выгоды для организации (материальные или нематериальные).
9.3.2 Количественная оценка факторов утверждения проекта
Нужно быть ясным
Предполагаемое время завершения
Ориентировочная стоимость разработки
Ориентировочные текущие расходы
Предварительная прибыль
анализ выгоды и затрат
некоторые концепции
NPV (Чистая приведенная стоимость) чистая приведенная стоимость
Текущая стоимость выгод и затрат от конкретной инвестиции
Рассчитывается путем вычитания затрат с использованием «текущей прибыли» (с использованием коэффициента дисконтирования).
точка возмещения затрат
В течение этого периода долларовая прибыль компенсировала долларовые затраты.
ощутимые выгоды
Часть выгоды, которую можно измерить в деньгах.
нематериальные выгоды
Выгоды для организации, но не поддающиеся количественному измерению или точной оценке.
Улучшения уровня обслуживания (такими способами, которые невозможно измерить в долларах)
Повышение удовлетворенности клиентов (не измеряется в долларах)
Выживание - нужно соревноваться вот так
Необходимость развивать собственный опыт (например, пилотные проекты по новым технологиям)
метод анализа затрат/выгод
Используйте текущую стоимость в качестве оценочной стоимости.
Рассчитать срок службы системы
Рассчитайте период окупаемости и конечный доход, накапливая чистую приведенную стоимость каждый год.
Пример
Период окупаемости использует положительные и отрицательные точки поворота накопленной чистой приведенной стоимости в качестве целой части, а десятичная часть рассчитывается с использованием (последнее отрицательное значение/общая разница)
9.3.3 Оценка риска и технико-экономический анализ
Определить риск и жизнеспособность организации.
Оценить технические риски и осуществимость
Оценить риск и жизнеспособность ресурсов
Определить риски и осуществимость графика
9.3.4 Работа с заказчиками по согласованию
Рассмотрение и одобрение Исполнительного комитета
Советы директоров должны рассматривать и утверждать очень крупные проекты.
Заинтересованные стороны должны понимать, чего от них ожидают.
ИТ-отделам необходимо знать, что делать с кадровым обеспечением и поддержкой.
Вся организация должна знать об этом проекте и его важности.
9.4 Основной процесс 2: Планирование и мониторинг проектов
9.4.1 Создание среды проекта
В отличие от упомянутого ранее проектирования среды, под средой проекта здесь понимается рабочая среда и общение внутри и за пределами команды, а не технология, требуемая системой, и т. д.
Записи и коммуникации – внутренние/внешние
Рабочая среда – поддержка/оборудование/инструменты
ПК или рабочая станция
Программное обеспечение и инструменты для личного развития
Сервер с библиотекой ресурсов, средствами связи
Офисы, конференц-залы, принтеры и другое оборудование
Сотрудники поддержки (вне команды)
Процессы и процедуры
Отчеты и документация
программирование
тест
Практические результаты
Код и контроль версий
9.4.2 Организация хода работ
Используйте график итераций проекта, чтобы назначать варианты использования итерациям.
Составьте подробный график задач и работ, которые необходимо выполнить в каждой итерации – используйте подробный график работ.
Три шага для создания итеративного подробного графика работы
Создание иерархической структуры работ WBS
Оценка усилий и выявление зависимостей
Создайте график, используя диаграмму Гатта
Структура декомпозиции работ содержит
Основа декомпозиции
необходимое время
Порядок выполнения
Оцените время на основе соответствующей информации из WBS и выясните зависимости, возможно, используя критический путь.
Диаграмма Ганта — это гистограмма с действиями в виде столбцов, отображаемая на горизонтальной временной шкале.
За исключением первой задачи, каждая задача имеет предшественницу.
Светлая часть — это критический путь, который влияет на весь прогресс и требует тщательного мониторинга.
9.4.3 Персонал и распределение ресурсов
пять задач
Создание плана ресурсов в проекте
Определите и запросите конкретных технических сотрудников
Определите и запросите конкретных сотрудников пользователей
Организуйте команды в рабочие группы
Организуйте начальное обучение и упражнения по построению команды.
9.4.4 Процесс оценки
ретроспективная выставка
9.4.5 Процесс мониторинга и корректировка
Назначайте работу отдельным лицам или командам
статус коллекции
Была ли задача выполнена и цель достигнута?
Анализ аномалий
Имеют ли исключения значение?
предпринять правильные действия
глава 10 Объектно-ориентированное проектирование: принципы проектирования
10.2 Объектно-ориентированное проектирование: мост между анализом и реализацией
10.3 Проектирование объектно-ориентированной архитектуры (проектирование высокого уровня)
Программные системы обычно делятся на два типа.
Однопользовательская система: выполняется на рабочем столе пользователя или сервере без совместного использования ресурсов.
Системы уровня предприятия: компоненты могут совместно использоваться несколькими людьми или организациями.
Сервер/Клиентская система
Интернет-система (браузер/сервер)
Три основных различия, влияющих на проектирование архитектуры системы
состояние
Клиент/сервер — это система, основанная на состоянии, и соединения клиент/сервер долговечны.
Интернет-системы являются системами без сохранения состояния, и соединения не являются долгосрочными.
Развертывание клиента
Прямое отображение экранов и таблиц
Экраны и таблицы отображаются через браузер
Развертывание сервера
Приложение или клиент подключается напрямую к серверу
Клиент подключается к серверу приложений косвенно через браузер.
Схема компонентов и проект архитектуры
Тип диаграммы проектирования, которая показывает общую архитектуру системы и ее логические компоненты, иллюстрируя, как система будет реализована.
Диаграмма компонентов определяет компоненты системы с точки зрения логики, возможности повторного использования и переносимости.
Базовыми элементами диаграммы компонентов являются элементы компонентов с API.
API — это общедоступные методы, к которым может получить доступ внешний мир.
В диаграммах компонентов есть два типа API.
Входная розетка (Socket)
Выходной порт (Порт)
Пример
Кейс: Проектирование двухуровневой архитектуры Интернета (на самом деле она может быть и трехслойной)
Уровень пользовательского интерфейса (слой просмотра)
Уровень домена (логический уровень)
Уровень доступа к базе данных (уровень данных)
Представление с использованием диаграмм компонентов
10.4 Основные принципы объектно-ориентированного детального проектирования
Этапы объектно-ориентированного детального проектирования
Разработать предварительные диаграммы классов проекта.
Используйте карты CRC для определения обязанностей класса и сотрудничества в сценариях использования.
Разработайте подробные диаграммы последовательности для каждого варианта использования: сначала разработайте предварительные диаграммы последовательности, затем многоуровневые диаграммы последовательности.
Добавьте характеристики метода и навигационную информацию.
Разделите решение на пакеты (схема пакета)
10.5 Класс конструкции и диаграмма классов конструкции
10.5.1 Символы дизайна
Прототип — это способ классификации элементов на основе их характеристик, представленный <<>>
Существует четыре типа прототипов дизайна.
Класс сущности
Идентификатор проекта класса проблемной области, обычно постоянный, представленный <<entity>>
Постоянные классы относятся к классам, данные которых все еще имеют после выключения системы. При реализации методов их данные записываются в базу данных или файл.
Пример
Студенты и преподаватели в системе управления образованием
Класс управления
Это класс, который играет координирующую роль между классами представлений и классами сущностей, подобно маршрутизаторам или коммутаторам, представленным <<controller>>.
Посмотреть класс
Классы представлений или граничные классы находятся на границе автоматизации системы, подобно полям ввода или веб-страницам, обращенным к пользователям, и представлены <<границами>>.
Класс доступа к базе данных
Это класс, который получает данные из базы данных и возвращает их, представленный <<dataAccess>>.
Каждый класс прототипа имеет свой символ.
10.5.2 Представление класса проекта
Определите формат атрибутов в классе дизайна.
видимость
Указывает (или -), может ли другой объект получить прямой доступ к свойству. Обычно частное(-) вместо публичного()
Имя свойства
нижний регистр верблюжьего регистра
выражение типа
класс, строка, целое число, двойное число, дата
Начальное значение
свойство
В фигурных скобках, например {key}.
Определить формат метода (характеристики метода)
видимость метода
имя метода
Тип возвращаемого значения метода
список параметров
Пример
Между именем и типом свойства стоит двоеточие, а также между списком параметров и типом возвращаемого значения метода перед начальным значением стоит знак равенства;
Используйте выделенные курсивом имена классов для обозначения абстрактных классов.
Классы, допускающие только наследование, но не создание экземпляров, обычно представляют собой абстрактные концепции более высокого уровня.
10.5.3 Разработка предварительных диаграмм классов проекта
Уточнение атрибута
Дизайнеры определяют типы атрибутов на основе опыта. В большинстве случаев атрибуты являются невидимыми (частными).
Видимость навигации
Видимость навигации означает, является ли класс видимым или невидимым для другого класса, что указывает на способность одного объекта видеть другой объект и взаимодействовать с ним.
Используйте стрелку, чтобы указать, что указанное направление является видимой стороной.
В этом примере клиент относится к классу продажи, поэтому продажа видна покупателю, но клиент не виден продавцу.
Тип видимости навигации
Представляет отношения «один ко многим» между начальниками и подчиненными, обычно от начальников к подчиненным.
Принудительная ассоциация, при которой объект одного класса не может существовать без объекта другого класса, обычно происходит переход от более независимого класса к зависимому классу.
Например, в описанном выше примере «Клиент и продажа» продажа не имеет смысла, если нет клиентов.
Когда одному объекту требуется информация от другого объекта, может потребоваться стрелка навигации.
Видимость навигации может быть двунаправленной
Шаги по разработке предварительных диаграмм вариантов использования
Вариант использования за вариантом использования, добавленный на диаграмму
Выберите классы предметной области, участвующие в варианте использования (см. идею пререквизитов и постусловий).
Предусловия и постусловия должны быть указаны в описании варианта использования в главе 5.
Добавьте класс контроллера, чтобы позаботиться о варианте использования.
Используйте рекомендации, чтобы определить первоначальные потребности в видимости навигации и добавить их на диаграмму.
Подробно опишите свойства каждого класса с указанием видимости и типа.
Обратите внимание, что из диаграмм классов дизайна часто удаляют ассоциации и множественность, так же как в тексте подчеркивается навигация, но они часто сохраняются.
От диаграммы классов предметной области к диаграмме классов предварительного проектирования
10.6 Использование карт CRC для детального проектирования
Карта CRC означает класс, ответственность, сотрудничество.
Объектно-ориентированное проектирование — это распределение обязанностей по классам и их совместная работа для реализации варианта использования.
Карта CRC разделена на три области: имя класса, имя ответственности и класс сотрудничества.
Шаги по использованию карты CRC
Начните с набора неиспользуемых карточек CRC и последовательно проходите один вариант использования за другим.
Выберите вариант использования и выберите карту в качестве ее контроллера.
Определите класс домена, который в основном отвечает за этот вариант использования. Объекты этого класса будут получать сообщения от контроллера, определять обязанности и записывать их в левой части карточки.
Определите другие классы, которые взаимодействуют с основным классом объекта, чтобы завершить вариант использования, и запишите их на правой стороне карты CRC.
После определения категорий сотрудничества выполнить вышеуказанные операции для каждой категории сотрудничества (определить обязанности/найти категории сотрудничества)
Классы пользовательского интерфейса и классы доступа к базе данных могут быть добавлены соответствующим образом.
Используйте результаты карты CRC для обновления диаграммы классов предварительного проекта.
Обновите метод: ответственность в карточке CRC становится методом (но нет выражения видимости и возвращаемого типа, то есть не добавляются никакие характеристики метода)
Обновить видимость навигации
Пример
Предварительная диаграмма классов дизайна
Обновленная диаграмма классов проектирования.
10.7 Некоторые принципы детального проектирования
низкая связь
Высокая сплоченность
Переменная защита
косвенный
Обязанности объекта
глава 11 Объектно-ориентированное проектирование: реализация проекта
11.2 Детальное проектирование многоуровневых систем
Шаблоны проектирования
Шаблоны проектирования — стандартные методы проектирования и шаблоны, широко признанные хорошей практикой.
Для распространенных проблем проектирования/кодирования шаблоны проектирования предлагают лучший способ решения проблемы.
элементы шаблонов проектирования
Имя схемы
Проблемы, требующие решения
модель решения проблем
Чехол с узором
Преимущества и последствия шаблонов
Первым примером шаблона проектирования программирования является шаблон «Контроллер».
Контроллеры вариантов использования создаются искусственно для передачи сообщений с уровня представления на уровень домена, чтобы уменьшить связанность.
Преимущества и последствия
Уменьшает связь между слоем домена и слоем представления.
обеспечивает уровень косвенности
Контроллеры и классы предметной области тесно связаны
Если вы не будете осторожны, контроллер будет содержать много ненужной логики, особенно бизнес-логики.
11.3 Реализация варианта использования и диаграмма последовательности SSD
Реализация вариантов использования — процесс детального проектирования вариантов использования с использованием диаграмм взаимодействия.
Существует два типа диаграмм взаимодействия.
Блок-схема
Диаграммы последовательности показаны путем расширения диаграммы последовательности системы.
просмотреть объект слоя
Объекты слоя домена (обычно это делается в первую очередь)
объект уровня доступа к данным
Схема сотрудничества
11.3.1 Понимание диаграмм последовательности
Разница между диаграммой последовательности системы и диаграммой последовательности
Диаграмма последовательности системы имеет только один объект, который представляет систему: system; в то время как диаграмма последовательности расширяет объект до внутренней части системы.
Диаграмма последовательности системы имеет только две линии жизни, представляющие актеров и систему. Актеры и каждый объект на диаграмме последовательности имеют линию жизни, хотя длина может быть разной (отсчет времени начинается при создании объекта);
В одном и том же случае использования граничная часть автоматизации диаграммы последовательности системы и диаграммы последовательности одинаковы (все остается неизменным), то есть вход в систему и выход системы наружу являются такой же.
На диаграммах последовательности есть специальный раздел, называемый линией жизни активности.
Линия жизни активности представляет собой время, в течение которого объект находится в активном состоянии выполнения. Активное состояние длится до тех пор, пока все данные не будут сохранены или не будут вызваны другие методы.
На этой диаграмме последовательности создания пользовательского варианта использования: Customform и CustomHandler созданы, а объект Custom создается после метода createCustom, поэтому время начала линии жизни отличается, а прямоугольная полоса является активной линией жизни.
11.3.2 Процесс проектирования реализации варианта использования
этапы проектирования
Разработайте предварительную диаграмму классов дизайна, показывающую видимость навигации.
Используйте карты CRC для назначения функций классам в сценариях использования.
Разработайте подробные диаграммы последовательности действий для каждого варианта использования.
Предварительная диаграмма последовательности
Многоуровневая диаграмма последовательности
Используйте карты CRC и подробные диаграммы последовательности для обновления диаграмм классов проектов и добавления функций методов.
Диаграммы классов дизайна упаковки
11.3.3 Случай: Предварительная диаграмма классов проекта для создания учетной записи пользователя
Разработайте предварительную диаграмму последовательности на основе предварительной диаграммы классов проекта, разработанной ранее.
Разверните диаграмму последовательности системы и отметьте объекты классов, которые необходимо использовать в исходной системе: перед ней все еще стоит двоеточие.
Определите внутренние сообщения между объектами, добавьте сообщения и активации для завершения совместной работы.
Формат сообщения соответствует диаграмме последовательности действий системы: *[кодировка] return_value:=имя_функции(список_параметров) Вы также можете использовать пунктирную обратную стрелку в качестве возвращаемого значения.
подтема
11.3.5 Рекомендации и предположения для разработки предварительных диаграмм последовательности
гид
Принять каждое сообщение и определить другие внутренние сообщения, возникающие в результате этого входного сообщения.
При обработке каждого сообщения указывайте набор затрагиваемых классов.
Обогащайте структуру сообщения, добавляйте истинные и ложные условия, циклы, возвращаемые значения, передачу параметров и т. д.
гипотеза
Гипотеза технического совершенства
предположение об идеальной памяти
никаких предположений об аномалиях
11.3.6 Разработка многоуровневых диаграмм последовательности
Вышеупомянутое является лишь предварительной диаграммой последовательности для уровня домена (логического уровня). Чтобы более подробно описать варианты использования, вам необходимо разработать диаграммы последовательности для уровня доступа к данным и уровня представления.
11.4 Использование диаграммы взаимодействия диаграммы взаимодействия
11.5 Обновление и диаграмма классов дизайна упаковки
Обновить диаграмму классов проектирования
На основе информации из диаграммы последовательности добавьте функции метода для обновления DCD.
Три типа метода
Метод конструктора: создание нового экземпляра объекта
Методы чтения и записи данных: получение или обновление значений атрибутов.
Методы, специфичные для конкретного случая использования: включены в диаграмму классов проектирования.
Карта пакета
Диаграмма пакета — это диаграмма высокого уровня, которая связывает связанные группы классов.
Используйте значки в виде папок для обозначения пакетов, а классы размещаются в соответствующих пакетах в соответствии со слоями, к которым они принадлежат.
Используйте пунктирные стрелки для обозначения зависимостей, включая зависимости между классами и зависимости между пакетами.
Пример
Частичная диаграмма пакета только с одним вариантом использования
Схема пакета подсистемы
11.6 Другие распространенные шаблоны проектирования
адаптер
Когда необходимо соединить две системы, но интерфейсы между ними не совпадают, необходим адаптер.
Подключите несовпадающие интерфейсы, перезаписав данные
Например: при столкновении с разными поставщиками (налоги, стоимость доставки) вам нужно только переписать адаптер.
фабрика
Фабричные классы используются для создания множества различных типов экземпляров служебных классов.
Обычно классу инструмента нужен только один экземпляр, и фабрика должна гарантировать, что существует только один экземпляр.
Синглтон
У синглтона есть статическая переменная, указывающая на его экземпляр. Проверьте эту переменную каким-нибудь методом. Если он пуст, вы можете создать экземпляр и присвоить его переменной, если он не пуст, вы можете напрямую вернуть экземпляр переменной.
Соединение классов{ частный статический conn = null; публичный синхронизированный статический getConnection(){ если конн == ноль { conn = новое соединение (); } возвратный конн.; } }
Фабрика и синглтон
Основная логика фабрик и синглтонов одна и та же: оба призваны гарантировать наличие только одного экземпляра объекта и экономить накладные расходы на память.
Но фабрика должна отвечать за несколько классов; синглтон проверяет только статические переменные экземпляра внутри класса.