«Программная инженерия» 60'

1. Программный процесс

1. Концепция программного процесса

отвечать:

1) Программный процесс описывается как кто, когда, что и как достигает конкретной цели, чтобы разработать программное обеспечение, требуемое заказчиком. ** ISO9000 определяет процесс как: «Систему действий, использующих ресурсы для преобразования входных данных в выходные». («Введение в программную инженерию», стр. 14)

2) Процесс определенпорядок применения,Документация, которую необходимо предоставить,Действия руководства, необходимые для обеспечения качества программного обеспечения и координации измененийа такжеВехи, отмечающие завершение задач на разных этапах разработки программного обеспечения. («Введение в программную инженерию», стр. 14)

3)Программный процесс — это ряд связанных процессов в цикле создания программного обеспечения. Процесс — это набор действий, а действие — это набор задач.(«PPT Soft Engineering Фуданьского университета»)

Программный процесс имеет три значения:

индивидуальное значение:

Он относится к набору действий определенного типа в жизненном цикле программного продукта или системы, таких как процесс разработки программного обеспечения, процесс управления программным обеспечением и т. д.;

Общее значение:

означает совокупность программного процесса программного продукта или системы во всех вышеуказанных значениях;

Инженерное значение:

Это относится к разработке решения программного процесса.Он применяет принципы и методы разработки программного обеспечения для построения модели программного процесса и сочетает в себе конкретные требования программных продуктов для создания экземпляров и работы в пользовательской среде с целью дальнейшего улучшения программного обеспечения. производительность и сократить расходы.

2. Особенности классических моделей программных процессов (водопадная модель, инкрементная модель, эволюционная модель, унифицированная модель процесса)

отвечать:

модель водопада

Водопадная модель делит жизненный цикл программного обеспечения на шесть основных действий, включая анализ требований, спецификацию, проектирование, написание программ, тестирование программного обеспечения, а также эксплуатацию и техническое обслуживание, и указывает их нисходящую, взаимосвязанную фиксированную последовательность, как водопад, один за другим. , падение уровня.
Модель водопада подчеркивает роль документации и требует тщательной проверки на каждом этапе.
Линейный процесс модели водопада слишком идеален и больше не подходит для современных моделей разработки программного обеспечения, и индустрия почти отказалась от него.Главная проблемаДа:

1. Полностью фиксировано разделение каждого этапа, а между этапами формируется большое количество документов, что сильно увеличивает нагрузку;

2. Поскольку модель разработки является линейной, пользователи могут видеть результаты разработки только в конце всего процесса, что увеличивает риск разработки;

3. Ранние ошибки могут быть обнаружены только на более позднем этапе тестирования разработки, что чревато серьезными последствиями.

Инкрементная модель

Подобно строительству здания, программное обеспечение создается шаг за шагом.

В инкрементной модели программное обеспечение проектируется, внедряется, интегрируется и тестируется как ряд инкрементных компонентов, каждый из которых состоит из фрагментов кода, обеспечивающих определенные функции, образованные несколькими взаимодействующими модулями.

Инкрементные модели предоставляют не работающий законченный продукт на различных этапах, а рабочий продукт, который удовлетворяет подмножество потребностей клиента.
Инкрементные модели фокусируются на фиксации рабочего продукта для каждого инкремента.
Весь продукт разбивается на несколько компонентов, и разработчики доставляют продукт покомпонентно,Преимущество этого заключается в том, что разработка программного обеспечения может лучше адаптироваться к изменениям, и клиенты могут постоянно видеть разрабатываемое программное обеспечение, тем самым снижая риски разработки..

Однако инкрементная модель также имеет следующие недостатки:

1. Поскольку каждый компонент постепенно включается в существующую программную архитектуру,Поэтому добавление компонентов не должно разрушать части уже построенной системы., но также требует, чтобы программное обеспечение имело открытую архитектуру.

2. В процессе разработки неизбежны изменения требований. Гибкость инкрементной модели может сделать ее намного лучше, чем модели водопада и модели быстрого прототипирования, с точки зрения возможности внесения таких изменений, ноПри этом также легко скатиться к изменению модели, так что управление программным процессом потеряет свою целостность..

При использовании инкрементной модели первым инкрементом часто является основной продукт, удовлетворяющий основные потребности. После того, как основной продукт доставлен пользователям, после оценки формируется следующий инкрементальный план развития, который включает в себя модификацию основного продукта и выпуск некоторых новых функций. Каждый процесс повторяется после каждого дополнительного выпуска, пока не будет получен окончательный отполированный продукт.

модель эволюции

Эволюционная модель — это глобальная модель жизненного цикла программного обеспечения (или продукта). Это итеративный метод разработки.

