Форум Сообщества Аналитиков

Общий раздел => Примеры => Задачи студентов => Тема начата: rave от 14 Мая 2011, 17:18:16

Название: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 14 Мая 2011, 17:18:16
Здрасьте.

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

Для начала UML проектирования попытался составить требования к системе, на основе которых нарисовал подобие Business Domain Model (кстати как это по-русски? Диаграмма бизнес-объектов?):

Акторы будут следующие:

Не откажусь от советов и рекомендаций по поводу того, что делать дальше.. Написать ВИ системы? Нарисовать ДВИ? Что еще? Заранее спасибо.

Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 14 Мая 2011, 17:34:48
Еще раз повторюсь, что это не интернет-магазин, оплатить онлайн возможности нет.
Кстати седня еще туда ввпихнул систему управления проектами (типа так удобнее будет бухгалтеру и зав складом смотреть чо когда сделать надо, и не только). Так что ее в UML тоже как-то обыграть надо я думаю..
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 21 Мая 2011, 22:07:55
Прошу прощения, что создал тему, и не отписывался в ней больше. Просто было слегка не до этого, т.к. занимался здоровьишком.

Итак, я набросал примерные сценарии ВИ системы, хотелось бы услышать комментарии по поводу моих изысканий, спасибо.

Варианты использования

ВИ 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. Авторизация
Сценарий:
•   Менеджер по продажам с определенной периодичностью формирует прайс-листы светильников по категориям в сторонних программных продуктах
•   Загружает сформированные прайс-листы на сайт
Альтернативный сценарий:
Менеджер дает задание администратору сайта для загрузки тех или иных прайс-листов
Постусловия: Сформированные и загруженные прайс-листы


Выстроил я правда слегка в сумбурном порядке их все, но я это исправлю, на это не смотрите..
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 22 Мая 2011, 00:05:24
Вообще шаги принято нумеровать
Цитировать
ВИ 01. Авторизация
•   Система проверяет введенные данные, после чего открывает доступ к сайту
Здесь нужно просто - система открывает доступ к сайту (или страницам сайта)

Цитировать
ВИ 02. Оформление заказа
Предусловия: ВИ 01. Авторизация
Вариант использования не может быть предусловием, так как вариант использования может завершиться двумя разными результатами: успешным и неуспешным. Какое из этих условий будет верным?
Там же - нет действий системы, нет реакции системы, описаны только действия Клиента.
Все остальные ВИ страдают ровно тем же

Исправляем ошибки - потом вернемся
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 22 Мая 2011, 02:36:07
Не ну вообще я тут не на 100% развернутые описания каждого прецедента делал.. Любым откликом системы в кждом ВИ будет очевидное: "система отображает форму или окно", поэтому я их просто опустил..
К примеру:

Не, ну если это так критично, то могу добавить...
Я просто на данный момент страдаю над выделением концептуальных классов.. Потомучто я запутался слегка. Выделил пока для себя:
Не знаю, выделять ли "проект", "этап" и "задание" из системы управления проектами в отдельные классы, ведь в моем случае проект = клиент, а этап = заказ. Короче запутался я чето совсем :(
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 22 Мая 2011, 09:23:11
Цитировать
Не ну вообще я тут не на 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) вас

Кому интересно это известно, что система отображает форму или окно? Всякие нажатия кнопок и т.п. есть неправильное понимание ВИ, об этом говорено, переговорено. Смотрите страницы форума.

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

Думаем. Голова, не чтобы фуражку носить
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 22 Мая 2011, 15:05:14
Не понятно почему проект - некая деятельность над созданием продукта = клиент - суть живое существо или организация
Не понятно почему  этап - шаг некоторого процесса = заказ - вид операции, характеризующийся в том, что некто или нечто оставляет заявку или запрос на получение чего-то.

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

За ссылку спасибо, щас буду переделывать.
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 22 Мая 2011, 16:15:37
Вот, переделал и доделал пока что "системные" ВИ:

ВИ Управление аккаунтами
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.   Система выводит сообщение о том, что профиль пользователя сохранен
Альтернативные потоки:
Нет
Постусловия:
Нет
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 22 Мая 2011, 19:32:04
Почти идеально.

Я объясню: в системе управления проектами я организовал все таким образом, что каждый клиент будет отождествляться с проектом, а каждый заказ данного клиента будет прирваниваться к этапу проекта, дабы избежать путанницы. А уже потом задания выдаются по каждому заказу (этапу) соответственно. Я думаю могут быть случаи, когда будут исключения, например, создание какого-то стороннего проекта, например по доработке сайта, но на данном этапе все происходит именно так как я описал.
И почему же все-таки - проект=клиент и этап =заказ.
Я могу предположить, что любые действия с клиентом- есть некий проект. Проект состоит из каких-то этапов. каждый этап состоит видимо из заданий. этап порождается каким-то заказом?
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 22 Мая 2011, 23:35:15
И почему же все-таки - проект=клиент и этап =заказ.
Я могу предположить, что любые действия с клиентом- есть некий проект. Проект состоит из каких-то этапов. каждый этап состоит видимо из заданий. этап порождается каким-то заказом?
Да, именно. я так сделал чисто из-за того, чтобы "подогнать" систему управления проектами под решаемую мной задачу.
Тоесть пользователь, который заходит в систему, может легко понять с каким заказом и с каким клиентом связана данная ему задача.
Просто в систему управления проектами получается есть 3 уровня: самый обширный - это проект, в проекте может быть несколько этапов, и на каждом этапе может выдаваться несколько заданий
Так же и с клиентом: есть клиент, который делает заказы, а по каждому заказу выдаются определенные задания. Ну вот я и отождествил клиентов с проектами, а заказы с этапами, хотя, еще раз повторюсь, это не значит, что нельзя, например, создать проект "Инвентаризация складов", а в нем сделать этапы "Инвентаризация склада №1", "Инвентаризация склада №2".

