211

ПО Аналитика / Re: MagicDraw класс-ассоциация наследование

« : 07 Декабря 2017, 13:12:30 »

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

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

212

ПО Аналитика / Re: MagicDraw класс-ассоциация наследование

« : 02 Декабря 2017, 00:31:08 »

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

213

Sparx / Re: Нужны примеры описания API в UML

« : 02 Декабря 2017, 00:26:41 »

Перешли на 13тый ЕА ...
открыл для себя Schema Composer для описания API милое дело
собираем класс диаграмму со связями и отношениями .. после чего строим на основании диаграммы JSON Schema или XML Schema как кому нравится .. !!

А немного развернуть кейс? Кстати в январе вроде 14 будет представлена

214

ПО Аналитика / Re: MagicDraw класс-ассоциация наследование

« : 01 Декабря 2017, 13:54:02 »

EA (Sparx Enterprise Architect) позволяет подчинять классы классу-ассоциации. Пример на "серой" диаграмме. Правда он не позволяет ассоциациям наследовать друг друга.

А ответ на первую часть вопроса:))

215

ПО Аналитика / Re: MagicDraw класс-ассоциация наследование

« : 30 Ноября 2017, 16:27:30 »

• не разрешать подчинять классу-ассоциации просто класс или просто ассоциацию
• давать возможность на диаграмме представлять класс-ассоциацию как класс или как ассоциацию

MagicDraw не выполняет 2

Не совсем понял, это как? ЕА может?

216

Sparx / Re: ссылка на диаграме развертывания

« : 29 Ноября 2017, 21:15:50 »

В Toolbox каждой диаграммы есть раздел Common, в нем есть элемент: гиперссылка. Перетащите ее на диаграмму, клик на нее позволяет решить вашу задачу.

217

ПО Аналитика / Re: MagicDraw класс-ассоциация наследование

« : 23 Ноября 2017, 21:57:05 »

Отношение одно, остальные 4 - его вариации.

Я что-то не догоняю, разве так можно? НЛО? Разве нотация позволяет в данном случае читать розовую модель как одно из возможных отношений?

И также интересно почему выбрана иерархия наследования, а не простое включение?

218

ПО Аналитика / Re: MagicDraw класс-ассоциация наследование

« : 22 Ноября 2017, 21:57:58 »

Вот предметная область:

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

А картинка в ЕА какая?

219

ПО Аналитика / Re: MagicDraw класс-ассоциация наследование

« : 20 Ноября 2017, 20:32:44 »

С точки зрения экзамена изучение разбивается на 2 подкласса: "с экзаменом" и "без экзамена". "С экзаменом" тоже разбивается на 2 подкласса: "Экзамен сдавался" (с атрибутами "дата" и "оценка") и "Экзамен не сдавался". С точки зрения зачета - аналогично (и независимо?!).

Что разбивается на подклассы? Класс -ассоциации? Зачем, класс ассоциации имеет четкое назначение, в случае многозначности связи студент- дисциплина - лучше и правильнее использовать отдельный класс, в тернарой ассоциации или в двух бинарных кмк

220

ПО Аналитика / Re: MagicDraw класс-ассоциация наследование

« : 20 Ноября 2017, 13:27:09 »

Так ситуации ещё разнообразнее: есть/нет экзамен, есть/нет зачет, если есть экзамен (зачет), то он уже был/не был. Если каждый подкласс сопровождать изображением ассоциации - очень запутанная диаграмма.

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

221

ПО Аналитика / Re: MagicDraw класс-ассоциация наследование

« : 19 Ноября 2017, 23:23:35 »

Студенты изучают Предметы (ассоциация многие-ко-многим). Надо бы зафиксировать сколько времени Студент потратил на Предмет (ассоциация переходит в класс-ассоциацию - нужен атрибут). Некоторые Студенты по некоторым Предметам уже сдали экзамен: есть дата и оценка (а вот тут и нужен подкласс "Сдан экзамен")

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

222

ПО Аналитика / Re: MagicDraw класс-ассоциация наследование

« : 18 Ноября 2017, 13:36:53 »

Вопрос, конечно, не по адресу. Это нужно вендору задавать. Но, думаю стоит посмотреть на стандарт UML, является ли такое отношение допустимым как синтаксически, так и семантически.

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

Можно рассмотреть пример подобной конструкции?

223

Для всех / Re: Правильные ли этапы проектирования программной системы?

« : 09 Ноября 2017, 09:24:04 »

Мне кажется, вы идете неправильной дорогой.

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

https://yadi.sk/d/eTznHQAF3B7aKz
https://yadi.sk/d/ewTF17Od3PXutQ
https://yadi.sk/i/yPB2G4Sc3PXuuF
https://yadi.sk/i/K6D3jMOQ3PXuvE

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

Вы явно или неявно говорите о использование многослойной архитектуры - типичный выбор начинающих: например https://yadi.sk/i/rrbjoIZTgVVxP

224

ПО Аналитика / Re: Управление изменениями требований

« : 01 Октября 2017, 21:25:40 »

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

Ну да, Вы правы. Я вспомнил такое правило. У каждого ВИ есть только одно основное действующее лицо (первичное), то, которое инициирует ВИ, остальные могут быть только вспомогательными.

225

ПО Аналитика / Re: Управление изменениями требований

« : 01 Октября 2017, 00:13:54 »

И тут везде одно и то же: один ВИ и два связанных с ним ДЛ. В каждом случае чеккер прочтёт модель с одинаковым смыслом.

Именно, как только мы начинаем производить автоматическую трансформацию с целью получения исполняемого кода или другого интерпретируемого продукта.

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

Но даже в спецификации написано для чего применяется диаграмма ВИ и описание закладываемого в ВИ поведения определяется другими средствами: диаграммой деятельности, машиной состояния, последовательности.