То есть в соответствии с основными потребностями пользователей,Создайте первоначальную работоспособную версию программного обеспечения с помощью быстрого анализа, это исходное программное обеспечение обычно называют прототипом, а затем в соответствии сЗамечания и предложения пользователей по использованию прототипов, сделанные в ходе разработки прототипа для улучшения, получения прототипа новой версии.повторить процесс, и, наконец, может быть получен программный продукт, удовлетворяющий пользователя.

Процесс разработки с использованием эволюционной модели на самом деле представляет собой процесс постепенного развития от первоначального прототипа до конечного программного продукта. Эволюционные модели особенно полезны, когда нет точного знания требований к программному обеспечению.

недостаток:

1. Если все требования к продукту не будут полностью ясны в начале, это вызовет трудности в общем проектировании и ослабит целостность дизайна продукта, что повлияет на оптимизацию производительности продукта и ремонтопригодность продукта;

2. Без строгого управления процессами эта модель жизненного цикла, скорее всего, выродится в примитивную незапланированную модель «пробы-исправление-ошибки»;

Унифицированная модель процесса

RUP/UP (Rational Unified Process) — это основанная на прецедентах, ориентированная на архитектуру, итеративная и инкрементная модель программного процесса, поддерживаемая методами и инструментами UML и широко используемая в различных объектно-ориентированных проектах.

RUP разработан и поддерживается Rational Corporation и тесно интегрирован с рядом инструментов разработки программного обеспечения. RUP содержит большое количество отличных практик, эти практики называются "Лучшие практики".

Передовой опыт включает в себя:

итеративная разработка программного обеспечения
Управление требованиями
приложение с компонентной архитектурой
Создание визуальной модели программного обеспечения
Серьезное качество программного обеспечения
Контроль изменений программного обеспечения и т. д.

Статическая структура RUP состоит из 6 основных рабочих процессов (бизнес-моделирование,необходимость,Анализ и дизайн,выполнить,контрольная работа,развертывать) и 3 основных рабочих процесса поддержки (Конфигурация и управление изменениями,управление проектом,окрестности)

RUP делит жизненный цикл программного обеспечения на 4 последовательных фазы. Каждый этап имеет четкие цели и определяет вехи, по которым можно оценить, достигнуты ли эти цели. Цели каждого этапа достигаются за одну или несколько итераций.

Цели 4-этапной работы включают в себя:Начальная фаза,Эссенциальная стадия,Этап строительства,этап передачи.

Модель RUP использует итеративную разработку.Посредством многократного выполнения различных рабочих процессов разработки постепенно определяется часть анализа требований и рисков.После проектирования, внедрения и подтверждения этой части выполняется следующая часть работы по анализу требований, проектированию, внедрению и подтверждению. Продолжение последовательно, пока весь проект не будет завершен, позволяет лучше понять требования к поэтапной интеграции для создания надежной архитектуры.

3. Основные понятия оценки процесса и CMM/CMMI

отвечать:

1)CMM (модель зрелости возможностей) — это модель зрелости возможностей.была создана в конце 1980-х годов Институтом разработки программного обеспечения (SEI) Университета Карнеги-Меллона при поддержке Министерства обороны США.Модель оценки зрелости программных процессов организаций, занимающихся разработкой программного обеспечения. В начале создания и развития этой модели основная цель состоит в том, чтобы предоставить метод оценки возможностей разработчика программного обеспечения, а также обеспечить всестороннюю и объективную основу для оценки тендерной деятельности крупномасштабных программных проектов. Позже он также использовался организациями-разработчиками программного обеспечения для улучшения своих программных процессов. («Программная инженерия» Университета Фудань)

CMM обеспечивает структуру уровня зрелости:

Уровень 1 - Начальный уровень
Уровень 2 - Повторяемый уровень
Уровень 3 — определенный уровень
Уровень 4 - Управляемый
Уровень 5 - Уровень оптимизации

2) Министерство обороны США, Совет оборонной промышленности США и SEI/CMU запустили проект CMMI в 1998 г.,Есть надежда, что CMMI представляет собой синтез и улучшение нескольких моделей процессов, систематическую и последовательную структуру улучшения процессов, которая поддерживает несколько инженерных дисциплин и областей, может адаптироваться к характеристикам и потребностям современной инженерии и может улучшить качество и эффективность работы. процесс.. («Программная инженерия» Университета Фудань)

3) Модель CMMI обеспечивает два представления для каждой комбинации дисциплин: поэтапную модель и непрерывную модель.

4. Характеристики Agile-манифеста и Agile-процесса

1)Agile-манифест:

(«Программная инженерия» Университета Фудань)

(1)Люди и взаимодействия важнее процессов и инструментов

Вместо того, чтобы отрицать важность процессов и инструментов, он подчеркивает роль людей и роль коммуникации в разработке программного обеспечения. Программное обеспечение разрабатывается командой людей.Только при достаточном общении и эффективном сотрудничестве между различными сотрудниками, связанными с программным проектом, они могут успешно разработать программное обеспечение, которое удовлетворит пользователей.

