31

Бизнес-анализ и Целеполагание / use case как описать что процесс может при необходимости повторяться

« : 27 Сентября 2016, 10:59:03 »

Есть система учета за комплектующими автомобиля. У автомобиля есть двигатель, шасси, кабина, коробка и т.д. В систему пользователь последовательно вводит все части авто. Как отразить в сценарии, что пользователь может вести

Пример:
Условие:
Открыт форма учета составных частей автомобиля
Сценарий:
1.   Пользователь нажимает на кнопку «Добавить»
2.   Система создает и выделяет строку для ввода в поля значений
3.   Пользователь нажимает двойным кликом ЛКМ на поле «Наименование составной части» и в выпадающем списке нажимает на ссылку «Показать все»
4.   Система открывает новое окно «Список составных частей»
5.   Пользователь в указанном списке выбирает и нажимает ЛКМ на наименование составной части
6.   Система отображает выбранное наименование составной части в поле «Наименование составной части»
7.     Система автоматически отображает серийный номер выбранной составной части в поле «Серийный №»

8.     Пользователь при необходимости продолжает вводить новые позиции составных частей (согласно п.1-6 сценария)

9. Пользователь переходит в раздел "Компоненты" формы учета составных частей

Вот такая, п.8, формулировка уместна? Или как то иначе переформулировать требуется или переоформить?

с уважением

32

Системный Анализ и Требования / Re: Описание алгоритма отображения знаения в отчете

« : 05 Августа 2016, 16:31:48 »

А что не так? все вроде правильно, все сливается в один, т.е. результат, оценка результата всех вычислений

33

Системный Анализ и Требования / Re: Описание алгоритма отображения знаения в отчете

« : 05 Августа 2016, 08:53:48 »

Откорректировал диаграмму, добавил блок при отсутствии записи и в нижней части диаграммы о результатах вычислений.

Текстовое описание алгоритма:
1.   Проверка на наличие записи во вкладке «записи о произведенном ремонте» раздела «Ремонт автомобиля»
2.   Запись есть.
3.   Если запись последнего  ремонта имеет в поле «Вид ремонта» запись «Капиталка», то осуществляется вычисление по формуле указанное в пункте А.
4.   Если результат вычисления от 1% до 10%, то указанный объект записывается в данную графу. Если результат при вычислении иной, то объект записывается в соответствующем столбце (столбце "10% до 40%" или "40% до 80% и т.д.).
Альтернативный поток:
2а. Записи нет
2а.1. Осуществляется вычисление по формуле указанное в пункте Б.
2а.2. Переход в п.4
3а. Если запись последнего ремонта имеет в поле «Вид ремонта» запись «Текущий», то осуществляется вычисление по формуле указанное в пункте В.
3а.1. Переход в п.4.

Формула:
А) ((Числовое значение вид ремонта «Капитальный» - Фактическая наработка объекта)/Числовое значение  вид ремонта «Капитальный» раздела «Нормативные ремонты»))*100%
Б) (Числовое значение вид ремонта «Текущий» - значение поля «С момента выпуска автомобиля»/Числовое значение вид ремонта «Текущий»)*100%
В) ((Числовое значение вид ремонта «Текущий» - Фактический пробег автомобиля с даты выхода из ремонта)/Числовое значение поля вид ремонта «СР»))*100%

34

Системный Анализ и Требования / Re: Описание алгоритма отображения знаения в отчете

« : 04 Августа 2016, 18:36:27 »

У меня не было опыта рисования диаграмм. Нарисовал примерную блок схему алгоритма (диаграмма активности).
Посмотрите пожалуйста, корректно ли блок схема?


