ЭКАУНТОЛОГИЯ
Сайт, посвященный истории бухгалтерского учета и его неминуемому превращению в компьютерный учет
Техническое задание - Форум
Меню сайта

Войти

Случайная картинка

Умная мысль
Как в зеркале отражается каждая черта, малейшее пятнышко лица, так и торговые книги должны показывать весь ход дела, все обороты, сделки и вызываемые ими прибыли и убытки. Только когда предприниматель будет знать, что ему приносит прибыль и что убыток, когда он будет видеть ясно, на что, где и сколько расходует и от чего, где и сколько получает, тогда он сможет убыточные сделки прекратить, а прибыльные расширить, и только тогда он будет гарантирован от неожиданного разорения.
Г.И. Дорошенко

Старинный термин
МАЙДАН – на Востоке, в южных областях России, на Украине: рынок, базар, базарная площадь.

Последняя картинка

Социальные сети

Статистика

Время жизни

Приветствую Вас, Гость · RSS 14.12.2024, 10:03

Личка:

[ Новые сообщения · Участники · Правила форума · Поиск · RSS ]

Уважаемые посетители!
Для участия в обсуждениях, а также инициативного создания тем для обсуждений Вам необходимо зарегистрироваться и зайти на сайт в качестве пользователя (см. "Войти" на левой панели).


  • Страница 1 из 1
  • 1
Модератор форума: mikejum  
Техническое задание
MakitaДата: Среда, 09.01.2013, 16:21 | Сообщение # 1
Группа: Пользователи
Сообщений: 1
Я прочитал половину ТЗ с вашего сайта, т.к. я разработчик и эта тема мне ближе всего.
Как ваша система будет учитывать эволюцию информационных объектов?
Например, литературу, программное обеспечение, те же сайты или, даже, билеты в кино — какой в этом будет смысл?
Вот книга имеет материальную составляющую и информационную составляющую.
ПО уже чисто информационный продукт. Можно предложить хранение эволюции
исходных текстов, но похоже ваша система не приспособлена для хранения эволюции исходных текстов. Но кроме исходных текстов, ПО подвергается проектированию, дизайну, сборке, тестированию и т.д.
Получается ваша система совсем не дружит с постиндустриальным бизнесом. А ведь постиндустриальному бизнесу пророчат большое будущее.

Теперь мелкие придирки (я читал ТЗ только один раз и не полностью, может что-то пропустил, тогда извините):
1. Пользовательских полей может оказаться недостаточно. Например, на промышленном
предприятии может быть зарегистрировано сотни тысяч объектов. И у каждого могут быть уникальные свойства. Тут можно предложить отдельную онтологию для свойств.
С другой стороны, при операциях, возможны большие накладные расходы при копировании всех свойств объекта.
Я, кстати, немного работал с подобной базой данных. И как по мне, внутренняя реализация онтологии объектов и свойств выглядит жутко.
2. Может пропустил, но я не видел в ТЗ интерфейса создания и редактирования словаря (добавление/удаление слов, привязка словаря к полю.)
3. (совсем мелкое) у многих операций есть продолжительность: время начала и время конца.
4. Индустриальное производство во многом автоматизировано, поэтому нужно предложить механизмы автоматического ведения учета (некий программный интерфейс, API.)
5. Например вы получаете объект произведенный в Китае, вы открываете его в системе, а там все написано иероглифами. Что тогда?

Это пока все, что приходит в голову.

P.S. Я вопросы задаю чисто из праздного любопытства.
 
mikejumДата: Среда, 09.01.2013, 16:53 | Сообщение # 2
Группа: Администраторы
Сообщений: 181
Цитата (Makita)
Вот книга имеет материальную составляющую и информационную составляющую.
ПО уже чисто информационный продукт. Можно предложить хранение эволюции
исходных текстов, но похоже ваша система не приспособлена для хранения эволюции исходных текстов. Но кроме исходных текстов, ПО подвергается проектированию, дизайну, сборке, тестированию и т.д.
Получается ваша система совсем не дружит с постиндустриальным бизнесом. А ведь постиндустриальному бизнесу пророчат большое будущее.

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

Проблема тоже понятна. Решается следующим образом. Каждый субъект имеет в своем распоряжении ограниченное число полей для характеристики объектов, допустим N. Добывающее предприятие характеризует руду N свойствами. Затем руда передается обрабатывающему предприятию, которая не характеризует руду заново (она уже охарактеризована в общей системе), а характеризует в основном выплавленный из руды металл. Получаем 2N свойств: руды, из которой выплавлен металл, и самого металла. И т.д. до потребителя. А характеризовать объект в каждом субъекте заново - это ужас, я согласен.
Цитата (Makita)
Может пропустил, но я не видел в ТЗ интерфейса создания и редактирования словаря (добавление/удаление слов, привязка словаря к полю.)

Это мелочь, я даже не помню. Стандартный интерфейс.
Цитата (Makita)
(совсем мелкое) у многих операций есть продолжительность: время начала и время конца.

Это не мелочь. С точки зрения экаунтологии, имеются материальные связи, обозначающие преемственность вещей и их частей, и каузальные (причинно-следственные). Материальные связи мгновенны: т.к. записи в базе данных дискретны, то и любое изменение свойств объекта тоже дискретно. А вот каузальные связи продолжительны. Раскаленная сковорода действует на разбитые в ней яйца продолжительно, а яичница получается из сырых яиц мгновенно - в тот момент, когда мы посчитаем ее готовой. В настоящий момент в ТЗ реализованы только материальные связи. Как приделывать каузальные связи, понимаю, хотя это сильно усложнит интерфейс. Возможно, в ближайшем будущем.
Цитата (Makita)
Индустриальное производство во многом автоматизировано, поэтому нужно предложить механизмы автоматического ведения учета (некий программный интерфейс, API.)

Не на этом этапе. Это вообще не вопрос методологии.
 
mikejumДата: Среда, 09.01.2013, 16:54 | Сообщение # 3
Группа: Администраторы
Сообщений: 181
Цитата (Makita)
Например вы получаете объект произведенный в Китае, вы открываете его в системе, а там все написано иероглифами. Что тогда?

Ничего. По умолчанию предполагается единый язык. Вавилонское столпотворение, в результате которого языки оказались разделены - это плохо.
 
mikejumДата: Среда, 09.01.2013, 17:52 | Сообщение # 4
Группа: Администраторы
Сообщений: 181
Вспомнил, как словарь реализован. Там так сделано: добавление значения в словарь происходит при добавлении объекта. Т.е. при добавлении объекта значение либо выбирается из словаря, либо вписывается от руки (если его нет в словаре). При добавлении объекта значение автоматически добавляется в словарь. Соответственно, при удалении объекта значение (если такого нет ни у какого другого объекта в системе) из словаря автоматически удаляется (чтобы словарь очищать от не используемых значений). Поэтому и интерфейса на словаре нет, кроме возможности выбора значения.
 
akyl91Дата: Среда, 31.07.2013, 16:53 | Сообщение # 5
Группа: Модераторы
Сообщений: 17
Цитата (mikejum)
при удалении объекта значение (если такого нет ни у какого другого объекта в системе) из словаря автоматически удаляется
Не при всяком "удалении" словарь можно будет чистить.
 
mikejumДата: Среда, 31.07.2013, 17:36 | Сообщение # 6
Группа: Администраторы
Сообщений: 181
Почему? По-моему, если значение не используется ни одним объектом, оно может быть свободно удалено из словаря.
 
  • Страница 1 из 1
  • 1
Поиск:
Колонка Редактора

Постоянные авторы
Copyright Медведев М.Ю. © 2012-2024