2791

Примеры / Re: UML пример физической системы.

« : 21 Декабря 2009, 21:08:48 »

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

Может Вы и правы, но что гадать, пусть автор сам определится

2792

Примеры / Re: UML пример физической системы.

« : 21 Декабря 2009, 14:25:20 »

Ок, мне бы диаграмму классов. Этого было бы за глаза.

Делайте, мы посмотрим и подскажем.

Начните с простого. Есть класс автомобиль, он состоит из классов: колеса, кузов, двери и т.п. Эти классы как-то взаимодействуют, следует показать как через ассоциации.

Вопрос цели как всегда первичен!

2793

Примеры / Re: UML пример физической системы.

« : 21 Декабря 2009, 14:16:45 »

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

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

Диаграмма классов показывает статическую структура автомобиля, как агрегата или композита, например.

Поведение этого агрегата можно описать путем диаграмм состояний.

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

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

2794

Конференции Семинары и Тренинги / Re: Семинар Сообщества аналитиков в Киеве №2, декабрь

« : 19 Декабря 2009, 16:31:58 »

Можно ещё давать комментарии по поводу качества трансляции по скайпу:
gpechyonkin

гречёнкин?

2795

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

« : 19 Декабря 2009, 16:30:09 »

Так что??? Между классами зависимость??? или Ассоциация???

Студент, я тебя русским голосом говорил, зависимость. Тебя это не убеждало. Пришлось прибегнуть к цитатной артиллерии. И это мимо.

Как уж еще сказать? Ну вот хоть Денис высказался!

2796

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

« : 18 Декабря 2009, 22:43:03 »

распечатал статью и прочитал ее, мне это не дало возможности решить ту проблеме - как указать метод, который оперирует объектом другого класса. Это зависимость??? Или это ассоциация??? Или что??? Я не могу до конца понять! Объясните пожалуйста.

Хотя и против правил делать большие цитаты, я все-таки решусь в данном случае. Приведу ряд цитат из Г Буч, Д Рамбо, А Джекобсон Язык UML Руководство пользователя.

Зависимостью (Dependency) называют отношение использования, согласно которому изменение в спецификации одного элемента (например, класса Event) может повлиять на другой элемент, его использующий (в данном случае - класс Window), причем обратное не обязательно. Графически зависимость изображается пунктирной линией со стрелкой, направленной от данного элемента на тот, от которого он зависит. Используйте зависимости, когда хотите показать, что один элемент использует другой.

Чаще всего зависимости применяются при работе с классами, чтобы отразить в сигнатуре операции тот факт, что один класс использует другой в качестве аргумента (см. рис. 5.2). Это хороший пример отношений зависимости - изменение одного класса отразится на работе другого, так как используемый класс может теперь представлять иной интерфейс или поведение. В UML разрешается определять зависимости и между другими элементами, например примечаниями (см. главу 6) или пакетами (см. главу 12).

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

    * bind - определяет, что источник инстанцирует целевой шаблон с заданными фактическими параметрами. Этот стереотип используют при моделировании деталей шаблонов классов (см. главу 9). Например, отношения между шаблоном класса-контейнера и экземпляром этого класса моделируются как зависимость bind. Стереотип bind должен содержать список фактических аргументов, соответствующих формальным аргументам шаблона;
    * derive - показывает, что источник может быть вычислен по целевому элементу. С помощью этого стереотипа моделируют отношения между двумя атрибутами (см. главу 4 и 9) или ассоциациями (см. главу 5), причем один из соотносимых элементов является конкретным, а другой - концептуальным. Скажем, класс Человек имеет атрибут Дата Рождения (конкретный) и атрибут Возраст (который может быть выведен из первого и потому не объявлен в классе отдельно). Отношения между ними можно определить с помощью зависимости типа derive, при этом Возраст будет производным от ДатаРождения;
    * friend - указывает, что источнику даются специальные права видимости свойств цели (см. главу 5). Используйте этот стереотип для моделирования отношений, подобных отношениям между классом и его друзьями в языке C++;
    * instanceOf - говорит, что исходный объект является экземпляром целевого классификатора;
    * instantiate - показывает, что источник создает экземпляры целевого элемента.
      Последние два стереотипа позволяют явно моделировать отношения "класс/ объект" (см. главу 2). instanceOf применяется для моделирования отношения между классом и объектом на одной и той же диаграмме или же между классом и его метаклассом instantiate указывает, какой элемент создает объекты другого;
    * powertype - означает, что все объекты целевого классификатора являются потомками заданного родителя. Этот стереотип применяется при моделировании классов, содержащих другие классы, например при проектировании баз данных, о чем идет речь в главах 8 (логические базы данных) и 29 (физические базы данных).
    * refine - свидетельствует, что источник находится на более низком уровне абстракции, чем цель. Данный стереотип используется для моделирования концептуально одинаковых классов, рассматриваемых на различных уровнях абстракции. Так, класс Клиент, возникший на стадии анализа, будет уточнен в фазе проектирования, в результате чего появится более детальный класс Клиент вместе со своей реализацией;
    * use - показывает, что семантика исходного элемента зависит от семантики открытой части целевого. Этот стереотип позволяет явно указать, что зависимость по своему типу принадлежит к отношениям использования, в отличие от отношений зависимости, обозначаемых другими стереотипами.

Стереотипы наверное Вам тут не нужны особо

А вот по интерфейсам
Типы и роли

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

Рассмотрим, например, экземпляр класса Человек. В зависимости от контекста экземпляр этого класса может играть роль Матери, Налогоплательщика, Работника, Покупателя, Менеджера, Летчика, Певца и т.д. Следовательно, объект предъявляет миру ту или иную "личину", и взаимодействующие с ним клиенты ожидают от него соответствующего поведения. Например, экземпляр класса Человек в роли Менеджера обладает не таким набором свойств, какой был бы у него в роли Матери.