Алгоритм:
1.   Проверка на наличие записи во вкладке «записи о произведенном ремонте» раздела «Ремонт автомобиля»
2.   Запись есть.
3.   Если запись последнего  ремонта имеет в поле «Вид ремонта» запись «Капиталка», то осуществляется вычисление по формуле указанное в пункте А.
4.   Если результат вычисления от 1% до 10%, то указанный объект записывается в данную графу. Если результат при вычислении иной, то объект записывается в соответствующем столбце (столбце "10% до 40%" или "40% до 80% и т.д.).
Альтернативный поток:
2а. Записи нет
2а.1. Осуществляется вычисление по формуле указанное в пункте Б.
2а.2. Переход в п.4
3а. Если запись последнего ремонта имеет в поле «Вид ремонта» запись «Текущий», то осуществляется вычисление по формуле указанное в пункте В.
3а.1. Переход в п.4.

Формула:
А) ((Числовое значение вид ремонта «Капитальный» - Фактическая наработка объекта)/Числовое значение  вид ремонта «Капитальный» раздела «Нормативные ремонты»))*100%
Б) (Числовое значение вид ремонта «Текущий» - значение поля «С момента выпуска автомобиля»/Числовое значение вид ремонта «Текущий»)*100%
В) ((Числовое значение вид ремонта «Текущий» - Фактический пробег автомобиля с даты выхода из ремонта)/Числовое значение поля вид ремонта «СР»))*100%

35

Системный Анализ и Требования / Re: Описание алгоритма отображения знаения в отчете

« : 04 Августа 2016, 16:40:16 »

Тоже начал склоняться к диаграмме.
МОжете подсказать:

1. Какие диаграммы проще использовать? на какой нотации? чтобы можно было за 5 минут освоить
2. Можете привести примеры алгоритмов сделанных с помощью диаграмм?

36

Системный Анализ и Требования / Re: Описание алгоритма отображения знаения в отчете

« : 04 Августа 2016, 07:57:56 »

Здравствуйте.

На данном этапе необходимо именно текстовое описание.

По моему проблема с содержанием. Вам понятен алгоритм?

37

Системный Анализ и Требования / Описание алгоритма отображения знаения в отчете

« : 03 Августа 2016, 18:32:59 »

Здравствуйте.
Имеется отчет, значение поля которого рассчитывается по алгоритму.
Таблица 1.
Наименование автомобиля   Запас ресурса до ремонта
                                              3% до 9%   9% до 20%  .....
         
Алгоритм:
1.   Проверка на наличие записи в разделе «Ремонт автомобиля»:
2.а.   Запись есть.
3.а.1.Если запись последнего ремонта имеет в поле «Вид ремонта» запись «Капитальный», то
осуществляется следующее вычисление:
Значение фактического пробега автомобиля с даты выхода из ремонта до текущей даты/Нормативное значение для капитального ремонта
3.а.2.Переход к п.4.
3.б.1.Если запись последнего ремонта имеет в поле «Вид ремонта» запись «Текущий», то осуществляется следующее вычисление:
Значение фактического пробега автомобиля с даты выхода из ремонта/Нормативное значение для текущего ремонта
3.б.2.Переход к п.4.
4.  Если результат при вычислении больше 3 но меньше 9%, то указанный автомобиль записывается в данную графу. Если результат при вычислении иной, то переход к описанию в другом столбце.
2.б. Записи нет.
2б.1.Осуществляется следующее вычисление:
Значение фактического пробега автомобиля с даты ввода в эксплуатацию до текущей даты/Нормативное значение для текущего ремонта
2б.2.Переход в п.4


Я хоть и написал алгоритм, но мне он не очень нравиться. Порекомендуйте пожалуйста, как можно улучшить понятность описания алгоритма? Понятен ли алгоритм? Алгоритм описывается текстом. Графики не нужны.

38

Системный Анализ и Требования / Re: Есть у кого образцы ТЗ (требований) к работе с данными (MDM)? (сопоставление))

« : 03 Августа 2016, 09:50:02 »

Новая версия да нужно создавать, как вариант. Новая версия - это результат сопоставлений должна быть наверное. Т.к. поступает разного (и неполного) объема информация с разных объектов. Пример:

С сервера №2 поступает  на сервер №1 сведения:
ООО Маяк
Количество сотрудников: 690
Дата получения информации: 10.10.2016

С сервера №3 поступает на сервер №1 сведения:
ООО Маяк
Месторасположение: Россия
Дата получения информации: 11.10.2016

С сервера №4 поступает на сервер №1 сведения:
ООО Муяк
Месторасположение: Россия
Координаты: 45 45 545, 5454
Сотрудников: 1000 человек
Дата получения информации: 10.10.2016

