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

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

Организация программы

Системная архитектура требует обзора, который описывает систему в общих чертах.

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

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

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

У каждого блока должна быть одна зона ответственности, и не должны отображаться детали каждой части.

Основные классы

Если мы хотим работать над реализацией, нам нужно больше деталей в нашем дизайне.

У нас должны быть основные классы, которые мы хотим иметь в окончательном решении.

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

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

Желательно показать 80 процентов поведения на нашей диаграмме.

Дизайн данных

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

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

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

Бизнес правила

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

Дизайн пользовательского интерфейса

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

Мы должны указать основные элементы дизайна, такие как макет, пользовательский интерфейс, интерфейс командной строки и т. Д.

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

Управление ресурсами

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

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

Безопасность

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

Есть много видов атак, поэтому мы должны подумать, как их предотвратить.

Представление

Если наша программа потенциально неэффективна. Затем нам нужно подумать о том, как сделать его работоспособным в нашем архитектурном документе.

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

Масштабируемость

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

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

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

Совместимость

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

Интернационализация / локализация

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

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

Локализация - это перевод программы для поддержки определенного местного языка.

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

Ввод, вывод

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

Обработка ошибок

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

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

Поэтому нам нужно подумать о том, как обрабатывать ошибки.

Мы просто обнаруживаем ошибки или исправляем их? Как следует распространять ошибки? Каковы правила обработки сообщений об ошибках?

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

Заключение

Есть над чем подумать - от общего обзора и обработки ошибок до интернализации.

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