2566

Поздравления / Re: С Новым Годом - весенним Равноденствием!

« : 21 Марта 2010, 15:17:56 »

Спасибо

2567

Примеры / Re: Вопрос по диаграмме классов

« : 19 Марта 2010, 18:10:38 »

В случае со стоимостью парковки я же не могу использовать класс "Стоимость парковки". Как-то нелогично это...

Опять ничего не понял
Но все-таки попытаюсь. Стоимость парковки у магазина величина однозначная. Верно?
Стоимость парковки может изменять свое значение время от времени. Т.е. можно рассмотреть (концептаульно) наличие класса Парковка (Стоимость, Дата начала действия, Дата завершения действия)
Если это так - то решение может быть похожим на ранее рассмотренное.
Другое дело, что реализация этого решения может быть совершенно разная. Например созданием специального домена исторический атрибут, который по мимо значения хранит и дату

2568

Примеры / Re: Вопрос по диаграмме классов

« : 19 Марта 2010, 14:21:19 »

Раз уж пошла такая интересная дискуссия, предложу еще одну тему для обсуждения:
что если для магазина необходимо знать историю какого-то атрибута, который невозможно вынести в справочник по типу "Режим работы". Например, атрибут "Стоимость парковки"
Как такое изобразить? Кто в этом случае будет третьим классом?

Если честно, ничего не понял

2569

Примеры / Re: Вопрос по диаграмме классов

« : 19 Марта 2010, 14:11:26 »

Этот пример более корректный согласно Note.

Магазин     | Режим работы    | Дата начала действия режима
Магазин  1 | Режим работы 1  | 1/01/2010
Магазин  1 | Режим работы 2  | 1/02/2010
Магазин  1 | Режим работы 1  | 1/03/2010

У каждого экземпляра  "дата начала действия" есть по одному экземпляру Магазин и Режим работы.

А причем тут экземпляр "дата начало действия" - какие такие свойства кроме самой даты данный экземпляр имеет?

Позволю себе цитату:
Арлоу Д., Нейштадт И.
UML 2 и Унифицированный процесс. Практический объектноориентированный анализ и проектирование, 2е издание. – Пер. с англ. – СПб: СимволПлюс, 2007. – 624 с., ил.

В ОО моделировании распространена следующая проблема: когда между классами установлено отношение многиекомногим, встречаются такие атрибуты, которые не удается поместить ни в один из классов. Проиллюстрируем это примером, приведенным на рис. 9.18.
На первый взгляд это довольно безобидная модель:
• каждый человек (объект Person) может работать во многих компаниях (объект Company);
• каждая компания (Company) может нанимать много людей (объект Person).
Однако что происходит, если добавить бизнесправило, заключающееся в том, что каждый Person получает зарплату в каждой нанявшей его Company? Где должна быть записана эта зарплата: в классе Person или в классе Company?
Действительно, нельзя сделать зарплату Person атрибутом класса Person, потому что каждый экземпляр Person может работать на многие Company и в каждой получать разную зарплату. Аналогично нельзя сделать зарплату атрибутом Company, поскольку каждый экземпляр Company нанимает множество Person, зарплата которых может быть разной.
Решение кроется в том, что зарплата на самом деле является собственностью самой ассоциации. У каждой ассоциации найма, устанавливаемой между объектом Person и объектом Company, своя индивидуальная зарплата.
UML позволяет моделировать эту ситуацию с помощью классаассоциации (рис. 9.19). Важно понимать этот синтаксис: многие люди думают, что классассоциация – это всего лишь прямоугольник, свисающий с ассоциации. Но ничто не могло бы быть дальше от истины, чем это.
На самом деле классассоциация – это линия ассоциации (включая все имена ролей и кратности), пунктирная нисходящая линия и прямоугольник класса на конце пунктирной линии. Короче говоря, классассоциация – все, что входит в затемненную область (рис. 9.19).

Классассоциация означает, что в любой момент времени между любыми двумя объектами может существовать только одна связь

Экземпляры классаассоциации – это на самом деле связи, у которых есть атрибуты и операции. Уникальная идентификация этих связей определяется исключительно индивидуальностью объектов, находящихся на каждом конце. Этот фактор ограничивает семантику классаассоциации: его можно использовать только тогда, когда между двумя объектами в любой момент времени установлена единственная уникальная связь. Это обусловлено тем, что каждая связь, которая является экземпляром классаассоциации, должна быть уникальной. На рис. 9.19 применение классаассоциации означает, что на модель накладывается следующее ограничение: для данного объекта Person и данного объекта Company может существовать только один объект Job (должность). Иначе говоря, каждый Person может занимать только одну Job в данной Company.
Однако если ситуация такова, что данный объект Person может занимать несколько Job в данном объекте Company, классассоциацию использовать нельзя – семантика не соответствует!

2570

Примеры / Re: Вопрос по диаграмме классов

« : 19 Марта 2010, 10:40:19 »

"Note – It should be noted that in an instance of an association class, there is only one instance of the associated classifiers at
each end, i.e., from the instance point of view, the multiplicity of the associations ends are ‘1.’"

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

Класс-ассоциация является особым представлением ассоциации. Потому каждый экземпляр класс-ассоциации, представляя собой конкретный экземпляр самой ассоциации, идентифицируется через участников такой ассоциации, т.е. через экземпляры классов на концах этой связи - экземпляра ассоциации. Это и предполагает независимо от значений атрибутов класса-ассоциации дефолтное значение скрытых от нас двух атрибутов представляющих идентификаторы объектов на концах связи. Совокупность этих атрибутов и есть идентификатор конкретного экземпляра ассоциации и он должен быть уникальным!!!!