В итоге на сервере должно быть запись (результат сопоставлений и т.д.):
ООО Маяк
Месторасположение: Россия
Координаты: 45 45 545, 5454
Сотрудников: 1000 человек

Смысл в том, что объект не может быть ни закрыт, ни изменен. Но может быть закрыта текущая версия объекта и выпущена новая. Это не только решает вашу проблему на уровне элементарных правил, но и позволяет делать много фокусов, вроде ввода нового значения классификатора будущим периодом (актуально для тарифов, изменяющихся в будущем).

39

Системный Анализ и Требования / Re: Есть у кого образцы ТЗ (требований) к работе с данными (MDM)? (сопоставление))

« : 02 Августа 2016, 15:54:01 »

Кстати, хорошая идея реализации. А есть ли эта книга на русском языке?

Книга: "Developing Time-Oriented Database Applications in SQL" от дремучего 2000 года. На хабре утверждают, что сейчас она раздается бесплатно. https://habrahabr.ru/post/191312/

Смысл в том, что объект не может быть ни закрыт, ни изменен. Но может быть закрыта текущая версия объекта и выпущена новая. Это не только решает вашу проблему на уровне элементарных правил, но и позволяет делать много фокусов, вроде ввода нового значения классификатора будущим периодом (актуально для тарифов, изменяющихся в будущем).

40

Системный Анализ и Требования / Re: Есть у кого образцы ТЗ (требований) к работе с данными (MDM)? (сопоставление))

« : 27 Июля 2016, 08:39:52 »

Иерархия многоуровневая и многокорневая.
Состав атрибутов один и тот же.

41

Системный Анализ и Требования / Re: Есть у кого образцы ТЗ (требований) к работе с данными (MDM)? (сопоставление))

« : 26 Июля 2016, 17:56:42 »

Да вроде это и нужно. Можете дать какой либюо образец подобного описания?
Как описываются сопоставления, "сведение" на примере?

На серваке №1 имеются следующие данные:
1. ООО "Маяк" (Россия)
 1.1. ООО "Филиал 1 маяка"
 1.2. ООО "Филиал 2 маяка"

На сервере №2

1. ООО "Маяк" (Россия)
1.1. ООО "Филиал 2 маяка"

Проблема: При получении из другого сервера данные по умолчанию сливаются в БД (т.е. происходит замена существующих данных на поступившую). Но если сервер не найдет присланные данные об объекте в текущем сервере создаст новый объект (возможно будет дубль данных)

Нужно: чтобы система при получении из другого сервера данные
а) находила аналогичный объект в базе данных текущего сервера
б) если найдет, не стирала текущие данные, а с помощью сопоставления заменяла/дополняла данные.












Само сопоставление данных должно сводится к mapping (Сущность исходная, Атрибут исходный, Сущность целевая. Атрибут целевой, Правило преобразования)

При этом правило преобразования - это что-то простое (типа функции строка в дату), а не некоторая волшебная палочка

Поскольку вся интеграция идет черех xml или rest, то интеграционщики захотят в итоге именно такой формат. А обработка всех исключений, более сложные преобразования и т.д. должны быть описаны ранее в "обвесе". Если это интеграция, то это опять же оправдано, поскольку интеграционщики будут брать описания триггеров из одного места, а не выцеплять их из всего проекта.

42

Системный Анализ и Требования / Есть у кого образцы ТЗ (требований) к работе с данными (MDM)? (сопоставление))

« : 26 Июля 2016, 13:23:03 »

Приветствую!

Кто нибудь может поделиться ссылками или файлами с образцами описания требований к работе с данными MDM?
Как сопоставляться будут, как сравниваться объекты.

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

Сервер №1
-Азербайджан
-Грузия
-Германия
-.... и т.д.
-Россия:
1. ООО "Маяк" (Россия)
 1.1. ООО "Филиал 1 маяка"
 1.2. ООО "Филиал 2 маяка"

На сервере №2
-Азербайджан
-Грузия
-Германия
-.... и т.д.
-Россия:
1. ООО "Маяк"


Нужно образец описания как вообще сопоставлять эти данные..



Начало темы:
http://www.uml2.ru/forum/index.php?topic=6592.0

43

Системный Анализ и Требования / Re: Описание проверки при получении данных из другого сервака

