Wondershare EdrawMind
Галерея диаграмм связей Глава 4. Интеллектуальная карта проектирования и инженерии
- 2
Глава 4. Интеллектуальная карта проектирования и инженерии
Глава 4. Интеллектуальная карта проектирования. Эта интеллектуальная карта включает обзор разработки программного обеспечения, принципов проектирования программного обеспечения, проектирования архитектуры программного обеспечения, технологии проектирования на уровне компонентов, спецификаций проекта и анализа проекта. Она используется для обзора и предварительного просмотра.
Отредактировано в 2023-11-14 21:39:57
Глава 4. Интеллектуальная карта проектирования и инженерии
- Рекомендовано вам
- Структура
Организационная структура команды разработчиков программного обеспечения, планирование целей, интеллектуальная карта
- 2
Анализ требований, тестирование программного обеспечения, разработка программного обеспечения, проектирование программного обеспечения, самостоятельное изучение интеллект-карты.
- 3
Разработка программного обеспечения, регистрация в наушниках и механизм управления сообщениями
- 2
Глава 4 Дизайн-проект
Обзор проектирования программного обеспечения
Обзор проектирования программного обеспечения
Анализ требований к программному обеспечению решает проблему «что делать», а процесс проектирования программного обеспечения решает проблему «как это сделать».
Проектирование программного обеспечения — это процесс преобразования требований к программному обеспечению в представление программного обеспечения. Он в основном состоит из двух этапов: этапа проектирования архитектуры программного обеспечения и проектирования на уровне компонентов.
Задачи по проектированию программного обеспечения
Используя подход проектирования, информация о требованиях к программному обеспечению, представленная данными, функциональными и поведенческими моделями в модели анализа программного обеспечения, передается на этап проектирования, в результате чего проектируются данные/классы, проектируется архитектура, проектируется интерфейс, проектируется уровень компонентов.
Проектирование данных/классов: преобразование модели аналитического класса в реализацию класса и структуры данных, необходимые для реализации программного обеспечения.
Подробное содержание данных, описанное в классах, объектах данных и связях, определенных в CRC и словаре данных, обеспечивает основу для действий по проектированию данных.
Процесс проектирования данных включает в себя следующие два этапа:
Во-первых, выбор логического представления объектов данных, определенных на этапе анализа требований, требует алгоритмического анализа различных структур с целью выбора наиболее эффективного проектного решения;
Затем определите программные модули, которые работают с логическими структурами данных, необходимыми для ограничения или масштабирования влияния отдельных решений по проектированию данных.
Архитектурное проектирование. Архитектурное проектирование определяет общую структуру программного обеспечения.
Архитектурный проект определяет общую структуру программного обеспечения, которая состоит из компонентов программного обеспечения, видимых снаружи атрибутов и связей между ними.
Представления архитектурного проекта могут быть получены на основе спецификаций системы, моделей анализа и взаимодействий подсистем, определенных в модели анализа.
Проектирование интерфейса. Проектирование интерфейса описывает, как взаимодействовать внутри программного обеспечения, между программным обеспечением и системами совместной работы, а также между коллегами по программному обеспечению.
Дизайн интерфейса в основном включает в себя три аспекта:
Проектирование интерфейсов между программными модулями
Проектируйте интерфейсы между модулями и другими производителями и потребителями информации, не связанными с человеком (например, внешними объектами).
Интерфейс между дизайнером (пользователем) и компьютером
Проектирование на уровне компонентов. Проектирование на уровне компонентов преобразует структурные элементы архитектуры программного обеспечения в процедурное описание компонентов программного обеспечения.
Проектирование на уровне компонентов преобразует структурные элементы архитектуры программного обеспечения в процедурные описания компонентов программного обеспечения.
Информация, полученная из моделей на основе классов, моделей потоков и поведенческих моделей, является основой для проектирования компонентов.
Цели проектирования программного обеспечения
В процессе разработки программного обеспечения мы должны уделять пристальное внимание факторам качества программного обеспечения.
Целями процесса разработки программного обеспечения McGlanghlin являются:
1) Проект должен реализовывать все явные требования, описанные в модели анализа, и должен отвечать всем неявным требованиям, ожидаемым пользователем.
2) Проект должен быть читаемым и понятным, чтобы его можно было легко программировать, тестировать и поддерживать в будущем.
3) Проектирование должно начинаться с точки зрения реализации и давать полную картину программного обеспечения, связанную с данными, функциями и поведением.
Технические стандарты для измерения проектирования
1) Разработанная структура должна представлять собой иерархическую структуру для установления контроля между компонентами программного обеспечения.
2) Конструкция должна быть модульной, с логическим разделением программного обеспечения на компоненты, выполняющие определенные функции или подфункции.
3) Проект должен включать в себя как абстракцию данных, так и абстракцию процесса.
4) В конструкции должны быть установлены модули с независимыми функциональными характеристиками.
5) В проекте должны быть предусмотрены интерфейсы, которые уменьшают количество сложных связей между модулем и внешней средой.
6) При проектировании должна быть предусмотрена возможность создания управляемого и воспроизводимого метода, основанного на информации, полученной в результате анализа требований к программному обеспечению.
процесс разработки программного обеспечения
1) Разработать спецификации
2) Архитектура и дизайн интерфейса
3) Проектирование данных/классов
4) Проектирование на уровне компонентов (процессов)
5) Написание проектной документации.
6) Обзор дизайна
принципы проектирования программного обеспечения
Абстракция и постепенное уточнение
Абстракция — это базовая стратегия управления сложностью по мере постепенного увеличения масштаба разработки программного обеспечения.
Процесс абстракции идет от частного к общему. Концепция верхнего уровня — это абстракция концепции нижнего уровня, а концепция нижнего уровня — это уточнение и уточнение концепции верхнего уровня.
Каждый шаг процесса разработки программного обеспечения представляет собой конкретное описание интерпретации более высокого уровня абстракции.
Основными методами абстракции при проектировании программного обеспечения являются: абстракция процесса и абстракция данных.
Абстракция процесса (также называемая функциональной абстракцией) означает, что любая операция, завершающая четко определенную функцию, может рассматриваться пользователем как единый объект, хотя на самом деле эта операция завершается серией операций более низкого уровня.
Абстракция данных относится к определению типов данных и операций, применяемых к объектам этого типа, и ограничивает диапазон значений объектов. Данные можно изменять и наблюдать только с помощью этих операций.
Постепенно добивайтесь усовершенствования
Пошаговое уточнение: разбиение процесса решения проблемы на несколько шагов или этапов, причем каждый шаг становится более уточненным и ближе к решению проблемы, чем предыдущий.
Абстракция позволяет дизайнерам описывать процессы и данные, игнорируя детали низкого уровня, а уточнение помогает дизайнерам раскрывать детали низкого уровня в процессе проектирования.
Модульный
Модуляризация, то есть разделение программного обеспечения на более мелкие, независимые, но взаимосвязанные компоненты в соответствии с заданными принципами, на самом деле представляет собой процесс декомпозиции и абстракции системы.
Модуль — это набор программных объектов, таких как описания данных и исполняемые операторы. Он имеет индивидуальное имя и доступен по имени.
Например, процесс. Функции, подпрограммы, макросы и т. д.
сокрытие информации
Детали реализации каждого модуля должны быть скрыты от других модулей.
Информация (включая данные и процедуры), содержащаяся в блоке, не может быть использована другими модулями, которым эта информация не нужна.
Посредством сокрытия информации можно определить и обеспечить ограничения доступа к деталям процесса и локальным структурам данных модуля.
Функционально независимый
Функциональная независимость. Функциональная независимость является прямым результатом таких концепций, как модульность, абстракция, сокрытие информации и локализация. Функциональная независимость может быть достигнута путем разработки модулей, которые являются функционально специфичными и избегают чрезмерного взаимодействия с другими модулями.
Важность функциональной независимости
Функциональность разделена, а интерфейсы упрощены, что упрощает разработку программного обеспечения.
Поскольку побочные эффекты, вызванные изменением конструкции или кодирования, ограничены, распространение ошибок уменьшается и становится возможным повторное использование модулей, что упрощает обслуживание и тестирование программного обеспечения.
Функциональную независимость можно измерить двумя показателями: сплоченностью и связанностью.
Сплоченность — это мера того, насколько тесно элементы внутри модуля интегрированы друг с другом.
Общая связность модулей разделена на семь типов.
1) Случайная связность (случайная связность): Модуль, разделяющий одни и те же сегменты программного кода, не обладающие явно независимыми функциями в нескольких модулях, называется модулем случайной связности.
2) Логическая связность: относится к модулю, который выполняет набор логически связанных задач. При вызове модуля передаваемые ему параметры управления определяют, какую функцию модуль должен выполнять.
3) Конвергенция времени: означает, что все задачи в модуле должны выполняться в течение одного и того же периода времени. Например, модуль инициализации и модуль завершения.
4) Связность процесса: относится к модулю, выполняющему несколько задач, и эти задачи должны выполняться в соответствии с определенной процедурой (процедурной).
5) Связность связи: означает, что все элементы обработки в модуле сосредоточены в области определенной структуры данных.
6) Последовательная связность: относится к модулю, выполняющему несколько функций, и эти функции должны выполняться последовательно.
7) Функциональная сплоченность: относится к тому факту, что все части модуля работают вместе для выполнения определенной функции, тесно связаны и неделимы.
Связь — это мера относительной независимости между модулями (насколько тесно они связаны друг с другом).
Обычно существует семь типов возможных методов связи между модулями.
1) Соединение контента: если один модуль напрямую обращается к внутренним данным другого модуля или один модуль не обращается к другому модулю через обычный вход, или у двух модулей частично перекрывается программный код, или у одного модуля есть несколько входов; Затем между двумя модулями происходит соединение контента.
2) Публичная связь: если все группы модулей имеют доступ к одной и той же общей среде данных, связь между ними называется публичной связью. Среда общедоступных данных может представлять собой глобальную структуру данных, общую область связи, общедоступную зону покрытия памяти и т. д.
3) Внешнее соединение: Когда модули подключаются через среду вне программного обеспечения (например, ввод-вывод, соединяющий модуль с определенным устройством, форматом или протоколом связи), это называется внешним соединением.
4) Связь управления: если параметры, передаваемые от одного модуля к другому модулю, содержат информацию управления, и информация управления используется для управления логикой выполнения в принимающем модуле, это называется связью управления.
5) Связь тегов: часть структуры данных (например, подструктура определенной структуры данных) передается между двумя модулями через таблицу параметров, что представляет собой связь тегов.
6) Связь данных: только простые данные передаются между двумя модулями через таблицы параметров, что называется связью данных.
7) Косвенная связь: Если между двумя модулями нет прямой связи, то есть любой из них не зависит от другого и может работать независимо, такая связь называется косвенной связью.
Чем теснее связи между модулями, тем больше связей, тем выше связанность и слабее их функциональная независимость.
Чем теснее связь между различными элементами внутри модуля, тем выше его связность.
Модули с сильной функциональной независимостью должны быть модулями с высокой связностью и низкой связанностью.
Проектирование архитектуры программного обеспечения
Архитектура программного обеспечения фокусируется на одной или нескольких структурах системы, включая программные компоненты, видимые извне свойства этих компонентов и отношения между ними.
Басс предлагает три ключевые причины, почему архитектура важна:
① Содействие общению между заинтересованными сторонами
②Способствует раннему принятию решений при проектировании системы
③Передаваемая абстракция системного уровня
процесс разработки архитектуры
Общая архитектура программного обеспечения
Структура с одним хостом k
Структура C/S (Клиент/Сервер)
Структура B/S (браузер/сервер)
стиль архитектуры программного обеспечения
Подавляющее большинство можно отнести к одному из относительно небольшого числа архитектурных стилей.
Каждый стиль описывает системную категорию, которая включает в себя:
① Некоторые компоненты, реализующие функции, необходимые системе (например, базы данных, вычислительные модули).
②Набор «разъемов», используемых для подключения компонентов для «связи, координации и сотрудничества».
③ Определить системные ограничения на интеграцию компонентов.
④ Семантическая модель, позволяющая проектировщикам понимать свойства всей системы и анализировать известные свойства.
дата-ориентированная архитектура
Некоторые данные (например, файл или база данных) хранятся в центре структуры и часто используются, добавляются, удаляются или изменяются другими компонентами.
Архитектура стиля потока данных
Эта структура подходит для преобразования входных данных в выходные данные с помощью ряда компонентов расчета или обработки.
Архитектура стиля вызова и возврата
Этот стиль позволяет разработчику программного обеспечения создавать архитектуру, которую очень легко модифицировать и расширять.
Содержит: архитектуру стиля основной программы/подпрограммы и архитектуру стиля удаленного вызова процедур.
Здесь нужно понять несколько понятий:
Глубина структуры программы. Количество уровней структуры программы называется глубиной структуры. Глубина структуры в определенной степени отражает размер и сложность структуры программы.
Ширина структуры программы: максимальное количество модулей на одном уровне иерархии называется шириной структуры.
Разветвление и разветвление модуля: разветвление представляет собой количество других модулей, которые модуль напрямую вызывает (или контролирует). Включение определяется как количество модулей, которые вызывают (или управляют) данный модуль. Множественные разветвления означают, что необходимо контролировать и координировать множество подчиненных модулей. Модули с несколькими вентиляторами обычно являются общедоступными.
Архитектура объектно-ориентированного стиля
Методы системных компонентов для инкапсуляции данных и манипулирования ими.
Взаимодействие и координация между компонентами передаются через сообщения.
иерархический стиль архитектуры
В этой структуре определены различные уровни, и каждый уровень выполняет операции, более близкие к машинным инструкциям, чем внешний уровень.
Оценка альтернативных архитектур
Для одного и того же требования к программному обеспечению будут созданы разные структуры программного обеспечения из-за разных принципов различных методов проектирования.
Различные структуры программного обеспечения для одной и той же проблемы
ATAM (метод анализа компромиссов в архитектуре)
1) Определите сценарии применения (сценарии): опишите систему с точки зрения пользователя через диаграммы вариантов использования.
2) Получение требований, ограничений и описания среды. Это часть разработки требований, позволяющая гарантировать, что все проблемы клиента перечислены.
3) Опишите архитектурный стиль, который может справиться с вышеуказанными ситуациями и требованиями.
4) Оцените каждую производительность системы индивидуально. Производительность проектирования архитектуры включает в себя: надежность, производительность, безопасность, ремонтопригодность, гибкость, тестируемость, переносимость, возможность повторного использования и взаимодействия и т. д.
5) Для различных архитектурных форм оцените чувствительность характеристик, упомянутых в шаге 4. Оценить это можно так: внести небольшие изменения во всю архитектуру, проанализировать и определить, есть ли какие-то чувствительные изменения в производительности обращения. Те характеристики, на которые сильно влияют архитектурные изменения, называются чувствительными точками.
6) Оцените архитектуры, предложенные на этапе 3, посредством анализа чувствительности на этапе 5. Метод, описанный SEI, заключается в следующем: когда определены чувствительные точки архитектуры, нам необходимо найти факторы, которые требуют наибольшего количества компромиссных точек в системе (точки компромисса). Фактор компромисса означает, что изменение этого содержимого в архитектуре приведет к чувствительным изменениям в производительности системы. Например, производительность системы с клиент-серверной структурой тесно связана с количеством серверов в системе (например, увеличение количества серверов в определенной степени улучшит производительность системы)... В в данном случае количество серверов такое. Точка баланса в архитектуре.
При проектировании архитектуры программного обеспечения можно руководствоваться следующими правилами:
(1) Улучшить структуру программного обеспечения и повысить независимость модулей.
(2) Соответствующая глубина, ширина, разветвление и разветвление модуля.
(3) Объем оценки модуля должен находиться в пределах его контроля.
(4) Стремиться снизить сложность интерфейсов модулей.
(5) Спроектируйте модуль с одним входом и одним выходом.
(6) Функциональность модуля должна быть предсказуемой, а размер модуля должен быть умеренным.
(7) Как правило, лучше, чтобы модуль содержал от 30 до 50 операторов.
(8) Хорошо спроектированная структура программного обеспечения обычно имеет более высокую степень разветвления на верхнем уровне, меньшую на среднем уровне и высокую степень разветвления на нижнем уровне.
технология проектирования на уровне компонентов
В методах структурного анализа и проектирования компоненты часто называют модулями.
В объектно-ориентированном анализе и проектировании компоненты называются классами. В методах разработки, основанных на компонентах, компоненты называются компонентами.
На этапе проектирования на уровне компонентов в основном выполняются следующие работы:
Определите алгоритм, используемый для каждого компонента, выберите подходящий инструмент для описания процесса алгоритма и напишите подробное процедурное описание компонента.
Определите структуры данных, используемые внутри каждого компонента.
В конце проектирования на уровне компонентов вышеуказанные результаты должны быть записаны в спецификацию проекта на уровне компонентов и посредством проверки сформированы в формальный документ, который послужит основой для следующего этапа (этапа кодирования).
Метод структурированного программирования
Более популярное определение звучит так: «Если блоки кода программы связаны только через три основные структуры управления: последовательность, выбор и цикл, и каждый блок кода имеет только один вход и один выход, то программа называется структурированной. . из"
С развитием новых методов и технологий разработки программного обеспечения, таких как объектно-ориентированное и повторное использование программного обеспечения, более реалистичным и эффективным подходом к разработке может стать органичное сочетание методов «сверху вниз» и «снизу вверх».
Графическое представление
Блок-схема программы
Блок-схемы программ не зависят от какого-либо языка программирования, относительно интуитивно понятны, понятны и просты в освоении и освоении.
Чтобы использовать блок-схемы для описания структурированных программ, вы должны ограничить блок-схемы только пятью базовыми структурами управления.
диаграмма Н-С
Насси и Шнейдерман предложили инструмент графического описания, соответствующий принципам структурного программирования, называемый блочной диаграммой, также называемой диаграммой NS.
Пять основных структур управления
ПАД
PAD — это аббревиатура диаграммы анализа проблем, которая произошла от блок-схемы программы.
Пять основных структур управления
Таблица решений
Когда алгоритм содержит несколько вложенных вариантов выбора условий, его трудно четко описать с помощью блок-схем программы, диаграмм N-S или PAD.
Однако таблицы решений могут четко выразить соответствие между сложными комбинациями условий и действиями, которые следует предпринять.
Преимущество таблицы решений в том, что она позволяет кратко и однозначно описать все правила обработки.
Однако таблица решений представляет собой статическую логику, которая является возможным результатом при определенной комбинации значений условий. Она не может выразить ни последовательность обработки, ни структуру цикла.
Язык дизайна PDL
PDL (язык проектирования программ) — это язык, используемый для описания разработки алгоритмов и деталей обработки функциональных компонентов, называемый языком проектирования.
Это своего рода псевдокод. Вообще говоря, грамматические правила псевдокода делятся на «внешнюю грамматику» и «внутреннюю грамматику».
Иностранный синтаксис должен соответствовать грамматическим правилам часто используемых операторов общих языков программирования.
Внутренняя грамматика может использовать несколько простых предложений, фраз и общих математических символов на английском языке для описания функций, которые должна выполнять программа.
Примеры использования PDL
Возможности PDL
1. Существует фиксированный внешний синтаксис ключевых слов, который обеспечивает все структурированные структуры управления, описания данных и функции компонентов. Ключевые слова, принадлежащие иностранной грамматике, представляют собой ограниченный словарный набор, который может структурно сегментировать текст PDL и облегчить его понимание. Чтобы различать ключевые слова, предусмотрено, что ключевые слова должны быть написаны с заглавной буквы, а остальные слова — со строчной.
2. Внутренняя грамматика использует естественный язык для описания характеристик обработки. Внутренний синтаксис относительно гибок: пока он написан ясно, нет необходимости беспокоиться о грамматических ошибках, чтобы люди могли сосредоточиться на описании логики алгоритма.
3. Существуют механизмы описания данных, включая простые (например, скаляры и массивы) и сложные (например, связанные списки и иерархические структуры) структуры данных.
4. Существует определение подпрограммы и механизм вызова для выражения описаний интерфейса различными способами.
Спецификации дизайна и обзоры дизайна
технические характеристики проекта
обзор дизайна
Конечная цель проектирования программного обеспечения — получить лучшее решение.
«Лучшее» означает, что среди всех решений-кандидатов выбирается решение, способное достичь более высокой производительности, большей надежности и ремонтопригодности, исходя из условий экономии затрат на разработку, снижения потребления ресурсов и сокращения времени разработки.
Содержание обзора дизайна
Прослеживаемость: то есть анализ структуры системы и структуры подсистем программного обеспечения для подтверждения того, охватывает ли проект программного обеспечения все выявленные требования к программному обеспечению и можно ли проследить каждый компонент программного обеспечения до определенного требования.
Интерфейс: проанализируйте связь между различными частями программного обеспечения и убедитесь, что внутренний и внешний интерфейс программного обеспечения четко определены. Соответствует ли компонент требованиям высокой связности и низкой связанности. Находится ли область действия компонента в пределах его диапазона управления.
Риск: Подтвердите, может ли проект программного обеспечения быть реализован в срок при существующих технических условиях и в рамках бюджета.
Практичность: подтвердите, является ли дизайн программного обеспечения практичным для решения потребностей.
Техническая ясность: подтверждение того, что дизайн программного обеспечения выражен в форме, которую можно легко перевести в код.
Удобство сопровождения: с точки зрения обслуживания программного обеспечения подтвердите, учитывает ли конструкция программного обеспечения удобство будущего обслуживания.
Качество: подтвердите, имеет ли дизайн программного обеспечения хорошие характеристики качества.
Различные варианты: посмотрите, рассматривали ли вы другие варианты и каковы критерии сравнения различных вариантов?
Ограничения: оцените, реалистичны ли ограничения программного обеспечения и соответствуют ли они требованиям.
Другие конкретные вопросы: оценка документации, тестируемость, процесс проектирования и т. д.
Существует два типа проверки: формальная проверка и неофициальная проверка.
Помимо разработчиков программного обеспечения, к участию в официальной проверке также приглашаются представители пользователей и эксперты в предметной области, обычно в форме защиты.
Неофициальные обзоры носят более или менее одноранговый характер и не ограничены временем или форматом.