На языке UML роль, которую одна абстракция играет по отношению к другой, можно описать, дополнив соответствующую концевую точку ассоциации (см. главы 5 и 10) именем интерфейса. Например, на рис. 11.5 показан интерфейс Работник, определение которого включает три операции. Между классами Человек и Компания существует ассоциация, в контексте которой Человек играет роль е, относящуюся к типу Работник. В другой ассоциации этот класс может быть "обращен к миру иным лицом". При наличии явного типа роль, которую играет Человек, - это не просто слово, понятное для читателя, изучающего диаграмму. В UML это означает, что класс Человек играет для класса Компания роль Работника, и в данном контексте для Компании будут видимы и существенны только свойства, определенные данной ролью.

2797

Sparx / Re: Enterprise Architect и управление требованиями

« : 18 Декабря 2009, 22:33:45 »

Хм... походу беседа клонится к обсуждению таксономии требований и EA тут не при чем получается.

Да может быть ЕА и не причем. Поскольку я уже сталкивался с такой проблемой прошлым летом, пытаясь найти точки соприкосновения на то как выстраивать иерархию требований. Мною был предложен взгляд Вигерса. Но тогда меня как-то не поняли.

Сейчас несколько ситуация поменялась. Тем не менее меня интересовало в первую очередь вкладывание одних требований в другие. Но, кажется, я для себя прояснил ситуацию. Потому можно двигаться дальше.

М.б. ЕА и не причем, но нужно учитывать, что ЕА позволяет производить многие действия только на основе пакетов, например, посмотреть трассировку требований можно посмотреть только сравнивая 2 пакета.

Да ты прав Саша, это следует иметь в виду обязательно

2798

Sparx / Re: Enterprise Architect: Проблема с генерацией отчетов

« : 18 Декабря 2009, 09:36:08 »

не вопрос. а когда билд будет в паблике ?

Этого они не написали. Последний был от 4 ноября

2799

Sparx / Re: Enterprise Architect: Проблема с генерацией отчетов

« : 18 Декабря 2009, 09:16:58 »

А вот и ответ.

Thanks for sending through the model. The problem with  text 'pre' the
table not being reproduced for subsequent Elements in a package has been
corrected and will be in the next available build.

Best regards,

Dermot O'Bryan

Будем ожидать нового билда, а с Вас тестирование:)

2800

Обсуждение статей / Re: Моделирование бизнес-процессов автоматизируемой предметной области при помощи диаграмм деятельно

« : 17 Декабря 2009, 23:40:59 »

Статья проходила закрытое экспертное рецензирование?

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

Название, согласен, выглядит несколько вызывающе.

2801

Sparx / Re: Enterprise Architect и управление требованиями

« : 17 Декабря 2009, 14:27:24 »

Не понимаю. Объясни плиз, в какое время и почему она будет меняться? Отчеты можно делать разные, опять же все зависит от того как организованна работа. Требования к отчетности навряд ли могут стать требованиями к администированию 

Ты же сам пишешь группировка по актерам. по функциям, по другим моментам, можно группировать на верхнем уровне по актерам а ниже по другим категориям, а можно просмотреть все по другой иерархии

В системе должны быть предусмотрены такие-то регистрационные данные

но требование то по формату. Ты пишешь Формат рег данных: система должна поддерживать установленный формат данных для таких-то рег данных? и дальше раскрывать конкретно? Конкретные моменты мы проверим, но как проверить само группирующее требование? или проверять его следует как агрегат и только как агрегат?

Эд, в книге есть список иллюстраций. Их просмотр занимает 2 минуты
Figure 23-1

Злой ты, Виталик, вижу я рисунки - поди догадайся какой ты имел в виду. И кстати мы не используем Use Cases

2802

Sparx / Re: Как задать стартовую модель

« : 17 Декабря 2009, 13:43:20 »

Меня ничем. ОП просил "вместо", а не "вместе"

Скажите ОПу, что таковы ограничения продукта. так уж они устроили свое приложение

2803

Sparx / Re: Enterprise Architect и управление требованиями

« : 17 Декабря 2009, 13:29:51 »

Книгу нашел. Где смотреть

2804

Sparx / Re: Enterprise Architect и управление требованиями

« : 17 Декабря 2009, 13:17:15 »

По типам,например, модель требования (читай SUP) разделяю в отдельные пакеты функциональные требования, требования по производительности, ограничения и тп,
По предметным областям для требований и вариантов использования это, например, безопасность, сервисы для клиента, сервисы оператора, CRM, Отчетность и тп.
Для акторов это 2 пакета обычно по типам - Пользователи и Системы, но их тоже можно поделить по областям, если акторов много

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

1. Формат регистрационный данных
  1.1 Формат логина
  1.2 Формат пароля
  1.3 Формат ФИО
  1.4 Формат паспортных данных

Как я понимаю это именование (алиасы) требований. Вот требование 1 ка у тебя сформулируется? Ч учетом, что оно должно быть проверяемым поскольку это требование?

Назвать можно как хочется, главное чтобы все тебя понимали и это помогало решать ВАШУ проблему (задачу)
В книге Вигерса "More about software requirements" есть хорошая картинка показывающая не просто связи требований друг с другом, а их семантику

у меня нет книги, у тебя есть?

2805

Sparx / Re: Enterprise Architect: Проблема с генерацией отчетов

« : 17 Декабря 2009, 13:10:47 »

Отправил запрос