61

Задачи студентов / Re: Давайте подискутируем насчет модели

« : 29 Ноября 2010, 15:39:57 »

Давайте кратко пройдемся по диаграмме классов.
1. Не вполне понятно, что все-таки требуется сделать - систему автоматизации исполнения заказов, либо некий симулятор для, скажем, моделирования процесса обслуживания клиентов в подобной системе? Если именно систему автоматизации, то класса вроде Scheduler с его Generate_Call и т.п. в бизнес-логике и вовсе нету. Там реальный клиент вместо него будет. Если же верно второе, то такой класс допустим.
2. Водитель-авто - связь строго один-к-одному? Не знаю, соответствует ли это истине в реальном таксопарке, но для простоты пока будем считать, что это так.
3. Явно видна сущность 'Заказ' с атрибутами 'Время приема', 'Пункт назначения', 'Адрес клиента', и, возможно (если задача учебная), 'Стоимость'. Если задача реальная, со стоимостью все будет значительно сложнее.
4.У вас класс Dispatcher описывает, видимо, реального диспетчера таксопарка. А почему он из водителей состоит?... В смысле, агрегация-то там, наверно, не нужна.

Прилагаю набросок.

62

Примеры / Re: внутренняя структура

« : 19 Ноября 2010, 15:30:37 »

Простите не очень понял, это получается всю функциональность переложить на Устройство (поясните пожалуйста вашу идею по подробней)?

Да нет, функциональность контроллера при нем и остается.
Такого плана что-то. При этом методы конкретных устройств - которые здесь для наглядности названы 'ИспользоватьКонтроллерДля....()' - инкапсулируют вызовы методов Контроллера.

63

Системный Анализ и Требования / Re: Классификация требований и стандарты

« : 19 Ноября 2010, 11:18:17 »

Спасибо всем.
Презентацию Юрия я видела - она многое прояснила.

64

Примеры / Re: внутренняя структура

« : 19 Ноября 2010, 10:05:05 »

Так может и не описывать эти роли классов для ассоциаций? Оставить так, как у Вас есть, а в каждом конкретном классе Устройства добавить метод, который и будет описывать использование атрибута Контроллер для данного класса. Либо добавить этот метод еще в абстрактном классе Устройства и переопределить его в потомках.

65

Примеры / Re: Еще по диаграмме Классов

« : 15 Ноября 2010, 14:13:48 »

А Вы не пробовали экспериментировать с управлением доступом? Скажем, в свойствах агрегации Транспорт-Колесо для источника установить 'private' вместо 'public'?

66

Системный Анализ и Требования / Классификация требований и стандарты

« : 13 Ноября 2010, 16:05:58 »

Добрый день!
Хотелось бы уточнить следующее. Есть пирамида требований: бизнес-требования, пользовательские требования, функциональные требования. Плюс, соответственно, нефункциональные требования.
Описана ли эта схема в каком-либо стандарте (ISO, IEEE и т.п.), или это просто удобная классификация, предложенная Вигерсом?

67

Примеры / Re: Еще по диаграмме Классов

« : 13 Ноября 2010, 14:10:38 »

Добрый день.
Судя по первой диаграмме - не должно в Автомобиле быть абстрактных Колес. Может, это особенности отображения в RSA? Можно еще попробовать код сгенерить. Интересно, там тоже эти колеса появятся в виде атрибутов класса?

68

Теория моделирования и нотации / Re: Явная связь класса с прецедентом - бред?

« : 09 Ноября 2009, 11:10:58 »

Для этой цели лучше воспользоваться матрицей отношений.

Если не трудно, можно чуть-чуть поподробнее? Это просто компактная форма представления связей между артефактами, насколько я понимаю?
В EA, например, есть такой инструмент?
P.S. Отдельное спасибо Michaj за поднятую тему.

69

Идеи и мозговой штурм / Re: Про кашу в головах работодателей -- аналитик\техпис ...

« : 02 Ноября 2009, 11:36:07 »

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

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

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

Опытный разработчик обычно хорошо разбирается в предметной области.

Agile методы так и работают: выделенных аналитиков, как правило, нет, и выявлением требований занимается вся команда

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

70

Идеи и мозговой штурм / Re: Про кашу в головах работодателей -- аналитик\техпис ...

« : 30 Октября 2009, 16:30:43 »

Умение программировать ... служит своего рода ограничением при формировании требований

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

71

Конференции Семинары и Тренинги / Re: Серия семинаров от uml2.ru осенью в Москве

« : 30 Сентября 2009, 09:54:08 »

Добрый день!
Удастся ли выложить видео четвертого семинара "Анализ требований"? Очень хотелось бы посмотреть.

72

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

« : 15 Сентября 2009, 21:08:20 »

Проблема решена, всем спасибо за помощь.

73

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

« : 15 Сентября 2009, 17:58:04 »

Проверяю прямые ссылки
"Вы попытались получить доступ к адресу http://it-mapru.506.com1.ru/video/uml2.ru/10.09.2009_185951.flv, который сейчас недоступен. Убедитесь, пожалуйста, что веб-адрес (URL) введен правильно и затем попытайтесь перезагрузить."

74

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

« : 15 Сентября 2009, 16:41:25 »

У меня не заработало.

75

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

« : 15 Сентября 2009, 15:22:59 »

Тоже не открывается
IE8, Opera.