Потому в схеме с ассоциативным классом невозможна такая ситуация:

Магазин     | Режим работы    | Дата начала действия режима
Магазин  1 | Режим работы 1  | 1/01/2010
Магазин  1 | Режим работы 2  | 1/02/2010
Магазин  1 | Режим работы 1  | 1/03/2010

Записи которые возможны в этом случае буду такими
Магазин     | Режим работы    | Дата начала действия режима
Магазин  1 | Режим работы 1  | 1/01/2010 1/03/2010
Магазин  1 | Режим работы 2  | 1/02/2010

Т.е. мы можем знать лишь дату последнего действия режима, но не сможем получить ответ на такой вопрос:
Сколько раз в течение года магази 1 работал по режиму 1 или какова общая продолжительность работы магазина 1 в течение года по режиму 1

2571

Системный Анализ и Требования / Re: Является ли процесс объектом автоматизации? Два вопроса.

« : 19 Марта 2010, 09:05:13 »

Процесс ОДНОЗНАЧНО является объектом автоматизации. Ну, если точнее, то следовало бы его назвать субъектом, наверное В ГОСТ 34-й системы столько противоречий...

А что Вы понимаете под субъектом?

2572

Для всех / Re: Построение диаграмм окружающей обстановки

« : 19 Марта 2010, 09:03:59 »

Ura, декомпозировать можно по-разному:
1. по функциональности - общая функциональность Обнаружение судов: декомпозиция: Обнаружение судов радиолокатором кругово обзора, Обнаружение судов посредством радиосвязи с диспетчером, Обнаружение через спутниковую навигацию и т.д

2. по объектам - Систем обнаружения судов: Радиолокационная подсистема; Подсистема радиосвязи с диспетчером; Подсистема спутниковой навигацию. Далее можно показать соотносятся ли эти системы. Потом декомпозируем каждую подсистему, описывая что в нее входит какие части как соотносятся и взаимодействуют

2573

Примеры / Re: Вопрос по диаграмме классов

« : 18 Марта 2010, 16:28:48 »

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

Описываемая Вами ситуация не есть N-арная ассоциация, а есть класс-ассоциации. Как сказано было (ниже или выше) класс-ассоциации тут может и не подойти

2574

Примеры / Re: Вопрос по диаграмме классов

« : 18 Марта 2010, 16:25:00 »

Не совсем согласен с Эдом, скорее надо нарисовать Д Последовательности и сразу станет понятно у кого какая операция.

Не понял с чем ты не согласен в данном случае?

2575

Примеры / Re: Вопрос по диаграмме классов

« : 18 Марта 2010, 16:24:39 »

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

Впрочем, на вкус и цвет....

Прочитал у Фаулера, что двум участвующим в ассоциации объектам может соответствовать ТОЛЬКО ОДИН экземпляр класса-ассоциации. То есть магазин не сможет перейти на круглосуточный режим, потом вернуться на 12-ти часовой, и потом снова на круглосуточный.
Буду испольовать три класса - "магазин", "режим работы" и "журнал работы"

Молодец idaxebrn, именно это я хотел ответить kirillss. Кстати ничего в моих рассуждениях от реализации то и нет

2576

Примеры / Re: Вопрос по диаграмме классов

« : 18 Марта 2010, 13:48:26 »

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

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

Насчет журнала - т.е. необходимо вести историю типа: Дата - Режим работы.
На концептуальной модели я бы ввел класс Журнал и две ассоциации к магазину и к режиму соотвественно. Кратность на стороне журнала много.

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

2577

Примеры / Re: Вопрос по диаграмме классов

« : 18 Марта 2010, 11:57:17 »

На уровне предметной области операции классов обычно не отображаются.

Тем не менее при моделировании нужно опираться на понятие ответственности класса.

Исходя из этого принципа, очевидно, что первая диаграмма более корректна.

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

Правда в данном случае это некоторые внешние события идущие от клиента - как я понимаю некоторого участника процесса заказа

Добавить элемент заказа - в принципе тоже ответственность клиента, хотя действительно эту операцию можно разместить в заказе

2578

Обучение / Re: Хотите протестировать свои навыки?

« : 15 Марта 2010, 19:36:49 »

Так же спорный вопрос № 8. Я не совсем согласен с тем что сценарий это все состояния Use Case

Не там говорилось instance, а это означет в данном контексте экземпляр. Так что сценарий ВИ - его экземпляр. Что вполне нормально, если не принимать во внимание что под экзепляром в классах мы понимаем объект, т.е. реальное воплощение класса.
Так что в данном случае другого ответа и не подберешь

2579

Обучение / Re: Хотите протестировать свои навыки?

« : 15 Марта 2010, 15:19:00 »

А что Вам показалось спорным, если не секрет? Мне например что UML - объекно-ориентированный язык программирования. Правда там как мне показалось вообще нет корректного ответа

2580

Обучение / Хотите протестировать свои навыки?

« : 14 Марта 2010, 15:51:52 »

Если вдруг Вам пришла такая мысль в голову и не жалко небольшого количества времени, то я приглашаю Вас пройти два небольших испытания:
take the business analysis quiz
и
take the UML quiz

думаю некоторые результаты будут для Вас большим сюрпризом