Программное обеспечение трудно разрабатывать успешно, если есть только четко определенные процессы и продвинутые инструменты, а также малоквалифицированные люди, которые плохо общаются и сотрудничают.

(2)Работающее программное обеспечение по исчерпывающей документации

Гораздо проще понять, что программа делает с работающей частью программы, чем читать толстую документацию.

Гибкая разработка программного обеспечения делает упор на непрерывную и быструю доставку работающего программного обеспечения (не обязательно полного программного обеспечения) пользователям для утверждения пользователями.

Хорошая и необходимая документация по-прежнему необходима, чтобы помочь нам понять, что делает программное обеспечение, как это сделать и стоит ли его использовать, но главная цель разработки программного обеспечения — создать работающее программное обеспечение.

(3)Взаимодействие с заказчиком при заключении договора (договора)

Только заказчик может четко указать, какой именно софт нужен, однако, как показывает практика, заказчик часто не может в полной мере выразить все свои потребности на ранней стадии разработки, а часть потребностей, выявленных на ранней стадии, может измениться и позже. .

Часто бывает трудно определить требования путем переговоров по контракту.

Гибкая разработка программного обеспечения делает упор на сотрудничество с клиентами и любит потребности пользователей посредством общения и тесного сотрудничества с клиентами.

(4)Своевременное реагирование на изменения, а не следование плану

При разработке любого программного проекта следует разработать план проекта, чтобы определить приоритеты, а также даты начала и окончания задач разработки. Однако по ходу проекта могут меняться требования, бизнес-окружение, технологии и т. д., а также могут меняться приоритеты, даты начала и окончания задач по разным причинам.

Поэтому план проекта должен быть гибким и иметь возможность для изменений. Десятки компаний реагируют на изменения, пересматривая планы с учетом изменений.

2)Характеристики гибкого процесса

(«Программная инженерия» Университета Фудань)

(1) Наивысшим приоритетом является удовлетворение пользователей за счет раннего и непрерывного предоставления ценного программного обеспечения.

(2) Приветствуя необходимость изменений, даже если они происходят на более позднем этапе разработки, чтобы повысить конкурентное преимущество для клиентов, процесс Agile использует изменения в качестве движущей силы.

(3) В цикле от нескольких недель до нескольких месяцев выпускайте работающее программное обеспечение как можно скорее и непрерывно.

(4) В течение всего процесса проекта бизнес-персонал и разработчики должны работать вместе каждый день.

(5) Создайте проектную команду с позитивными сотрудниками в центре, предоставьте им необходимую среду и поддержку и полностью доверяйте их работе.

(6) Наиболее эффективным и действенным способом передачи информации внутри проектной команды является личное общение.

(7) Первичной основой для измерения прогресса проекта является исполняемое программное обеспечение.

(8) Гибкий процесс выступает за устойчивое развитие, и спонсоры проекта, разработчики и пользователи должны иметь возможность поддерживать постоянную скорость в течение длительного времени.

(9) Всегда обращайте внимание на техническое совершенство и хороший дизайн для повышения маневренности.

(10) Простота имеет важное значение, что является искусством максимально сократить ненужную работу.

(11) Лучшие архитектуры, требования и проекты исходят от самоорганизующихся команд.

(12) Команда должна регулярно размышлять о том, как стать более эффективной, и соответствующим образом корректировать свое поведение.

2. Требования к программному обеспечению

1. Концепция требований к программному обеспечению

отвечать:

субъективные потребности: состояние или способность, которые необходимы пользователю для решения проблемы или достижения цели;

объективные потребности: Для удовлетворения системы Конвенции, стандарты, технические характеристики или другие официальные документы, которые должны быть выполнены или обладать условием или способностью;

функциональные требования:

Услуги или функции, которые должна обеспечивать система: например, поиск книг;
Как система обрабатывает определенные входные данные: например, подсказки о недопустимых входных данных;
Поведение системы в конкретной среде: например, долго не работавшая заставка;

нефункциональные требования:

Ограничения качества, связанные с системными функциями или услугами, такие как время отклика, отказоустойчивость, безопасность и т. д. — то, что заботит заказчика (внешнее качество);
Атрибуты качества с точки зрения разработки и сопровождения системы, такие как понятность, масштабируемость и т. д. — что волнует разработчиков программного обеспечения или специалистов по сопровождению (внутреннее качество, владение программным обеспечением)

2. Основной процесс разработки требований

отвечать:

Сбор требований, анализ и обсуждение требований, моделирование системы, спецификация требований, проверка требований, управление требованиями

3. Иерархическая модель потока данных

отвечать:

Метод проектирования иерархической схемы потоков данных

Первым шагом является рисование входных и выходных данных подсистемы.

Представьте себе всю систему как один большой процесс, а затем нарисуйте диаграмму ввода-вывода на основе того, от каких внешних объектов система данных получает потоки данных и каким внешним объектам система отправляет потоки данных. Этот граф называется графом верхнего уровня.

Второй шаг — нарисовать внутреннюю часть подсистемы.

Обработка графа верхнего уровня разбивается на несколько процессов, а потоки данных используются для связи этих процессов, так что входные данные графа верхнего уровня становятся выходным потоком данных графа верхнего уровня после нескольких процессов . Этот граф называется графом слоя 0. Процесс построения графа потока данных из процесса представляет собой декомпозицию процесса. Обработку можно определить следующим образом: там, где изменяется состав или значение потока данных, должна быть проведена обработка, функция которой состоит в реализации изменения, или ее можно рассматривать как единое целое (данные поступают вместе, при совместной обработке) эти данные можно рассматривать как поток данных. Что касается хранения данных, для некоторых данных, которые будут использоваться в определенное время в будущем, они могут быть организованы в хранилище данных для представления.

Третий этап, покраска салона из обработки

Относитесь к каждому процессу как небольшую систему, и просмотрите потоки входных и выходных данных процесса в качестве входных и выходных потоков малой системы. Следовательно, обработка DFD-диаграмма каждой маленькой системы может быть нарисована как диаграмма 0-слоя.

Четвертый шаг, нарисуйте покомпонентный вид подпроцесса.

Для каждой обработки в DFD-диаграмме, декомпозированной на третьем шаге, процесс декомпозиции на третьем шаге повторяется до тех пор, пока обработка, которая не была декомпозирована в диаграмме, не станет достаточно простой (то есть ее нельзя будет декомпозировать повторно). На данный момент получен набор иерархических графов потоков данных.

Пятый шаг — нумерация диаграммы потока данных и обработка

Для программной системы граф потока данных может иметь много слоев, и каждый слой имеет много графов. Чтобы различать разную обработку и разные подграфы DFD, каждый граф должен быть пронумерован для облегчения управления.

Картинка верхнего уровня только одна, и обработка в картинке только одна, поэтому нумеровать ее не нужно.
Для слоя 0 существует только одно изображение, а номера обработки на изображении — 0,1, 0,2, ... или 1, 2.
Подкадр — это номер обработки, который разбивается на родительское изображение.
Номер обработки в дополнительном изображении состоит из номера чертежа, точки и порядкового номера, например: 1,12, 1, 3 и так далее.

4. Моделирование вариантов использования и сценариев и их UML-выражение (диаграмма вариантов использования, диаграмма действий, диаграмма дорожек, диаграмма последовательности).

Диаграмма вариантов использования:

Вариант использования — это текстовое описание последовательности взаимодействий, которые выполняет актор при использовании функции системы. Описание пользовательских требований к системе выражает функции системы и предоставляемые ею услуги, но описывает только то, что делают действующие лица и система в процессе взаимодействия, а не то, как это делать.

Диаграмма деятельности:

Диаграмма деятельности — это частный случай диаграммы состояний. Используется для упрощения рабочих шагов, описывающих процесс или операцию. Действия представлены прямоугольниками со скругленными углами — уже, чем диаграммы состояний, и ближе к эллипсам. Как только обработка в одном действии завершена, оно автоматически вызывает выполнение следующего действия. Стрелки указывают на переход от одного действия к другому. Как и на диаграмме состояний, начальная точка диаграммы деятельности представлена сплошным кругом, а конечная точка представлена концентрическим кругом (внутренний круг — сплошной круг). На диаграмме деятельности могут быть точки принятия решений, то есть один набор условий ведет к одному пути выполнения, а другой набор условий ведет к другому пути выполнения, и эти два пути выполнения являются взаимоисключающими. Точки принятия решений обычно представляются небольшими ромбовидными значками, а условия, вызывающие выполнение этого пути, указываются рядом с соответствующим путем, а сами условия заключаются в квадратные скобки. Используйте диаграмму деятельности, чтобы описать процесс телефонного звонка.

Карта Lanes:

Плавательные дорожки делят действия на диаграмме действий на группы. и назначить группу бизнес-организации, ответственной за эту группу действий. На диаграмме активности дорожки нарисованы вертикальными сплошными линиями.

Блок-схема:

Диаграмма последовательности — это диаграмма взаимодействия, которая подчеркивает синхронизацию сообщений, описывает временную последовательность сообщений, отправляемых между объектами, и используется для представления последовательности действий в варианте использования. На этой двумерной диаграмме объекты располагаются слева направо, а сообщения располагаются в хронологическом порядке по вертикальной оси. При обрамлении рисунка макет должен быть лаконичным.

