76

Конференции Семинары и Тренинги / Осенние семинары UML2.ru — Доступ к материалам

« : 15 Сентября 2009, 11:21:19 »

Добрый день!
Хотелось бы поблагодарить организаторов семинаров, а также докладчика Сергея Нужненко. Дело важное и нужное. К сожалению, посетить все семинары не смогу, но с интересом посмотрела бы видео. Только оно у меня не отображается . Вижу только заголовок "Видеозапись семинара «Введение в системный анализ и профессию Аналитика, часть 2», проведенного Сергеем Нужненко от имени Сообщества системных аналитиков 10 сентября 2009 года. ", и ниже сразу баннер.

77

Примеры / Re: Цикл в диаграмме последовательности

« : 16 Мая 2009, 00:46:01 »

В целом я согласна с тем, что здесь проще пояснить

словами или в табличке

И все же было бы интересно отобразить визуально.

а все-таки где-то я видела диаграммы последовательностей с двумя сценариями... Попытаюсь найти.

Буду очень рада взглянуть, ну если не трудно найти, конечно

поток управления "застрянет" в верхнем loop

Вы совершенно правы. Из первого цикла (Автозапуск) мы действительно не выйдем, пока существует объект 'Таймер'. Если мне удалось наглядно это отобразить, значит, я до определенной степени преуспела в своих творческих изысканиях.

...то до нижнего управление никогда не дойдет

Почему? На ДП отображаются взаимодействия объектов, упорядоченные по времени. Таймер посылает серверу в бесконечном цикле асинхронные сообщения - ну и что? Что мешает объекту 'Клиент_Х' послать сообщение объекту 'Сервер' в любой момент времени?

78

Примеры / Re: Цикл в диаграмме последовательности

« : 15 Мая 2009, 16:27:53 »

Спасибо всем, кто ответил. Ознакомившись с Вашими соображениями и изучив некоторые образцы диаграмм (http://www.sparxsystems.com/uml_tool_guide/visual_execution_analyzer/generating_sequence_diagrams.html; http://www.ibm.com/developerworks/rational/library/3101.html), я смогла нарисовать другой вариант ДП, вероятно, более правильный, хотя с практической точки зрения для меня не очень приемлемый (поскольку таймер как самостоятельный объект мне совершенно не нужен . Все же выкладываю, просто как идею:

79

Примеры / Цикл в диаграмме последовательности

« : 15 Мая 2009, 09:43:00 »

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

80

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

« : 24 Июля 2008, 17:23:28 »

Заказчик говорит "ДА", у нас это работает именно так, т.е. бизнес-процессы верны, правила, ограничения и т.д. поняты

Это не заказчик, а просто какой-то ангел.

81

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

« : 22 Июля 2008, 12:11:40 »

Формулировать требования в любом случае стоит, как мне кажется, хотя бы для себя лично. Даже если вы автор эссе/разработчик, все нюансы постоянно в голове держать трудно. Лучше, когда они где-то описаны, и в случае возникновения вопросов можно сослаться на какой-либо документ. Разработчик, конечно, может и по коду логику восстановить (да частенько так и делается). К сожалению, у такого подхода есть по крайней мере два недостатка:
 1) получение информации о том, как работает система, может быть занять много времени, если, скажем, код чужой;
 2) получить информацию о том, как работает система, может только человек, обладающий навыками разработки.
А вообще нужно стремиться к тому, чтобы все участники процесса разработки и иные заинтересованные в успешном внедрении системы лица все-таки с требованиями знакомились - во избежание недоразумений на более поздних этапах разработки.

82

UML SysML и пр. / Re: Может ли кто-нибудь прояснить такую простую тему?

« : 07 Июля 2008, 14:55:36 »

Думаю, следует считать, что полюс ассоциации относится именно к ассоциации, а не к классу или объекту. Т.е., говорить 'объект такой-то имеет полюс такой-то' вряд ли верно. Более правильно - объект А связан с объектом В.
Вашими словами:

не класс имеет полюс ассоциации, а ассоциация связывает свой полюс с классом

все вопросы остаются

Почему остаются? 1 и 3 уходят сразу.
М.б., более наглядный пример в той же книге, рис. 12.13. (прошу прощения, приводить здесь сейчас не буду - рисовать некогда)

83

Примеры / Re: Изображение Плана счетов в UML

« : 30 Июня 2008, 16:45:14 »

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

84

Примеры / Re: Изображение Плана счетов в UML

« : 30 Июня 2008, 16:38:20 »

Чтобы не перегружать диаграмму, наверно, имеет смысл использовать пакеты.
Что-то вроде:

85

Примеры / Re: Помогите разобраться с UML

« : 25 Июня 2008, 11:17:10 »

