526

Системный Анализ и Требования / Re: Диаграмма классов (объекты, атрибуты, связи) - правильно ли установлены связи?

« : 18 Октября 2015, 21:52:34 »

Здравствуйте.

1. Если уж следовать стандарту UML, то наименование классов нужно делать в единственном числе
2. Ромб заполненный - это композиция, разновидность агрегации, которая сама разновидность ассоциации. В вашем случае дотаточно иметь агрегацию, но я бы начал с простой ассоциации.
3. чем пром предприятие отличается от энергетики? По-моему, это виды предприятий, проще ввести атрибут: Вид предприятия. Можно создать абстрактный класс - Предприятие, от которого унаследовать разные виды предприятий. Но делать это нужно, если у разновидностей, есть какие-то особые атрибуты
4. Классификатор продукции - должен быть независимым классов. Между Предприятием и Классификатором продукции будет связь - многие ко многим, которую можно разрешить или промежуточным классом Выпускаемая продукция, или классом-ассоциацией Выпускаемая продукция.

А вообще мне к вам совет изучите нотацию рисования классов в UML: http://www.uml-diagrams.org/class-diagrams-overview.html

527

Примеры / Re: Продажа автомобилей

« : 14 Октября 2015, 23:25:16 »

Набросал сейчас ДК согласно Вашим замечанием. Не могу решить, как обомзвать ассоциации между Автомобиль-Продажа и Клиент-Продажа.

Автомобиль - Продажа (я бы сделал кратность 1 со стороны авто и много со стороны продажи - один и тот же тип авто может продаваться в разных продажах) ну наоборот - понятно, на каждый авто оформляется одна продажа. Название связи - участвует в

Клиент- Продажа - кратность только 1 - *, никак иначе, в Продаже участвует только 1 клиент, а не много одновременно. Клиент в принципе может осуществлять много продаж,

Хотя тут возможны варианты

И как я понял, связывать Требования и Продажа посредством зависимости не имеет смысла?

Как продажа связана с требованиями? Они влияют на выбор, а продажа - это отражение факта передачи автомобиля клиенту за соответствующее вознаграждение.

Кстати связь Между Требованием и Клиентом не верна, кратность наоборот. И по-моему смоделировано не верно. Требования = Критерии отбора. Т.е. каждый автомобиль может быть описан определенными характеристика = критериями отбора, клиент по сути  выбирает из некоего определенного набора характеристик, задает дапазоны: цена: от а до б, цвет , синий или черный или металик, ну и т.п.

Имеет ли смысл композиция между Клиент и Требования? Или же, более верный вариант - перенести атрибуты из Требования в Клиент и удалить класс Требования?

Может но смотрите выше.

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

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

528

Примеры / Re: Продажа автомобилей

« : 14 Октября 2015, 23:12:19 »

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

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

Ведь тогда результат работы системы может быть другим.

А что может измениться?
 

Является ли возможным "обзывания" всех эти ВИ как ВнесениеИзменений?

Мне не нравится, так как Вы спускаетесь на уровень реализации. Вообще, это называется CRUD вариант использование и может называться: Управление списком: <клиентов> и т.п. можно абcтрагироваться до <объектов>. В рамках которога описывать сценарии добавления, изменения, удаления и ... поиска элемента списка.

Представленный вариант диаграммы мне представляется сложным, хотя наверное и возможным.

529

Примеры / Re: Продажа автомобилей

« : 11 Октября 2015, 00:27:40 »

Да, извините заранее, за вызванные негативные эмоции при просмотре приложенных диаграмм.

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

Ну, по существу.

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

Тут также вопрос, а почему Клиент - действующее лицо, как он взаимодействует с системой?

У вас есть ВИ - Выполнить поиск авто в бд, а почем Редактировать авто в бд или удалить авто из бд не предусматривает Выполнить поиск авто в бд?

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

А продажа автомобиля может выполняться без оформление документов на продажу?? и чем принципиально оформление документов на продажу отличается от собственно продажи?

530

Примеры / Re: Продажа автомобилей

« : 03 Октября 2015, 00:51:34 »

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

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

Это разные точки зрения на один и тот же объект: структурный (статический) и функциональный(динамический). Это у же часть бизнес-логики, которая при проектировании проявится как операция какого-то класса.

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

Я отталкивался от того, что при изменении свойств экземпляра класса "ТребованияКлиента", "подборАвто" и "ЗаявкаПоставщику" тоже поменяют свои свойства. Или я снова ?

Тупишь? Точно так.

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

Хорошо, начну с ДВИ, спасибо за совет!

С чего начать с ДВИ или ДК не суть важно, реально это два параллельных процесса.

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

Так что я бы начал с хотя бы краткого изучения UML http://book.uml3.ru

531

Примеры / Re: Продажа автомобилей

« : 02 Октября 2015, 23:38:33 »

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

