Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Темы - 474

Страницы: 1
1
Идеи и мозговой штурм / XSD -> документ
« : 03 Октября 2013, 15:17:31 »
Добрый день.

Подскажите, кто-нибудь знает ПО или сервис, который мог бы по XML схеме создать описание в читаемом бизнес-пользователями виде?
Или хотя бы рыбу для такого описания.
Нужно массу описаний XSD схем включить в документы.

Поясню, что я имею в виду.

Есть вот такая схема (для примера взял с w3schools.com):
<?xml version="1.0" encoding="ISO-8859-1" ?>
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
 <xs:element name="shiporder">
   <xs:complexType>
     <xs:sequence>
       <xs:element name="orderperson" type="xs:string"/>
       <xs:element name="shipto">
         <xs:complexType>
           <xs:sequence>
             <xs:element name="name" type="xs:string"/>
             <xs:element name="address" type="xs:string"/>
             <xs:element name="city" type="xs:string"/>
             <xs:element name="country" type="xs:string"/>
           </xs:sequence>
         </xs:complexType>
       </xs:element>
       <xs:element name="item" maxOccurs="unbounded">
         <xs:complexType>
           <xs:sequence>
             <xs:element name="title" type="xs:string"/>
             <xs:element name="note" type="xs:string" minOccurs="0"/>
             <xs:element name="quantity" type="xs:positiveInteger"/>
             <xs:element name="price" type="xs:decimal"/>
           </xs:sequence>
         </xs:complexType>
       </xs:element>
     </xs:sequence>
     <xs:attribute name="orderid" type="xs:string" use="required"/>
   </xs:complexType>
 </xs:element>
 </xs:schema>

Нужно получить вот такую таблицу:
TagMinMaxType
.shiporder11
.orderid(shiporder)string
..orderperson11string
..shipto11
...name11string
...address11string
...city11string
...country11string
..item1*
...title11string
...note01string
...quantity11positiveInteger
...price11decimal
(Точки перед наименованием элементов и атрибутов я добавил чтобы была видна вложенность, пробелы длиной более одного в сообщении заменяются на один, поэтому их не видно)

2
Добрый день.

Рассматриваю вопрос создания системы, которая будет составлять расписание тренировок для спортсменов (пока ограничимся качками, далее возможно добавление других видов спорта).

Хочется в итоге иметь что-то такое, что позволит указать пользователю свои параметры (рост, вес, возраст, пол, данные по силовым показателям, данные по показателям выносливости), свои цели (похудеть, набрать массу, достичь (опредененного/неопределенного) прогресса в каких-то упражнениях), предпочитаемые стили тренировок, длительность тренировок, количество недель в программе, количество тренировок в неделю и получить готовую программу на весь период.

При этом желательно чтобы алгоритм учитывал различные существующие (ново/модные) методики составления тренировочных планов. А их целая куча и постоянно появляются новые/опровергаются старые. Для примера - есть принципы "пирамиды", "прогрессирующей нагрузки", "супер-сеты", "предварительного утомления", "периодизации", "шокирования", "изоляции", "статика", "негативы", "частичная амплитуда", "баланс", "принцип базовых упражнений", "круговые тренировки", "скоростные упражнения" и много чего еще. Что-то сочетается друг с другом, что-то нет. И это только у качков, в других видах спорта тоже немало ))

Кроме того желательно еще и что-бы оценивался такой параметр как общая нагрузка и выдавались рекомендации не только по тренировкам, но и по отдыху (возможно и советы по препаратам, которые стоит использовать).

Соответвенно нужно как-то задать возможность гибко описывать "кирпичики" из которых будет составляться план тренировок и "правила" составления этого плана.

Самому пришла в голову параметрическая модель в основу которой положены упражнения, масса параметров для каждого упражнения, в том числе и оптимальные параметры выполнение данного упражения. Это "кирпичика". А "правила" создаются матрицей совместимости "кирпичей" по параметрам оптимальности выполнения. Но что-то мне не нравится громоздскость решения. Да и не системно это как-то выглядит.

Вопрос - где можно почитать про оптимальные пути задания таких правил и описаний? Не хочется создавать велосипед и наступать на грабли.

3
По работе поставили задачу закончить СТП, начатое другим человеком.

Перед тем, как начать писать хочется представить себе возможные пути реализации, т.к., честно говоря, не нравится то, что сейчас в документе явно прослеживается не очень, по моему мнению, оптимальный вариант решения проблемы. Сразу замечу, что то, что у нас называется СТП – это некий гибрид ТЗ и ТП, то есть описываются и требования, и предлагаемые пути реализации. При этом разработчики могут по прочтению СТП сразу взяться за реализацию или написать свой ТП.

Ниже напишу еще свои соображения, а пока задача.

Суть задачи: Есть поток текстовых данных, разделенных на блоки. В каждом блоке требуется найти некий (или некие, если их несколько) идентификатор, вычислить (если требуется) контрольное значение для него и выдать в отдельный файл, возможно обработав перед этим.
Идентификатор: Последовательность символов в большинстве случаев описываемая в широких пределах.

Например, строка из арабских цифр длинной от 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 и все. Кроме того, обычно мы не используем внешних библиотек и еще и поэтому такая мысль может никому в голову не придти.

4
А то вот нарисовал, а что это...   ;D
Activity подходит, нет?


5
Добрый день.

Я не знаток UML, мне просто показали как EA пользоваться. С диаграммами по хелпу разбираюсь.
Нарисовал для себя диаграмму деятельности по обработке платежных требований и инкассовых поручений.
Но не уверен, что нарисовал правильно с точки зрения нотации. Точнее уверен, что ошибки есть.
Может кто-нибудь указать на них?

Страницы: 1