|
2 aag:
Ибо, он, - Репликант - кажется мне наименее ангажированным тем или иным лагерем :)
Как это так, что я наименее ангажированый лагерем?! Такого просто не бывает, чтобы человек, а тем более разработчки не был кем-то (или чем-то) ангажирован. Я, например, приблизительно ангажирован Microsoft на 50%, Rational на 30%, Borland на 15% и еще Sybase - 5%. Это если считать по суммарной стоимости всех средств разработки, использующихся у нас. Вот скажи мне, что Sybase PowerBuilder или IBM VisualAge удобнее, чем тот же VS я соглашусь, конечно, но ангажемент есть ангажемент и его придется соблюдать (т.е ведь в него были уже деньги вложены). Собственно это не имеет прямого отношения к выбору типа арх-ры, но на выбор той же реализации такая ангажированность имеет влияние в реальной жизни :о)
Поскольку на форуме не утихают яростные схватки апологетов той и другой архитектур, может быть Репликант и осветит, какие, по его мнению, требования влияют на выбор архитектуры и какие достоинства/недостатки и той и др. архитектуры для внутрикорпоративных проектов.
((А что значит для "внутрикорпоративных проектов"? Может имелись в виду просто корпоративные проекты , т.е для автоматизации какого-то бизнеса , т.е производственного процесса(ов) заказчика? Ладно, попробуем исходить из этого более понятного всем определения.))
Проблема выбора или процесс (прикладной) определения необходимого типа архитектура на самом деле не такая простая как кажетс, если к ней подходить с позиций ИТ-науки, к-рую я вкратце изложу ниже ч.II.
I. Обычно (будем уж объективны!) тип архитектуры выбирается интуитивно , т.е на основе нескольких простых правил ("шаблонов") . Например, если абстрактно:
1 клиент и БД (локальная) - 1-звенный тип
много клиентов и БД - 2-звенный тип
много клиентов и БД и отдельная бизнес-логика (БЛ) - 3-звенный тип
очень много клиентов и БД и/или отдельная БЛ - 3,4...N-звенный тип
...ну и так далее с вариантами типа Web, типа повышенная надежность БД/БЛ/Web и т.д. Этот пождход неплох, когда дело касается традиционных архитектурных решений, к-рые уже проверенны временем, опытом и разработчик просто знает, что вот эта архитектура (тип архитектуры и т.д) сдюжит кол-во пользователей X, обеспечит функциональность сервиса Y и его расширяемость Z и т.д. Другой вопрос, когда имеешь дело с какими-то НОВЫМИ (например, для себя), сложными , дорогими (т.е предполагающим покупку дорого софта или оборудования) или надежными решениями. Тут конечно неплохо бы убедиться заранее, что выбранная архитектура соответствует требованиям, т.е если не искать эту архитектуру с помощью методологии, то хотя бы обосновать ее выбор
II. Теперь о выборе типа архитектуры с позиций ИТ-науки (программной инженерии) и тех же современных методологий ООAD, SPE и т.д. Прежде всего цель: найти такой вариант архитектуры, чтобы он наилучшим образом удовлетворял нашим условиям или требованиям. Что значит наилучшим образом ? Для простоты допустим, что это значит а) удовлетворять обязательным требованиям и б) удовлетворять наибольшему числу обязательным (желательным) . Все это, конечно, рассуждения "на пальцах", но для грубого объяснения допустимые. Иначе придется привлекать, например, анализ на основе весов (WPA) . Архитектуру, к-рая удовлетворяет заданным условиям наилучшим образом можно назвать оптимальной архитектурой . Напомню, что "архитектура" как понятие является достаточно общим и неопределяемым четко как, например, "счастье" или "народ", но вот классическое определение:
Архитектура программной системы - описывает:
1. структуру: организацию элементов системы и подсистемы;
2. состав: элементы системы и ее подсистемы ;
3. взаимодействие: интерфейсы и поведение элементов системы и ее подсистем;
4. технологию: ......
или в оригиналах: "architecture IS design, structure, infrastructure, technology....and more" и "the work of a single architect." (с) Брукс, Кратчен, Якобсон-Буч-Рамбо.
Понятно, что программная инженерия не дает какой-то универсальной "формулы" или алгоритма "вычисления" типа архитектуры. Только общие (и, конечно, обоснованные) рекомендации относительно тех же модульностей, связанностей, параллельности и т.д Далее..
Методологии проектирования наподобии OOAD (Object-oriented Analysis & Design)
- позволяют, исходя из вариантов использования (ВИ) или функциональных требований
получить архитектуру, в виде модель реализации системы, т.е классы, интерфейсы
и взаимодействие между ними - пп.2-3 в Архитектуре;
Архитектурные шаблоны также позволяют оптимально выделить подсистемы
даже если система достаточно сложная, но тривиальная для шаблона - пп.1-3;
SPE (Software Performance Engineering) - позволяет еще на стадии
проектирования опрделить будет ли система удовлетворять необходимым требованиям
(производительность, расширяемость/масштабируемость) с помощью моделей выполнения
и моделей работы системы;
WPA (Weighed Points Analysis) - позволяет оценить и выбрать под пп.1-3
технологию - п.4;
...
Тип архитектуры можно, конечно, "угадывать" вначале проекта, чтобы быстренько вписать его в то же ТЗ, но это просто а) не нужно и б) рискованно. Лучше его честно получать в процессе проектирования архитектуры, а заодно и обосновывать. В РФ традиционно и в основномй массе коммерческие разработчики не очень грамотные по части проектирования поэтому они также, например, когда составляют ТЗ по ГОСТ 34.602 "забывают", что согласно ГОСТу 34-й серии тому же ТЗ должны предшестовать предварительные исследовательские работы с важным результатом - ТЭО, в к-ром как раз и обосновывывается определенный выбор той или иной архитектуры.
Вот как бы почти "все", если вкратце
2 xGuest:
Ядро mathlab-mapple работает, прямо скажем, небыстро.
И плюс у него, скорее, в функциях символьной математики, нежели в скоростях расчета.
Если задача полностью формализована, то ее быстрее своей программой посчитать, особенно если нужно данные из базы забрать не самым прямым образом.
Все верно! Это я так привел самый относительно легкий по исполнению вариант, к-рый просто лучше, чем математика, считабщаяся в MSSQL. Конечно, самый быстрый вариант - это писать все самому, используя те же GNU С/С++ библиотеки для работы с матрицами
Компоненты, использующие .net framework, из-под SQL Server недоступны.
Другими словами, расширенная процедура не может попользовать функционал и классы framework. Что-то там у них не срослось на системном уровне. Хотел как-то попользовать богатые классы шифрования framework - пришлось обойтись своими силами.
А зачем это нужно - вызов .net из расширенной процедуры под MSSQL? Вызов из .net расширенной в MSSQL это понятно. Просто судя по обычным проектам СУБД функционально используется как пассивное (т.е здесь не имеется в виду, например, репликация или другие служебные процессы для поддержания целостности бизнес-данных) хранилище данных, т.е клиент в самом общем смысле делает запрос и СУБД изменяет/возвращает данные по запросу. А здесь дата-тир обращается к бизнес-тиру, т.е там что-то обсчитывается и складируется обратно в БД?
Кстати, о версиях, если нет возможности централизованно обновлять клиентское ПО, а функциональность его такова, что на БД не повесишь, то опять же среднее звено может выручить, т.к. его немного, а клиентов может быть ну очень много.
Все это понятно, но апологеты (в хорошем смысле!) 2-звенных архитектур скажут, что можно обойтись и без этого, т.к бизнес-логику в БД надо менять в нерабочее время тем более это происходит не так часто. Возможны и варианты, когда можно менять без остановки БД (offline), если преспичет
2 папа Карло:
немного не то имелось ввиду. я имел ввиду что при разработке системы определяют ее архитектуру, а так-же процессы (операционные) которые будут при ее использовании (ты же не делаешь систему которую будет не известно как использовать). следовательно может получиться так, что стоимость поддержки одного сервака будет 100 рублей, а добавление еще одного (операционные затраты) будет 100 руб. 10 коппеек. чем можно принебреч если так позвояют требования. так что мы немного про разные вещи говорим.
Да нет же, мы говорим про одни и те же вещи! Тип архитектуры, т.е N-звенность, конечно(!!) определяется также и из затрат на сопрвождение (TCO). Например, введение того же Web-тира подтребует "Web-администратора". Даже если он и будет одновременно в одном лице ДБА и сисадмином, то все равно забот у него прибавится порядочно особенно, если Web-тир еще и публичный, т.е Инете. Другое дело, что сам по своему опыту знаю, что заказчики обычно "забивают" на рекомендацию 2 админов и ТСО, считая, что вот у них ДБА и так уже есть, так пусть он еще за одно и Web администерит. Потом через 2 мес. выясняется, что пришлось нанять еще 2-го админа. И начинаются якобы "невинные" возмущения, что мол "вот, почему вы нам не сказали, что затраты на сопровождение вашей системы требуют еще +6000$ в год?!".
2 папа Карло & ASCRUS:
А с чего вы решили что инструменты не могут быть оговорены в требованиях тоже? например мне выставлено было требование построить террабайтную базу с откликом не более 10 секунд на _все_ запросы и 1-2 секунды на 80% запросов на скл сервере. я к тому моменту знал как это сделать в оракле и страшно его защищал потом мне сказали. скл сервер -- требование, оракла не будет.
Позволю себе немного поправить: MSSQL/Oracle - это не инструменты , это скорее часть "платформы" или подсистема (СУБД). Такие подсистемы как MSSQL обычно кажется называют коробочными (boxed или commercial-off-the-shelf (COTS)) или готовыми к пользованию (ready-to-use) . ((Не понятно зачем все эти названия одинаковые по смыслу объяснил бы кто.))
Средствами производства (разработки) инструментами являются те же Word (для создания проектной документации), Rose или PowerDesigner (для проектирования приложения и БД), VS или Delphi (для написания и отладки кода) и т.д. Хотя СУБД тоже можно назвать "инструментом достижения цели". Что же касается инструментов, то они тоже могут быть оговорены и в ТЗ. Хотя, например, в том же ГОСТ 34.602 нет такого раздела явно, но по своему опыту могу сказать, что в 50% случаев заказчик хочет или прямо настаивает на опрделенных инструментах особенно если он получает исходные тексты и планирует сам поддерживать систему. Были и случаи, что только VB и все тут
-----
З.Ы. Господа, не спорьте! Как люди опытные присоединяйтесь к обсуждению того, что влияет на выбор архитектуры. Все ж для общей пользы :о)
|
