Форум Сообщества Аналитиков
Общий раздел => Примеры => Задачи студентов => Тема начата: rave от 14 Мая 2011, 17:18:16
-
Здрасьте.
В общем необходимо спроектировать сабж. В общем-то я уже все сдеал практически, но надо еще описать все в рамках нотации UML.
Для ясности прилагаю IDEF0 схему БП продажи при помощи данного сайта.
Для начала UML проектирования попытался составить требования к системе, на основе которых нарисовал подобие Business Domain Model (кстати как это по-русски? Диаграмма бизнес-объектов?):
- Портал предназначен для доступа к нему заранее зарегистрированных (администратором) оптовых клиентов
Клиент должен авторизоваться для входа на сайт
Клиенты могут скачивать прайс-листы из выбранной категории товара (светильников)
Клиент может сделать заказ, используя форму загрузки заказов
Клиент может отследить статус заказа
Бухгалтер формирует счет на оплату (и публикует ссылку на этот счет на сайте, или загружает на сайт, пока не знаю..)
Системный администратор и менеджер управляют статусами заказов
Менеджер по оптовым продажам формирует прайс-листы
Администратор управляет учетными записями пользователей
Администратор управляет безопасностью
Клиент может воспользоваться формой обратной связи
Акторы будут следующие:
- Клиент
Админ
Менеджер
Бухгалтер
Зав складом
Не откажусь от советов и рекомендаций по поводу того, что делать дальше.. Написать ВИ системы? Нарисовать ДВИ? Что еще? Заранее спасибо.
-
Еще раз повторюсь, что это не интернет-магазин, оплатить онлайн возможности нет.
Кстати седня еще туда ввпихнул систему управления проектами (типа так удобнее будет бухгалтеру и зав складом смотреть чо когда сделать надо, и не только). Так что ее в UML тоже как-то обыграть надо я думаю..
-
Прошу прощения, что создал тему, и не отписывался в ней больше. Просто было слегка не до этого, т.к. занимался здоровьишком.
Итак, я набросал примерные сценарии ВИ системы, хотелось бы услышать комментарии по поводу моих изысканий, спасибо.
Варианты использования
ВИ 01. Авторизация
Роли: Любой пользователь системы
Предусловия: ---
Сценарий:
• Пользователь заходит на сайт
• Система запрашивает логин и пароль
• Пользователь вводит выданный ему логин и пароль
• Система проверяет введенные данные, после чего открывает доступ к сайту
Альтернативный сценарий:
• Пользователь вводит неверный логин или пароль
• Система выдает сообщение об ошибке
• Пользователь может попробовать ввести данные заново или выбрать 1 из пунктов «Восстановление логина», «Восстановление пароля»
• В обоих случаях выводится форма ввода электронной почты
• Пользователь заполняет данную форму адресом своей электронной почты
• Система отправляет письмо с данными на указанный e-mail
Постусловия:
Пользователь входит в систему под своей учетной записью, согласно которой получает определенные права и ограничения
ВИ 02. Оформление заказа
Роли: Клиент
Предусловия: ВИ 01. Авторизация
Сценарий:
• Клиент выбирает заинтересовавшую его категорию светильников
• Скачивает прайс-лист(ы) и остатки
• Заполняет ячейки с товаром для заказа
• Заходит на сайт
• Выбирает пункт «загрузка заказа»
• Загружает сформированный заказ на сервер
Альтернативный сценарий:
Постусловия:
Заказ загружен на сервер для дальнейшей проверки
ВИ 03. Формирование статуса заказа
Роли: Системный администратор
Предусловия: ВИ 01. Авторизация
Сценарий:
• Администратор сверяется с СУП?????
• Администратор в фронтэнде или бэкэнде сайта формирует в таблице статусов нужного пользователя статус конкретного заказа в зависимости от фактического статуса выполнения заказа.
Альтернативный сценарий:
Постусловия: Сформированный статус
ВИ 04. Создание проекта в ИСУП
Роли: Менеджер по оптовым продажам
Предусловия: ВИ 01. Авторизация
Сценарий:
• Менеджер заходит в систему управления проектами
• Нажимает на кнопку «Новый проект»
• Вводит название проекта
• По необходимости ставит срок завершения проекта
• Добавляет участников проекта
• При необходимости совершает дополнительные настройки
o Делает проект публичным
o Разрешает запросы на присоединение к проекту
o Выбирает цвет и логотип проекта
• Сохраняет созданный проект
Альтернативный сценарий:
Постусловия:
Создан новый проект
ВИ 05. Создание нового этапа в ИСУП
Роли: Менеджер по оптовым продажам
Предусловия: ВИ 01. Авторизация, ВИ 04. Создание проекта в ИСУП
Сценарий:
• Менеджер заходит в систему управления проектами
• Выбирает в списке проектов тот, в котором необходимо создать новый этап
• Нажимает на кнопку «Новый этап»
• Вводит заголовок и, если необходимо, краткое описание этапа
• При необходимости совершает дополнительные настройки
o Вводит срок завершения этапа
o Выбирает приоритет созданного этапа
• Сохраняет созданный этап проекта
Альтернативный сценарий:
Постусловия:
Создан новый этап
ВИ 06. Создание новой задачи в ИСУП
Роли: Менеджер по оптовым продажам, администратор сайта, бухгалтер
Предусловия: ВИ 01. Авторизация, ВИ 04. Создание проекта в СУП
Сценарий:
• Пользователь системы заходит в систему управления проектами
• Выбирает в списке проектов тот, в котором необходимо создать новую задачу
• Нажимает кнопку «Новая задача»
• Вводит заголовок задачи
• Выбирает этап проекта
• Выставляет приоритет задачи
• Обозначает сроки завершения задачи
• Назначает ответственных лиц
• Сохраняет созданную задачу
Альтернативный сценарий:
Постусловия:
Создана новая задача
ВИ 07. Формирование счета
Роли: Бухгалтер
Предусловия: ВИ 01. Авторизация
Сценарий:
• Бухгалтер сверяется с ИСУП
• При наличии активных заданий, связанных с формированием счетов, бухгалтер выбирает одно из них
• Скачивает прикрепленный к заданию файл с заказом
• Формирует счет по данному заказу, используя сторонние программные продукты
• Прикрепляет сформированный счет к заданию
• Помечает задание как выполненное
• Передает информацию администратору сайта (через ИСУП мб?)
• Администратор сайта обновляет статус заказа конкретного пользователя и прикрепляет счет на оплату по данному заказу
Альтернативный сценарий:
Постусловия: Сформированный счет
ВИ 08. Управление аккаунтами
Роли: Администратор сайта
Предусловия:
Сценарий:
Администратор сайта регистрирует пользователей в системе, присваивая им учетные имена и пароли.
Альтернативный сценарий:
Постусловия: Зарегистрированные под определенными учетными записями пользователи
ВИ 09. Управление правами
Роли: Администратор сайта
Предусловия:
Сценарий:
Администратор сайта устанавливает определенные ограничения доступа пользователей в соответствии с их ролями в системе.
Альтернативный сценарий:
Постусловия: Распределенные права пользователей
ВИ 10. Использование формы обратной связи
Роли: Клиент
Предусловия:
Сценарий:
• Клиент при возникновении каких-либо вопросов и предложений нажимает на кнопку «Обратная связь»
• Выбирает удобный для него способ обратной связи из предложенных:
o Рабочий телефон
o Мобильный телефон
o Почтовый адрес
o Адрес электронной почты
o ICQ
o Заполнение непосредственно самой формы обратной связи с автоматической отправкой письма на указанный e-mail
Альтернативный сценарий:
Постусловия:
ВИ 11. Мониторинг ИСУП
Роли: Администратор сайта, менеджер, бухгалтер, управляющие складами
Предусловия: ВИ 01. Авторизация
Сценарий:
Пользователь производит мониторинг ИСУП в зависимости от роли в системе на предмет:
• новых заданий
• выполнения того или иного задания
• просматривает активные задания
o в режиме списка
o в режиме календаря
Альтернативный сценарий:
Постусловия:
ВИ 12. Формирование прайс-листов
Роли: менеджер по продажам
Предусловия: ВИ 01. Авторизация
Сценарий:
• Менеджер по продажам с определенной периодичностью формирует прайс-листы светильников по категориям в сторонних программных продуктах
• Загружает сформированные прайс-листы на сайт
Альтернативный сценарий:
Менеджер дает задание администратору сайта для загрузки тех или иных прайс-листов
Постусловия: Сформированные и загруженные прайс-листы
Выстроил я правда слегка в сумбурном порядке их все, но я это исправлю, на это не смотрите..
-
Вообще шаги принято нумеровать
ВИ 01. Авторизация
• Система проверяет введенные данные, после чего открывает доступ к сайту
Здесь нужно просто - система открывает доступ к сайту (или страницам сайта)
ВИ 02. Оформление заказа
Предусловия: ВИ 01. Авторизация
Вариант использования не может быть предусловием, так как вариант использования может завершиться двумя разными результатами: успешным и неуспешным. Какое из этих условий будет верным?
Там же - нет действий системы, нет реакции системы, описаны только действия Клиента.
Все остальные ВИ страдают ровно тем же
Исправляем ошибки - потом вернемся
-
Не ну вообще я тут не на 100% развернутые описания каждого прецедента делал.. Любым откликом системы в кждом ВИ будет очевидное: "система отображает форму или окно", поэтому я их просто опустил..
К примеру:
- пользователь выбирает пункт "загрузка заказов"
- система отображает форму загрузки заказов..
Не, ну если это так критично, то могу добавить...
Я просто на данный момент страдаю над выделением концептуальных классов.. Потомучто я запутался слегка. Выделил пока для себя:
- аккаунт
- заказ
- счет
- статус
- прайс-лист
Не знаю, выделять ли "проект", "этап" и "задание" из системы управления проектами в отдельные классы, ведь в моем случае проект = клиент, а этап = заказ. Короче запутался я чето совсем :(
-
Не ну вообще я тут не на 100% развернутые описания каждого прецедента делал.. Любым откликом системы в кждом ВИ будет очевидное: "система отображает форму или окно", поэтому я их просто опустил..
Не, ну вообще, тут кто кого учит как писать ВИ. В FAQ (http://www.uml2.ru/index.php?option=com_content&task=view&id=399&Itemid=51) батенька, в FAQ (http://www.uml2.ru/index.php?option=com_content&task=view&id=399&Itemid=51) вас
Кому интересно это известно, что система отображает форму или окно? Всякие нажатия кнопок и т.п. есть неправильное понимание ВИ, об этом говорено, переговорено. Смотрите страницы форума.
Я просто на данный момент страдаю над выделением концептуальных классов..
Не знаете, что выбрать - выбирайте все. Потом будете удалять.
Не понятно почему проект - некая деятельность над созданием продукта = клиент - суть живое существо или организация
Не понятно почему этап - шаг некоторого процесса = заказ - вид операции, характеризующийся в том, что некто или нечто оставляет заявку или запрос на получение чего-то.
Думаем. Голова, не чтобы фуражку носить
-
Не понятно почему проект - некая деятельность над созданием продукта = клиент - суть живое существо или организация
Не понятно почему этап - шаг некоторого процесса = заказ - вид операции, характеризующийся в том, что некто или нечто оставляет заявку или запрос на получение чего-то.
Я объясню: в системе управления проектами я организовал все таким образом, что каждый клиент будет отождествляться с проектом, а каждый заказ данного клиента будет прирваниваться к этапу проекта, дабы избежать путанницы. А уже потом задания выдаются по каждому заказу (этапу) соответственно. Я думаю могут быть случаи, когда будут исключения, например, создание какого-то стороннего проекта, например по доработке сайта, но на данном этапе все происходит именно так как я описал.
За ссылку спасибо, щас буду переделывать.
-
Вот, переделал и доделал пока что "системные" ВИ:
ВИ Управление аккаунтами
ID: 1
Краткое описание:
Администратор сайта регистрирует пользователей в системе, присваивая им учетные имена и пароли
Основные действующие лица:
Администратор
Предусловия:
Нет
Основной поток:
1. Администратор заходит в менеджер пользователей в бэкэнде сайта
2. Администратор выбирает опцию создания нового пользователя
3. Система отображает форму ввода информации об учетной записи
4. Пока данные о пользователе не удовлетворяют требованиям системы
4.1. Система просит ввести его имя, логин, адрес электронной почты, пароль и еще раз пароль для подтверждения
4.2. Система проверяет уникальность вводимого логина и адреса электронной почты
4.3. Система проверяет идентичность паролей
5. Администратор определяет, в какую группу пользователей входит данный конкретный пользователь
6. Система регистрирует нового пользователя и выдает сообщение о том, что данные успешно сохранены
Альтернативные потоки:
1. Пользователь с данными логином уже существует
2. Пользователь с данным электронным адресом уже зарегистрирован
3. Введенные пароли не совпадают
Постусловия:
Создан новый аккаунт
Альтернативный поток: Управление аккаунтами: Пользователь с данным логином уже существует
ID: 1.1
Краткое описание:
Система сообщает администратору, что пользователь с данным логином уже существует
Основные действующие лица:
Администратор
Предусловия:
Администратор ввел уже зарегистрированный в системе логин
Альтернативные потоки:
1. АП начинается после шага 4.2 основного потока
2. Система сообщает Администратору, что пользователь с данным логином уже зарегистрирован в системе
Постусловия:
Нет
Альтернативный поток: Управление аккаунтами: Пользователь с данным электронным адресом уже зарегистрирован
ID: 1.2
Краткое описание:
Система сообщает администратору, что данный электронный адрес уже зарегистрирован
Основные действующие лица:
Администратор
Предусловия:
Администратор ввел уже зарегистрированный в системе электронный адрес
Альтернативные потоки:
1. АП начинается после шага 4.2 основного потока
2. Система сообщает Администратору, что пользователь с данным электронным адресом уже зарегистрирован в системе
Постусловия:
Нет
Альтернативный поток: Управление аккаунтами: Введенные пароли не совпадают
ID: 1.3
Краткое описание:
Система сообщает администратору, что введенные им пароли не совпадают
Основные действующие лица:
Администратор
Предусловия:
Администратор ввел не совпадающие пароли
Альтернативные потоки:
1. АП начинается после шага 4.3 основного потока
2. Система сообщает Администратору, что введенные им пароли не совпадают
Постусловия:
Нет
ВИ Управление правами
ID: 2
Краткое описание:
Администратор сайта устанавливает определенные ограничения доступа пользователей в соответствии с их ролями в системе
Основные действующие лица:
Администратор
Предусловия:
Нет
Сценарий:
1. Администратор в бэкэнде сайта выбирает материал, к которому нужно определить уровень доступа.
2. Система предоставляет выбор уровня доступа в зависимости от принадлежности к той или иной группе пользователей
3. Администратор выбирает необходимый уровень доступа и сохраняет изменения
4. Система регистрирует выбор и ограничивает доступ тем пользователям, которые не входят в выбранную группу
Альтернативный сценарий:
Постусловия: Распределенные права пользователей
ВИ Авторизация
ID: 3
Краткое описание:
Пользователь вводит заранее выданные ему данные для авторизации для входа на сайт
Основные действующие лица:
Любой пользователь системы
Предусловия:
Пользователю выданы данные для авторизации
Основной поток:
1. Пользователь заходит на сайт
2. Система запрашивает логин и пароль
3. Пользователь вводит выданный ему логин и пароль
4. Система проверяет действительность введенных пользователем данных
5. Система открывает доступ к разделам сайта
Альтернативные потоки:
1. Неверный логин или пароль
Постусловия:
Пользователь входит в систему под своей учетной записью, согласно которой получает определенные права и ограничения
Альтернативный поток
ID: 3.1
Краткое описание:
Система сообщает пользователю, что он ввел неверный логин
Основные действующие лица:
Любой пользователь системы
Предусловия:
Пользователь ввел неверный логин или пароль
Альтернативные потоки:
1. АП поток начинается после шага 4 основного потока
2. Система выдает сообщение об ошибке: «Логин или пароль введены неправильно, либо такой учётной записи ещё не существует».
Постусловия:
Нет
ВИ Восстановление логина
ID: 4
Краткое описание:
Пользователь вводит адрес своей электронной почты для восстановления логина
Основные действующие лица:
Любой пользователь системы
Предусловия:
Пользователю необходимо узнать свой логин
Основной поток:
1. Пользователь при входе на сайт нажимает на ссылку «Забыли логин?»
2. Системы выводит форму ввода адреса электронной почты
3. Пользователь заполняет данную форму адресом своей электронной почты
4. Система отправляет письмо с данными о логине пользователя на указанный e-mail
Альтернативные потоки:
Нет
Постусловия:
Нет
ВИ Восстановление пароля
ID: 5
Краткое описание:
Пользователь вводит адрес своей электронной почты для восстановления пароля
Основные действующие лица:
Любой пользователь системы
Предусловия:
Пользователю необходимо узнать свой пароль
Основной поток:
1. Пользователь при входе на сайт нажимает на ссылку «Забыли пароль?»
2. Системы выводит форму ввода адреса электронной почты
3. Пользователь заполняет данную форму адресом своей электронной почты
4. Система отправляет письмо с данными о пароле пользователя на указанный e-mail
Альтернативные потоки:
Нет
Постусловия:
Нет
ВИ Редактирование профиля
ID: 6
Краткое описание:
Пользователь редактирует свой профиль на сайте
Основные действующие лица:
Любой пользователь системы
Предусловия:
Пользователь авторизован в системе
Основной поток:
1. Пользователь выбирает опцию редактирования профиля
2. Система выводит окно с данными пользователя
3. Пользователь редактирует доступные для изменения данные и подтверждает нажатием кнопки «Отправить»
4. Система изменяет данные пользователя
5. Система выводит сообщение о том, что профиль пользователя сохранен
Альтернативные потоки:
Нет
Постусловия:
Нет
-
Почти идеально.
Я объясню: в системе управления проектами я организовал все таким образом, что каждый клиент будет отождествляться с проектом, а каждый заказ данного клиента будет прирваниваться к этапу проекта, дабы избежать путанницы. А уже потом задания выдаются по каждому заказу (этапу) соответственно. Я думаю могут быть случаи, когда будут исключения, например, создание какого-то стороннего проекта, например по доработке сайта, но на данном этапе все происходит именно так как я описал.
И почему же все-таки - проект=клиент и этап =заказ.
Я могу предположить, что любые действия с клиентом- есть некий проект. Проект состоит из каких-то этапов. каждый этап состоит видимо из заданий. этап порождается каким-то заказом?
-
И почему же все-таки - проект=клиент и этап =заказ.
Я могу предположить, что любые действия с клиентом- есть некий проект. Проект состоит из каких-то этапов. каждый этап состоит видимо из заданий. этап порождается каким-то заказом?
Да, именно. я так сделал чисто из-за того, чтобы "подогнать" систему управления проектами под решаемую мной задачу.
Тоесть пользователь, который заходит в систему, может легко понять с каким заказом и с каким клиентом связана данная ему задача.
Просто в систему управления проектами получается есть 3 уровня: самый обширный - это проект, в проекте может быть несколько этапов, и на каждом этапе может выдаваться несколько заданий
Так же и с клиентом: есть клиент, который делает заказы, а по каждому заказу выдаются определенные задания. Ну вот я и отождествил клиентов с проектами, а заказы с этапами, хотя, еще раз повторюсь, это не значит, что нельзя, например, создать проект "Инвентаризация складов", а в нем сделать этапы "Инвентаризация склада №1", "Инвентаризация склада №2".
Вобщем я думаю завтра доделаю ВИ, а потом хотелось бы разобраться все-таки с концептуальными классами :(
Сейчас скриншот прилеплю как выглядит система управления проектами для большей наглядности.
-
А если после завершения ЭТОГО проекта, спустя цать лет (или скорее) тот же самый клиент захочет сделать с вами еще проект?
-
Да он со мной никакого проекта не делает, у него просто со мной договор заключен, и он переодически закупает у меня светильники. какой он может со мной проект захотеть сделать ?
-
Вот набросал какоето ужасное подобие концептуальной диаграммы классов...
Посоветуйте нормальный UML редактор кроме рэшнл роуз, а то этот visual uml вообще раковый, одно мученье с ним..
-
ой там еще этап с проектом соединен агрегацией
-
короче доделал я варианты использования наконец-то :(
прикрепляю док файл, а то там много букав
хотелось бы получить комментарии относительно диаграммы концептуальных классов, спасибо.
-
Вот набросал какоето ужасное подобие концептуальной диаграммы классов...
Посоветуйте нормальный UML редактор кроме рэшнл роуз, а то этот visual uml вообще раковый, одно мученье с ним..
MagicDraw, Modelio, EA, VISIO, StarUML, да и VP отличный инструмент.
диаграмма мне не понравилась. что-то все в кучу. концептуальная - она и есть концептуальная, вопросы реализации нужно вводить постепенно.
клиент и прайс-лист - вам непременно нужно контролировать сколько каких прайс-листов скачал какой клиент? или важно контролировать количество закачек в принципе?
менеджер и прайс-лист - зачем? чтобы понять сколько менеджер науправлял? или распределить между менеджерами прайс-листы для управления?
Заказ - статус заказа - почему такая честь статусу заказа? и почему статус заказа - это материалы
прайс-листы - это материалы - мне не понятно
Почему нужно знать сколькими материалами управляет администратор? и почему менеджер управляя прайс листами лишен возможности управлять материалами?
бухгалтер- счет - счет на что формируется - на сферического коня в вакууме?
-
MagicDraw, Modelio, EA, VISIO, StarUML, да и VP отличный инструмент.
Скачал уже EA, небо и земля по сравнению с тем чем я пользовался.
диаграмма мне не понравилась. что-то все в кучу. концептуальная - она и есть концептуальная, вопросы реализации нужно вводить постепенно.
мне она самому не понравилась, но я уже засыпал когда доделывал :(
клиент и прайс-лист - вам непременно нужно контролировать сколько каких прайс-листов скачал какой клиент? или важно контролировать количество закачек в принципе?
мне вообще не нужно ничо из этого контролировать.. Я просто хотел показать как связаны объекты, видимо это неверный подход?
менеджер и прайс-лист - зачем? чтобы понять сколько менеджер науправлял? или распределить между менеджерами прайс-листы для управления?
то же самое..
Заказ - статус заказа - почему такая честь статусу заказа? и почему статус заказа - это материалы
Такая честь статусу заказа потомучто это целый раздел на сайте, в котором пользователь может посмотреть таблицу со своими заказами и статусами соответственно.. А материал это потомучто все, что располагается на сайте в виде какихто текстовых посылов - материалы. то же и с прайс-листами (ну они правда не в текстовом виде, а в виде файлов для скачивания)
Почему нужно знать сколькими материалами управляет администратор? и почему менеджер управляя прайс листами лишен возможности управлять материалами?
не знаю, почему нужно знать.. Видимо я чего-то не допонимаю просто.. убрать кратности чтоли? или вообще убрать связь?
Менеджер у меня только прайс-листами управялет, для остального - админ сайта.
бухгалтер- счет - счет на что формируется - на сферического коня в вакууме?
:)
-
Еще вопрос:
В теме примера про ИС Аттестации студентов я нашел вот такой документ
Вопрос: таблицы "Заинтересованные лица", "проблем", "цели", буквы R, P, G (я так понял это requirement, problem, goal) <== это что за методология?
http://www.uml2.ru/forum/index.php?action=dlattach;topic=1106.0;attach=1179
-
R - role, в остальном угадали. Это методология UP и просто здравого смысла:)
По поводу связей с администраторами менежерами и т.п. - вы правильно поняли тонкий намек :)
Все эти аспекты вы выражаете через ВИ например или другое взаимодействие. ДК отражает статическую, и существенную для понимания структуру
-
то есть номер потребности R1 = Role 1, а не Requirement 1 ? не логично как-то..
UP = unified process ?
нед диаграммой седня подумаю еще
-
Не пойму где вы нашли в документе R1.
Все просто заинтересованное лицо, имеющаяся проблема (потребность), цель в ее решении
-
Не пойму где вы нашли в документе R1.
Все просто заинтересованное лицо, имеющаяся проблема (потребность), цель в ее решении
Заинтересованные лица там как раз не пронумерованы
Вот где я нашел R1:
-
Ну вот, переделал в ЕА, подубрал что Вам не понравилось..
-
Вот, сделал ДВИ, помоему выглядит эпично хахаха
Тока думаю надо еще добавить ВИ Мониторинг статуса, а то пользователь не понятно как видит статус..
И еще наверное надо ВИ отправка товара.. но это вроде как выходит за рамки системы, или как?
-
Я не большой поклонник ICONIX, хотя в целом нормальный процесс, и зачем им это предшедствование и затрагивание, ну есть же в UML уже инклюды с экстендами.
И Вам не советую, "будь проще, к тебе потянутся ..."
-
Я не большой поклонник ICONIX, хотя в целом нормальный процесс, и зачем им это предшедствование и затрагивание, ну есть же в UML уже инклюды с экстендами.
И Вам не советую, "будь проще, к тебе потянутся ..."
про иконикс - я не знаю чо это и причем тут это =)
А про инклюды\не инклюды вот как получается:
В ЕА я не нашел инклюдов и экстендов, там были просиды и инвоуки
Так как я ни в том ни в том особо не разбираюсь, я почитал описание того и другого, дабы определить для себя: искать новый программный продукт, где есть инклюды и экстенды, либо разобраться в том в чем есть.
Так вот описание эстендов и инклюдов, в которых я честно сказать нихера не понял:
Отношение расширения
Отношение расширения определяет взаимосвязь экземпляров отдельного варианта использования с более общим вариантом, свойства которого определяются на основе способа совместного объединения данных экземпляров. В метамодели отношение расширения является направленным и указывает, что применительно к отдельным примерам некоторого варианта использования должны быть выполнены конкретные условия, определенные для расширения данного варианта использования. Так, если имеет место отношение расширения от варианта использования А к варианту использования В, то это означает, что свойства экземпляра варианта использования В могут быть дополнены благодаря наличию свойств у расширенного варианта использования А.
Отношение включения
Отношение включения между двумя вариантами использования указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования.
Семантика этого отношения определяется следующим образом. Когда экземпляр первого варианта использования в процессе своего выполнения достигает точки включения в последовательность поведения экземпляра второго варианта использования, экземпляр первого варианта использования выполняет последовательность действий, определяющую поведение экземпляра второго варианта использования, после чего продолжает выполнение действий своего поведения. При этом предполагается, что даже если экземпляр первого варианта использования может иметь несколько включаемых в себя экземпляров других вариантов, выполняемые ими действия должны закончиться к некоторому моменту, после которого должно быть продолжено выполнение прерванных действий экземпляра первого варианта использования в соответствии с заданным для него поведением.
Один вариант использования может быть включен в несколько других вариантов, а также включать в себя другие варианты. Включаемый вариант использования может быть независимым от базового варианта в том смысле, что он предоставляет ему некоторое инкапсулированное поведение, детали реализации которого скрыты и могут быть перераспределены между несколькими включаемыми вариантами использования. Более того, базовый вариант может зависеть только от результатов выполнения включаемого в него поведения, но не от структуры включаемых в него вариантов.
Отношение включения, направленное от варианта использования А к варианту использования В, указывает, что каждый экземпляр варианта А включает в себя функциональные свойства, заданные для варианта В. Эти свойства специализируют поведение соответствующего варианта А на данной диаграмме. Графически данное отношение обозначается пунктирной линией со стрелкой, которая помечается ключевым словом «include» (включает).
И вот описание инвоуков и просидов, которое на английском языке, но я понял его за секунду тем не менее:
Invokes and Precedes relationships are defined by the Open Modeling Language (OML). They are stereotyped Dependency relationships; Invokes indicates that Use Case A, at some point, causes Use Case B to happen, whilst Precedes indicates that Use Case C must complete before Use Case D can begin.
Так что я как раз выбрал менее загонный путь лично для себя =)
-
о я нашел нужные стрелочки =)
ну они мне все равно не нравятся
-
А про инклюды\не инклюды вот как получается:
В ЕА я не нашел инклюдов и экстендов, там были просиды и инвоуки
Так как я ни в том ни в том особо не разбираюсь, я почитал описание того и другого, дабы определить для себя: искать новый программный продукт, где есть инклюды и экстенды, либо разобраться в том в чем есть.
о я нашел нужные стрелочки =)
ну они мне все равно не нравятся
Я долго смеялся
-
Заинтересованные лица там как раз не пронумерованы
Вот где я нашел R1:
уел:) ну значит r - требования потребности (request или requirement)
-
Вот, сделал ДВИ, помоему выглядит эпично хахаха
Цель ДВИ - дать контекст и общий обзор.
Задача контекста показать:
- кто будет пользоваться системой - т.е. кто или что вне границы системы
- показать саму границу системы - boundary
- показать цели использования системы внешними сущностями - то есть именнованные в терминах цели пользователя обязанности (отвественности) системы = варианты использования
- возможно как-то структурировать это в целях улучшения отображения
-
Я долго смеялся
Я старался чо.
- показать саму границу системы - boundary
- показать цели использования системы внешними сущностями - то есть именнованные в терминах цели пользователя обязанности (отвественности) системы = варианты использования
границу не могу показать - не умещается. за границей в основном всегда только акторы стоят (другого не встречал, хотя Вы может и встречали - я не такой знаток)
Вопрос: можно ли на ДВИ отобразить прецедент, которого нет в сценариях ВИ, и он происходит не при помощи системы, но влияет на другие прецеденты (я говорю конкретно про отгрузку товара). Например, он влияет на формирование статуса и зависим от мониторинга ИСУП..
-
Вопрос: можно ли на ДВИ отобразить прецедент, которого нет в сценариях ВИ, и он происходит не при помощи системы, но влияет на другие прецеденты (я говорю конкретно про отгрузку товара). Например, он влияет на формирование статуса и зависим от мониторинга ИСУП..
НЕт, вариант использование рассматриваемой системы. Если хочешь показать другие прецеденты, расширяй контекст.
-
НЕт, вариант использование рассматриваемой системы
ну а если например нарисовать границу системы и прецедент вынести за эту границу? =) нельзя так сделать ?
Если хочешь показать другие прецеденты, расширяй контекст.
Это как сделать ? :(
Еще вопрос. Про диаграмму развертывания. Вот например у меня есть физческий сервер и я на него устанавливаю веб-сервер, сервер базы данных, php.. Узлом будет являться только физический сервер, а все остальное - компонентами узла, или как?
-
ну а если например нарисовать границу системы и прецедент вынести за эту границу? =) нельзя так сделать ?
Потом нарисовать еще одну границу дать ей название, по смыслу включающее и новый прецедент и уже имеющейся баундэри и часть акторов. Можно, только мы получим уже совсем другую историю. UML однозначного ответа не дает, поскольку не регламентирует такие попытки, пробуй! Вопрос в целесообразности.
Еще вопрос. Про диаграмму развертывания. Вот например у меня есть физческий сервер и я на него устанавливаю веб-сервер, сервер базы данных, php.. Узлом будет являться только физический сервер, а все остальное - компонентами узла, или как?
http://www.uml-diagrams.org/deployment-diagrams.html
Узел - это физическое устройство или некоторая операционная среда. Делаем вывод, что это можно рассматривать как операционную среду, т.е. узел - вот пример http://www.uml-diagrams.org/deployment-diagrams-examples.html#web-application
вообще покопайся http://www.uml-diagrams.org, IMO много полезного, хотя и по-английски, но делал наш бывший гражданин (хотя может и не бывший)
-
http://www.uml-diagrams.org/deployment-diagrams.html
Узел - это физическое устройство или некоторая операционная среда. Делаем вывод, что это можно рассматривать как операционную среду, т.е. узел - вот пример http://www.uml-diagrams.org/deployment-diagrams-examples.html#web-application
вообще покопайся http://www.uml-diagrams.org, IMO много полезного, хотя и по-английски, но делал наш бывший гражданин (хотя может и не бывший)
Отправлено: Мая 28, 2011, 10:20:45 pm
Спасибо за ссылки =) хорошо все написано.
Как я понял компоненты уже давно входят в узлы окружения и, соответственно, не отображаются на схемах.
Единственная трудность для меня теперь - это как придумывать названия "артефактам"..
-
Передел ДВИ и сделал диаграмму развертывания. Посмотрите, пожалуйста
-
С диаграммой концептуальных классов никак не разберусь.. Поудалял связи какие Вам не понравились, и теперь чето ничо ни с чем не связано..
-
Вот сделал диаграмму последовательности для ВИ "создание проекта", но чето мне не нравится, что активация там в некоторых местах прирывется, и что обратные стрелочки не пунктиром нарисованы.. Да и вообще, укажите мои ошибки, пожалуйста.
-
С диаграммой концептуальных классов никак не разберусь.. Поудалял связи какие Вам не понравились, и теперь чето ничо ни с чем не связано..
Не, я просто задал вопросы. Я не советовал их удалять, нужно внимательно подумать, нужна ли тут связь, стоит ли ее хранить
-
обратные стрелочки не пунктиром нарисованы..
Ну нельзя было сказать: "Поставь галочку "Is Return""?.. Я полчаса искал как этот возврат сделать..
-
Передел ДВИ и сделал диаграмму развертывания. Посмотрите, пожалуйста
А тебе самому твоя ДВИ нравится?
1. зачем нужна картинка? для того чтобы лучше быстрее и проще понять то, что написано словами. А у тебя что? лес ассоциаций, куча овальчиков
2. распределение ВИ и ролей - по-моему не продуманное. Например, администратор - то он управляет аккаунтами пользователей, то уже выставляет какие-то счета - смешение ролей явное
3. на одной диаграмме представлены ВИ разного уровня нужности. одни относяся к бизнес-контексту, другие просто к организации работы системы, я бы разделил их на две диаграммы
4. Название ВИ не всегда понятны. А инклюды с эксендами лишние. Каков в них смылс неясно. Выставление счета расширяет Мониторинг ИСУП (а где точка расширения, где условие)
и т.д.
-
Ну нельзя было сказать: "Поставь галочку "Is Return""?.. Я полчаса искал как этот возврат сделать..
Знание добытое самостоятельно наиболее ценно!
Что сказать по поводу ДП.
Каковое назначение, что ты хотел ею сказать и кому?
Варианты ответа:
научному руковдителю - смотри мол я умею рисовать ДП
будущей комиссии - смотрите мол я ведь знаю что такое UML и даже знаю что такое ДП
самому себе - понять как будет реализован ВИ, какие классы нужно добавить, как правильно распределеить обязанности между классами
Далее поскольку ты выбрал типичный принцип разделение интерфейса и модели, то выбор в качестве управляющего класса Систему, выглядет несколько странно. Я думаю что в данном случае как минимум это должен быть контроллер варианта использования
Далее каким образом происходит сохранение объекта Проект? Куда он сохраняется? Из реализации ВИ не ясно
-
А тебе самому твоя ДВИ нравится?
да так себе.
2. распределение ВИ и ролей - по-моему не продуманное. Например, администратор - то он управляет аккаунтами пользователей, то уже выставляет какие-то счета - смешение ролей явное
в "выставление счета" у меня входит собственно составление счета бухгалтером + публикация ссылки на этот счет на сайте, что делает как раз администратор.
4. Название ВИ не всегда понятны. А инклюды с эксендами лишние. Каков в них смылс неясно. Выставление счета расширяет Мониторинг ИСУП (а где точка расширения, где условие)
Условие простое: " В ходе мониторинга заданий в СУП обнаружено задание на публикацию счета".. Где это прописывать надо? в пометке к прецеденту?
на одной диаграмме представлены ВИ разного уровня нужности. одни относяся к бизнес-контексту, другие просто к организации работы системы, я бы разделил их на две диаграммы
Согласен, это самому не нравится... Но я чето не знаю как их разделить..
Знание добытое самостоятельно наиболее ценно!
=)
Что сказать по поводу ДП.
Каковое назначение, что ты хотел ею сказать и кому?
Варианты ответа:
научному руковдителю - смотри мол я умею рисовать ДП
будущей комиссии - смотрите мол я ведь знаю что такое UML и даже знаю что такое ДП
самому себе - понять как будет реализован ВИ, какие классы нужно добавить, как правильно распределеить обязанности между классами
Все 3 варианта.. А научный руководитель к сожалению сам не умеет рисовать ДП 8(
Далее каким образом происходит сохранение объекта Проект? Куда он сохраняется? Из реализации ВИ не ясно
Сохранение объекта проект происходит в базу данных mysql очевидно, в таблицу "проекты".
Далее поскольку ты выбрал типичный принцип разделение интерфейса и модели, то выбор в качестве управляющего класса Систему, выглядет несколько странно. Я думаю что в данном случае как минимум это должен быть контроллер варианта использования
Вся проблема в том, что я занимаюсь так называемым "обратным проектированием", тоесть систему я уже сделал, а теперь пытаюсь ее описать, мне бы, например, было бы легче наоборот (тоесть спроектировать, и не делать ничего), но я не ищу легких путей видимо.
Так вот, я не очень знаю какой класс выбрать для "контроллера", поэтому я назвал его абстрактно "System", тоесть система управления контентом \ движок сайта, называйте как хотите, при помощи него выполняются все движения по сайту, sql запросы, записи в БД и т.д. на мой взгляд..
-
А вы описание предметной области будете делать, или ограничитесь вариантами использования?
-
Описание предметной области у меня уже со всех сторон сделано =) я типа внедряю фирме, занимающейся розничной торговлей ИС для проведения оптовой торговли и повышения эффективности управления и работы с информацией сотрудников внутри организации, вместе с формированием клиентской базы и т.д.
-
Если вы конкретно про нотацию uml, то такого в задании вроде нет, но я подумаю над этим.. спасибо
-
Мне было бы интересно увидеть раскритикованную бизнес-модель предметной области. Сам не до конца разобрался, хотелось бы извлечь для себя некий шаблон, где есть: бизнес диаграмма вариантов использования, диаграмма бизнес объектов. И хочется понять в каких случаях строят другие диаграммы для бизнес модели.
-
Мне было бы интересно увидеть раскритикованную бизнес-модель предметной области. Сам не до конца разобрался, хотелось бы извлечь для себя некий шаблон, где есть: бизнес диаграмма вариантов использования, диаграмма бизнес объектов. И хочется понять в каких случаях строят другие диаграммы для бизнес модели.
уберите отовсюду слово "бизнес" для начала =)
И диаграмма бизнес-объектов - это по идее и есть модель предметной области, да и вообще формулировку "диаграмма бизнес-объектов" я только на этом сайте и встречал..
Кстати говоря, переделал модель предметной области, покритикуйте меня, пожалуйста, товарищ Galogen =)
-
Кстати говоря, переделал модель предметной области, покритикуйте меня, пожалуйста, товарищ Galogen =)
Критиковать, это мы завсегда. Ну держись.
1. Зачем сущность сайт на диаграмме? Какую смысловую нагрузка она несет, чем характеризуется? Как ты собираешься в конкретной предметке различать РАЗНЫЕ сайты
2. Какой смысл указывать что на сайте размещена система управления проектами? А какую систему вообще моделирует данная предметная область?
3. Среди группы пользователей ясно выделяются: администратор - человек управляющий и настраивающий системы - никакого отношения к реальной бизнес-системе управления проектами не имеющего; сотрудник некой компании которые работаю по проектам (менеджер, бухгалтер, завскладом), клиент - тот кто размещает заказ
4. Сотрудники - исполнители проекта. У любого проекта есть отвественный или руковдитель. Проект состоит из этапов, этапы из заданий. В задании (этапе или проекте) имеется автор - который предлагает его к производству, менеджер, который определяет кто конкретно будет исполнять задание, исполнитель - который будет его исполнять, возможно проверяющий который принимает работу. Т.е. Менеджер, бухгалтер или завскладом для системы - просто участник проекта или сотрудник. Поскольку в задании нужно как миними указать менеджера, бухгалтера, завскладом (чтобы это не значило), то это можно передать ролью!!! которую играет человек в конкретном проекте
5. ассоциации ни в коем случае не должны сливаться как показано у тебя. Это грубейшая ошибка. Сливание ветвей допустимо только в обобщении иногда в агрегации и композиции.
6. Счет, если что, не является юридическим документом. В данном случае вообще не очень понятно выделение счета как сущности, достаточно было бы использовать Заказ
7. Проект как я понял связан с заказом, из модели этого не видно
8. Зачем нужно указывать Админа в заданиях и связи с контентом? Если для контента важно кто его создавал - допускаю эту мысль, то я все равно настаиваю. тут нужно рассматривать две модели: модель системы управления проектами и модель сайта - но это уже скорее будет модель артефактов
-
И диаграмма бизнес-объектов - это по идее и есть модель предметной области, да и вообще формулировку "диаграмма бизнес-объектов" я только на этом сайте и встречал..
Вот поэтому я и спрашиваю здесь с чем её едят, так как больше нигде не найти(на русских порталах). Например, не ясно нужно ли строить отдельно БДВИ предметной области и БДВИ системы или они по хорошему будут выглядеть одинаково и представлять из себя одну диаграмму?
FAQ на этом сайте трактует одназначно:
На Бизнес Диаграмме ВИ (БДВИ) отображается, как взаимодействуют внешние пользователи с вашей организацией для достижения бизнес целей.
Но у меня закрались сомнения разве не нужно делать БДВИ для самой системы, а не для предметной области? Просто где-то видел это в инете.
-
1. Зачем сущность сайт на диаграмме? Какую смысловую нагрузка она несет, чем характеризуется? Как ты собираешься в конкретной предметке различать РАЗНЫЕ сайты
ну не знаю, помоему она добовляет наглядность модели.. Плюс только пользователи имеют доступ к сайту, что тоже немаловажно, т.к. сайт закрытый.
2. Какой смысл указывать что на сайте размещена система управления проектами? А какую систему вообще моделирует данная предметная область?
Информационную систему предприятия которую я создаю, включающую интранет и экстранет часть (ИСУП и сам сайт соответственно)
В задании (этапе или проекте) имеется автор - который предлагает его к производству, менеджер, который определяет кто конкретно будет исполнять задание, исполнитель
Менеджер у меня и есть автор..
Поскольку в задании нужно как миними указать менеджера, бухгалтера, завскладом (чтобы это не значило), то это можно передать ролью!!! которую играет человек в конкретном проекте
Я вот это не очень понял.. А где эти роли описываются? в вариантах использования?
Вроде как модель предметной области это "графический словарь", в котором графически отображено как термины предметной области связаны между собой..
Я думаю может просто объеденить админа, бухгалтера и завскладом в 1 какую-то группу, типа "персонал", и показать, что персонал получает задания, а менеджер выдает..
5. ассоциации ни в коем случае не должны сливаться как показано у тебя. Это грубейшая ошибка. Сливание ветвей допустимо только в обобщении иногда в агрегации и композиции.
ок, исправлю, думал просто покомпактнее сделать, не знал что нельзя 8(
7. Проект как я понял связан с заказом, из модели этого не видно
Вот это да, надо бы как-то связать, забыл реально..
8. Зачем нужно указывать Админа в заданиях и связи с контентом? Если для контента важно кто его создавал
Для контента не важно, а для меня и для понимания системы - важно. Это неправильно?
6. Счет, если что, не является юридическим документом. В данном случае вообще не очень понятно выделение счета как сущности, достаточно было бы использовать Заказ
Думаю надо просто показать, что счет тоже является контентом
-
хотя, блин, менеджер тоже к персоналу относится.. не знаю блин.. может, производственный персонал?)
-
ну не знаю, помоему она добовляет наглядность модели.. Плюс только пользователи имеют доступ к сайту, что тоже немаловажно, т.к. сайт закрытый.
Я думаю, что для этого существуют другие диаграммы, но никак ни диаграмма классов.
Информационную систему предприятия которую я создаю, включающую интранет и экстранет часть (ИСУП и сам сайт соответственно)
см. выше
Менеджер у меня и есть автор..
Автор - то кто предлагает работу, источник работы.
Менеджер - тот кто определяет исполнителя
Менеджер может быть автором, а может и не быть.
Автором проекта вялестя Клиент например
Я вот это не очень понял.. А где эти роли описываются? в вариантах использования?
Могут и на ДВИ и могут на ДК
Вроде как модель предметной области это "графический словарь", в котором графически отображено как термины предметной области связаны между собой..
и каковы же термины вашей предметной области?
Я думаю может просто объеденить админа, бухгалтера и завскладом в 1 какую-то группу, типа "персонал", и показать, что персонал получает задания, а менеджер выдает..
может быть, только персонал - это группа, а админ - это не персонал, а часть персонала, представитель персонала. Понятна аналогия?
Для контента не важно, а для меня и для понимания системы - важно. Это неправильно?
Для себя вовсе не обязательно выкладывать на обозрение и происть помощи. Для меня не понятно. Это другая модель.
Бухгалтер контентом не мыслит знаете ли :)
[/quote]
-
Короче я запутался вконец.. Вот сделал еще вариант, не знаю уже..
-
Короче я запутался вконец.. Вот сделал еще вариант, не знаю уже..
Для домейна нормально. Только добейся, чтобы не было пересечения связей
-
Для домейна нормально. Только добейся, чтобы не было пересечения связей
еее спасибо.
Ну вот, только 1 пересечение, не знаю как от него избавиться..
Еще вопрос: Вы случайно не знаете как такую стрелочку в ЕА сделать, как во вложении №2 ?
-
Еще вопрос: по хорошему модель предметной области строится же до вариантов использования, да?
-
Еще вопрос: Вы случайно не знаете как такую стрелочку в ЕА сделать, как во вложении №2 ?
Это direction. Кликаешь по имени ассоциации правой кнопкой мыши, где-то там найдешь direction
Еще вопрос: по хорошему модель предметной области строится же до вариантов использования, да?
параллельно я бы сказал. итерационно
-
А система управления проектами может входить в модель предметной области? Если мы её допустим только разрабатываем. Я бы нарисовал без неё.
-
А система управления проектами может входит в модель предметной области? Если мы её допустим только разрабатываем. Я бы нарисовал без неё.
И я о том же..
-
А система управления проектами может входить в модель предметной области? Если мы её допустим только разрабатываем. Я бы нарисовал без неё.
Ну блин, как я тогда покажу как счет, например, формируется, если он у меня вне системы вообще делается (бухгалтером в 1с или там в екселе).. А так я все составляющие вместе связал..
Я сначала так и хотел сделать, типа с устными поручениями, или там по телефону.. Но что это тогда за система.. Клиент-заказ-статус-админ, все.. Не интересно.
Я могу конечно нарисовать: Клиент аплоадит заказ, админ обновляет статус... =)
Это direction. Кликаешь по имени ассоциации правой кнопкой мыши, где-то там найдешь direction
Я это находил уже, это делает ассоциацю направленной (ну на конце стрелочка рисуется всмысле), а что бы рядом со словом - не могу найти.. 8(
-
А все, нашел, надо на самом лейбле ткнуть, спасибо.
-
Я вот думаю, надо ли в моем случае делать диаграмму классов, диаграммау коммуникации, диаграмму состояний.. Они ведь больше уже к программной реализации относятся.. Мне кажется это юслесс..
Диаграмму деятельности еще можно наверное сделать..
-
Вот, можно так сделать? =) все довольны будут тогда)
-
А администратор не авторизуется? На самом деле я почитав этот форум стал выкидывать из своих диаграмм авторизацию. Так как у меня при входе на любой сайт нет цели регистрироваться и авторизоваться. Это даже напрягает. С редактированием профиля можно тоже поспорить. Хотя у меня на диаграмме этот ВИ присутствует.
Присутствует на моей диаграмме и пакет администрирование. Свою диаграмму я делал задолго до вас и пакет выглядят практически также. Только я туда добавил редактирование прав файлов. но возможно тоже выкину.
По-моему ВИ загрузка заказа должен быть на более абстрактном уровне. В книге Коберна можно почитать про уровни вариантов использования.
Но мне интереснее другое. Я как то пробовал разбивать элементы на пакеты. Получается так что ДВИ и диаграмма классов связаны одними и теми же пакетами. И когда доходим до этапа генерации кода из диаграмм, пакеты превращаются в названия папок, в которых создаются исходники. Может быть в EA тоже самое по смыслу получится? Тогда стоит называть пакеты таким образом, чтобы потом компилятор с названиями таких папок корректно работал. У меня названия пакетов это английские короткие названия. Конечно для вас это может быть не существенно, но мне хотелось бы разобраться.
Это в EA выглядит так диаграмма всех пакетов? или это только диаграмма пакетов для вариантов использования?
-
Я тут подразобрался, мне терь кажется, что таким образом как я вот выложил в предыдущем посте вообще нельзя с пакетами работать. Теперь у меня просто список пакетов, в каждый из которых помимо ВИ включены еще акторы, и каждый пакет я рассмотрел как отдельную ДВИ..
Про генерацию кода я вообще ничо не знаю, никогда не работал с этим.. Но мне кажется, что код все-таки лучше в ручную писать на основании сделанных диаграмм.
По-прежнему еще очень интересует вопрос:
Я вот думаю, надо ли в моем случае делать диаграмму классов, диаграммау коммуникации, диаграмму состояний.. Они ведь больше уже к программной реализации относятся.. Мне кажется это юслесс..
-
Еще услышал от препода такую тему, что "Прецеденты в диаграмме прецедентов должны идти по порядку их использования сверху вниз".. Я если честно не слышал о таком до этого.. Вроде как для этого другие диаграммы есть.. Или действительно необходимо размещать их в порядке возникновения? Просто там довольно много параллельных прецедентов например существует.. что скажете?
-
Еще услышал от препода такую тему, что "Прецеденты в диаграмме прецедентов должны идти по порядку их использования сверху вниз".. Я если честно не слышал о таком до этого.. Вроде как для этого другие диаграммы есть.. Или действительно необходимо размещать их в порядке возникновения? Просто там довольно много параллельных прецедентов например существует.. что скажете?
Первый раз слышу. Хотя сколько людей столько мнений. Включай свой рассудок.
Диаграмма классов нужна - все ООП на этом построено, а у тебя не будет. весь вопрос какие классы ты планируешь рассмотреть, только предметки и интерфейсные? Читай руп или иконикс, там все ответы
-
Диаграмма классов нужна - все ООП на этом построено, а у тебя не будет. весь вопрос какие классы ты планируешь рассмотреть, только предметки и интерфейсные? Читай руп или иконикс, там все ответы
Ну я ведь делал модель предметной области, это вроде как сродни диаграмме классов с концептуальной точки зрения. Или надо рассмотреть диаграмму классов с точки зрения спецификации\реализации ? Я тут теряюсь вообще.. Хотел без нее обойтись, у меня ведь уже есть реализация..
А какие книжки по руп\иконикс посоветуете? я юзаю "UML. Основы" Мартина Фаулера и "UML 2 и унифицированный процесс" Джим Арлоу\Айла Нейштадт..
-
Вот еще чо слепил.. =)
-
На сколько корректно соединять стрелочкой отправку и приём сигнала, я никогда так не делал? Я бы заменил двумя элементами Action
-
На сколько корректно соединять стрелочкой отправку и приём сигнала, я никогда так не делал? Я бы заменил двумя элементами Action
ты про "оплатить счет" --> "получить сведения об оплате" ? А чем еще соединять отправку и прием кроме стрелочки?)
Вот тут (http://www.sparxsystems.com/enterprise_architect_user_guide/8.0/modeling_languages/receive.html) в примере даже соединено так..
Ну вообще я ни в чем не уверен, т.к. 1ый раз такую диаграмму делал =)
-
Я бы заменил зависимостью. пунктирной стрелкой со стереотипом типа месадж
-
Ну я ведь делал модель предметной области, это вроде как сродни диаграмме классов с концептуальной точки зрения. Или надо рассмотреть диаграмму классов с точки зрения спецификации\реализации ? Я тут теряюсь вообще..
Видел, что некоторые строят диаграмму классов предметной области. В ней не упоминаются классы самой системы. Сам не разобрался насколько она нужна, если есть диаграмма бизнес-объектов. Эдуард вероятно говорил о диаграмме классов для реализации системы. Скорее всего в вашем случае нужно смотреть на реализацию и по ней делать диаграмму классов.
Ваша система реализована на классах или процедурах?
Хотел без нее обойтись, у меня ведь уже есть реализация..
У вас хорошо получается, зачем останавливаться :) Ваш пример поможет не только нам лучше разобраться, но и многим другим. Тема очень актуальная. Кроме того, сделав полную модель системы, вы можете найти ошибки в реализации.
-
хз мозги плавятся, сделал пока вот так.. На типы данных тока не смотрите, я там их нигде не выставлял почти пока что.
Это очень упрощенно, я никогда в жизни не смогу сделать полную диаграмму классов всей джумлы со всеми модулями, это итак понятно.. Да это и никому не нужно я думаю..
Еще порой тяжело отличать объекты класса от классов-потомков.. Например вот с группами разобраться не могу. Каждая группа это класс, или это объект класса "группа"? :(
Просто у них иерархическая зависимость, и все значения передаются в зависимости от включения одной группы в другую..
-
Это очень упрощенно, я никогда в жизни не смогу сделать полную диаграмму классов всей джумлы со всеми модулями, это итак понятно.. Да это и никому не нужно я думаю..
А ты ее вообще не должен показывать - это не твои классы. Ты лишь можешь показать классы родители и то не очень подробно, так как реализация их скажем не в твоей компетенции. А вот дальше ты берешь и делаешь
На самом деле джумла фреймвёрк, ведь ты делаешь компонент, модуль или бот, согласно принятой технологии самого каркаса. Где-то можно указать шаблон такого каркаса, кооперацию там, а потом показать свое намясывание
-
А ты ее вообще не должен показывать - это не твои классы. Ты лишь можешь показать классы родители и то не очень подробно, так как реализация их скажем не в твоей компетенции
Ну я вроде как так и старался сделать примерно.. Похоже хоть немного на правду ?
-
Я конечно не эксперт в ООП. Но если у класса потомка от класса родителя наследуются методы то зачем прописывать у потомков класса Module SetAccessLevel? Возможно это перезагрузка метода? В любом случае хотелось бы услышать ваши комментарии.
Так, а чем закончилось разбиение на пакеты, в классах они бы пригодились. Очень удобно работать с классами разбитыми на пакеты.
А диаграмму состояний не будете делать? просто можно на ней показать как мы по формам двигаемся.
Кстати может сделать класс формы, как родителя класса меню? вместо наследования от класса модуль.
И если используете пакеты, то диаграмму пакетов тоже хотелось бы увидеть. Может вам лучше файл офисного пакета выкладывать. а то не хватает комментариев по диаграммам.
-
Ну я вроде как так и старался сделать примерно.. Похоже хоть немного на правду ?
Похоже. Но помни, не следует показывать все, показывай главное. Ведь каждый модуль можно рассмотреть отдельно. Joomla фреймвёрк MVC. Каждый функциональный блок в нем самостоятелен, покажи на одной диаграмме только функционально связанные классификаторы.
Да если смотреть на способ реализации все-таки там должен быть класс представления, класс управления и класс моделей, я не ошибаюсь?
-
Я конечно не эксперт в ООП. Но если у класса потомка от класса родителя наследуются методы то зачем прописывать у потомков класса Module SetAccessLevel? Возможно это перезагрузка метода? В любом случае хотелось бы услышать ваши комментарии.
перегрузка всмысле? ну да, наверное, я просто сам уже все ооп забыл.. ты в ЕА галочки появились заимствования, я и выбрал методы.. косяк кароче.
А диаграмму состояний не будете делать? просто можно на ней показать как мы по формам двигаемся.
не знаю.. мне уже сдавать через пару дней, а я нихрена не успеваю.. может и сделаю, если разберусь :(
Кстати может сделать класс формы, как родителя класса меню? вместо наследования от класса модуль.
не, в джумле меню - это именно модуль.. А вот класс формы можно бы сделать, только это слишком перегрузит диаграмму, потомучто там везде какие-то формы используются.. не знаю.. надо подумать, а времени нет..
Joomla фреймвёрк MVC. Каждый функциональный блок в нем самостоятелен, покажи на одной диаграмме только функционально связанные классификаторы.
да уж, жаль я раньше не знал о существовании этого шаблона.. теперь все стало понятнее.. жаль только поздновато
-
так это получается для каждого уровня надо свою диаграмму классов? или достаточно указания каждого из классов на 1 модели?
-
да уж =)
http://joomlacode.org/gf/project/joomla/scmsvn/?action=browse&path=/documentation/joomla.uml/
-
Диаграмма состояний для ви "загрузка заказа"
-
перегрузка всмысле? ну да, наверное, я просто сам уже все ооп забыл.. ты в ЕА галочки появились заимствования, я и выбрал методы.. косяк кароче.не знаю..
ну если EA так показывает методы наследованные от родителя то не косяк. но надо быть готовым отстоять свою диаграмму перед комиссией. Если остальные диаграммы они возможно в глаза не видели, то диаграмма классов очень распространена.
мне уже сдавать через пару дней, а я нихрена не успеваю..
Я советую оставить как есть, займитесь оформлением. А потом если будет интересно разберемся до конца, наверняка вам поставят хорошую оценку если будет хорошо подано.
По диаграмме состояний ничего вам говорить не буду, потому сам не до конца с ней разобрался. Мне хотелось чтобы вы её сделали, и увидеть реакцию экспертов.
Научные работы часто критикуют из-за отсутствия сравнения с аналогами, думаю этому стоит уделить большее внимание нежели проектированию.
А как сдадите и появится свободное время хотелось бы от вас услышать оценку фреймворка джумла. Что он позволяет сделать, чего не позволяет, и чем лучше других. Просто я сам про него не слышал.
-
По ДС.
Это, конечно, не совсем ДС, скорей диаграмма последовательности экранных форм. Но не будем придираться к мелочам, укажем на серьезные недостатки.
1. В целом неплохо
2. Вход - тут можно указать либо как событие, либо как действие на переходе (скорее последнее): открыта сессия, начался сеанс
3. Вести логин и пароль - это внутренняя деятельность в состоянии Форма авторизации. Триггер=событие = Нажата кнопка Submit [Логин + пароль = @Логин + @Пароль]
4. Из этог же состоянию будет переход в само состояние (хотя можно и не указывать) Нажата кнопка Submit [Логин <> @Логин |Пароль<> @Пароль]/showMessage('Нет пользователя с такими учетными данными')
5. все что у тебя в [] - сторожевое условие, или просто УСЛОВИЕ - выражение булевского типа, а не то что у тебя. ТО что у тебя либо триггер либо действие на переходе. Сторожевое условие необязателно, но если есть то говорит возможен ли переход из одного состояния в другое. С.У. обязательно если из состояния есть несколько переходов, в текущий момент времени возможен только один т.е XOR условие
6. Выход должен приводить не к форме авторизации, а к прекращению сеанса и конечному псевдосостоянию. Либо суперсостояние Сайт нужно убить как лишнее и не нужное, только затрудняющее понимание
-
ну если EA так показывает методы наследованные от родителя то не косяк.
Да не, там как раз имелась ввиду наверное перегрузка метода, а я чето забыл про эту тему, хорошо что ты напомнил =)
Я советую оставить как есть, займитесь оформлением. А потом если будет интересно разберемся до конца, наверняка вам поставят хорошую оценку если будет хорошо подано.
спасибо =) я вообще просто сдать хоть на чето надеюсь
А как сдадите и появится свободное время хотелось бы от вас услышать оценку фреймворка джумла. Что он позволяет сделать, чего не позволяет, и чем лучше других.
Ок))
А вообще, UML - весьма интересная штука, хотелось бы и дальше ей заниматься. Только вот я думаю, что все-таки для генерации кода uml не очень применим, а вот на более асбтрактном и иногда, наверное, даже бытовом уровне, его применение может быть весьма полезно имхо.
Цитата
По ДС.
Это, конечно, не совсем ДС, скорей диаграмма последовательности экранных форм. Но не будем придираться к мелочам, укажем на серьезные недостатки.
1. В целом неплохо
2. Вход - тут можно указать либо как событие, либо как действие на переходе (скорее последнее): открыта сессия, начался сеанс
3. Вести логин и пароль - это внутренняя деятельность в состоянии Форма авторизации. Триггер=событие = Нажата кнопка Submit [Логин + пароль = @Логин + @Пароль]
4. Из этог же состоянию будет переход в само состояние (хотя можно и не указывать) Нажата кнопка Submit [Логин <> @Логин |Пароль<> @Пароль]/showMessage('Нет пользователя с такими учетными данными')
5. все что у тебя в [] - сторожевое условие, или просто УСЛОВИЕ - выражение булевского типа, а не то что у тебя. ТО что у тебя либо триггер либо действие на переходе. Сторожевое условие необязателно, но если есть то говорит возможен ли переход из одного состояния в другое. С.У. обязательно если из состояния есть несколько переходов, в текущий момент времени возможен только один т.е XOR условие
6. Выход должен приводить не к форме авторизации, а к прекращению сеанса и конечному псевдосостоянию. Либо суперсостояние Сайт нужно убить как лишнее и не нужное, только затрудняющее понимание
Спасибо большое за пояснения. Поизучал еще немного теорию этой диаграммы, в итоге переделал вот во что. Мне все-таки не очень хочется убирать состояние "сайт", т.к. оно показывает, что пользователь гипотетически может совершать и другие действия после загрузки заказа на сайте. Не знаю, может я и не прав :(
-
http://caveman.ru/yii.1.1.2r2135.png вот кстати диаграмма классов yii framework. Не встречали такое для джумлы?
Обратите внимание на название пакетов.
-
Rave,
ну зачем тебе сайт? Смешно как-то. По сути ты хочешь сказать, что войдя на сайта, посетитель получает сеанс и находится в этом сеансе пока не закроет браузер, не покинет сайт, не произойдет дисконнект.
После авторизации - ты пропускаешь посетителя в закрытую зону.
В любой момент времени может произойти обрыв сессии, по желанию или без посетителя.
Показав составное состояние, вовсе не нужно явно показывать переходы из всех состояний по событию выход. Если оно призойдет, тебя так и так выкинет из сеанса и тебе придется начинать новый следовательно пройдешь авторизацию
-
Показав составное состояние, вовсе не нужно явно показывать переходы из всех состояний по событию выход. Если оно призойдет, тебя так и так выкинет из сеанса и тебе придется начинать новый следовательно пройдешь авторизацию
ну под выходом имеется ввиду разлогинивание, это можно сделать со всех страниц сайта, но не со всех состояний. Ну типа как переход на домашнюю страницу.. Тоесть нельзя нажать, например, когда открыто диалоговое окно загрузки файла.. Я не знаю, убрать, не нужно это?
Цитата
http://caveman.ru/yii.1.1.2r2135.png вот кстати диаграмма классов yii framework. Не встречали такое для джумлы?
Я вообще таких картинок не встречал раньше =) какой псих это делал))
Для джумлы я находил только упрощенные ЕР диаграммы, например:
http://oozman.com/wp-content/uploads/2011/03/joomla-15-erd.png
http://img142.imageshack.us/img142/2519/joomla10databasetables1ge.png
хотя вторая вообще какаято странная..
Ну и по той ссылке, что я постил раньше находятся вообще все UML диаграммы, относящиеся к джумле, просто они не слеплены в 1 картинку)
-
вопросы по диаграмме коммуникаций:
изображаются ли на ней return messages?
в ней участвуют объекты, которые я выделил в концептуальной модели? или программные классы? или в моем случае формы?
вообще есть какие-нибудь рекомендации по этой диаграмме? А то чето в инете очень скупо описано про нее..
-
И еще как показать на ней условие ?
-
И еще как показать на ней условие ?
на чем на диаграмме коммуникации? Я бы не стал этого делать. ДК - суть протокол
-
Так правильно?
-
Цель диаграмм последовательности и коммуникации состоит в проверке корректности разделения обязанностей между классами. Здесь следует действовать согласно принципам Low Coupling и High Cohesion - инь и ян ООП.
Исходя их этого и следует оценивать правильность и корректность твоей диаграммы. Не очень понятно почему установка разрешений осуществляет форма авторизации. Ее основная обязанность предоставить возможность ввести данные и передать их тому классу, который способен выполнить цель пользователя
-
Не очень понятно почему установка разрешений осуществляет форма авторизации. Ее основная обязанность предоставить возможность ввести данные и передать их тому классу, который способен выполнить цель пользователя
так у меня же так и сделано вроде.. Форма считывает данные, передает контроллеру, контроллер проверяет правильность введенных данных, наделяет пользователя соответствующим ему уровнем доступа и дает разрешение для входа на сайт.. или убрать grandpermission ? получается, что это метод формы что ли ?
-
grandpermission ? получается, что это метод формы что ли ?
ессесно, именно это ты и говоришь разработчику - сделай метод grandpermission у формы. И куда ты его прикрутишь у формы?
-
На диаграмме состояний элемент "Нажата кнопка Submit" смущает. Я бы описал алгоритм этого перехода на диаграмме активности. Этот элемент, если его рисовать, назвал бы "проверка данных авторизации" то есть на более высоком уровне, чтобы исключить детали интерфейса из диаграммы состояний.
http://vv.sytes.net/files/rec/share/lib/uml/uml_sound_rec.pdf
На странице 18 изображены переходы по менюшке.
У меня пару вопросов к знатокам.
Framework(джумла например) это внешняя система, которую мы помечаем актёром на ДВИ?
Показываем ли мы framework как компонент на диаграмме компонентов?
И как показать его на диаграмме развёртывания?
То есть суть вопроса в том как указать на диаграммах присутствие framework в системе?
-
кароче я защитился на 5 =) всем спасибо, особенно Эдуарду.
Правда оно того не стоило)) потомучто глядя на то, что было у остальных, я понял, что вообще зря загонялся :D
но все равно спасибо за помощь) да и для себя много нового узнал, это главное =)
-
кароче я защитился на 5 =) всем спасибо, особенно Эдуарду.
Правда оно того не стоило)) потомучто глядя на то, что было у остальных, я понял, что вообще зря загонялся :D
но все равно спасибо за помощь) да и для себя много нового узнал, это главное =)
Поздравляю, а то что узнал больше - это правильно и лучше, узнавать надо еще больше
-
Эй, а как же
А как сдадите и появится свободное время хотелось бы от вас услышать оценку фреймворка джумла. Что он позволяет сделать, чего не позволяет, и чем лучше других. Просто я сам про него не слышал.
Правда оно того не стоило)) потому что глядя на то, что было у остальных, я понял, что вообще зря загонялся :D
Мой небольшой жизненный опыт подсказывает, что загоняться стоит. Полученных навыков в универе всегда не хватает для решения реальных интересных задач.