Принципиальная схема, простая схема покупки автомобиля.

5. Моделирование модели данных и ее UML-выражение (диаграмма классов)

отвечать:

Диаграмма классов (Class Diagram) — это диаграмма, которая описывает классы, интерфейсы, взаимодействия и отношения между ними и используется для отображения статической структуры каждого класса в системе. Диаграммы классов являются основой для определения других диаграмм.На основе диаграмм классов можно использовать диаграммы состояний, диаграммы сотрудничества, диаграммы компонентов и диаграммы конфигурации для дальнейшего описания характеристик других аспектов системы.

В дескрипторе класса UML выражены, чтобы стать набором объектов, имеющих ту же структуру, поведение и отношения. Как использованные атрибуты и операции прикреплены к классу. Класс определяет набор объектов с состоянием и поведением. При этом атрибуты используются для описания состояния и ассоциации. Собственность обычно представлена как цифры и строки значений данных и без личности. Связь об ассоциации между объектами с использованием идентичности представления. Поведение описывается оператором, операция - это реализация метода. По времени жизни класса объекта будет описана, добавляется в состояние, будет описан.

В графическом представлении UML представление класса представляет собой прямоугольник, который состоит из трех частей, а именно имени класса (Name), атрибута класса (Attribute) и операции класса (Operation). Имя класса находится в верхней части прямоугольника, свойства класса — в середине прямоугольника, а операции класса показаны в нижней части прямоугольника. В средней части отображаются не только свойства класса, но также тип свойства и значение инициализации свойства. В нижней части прямоугольника также может отображаться список параметров и тип возвращаемого значения операции и т. д., как показано на рисунке 1.

Состав класса также должен включать такую информацию, как обязанности класса (Ответственность), ограничения класса (Ограничение) и аннотации класса (Примечание).

6. Моделирование поведенческой модели и ее UML-выражение (диаграмма конечного автомата)

отвечать:

Диаграммы конечных автоматов используются для моделирования состояний объектов и событий, вызывающих изменения состояния. Диаграмма конечного автомата UML в основном используется для установления модели динамического поведения класса объекта или объекта, для представления последовательности состояний, испытываемых объектом, событий, которые вызывают переход состояния или действия, и действий, которые сопровождают состояние или объект. переход активности. Диаграммы конечного автомата также можно использовать для описания вариантов использования, а также динамического поведения всей системы.

3. Дизайн и создание программного обеспечения

1. Понятия архитектуры программного обеспечения и архитектурного стиля

отвечать:

Архитектура программного обеспечения (версия Baidu): структурированный элемент определенной формы, то есть набор компонентов, включая компоненты обработки, компоненты данных и компоненты соединения. Компонент обработки отвечает за обработку данных, компонент данных представляет собой обработанную информацию, а компонент связывания объединяет различные части архитектуры в группы. Это определение фокусируется на различии между компонентами обработки, компонентами данных и компонентами соединения, подход, который в значительной степени сохраняется в других определениях и методах. Благодаря некоторым общим свойствам программных систем эта модель может быть перенесена между несколькими системами, особенно в системы с аналогичными атрибутами качества и функциональными требованиями, и может облегчить повторное использование крупномасштабного программного обеспечения на уровне системы.

Архитектура программного обеспечения (указать версию учебника): Программная архитектура программы или компьютерной системы относится к одной или нескольким структурам системы, включая программные компоненты, их внешне видимые свойства и их взаимосвязи.

Архитектура — это не работающая программа. Это выражение служит трем целям:

1) Анализ эффективности конструкции в соответствии с заданными требованиями

2) Рассмотрите возможные архитектурные варианты на этапе, когда внесение изменений в проект относительно несложно.

3) Снизить риски, связанные с созданием программного обеспечения

архитектурный стиль: изучение и практика стилей архитектуры программного обеспечения облегчают повторное использование проектов, а некоторые проверенные решения также могут надежно использоваться для решения новых проблем. Неизменная часть архитектурного стиля позволяет различным системам совместно использовать один и тот же код реализации. Пока система организована с использованием общих нормативных методов, другие разработчики могут легко понять архитектуру системы. Например, если кто-то описывает систему как модель «клиент/сервер», нам не нужно вдаваться в детали дизайна, мы сразу понимаем, как система устроена и работает.

Вот классификация Гарлана и Шоу общих архитектурных стилей:

1) Стиль потока данных: пакетная последовательность, конвейер/фильтр.

2) Стиль вызова/возврата: основная программа/подпрограмма, объектно-ориентированный стиль, иерархия

3) Независимый стиль компонентов: обмен данными между процессами, система событий.

4) Стиль виртуальной машины: интерпретатор, система на основе правил

5) Стиль склада: система базы данных, гипертекстовая система, система классной доски.

