class CComp
{
Tscreen CScreen;
TFile CFile;
fnc StopServ;
fnc StartServ;
fnc ConnectSensor/*Device*/( ... )
fnс DisconnectSensor /*Device*/ ( ... )
fnc SendData( ... )
fnc ReceiveData( ... )
}
class CSensor/*Device*/
{
Tstring Name;
float Value;
int Type;
prop Enable/*InUse*/;
fnc ConnectToServ;
fnc DisconnectFromServ;
fnc Send;
fnc Receive;
}
Создание большого проекта
Здравствуйте, участники форума!
Возникла необходимость в помощи.
Поставили задачу в разработке большого проекта. Народу - человека 3-4, так что встала необходимость грамотно разделить силы. В ООП все работали только левым боком и с закрытыми глазами, так что...
А сама задача примерно следущая: куча приборов и датчиков, в сумме около 10-15 единиц подключенных через Lan, RS-232, USB , с одних получать данные на другие посылать данные, какие-то из этих данных обрабатывать, что-то так записывать.
Наши идеи: ООП (будем учиться), DLL файлы подключаемые к главному модулю, ну и что по мелочи понадобится.
Может подсказать кто-либо учавствующий(вший) в создании большого проекта как расписать по блокам, что-ли, кому что делать и как потом собрать все коды в рабочую программу.
Ну вот как-то так.
Возникла необходимость в помощи.
Поставили задачу в разработке большого проекта. Народу - человека 3-4, так что встала необходимость грамотно разделить силы. В ООП все работали только левым боком и с закрытыми глазами, так что...
А сама задача примерно следущая: куча приборов и датчиков, в сумме около 10-15 единиц подключенных через Lan, RS-232, USB , с одних получать данные на другие посылать данные, какие-то из этих данных обрабатывать, что-то так записывать.
Наши идеи: ООП (будем учиться), DLL файлы подключаемые к главному модулю, ну и что по мелочи понадобится.
Может подсказать кто-либо учавствующий(вший) в создании большого проекта как расписать по блокам, что-ли, кому что делать и как потом собрать все коды в рабочую программу.
Ну вот как-то так.
Цитата: Rize
А сама задача примерно следущая: куча приборов и датчиков
Может, не в тему, но весьма поучительно будет почитать статью "Освобождение узников оператора IF". Русский ТРИЗ разносит Буча.
И еще вспомнить что такое "декомпозиция" и поработать с BPWin'ом, и не плохо бы еще про тех. задания узнать (:
Т.е. берешь BPWin ( или простую бумажку, если мазахизм прикалывает), разбиваешь все что необходимо на процессы. Допустим, "Функционирование Библиотеки" ( просто мало представляю как можно обозвать "кучу датчиков" и т.д., поэтому стандартный пример). Это "функционирование" разбиваешь, допустим, на "Выдачу книг", "Хранение книг", "Прием ( возвращение) книг". Далее все эти процессы бьешь еще на процессы и так пока остаются процессы, которые можно разбить еще на несколько процессов. Это еще все приправлено входами/выходами - т.е. "Выдача книг" имеет вход - запрос читателя, выход - книги и по такому же принципу...
После этого ты уже примерно ( или точно, смотря что получилось (: ) можешь представить что должна будет включать в себя будущая программа ( модули, алгоритмы и т.д и т.п.), соответственно, эти модули делишь на 3-4 человека и пишешь тех. задание на каждый модуль: что должен делать, что должен принимать ( типо входные данные), что выдавать ( соответственно, выходные), должен ли хранить информацию, если да, то в каком виде и т.д.
Эти 3-4 человека получают тех. задание, пишут модули и документацию к ним ( как минимум спецификацию) и фсе - собираешь все модули в один главный уже по их спецификациям/комментариям/еще чему-нибудь (:
После этого ты уже примерно ( или точно, смотря что получилось (: ) можешь представить что должна будет включать в себя будущая программа ( модули, алгоритмы и т.д и т.п.), соответственно, эти модули делишь на 3-4 человека и пишешь тех. задание на каждый модуль: что должен делать, что должен принимать ( типо входные данные), что выдавать ( соответственно, выходные), должен ли хранить информацию, если да, то в каком виде и т.д.
Эти 3-4 человека получают тех. задание, пишут модули и документацию к ним ( как минимум спецификацию) и фсе - собираешь все модули в один главный уже по их спецификациям/комментариям/еще чему-нибудь (:
Согласен вообщем-то с The_Ice.
Сам работал над 2-мя большими проектами (АСУ ТП). Разбиение было на уровне функциональности (контроллер - рабочая станция - терминал). Каждый писал отдельно свой прогаммный модуль (почему то кажется что так будет быстрее). Контроллер реализует управляющие воздействия (с базовой логикой),принимает входные сигналы. Рабочая станция хранит БД, реализует логику более высокого уровня. Терминал занимается отображением процесса.
Разбиение на такие блоки позволяет подключить сколь угодно много теминалов, что вообщем то и требовалось.
Как вариант вообщем-то. Дробить на более мелкие модули, когда несколько человек отлаживают один испольняемый файл, в таких проектах. помоему слишком геморойно. В крайнем случае все эти модули можно свести в один, если перед сетевыми модулями использовать прослойку.
Сам работал над 2-мя большими проектами (АСУ ТП). Разбиение было на уровне функциональности (контроллер - рабочая станция - терминал). Каждый писал отдельно свой прогаммный модуль (почему то кажется что так будет быстрее). Контроллер реализует управляющие воздействия (с базовой логикой),принимает входные сигналы. Рабочая станция хранит БД, реализует логику более высокого уровня. Терминал занимается отображением процесса.
Разбиение на такие блоки позволяет подключить сколь угодно много теминалов, что вообщем то и требовалось.
Как вариант вообщем-то. Дробить на более мелкие модули, когда несколько человек отлаживают один испольняемый файл, в таких проектах. помоему слишком геморойно. В крайнем случае все эти модули можно свести в один, если перед сетевыми модулями использовать прослойку.
В продолжение...
Тот, кто будет писать ТЗ вряд ли сможет писать код. По крайней мере, поначалу ему потребуется написать и раздать ТЗ каждому. Грамотное ТЗ с непривычки написать не выйдет, но писать всё равно придётся так, чтобы минимизировать количество лишних вопросов. А это означает, что писать придётся много. А потом ещё отвечать на вопросы, которые-таки возникнут у людей.
Но без ТЗ работать вообще похоже на суицид, так что готовьтесь. ;)
Тот, кто будет писать ТЗ вряд ли сможет писать код. По крайней мере, поначалу ему потребуется написать и раздать ТЗ каждому. Грамотное ТЗ с непривычки написать не выйдет, но писать всё равно придётся так, чтобы минимизировать количество лишних вопросов. А это означает, что писать придётся много. А потом ещё отвечать на вопросы, которые-таки возникнут у людей.
Но без ТЗ работать вообще похоже на суицид, так что готовьтесь. ;)
2 Freeman респектище за ссылку! Много наших косяков нашли, а от скольких, надеемся, убережёмся!
2 The_Ice общий смысл понятен начали работать над разбивкой, правда этот BPWin тож не простым оказался, так что мы пока на листочке, по-старинке, так сказать.
2 Odissey_ с тем на какие блоки разбивать пытамся разобраться, пока до драки не дошло, но курить стали явно чаще, учимся (=
2 .nornad если чесно не совсем понял с терминами, ТЗ в частности. Шеф сказал надо, вот тебе люди, работайте, попытка объянисть нашу ситуацию привела только к тому, что нам сроки сдачи увеличили и всё.
Мне объяснили что необходимо получить в итоге, так что чуствую ТЗ придется писать мне, а что там писать кроме - на входе икс на выходе икс в квадрате, хз.
Задание следущее:
Лаборатория в которой стоит куча приборов, оборудования, датчиков вот лаборанты видать хотят автоматизировать весь процесс работы, показали приборы и спросили о сроках, чесн слово что им ответить не знаем! попросили время для раздумий.
P.S. Очень непростым оказался, с виду элементарный, процесс разбиения на классы и типы всей этой кучи датчиков, для последущей возможности внедрения в рабочую систему новых приборов.
2 The_Ice общий смысл понятен начали работать над разбивкой, правда этот BPWin тож не простым оказался, так что мы пока на листочке, по-старинке, так сказать.
2 Odissey_ с тем на какие блоки разбивать пытамся разобраться, пока до драки не дошло, но курить стали явно чаще, учимся (=
2 .nornad если чесно не совсем понял с терминами, ТЗ в частности. Шеф сказал надо, вот тебе люди, работайте, попытка объянисть нашу ситуацию привела только к тому, что нам сроки сдачи увеличили и всё.
Мне объяснили что необходимо получить в итоге, так что чуствую ТЗ придется писать мне, а что там писать кроме - на входе икс на выходе икс в квадрате, хз.
Задание следущее:
Лаборатория в которой стоит куча приборов, оборудования, датчиков вот лаборанты видать хотят автоматизировать весь процесс работы, показали приборы и спросили о сроках, чесн слово что им ответить не знаем! попросили время для раздумий.
P.S. Очень непростым оказался, с виду элементарный, процесс разбиения на классы и типы всей этой кучи датчиков, для последущей возможности внедрения в рабочую систему новых приборов.
Цитата: Rize
Мне объяснили что необходимо получить в итоге, так что чуствую ТЗ придется писать мне, а что там писать кроме - на входе икс на выходе икс в квадрате, хз.
Если ТЗ на разработку функции возведения в квадрат, то описываешь вход и что надо получить на выходе. Если что-то, что должно (или может) использовать другие функции и библиотеки, то стоит привести их список.
В ТЗ (тех.задание) обычно описывается функционал проектируемой программы - что она должна делать и (возможно) как. У нас на фирме в ТЗ также кратко описывался интерфейс пользователя. Тут же описываются неочевидные нюансы работы - например, если клиент хочет иметь экспорт из своей БД в Excel через XML.
P.S. Если кто считает по поводу ТЗ иначе - поправьте.
Цитата: Freeman
Может, не в тему, но весьма поучительно будет почитать статью "Освобождение узников оператора IF". Русский ТРИЗ разносит Буча.
Несколько раз перечитал...
Каждый раз казалось: вот он смысл, но нет...
Остановился на мысли что автор пытался сложно объяснить простое: "полиморфизм хорошая замена if-у". Но такую очевидную вещь можно было объяснить и проще. Что паттерн "стратегия" лучше (там где применим), чем полиморфизм? Это тоже можно было объяснить значительно проще. Кстати, автор не владеет OOA&D терминологией.
Другая мысль, которую IMHO пытался довести автор: "классы всех программ абстрагируйтесь!", причем, от рождения.
Не совсем согласен с таким подходом. IMHO, абстрагирования должно быть в меру, абстрагироваться можно постепенно. Метод индукции (от частного к общему) никто не отменял.
Мы как-то спорили на "топологические темы":
http://forum.codenet.ru/showthread.php?t=28242
(читать лучше страницы со второй).
Как бы я решал вашу задачу.
Не думайте об DLL, классах и т.п. заранее, это придет в процессе.
Опишите в общих чертах, что требуется от ПО. Опишите самые частые примеры использования.
Попробуйте описать и реализовать простейший но цельный pipeline, т.е. полный путь передачи информации от входной точки (датчика) до выходной (запись в файл, вывод на экран и т.п.). Датчики обычно подключаются через специализированное ПО (драйвера и т.п.), пока не заостряйтесь на нём. Вместо реального датчика используйте эмулятор, это должен быть весьма простой класс, который примерно описывает интерфейс реального датчика. Вот здесь уже определяется некоторая абстрактная сущность - "датчик", которая может быть как реальным устройством, так и эмулятором. Аналогично могут возникать и другие сущности, изобретать которые специально не надо, они сами проявятся (правда, чтоб разглядеть их, понадобиться некоторый опыт).
Основная мысль: задача кажется сложной потому, что в ней много деталей. Пытаться вычленить детали и собрать из них общую систему - очень сложный путь. Значительно удобнее упростить задачу, сохраняя ориентир на общее решение. Решая эту задачу можно получить картину о решении более сложной задачи. А уж за тем итерационно развивать решение до полной задачи.
Другими словами, я бы сначала сделал бы простейшую систему из одного датчика и одного, потом применил эту систему к двум датчикам, не боясь модернизировать код. Неизменные части объединял бы в общие сущности, различия выносил бы в отдельные сущности. Здесь очень хорошо бы иметь представление об объектно-ориентированном проектировании (OOD).
Теперь об инструментарии.
Возьмите в привычку сохранять историю развития своих решений. Для этого вам понадобиться система контроля версий (VCS). Хорошей практикой так же будет иметь в VCS основной транк и под каждый эксперимент создавать бранчи. Ну это основы, так работают все, здесь ничего нового для вас нет.
Что касается мазахизма, то лично я считаю, что использование различного ПО для проектирования небольших проектов (в моём понимании "большие" это где-то 50 чел/лет) это (R.Rose, Toogether, BPWin и пр.) и есь мазохизм и лишняя трата времени. На небольших проектах вполне можно обойтись бумагой, Word-ом и Excel. Схемы и чертежи значительно проще рисовать карандашом на бумаге, а для их документирования и приобщения к делу дешевле, проще и удобнее воспользоваться обычным дешевеньким сканером.
Что касается инструментария по части управления проектом (хотя автор этим вопросом здесь не задавался), то при таком размере команды целесообразно так же ограничиться Excel-ем и почтой на базе IMAP.
В последнем проекте, в котором я учавствовал использовались R. XDE и TortoiseSVN, вполне ничего.
Цитата: Freeman
Может, не в тему, но весьма поучительно будет почитать статью "Освобождение узников оператора IF". Русский ТРИЗ разносит Буча.
Вот правильная статья! Спасибо, это как раз полезно авторам топика. Впрочем, Green тоже прав.
Sanila_san, поделись, о чем статья то?
Я без тени иронии спрашиваю. От меня смысл как-то ускользнул...
Я без тени иронии спрашиваю. От меня смысл как-то ускользнул...
Доброго дня всем ищущим! Удачной Вам рабочей недели.
Теперь о насущном.
Что требуется от ПО:
Запускаться, проверять наличие датчиков, подключение датчиков, установка параметров для некоторых приборов(датчиков), прием данных, построение графиков и зависимостей по полученным данным.
Наиболее сложными, на настоящий момент для нас, я вляются подключение и прием. Поскольку подключаться придется через различные протоколы TCP/IP, RS-232, USB, т.е. для каждого протокола свои особенности в запуске и работе, ну и соответсвенно отсюда же вытекают трудности с приемом/передачей.
Ещё у нас не очень получается с организацией промежуточного класса что-ли или наобот основного класса через который будут проходить все данные и который будет определять куда что отправить.
Ну, а теперь, что у нас уже получилось:
В самом общем случае, "доабстрагировавшись" по полной получается, что все наши датчики возвращают только своё текущее значение.
То есть получается самая простейшая pipeline получается следующего вида:
датчик (значание)-> компьютер
Но кажется что ошибка здесь есть, уж как то вообще элементарно получается.
Ребята, реально нужна подсказка. Где мы маху дали, может видит кто?
P.S. 2 Green чесн слово статья "Освобождение узников оператора IF" показала насколько много можно выиграть мысля "по-иному". Спорить о полезности не будем, но нам понравилось.
Теперь о насущном.
Что требуется от ПО:
Запускаться, проверять наличие датчиков, подключение датчиков, установка параметров для некоторых приборов(датчиков), прием данных, построение графиков и зависимостей по полученным данным.
Наиболее сложными, на настоящий момент для нас, я вляются подключение и прием. Поскольку подключаться придется через различные протоколы TCP/IP, RS-232, USB, т.е. для каждого протокола свои особенности в запуске и работе, ну и соответсвенно отсюда же вытекают трудности с приемом/передачей.
Ещё у нас не очень получается с организацией промежуточного класса что-ли или наобот основного класса через который будут проходить все данные и который будет определять куда что отправить.
Ну, а теперь, что у нас уже получилось:
В самом общем случае, "доабстрагировавшись" по полной получается, что все наши датчики возвращают только своё текущее значение.
То есть получается самая простейшая pipeline получается следующего вида:
датчик (значание)-> компьютер
Но кажется что ошибка здесь есть, уж как то вообще элементарно получается.
Ребята, реально нужна подсказка. Где мы маху дали, может видит кто?
P.S. 2 Green чесн слово статья "Освобождение узников оператора IF" показала насколько много можно выиграть мысля "по-иному". Спорить о полезности не будем, но нам понравилось.
Вот так выглядит схема будущей работы системы в сборе:
[ATTACH]1495[/ATTACH]
а вот примерно такие взаимодействия внутри программы:
[ATTACH]1496[/ATTACH]
Сейчас думаем над вот этим "черным квадратом" в программе определяющим что куда и как передавать.
Вот примерно что у нас получилось:
[ATTACH]1495[/ATTACH]
а вот примерно такие взаимодействия внутри программы:
[ATTACH]1496[/ATTACH]
Сейчас думаем над вот этим "черным квадратом" в программе определяющим что куда и как передавать.
Вот примерно что у нас получилось:
Код:
Цитата: Rize
Сейчас думаем над вот этим "черным квадратом" в программе определяющим что куда и как передавать.
IMHO вы не "думаете", а "выдумываете". Точно такая же ситуация с "Где мы маху дали, может видит кто?"
Реализуйте простейший pipeline для одного датчика (пусть даже не реального, а виртуального) и сразу станет яснее, где дали маху.
Зачем ударяться в абстрактное обдумывание, когда можно довольно легко провести эксперимент?
Цитата: Rize
P.S. 2 Green чесн слово статья "Освобождение узников оператора IF" показала насколько много можно выиграть мысля "по-иному". Спорить о полезности не будем, но нам понравилось.
Не знаю, что там "по-иному" и что вам показала статья, но то о чем там написано (что описывалось множество раз и значительно проще) вы на практике (IMHO) так и не применили.
По поводу первого рисунка.
Не вижу там абстракции. Я бы сделал так:
[ATTACH]1497[/ATTACH]
Т.е. Comp. работает только с некоторыми абстрактными устройствами, которые в реальности могут быть чем угодно, для эксперимента мок-объектом. При этом он ничего не знает о реальных устройствах.
Далее сам Comp. - непонятная сущность. Что это? Всё в одном?!
Что за Tscreen? Что за TFile CFile? Что за Serv?
Разберитесь, что за сущность CComp? Это регистратор? Менеджер устройств? Логгер?
Для чего он? Получать информацию и перенаправлять её получателям? Получать и обрабатывать? Управлять активностью датчиков? Отображать информацию на экране? Вести лог поступающей информации?
Всё это вместе он делать не может (в нормальной архитектуре).
Опишите что это в двух предложениях что это и для чего. Сможете?
Я бы нарисовал такую архитектуру:
1) есть абстрактный датчик, на базе которого строятся конкретные датчики;
2) есть менеджер датчиков, который управляет коллекцией абстрактных датчиков (добавляет, исключает, включает, выключает), он же может снимать с них информацию и передавать её "наблюдателям";
3) "наблюдатели" - это коллекция сущностей (опятьже на базе единого интерфейса, некоторого абстрактного наблюдателя), которые получают от менеджера информацию. Наблюдатели подписываются у менеджера на определенный или все виды информации, т.е. есть некоторая политика распределения информации. Пример наблюдателя - логгер, он может подписаться у менеджера и запросить всю информацию приходящую от датчиков. Менеджер, получив инф. от датчика, согласно политики подписки логгера передает её ему, не заботясь на кой хрен она логгеру понадобилась. Логгер же получив инф. сбрасывает её в файл. Другой наблюдатель может выводить её на экран и т.п.
Т.о. менеджер ничего не знает кроме абстрактных устройств и абстрактных наблюдателей; наблюдатели ничего не знают о датчиках, они лишь подписываются на информацию у менеджера; датчики вообще в полном неведении, их дело отдавать инф. менеджеру.
Второй рисунок - для меня вообще китайская грамота. Ничего не понял.
Вместо тавтологии "про IF" рекомендую почитать про паттерны, для начала классику от "банды четырех" (GoF).
Теперь понятно что значит pipeline - занимаемся, именно экспериментом и занимаемся.
CComp эта именно сущность принимающая, обрабатывающая, хранящая и выводящая всё, кажется придется пересмотреть её поведение. А на первом рисунке она - Comp.(computer) - главный обработчик, косячёк получается. Вот пересмотрели этот Comp.: разбили его на три, пока три, модуля - Logger, Visualisation, Processing и, соответсвенно, Senser Manager, идущий отдельно(выше уровнем, так наверное).
TScreen это экран на который будет выводиться инфа, TFile - файл в котором будут храниться данные, оба эти объекта для общего представления были представлены, зря оказывается, и это хорошо.
Можно объяснить ещё раз следущее: "есть абстрактный датчик, на базе которого строятся конкретные датчики" - вообще не понятен процесс такого построения.
То есть понятно, теперь, что необходимо общаться с датчиками через абстрактный менеджер, но сразу пугает сложность в реализации такого подхода, так как датчики имеют различные интерфейсы подключения.
CComp эта именно сущность принимающая, обрабатывающая, хранящая и выводящая всё, кажется придется пересмотреть её поведение. А на первом рисунке она - Comp.(computer) - главный обработчик, косячёк получается. Вот пересмотрели этот Comp.: разбили его на три, пока три, модуля - Logger, Visualisation, Processing и, соответсвенно, Senser Manager, идущий отдельно(выше уровнем, так наверное).
TScreen это экран на который будет выводиться инфа, TFile - файл в котором будут храниться данные, оба эти объекта для общего представления были представлены, зря оказывается, и это хорошо.
Можно объяснить ещё раз следущее: "есть абстрактный датчик, на базе которого строятся конкретные датчики" - вообще не понятен процесс такого построения.
То есть понятно, теперь, что необходимо общаться с датчиками через абстрактный менеджер, но сразу пугает сложность в реализации такого подхода, так как датчики имеют различные интерфейсы подключения.
Цитата: Rize
Теперь понятно что значит pipeline - занимаемся, именно экспериментом и занимаемся.
Pipeline - это не "эксперимент".
Pipeline в переводе с буржуйского - "трубопровод" или "конвеер".
В данном случае под pipeline понимается путь (цепочка преобразований), который проходят данные от точек входа (датчики) до точек выхода (экран, файл и т.п.)
Я в предыдущих постах рекомендовал построить простейшую такую цепочку. Этот эксперимент позволит вам прояснить для себя нюансы и проверить (расширить, дополнить, переработать) разрабатываемую архитектуру.
Цитата: Rize
Вот пересмотрели этот Comp.: разбили его на три, пока три, модуля - Logger, Visualisation, Processing и, соответсвенно, Senser Manager, идущий отдельно(выше уровнем, так наверное).
Ну вот, уже лучше.
Цитата: Rize
Можно объяснить ещё раз следущее: "есть абстрактный датчик, на базе которого строятся конкретные датчики" - вообще не понятен процесс такого построения.
Абстрактный датчик - это всего лишь обобщенный интерфейс.
Цитата: Rize
То есть понятно, теперь, что необходимо общаться с датчиками через абстрактный менеджер, но сразу пугает сложность в реализации такого подхода, так как датчики имеют различные интерфейсы подключения.
Я так понимаю, что пугает: "как же менеджер будет знать как именно с каким датчиком общаться?"
Да не будет менеджер ничего знать о реализации датчика. Для этого и служит обобщенный интерфейс (абстрактный датчик). Ты ведь когда записываешь инф. в файл не заморачиваешься с тем как он физически пишется, на HDD или FDD, сколько дорожек на диске, сколько байт в секторе и т.п. Ты просто говоришь WriteFile, а уж что там скрыто за ним тебе знать не обязательно.
Так же и менеджер будет говорить open(), чтобы инициализировать (законектиться и т.п.), read(), - чтобы получать информацию, и т.д.. А вот что скрыто за этими методами его не волнует, это проблема конкретной реализации, скрытой за интерфейсом абстрактного датчика.
Вот как это выглядит (упрощенно до нельзя) в коде (это псевдо-язык):
Код:
class AbstructSensor
{
public:
open() =0;
close() =0;
read() =0;
};
class AbstructObserver
{
public:
init() =0;
write(data) =0;
};
class Manager
{
addSensor(AbstructSensor&);
addObserver(AbstructObserver&);
bool init() {
foreach(sensors)
if( !sensor.open() ) return false;
foreach(observers)
if( !observer.init() ) return false;
return true;
}
onEvent() {
foreach(sensors) {
data = sensor.read();
foreach(observers)
observer.write(data);
}
}
container<AbstructSensor> sensors;
observer<AbstructObserver> observers;
};
class FakeSensorByFile :public AbstructSensor
{
public:
open() {
file.open(filename)
}
close() {
file.close()
}
read() {
return file.read();
}
File file;
};
class FileLogger :public AbstructObserver
{
public:
init() {
log.open(filename)
}
write(data) {
log.write(data)
}
File log;
};
{
public:
open() =0;
close() =0;
read() =0;
};
class AbstructObserver
{
public:
init() =0;
write(data) =0;
};
class Manager
{
addSensor(AbstructSensor&);
addObserver(AbstructObserver&);
bool init() {
foreach(sensors)
if( !sensor.open() ) return false;
foreach(observers)
if( !observer.init() ) return false;
return true;
}
onEvent() {
foreach(sensors) {
data = sensor.read();
foreach(observers)
observer.write(data);
}
}
container<AbstructSensor> sensors;
observer<AbstructObserver> observers;
};
class FakeSensorByFile :public AbstructSensor
{
public:
open() {
file.open(filename)
}
close() {
file.close()
}
read() {
return file.read();
}
File file;
};
class FileLogger :public AbstructObserver
{
public:
init() {
log.open(filename)
}
write(data) {
log.write(data)
}
File log;
};
Кстати, FakeSensorByFile - это и есть некий не реальный датчик для первых экспериментов, который читает подготовленные данные из файла и выдает себя за реальный датчик.
onEvent - это метод, который по какому-то событию (не знаю, какое событие используете вы, таймер или ещё что) вычитывает данные из всех датчиков и передает их всем наблюдателям.
Самый простой способ реализации любого проекта – делать всё по «законам искусства»…
Как не странно, но именно так и можно решить в кротчайшие сроки с минимум ошибок любую задачу.
1. Произвести анализ предметной области – как правило, это делает сторонний человек, т.е. грамотный специалист в ИТ – аналитик, ну, или человек, который способен думать аналитически. Анализ лучше начинать с модели «как есть» - глубина детализации – определяет дальнейшее количество вопросов (обратная пропорциональность). На этом этапе часто довольно существенно помогают инструменты моделирования процессов, в частности тот же BPWin (можно просто Visio). На этом этапе, как правило, уточнение делаются на уровне конечного пользователя и существующих возможностей.
2. После построения модели «как есть» - считайте, ваш проект готов. На самом деле, следующая стадия – определение оптимальных планов, т.е. оптимизация существующих процессов – это дело сугубо интимное, и зависит как правило от того, что же в конечном итоге мы хотим получить. У вас как «на ладони» будет картинка производства, и сразу будет видно что не эффективно (дублируется например), что станет не эффективным в результате добавления элемента автоматизации. Короче, фантазируем как хотим (с привязкой к нашим экономическим и материальным возможностям). В результате, получим модель «как будет» (точнее, «как должно быть»). Всё – проект готов. Мы определили, что хотим, что должно быть сделано (или не сделано). Эти этапы делают аналитики при тесном (ну очень тесном) контакте с экспертами – технологами.
3. Этот (третий) этап – составление ТЗ (технического задания). Эта бумажка – руководство разработчику, чего делать НЕ НАДО (для заказчика) и что делать НАДО (для разработчика). По сути, это перечисление по пунктам функций, определенных на стадии моделирования. При этом, функциональные обязанности проекта декомпозируются на функционально – логические модули (программы, библиотеки и т.д.) При этом, в Т.З. не указывается не способы не методы реализации - это решает разработчик. Указываются только ограничения (как правило, связанные с фактическим состоянием дел).
4. Это не этап – просто теперь у Вас есть набор разложенных по полочкам задач, и кому, что и сколько дать (поручить) - решать только Вам. Если Вы не работаете по стандартам (а кто по ним работает?) и проект не коммерческий– то, сроки реализации – определяются исходя из возможностей персонала.
Это краткий алгоритм – не пугайтесь, на самом деле, при хорошем знании производства – анализ – дело пару дней…Самое главное – не притягивайте на каждой стадии всё за уши к собственным интересам (в этом случае, теряется смысл всего этого – что часто бывает в действительно больших коммерческих проектах), подходите при этих операциях как посторонний человек (ну, или как если бы Вы это делали для фирмы стороннего разработчика, заплатив им пару миллиардов евро, и хотите что бы они отработали эти деньги)…
Инструменты которые могут помочь:
BPWin ERWin MS Visio Access MS Word. RRose. Бумага карандаш.
Просто обычно, не решается «всё сразу» - отработайте один датчик (устройство) т.е. имеющих один интерфейс подключения. Чем глубже декомпозиция – тем меньше ошибок, быстрее и легче сделать (Проше). И, остерегайтесь стоить системные дела (например серверные функции) в средах быстрой разработки типа Delphi, C++Builder и тем более VB. Конечно можно на продуктах Borland это делать – но только на API.
Как не странно, но именно так и можно решить в кротчайшие сроки с минимум ошибок любую задачу.
1. Произвести анализ предметной области – как правило, это делает сторонний человек, т.е. грамотный специалист в ИТ – аналитик, ну, или человек, который способен думать аналитически. Анализ лучше начинать с модели «как есть» - глубина детализации – определяет дальнейшее количество вопросов (обратная пропорциональность). На этом этапе часто довольно существенно помогают инструменты моделирования процессов, в частности тот же BPWin (можно просто Visio). На этом этапе, как правило, уточнение делаются на уровне конечного пользователя и существующих возможностей.
2. После построения модели «как есть» - считайте, ваш проект готов. На самом деле, следующая стадия – определение оптимальных планов, т.е. оптимизация существующих процессов – это дело сугубо интимное, и зависит как правило от того, что же в конечном итоге мы хотим получить. У вас как «на ладони» будет картинка производства, и сразу будет видно что не эффективно (дублируется например), что станет не эффективным в результате добавления элемента автоматизации. Короче, фантазируем как хотим (с привязкой к нашим экономическим и материальным возможностям). В результате, получим модель «как будет» (точнее, «как должно быть»). Всё – проект готов. Мы определили, что хотим, что должно быть сделано (или не сделано). Эти этапы делают аналитики при тесном (ну очень тесном) контакте с экспертами – технологами.
3. Этот (третий) этап – составление ТЗ (технического задания). Эта бумажка – руководство разработчику, чего делать НЕ НАДО (для заказчика) и что делать НАДО (для разработчика). По сути, это перечисление по пунктам функций, определенных на стадии моделирования. При этом, функциональные обязанности проекта декомпозируются на функционально – логические модули (программы, библиотеки и т.д.) При этом, в Т.З. не указывается не способы не методы реализации - это решает разработчик. Указываются только ограничения (как правило, связанные с фактическим состоянием дел).
4. Это не этап – просто теперь у Вас есть набор разложенных по полочкам задач, и кому, что и сколько дать (поручить) - решать только Вам. Если Вы не работаете по стандартам (а кто по ним работает?) и проект не коммерческий– то, сроки реализации – определяются исходя из возможностей персонала.
Это краткий алгоритм – не пугайтесь, на самом деле, при хорошем знании производства – анализ – дело пару дней…Самое главное – не притягивайте на каждой стадии всё за уши к собственным интересам (в этом случае, теряется смысл всего этого – что часто бывает в действительно больших коммерческих проектах), подходите при этих операциях как посторонний человек (ну, или как если бы Вы это делали для фирмы стороннего разработчика, заплатив им пару миллиардов евро, и хотите что бы они отработали эти деньги)…
Инструменты которые могут помочь:
BPWin ERWin MS Visio Access MS Word. RRose. Бумага карандаш.
Просто обычно, не решается «всё сразу» - отработайте один датчик (устройство) т.е. имеющих один интерфейс подключения. Чем глубже декомпозиция – тем меньше ошибок, быстрее и легче сделать (Проше). И, остерегайтесь стоить системные дела (например серверные функции) в средах быстрой разработки типа Delphi, C++Builder и тем более VB. Конечно можно на продуктах Borland это делать – но только на API.
Большое спасибо всем за информацию!
Сейчас работаем - ничего не получается! (= Ну не получается пока того, что мы себе представляли, надеемся, что это дело времени.
Как только появятся приемлемые результаты покажем.
Сейчас работаем - ничего не получается! (= Ну не получается пока того, что мы себе представляли, надеемся, что это дело времени.
Как только появятся приемлемые результаты покажем.
Цитата: Rize
Ну, а теперь, что у нас уже получилось:
В самом общем случае, "доабстрагировавшись" по полной получается, что все наши датчики возвращают только своё текущее значение.
То есть получается самая простейшая pipeline получается следующего вида:
датчик (значание)-> компьютер
Но кажется что ошибка здесь есть, уж как то вообще элементарно получается.
Ребята, реально нужна подсказка. Где мы маху дали, может видит кто?
Как не странно - но это не ошибка а цель. И смысл всего - элементарность. Ничего и не надо больше делать этому функционалу, как тупо обрабатывать данные. "А ларчик то, открывался просто...":)
Ребята – пока тут обсуждается всякое разное, произошли следующие события.
Две недели назад, к нам на предприятие пришли датчики. С ними документация на 4-х страницах с подробным описанием в виде полной лажи. Начальник сказал «посмотри…». Сегодня уже второй день система работает в пром.эксплуатации… Что делает? Есть набор датчиков, каждый датчик подключен к технологической машине по RS-232. На технологической машине, в виде службы запущен сервер: обрабатывает данные с контроллера, пишет в SQL базу на сервер, отвечает клиентам по TCP в виде реальных данных, принимает команды. Клиент – смотрит показания текущие, и накопленную статистику (среднечасовые, среднесуточные и т.д.) ну это и в виде графика отображается (для удобства). Удаленность объектов: 2 – 24 км. Осталось дописать модуль отчетов. Переписываю эти каракули под Linux – будет один сервер приложений, все датчики переведу на работу ч/з преобразователи интерфейсов MOXA.
Вывод: если бы я заморачивался принципами OOP и абстрактно строил модель – думаю, датчики и сейчас лежали бы на складе (если задача продолжается без прогресса больше 2-х недель, я теряю интерес //если конечно, за это не платят достаточно приемлемые деньги). Я уже говорил – отработайте один датчик (по типам). У вас получилось, в чем проблема? А то, что датчики USB/RS – то в чем проблема тут? С USB можно организовать работу по RS-232 (промышленное решение). Сколько это делало человек? Не поняли? Один человек.
Посчитайте по формуле: T = t x P x F время на разработку.
Где:
t – время для разработки одного функционала одним человеком
P – количество человек принимающих участие в разработке над данным функционалом
F – количество функционалов.
Как видим, есть над чем подумать, проигравшись с формулой, можно оптимизировать процесс…
Классическое определение управления процессом проектирования – «делим задачу на функционалы и каждый функционал отдаём одному человеку» Вот, пусть одним типом контроллере и занимается один человек. И не надо парится с ООП концепциями – они существуют не для усложнения жизни, а для её облегчения, тем самым определяя «ООП не исключает процедурного подхода, Объектный подход построен на процедурном, но с объединением в группы (классы)» Короче, не парьтесь, не стройте умно-запутанных конструкций, чем проще, тем эффективней и быстрее.
Две недели назад, к нам на предприятие пришли датчики. С ними документация на 4-х страницах с подробным описанием в виде полной лажи. Начальник сказал «посмотри…». Сегодня уже второй день система работает в пром.эксплуатации… Что делает? Есть набор датчиков, каждый датчик подключен к технологической машине по RS-232. На технологической машине, в виде службы запущен сервер: обрабатывает данные с контроллера, пишет в SQL базу на сервер, отвечает клиентам по TCP в виде реальных данных, принимает команды. Клиент – смотрит показания текущие, и накопленную статистику (среднечасовые, среднесуточные и т.д.) ну это и в виде графика отображается (для удобства). Удаленность объектов: 2 – 24 км. Осталось дописать модуль отчетов. Переписываю эти каракули под Linux – будет один сервер приложений, все датчики переведу на работу ч/з преобразователи интерфейсов MOXA.
Вывод: если бы я заморачивался принципами OOP и абстрактно строил модель – думаю, датчики и сейчас лежали бы на складе (если задача продолжается без прогресса больше 2-х недель, я теряю интерес //если конечно, за это не платят достаточно приемлемые деньги). Я уже говорил – отработайте один датчик (по типам). У вас получилось, в чем проблема? А то, что датчики USB/RS – то в чем проблема тут? С USB можно организовать работу по RS-232 (промышленное решение). Сколько это делало человек? Не поняли? Один человек.
Посчитайте по формуле: T = t x P x F время на разработку.
Где:
t – время для разработки одного функционала одним человеком
P – количество человек принимающих участие в разработке над данным функционалом
F – количество функционалов.
Как видим, есть над чем подумать, проигравшись с формулой, можно оптимизировать процесс…
Классическое определение управления процессом проектирования – «делим задачу на функционалы и каждый функционал отдаём одному человеку» Вот, пусть одним типом контроллере и занимается один человек. И не надо парится с ООП концепциями – они существуют не для усложнения жизни, а для её облегчения, тем самым определяя «ООП не исключает процедурного подхода, Объектный подход построен на процедурном, но с объединением в группы (классы)» Короче, не парьтесь, не стройте умно-запутанных конструкций, чем проще, тем эффективней и быстрее.
М-да... единственный вывод из твоего опуса: видимо, ты не умеешь использовать ООП (а точнее, видимо, OOA&D), поэтому для тебя это представляется сложностью и затягиванием по времени.
Умение видеть задачу в OOD свете надо развивать тренировками.
Единственная правильная мысль (но не фраза), что целесообразно создавать простые конструкции. Вот только простое решение - это не значит примитивное решение влоб.
P.S. Слово "функционал" в данном контексте режет слух (глаз).
Функционал - это функция, определённая на множестве функций.
Ты же имеешь в виду "функциональность".
Умение видеть задачу в OOD свете надо развивать тренировками.
Единственная правильная мысль (но не фраза), что целесообразно создавать простые конструкции. Вот только простое решение - это не значит примитивное решение влоб.
P.S. Слово "функционал" в данном контексте режет слух (глаз).
Функционал - это функция, определённая на множестве функций.
Ты же имеешь в виду "функциональность".
Цитата: Green
М-да... единственный вывод из твоего опуса: видимо, ты не умеешь использовать ООП (а точнее, видимо, OOA&D), поэтому для тебя это представляется сложностью и затягиванием по времени.
Умение видеть задачу в OOD свете надо развивать тренировками.
Единственная правильная мысль (но не фраза), что целесообразно создавать простые конструкции. Вот только простое решение - это не значит примитивное решение влоб.
P.S. Слово "функционал" в данном контексте режет слух (глаз).
Функционал - это функция, определённая на множестве функций.
Ты же имеешь в виду "функциональность".
Умение видеть задачу в OOD свете надо развивать тренировками.
Единственная правильная мысль (но не фраза), что целесообразно создавать простые конструкции. Вот только простое решение - это не значит примитивное решение влоб.
P.S. Слово "функционал" в данном контексте режет слух (глаз).
Функционал - это функция, определённая на множестве функций.
Ты же имеешь в виду "функциональность".
С «функционалом» согласен (рад что поняли (?)). Имелось в виду функциональность ИС, и как подмножество исполняемых задач – конкретный модуль (группа функций, приведенных над полем допустимых решений). Ладно, не суть..
Пример (реализован на C# - как пробный камень на Framework, понятно на ООП) просто должен был напомнить ребятам, что проектирование само по себе не цель, требуется реализация, для этого надо более практично подходить. ООП - прежде всего инструмент, и если у человека не получается думать на уровне объектов (а они, как я понял, не аналитики и не проектировщики…), то стремление реализовать эти концепции – только запутает всё. Можно определить устройство как класс, и охарактеризовать его свойствами и методами – но тогда, мы должны создать абстрактный класс и… А надо ли устройству быть отдельной сущностью? – может это устройство только и делает, что передаёт принимает пару параметров, и в системе можно подняться на уровень выше – определив методы общения с этим устройством, а его самого как, например, членом более высокого класса? Пошли вопросы – как видно, совсем не приближающие нас к решению задачи. Нет, я не за то, что бы всё решать «в лоб» (не дай бог! – Описанный мной экстремал, результат достаточного опыта, досконального знания проблемной области, и умения «мыслить объектами»), но сложность задачи, как правило, возрастает от неуместного или чрезмерного «увлечения» средствами и методами малознакомыми. Ведь данная ИС делается для себя, значит усложнять её нет смысла. И если можно сделать что-то проще, почему бы это так и не сделать? Конечно, я совсем не веду речь о процедурном подходе, но если что-то проще сделать именно так, так почему это не сделать?
Две недели – это нормальный (максимальный) срок решения для любой задачи одним человеком (но не проекта!), если за это время данная задача не решена, значит: или неправильная изначальная постановка, или данная задача требует декомпозиции (слишком большая). Поэтому, при планировании работ, так важно распределение по времени и объему между персоналом, или составление личного плана. Психология однако, тоже, вещь не маловажная…:)
Цитата: .nornad
В продолжение...
Тот, кто будет писать ТЗ вряд ли сможет писать код. По крайней мере, поначалу ему потребуется написать и раздать ТЗ каждому. Грамотное ТЗ с непривычки написать не выйдет, но писать всё равно придётся так, чтобы минимизировать количество лишних вопросов. А это означает, что писать придётся много. А потом ещё отвечать на вопросы, которые-таки возникнут у людей.
Но без ТЗ работать вообще похоже на суицид, так что готовьтесь. ;)
Тот, кто будет писать ТЗ вряд ли сможет писать код. По крайней мере, поначалу ему потребуется написать и раздать ТЗ каждому. Грамотное ТЗ с непривычки написать не выйдет, но писать всё равно придётся так, чтобы минимизировать количество лишних вопросов. А это означает, что писать придётся много. А потом ещё отвечать на вопросы, которые-таки возникнут у людей.
Но без ТЗ работать вообще похоже на суицид, так что готовьтесь. ;)
У нас работает система, так вот ТЗ на промежуточный уровень писал человек делавщий этот уровень... Уже после того, как его написал, занятно, да. Смотриш исходный код, видеш ошибки, и как коментарии читаеш усё это в ТЗ...
Дорвался…
Мне не понятно, что коллективно всё делается? Почему всегда звучит «мы подумали» «мы пересмотрели» - речь то идет как правило о чем-то конкретном – чем должен заниматься один человек. Коллективный разум конечно хорошо, но так во первых договорится сложнее, во вторых, значительно дольше все будет делаться. Предложение «разбить на подзадачи» не преследовало цели заниматься этими «подзадачами» коллективно… :)
Мне не понятно, что коллективно всё делается? Почему всегда звучит «мы подумали» «мы пересмотрели» - речь то идет как правило о чем-то конкретном – чем должен заниматься один человек. Коллективный разум конечно хорошо, но так во первых договорится сложнее, во вторых, значительно дольше все будет делаться. Предложение «разбить на подзадачи» не преследовало цели заниматься этими «подзадачами» коллективно… :)
Цитата: Rize
........
Мне объяснили что необходимо получить в итоге, так что чуствую ТЗ придется писать мне, а что там писать кроме - на входе икс на выходе икс в квадрате, хз.
.
Есть простой способ не нагружать себя:
ГОСТ 34.602-89
"ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ"
Отвечаем по пунктам и всё, и другим понятно, и сами пока пишем, разберемся - чего надо-то... Да и потом, проще доказавать что "так хотели сами..." :)
Цитата: Виктор А.
Посчитайте по формуле: T = t x P x F время на разработку.
Где:
t – время для разработки одного функционала одним человеком
P – количество человек принимающих участие в разработке над данным функционалом
F – количество функционалов.
Как видим, есть над чем подумать, проигравшись с формулой, можно оптимизировать процесс…
Играться с формулой, конечно, приятно и полезно, но посмотри -
T = t x P x F . P - кол-во человек, величина больше 1. Получается, что чем больше человек делают работу, тем медленнее она продвигается. Это из законов Мерфи о машинном проектировании, кажется:).
Да и потом, с чего ты взял, что между кол-вом разработчиков, и временем работы есть линейная зависимость?
Цитата: Zorkus
Играться с формулой, конечно, приятно и полезно, но посмотри -
T = t x P x F . P - кол-во человек, величина больше 1. Получается, что чем больше человек делают работу, тем медленнее она продвигается. Это из законов Мерфи о машинном проектировании, кажется:).
Да и потом, с чего ты взял, что между кол-вом разработчиков, и временем работы есть линейная зависимость?
T = t x P x F . P - кол-во человек, величина больше 1. Получается, что чем больше человек делают работу, тем медленнее она продвигается. Это из законов Мерфи о машинном проектировании, кажется:).
Да и потом, с чего ты взял, что между кол-вом разработчиков, и временем работы есть линейная зависимость?
Это при условии, что P > 1 а если P -> 1 (?). Можно добавть: if(T<= "приемлимое время") иначе F = F*n (где n - коэфициент дискретности, т.е. по сути понижающий коэфициент, который n = 1/ <количество подзадачь> определяет степень декомпозиции. Т.е. задача сложная... Разбиваем на более мелкие... :)
Да ладно, это из серии зн. Мерфи... иногда, может пригодится. Ну действительно, если три человека будут проыерять одно и то же условие, ошибка может и не увеличится, но время на её поиск наверняка бедет больше...
Почему линейная зависимость? Возможно и нет… Лень искать точное определение, вывел по памяти… Но суть должна быть верной. В любом случае, вся эта бодяга для одной задачи, но никак не для проекта в целом (я не сторонник одиночества…)
Цитата: Виктор А.
Пример (реализован на C# - как пробный камень на Framework, понятно на ООП) просто должен был напомнить ребятам, что проектирование само по себе не цель, требуется реализация, для этого надо более практично подходить.
Реализация - тоже не цель. Проектирование, реализация - это всего лишь "сверла", а заказчику нужны "дырки".
Так что всему свое время и вес в процессе разработки.
Цитата: Виктор А.
ООП - прежде всего инструмент, и если у человека не получается думать на уровне объектов (а они, как я понял, не аналитики и не проектировщики…), то стремление реализовать эти концепции – только запутает всё.
Но надо когда-то вырастать из кодеров в программисты из программистов в архитекторов и аналитиков. Ну а чтоб не запутались, мы поможем. ;) (чем сможем)
Цитата: Виктор А.
Можно определить устройство как класс, и охарактеризовать его свойствами и методами – но тогда, мы должны создать абстрактный класс и… А надо ли устройству быть отдельной сущностью? – может это устройство только и делает, что передаёт принимает пару параметров, и в системе можно подняться на уровень выше – определив методы общения с этим устройством, а его самого как, например, членом более высокого класса? Пошли вопросы – как видно, совсем не приближающие нас к решению задачи.
Почему же? Приближающие, но только не с того конца.
Плясать то надо не снизу вверх...
Цитата: Виктор А.
Ведь данная ИС делается для себя, значит усложнять её нет смысла. И если можно сделать что-то проще, почему бы это так и не сделать?
Почему усложнять?
Переводить в другую плоскость, а сл-но упрощать для понимания.
Цитата: Виктор А.
Две недели – это нормальный (максимальный) срок решения для любой задачи одним человеком (но не проекта!), если за это время данная задача не решена, значит: или неправильная изначальная постановка, или данная задача требует декомпозиции (слишком большая). Поэтому, при планировании работ, так важно распределение по времени и объему между персоналом, или составление личного плана. Психология однако, тоже, вещь не маловажная…:)
Две недели - это слишком большой интервал. Я придерживаюсь мнения, что задачи должны быть по продолжительности не более 8 часов.
Цитата: Green
Реализация - тоже не цель. Проектирование, реализация - это всего лишь "сверла", а заказчику нужны "дырки".
Так что всему свое время и вес в процессе разработки.
................................
Но надо когда-то вырастать из кодеров в программисты из программистов в архитекторов и аналитиков. Ну а чтоб не запутались, мы поможем. ;) (чем сможем)
................................
Почему же? Приближающие, но только не с того конца.
Плясать то надо не снизу вверх...
...............................
Почему усложнять?
Переводить в другую плоскость, а сл-но упрощать для понимания.
..............................
Две недели - это слишком большой интервал. Я придерживаюсь мнения, что задачи должны быть по продолжительности не более 8 часов.
Так что всему свое время и вес в процессе разработки.
................................
Но надо когда-то вырастать из кодеров в программисты из программистов в архитекторов и аналитиков. Ну а чтоб не запутались, мы поможем. ;) (чем сможем)
................................
Почему же? Приближающие, но только не с того конца.
Плясать то надо не снизу вверх...
...............................
Почему усложнять?
Переводить в другую плоскость, а сл-но упрощать для понимания.
..............................
Две недели - это слишком большой интервал. Я придерживаюсь мнения, что задачи должны быть по продолжительности не более 8 часов.
Думаю, мы об одном и том же... Интересно, то, что мы тут болтаем, кто-то ещё читает?
Как дела у ребят?
.....:)
Цитата: Green
................
На небольших проектах вполне можно обойтись бумагой, Word-ом и Excel. Схемы и чертежи значительно проще рисовать карандашом на бумаге, а для их документирования и приобщения к делу дешевле, проще и удобнее воспользоваться обычным дешевеньким сканером.
Добавлю - довольно удобно работать в MS Visio - простенько и сердито.