Вобщем я думаю завтра доделаю ВИ, а потом хотелось бы разобраться все-таки с концептуальными классами :(

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


Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 23 Мая 2011, 00:05:36
А если после завершения ЭТОГО проекта, спустя цать лет (или скорее) тот же самый клиент захочет сделать с вами еще проект?
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 23 Мая 2011, 08:10:50
Да он со мной никакого проекта не делает, у него просто со мной договор заключен, и он переодически закупает у меня светильники. какой он может со мной проект захотеть сделать ?
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 23 Мая 2011, 16:53:43
Вот набросал какоето ужасное подобие концептуальной диаграммы классов...

Посоветуйте нормальный UML редактор кроме рэшнл роуз, а то этот visual uml вообще раковый, одно мученье с ним..

Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 23 Мая 2011, 16:56:03
ой там еще этап с проектом соединен агрегацией
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 23 Мая 2011, 22:32:36
короче доделал я варианты использования наконец-то :(
прикрепляю док файл, а то там много букав

хотелось бы получить комментарии относительно диаграммы концептуальных классов, спасибо.

Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 23 Мая 2011, 23:03:00
Вот набросал какоето ужасное подобие концептуальной диаграммы классов...
Посоветуйте нормальный UML редактор кроме рэшнл роуз, а то этот visual uml вообще раковый, одно мученье с ним..
MagicDraw, Modelio, EA, VISIO, StarUML, да и VP отличный инструмент.

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

бухгалтер- счет - счет на что формируется - на сферического коня в вакууме?
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 23 Мая 2011, 23:44:36
MagicDraw, Modelio, EA, VISIO, StarUML, да и VP отличный инструмент.
Скачал уже EA, небо и земля по сравнению с тем чем я пользовался.

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

Цитировать
клиент и прайс-лист - вам непременно нужно контролировать сколько каких прайс-листов скачал какой клиент? или важно контролировать количество закачек в принципе?
мне вообще не нужно ничо из этого контролировать.. Я просто хотел показать как связаны объекты, видимо это неверный подход?
Цитировать
менеджер и прайс-лист - зачем? чтобы понять сколько менеджер науправлял? или распределить между менеджерами прайс-листы для управления?
то же самое..
Цитировать
Заказ - статус заказа - почему такая честь статусу заказа? и почему статус заказа - это материалы
Такая честь статусу заказа потомучто это целый раздел на сайте, в котором пользователь может посмотреть таблицу со своими заказами и статусами соответственно.. А материал это потомучто все, что располагается на сайте в виде какихто текстовых посылов - материалы. то же и с прайс-листами (ну они правда не в текстовом виде, а в виде файлов для скачивания)
Цитировать
Почему нужно знать сколькими материалами управляет администратор? и почему менеджер управляя прайс листами лишен возможности управлять материалами?
не знаю, почему нужно знать.. Видимо я чего-то не допонимаю просто.. убрать кратности чтоли? или вообще убрать связь?
Менеджер у меня только прайс-листами управялет, для остального - админ сайта.
Цитировать
бухгалтер- счет - счет на что формируется - на сферического коня в вакууме?
:)
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 24 Мая 2011, 16:57:52
Еще вопрос:

В теме примера про ИС Аттестации студентов я нашел вот такой документ
Вопрос: таблицы "Заинтересованные лица", "проблем", "цели", буквы R, P, G (я так понял это requirement, problem, goal)  <== это что за методология?
http://www.uml2.ru/forum/index.php?action=dlattach;topic=1106.0;attach=1179
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 24 Мая 2011, 17:24:17
R - role, в остальном угадали. Это методология UP и просто здравого смысла:)

По поводу связей с администраторами менежерами и т.п. - вы правильно поняли тонкий намек :)

Все эти аспекты вы выражаете через ВИ например или другое взаимодействие. ДК отражает статическую, и существенную для понимания структуру
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 24 Мая 2011, 17:54:42
то есть номер потребности R1 = Role 1, а не Requirement 1 ? не логично как-то..

UP = unified process ?

нед диаграммой седня подумаю еще
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 24 Мая 2011, 18:04:10
Не пойму где вы нашли в документе R1.
Все просто заинтересованное лицо, имеющаяся проблема (потребность), цель в ее решении
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 24 Мая 2011, 20:48:01
Цитировать
Не пойму где вы нашли в документе R1.
Все просто заинтересованное лицо, имеющаяся проблема (потребность), цель в ее решении
Заинтересованные лица там как раз не пронумерованы
Вот где я нашел R1:
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 25 Мая 2011, 01:27:25
Ну вот, переделал в ЕА, подубрал что Вам не понравилось..
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 25 Мая 2011, 20:08:10
Вот, сделал ДВИ, помоему выглядит эпично хахаха

Тока думаю надо еще добавить ВИ Мониторинг статуса, а то пользователь не понятно как видит статус..
И еще наверное надо ВИ отправка товара.. но это вроде как выходит за рамки системы, или как?

Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 25 Мая 2011, 23:19:11
Я не большой поклонник ICONIX, хотя в целом нормальный процесс, и зачем им это предшедствование и затрагивание, ну есть же в UML уже инклюды с экстендами.
И Вам не советую, "будь проще, к тебе потянутся ..."
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 26 Мая 2011, 00:41:20
Цитировать
Я не большой поклонник 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.

Так что я как раз выбрал менее загонный путь лично для себя =)
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 26 Мая 2011, 02:43:37
о я нашел нужные стрелочки =)
ну они мне все равно не нравятся
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 26 Мая 2011, 07:49:55
А про инклюды\не инклюды вот как получается:
В ЕА я не нашел инклюдов и экстендов, там были просиды и инвоуки
Так как я ни в том ни в том особо не разбираюсь, я почитал описание того и другого, дабы определить для себя: искать новый программный продукт, где есть инклюды и экстенды, либо разобраться в том в чем есть.
о я нашел нужные стрелочки =)
ну они мне все равно не нравятся
Я долго смеялся
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 26 Мая 2011, 11:10:08
Заинтересованные лица там как раз не пронумерованы
Вот где я нашел R1:

уел:) ну значит r - требования потребности (request или requirement)
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 26 Мая 2011, 11:13:51
Вот, сделал ДВИ, помоему выглядит эпично хахаха
Цель ДВИ - дать контекст и общий обзор.
Задача контекста  показать:
- кто будет пользоваться системой - т.е. кто или что вне границы системы
- показать саму границу системы - boundary
- показать цели использования системы внешними сущностями - то есть именнованные в терминах цели пользователя обязанности (отвественности) системы = варианты использования
- возможно как-то структурировать это в целях улучшения отображения
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 28 Мая 2011, 00:22:30
Цитировать
Я долго смеялся
Я старался чо.

Цитировать
- показать саму границу системы - boundary
- показать цели использования системы внешними сущностями - то есть именнованные в терминах цели пользователя обязанности (отвественности) системы = варианты использования

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