2. Концепция шаблонов проектирования (от Baidu)

отвечать:

Шаблон проектирования программного обеспечения (шаблон проектирования), также известный как шаблон проектирования, представляет собой набор многократного использования, известный большинству людей, классифицированный и каталогизированный, а также сводку опыта проектирования кода. Шаблоны проектирования используются для многократно используемого кода, облегчая понимание кода другими, обеспечивая надежность кода и возможность повторного использования программы.

3. Основные идеи и концепции модульного проектирования (абстракция, декомпозиция, модуляризация, инкапсуляция, сокрытие информации, независимость от функций) (из учебника)

1) Модульность: Идея модульной конструкции состоит в том, чтобы разделить все программное обеспечение на несколько компонентов с независимыми именами или независимым доступом.Эти модули могут быть собраны для удовлетворения потребностей задачи, а большая и сложная программная система может быть разделена на Более простая модульная структура, которую легко понять.

Модульные требования: необходимо соблюдать принцип сокрытия информации, модули независимы друг от друга и стараются соответствовать требованиям высокой сплоченности и низкой связанности.

2) Инкапсуляция: это технология сокрытия информации, пользователь может видеть только информацию об интерфейсе инкапсуляции объекта, а внутренняя реализация объекта скрыта от пользователя. Цель инкапсуляции — отделить использование объектов от производителей. Разделяйте определение и реализацию объекта. Объект обычно состоит из трех частей: имени объекта, атрибутов и операций.

3) Сокрытие информации: детали реализации каждого модуля скрыты (недоступны) для других модулей, то есть информация (данные и процедуры), содержащиеся в модуле, не может использоваться другими модулями, которым эта информация не нужна.

Сокрытие информации: некоторые факторы, которые могут измениться, скрываются в модуле во время проектирования, чтобы повысить удобство сопровождения и уменьшить распространение ошибок.

4. Концепция рефакторинга программного обеспечения UML-моделирование архитектуры программного обеспечения (диаграмма пакетов, диаграмма классов, диаграмма компонентов, диаграмма последовательности, диаграмма развертывания) (из блогов и учебников)

отвечать:

1) Рефакторинг: процесс модификации программной системы таким образом, чтобы улучшить ее внутреннюю структуру без изменения внешнего поведения кода. Это строгий метод очистки кода, чтобы свести к минимуму появление ошибок.

2) Диаграмма пакета (опущена, не важна): разновидность статической диаграммы.

3) Диаграмма классов (выделено): Показывает статическую структуру класса системы, то есть взаимосвязь между классами.

Конкретное значение и способ его нанесения (см. сайт и узнайте)blog.CSDN.net/monkey_'s_…)

4) Компонентный чертеж

Диаграмма компонентов показывает статическую структуру кода, а компоненты кода используются для отображения физической структуры кода.

5) Диаграмма последовательности (выделено)

Используется для отображения порядка отправки сообщений между объектами и взаимодействия между объектами.Пример:

6) Схема развертывания (опущено, не важно)

Представляет физическую организацию аппаратного и программного обеспечения в системе.

Художественный стиль:blog.CSDN.net/Ван Юнся…

5. Концепция интерфейса, принципы объектно-ориентированного проектирования (принцип открытого-закрытого, принцип подстановки Лисков, принцип транспонирования зависимостей, принцип изоляции интерфейса)

принцип открыто-закрыто:

Изменения класса вносятся путем добавления кода, а не путем изменения исходного кода.

Принцип замены Лисков:

Там, где появляется какой-либо абстрактный класс, его можно заменить классом его реализации, который фактически является виртуальным механизмом, а уровень языка реализует объектно-ориентированные функции.

Принцип инверсии зависимости:

Полагаться на абстракции (интерфейсы), не зависеть от конкретных реализаций (классов), то есть программировать против интерфейсов.

Принцип разделения интерфейса:

Пользовательские программы не следует заставлять полагаться на методы интерфейса, которые им не нужны. Интерфейс должен предоставлять только одну внешнюю функцию и не должен инкапсулировать все операции в один интерфейс.

6. Понятие сплоченности и сцепления, общие виды сплоченности и сцепления

отвечать:

«Высокая сплоченность, низкая связанность»

Причина: независимость модуля означает, что каждый модуль выполняет только независимые подфункции, требуемые системой, и имеет наименьшую связь с другими модулями и простой интерфейс, две качественные метрики - связь и связность.

Сцепление также называют межблочным соединением. Относится к мере степени взаимосвязи между модулями в структуре программной системы. Чем теснее связь между модулями, тем сильнее связь и тем хуже независимость модулей. Уровень связи между модулями зависит от сложности интерфейса между модулями, способа вызова и передаваемой информации.

Классификация связи (низкая-высокая): отсутствие прямой связи; связь данных; связь тегов; связь управления; связь общего доступа; связь контента;

