Давненько я не брал в руки шашек, посему пришла пора написать немного текста на тему практического софтостроения, немного затронув «любимую» тему наживульки (agile).

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

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

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

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

Поскольку маркетинговый шум вокруг ОСА - ориентированной на службы архитектуры (SOA - Servce Oriented Architecture, часто встречается русскоязычная калька СОА) слегка поутих, а жужжащие словечки вроде loose coupling подзабылись, можно обратиться к сюжету на уровне собственно технологии и написать пару абзацев.

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

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

В процессе завязавшейся дискуссии о познании сама собой всплыла ассоциация с проектированием. Сложной и большой системы, разумеется. Которая не укладывается целиком в одной голове. И даже в семи :)

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

"Бросая в воду камешки, смотри на круги, ими образуемые; иначе такое бросание будет пустою забавою" (с) Козьма Прутков

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

Оговорюсь сразу, целью очередной заметки серии не является "очернение светлого образа" сборщика мусора (GC - garbage collector) в средах программирования с автоматическим управлением памятью.

И была дискуссия на тему кризиса в софтостроении. И о сравнении, мол в железостроении все шоколадно. Ну, или почти. А в софтостроении не хватает аналогичного компонентного подхода. И тогда я подумал вот о чем.