Вопрос: можно ли на ДВИ отобразить прецедент, которого нет в сценариях ВИ, и он происходит не при помощи системы, но влияет на другие прецеденты (я говорю конкретно про отгрузку товара). Например, он влияет на формирование статуса и зависим от мониторинга ИСУП..
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 28 Мая 2011, 20:36:49
Вопрос: можно ли на ДВИ отобразить прецедент, которого нет в сценариях ВИ, и он происходит не при помощи системы, но влияет на другие прецеденты (я говорю конкретно про отгрузку товара). Например, он влияет на формирование статуса и зависим от мониторинга ИСУП..
НЕт, вариант использование рассматриваемой системы. Если хочешь показать другие прецеденты, расширяй контекст.
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 28 Мая 2011, 22:20:45
Цитировать
НЕт, вариант использование рассматриваемой системы
ну а если например нарисовать границу системы и прецедент вынести за эту границу? =) нельзя так сделать ?

Цитировать
Если хочешь показать другие прецеденты, расширяй контекст.
Это как сделать ? :(

Еще вопрос. Про диаграмму развертывания. Вот например у меня есть физческий сервер и я на него устанавливаю веб-сервер, сервер базы данных, php.. Узлом будет являться только физический сервер, а все остальное - компонентами узла, или как?
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 28 Мая 2011, 22:59:33
ну а если например нарисовать границу системы и прецедент вынести за эту границу? =) нельзя так сделать ?
Потом нарисовать еще одну границу дать ей название, по смыслу включающее и новый прецедент и уже имеющейся баундэри и часть акторов. Можно, только мы получим уже совсем другую историю. 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 много полезного, хотя и по-английски, но делал наш бывший гражданин (хотя может и не бывший)
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 29 Мая 2011, 00:38:06
Цитировать
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
Спасибо за ссылки =) хорошо все написано.
Как я понял компоненты уже давно входят в узлы окружения и, соответственно, не отображаются на схемах.
Единственная трудность для меня теперь - это как придумывать названия "артефактам"..
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 29 Мая 2011, 15:51:56
Передел ДВИ и сделал диаграмму развертывания. Посмотрите, пожалуйста

Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 29 Мая 2011, 16:00:11
С диаграммой концептуальных классов никак не разберусь.. Поудалял связи какие Вам не понравились, и теперь чето ничо ни с чем не связано..

Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 29 Мая 2011, 22:14:25
Вот сделал диаграмму последовательности для ВИ "создание проекта", но чето мне не нравится, что активация там в некоторых местах прирывется, и что обратные стрелочки не пунктиром нарисованы.. Да и вообще, укажите мои ошибки, пожалуйста.

Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 29 Мая 2011, 22:54:08
С диаграммой концептуальных классов никак не разберусь.. Поудалял связи какие Вам не понравились, и теперь чето ничо ни с чем не связано..
Не, я просто задал вопросы. Я не советовал их удалять, нужно внимательно подумать, нужна ли тут связь, стоит ли  ее хранить
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 30 Мая 2011, 02:57:10
Цитировать
обратные стрелочки не пунктиром нарисованы..

Ну нельзя было сказать: "Поставь галочку "Is Return""?.. Я полчаса искал как этот возврат сделать..

Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 30 Мая 2011, 10:17:16
Передел ДВИ и сделал диаграмму развертывания. Посмотрите, пожалуйста
А тебе самому твоя ДВИ нравится?
1. зачем нужна картинка? для того чтобы лучше быстрее и проще понять то, что написано словами. А у тебя что? лес ассоциаций, куча овальчиков
2. распределение ВИ  и ролей - по-моему не продуманное. Например, администратор - то он управляет аккаунтами пользователей, то уже выставляет какие-то счета - смешение ролей явное
3. на одной диаграмме представлены ВИ разного уровня нужности. одни относяся к бизнес-контексту, другие просто к организации работы системы, я бы разделил их на две диаграммы
4. Название ВИ не всегда понятны. А инклюды с эксендами лишние. Каков в них смылс неясно. Выставление счета расширяет Мониторинг ИСУП (а где точка расширения, где условие)

и т.д.
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 30 Мая 2011, 11:17:28
Ну нельзя было сказать: "Поставь галочку "Is Return""?.. Я полчаса искал как этот возврат сделать..
Знание добытое самостоятельно наиболее ценно!

Что сказать по поводу ДП.
Каковое назначение, что ты хотел ею сказать и кому?
Варианты ответа:
научному руковдителю - смотри мол я умею рисовать ДП
будущей комиссии - смотрите мол я ведь знаю что такое UML  и даже знаю что такое ДП
самому себе - понять как будет реализован ВИ, какие классы нужно добавить, как правильно распределеить обязанности между классами

Далее поскольку ты выбрал типичный принцип разделение интерфейса и модели, то выбор в качестве управляющего класса Систему, выглядет несколько странно. Я думаю что в данном случае как минимум это должен быть контроллер варианта использования
Далее каким образом происходит сохранение объекта Проект? Куда он сохраняется? Из реализации ВИ не ясно
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 30 Мая 2011, 13:32:56
Цитировать
А тебе самому твоя ДВИ нравится?
да так себе.

Цитировать
2. распределение ВИ  и ролей - по-моему не продуманное. Например, администратор - то он управляет аккаунтами пользователей, то уже выставляет какие-то счета - смешение ролей явное
в "выставление счета" у меня входит собственно составление счета бухгалтером + публикация ссылки на этот счет на сайте, что делает как раз администратор.

Цитировать
4. Название ВИ не всегда понятны. А инклюды с эксендами лишние. Каков в них смылс неясно. Выставление счета расширяет Мониторинг ИСУП (а где точка расширения, где условие)
Условие простое: " В ходе мониторинга заданий в СУП обнаружено задание на публикацию счета".. Где это прописывать надо? в пометке к прецеденту?


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

Цитировать
Знание добытое самостоятельно наиболее ценно!
=)

Цитировать
Что сказать по поводу ДП.
Каковое назначение, что ты хотел ею сказать и кому?
Варианты ответа:
научному руковдителю - смотри мол я умею рисовать ДП
будущей комиссии - смотрите мол я ведь знаю что такое UML  и даже знаю что такое ДП
самому себе - понять как будет реализован ВИ, какие классы нужно добавить, как правильно распределеить обязанности между классами