1. Я бы убрал Администратора, - это просто роль, скорее всего она проявится на уровне прав доступа.
2. Менеджер - убрать связь с Требований клиента,
3. Не понятно что такое подбор автомобиля
4. Нет сущности, отражающей факт продажи. введите Продажу
5. Не понятна причина использования зависимостей - убрать имхо
6. Иерархия автомобилей на мой взгляд не обоснована

Короче морда в крови.

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

532

Sparx / Re: Настройка профиля MDG-импорта для импорта из Excel структуры (колонок) таблицы

« : 28 Сентября 2015, 22:54:39 »

А насколько Вы дружны с программированием, посмотрите в сторону automation. Более я ничего не могу посоветовать.
Можно используя MySQL к примеру импортировать данные из excel, а оттуда уже в ЕА. Ну или попробуйте все-таки ODBC.

533

Sparx / Re: Настройка профиля MDG-импорта для импорта из Excel структуры (колонок) таблицы

« : 28 Сентября 2015, 15:23:43 »

А вот как втянуть структуру (columns с именами, типами и размерами полей) - не нашел. Хотя по идее ничего сложного тут нет (с точки зрегия самого Спаркса). Тот же импорт объектов, но не в пакет, а в класс.

Не знаю, возможно это только у меня так, но если бы Вы говорили реальными примерами, то я бы понял Вас лучше. Правильно ли я понимаю, что Вы хотите:
имея некую таблицу в excel
   columns
   type
   size
что-то еще, получить от Спаркса структуру данных? в виде диаграммы классов или модели данных?

Можно посмотреть в сторону написания своего скрипта импорта? Может быть подойдет DatabaseBuilder? Или попробуйте Import DB scheme from ODBC source

534

Sparx / Re: Настройка профиля MDG-импорта для импорта из Excel структуры (колонок) таблицы

« : 28 Сентября 2015, 00:19:45 »

Что значит импорт объектов верхнего уровня?

Это поможет? http://www.sparxsystems.com/products/mdg/int/office/office-integration.html
Я бы еще посмотрел в сторону xmi или csv.

Ну и мало информации, не совсем ясно, что нужно.

535

ПО Аналитика / Re: Консоль и текстовый редактор как инструменты для управления требованиями - Creq

« : 28 Сентября 2015, 00:12:45 »

С руби на какой операционке играете? На виндах не все так просто.

536

Примеры / Re: Помогите новичку

« : 28 Сентября 2015, 00:11:12 »

Использовать или не использовать merge - это вопрос культуры и качества передачи информации.

В большинстве случаев, merge можно опускать, но при сохранении и передачи моделей, их следует использовать везде, где есть desicion.
Исключением будет разве цикл выход-вход.

537

Обучение / Re: Требуется вводный пинок в моделирование на UML.

« : 17 Сентября 2015, 22:08:00 »

Андрей, ЕА поддерживает BPMN.Если Вы об этом, Вы вполне можете транслировать подобие туда. Изучив возможности инструмента в этом аспекте.

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

Почему Вы полагаете, что БП Вам помогут?

538

Обучение / Re: Требуется вводный пинок в моделирование на UML.

« : 16 Сентября 2015, 23:00:23 »

Очень большая задача, для глубокого мотивированного погружения. Если бы Вы их разделили на более мелкие и обособленные и описание -вопрос для каждой сформулировали отдельно, было бы 100 крат лучше.

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

Я бы мог поучаствовать в эксперименте. Обладатель ЕА с 2008 (или даже 2007) года. Особенно если бы Вы прислали бы свой проект, ну или просто выложили его в общей шаре на гугль диске или яндексдиске или энифинг элз.

539

Задачи студентов / Re: как на sequence diagramm показать activity diagramm

« : 14 Сентября 2015, 22:57:26 »

Всем доброго времени суток. Провожу реверс-инжениринг последовательности объединения платежей с помощью sequence diagrammна определенном этапе мне нужно отобразить динамику в виде activity diagramm
(диаграмму вставить не получается) ... если есть примеры вставки ссылки на активити внутрь сиквенс диаграммы .. ткните носом

Если честно, мотивация не очень понятна. Если бы был какой-то пример, понять можно было бы проще и быстрее. Но возможно, ваша задача решается просто использованием interaction use/

Кроме того не совсем понятен переход из сиквенса в активити. Все-таки это разные по своему назначению диаграммы.

540

Примеры / Re: Аннулирование сущности в любой момент времени. Как отобразить?

« : 10 Сентября 2015, 10:04:54 »

Подскажите пожалуйста был у вас такой опыт и как бы вы это реализовали?

Я бы посмотрел в сторону Interrupting Edge (http://www.uml-diagrams.org/activity-diagrams.html). Другой способ все-таки использовать не диаграммы деятельностей, а диаграммы автоматов. Там есть исторические состояния, вложенные и т.п. средства решения вашей задачи (http://www.uml-diagrams.org/state-machine-diagrams.html).