Case средства и Lotus.

[Azrael]

Хочу еще раз поднять тему https://codeby.net/threads/1594.html поскольку в ближайшее время прийдется писать диплом и под это дело можно какой-нибудь из своих проектов подбить.
Целиком согласен, что по крайней мере, для небольших проектов в Lotus case-средства ни к чему. Один из шикарнейших плюсов Лотуса в том, что расширить систему, как правило, намного проще, чем переделать реляционную базу. Если правильно базу делать, конечно: досталась одна база в наследство с нереальным количеством связей между документами (где, например, в поле одного документа хранился лист UNID'ов других документов). В итоге все глючило и стремительно покрывалось конфликтами... исправить ошибку, произошедшую из-за какого-нибудь конфлика где-нибудь не считалась сумма стоило кучи нервов.
Тем не менее, в дипломе мы вроде как проектируем, соответственно нужно рисовать всякую ерунду... Соответственно, прошу поделиться дельными мыслями насчет case-средств.

 

[Mihal]

Сущности (типы документов в базе) никто никуда не девал. Рысуешь стрелочки, над ними малюешь "$ref" или название итема, содержащегно ссылку на другой документ. Получил связи между документами. Практически структуру системы!

В качестве свойст таких классов можешь намалевать основне реквизиты документов. Опять же, диаграмму последовательности действий тоже никто не отменял. Равно как и диаграму прецедентов. Да и диагрмму классов можно подключить, между прочим.

Форма - тоже класс. Методы этого класса - отображение всяческих кнопочек и экшенов в экшен-баре. Каждая форма связаны с документом. Типа, документ - одно из свойст класса формы.

Покопаюсь - найду статью из The View на эту тему.

 

[Azrael]

Для: Mihal
Т.е. учить UML... А как там, например, ситуацию "многие ко многим" описывать, ну, например, есть накладная и есть документы оплаты. Один документ оплаты может оплачивать несколько накладных, в одной накладной может быть много документов оплаты. Физически решаю через поле типа "лист" со значениями типа номер|дата//сумма и хитрым видом. И вообще в последнее время респонсы использую, но нечасто, чаще привязываю по значению поля или нескольких полей...
За статью буду очень признателен.

 

[Mihal]

<!--QuoteBegin-Azrael+6:10:2007, 09:37 -->
<span class="vbquote">(Azrael @ 6:10:2007, 09:37 )</span><!--QuoteEBegin-->Т.е. учить UML... А как там, например, ситуацию "многие ко многим" описывать, ну, например, есть накладная и есть документы оплаты. Один документ оплаты может оплачивать несколько накладных, в одной накладной может быть много документов оплаты. Физически решаю через поле типа "лист" со значениями типа номер|дата//сумма и хитрым видом. И вообще в последнее время респонсы использую, но нечасто, чаще привязываю по значению поля или нескольких полей...
За статью буду очень признателен.

[snapback]80846" rel="nofollow" target="_blank[/snapback]​

[/quote]

Погодь! А как ты хотел? Использовать case-средства и ничего не учить? "Эх, маладёжжжжь"(с) B).

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

P.S. Статью поищу на работе. Должна быть.

 

[Azrael]

Для: Mihal
Задача: написать диплом и забыть В универе учат er-win / bp-win. Учет давно написан, даже, частично, мной, и даже работает B) Шеф в восторге. Сча в основном, какие-либо замороченные вещи пишем.
Case-средставами пользуемся, но мало. Были попытки вводить BPWin, но клиенты сами не знают, чего хотят, в стандартах разбираться не хотят и толку много от него много не было.

 

[Mihal]

А там и не надо разбираться. Главное уловить и договориться между собой о специфических обозначениях. Use-Case Диаграммы пользователь словит на ура. А дальше от них плясать можно и без него.