1) Нет прямой связи: между двумя модулями нет прямой связи, и связь между ними полностью реализуется через управление и вызов основного модуля;

2) Связь данных: относится к взаимосвязи вызова между двумя модулями, а передача простых значений данных эквивалентна передаче значений языков высокого уровня;

3) Связь тегов: относится к структуре данных, передаваемой между двумя модулями, например, имя массива, имя записи, имя файла и другие имена на языках высокого уровня являются тегами, фактически передается адрес этой структуры данных;

4) Связь управления: когда модуль вызывает другой модуль, он передает управляющую переменную (такую как переключатель, флаг и т. д.), и вызываемый модуль выборочно выполняет функцию в блоке через значение управляющей переменной;

5) Общая связь: относится к связи между теми модулями, которые взаимодействуют через общую среду данных. Сложная программа публичной связи увеличивается по мере увеличения количества связанных модулей.

6) Связывание контента: это наивысшая и наихудшая степень связанности. Когда модуль напрямую использует внутренние данные другого модуля или передает их в другой модуль посредством нештатной записи.

Сплоченность также известна как внутриблочная связь. Относится к показателю функциональной силы модуля, то есть к показателю близости каждого элемента внутри модуля в сочетании друг с другом. Чем более тесно связаны элементы в модуле (между названиями языков и между сегментами программы), тем выше его связность.

Категории связности (низкая-высокая): контингентная связность, логическая связность, темпоральная связность, коммуникативная связность, последовательная связность, функциональная связность,

1) Случайная связность: относится к отсутствию какой-либо связи между элементами обработки внутри модуля.

2) Логическая связность: относится к выполнению нескольких логически подобных функций в модуле, и функция, которую выполняет модуль, определяется параметрами.

3) Агрегация времени: модуль, образованный объединением действий, которые необходимо выполнять одновременно, называется модулем агрегации времени.

4) Связь связи: Это означает, что все элементы обработки в модуле работают с одной и той же структурой данных (иногда называемой информационной связностью), или что каждый процесс использует одни и те же входные данные или генерирует одни и те же данные данных.

5) Последовательная связность: это означает, что каждый элемент обработки в модуле тесно связан с одной и той же функцией и должен выполняться последовательно, а вывод предыдущего функционального элемента является вводом следующего функционального элемента.

6) Функциональная сплоченность: это самая сильная сплоченность, которая означает, что все элементы в модуле работают вместе для выполнения функции, которая необходима. Сцепление с другими модулями самое слабое.

Связность и связность — два качественных критерия модульной независимости.При разделении программной системы на модули постарайтесь достичь высокой связности и низкой связанности, улучшить независимость модулей и заложить основу для разработки высококачественных программных структур.

4. Тестирование программного обеспечения

1. Понятие о тестировании ПО и тест-кейсах;

отвечать:

Тестирование программного обеспечения — это процесс работы программы в определенных условиях с целью поиска ошибок в программе, измерения качества программного обеспечения и оценки его соответствия проектным требованиям.

Тестовый пример — это набор тестовых входных данных, условий выполнения и ожидаемых результатов, написанных для конкретной цели, чтобы проверить путь программы или убедиться, что определенное требование выполнено.

2. Концепции модульного тестирования, интеграционного тестирования, проверочного тестирования, системного тестирования и регрессионного тестирования;

отвечать:

Модульное тестирование: также известное как модульное тестирование, оно направлено на проверку наименьшей единицы (программного модуля) дизайна программного обеспечения. Модульное тестирование проверяет важные пути управления в соответствии с описанием проекта, чтобы найти ошибки в каждом модуле. Модульное тестирование обычно представляет собой тестирование белого ящика, и несколько модулей тестируются параллельно.

Интеграционное тестирование: также известное как тестирование сборки. , Совместное тестирование, после модульного тестирования каждый модуль может работать независимо, но объединение их часто не работает должным образом. Подтверждающее тестирование основано на спецификации требований к программному обеспечению, проверяя, соответствуют ли функции и производительность программного обеспечения и другие функции потребностям пользователя, включая все функции и производительность, предусмотренные в контракте, документации (правильной и обоснованной), других требованиях (таких как как переносимость), совместимость, устойчивость к ошибкам, ремонтопригодность и т. д.).

Тестирование системы: это интеграция программного обеспечения, прошедшего подтверждающее тестирование, как элемента всей компьютерной системы с другими компонентами системы (такими как аппаратное обеспечение, периферийные устройства, некоторое вспомогательное программное обеспечение, данные и персонал и т. д.), а также в фактическая операционная среда. На компьютерных системах выполняется серия интеграционных и проверочных тестов. Целью системного тестирования является выявление несоответствий или противоречий между программным обеспечением и определением системы путем сравнения с определением требований к системе.

