| Георгий |
| Отправлено: 28.06.2003, 18:43 |
|
Почетный железнодорожник
Группа: Модератор
Сообщений: 874
|
собственно интересуют методы и средства:
1 проектирования и ведения проектной документации
2 разработки и документирования процесса разработки
3 тестирования и документирования процесса тестирования
4 исправление обнаруженных дефектов и документирования процесса исправления
есть подозрение, что меня отошлют к ЕСПД и ЕСКД, на я ничего свежее 1989 года не видел, да и эти документы не совсем отражают реальную жизнь.
сам я до недавнего времени писал программы по принципу — "да тут всё очевидно — тут пишем так, а там этак", т.е. никаких бумаг не велось — всё в голове держал, а потом забывал...
У этого подхода есть плюсы:
1. если повезёт — то отсутствуют затраты на явное проектирование => высокая скорость работы (эээ... моей работы, а не того, что получится...)
2. работы без меня продолжить не возможно — никто не знает как ЭТО работает и что надо дальше делать => я гарантировано получу все заработанные деньги и полный контроль над ПО
но есть и минусы:
1. практически нулевая повторная используемость кода, который будет получен в результете такой работы.
2. если разрабатывать не всю программу, а только её часть (модуль), то, разработанный таким образом, он никому не будет нужен => за него не заплатят (а если и заплатят, то ещё один не у меня будут заказывать)
Было бы не плохо, если по аналогичной схеме опишу другие методы создания ПО.
может Владимир даже статью сможет сделать |
|
| Admin |
| Отправлено: 29.06.2003, 16:59 |
|
Владимир
Группа: Администратор
Сообщений: 1190
|
Не уверен что в реальной жизни это нужно.
(в реальном программировании)
Например, есть мощная бухгалтерская система Парус,
документация к ней — куча книг, но в них все настолько бестолково и
запутано, что разобраться с ней просто нереально.
Также и много других подобных систем.
| QUOTE |
практически нулевая повторная используемость кода, который будет получен в результете такой работы
|
Почему ? Ведь это код у вас остается, как в голове, так и в компьютере,
используйте на здоровье. Или оформите в виде функций, и в свою lib
и присоеденяйте к очередному проекту, или в виде фреймов или dll,
или в виде компонента.
| QUOTE |
работы без меня продолжить не возможно — никто не знает как ЭТО работает и что надо дальше делать => я гарантировано получу все заработанные деньги и полный контроль над ПО
|
Абсолютно нормально.
| QUOTE |
если разрабатывать не всю программу, а только её часть (модуль), то, разработанный таким образом, он никому не будет нужен => за него не заплатят (а если и заплатят, то ещё один не у меня будут заказывать)
|
Как и советовал — оформите свой модуль в виде dll и предоставьте
только вызов функций из нее, (+ можете засунуть в него и проверку
авторских прав и др.)
|
|
| Георгий |
| Отправлено: 29.06.2003, 19:29 |
|
Почетный железнодорожник
Группа: Модератор
Сообщений: 874
|
мне почему то везёт на не большие диспечерские системки — но каждый раз приходится заново писать, хотя чётко прослеживается фактически идентичная структура ПО:
1. блок опросов оборудования (отдельный поток)
2. интерпретация показаний датчиков
3. БД (подсистема хранения данных)
4. механизм оповещений и протоколирования
5. система отображения данных и взаимодействия с пользователем (тут BCB хорошо помогает)
причём структуру ПО можно описать такой матрицей смежностей:
1 — 2
2 — 3
2 — 4
4 — 3
5 — 3
т.е. у меня все связи идут через БД и при выходе из строя БД (или машины с БД) рушится вся система, да и система разграничения прав (ну там оператор, директор,администратор, разработчик) реализуется только в виде надстройки (и легко ломается)
но тут в одну контору ездил, которые тоже диспечерскую систему разработывают — и посмотрел её структуру — у них не БД центральный элемент а есть система управления блоками (по одному экземпляру на физическую машину) т.е. у них преобладают вертикальные связи, причём строго вертикальные, это позволяет им очень легко масштабировать это ПО (даже не ПО, а АСУ) в зависимости от конкретных потребностей, что в моём случае даётся со скрипом (путём переписывания ПО). а также хорошая отказо-устойчивость — при выходе из строя одного блока другие могут сами (автоматически) переключиться на резервный, что у меня просто не предусмотрено, да и добавить очень сложно...
Вот и возникло у меня желание выполнять проектирования ПО по аналогии с интегральными схемами:
1. принципиальная схема — отражающая принципы соединения блоков
2. разработка или выбор структуры блоков
3. функциональная схема — уже оговариваются протоколы связи блоков, можно оценить стоимость и время разработки, а также масштабируемость и надёжность
4. раздача ТЗ на блоки конкретным исполнителям, которые автономно работают и не нуждаются в дополнительной информации (ну это если #3 качественно сделан)
5. компоновка блоков — в схемотехнике с этим проблемы есть (размещение, компоновка, трассировка), но в программировании связи между блоками ничего не стоят и друг на друга влияют только при не качественном #3
6. тестирование готового продукта
при изменение потребностей заказчика достаточно написать N новых ТЗ и повторить шаги с 4 по 6, а т.к. основная часть системы не будет меняться, то и трудозатраты на эти изменения значительно ниже, чем в моём случае. А в большинстве случаев нужно будет только 2 ТЗ:
1. на новые оконные и печатные формы
2. на новый блок интерпретации показаний датчиков
всё остальное идёт без существенных изменений (может придётся связи чуть чуть поправить)
а вот разработчики новых #1 и #2 уже и будут использовать свои наработки и то, что у них в голове остаётся, но это не решает глобальную задачу повторного использования.
Borland CBuilder позволяет легко и не принуждённо проектировать (но без документирования, в отличии от JBuilder) GUI, но не общую структуру ПО. Тут увидел вопрос про CORBA — вот и подумал — компонентная модель уже давно существует, а средств проектирования компонентной модели я не видел... Вот так и возник мой вопрос. |
|
| Art |
| Отправлено: 25.07.2003, 14:10 |
|
Не зарегистрирован
|
Есть такая офигенная штука: Rational Unified Process (RUP). А если его много, есть упрощённый процесс Iconix. |
|
| Георгий |
| Отправлено: 25.07.2003, 18:07 |
|
Почетный железнодорожник
Группа: Модератор
Сообщений: 874
|
А где её "напосмотреть" взять можно? |
|
| Young Coder |
| Отправлено: 25.07.2003, 21:03 |
|
Дежурный стрелочник
Группа: Участник
Сообщений: 34
|
За моя бытность, а я бывший директор софтверной компании (15 программистов, 4 вебдизайнера, еще несколько человек на подхвате), так вот, весь написанный софт, а это примерно полторы сотни проектов и програм, от софта до сайтов, никогда не документировался. Софт писался по типу: "во.. я могу нахерачить такую шнягу.. реально.." и херачил прораммист. и ему помогал другой, третий..
Все прогри писались одним человеком, максимум двумя (например клиент-сервер) поэтому если вдруг кто-то думал увольняться — весь его проект можно было выкинуть в ведро.
Причем сами программисты были очень толковые.. и продукты планировались толковые.. только до рынка они (продукты) не доходили.. нет.. вру, один дошел.. но так как никто продавать его не умел — он так и лежит на винте. А вообще на моем винте СТОЛЬКО написанного живыми людьми кода.. что если бы нормальный проджект-менеджер с самого начала нормально вел всех по правильному пути, то мы бы давно виндувс какой нить написали... (типа того).
Отсюда мораль для заказчика:
1. заказывать по возможность безотносительные модули
2. тестировать их отдельно
3. просить документировать обязательно
-- это только то, что сразу на ум пришло...
Мораль для программиста:
1. если зарплата тебя устраивает, то УЧИСЬ, УЧИСЬ и еще раз УЧИСЬ.
Потому что вероятность того, что твой код будет востребован очень мала. Даже если ты пишешь под заказ, то особо на этом заказе не заработаешь. Потому чем больше знаешь (учишься) тем ты ДОРОЖЕ стоишь. Значит ты имеешь шансы устроится туда где твой код так же будет не очень востребован, но зато ты получишь бОльшую зарплату.
2. Если у тебя нет зарплаты, т.е. ты самоучка и сидишь дома программишь или работаешь в компьютерном клубе администратором но игры тебе надоели и занялся ВСВ, то БЕГОМ в интернет, читай две вещи:
а — те форумы где пишут про вопросы программирования, на них реально найдешь то, что в help'е написано "непонятно".
б — те форумы где можно найти заказчика. Да, да.. именно.. тебя должны интересовать все форумы где можно найти вопросы топики типа "Срочно нужен скрипт, програмка, программист". Общайся с людьми. Ибо заказчика надо знать в лицо.
Умение программить — еще не означает владение толстым кошельком, надо уметь продавать свой софт.
P.S. Я много могу говорить, поверьте опыт у меня есть. А отрицательный опыт — он еще дороже. Если есть вопросы — обращайтесь. 
|
|
| Георгий |
| Отправлено: 25.07.2003, 23:33 |
|
Почетный железнодорожник
Группа: Модератор
Сообщений: 874
|
Young Coder вот как раз то, что ты написал в 1-м абзаце меня и волнует:
- когда надо что-то конкретное сделать делается "во.. я могу нахерачить такую шнягу.. реально.." (сам по такому принципу писал)
Этот подход имеет место в случае штучного ПО (в смысле больше одного экземпляра ПО и не надо — обычно это встраиваемые системы) которое разрабатывается фирмой или в случае практически любого ПО, но уже с точки зрения программиста (обычно платят за результат, а не за "мифическую" масштабируемость и гибкость кода, особенно, если реализация всего этого требует увеличения времени работы в 1.5-3 раза, а результаты будут видны чёрт знает когда...), что в последствии приводит в повтороной разработке одного и того-же...
И тут обнаружилось, что нет методов (по крайней мере известных мне), которые позволяли бы оценить проект, выполнить поиск аналогов (в т.ч. и на модульном уровне) ещё до серьёзных затрат на выполнение работ. Поэтому я и сделал попытку провести аналогии между этапами разработки цифровой схемы и этапами разработки программ.
Этапы разработки
Цифровая схемотехника:
1. ТЗ — где коротко и ясно написано чего хотят на выходе и в каких условиях это должно работать
2. выбор алгоритмов для решения логической части задачи (для процессора — это алгоритмы умножения, сложения; для контролера HDD — это поиск сектора, дорожки, коррекции ошибок), на основе поиска аналогов или разработки своих уникальных алгоритмов.
3. т.к. алгоритмы известны — уже есть представление что и в каком виде будет на входе в схему и на выходе, а также ключевые моменты внутренного устройства — количество функциональных блоков, их тип, функции, связи и т.п. в результате рожается принципиальная схема (как следует из название — на ней отображён принцип работы)
4. на основе принципиальной схемы строится функциональная — уже с конкретными узлами (выбирается разрядность регистров, сумматоров MUX и т.п.)
5. паяется схема (конечно грубо сказано, но, ввиду автоматизации с использованием различного ПО, не вижу смысла перечислять тонкости компоновки, размещения, трассировки и ещё чего-то).
создание ПО:
1. ТЗ — такое ощущение, что пишется по принципу или сказать всё, что только можно (получается книжка на 30-50 страниц) или "сделай то, незнамо что и непонятно зачем, но обязательно сделай". Эту беду можно исправить став тенью заказчика и путём внимательного наблюдения за его нуждами составить правильное ТЗ (конечно правильное оно только для себя любимого...)
2. выбор алгоритмов... какие нахрен алгоритмы — тут всё и так ясно — тут такая функция, а тут будет вот такое показываться и в томже духе... писать надо, а не думать 
3. на основе смутных представлений пункта №2 что-то делается, но, что именно делается понятно только тому, кто это делал...
4. это нечто сделано и даже (на первый взгляд и тестирование в режиме пробной эксплуатации) выполняет заявленные функции.
Но давайте посмотрим, что будет, если надо что-то поменять в исходных данных.
Цифровая схемотехника:
1. ТЗ на доработку (на разработку чего-то очень похожего на уже разработанное или исправление ошибок)
2. путём выяснения различий между уже выполненными ТЗ и вновь прибывшимы определяется реальный обьём работ и необходимые алгоритмы
3. из кусков уже имеющихся принципиальных схем составляется новая схема, разрабатываются блоки сопряжения модулей
4. разработка функциональных схем блоков и блоков уникальных (обьективно уникальных) для этого проекта
ПО:
1. -----||-------
2. что и с чем сравнивать, если есть только очень общие представления о том, как имеющиеся программы работают? какой обьём работ? одни вопросы... (вариант с тем, что кто-то наизусть помнит все разработанные программы и их структуру я не рассматриваю)
3. в лучшем случае можно повторно использовать некоторые ранее разработанные модули
4. разрабатывается программа фактически заново (небольшие вкрапления ранее разработанного кода не всчёт)
В чём спрашивается разница между ПО и аппаратурой:
В безответственном подходе?
В том, что для создания конечного продукта надо написать слово из 4-х букв make в _nix системах или нажать F9, а не тратить деньги?
У меня ответа нет...
Но есть предложение как это исправить:
1. дать всем по шее и сказать "штоб усё было задокументировано — начиная от выбора алгоритмов решения задачи, до рисования блок-схем конкретных функций"
2. дать "детям" новую игрушку — рисовалку, где можно нарисовать схему программы, обозначить процессы, связи между ними и дойти до уточнения прототипов функций и интерфейсов обьектов.
К сожалению выриант №1 с истинными программистами не пройдёт по обьективным причинам (им всё пофиг, кроме процесса программирования), а №2 не осуществим ввиду отсутствия рисовалки...
PS. я ещё не посмотрел Rational Unified Process — может это и есть рисовалка моей мечты?
Ещё раз кстати — абзац "мораль для программиста" основывается на способности к обучению программиста с целью решения задач фактически заново, но аналоги и готовые решения существуют в голове у этого программиста т.е. пункты 2-3 относительно ПО программист решает в голове, но рано или поздно она не справляется с обьёмом информации и проект или гибнет, или прекращает развитие, или превращается в нечто монстрообразное, увешанное ненужными придатками, которые боятся удалить — вдруг они где-то используюстся? Мне кажется, что это ещё раз подтверждает мою мысль о необходимости разработки и документирования процесса разработки ПО, а не кодировании...
PPS. попробую я свой нынешний проектик документировать — посмотрю, что мой новый начальник скажет |
|
| Admin |
| Отправлено: 26.07.2003, 15:17 |
|
Владимир
Группа: Администратор
Сообщений: 1190
|
Вообще судя по иностранным книгам,
у них там должность такая есть — системный аналитик.
(кажется примерно так называется, посмотрю, уточню)
Сначала он приходит на предприятие и анализирует
потоки информации, движение документов, продукции и др.
и составляет что-то типа блок схемы движения этого чего-то:
от входящей документации до исходящей,
от поступления сырья до выхода готовой продукции,
все движения и все перемещения,
он даже разрабатывает необходимую схему базы данных
предприятия (фирмы) с таблицами и полями и связями.
Но программирования он не знает совершенно !
А уже потом за работу берется программист,
на основании данных аналитика.
По всей видимости эта работа аналитика Вас и интересует.
Разумеется в наших условиях (да и за рубежом тоже)
всем этим обычно занимается сам программист, часто совместно
с неким дядей(тетей), сотрудником предприятия, на которого
возлагается работа все объяснить программисту, откуда ноги растут,
у которого (дяди) и так полно своей работы и отрывается на эти объяснения он часто неохотно.
Кстати, много лет назад, программируя на ДВК-2М я написал
(от нечего делать, изучая так сказать ассемблер)
на АССЕМБЛЕРЕ программу — учет кадров нашего предприятия !
И директор потребовал задокументировать каждую строчку !!!!!! 
Представляете ?
И я и мой начальник (отличный мужик, все понимал) полдня
валялись на полу от смеха.
А потом еще 2 недели — когда писал комментарии, что делает
каждая строчка программы на ассемблере.
|
|
| Admin |
| Отправлено: 28.07.2003, 09:42 |
|
Владимир
Группа: Администратор
Сообщений: 1190
|
Вот, нашел.
| QUOTE |
Определение стратегии.
Первое, что делает руководитель нового проекта — это организует
обследование системы. Главные задачи такого обследования — оценка
действительного объема и цели проекта, а также получение опреде-
лений сущностей и функций на высоком уровне. Успешного результата
можно добиться лишь путем привлечения опытных,
высококвалифицированных ьизнес-аналитиков, имеющих постоянный
доступ к высшему руководству фирмы. Именно высшее руководство
будет утверждать фонды на последующие этапы проекта, поэтому
необходимо тщательно фиксировать его требования к конечным
результатам.
...
Теперь после определения объема и сметы переходят к этапу анализа.
Анализ
Этап анализа — это подробное исследование бизнес-процессов
(функций) и информации, необходимой для выполнения этих
функций (сущностей с их атрибутами и отношениями)
* — то есть таблиц, полей и связей между полями в таблицах
...
Многим программистам совершенно непонятно, почему самые талантливые аналитики не способны писать программы
(даже несмотря на то, что они обычно утверждают, что при необходимости смогут сделать это). Причина проста: их неспособность разработать программу обуславливается тем, что в процессе анализа они не тратят время и силы на выяснения того, как спроектировать систему.
Аналитики собирают и фиксируют информацию в двух разных, но
взаимосвязанных формах.Это:
функции — информация о событиях и процессах, которые происходят
сущности — информация о "вещах имеющих значение для организации,
о которых что-то известно"
Вот два вида классических результатов анализа:
иерархия функций, которая разбивает процесс обработки на функции,
или вещи которые делаются
модель "сущность-отношение", охватывающая все сущности, их
атрибуты и отношения между ними.
Проектирование
В маленьком по масштабу проекте аналитики, проектировщики
и разработчики могут быть одними и теми же лицами (или лицом)
...
Проектировщик берет выходные данные анализа и выдает:
определение (или схему) базы данных — на основании модели сущностей
разработанной на этапе анализа;
набор спецификаций модулей — построенных на базе моделей функций
Реализация
По завершении исходного проектирования следует этап реализации,
на котором создаются и тестируются программные модули, опреде-
ленные при проектировании.
....
Важно понимать, что вплоть до запуска системы в эксплуатацию вам
придется постоянно возвращаться к этапу проектирования и анализа.
....
Журнал проектирования.
Следует подчеркнуть важность регистрации всех вопросов,
возникающих в процессе проектирования системы. Нужно регистри-
ровать все обсуждаемые варианты, варианты, которые учитывались и
окончательные решения. Эту информацию можно хранить в
CASE — репозитарии, в документах текстового процессора, в текстовых
файлах и даже на бумаге.
...
Журнал проектирования — отличный материал для изучения новыми
членами группы, будь то проектировщики, разработчики, тестировщики
или руководители. Ознакомившись с ним, они быстро поймут техничес-
кие особенности проекта.
..."
|
---------------------------------
Более подробно — в книге
"Проектирование баз данных Oracle" Дейв Энсор, Йен Стивенсон (BHV)
там именно о проектировании баз данных, но это полностью подходит
и к разработке и написанию программ без баз данных.
----
Теперь от себя:
Инструменты проектирования и CASE — средства разработки -
ERwin и BPwin (см книгу С.В. Маклакова в разделе "Литература"),
и на диске они есть "CASE и СУБД технологии"
(скоро выложу описание в раздел "Диски")
(или на других дисках на компьютерных рынках их можно найти)
также есть и другие CASE-инструменты.
BPwin — Business Process Design. Мощный инструмент моделирования,
используемый для анализа, документирования и улучшения комплексных
бизнес процессов.
ERwin — инструмент проектирования баз данных, помогающий
проектировать создавать и обслуживать базу данных.
|
|
| Георгий |
| Отправлено: 28.07.2003, 22:14 |
|
Почетный железнодорожник
Группа: Модератор
Сообщений: 874
|
Да Владимир это ответ на то, что я пытался спросить, но постоянно не мог перейти от деталей к обобщению и к чёткой формулировке вопроса.
Действительно модель сущность-связь позволит представить структуру любого проекта (думаю даже такого монстра как MS Windows), единственная сложность — это абстрагироваться от конкретного представления сущностей и считать, что сущность это не конкретный обьект (ну там товар, человек, отдел) как в случае БД, а нечто ещё не существующее (обьект, функция, модуль) и возможно никогда не существовавшее как при обычном программировании. Но тут поможет Журнал проектирования в котором небольшой коллектив фантазёров (в хорошем смысле этого слова) будет фиксировать свои идеи, возникающие на этапе анализа и проектирования, а потом по этому журналу отвечать на вопросы программистов ("а на х.. это надо?" "а тут проще ваттак сделать"), которые будут это всё реализовывать и, в свою очередь, делать в журнале пометки для потомков.
А потомки перед тем, как за новый проект браться, смогут поискать аналоги не в горах кода, оставленном предшественниками, а в простых и ясных (хотя и громоздких) ER диаграммах и прочесть предпосылки, приведшие к таким решениям, в журнале! И останется им только заниматься комбинаторикой из уже существующих програмных блоков с минимальными затратами на их сопряжение!
вспомнил, что покупал я 0.5 года назад одному заказчику набор учебной литературы, в котором была книжка ... блин забыл как называется ... MicrosoftPress такая в твёрдом переплёте с желтой обложной и золотой коёмкой в которой были расписаны эти этапы. Но забыл о ней, а небольшие крупицы той небольшой прочитанной части дали ростки и появились на свет как эта тема форума.
Надо поискать по книжным магазинам эту книжку — вдруг там есть рекомендации не только по проектированию, но и конкретные советы по выбору систем для проектирования ПО!
Кстати в JBuilder`е можно программу посмотреть как ER диаграмму
а на books.ru можно много найти:
вроде то, что надо:
1 http://www.books.ru/shop/books/25255 — к сожалению на английском
2 http://www.books.ru/shop/books/30436
3 http://www.books.ru/shop/books/15401
4 http://www.books.ru/shop/books/81078
5 http://www.books.ru/shop/books/30688
какой то среднячёк:
6 http://www.books.ru/shop/books/24579
экстримальное программирование отбросил как сырые книги.
возможно в течении 2-3 месяца смогу некоторые осилить и тогда конспект выжимки самых интересных мест явлю на суд общественности.
всем твердил о необходимости поиска аналогов, а сам не поискал... :-(
Отредактировано Георгий — 28/07/2003, 23:59 |
|
| Asher |
| Отправлено: 29.07.2003, 08:37 |
|
Мастер участка
Группа: Модератор
Сообщений: 550
|
Тут в VisualStudio.Net обещают такую штуку:
| QUOTE |
Наглядное моделирование веб-служб XML и баз данных с помощью средств Microsoft Visio®.
Наглядное описание архитектуры программного обеспечения и распространение информации о ней. Применение диаграмм для вариантов использования (use-case), классов (class) и действий (activity), согласно спецификации языка UML. Быстрое проведение инженерного анализа и генерация структуры программного кода. Полная поддержка концептуального, логического и физического моделирования баз данных, обеспечение точности формулировки бизнес-требований и четкой постановки задачи перед разработчиками. |
Но насколько я понял только этим дело не ограничивается — вроде как на Visio проектируешь модули и связи между ними, а VS.NET генерит полностью скелет программы, куда надо добавить только, как они говорят, Вашу 'бизнес-логику'
P.S. Где-то бумажная статья была — никак не найду
P.P.S. Все это относится к Visual Studio .NET Enterprise Architect
Отредактировано Asher — 29/07/2003, 10:41
|
|
| Георгий |
| Отправлено: 05.08.2003, 22:03 |
|
Почетный железнодорожник
Группа: Модератор
Сообщений: 874
|
Люди! а для C++ есть такая хрень, которая по *.hpp файлам рисует диаграмму взаимодействия классов? Или наоборот — по диаграмме генерирует хотя бы прототипы?
Я для JAVA видел и захотелось мне такую же, но для C++, а то я тут кода набил, а диаграммы карандашём на бумаге, да и то не все, и не очень точные... |
|
| Гость_Вадим |
| Отправлено: 13.08.2003, 17:52 |
|
Не зарегистрирован
|
Я использую Power Designer.
В нем можно из диаграммы классов прототипы генерить. И это лишь малая часть его возможностей.
Вот правда в обратную сторону не пробовал, а это как раз таки один из важных процессов.
И вообще мощный пакет, стоит обратить на него внимание.
Тут мне недавно один java-программист расхваливал пакт Together
( название написано со слов), так вот он с пеной у рта доказывал, что он позволяет по человечески генерить прототипы из диаграммы классов и в обратную сторону, т.е. изменение в коде отображается на диаграмме классов. Но что то с трудом вериться.
|
|
| OfLiNe |
| Отправлено: 26.08.2003, 10:40 |
|
Не зарегистрирован
|
Есть интересный продукт фирмы Rational Rose Software
который относится к Case-cредствам проектирования ПО. |
|
| Георгий |
| Отправлено: 26.08.2003, 19:19 |
|
Почетный железнодорожник
Группа: Модератор
Сообщений: 874
|
прочитат я тут http://www.citforum.ru/database/case/glava5_5.shtml об этом продукте — похоже это то, что мне надо. Буду искать на рынках "на посмотреть"...
Отредактировано Георгий — 26/08/2003, 20:22 |
|
|
