21
« : 14 Декабря 2010, 13:23:27 »
По работе поставили задачу закончить СТП, начатое другим человеком.
Перед тем, как начать писать хочется представить себе возможные пути реализации, т.к., честно говоря, не нравится то, что сейчас в документе явно прослеживается не очень, по моему мнению, оптимальный вариант решения проблемы. Сразу замечу, что то, что у нас называется СТП – это некий гибрид ТЗ и ТП, то есть описываются и требования, и предлагаемые пути реализации. При этом разработчики могут по прочтению СТП сразу взяться за реализацию или написать свой ТП.
Ниже напишу еще свои соображения, а пока задача.
Суть задачи: Есть поток текстовых данных, разделенных на блоки. В каждом блоке требуется найти некий (или некие, если их несколько) идентификатор, вычислить (если требуется) контрольное значение для него и выдать в отдельный файл, возможно обработав перед этим.
Идентификатор: Последовательность символов в большинстве случаев описываемая в широких пределах.
Например, строка из арабских цифр длинной от 3 до 8 символов, ограниченная пробелами или началом(концом) строки.
В этом случае:
1. строка «Контракт3135» неверна, результат – отрицательная обработка, т.е. идентификатор не найден.
2. строка «145 гугл» верна, результат – идентификатор «145».
2. строка «145568235 12-12-1985» неверна, результат – отрицательный, т.е. идентификатор не найден.
Или идентификатор - строка, начинающаяся с открывающейся скобки “(” и заканчивающаяся закрывающейся скобкой “)”. При этом внутри скобок находятся три под-идентификатора, разделенные символом “/”. Первый под-идентификатор - строка из арабских цифр длинной от 3 до 8 символов. Второй под-идентификатор - строка из букв кириллического алфавита длинной от 10 до 20 символов. Третий под-идентификатор – дата (формата ДД-ММ-ГГ). Вернуть требуется первый под-идентификатор, при условии, что все идентификатор и под-идентификаторы распознаны корректно.
В этом случае:
1. строка «Привет (100/Маша/13-13-2010» неверна, результат – отрицательная обработка, т.е. идентификатор не найден.
2. строка «(100/Маша/13-10-2010» неверна, результат – отрицательная обработка, т.е. идентификатор не найден.
3. строка «(100/ /13-10-2010» неверна, результат – отрицательная обработка, т.е. идентификатор не найден.
4. строка «(100/ Сергей1/13-10-2010)» неверна, результат – отрицательная обработка, т.е. идентификатор не найден.
5. строка «(100/ Сергей/13-10-2010)» верна, результат – идентификатор “100”.
В перспективе идентификаторов может быть очень много и они могут быть очень разнообразными.
Предлагаемое решение, которое описано в СТП сейчас предлагает для каждого нового идентификатора писать свою процедуру разбора текста. При этом правила разбора пишутся прямо в коде процедуры и больше в системе сами по себе не существуют.
Чем мне не нравится такое решение?
1. нужно каждый раз писать код для нового идентификатора.
2. нужно каждый раз писать код для нового идентификатора, если была допущена ошибка и процедура разбора работает неверно.
3. правила к идентификаторам существуют только в коде и их не видно пользователю.
Плюсы, которые я вижу:
1. процедуру можно написать какую угодно
Предлагаемое мной решение:
Реализовать справочник идентификаторов в котором они будут задаваться с помощью регулярных выражений POSIX (к примеру). Подключить к систему внешнюю библиотеку, реализующую парсер регулярных выражений и использовать ее (например, TextPipe).
Минусы моего подхода, которые я вижу:
1. нужно купить внешнюю библиотеку
2. пользователям потребуется разобраться с языком регулярных выражений (хотя можно передать эту функцию в службу сопровождения)
Плюсы:
1. не нужно писать код для каждого нового идентификатора
2. легко править описания для идентификаторов, если возникла такая возможность
Проблема моя вот в чем – как мне правильно поступить? Либо переписать СТП и оставить в нем только требования, либо запихнуть в него соображения по реализации, которые у меня не совпадают с тем, что в документе есть сейчас. Либо дописать СТП с тем подходом, который предлагается сейчас.
Поясню, почему не очень хочется оставлять только требования. В силу некоторой специфики, наши разработчики больше привыкли работать с БД, нежели с парсингом текстов и я на 90% уверен, что если оставить СТП так, как есть, никто не будет возражать. Напишут разбор на PL/SQL и все. Кроме того, обычно мы не используем внешних библиотек и еще и поэтому такая мысль может никому в голову не придти.
Просмотр сообщений