По поводу ДК.
- на диаграмме данные базы (SettingDAO) и данные кэша друг от друга никак не зависят
- появляется третий вариант хранения того же набора настроек - SettingCollection в виде ArrayList.
Мне кажется, SettingManager предназначен для управления набором данных (SettingCollection), который может быть представлен в разных физических реализациях. При этом изменение SettingCollection должно автоматически переноситься на все реализации. Наверно, можно посмотреть в сторону паттерна 'Наблюдатель'. http://www.intuit.ru/department/pl/umlbasics/14/4.html
Прилагаю сокращенную ДК - как вариант.

И еще по поводу человечка - вряд ли он здесь нужен. Он же некую внешнюю по отношению к системе сущность обозначает.

86

Примеры / Re: Помогите разобраться с UML

« : 23 Июня 2008, 15:11:53 »

to bas: Спасибо, полезная ссылка.

to Tixo:

В системе в целом будет доработка....

Думаю, было бы неплохо иметь общее описание системы в UML-нотации, раз предполагается использовать UML ... М.б. диаграмма развертывания http://www.intuit.ru/department/pl/umlbasics/13/2.html ?..

кэшировать данные на сервере

Ну вам виднее. Наверно, в этом подходе есть свои преимущества.

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

По поводу последнего варианта диаграмм не могу ничего сказать - че-то у меня картинки отображаться перестали. (

87

Примеры / Re: Помогите разобраться с UML

« : 20 Июня 2008, 21:35:23 »

Мне кажется, из представленных диаграмм не складывается  цельного представления о системе, а поскольку требуемая доработка касается большинства ее программных компонентов, это было бы очень желательно.
М.б, я чего-то не понимаю, но по-моему, из диаграмм последовательности и действия следует, что:
1) Будет иметь место трехзвенка (клиент – сервер_приложений - БД), где 'Менеджер настроек' будет выступать для клиентов в роли сервера приложений при получении настроек.
2) 'Менеджер настроек' будет почему-то использовать оперативную память для долговременного хранения данных – эта самая хэш-таблица (наверно, здесь все-таки 'хэш’, а не ‘кэш’ ) - что как-то нетрадиционно, а к БД он обращается только в самом крайнем случае – если уж ничего не находит. Вы уверены, что так и должно быть?
Вот для клиента вполне допустимо хранить эти данные в хэше (векторе, связном списке и т.д.), но клиент у вас сам к БД не обращается.

to bas:

Реализация интерфейса не так рисуется вообще.

А где можно было бы посмотреть, как она рисуется? Вот здесь мне попадалось нечто весьма похожее: http://www.intuit.ru/department/pl/umlbasics/14/3.html. Только отношение реализации обозначено пунктиром, а не сплошной линией.

88

Теория моделирования и нотации / Re: Как изобразить функциональную схему?

« : 17 Июня 2008, 17:22:59 »

Не совсем по теме вопроса, но мне хотелось бы уточнить.
Классы 'Регистратор' и 'Монитор' связаны с классом 'Телеметрическая_система' отношением композиции. Правильно ли это? Мне кажется, что здесь скорее следует использовать агрегацию. Ведь монитор не исчезнет, если перестанет существовать телеметрическая система.

89

Идеи и мозговой штурм / Re: Тематические анекдоты и смешные истории

« : 06 Июня 2008, 14:20:46 »

Не анекдот, но реальность. PM дает задание программисту.
PM: Саша, надо сделать чтобы сетевой график был привязан к форме.
Саша(свирепо): !!!! ВЫ ЖЕ ГОВОРИЛИ,ЧТО ЭТОГО НЕ НАДО ДЕЛАТЬ!!!!!!
Саша: /через секунду/ Так это уже сделано.
Что на старой работе, что на новой - программисты не хотят работать.

 ))
Но Саша оказался очень ответственным и сознательным сотрудником.
Чаще ситуация развивается примерно так:

[PM: Саша, надо сделать чтобы сетевой график был привязан к форме.
Саша: (в сторону) Да это было еще три месяца назад! Он ПО-то хоть раз видел?
(РМ'у, громко) Да, отличная идея. Но только реализация займет немного времени.
РМ: Сколько?
Саша (после непродолжительной паузы): М-м... Ну недели три.
РМ: ?!
Саша: Долго, да? Если очень постараться, можно в две уложиться...
РМ (решительно): Это слишком большой срок!
Саша (с обидой): Ну хорошо, неделя плюс два дня на тестирование, но я снимаю с себя ответственность за работоспособность этой фичи.
РМ: Ладно, но чтоб все было реализовано. (Уходит)
Саша поворачивается к монитору и открывает http://www.trinixy.ru/