Все 3 варианта.. А научный руководитель к сожалению сам не умеет рисовать ДП 8(

Цитировать
Далее каким образом происходит сохранение объекта Проект? Куда он сохраняется? Из реализации ВИ не ясно
Сохранение объекта проект происходит в базу данных mysql очевидно, в таблицу "проекты".

Цитировать
Далее поскольку ты выбрал типичный принцип разделение интерфейса и модели, то выбор в качестве управляющего класса Систему, выглядет несколько странно. Я думаю что в данном случае как минимум это должен быть контроллер варианта использования
Вся проблема в том, что я занимаюсь так называемым "обратным проектированием", тоесть систему я уже сделал, а теперь пытаюсь ее описать, мне бы, например, было бы легче наоборот (тоесть спроектировать, и не делать ничего), но я не ищу легких путей видимо.
Так вот, я не очень знаю какой класс выбрать для "контроллера", поэтому я назвал его абстрактно "System", тоесть система управления контентом \ движок сайта, называйте как хотите, при помощи него выполняются все движения по сайту, sql запросы, записи в БД и т.д. на мой взгляд..
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: RuZzz от 30 Мая 2011, 18:23:55
А вы описание предметной области будете делать, или ограничитесь вариантами использования?
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 30 Мая 2011, 21:07:54
Описание предметной области у меня уже со всех сторон сделано =) я типа внедряю фирме, занимающейся розничной торговлей ИС для проведения оптовой торговли и повышения эффективности управления и работы с информацией сотрудников внутри организации, вместе с формированием клиентской базы и т.д.
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 30 Мая 2011, 21:15:25
Если вы конкретно про нотацию uml, то такого в задании вроде нет, но я подумаю над этим.. спасибо
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: RuZzz от 30 Мая 2011, 23:34:39
Мне было бы интересно увидеть раскритикованную бизнес-модель предметной области. Сам не до конца разобрался, хотелось бы извлечь для себя некий шаблон, где есть: бизнес диаграмма вариантов использования, диаграмма бизнес объектов. И хочется понять в каких случаях строят другие диаграммы для бизнес модели.
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 31 Мая 2011, 01:13:16
Цитировать
Мне было бы интересно увидеть раскритикованную бизнес-модель предметной области. Сам не до конца разобрался, хотелось бы извлечь для себя некий шаблон, где есть: бизнес диаграмма вариантов использования, диаграмма бизнес объектов. И хочется понять в каких случаях строят другие диаграммы для бизнес модели.
уберите отовсюду слово "бизнес" для начала =)
И диаграмма бизнес-объектов - это по идее и есть модель предметной области, да и вообще формулировку "диаграмма бизнес-объектов" я только на этом сайте и встречал..

Кстати говоря, переделал модель предметной области, покритикуйте меня, пожалуйста, товарищ Galogen =)


Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 31 Мая 2011, 08:42:23
Кстати говоря, переделал модель предметной области, покритикуйте меня, пожалуйста, товарищ Galogen =)
Критиковать, это мы завсегда. Ну держись.

1. Зачем сущность сайт на диаграмме? Какую смысловую нагрузка она несет, чем характеризуется? Как ты собираешься в конкретной предметке различать РАЗНЫЕ сайты
2. Какой смысл указывать что на сайте размещена система управления проектами? А какую систему вообще моделирует данная предметная область?
3. Среди группы пользователей ясно выделяются: администратор - человек управляющий и настраивающий системы - никакого отношения к реальной бизнес-системе управления проектами не имеющего; сотрудник некой компании которые работаю по проектам (менеджер, бухгалтер, завскладом), клиент - тот кто размещает заказ
4. Сотрудники - исполнители проекта. У любого проекта есть отвественный или руковдитель. Проект состоит из этапов, этапы из заданий. В задании (этапе или проекте) имеется автор - который предлагает его к производству, менеджер, который определяет кто конкретно будет исполнять задание, исполнитель - который будет его исполнять, возможно проверяющий который принимает работу. Т.е. Менеджер, бухгалтер или завскладом для системы - просто участник проекта или сотрудник. Поскольку в задании нужно как миними указать менеджера, бухгалтера, завскладом (чтобы это не значило), то это можно передать ролью!!! которую играет человек в конкретном проекте
5. ассоциации ни в коем случае не должны сливаться как показано у тебя. Это грубейшая ошибка. Сливание ветвей допустимо только в обобщении иногда в агрегации и композиции.
6. Счет, если что, не является  юридическим документом. В данном случае вообще не очень понятно выделение счета как сущности, достаточно было бы использовать Заказ
7. Проект как я понял связан с заказом, из модели этого не видно
8. Зачем нужно указывать Админа в заданиях и связи с контентом? Если для контента важно кто его создавал - допускаю эту мысль, то я все равно настаиваю. тут нужно рассматривать две модели: модель системы управления проектами и модель сайта - но это уже скорее будет модель артефактов
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: RuZzz от 31 Мая 2011, 09:24:04
И диаграмма бизнес-объектов - это по идее и есть модель предметной области, да и вообще формулировку "диаграмма бизнес-объектов" я только на этом сайте и встречал..
Вот поэтому я и спрашиваю здесь с чем её едят, так как больше нигде не найти(на русских порталах). Например, не ясно нужно ли строить отдельно БДВИ предметной области и БДВИ системы или они по хорошему будут выглядеть одинаково и представлять из себя одну диаграмму?
FAQ на этом сайте трактует одназначно:
На Бизнес Диаграмме ВИ (БДВИ) отображается, как взаимодействуют внешние пользователи с вашей организацией для достижения бизнес целей.

Но у меня закрались сомнения разве не нужно делать БДВИ для самой системы, а не для предметной области? Просто где-то видел это в инете.
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 31 Мая 2011, 13:59:29
Цитировать
1. Зачем сущность сайт на диаграмме? Какую смысловую нагрузка она несет, чем характеризуется? Как ты собираешься в конкретной предметке различать РАЗНЫЕ сайты
ну не знаю, помоему она добовляет наглядность модели.. Плюс только пользователи имеют доступ к сайту, что тоже немаловажно, т.к. сайт закрытый.

Цитировать
2. Какой смысл указывать что на сайте размещена система управления проектами? А какую систему вообще моделирует данная предметная область?
Информационную систему предприятия которую я создаю, включающую интранет и экстранет часть (ИСУП и сам сайт соответственно)

Цитировать
В задании (этапе или проекте) имеется автор - который предлагает его к производству, менеджер, который определяет кто конкретно будет исполнять задание, исполнитель
Менеджер у меня и есть автор..

Цитировать
Поскольку в задании нужно как миними указать менеджера, бухгалтера, завскладом (чтобы это не значило), то это можно передать ролью!!! которую играет человек в конкретном проекте
Я вот это не очень понял.. А где эти роли описываются? в вариантах использования?
Вроде как модель предметной области это "графический словарь", в котором графически отображено как термины предметной области связаны между собой..