« : 26 Июля 2016, 12:06:54 »

Спасибо! Скорее всего это то что нужно.
А проверять на наличие эталонной по какому принципу? по стране и наименованию?

3.2. Или если это невозможно, то при создании объекта в другой базе, проверять на наличие в эталонной, если нет в ней, то заводить новый элемент в двух базах и присваивать уникальный идентификатор в эталоне и в базе создателе.

44

Системный Анализ и Требования / Re: Описание проверки при получении данных из другого сервака

« : 22 Июля 2016, 08:56:53 »

1. Спасибо. Предполагается что будет так: Каждый объект внутри сервера будет иметь свой уникальный идентификатор (suid). UUiD ассоциирован с suid. При отправке этого объекта на другой сервер, отправляется UUiD
В момент получения объекта другой сервер проверяет на наличие объекта с указанным идентификатором UUiD.
Если есть сопадения, осуществляется запись. Если совпадения нет, переход в проверке по:
-странам
-по наименованию и т.д.

5. Если будет два объекта с одинаковым именем...
Уникальный идентификатор (suid) частично не решит эту проблему... На каждом сервере заводится объект. Как сервер может привести идентификатор к единому на каждом сервере в момент заведения объекта в систему? По моему никак. Пример: На сервере №1: завели объект ООО "Маяк" ему присвоен уникальный идентификатор 0089.
На другом сервере №2 - завели объект ООО "Маяк", ему ведь не присвоиться тотже самый идентификатор? а скорее всего будет другой 1254.

Как вариант, наверное при получении объекта из другого сервера, после записи. Уникальный идентификатор этого объекта сохраниться.
Пример:
Есть объекты: сервер №1 объект ООО "Маяк" уникальный идентификатор 0089.
сервер №2 - объект ООО "Маяк"идентификатор 1254.

Получен с сервера №1 на сервер№2 объект. Осуществляется запись, идентификатор объекта на сервере №2 меняется на номер идентификатора сервера №1. После чего:
сервер №1 - объект ООО "Маяк" уникальный идентификатор 0089.
сервер №2 - объект ООО "Маяк"идентификатор 0089

Может так?

1. Нужно сделать на всех серверах единый идентификатор, просто надо, поверьте, иначе будете постоянно огребать проблемы. Постарайтесь убедить начальство.

5. Вам виднее - по каким критериям проверять, это нужно спросить у эксперта в предметной области. Я вижу сейчас две проблемы:
* Вы не сверяете Расположение (классификатор стран), что безусловно нужно делать.
* Что будете делать, если в базе приемника будет два объекта с одинаковым именем? А такое обязательно будет с подходом без уникальных идентификаторов.

45

Системный Анализ и Требования / Re: Описание проверки при получении данных из другого сервака

« : 20 Июля 2016, 16:28:45 »

Спасибо большое за ответ!

1. К сожалению уникального идентификатора не получиться сделать. Потому что знание об объектах у пользователей работающих на разных серверах разные. Объекты которые учитываются другого типа. Для примера просто привел компании. система многосерверная.  Наименования объектов на разных серваках могут не совпадать, могут вообще этого объекта не быть. Указанных объектов отсутствует такие уникальные идентификаторы как ИНН, код ОКПО и т.д. Может не совпадать вышестоящий объект, а совпадать наименование объекта и т.д.

2. Перекачка данных двухсторонняя.

3.Уровень вложенности может быть и больше. Это конечно же осложняет проверку.

4. Да я так и сделал, выделил в отдельный раздел. Так действительно удобнее.

5. Порекомендуйте пжта, а как определить по какому атрибуту стоит производить сначала проверку?
Т.к. компании есть следующие атрибуты:
Наименование (текст): Филиал №1
Организационня форма (текст): ООО
Расположение (классификатор стран): Россия
Вышестоящий объект: ООО Маяк


Для полноты картины:
-Азербайджан
-Грузия
-Германия
-.... и т.д.
-Россия:
1. ООО "Маяк" (Россия)
 1.1. ООО "Филиал 1 маяка"
 1.2. ООО "Филиал 2 маяка"

На сервере №1
-Азербайджан
-Грузия
-Германия
-.... и т.д.
-Россия:
1. ООО "Маяк"