Регрессионное тестирование: после изменения старого кода повторное тестирование для подтверждения того, что модификация не привела к возникновению новых ошибок и не привела к возникновению ошибок в другом коде.

3. Понятие отладки, связь между отладкой и тестированием;

отвечать:

Целью тестирования является поиск ошибок, а целью отладки (также называемой устранением неполадок) является определение причины и точного местоположения ошибок, а также их исправление.

Взаимосвязь между отладкой и тестированием: Тестирование и отладка имеют разные цели, методы и идеи. Тестирование — это процесс, целью которого является выявление существующих ошибок в программном обеспечении, обычно реализуемый инженерами по тестированию программного обеспечения. Отладка — это метод, средство, целью которого является поиск причины ошибки и ее устранение.Вообще говоря, действия после тестирования при отладке обычно выполняются инженерами-разработчиками.

4. Концепция тестового покрытия

отвечать:

Оценка тестового покрытия является одним из важных средств для измерения состояния выполнения поэтапного тестирования программного обеспечения, чтобы определить, соответствует ли тест предварительно установленному стандарту выполнения тестовой задачи. Тестовое покрытие — это метод количественного представления при оценке тестового покрытия, который обычно рассчитывается по требованиям к программному продукту, функциональным точкам, количеству тестовых случаев или программных кодов, подлежащих тестированию.

5. Концепция тестирования белого ящика и тестирования черного ящика

отвечать:

Тестирование белого ящика также называется структурным тестированием.Этот метод рассматривает тестовый объект как прозрачный ящик.Тестировщики обращаются к тестовым примерам в соответствии с внутренней логической структурой программы и соответствующей информацией и проверяют, все ли логические пути в программе работают правильно в соответствии с к заранее определенным требованиям.

Тестирование черного ящика также называется функциональным тестированием.В этом методе объект тестирования рассматривается как черный ящик.Тестер вообще не рассматривает внутреннюю логическую структуру и внутренние характеристики программы, а только проверяет, выполняет ли функция программу соответствует ему в соответствии с техническим заданием программы описание функции.

6. Метод расчета цикломатической сложности кода

отвечать:

Цикломатическая сложность — это мера сложности кода. В концепции тестирования программного обеспечения цикломатическая сложность используется для измерения сложности структуры решений модуля, а количество выражается как количество независимых линейных путей, то есть минимальное количество путей, необходимых для разумного тестирования. предотвращение ошибок Программный код может быть низкого качества, его трудно тестировать и поддерживать, и, как правило, возможные ошибки программы во многом связаны с высокой цикломатической сложностью. Его метод расчета: V(G)=e-n-2p. e представляет количество ребер в графе потока управления, n представляет количество узлов в графе потока управления, p представляет количество связанных компонентов в графе (количество компонентов в графе — это максимальный набор связанных узлов) , поскольку все графы потока управления связаны, поэтому p всегда равно 1

V (G) = количество регионов = количество узлов оценки + 1

В(Г)=Р. R представляет количество областей, на которые плоскость разделена графом потока управления.

7. Базовый метод тестирования пути в тестировании белого ящика

отвечать:

Тестирование базового пути — это метод тестирования белого ящика.В этом методе сначала рисуется граф потока управления в соответствии с программой или проектным чертежом, вычисляется количество его областей, затем определяется путь выполнения программы (называемый базовым путем) в группе группы и, наконец, разработайте тестовый пример для каждого основного пути. В практических задачах менее сложная программа может иметь большое количество путей, особенно когда она содержит циклы. Поэтому количество пройденных путей должно быть сжато до определенного предела.

8. Метод деления классов эквивалентности в тестировании черного ящика

отвечать:

Разделение на класс эквивалентности означает, что, поскольку все возможные входные данные не могут быть исчерпаны для тестирования, можно выбрать только небольшое количество репрезентативных входных данных, чтобы выявить как можно больше программных ошибок.Метод деления на класс эквивалентности разделяет все возможные входные данные.Данные делится на несколько классов эквивалентности, а затем репрезентативные данные в каждом классе эквивалентности выбираются в качестве тестового примера.Тестовый пример состоит из представителей допустимых классов эквивалентности и недопустимых классов эквивалентности, чтобы обеспечить целостность тестового примера.и представление.

mg-5OugY4Ha-1607958334409)]

V (G) = количество регионов = количество узлов оценки + 1

[Дамп изображения внешней ссылки...(img-Paxa2fta-1607958334410)]

В(Г)=Р. R представляет количество областей, на которые плоскость разделена графом потока управления.

[Дамп изображения внешней ссылки...(img-wcfd9uYF-1607958334410)]

7. Базовый метод тестирования пути в тестировании белого ящика

отвечать:

8. Метод деления классов эквивалентности в тестировании черного ящика

отвечать: