46

Проектирование / Re: Сравнение трёхзвенки (MVC) и варианта с переносом части бизнес-логики в СУБД

« : 11 Августа 2014, 11:45:03 »

Думаю, что лучшее место для таких обсуждений — sql.ru

- Денис, согласен, но все же решил выложить на всякий случай.

Почему не рассматриваете SQL Server? Непонятно.

- Не рассматриваю, т.к. у нас на работе существует нечто вроде стандарта организации, согласно которому

существуют две основные СУБД: Oracle - для сторонних систем и IBM DB2 - для систем, разрабатываемых своими силами.

- Это ограничение, на которое я, к сожалению (или к счастью), практически не могу сейчас повлиять. Кстати, на SQL server у меня развернуты модельные репозитории SPARX EA )))
Так что,

После 5 лет разработки ХП на Оракле, для простых систем настоятельно рекомендую рассматривать сначала более простые технологические связки, типа php + mysql

- к сожалению, не в моей компетенции.

Ну и это — покажите требования к качеству системы, тогда можно будет обсуждать более предметно.

- Вот что мне пока известно -

Нагрузка на БД целевой системы - порядка 150000 запросов в сутки, количество пользователей, работающих с веб-интерфейсом - порядка 20 сотрудников.

СУБД развернута на виртуальном сервере, параметры производительности пока что неизвестны, но известно, что при использовании СУБД DB2 периодически возникают "просадки" по производительности, чего не наблюдается, предположительно, при использовании Oracle со схожей конфигурацией платформы.
По поводу сравнения DB2 и Oracle наткнулся в форуме sql.ru на такую тему:
Oracle vs DB2
Вот такая фраза привлекла внимание:

у этих субд совершенно противоположные идиологии - оракл версионник, дб2 блокировочник

и ответ:

IBM-еры довольно много постарались для совместимости. Вплоть до того, что пустая строка может трактоваться, как NULL, а многие раньше блокирующие вещи теперь не блокируют. Нынешняя DB2 по совместимости... ну... примерно на уровне 9-го Oracle.

Читаю далее...

47

Проектирование / Сравнение трёхзвенки (MVC) и варианта с переносом части бизнес-логики в СУБД

« : 08 Августа 2014, 17:09:22 »

Коллеги, наткнулся на такую вот статью на хабре Где наша бизнес-логика, сынок?
У меня на работе завязался нешуточный спор по теме, что лучше:

• Вся бизнес логика реализована в приложении на сервере приложений (IBM WebSphere);
  
• Часть бизнес логики реализована на уровне БД в хранимых процедурах, приложение на сервере приложений используется, в основном, в качестве GUI (view)[четырехзвенка или недотрехзвенка?];
  

Дополнительно стоит добавить еще такие моменты:
У нас на работе существуют две основные СУБД: Oracle - для сторонних систем и IBM DB2 - для систем, разрабатываемых своими силами. Еще есть SQL Server, но его не будем рассматривать.
Нагрузка на БД целевой системы - порядка 150000 запросов в сутки, количество пользователей, работающих с веб-интерфейсом - порядка 20 сотрудников.
У меня вопрос к тем, кто сталкивался с подобным выбором:
Какой вариант будет предпочтительнее из приведенных ниже?

• Вся бизнес логика реализована в приложении на сервере приложений (IBM WebSphere), целевая СУБД - IBM DB2;
  
• Часть бизнес логики реализована на уровне БД в хранимых процедурах, приложение на сервере приложений используется, в основном, в качестве GUI, целевая СУБД - IBM DB2;
  
• Вся бизнес логика реализована в приложении на сервере приложений (IBM WebSphere), целевая СУБД - Oracle;
  
• Часть бизнес логики реализована на уровне БД в хранимых процедурах, приложение на сервере приложений используется, в основном, в качестве GUI, целевая СУБД - Oracle;
  

48

Примеры / Re: Диаграмма классов - подкорректируйте\ подскажите

« : 11 Июля 2014, 17:25:37 »

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


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

Тогда класс страхуемый вообще не нужен - агрегируй класс клиент и класс словари (фигнюшка) в договор страхования, раз пошла такая пьянка, будем бредить до упора, главное до "белочки" не доводить)))

49

Примеры / Re: Диаграмма классов - подкорректируйте\ подскажите

« : 11 Июля 2014, 15:21:07 »

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

На текущей диаграмме отображено множественное наследование - класс страхуемый содержит свойства классов клиент и словари.
Если я правильно понял, классы словари и клиент должны содержать свойства класса страхуемый.
И замени композицию на агрегацию.

50

Примеры / Re: Диаграмма классов - подкорректируйте\ подскажите

« : 11 Июля 2014, 09:49:05 »

