Что такое Архитектура ПО?

[Emelian]

А что Вы думаете?

То, что в обобщенных статьях мы все любим общие слова, вместо демонстрации своих идей в конкретных демо-проектах.

Хорошо, как говорил товарищ Сталин: «Критикуешь – предлагай! Предлагаешь – выполняй!». Т.е., можно сказать, что вы даёте повод для написания статьи об архитектуре собственной программы, относительно несложной, но достаточно неочевидной для реализации.

Таковой для меня является моя обучающая (иностранным языкам) программа: «L'école». Я себе чуть мозги не сломал, пока не получил её, более-менее, рабочую версию. При этом, она, естественно, как «первый блин комом», не оптимальна. Поэтому, вполне достойна для разбора на предмет архитектуры, оптимизации и добавления новых «улучшизмов».

Если говорить о начальном этапе работы «архитектора» этой программы, то, после утряски ее концепции, выбора инструментов разработки и определения программной логики, например, теоретически, в процессе согласования проекта с заказчиком («Любой каприз за ваши деньги!»), я бы начал с демонстрации структурного прототипа или шаблона этой программы.

Иначе говоря, архитектор должен предъявить нулевую итерацию проекта для своей команды. В моем случае, я бы дал шаблон оконного SDI-приложения, на C++ / WTL.

В этом шаблоне, можно сразу дать структуру меню, тулбар или командбар и статусбар. Также, добавить «горячие» клавиши и перегрузку видов (дочерних окон).

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

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

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

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

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

0. Использование сохраненных настроек программы при её запуске и их запись при завершении работы.

1. Графика (вывод различных фоновых изображений и логотипов для различных режимов работы и выбранных иностранных языков).

2. Звук (получаемый из блоб-поля файла базы данных, формата SQLite либо какие-нибудь тестовые образцы).

3. Отображение статического текста в клиентской области окна, с возможностью масштабирования, при изменении размеров приложения.

4. Динамическое отображение текста и озвучки, с помощью сообщений таймера (для режима «Видео»). Этот модуль зависит от работы предыдущих.

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

6. Работа с данными, в зависимости от выбранного режима (выборка, обработка и их сохранение, при необходимости).

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

8. Использование мультиязычного интерфейса программы.

9. Подготовка обучающих (файлов) данных (компьютерных уроков) вне основной программы.

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

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

Вот, примерно так, я хотел бы выстроить свою статью на эту тему. Да, многие захотят всё сделать по-другому. Добавить «кромплатформу», «мобильность» либо ограничиться веб-версией, использовать другие фрейморки и инструменты разработки. Но, кто против? Главное, чтобы было больше конкретики при демонстрации каких-то глобальных идей. А не как в анекдоте: «Сова: Ёжики – станьте птицами! – Ура! А как? – Отстаньте, глупые! Я не тактик, а стратег!».

P.S. Ну, а я пошел ваять статью на эту тему.