"АРХИТЕКТУРА" и "СТРУКТУРА"

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

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

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

Мы постарались здесь привести РАБОЧИЕ определения, полученные усреднением мнений преподавателей нашей кафедры. 

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

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

Говоря конкретнее о процессе создания информационой системы, уместно сказать, что в соответствии с принципом последовательной декомпозиции и детализации ("нисходящего проектирования", "сверху вниз"...) сначала определяются основные АРХИТЕКТУРНЫЕ особенности создаваемой системы, а затем, углубляя процесс разработки, прорабатывается СТРУКТУРА системы и ее подсистем.

Здесь мы постараемся объяснить, как, по нашему мнению, правильно показывать архитектуру и структуру системы ВИЗУАЛЬНО, с помощью изображений. Рабочие определения таковы:

Картинка "Архитектура системы" - это изображение совокупности разнотипных (к примеру, и аппаратных, и программных) сущностей, составляющих систему, и существующих между ними связей любого типа.

Обычно по изображению архитектуры возможно и удобно пояснять способ функционирования системы, которым она достигает цели своего существования. Кроме этого, очевидно, что архитектуру можно изображать с разной степенью детализации. Вообще говоря, для одной и той же системы можно создать различные изображения ее архитектуры. Бывает, что к приведенному определению добавляют оговорку: "Архитектурная схема не содержит сведений о способах технической реализации подсистем и элементов". Некоторые авторитеты в теоретическом программировании (к примеру, М.Фаулер) дополнительно подчеркивают, что в описание архитектуры системы включаются элементы, "которые не будут изменяться в дальнейшем". Вообще-то постулировать неизменность какой-либо части программного проекта является, с нашей точки зрения, действием рискованным, поскольку серьезные проекты выполняются обычно с применением различных циклических моделей жизненного цикла, а в них потенциально любая компонента проекта может многократно модифицироваться и уточняться.

Картинка "Структура [под]системы" - это изображение совокупности, как правило, однотипных (к примеру, только программных или только аппаратных) сущностей, составляющих систему и связей между ними, как правило, типа "часть - целое".

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

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

Ради полноты процитируем еще одно определение, которое произносилось во время обсуждений этого вопроса в нашем коллективе.
Говорилось так: "Структура - это, якобы, сущности + (связи, несущие информацию о способе реализации подсистем)".

На наш взгляд, подобное определение практически неприменимо. Как трактовать здесь понятие "способ реализации"? Как (по какому признаку) тогда разделить связи на "несущие" упомянутую информацию и "не несущие" оную? В какой степени "несущие"? Вопросов больше, чем ответов.  Ясно, что мы попадаем здесь в порочную последовательность определения "неизвестного через неизвестное", из которой выйти невозможно. Разумнее вообще не становиться на этот путь.


Если хотите что-то добавить или уточнить в этих рабочих определениях, пишите на cranoxy@gmail.com .


Comments