Как вы определяете «компонент» в программном продукте?

Question

Мы работаем над стандартизацией нашего приложения Bugzilla для всех проектов. Установка по умолчанию содержит ошибки, сгруппированные в Продукты , которые имеют Компоненты и Версии .

Мы едины в наших определениях Product и Version , но все еще существует некоторая путаница / дискуссия / спор о том, что составляет Component .

Как бы вы определили Компонент в части, касающейся классификации ошибок в проекте?

Answer 1

В целях отслеживания ошибок я бы использовал Компонент для представления областей высокого уровня, с которыми, как правило, работают разные разработчики. Для меня Компонент [в отслеживании ошибок] == Обеспокоенная область .

Например, для вымышленного приложения EventPlanner я бы перечислил мои компоненты как:

• Календарь
• Пользовательский интерфейс
• печать

Обратите внимание, что это может отличаться от того, что я, как разработчик, обычно рассматривал бы программный компонент . Например, мое приложение EventPlanner могло бы использовать Calendar API, но сами «Пользовательский интерфейс» и «Печать» не являются программными компонентами.

Answer 2

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

Например, если продукт переполнения стека, вот некоторые потенциальные компоненты:

• Вопросы * * 1006
• Метки
• Значки
• Профили

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

Answer 3

A хорошее определение , которое будет служить вашей цели.

Answer 4

Я бы определил Компонент, подобный ссылке на ветку кода, например, проект в Visual Studio, который может быть библиотекой классов, консольным приложением, приложением Windows или веб-сайтом / веб-приложением.

Answer 5

Dr. А. Ричард Ньютон из Университета Беркли, который ведет курс под названием «Состояние программного обеспечения на основе компонентов и извлеченные уроки», определяет программный компонент как

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

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

Answer 6

Что бы вы ни интересовали, вам нужно разбить ваши продукты для отслеживания ошибок. Более важно, чтобы это различие было полезным для вас, чем оно было бы «правильным» в соответствии с какой-то концепцией, не относящейся к проблеме отслеживания ошибок.

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

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

РЕДАКТИРОВАТЬ: В ответ на комментарий к другому ответу, эта модель работает лучше всего, если человек, регистрирующий ошибки, обладает необходимыми знаниями о проблеме, чтобы сделать регистрацию. Мы всегда анализируем (сортируемо) сообщения об ошибках и регистрируем их самостоятельно. Если вы оставляете выбор компонентов на усмотрение пользователей, эта идея не очень вам подойдет.

Answer 7

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

Например, класс EmailSender или ErrorLogger и т. Д.