всем доброго времени суток.

вот уже сколлько времени пыьаюсь описать проект и его работу в UML
и чесно говоря ничего толкомто и не получается. кажись.

вот выкладываю тут диаграмму нарисованную сегодня утром.. и хотел бы услышать критики на счет этого.
не то что "что за отстой. долой диаграмму. Бан на афтара."

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

и вообше буду благодарен за любые коментарии.

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

В Вашей диаграмме написано следующее:
MainThread посылает команду на выполнение Input Output Sys
После получение реакции о удачном запуске его, MainThread  инициализирует запуск доступа к БД.
При этом Input OutPut Buffer по неизвестной причине посылает запрос на чтение пакетов из очереди на отправку
Вслед за этим действом MainThread создает массив и передает ему управление
При этом Input Output Sys с какого-то перепугу вставляет какие-то прочитанные пактеы в очередь на исполнение вероятно и преедает это объекту класса Input OutPut Buffer, который в свою очередь сразу передает какую-то непонимаемую мною команду массиву.
Массив получив команду обращается к БД за информацией о клиенте (каком забавно?), получив оную активно обрабатываает запрос ( в каком интересно смылсе), обработав запрос, заносит непонятные изменения (в чем) в базу обратившись к доступу к БД

Резюме - бред сивой кобыли - извините за резкость

Здравствуйте Galogen. спосибо за ответ.
чесно говоря ваш ответ был почти идеален и не обижаюсь за рескость так как мне тоже кажется что это - бред сивой кобыли.
просто конкретные сложности в освоении uml

и так попытаюсь обьяснить с начала:
хочу сделать большой проект. хочу с начало его спроектировать. хочу воспользоваться всеми благами которые предоставляет uml для создания большого проекта.

но не знаю я какой стороны подобраться.

один хороший человек посоветовал мне начать с создания с описания структуры системы.
но я не нашел диаграммы UML в котором это можно нарисовать. вот и решил сделать это sequences.

для меня как для программиста удобнее было бы все описать Блоксхемами которых в UML я тоже не нашел..
читал что систему надо описывать с раздных сторон.

классы описывать вообшем то безтолку. там один основной класс. который делает основную часть работы.

с чего вы начинаете проектирование больших систем???

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

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

сверху??? вы имеете в виду диаграмму деятельности???

в UML точно нету струтур для описания блок схем??

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

в UML точно нету струтур для описания блок схем??

\
Activity

сверху??? вы имеете в виду диаграмму деятельности???

Нет я имел в виду немного другое 

Но вообще системный подход рулит- контекст, декомпозиция контектса, декомпозиция декомпозиции и т.д.
При чем UML позволяет делать это и по функциональному признаку и по объектному.

в UML точно нету струтур для описания блок схем??

диаграмма деятельности часто называется ОО блок-схемой. По сути она и есть, да еще более удобная чем собственно блок-схема. Начальное и конечно состояние есть. Логический элемент есть. Есть действие - акшин и деятельность - активити - сиречь процедура, котора легко может быть декомпозирована на другой диаграмме.

Но функциональный подход в ОО не рулит, реализация идет не по функциям, а по объектам реализующим нужные фичи

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

Многие утверждают - достаточно диаграммы классов и OCL. Возможно так и есть - особенно в вашем случае.

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

Далее вы уже обдумываете это дело внимательно, смотрите принципы GRASP (разделения обязанностей), вспоминаете инь-ян ООП, пытаетесь создать накой набор классов, который обеспечивает основное преимущестов ООП - повторное использование, расширяемость, модифицируемость проекта - если это надо. А коли это не так важно, то может все будет сделано 1 классом - простору творчества нет границ

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

passer, странная у Вас диаграмма.
Для начала вспомним, что диаграмма деятельности - это объектно-ориентированная блок-схема. Она имеет дополнительные моменты: распараллеливание, передачу сигналов и их прием, сигналы времени, плавательные дорожки и другие моменты.

теперь смотрим на Вашу диаграмму. Если рассмотреть разные цепочки событий и действий, не трудно заметить, что в определенные моменты происходит передача управления некоторому объекту и все назад дороги нет

либо логика переход явно очень запутанная. В частности - финализировать все - как данному действию передается управление? Синхронизировать добавление заявок в буфер - пришли и что?

>теперь смотрим на Вашу диаграмму. Если рассмотреть разные цепочки событий и действий, не трудно заметить, что в определенные моменты происходит передача управления некоторому объекту и все назад дороги нет

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


>либо логика переход явно очень запутанная. В частности - финализировать все - как данному действию передается управление?
не с программы. могу ошибатся но думаю программа сама заканчиваться никогда не будет.
а оканчивания или через сокеты. или просто системное прерывание работы(kill -9 ).

>Синхронизировать добавление заявок в буфер - пришли и что?
при синхронизированном добавлении заявок в буфер они попадяют некий буфер которым владеет обьект класса requestBuffer.а потом из этогоже буфера это request при помоши метода getReceivedRequest тогоже класса.




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

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

Добавлю вопросом. А зачем собственно вы создаете диаграмму? Чтобы понять логику работы? Чтобы дать возможность понять другим? Или просто нарисовать картинку и отчитаться?

ДД по сути алгоритм, а алгоритм должен быть понятным и приводит к конечному результату. ДД - не диаграмма состояний, может вам лучше отобразить свою логику именно через конечный автомат?

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

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

можно узнать что такое ДД, Мукс и демукс??
а то поиски ничем не увенчались.

можно узнать что такое ДД, Мукс и демукс??
а то поиски ничем не увенчались.

а то поиски ничем не увенчались.

Мукс и Демукс - это из Matlab мультиплексор - собственно собиратель потоков, демультиплескор - собственно разбиватель потоков - андерстуд?

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

При этом часто путаеют множественный выбор и разветвление распараллеливание потоков. Выбор значит ОСТАТЬСЯ ДОЛЖЕН ТОЛЬКО ОДИН - и им будет ДУНКАН МАКЛАУД