Я думаю может просто объеденить админа, бухгалтера и завскладом в 1 какую-то группу, типа "персонал", и показать, что персонал получает задания, а менеджер выдает..

Цитировать
5. ассоциации ни в коем случае не должны сливаться как показано у тебя. Это грубейшая ошибка. Сливание ветвей допустимо только в обобщении иногда в агрегации и композиции.
ок, исправлю, думал просто покомпактнее сделать, не знал что нельзя 8(
Цитировать
7. Проект как я понял связан с заказом, из модели этого не видно
Вот это да, надо бы как-то связать, забыл реально..

Цитировать
8. Зачем нужно указывать Админа в заданиях и связи с контентом? Если для контента важно кто его создавал
Для контента не важно, а для меня и для понимания системы - важно. Это неправильно?

Цитировать
6. Счет, если что, не является  юридическим документом. В данном случае вообще не очень понятно выделение счета как сущности, достаточно было бы использовать Заказ
Думаю надо просто показать, что счет тоже является контентом

Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 31 Мая 2011, 14:33:30
хотя, блин, менеджер тоже к персоналу относится.. не знаю блин.. может, производственный персонал?)
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 31 Мая 2011, 14:38:53
ну не знаю, помоему она добовляет наглядность модели.. Плюс только пользователи имеют доступ к сайту, что тоже немаловажно, т.к. сайт закрытый.
Я думаю, что для этого существуют другие диаграммы, но никак ни диаграмма классов.

Цитировать
Информационную систему предприятия которую я создаю, включающую интранет и экстранет часть (ИСУП и сам сайт соответственно)
см. выше
Цитировать
Менеджер у меня и есть автор..
Автор - то  кто предлагает работу, источник работы.
Менеджер - тот кто определяет исполнителя
Менеджер может быть автором, а может и не быть.
Автором проекта вялестя Клиент например
Цитировать
Я вот это не очень понял.. А где эти роли описываются? в вариантах использования?
Могут и на ДВИ и могут на ДК
Цитировать
Вроде как модель предметной области это "графический словарь", в котором графически отображено как термины предметной области связаны между собой..
и каковы же термины вашей предметной области?
Цитировать
Я думаю может просто объеденить админа, бухгалтера и завскладом в 1 какую-то группу, типа "персонал", и показать, что персонал получает задания, а менеджер выдает..
может быть, только персонал - это группа, а админ - это не персонал, а часть персонала, представитель персонала. Понятна аналогия?

Цитировать
Для контента не важно, а для меня и для понимания системы - важно. Это неправильно?
Для себя вовсе не обязательно выкладывать на обозрение и происть помощи. Для меня не понятно. Это другая модель.
Бухгалтер контентом не мыслит знаете ли :)


[/quote]
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 31 Мая 2011, 16:49:04
Короче я запутался вконец.. Вот сделал еще вариант, не знаю уже..

Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 31 Мая 2011, 17:18:05
Короче я запутался вконец.. Вот сделал еще вариант, не знаю уже..
Для домейна нормально. Только добейся, чтобы не было пересечения связей
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 31 Мая 2011, 17:58:38
Цитировать
Для домейна нормально. Только добейся, чтобы не было пересечения связей
еее спасибо.
Ну вот, только 1 пересечение, не знаю как от него избавиться..

Еще вопрос: Вы случайно не знаете как такую стрелочку в ЕА сделать, как во вложении №2 ?
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 31 Мая 2011, 18:33:56
Еще вопрос: по хорошему модель предметной области строится же до вариантов использования, да?
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 31 Мая 2011, 18:38:52
Еще вопрос: Вы случайно не знаете как такую стрелочку в ЕА сделать, как во вложении №2 ?
Это direction. Кликаешь по имени ассоциации правой кнопкой мыши, где-то там найдешь direction

Еще вопрос: по хорошему модель предметной области строится же до вариантов использования, да?
параллельно я бы сказал. итерационно
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: RuZzz от 31 Мая 2011, 19:04:28
А система управления проектами может входить в модель предметной области? Если мы её допустим только разрабатываем. Я бы нарисовал без неё.
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 31 Мая 2011, 19:11:12
А система управления проектами может входит в модель предметной области? Если мы её допустим только разрабатываем. Я бы нарисовал без неё.
И я о том же..
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 31 Мая 2011, 22:41:36
Цитировать
А система управления проектами может входить в модель предметной области? Если мы её допустим только разрабатываем. Я бы нарисовал без неё.

Ну блин, как я тогда покажу как счет, например, формируется, если он у меня вне системы вообще делается (бухгалтером в 1с или там в екселе).. А так я все составляющие вместе связал..
Я сначала так и хотел сделать, типа с устными поручениями, или там по телефону.. Но что это тогда за система.. Клиент-заказ-статус-админ, все.. Не интересно.
Я могу конечно нарисовать: Клиент аплоадит заказ, админ обновляет статус... =)

Цитировать
Это direction. Кликаешь по имени ассоциации правой кнопкой мыши, где-то там найдешь direction
Я это находил уже, это делает ассоциацю направленной (ну на конце стрелочка рисуется всмысле), а что бы рядом со словом - не могу найти.. 8(
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 31 Мая 2011, 22:58:46
А все, нашел, надо на самом лейбле ткнуть, спасибо.
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 01 Июня 2011, 00:00:46
Я вот думаю, надо ли в моем случае делать диаграмму классов, диаграммау коммуникации, диаграмму состояний.. Они ведь больше уже к программной реализации относятся.. Мне кажется это юслесс..
Диаграмму деятельности еще можно наверное сделать..
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 01 Июня 2011, 08:08:08
Вот, можно так сделать? =) все довольны будут тогда)
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: RuZzz от 06 Июня 2011, 01:04:15
А администратор не авторизуется? На самом деле я почитав этот форум стал выкидывать из своих диаграмм авторизацию. Так как у меня при входе на любой сайт нет цели регистрироваться и авторизоваться. Это даже напрягает. С редактированием профиля можно тоже поспорить. Хотя у меня на диаграмме этот ВИ присутствует.
Присутствует на моей диаграмме и пакет администрирование. Свою диаграмму я делал задолго до вас и пакет выглядят практически также. Только я туда добавил редактирование прав файлов. но возможно тоже выкину.
По-моему ВИ загрузка заказа должен быть на более абстрактном уровне. В книге Коберна можно почитать про уровни вариантов использования.