1. Стрелки генерализации для страхуемого должны быть в обратную сторону.
2. Композицию замени на агрегацию.

Для начала сойдет и так.

51

Задачи студентов / Re: Диаграмма прецедентов простого антивируса

« : 20 Мая 2014, 04:37:31 »

Можно добавить отдельный вариант использования "Обработать инфицированный объект" в качестве расширения варианта использования "Сканировать Систему" с указанием точек расширения - шагов сценария, на которых возможно выполнение сценария расширяющего варианта использования.

52

Задачи студентов / Re: Диаграмма прецедентов простого антивируса

« : 19 Мая 2014, 16:58:40 »

под "Сканировать Систему" имеется ввиду всё что угодно, но не разрабатываемая система (SuD) - дополнительный аспект)))

53

Задачи студентов / Re: Диаграмма прецедентов простого антивируса

« : 19 Мая 2014, 16:14:23 »

Хотя дочерние настройки можно включить в родительский вариант использования в качестве шагов варианта использования.

54

Задачи студентов / Re: Диаграмма прецедентов простого антивируса

« : 19 Мая 2014, 13:58:41 »

Вот так будет правильнее, как считаете, коллеги?

55

Конференции Семинары и Тренинги / Re: Курсы по аналитике

« : 13 Мая 2014, 19:30:04 »

Елена, а нас в Киев пустят, на таможенном контроле не развернут? А то знакомого с женой не пустили пару недель назад.

56

Sparx / Re: FAQ - Sparx Enterprise Architect

« : 24 Февраля 2014, 17:35:10 »

В Data Modeling связи между элементами типа Table задаются в форме Operations, как в элементах типа Class.
Т.е.:
1. Создаешь 2 таблицы с атрибутами и прописанными PK.
2. Создаешь между ними связь (Association) - причём для связи, например, один-много тянешь стрелку от много (source) к один (target)
3. Вызываешь контекстное меню на Association, на диаграмме, и выбираешь пункт Foreign Keys...
4. Выбираешь атрибут в Source. Выбираешь атрибут в Target (PK). Жмешь Apply.
5. Если всё правильно сделал, получаешь  подобную картинку:

57

Sparx / Re: FAQ - Sparx Enterprise Architect

« : 24 Февраля 2014, 14:53:49 »

Извиняюсь за беспокойство) У меня снова вопрос к знающим людям)
Начал рисовать ERD модель базы.
В целом все ясно: таблицы, атрибуты и связи. Но есть один момент. По феншую надо соединять таблицу с таблицей через связь типа Relationship. В примерах в хелпе написано так, в описании нотации Чена то же самое.
Мне же нужно соединять таблицы не просто так(таблица-таблица, без подробностей), а по конкретному атрибуту(внешнего ключа), тк этот атрибут в моем случае будет связываться с полем на экранных формах.
Можно конечно построить связь как Таблица - Атрибут внешнего ключа - Таблица, но это нарушение нотации и у меня нет уверенности, что это не выплывет где-то еще. Подскажите пожалуйста, как решить этот вопрос правильно?

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

58

Sparx / Re: FAQ - Sparx Enterprise Architect

« : 21 Февраля 2014, 14:10:33 »

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

plattark

, вот описание, как подружить метод класса с use cases и activity:
http://www.sparxsystems.com/enterprise_architect_user_guide/10/software_engineering/create_use_case_for_method.html
http://www.sparxsystems.com/enterprise_architect_user_guide/10/modeling_basics/generated_activity_diagram.html
http://www.sparxsystems.com/enterprise_architect_user_guide/10/standard_uml_models/class_operations_in_activity_d.html
Ну и структурированная activity:
http://www.sparxsystems.com/enterprise_architect_user_guide/10/standard_uml_models/loop_and_conditional_nodes.html

Для детализации конкретного метода подойдёт структурированная активность (на уровне самого метода) с вложенной активностью, описывающей реализацию конкретного метода

59

Идеи и мозговой штурм / Re: UML диалекты

« : 13 Февраля 2014, 09:24:28 »

Коллеги, возможно речь об этом - http://ru.wikipedia.org/wiki/Meta-Object_Facility.
Есть стандарт MOF от OMG, применяется в model-driven development (разработке, управляемой моделью). Актуальна версия 2 от 2006 года.
т.е. под диалектами UML, возможно, понимаются метамодели MOF уровня M2 (всего описано 4 уровня метамоделей: M0, M1, M2, M3). M3 - собственно, само ядро MOF, M2 - как раз UML, M1 - конкретные UML-модели, M0 - описание объектов реального мира.

60

Для всех / Re: Анализ информационно-комуникационной инфраструктуры

« : 31 Января 2014, 14:08:07 »

Стандартов много. Например, ГОСТ-34