Здрасьте.

В общем необходимо спроектировать сабж. В общем-то я уже все сдеал практически, но надо еще описать все в рамках нотации 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 батенька, в FAQ вас

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

Я просто на данный момент страдаю над выделением концептуальных классов..

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

Думаем. Голова, не чтобы фуражку носить

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

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

За ссылку спасибо, щас буду переделывать.

Вот, переделал и доделал пока что "системные" ВИ:

ВИ Управление аккаунтами
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 вообще раковый, одно мученье с ним..

ой там еще этап с проектом соединен агрегацией

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

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