Но мне интереснее другое. Я как то пробовал разбивать элементы на пакеты. Получается так что ДВИ и диаграмма классов связаны одними и теми же пакетами. И когда доходим до этапа генерации кода из диаграмм, пакеты превращаются в названия папок, в которых создаются исходники. Может быть в EA тоже самое по смыслу получится? Тогда стоит называть пакеты таким образом, чтобы потом компилятор с названиями таких папок корректно работал. У меня названия пакетов это английские короткие названия. Конечно для вас это может быть не существенно, но мне хотелось бы разобраться.
Это в EA выглядит так диаграмма всех пакетов? или это только диаграмма пакетов для вариантов использования?
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 07 Июня 2011, 16:30:43
Я тут подразобрался, мне терь кажется, что таким образом как я вот выложил в предыдущем посте вообще нельзя с пакетами работать. Теперь у меня просто список пакетов, в каждый из которых помимо ВИ включены еще акторы, и каждый пакет я рассмотрел как отдельную ДВИ..

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

По-прежнему еще очень интересует вопрос:
Я вот думаю, надо ли в моем случае делать диаграмму классов, диаграммау коммуникации, диаграмму состояний.. Они ведь больше уже к программной реализации относятся.. Мне кажется это юслесс..
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 07 Июня 2011, 16:38:31
Еще услышал от препода такую тему, что "Прецеденты в диаграмме прецедентов должны идти по порядку их использования сверху вниз".. Я если честно не слышал о таком до этого.. Вроде как для этого другие диаграммы есть.. Или действительно необходимо размещать их в порядке возникновения? Просто там довольно много параллельных прецедентов например существует.. что скажете?
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 07 Июня 2011, 18:41:26
Еще услышал от препода такую тему, что "Прецеденты в диаграмме прецедентов должны идти по порядку их использования сверху вниз".. Я если честно не слышал о таком до этого.. Вроде как для этого другие диаграммы есть.. Или действительно необходимо размещать их в порядке возникновения? Просто там довольно много параллельных прецедентов например существует.. что скажете?
Первый раз слышу. Хотя сколько людей столько мнений. Включай свой рассудок.

Диаграмма классов нужна - все ООП на этом построено, а у тебя не будет. весь вопрос какие классы ты планируешь рассмотреть, только предметки и интерфейсные? Читай руп или иконикс, там все ответы
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 07 Июня 2011, 20:32:10
Цитировать
Диаграмма классов нужна - все ООП на этом построено, а у тебя не будет. весь вопрос какие классы ты планируешь рассмотреть, только предметки и интерфейсные? Читай руп или иконикс, там все ответы

Ну я ведь делал модель предметной области, это вроде как сродни диаграмме классов с концептуальной точки зрения. Или надо рассмотреть диаграмму классов с точки зрения спецификации\реализации ? Я тут теряюсь вообще.. Хотел без нее обойтись, у меня ведь уже есть реализация..

А какие книжки по руп\иконикс посоветуете? я юзаю "UML. Основы" Мартина Фаулера и "UML 2 и унифицированный процесс" Джим Арлоу\Айла Нейштадт..
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 07 Июня 2011, 20:34:44
Вот еще чо слепил.. =)

Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: RuZzz от 08 Июня 2011, 00:09:16
На сколько корректно соединять стрелочкой отправку и приём сигнала, я никогда так не делал? Я бы заменил двумя элементами Action
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 08 Июня 2011, 00:54:44
На сколько корректно соединять стрелочкой отправку и приём сигнала, я никогда так не делал? Я бы заменил двумя элементами Action
ты про "оплатить счет" --> "получить сведения об оплате" ? А чем еще соединять отправку и прием кроме стрелочки?)
Вот тут (http://www.sparxsystems.com/enterprise_architect_user_guide/8.0/modeling_languages/receive.html) в примере даже соединено так..

Ну вообще я ни в чем не уверен, т.к. 1ый раз такую диаграмму делал =)
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 08 Июня 2011, 08:22:19
Я бы заменил зависимостью. пунктирной стрелкой со стереотипом типа месадж
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: RuZzz от 08 Июня 2011, 09:37:22
Ну я ведь делал модель предметной области, это вроде как сродни диаграмме классов с концептуальной точки зрения. Или надо рассмотреть диаграмму классов с точки зрения спецификации\реализации ? Я тут теряюсь вообще..

Видел, что некоторые строят диаграмму классов предметной области. В ней не упоминаются классы самой системы. Сам не разобрался насколько она нужна, если есть диаграмма бизнес-объектов. Эдуард вероятно говорил о диаграмме классов для реализации системы. Скорее всего в вашем случае нужно смотреть на реализацию и по ней делать диаграмму классов.
Ваша система реализована на классах или процедурах?
Хотел без нее обойтись, у меня ведь уже есть реализация..
У вас хорошо получается, зачем останавливаться :) Ваш пример поможет не только нам лучше разобраться, но и многим другим. Тема очень актуальная. Кроме того, сделав полную модель системы, вы можете найти ошибки в реализации.
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 08 Июня 2011, 19:22:00
хз мозги плавятся, сделал пока вот так.. На типы данных тока не смотрите, я там их нигде не выставлял почти пока что.
Это очень упрощенно, я никогда в жизни не смогу сделать полную диаграмму классов всей джумлы со всеми модулями, это итак понятно.. Да это и никому не нужно я думаю..

