Журнал «Компьютерра» № 16 от 25 апреля 2006 года
Шрифт:
Если этот подход предложил автор, то как быть со статьей Harrison W., Ossher Н. Subject-Oriented Programming (a Critique of Pure Objects)/Proceedings of OOPSLa’93, стр. 411-428, первое слово в названии которой может быть переведено как «Субъект»? Если принять такой перевод, то название обеих статей полностью совпадает, и новизна работы становится неочевидной. Более того, ряд статей по этой тематике опубликован на сайте www.research.ibm.com/sop/soppubs.htm.
Я тоже однажды написал статью, название которой совпадало с одной из разновидностей программирования, предложенной в Западной Европе, – синхронном программировании. Статья преследовала цель впервые на русском языке изложить суть публикаций по этой тематике, а список источников исключал
Так что ссылайтесь на предшественников, и все резко упростится.
Это особенно актуально, так как в обсуждаемом номере «Компьютерры» редактором номера, во избежание проблем, был введен список использованной литературы даже в редакторской колонке. Оказывается, с потенциальными проблемами можно бороться, и это так просто делается.
Анатолий Шалыто
Доктор технических наук, профессор
Прежде всего, необходимо поблагодарить доктора технических наук, профессора Анатолия Шалыто за проявленный интерес к моей статье, что, в свою очередь, послужило поводом еще раз коснуться темы субъектов в мире программирования, попутно расставляя точки над i.
Целиком и полностью поддерживаю автора заметки в претензии на то, что российские авторы, и не только российские["Известно, что многие американские ученые не читают иностранных работ и считают наукой только то, что публикуется в американских журналах… Заметим, что, когда это выгодно, американцы проводят весьма тщательный скрининг литературы" В.А. Ратнер, проф., д.б.н., академик РАЕН, ИЦиГ СО РАН, Новосибирск, «Впереди событий и в стороне от признания», Вестник ВОГиС №4 за 1998 год., www.bionet.nsc.ru], не любят ссылаться на используемые источники. Это действительно ощутимо бьет по научному обществу, где каждая публикация и даже ссылка на счету, где идет жесткая конкуренция за приоритеты, научные звания и гранты. Поэтому зачастую специализированные издания предъявляют более высокие требования к терминологии и ссылочной полноте материала, нежели к его содержимому. В популярных же изданиях акцент делается на доступность содержания, а если встречается специализированный термин, без которого нельзя обойтись, то здесь необходима ссылка для разъяснения термина и его происхождения. На мой взгляд, редакция журнала старается этого придерживаться! Кстати, в защиту авторитета издания, именно редакция «Компьютера» дала развернутую ссылку об автоматном программировании. Поэтому благодарность за добрые слова, сказанные об А. Шалыто, в первую очередь относятся к редакции журнала.
Спешу успокоить научную общественность: концепция SOP, упоминаемая в источниках, имеет другое содержание, несмотря на совпадения в терминологии. Честно говоря, не хотелось бы вот так просто отдавать наиболее подходящий по смыслу для русского языка термин «субъект» при описании данного рода программ. В словаре С. И. Ожегова слово «субъект» однозначно определяется как философское понятие, мыслящее существо – человек. Переводя на английский[Русско-английский, Англо-русский словари. – Мн:. Харвест; М:.ООО «Издательство АСТ», 2001], русскоговорящий человек ассоциирует это слово с наиболее созвучным – Subject. А англоязычные люди под Subject в первую очередь подразумевают[Там же]: тема, содержимое, предмет изучения и только на 6-м и 8-м местах оно может означать то, что однозначно понимается под словом субъект в русском языке.
Чем руководствовались создатели, называя свою технологию Subject-Oriented Programming? В первую очередь под этим термином подразумевался ориентир на поставленную задачу, но никак не наше философское – «субъект», самостоятельно осязающий окружающую среду и наделенный правом самостоятельно выбирать путь для дальнейших действий.
Итак, чтобы за спорами о терминологии не потерялась идея, о которой шла речь в моей статье, заострю внимание на следующем:
1. Если ознакомиться с содержанием статьи «a Decorator Implementation Using Subject-Oriented Programming», John Vlissides,
2. Метод, рассматриваемый в статье, разрабатывал я сам, опираясь на собственный 25-летний опыт практического программирования.
3. Мне бы хотелось сохранить русскоязычное название данного метода, а чтобы не создавать казуса, предлагаю переводить название как Being-Oriented Programming. Being – существо; считаю, что это более подходящее определение на английском языке.
P.S. Наиболее подходящим базисом для развития этой идеологии, как позднее выяснилось, является технология SemP-T®, «Российским НИИ искусственного интеллекта», которая была разработана под руководством Ю.А. Загорулько для моделирования сложных процессов. Ее появление еще раз подтверждает правильность и естественность применения описанного способа программирования для сложных информационных систем. И в этом была главная идея моей статьи.
Александр Петриковский
Руководитель проектов ООО «ИндаСофт»
ТЕХНОЛОГИИ: Как сделать успешный ERP-проект
Автор: Дмитрий Мартынов
Это незапланированное продолжение статьи Дмитрия Мартынова посвящено тому, как должен вести себя руководитель предприятия, решивший перевести бизнес на ERP. Автор не только дает рекомендации директорам, но и объясняет, почему внедренцы зачастую игнорируют пожелания рядовых пользователей, превращая и без того непростой процесс перехода с одного программного пакета на другой в настоящие хождения по мукам. По-хорошему, эту статью нужно было бы сопроводить рассказом невинной жертвой внедрения, но у нас такого материала нет, а на установку ERP редакция пока не заработала. Так что если кто-то из читателей решит поделиться своим опытом – будем очень благодарны. – В.Г.
Одна из главных проблем внедрения ERP заключается в том, что система нужна прежде всего генеральному директору, тогда как все остальные в ее внедрении не заинтересованы. Поэтому если руководитель предприятия отстраняется от процесса внедрения – а это очень естественный жест, если учесть, что формально ERP – всего лишь набор технических решений и относится к компетенции ИТ-специалистов, – то ни к чему хорошему это не приведет.
В таблице 1 условно показано влияние участия руководства на результаты проекта.
Как видно из таблицы, фактор участия руководства на этапе внедрения является более существенным, чем качество предпроекта (о контроле качества предпроекта см. предыдущую статью в «КТ» #628). Даже плохо сделанный предпроект можно вытянуть и превратить его в работающую систему.
Многие системные интеграторы риск пассивности руководства Заказчика ставят на первое место. Однако в чем суть этого участия – тайна за семью печатями. Любой консультант незамедлительно ответит, что руководство должно обеспечивать проект необходимыми ресурсами (под которыми подразумевается прежде всего оплата услуг самого консультанта). Оставим финансовые взаимоотношения фирмы с внешними консультантами за рамками статьи и попробуем разобраться в том, какими другими важными ресурсами директор может поделиться с проектом, если его волнует результат.
Внедрение ERP, несомненно, влияет на практику ведения бизнеса в компании, и иногда это влияние можно оценить. Но один из главных бизнес-эффектов – повышение управляемости компании – подсчету не поддается. Именно этот эффект и отличает ERP от других бизнес-приложений (CRM, SCM, MRP и пр.), каждое из которых заточено под решение конкретных бизнес-задач, тогда как ERP охватывает все бизнес-процессы и дает обобщенные и детальные отчеты по каждому направлению деятельности компании.