Еще порой тяжело отличать объекты класса от классов-потомков.. Например вот с группами разобраться не могу. Каждая группа это класс, или это объект класса "группа"? :(
Просто у них иерархическая зависимость, и все значения передаются в зависимости от включения одной группы в другую..
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 08 Июня 2011, 19:58:58
Это очень упрощенно, я никогда в жизни не смогу сделать полную диаграмму классов всей джумлы со всеми модулями, это итак понятно.. Да это и никому не нужно я думаю..
А ты ее вообще не должен показывать - это не твои классы. Ты лишь можешь показать классы родители и то не очень подробно, так как реализация их скажем не в твоей компетенции. А вот дальше ты берешь и делаешь

На самом деле джумла фреймвёрк, ведь ты делаешь компонент, модуль или бот, согласно принятой технологии самого каркаса. Где-то можно указать шаблон такого каркаса, кооперацию там, а потом показать свое намясывание
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 08 Июня 2011, 20:47:24
Цитировать
А ты ее вообще не должен показывать - это не твои классы. Ты лишь можешь показать классы родители и то не очень подробно, так как реализация их скажем не в твоей компетенции
Ну я вроде как так и старался сделать примерно.. Похоже хоть немного на правду ?
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: RuZzz от 09 Июня 2011, 21:05:18
Я конечно не эксперт в ООП. Но если у класса потомка от класса родителя наследуются методы то зачем прописывать у потомков класса Module SetAccessLevel? Возможно это перезагрузка метода? В любом случае хотелось бы услышать ваши комментарии.

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

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

Кстати может сделать класс формы, как родителя класса меню? вместо наследования от класса модуль.

И если используете пакеты, то диаграмму пакетов тоже хотелось бы увидеть. Может вам лучше файл офисного пакета выкладывать. а то не хватает комментариев по диаграммам.
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 09 Июня 2011, 23:29:54
Ну я вроде как так и старался сделать примерно.. Похоже хоть немного на правду ?
Похоже. Но помни, не следует показывать все, показывай главное. Ведь каждый модуль можно рассмотреть отдельно. Joomla фреймвёрк MVC. Каждый функциональный блок в нем самостоятелен, покажи на одной диаграмме только функционально связанные классификаторы.

Да если смотреть на способ реализации все-таки там должен быть класс представления, класс управления и класс моделей, я не ошибаюсь?
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 10 Июня 2011, 13:24:54
Цитировать
Я конечно не эксперт в ООП. Но если у класса потомка от класса родителя наследуются методы то зачем прописывать у потомков класса Module SetAccessLevel? Возможно это перезагрузка метода? В любом случае хотелось бы услышать ваши комментарии.
перегрузка всмысле? ну да, наверное, я просто сам уже все ооп забыл.. ты в ЕА галочки появились заимствования, я и выбрал методы.. косяк кароче.
Цитировать
А диаграмму состояний не будете делать? просто можно на ней показать как мы по формам двигаемся.
не знаю.. мне уже сдавать через пару дней, а я нихрена не успеваю.. может и сделаю, если разберусь :(
Цитировать
Кстати может сделать класс формы, как родителя класса меню? вместо наследования от класса модуль.
не, в джумле меню - это именно модуль.. А вот класс формы можно бы сделать, только это слишком перегрузит диаграмму, потомучто там везде какие-то формы используются.. не знаю.. надо подумать, а времени нет..

Цитировать
Joomla фреймвёрк MVC. Каждый функциональный блок в нем самостоятелен, покажи на одной диаграмме только функционально связанные классификаторы.
да уж, жаль я раньше не знал о существовании этого шаблона.. теперь все стало понятнее.. жаль только поздновато
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 10 Июня 2011, 13:34:50
так это получается для каждого уровня надо свою диаграмму классов? или достаточно указания каждого из классов на 1 модели?
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 10 Июня 2011, 14:23:36
да уж =)
http://joomlacode.org/gf/project/joomla/scmsvn/?action=browse&path=/documentation/joomla.uml/
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 10 Июня 2011, 15:27:41
Диаграмма состояний для ви "загрузка заказа"
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: RuZzz от 10 Июня 2011, 20:32:26
перегрузка всмысле? ну да, наверное, я просто сам уже все ооп забыл.. ты в ЕА галочки появились заимствования, я и выбрал методы.. косяк кароче.не знаю..
ну если EA так показывает методы наследованные от родителя то не косяк. но надо быть готовым отстоять свою диаграмму перед комиссией. Если остальные диаграммы они возможно в глаза не видели, то диаграмма классов очень распространена.

мне уже сдавать через пару дней, а я нихрена не успеваю..
Я советую оставить как есть, займитесь оформлением. А потом если будет интересно разберемся до конца, наверняка вам поставят хорошую оценку если будет хорошо подано.


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

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

А как сдадите и появится свободное время хотелось бы от вас услышать оценку фреймворка джумла. Что он позволяет сделать, чего не позволяет, и чем лучше других. Просто я сам про него не слышал.
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 10 Июня 2011, 23:48:07
По ДС.

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

1. В целом неплохо
2. Вход - тут можно указать либо как событие, либо как действие на переходе (скорее последнее): открыта сессия, начался сеанс
3. Вести логин и пароль - это внутренняя деятельность в состоянии Форма авторизации. Триггер=событие = Нажата кнопка Submit [Логин + пароль = @Логин + @Пароль]
4. Из этог же состоянию будет переход в само состояние (хотя можно и не указывать) Нажата кнопка Submit [Логин <> @Логин |Пароль<> @Пароль]/showMessage('Нет пользователя с такими учетными данными')
5. все что у тебя в [] - сторожевое условие, или просто УСЛОВИЕ - выражение булевского типа, а не то что у тебя. ТО что у тебя либо триггер либо действие на переходе. Сторожевое условие необязателно, но если есть то говорит возможен ли переход из одного состояния в другое. С.У. обязательно если из состояния есть несколько переходов, в текущий момент времени возможен только один т.е XOR условие
6. Выход должен приводить не к форме авторизации, а к прекращению сеанса и конечному псевдосостоянию. Либо суперсостояние Сайт  нужно убить как лишнее и не нужное, только затрудняющее понимание
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 11 Июня 2011, 13:20:31
Цитировать
ну если EA так показывает методы наследованные от родителя то не косяк.
Да не, там как раз имелась ввиду наверное перегрузка метода, а я чето забыл про эту тему, хорошо что ты напомнил =)
Цитировать
Я советую оставить как есть, займитесь оформлением. А потом если будет интересно разберемся до конца, наверняка вам поставят хорошую оценку если будет хорошо подано.
спасибо =) я вообще просто сдать хоть на чето надеюсь
Цитировать
А как сдадите и появится свободное время хотелось бы от вас услышать оценку фреймворка джумла. Что он позволяет сделать, чего не позволяет, и чем лучше других.
Ок))

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

Цитировать
Цитата
По ДС.

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

1. В целом неплохо
2. Вход - тут можно указать либо как событие, либо как действие на переходе (скорее последнее): открыта сессия, начался сеанс
3. Вести логин и пароль - это внутренняя деятельность в состоянии Форма авторизации. Триггер=событие = Нажата кнопка Submit [Логин + пароль = @Логин + @Пароль]
4. Из этог же состоянию будет переход в само состояние (хотя можно и не указывать) Нажата кнопка Submit [Логин <> @Логин |Пароль<> @Пароль]/showMessage('Нет пользователя с такими учетными данными')
5. все что у тебя в [] - сторожевое условие, или просто УСЛОВИЕ - выражение булевского типа, а не то что у тебя. ТО что у тебя либо триггер либо действие на переходе. Сторожевое условие необязателно, но если есть то говорит возможен ли переход из одного состояния в другое. С.У. обязательно если из состояния есть несколько переходов, в текущий момент времени возможен только один т.е XOR условие
6. Выход должен приводить не к форме авторизации, а к прекращению сеанса и конечному псевдосостоянию. Либо суперсостояние Сайт  нужно убить как лишнее и не нужное, только затрудняющее понимание
Спасибо большое за пояснения. Поизучал еще немного теорию этой диаграммы, в итоге переделал вот во что. Мне все-таки не очень хочется убирать состояние "сайт", т.к. оно показывает, что пользователь гипотетически может совершать и другие действия после загрузки заказа на сайте. Не знаю, может я и не прав :(
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: RuZzz от 11 Июня 2011, 20:28:36
http://caveman.ru/yii.1.1.2r2135.png вот кстати диаграмма классов yii framework. Не встречали такое для джумлы?
Обратите внимание на название пакетов.
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 11 Июня 2011, 20:32:29
Rave,
ну зачем тебе сайт? Смешно как-то. По сути ты хочешь сказать, что войдя на сайта, посетитель получает сеанс и находится в этом сеансе пока не закроет браузер, не покинет сайт, не произойдет дисконнект.

После авторизации - ты пропускаешь посетителя в закрытую зону.

В любой момент времени может произойти обрыв сессии, по желанию или без посетителя.

Показав составное состояние, вовсе не нужно явно показывать переходы из всех состояний по событию выход. Если оно призойдет, тебя так и так выкинет из сеанса и тебе придется начинать новый следовательно пройдешь авторизацию
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 11 Июня 2011, 21:27:18
Цитировать
Показав составное состояние, вовсе не нужно явно показывать переходы из всех состояний по событию выход. Если оно призойдет, тебя так и так выкинет из сеанса и тебе придется начинать новый следовательно пройдешь авторизацию
ну под выходом имеется ввиду разлогинивание, это можно сделать со всех страниц сайта, но не со всех состояний. Ну типа как переход на домашнюю страницу.. Тоесть нельзя нажать, например, когда открыто диалоговое окно загрузки файла.. Я не знаю, убрать, не нужно это?

Цитировать
Цитата
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 картинку)
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 12 Июня 2011, 14:38:48
вопросы по диаграмме коммуникаций:
изображаются ли на ней return messages?
в ней участвуют объекты, которые я выделил в концептуальной модели? или программные классы? или в моем случае формы?
вообще есть какие-нибудь рекомендации по этой диаграмме? А то чето в инете очень скупо описано про нее..
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 12 Июня 2011, 18:43:27
И еще как показать на ней условие ?
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 12 Июня 2011, 20:22:50
И еще как показать на ней условие ?
на чем на диаграмме коммуникации? Я бы не стал этого делать. ДК - суть протокол
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 12 Июня 2011, 23:41:39
Так правильно?
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 13 Июня 2011, 15:32:24
Цель диаграмм последовательности и коммуникации состоит в проверке корректности разделения обязанностей между классами. Здесь следует действовать согласно принципам Low Coupling и High Cohesion - инь и ян ООП.

Исходя их этого и следует оценивать правильность и корректность твоей диаграммы. Не очень понятно почему установка разрешений осуществляет форма авторизации. Ее основная обязанность предоставить возможность ввести данные и передать их тому классу, который способен выполнить цель пользователя
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 13 Июня 2011, 17:42:44
Цитировать
Не очень понятно почему установка разрешений осуществляет форма авторизации. Ее основная обязанность предоставить возможность ввести данные и передать их тому классу, который способен выполнить цель пользователя
так у меня же так и сделано вроде.. Форма считывает данные, передает контроллеру, контроллер проверяет правильность введенных данных, наделяет пользователя соответствующим ему уровнем доступа и дает разрешение для входа на сайт.. или убрать grandpermission ? получается, что это метод формы что ли ?
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 14 Июня 2011, 09:25:44
grandpermission ? получается, что это метод формы что ли ?
ессесно, именно это ты и говоришь разработчику - сделай метод grandpermission у формы. И куда ты его прикрутишь у формы?
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: RuZzz от 15 Июня 2011, 13:04:44
На диаграмме состояний элемент "Нажата кнопка Submit" смущает. Я бы описал алгоритм этого перехода на диаграмме активности. Этот элемент, если его рисовать, назвал бы "проверка данных авторизации" то есть на более высоком уровне, чтобы исключить детали интерфейса из диаграммы состояний.

http://vv.sytes.net/files/rec/share/lib/uml/uml_sound_rec.pdf

На странице 18 изображены переходы по менюшке.

У меня пару вопросов к знатокам.
Framework(джумла например) это внешняя система, которую мы помечаем актёром на ДВИ?
Показываем ли мы framework как компонент на диаграмме компонентов?
И как показать его на диаграмме развёртывания?

То есть суть вопроса в том как указать на диаграммах присутствие framework в системе?
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: rave от 22 Июня 2011, 15:18:42
кароче я защитился на 5 =) всем спасибо, особенно Эдуарду.
Правда оно того не стоило)) потомучто глядя на то, что было у остальных, я понял, что вообще зря загонялся :D
но все равно спасибо за помощь) да и для себя много нового узнал, это главное =)
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: Galogen от 22 Июня 2011, 17:49:28
кароче я защитился на 5 =) всем спасибо, особенно Эдуарду.
Правда оно того не стоило)) потомучто глядя на то, что было у остальных, я понял, что вообще зря загонялся :D
но все равно спасибо за помощь) да и для себя много нового узнал, это главное =)
Поздравляю, а то что узнал больше - это правильно и лучше, узнавать надо еще больше
Название: Re: Дипломное проектирование закрытого портала для оптовых покупателей
Отправлено: RuZzz от 22 Июня 2011, 18:23:23
Эй, а как же
А как сдадите и появится свободное время хотелось бы от вас услышать оценку фреймворка джумла. Что он позволяет сделать, чего не позволяет, и чем лучше других. Просто я сам про него не слышал.
Правда оно того не стоило)) потому что глядя на то, что было у остальных, я понял, что вообще зря загонялся :D
Мой небольшой жизненный опыт подсказывает, что загоняться стоит. Полученных навыков в универе всегда не хватает для решения реальных интересных задач.