Скажите пожалуйста как ефективно можно освоить UML. Я програмирую уже почти полтора года, то есть я думаю что некоторое понятие ООП я уже имею. Как само програмирование очень нравиться, но заинтересувало проектирование систем. Я уже немного прочитал по UML, но когда пишеш программу на любом языке програмирования, тогда после компиляции и експлуатирования можеш попробувать работает или нет, а вот с моделированием дело обстоит иначе. 
Я уже знаком с системным анализом, и уже пробувал проектировать систему, но вопрос состоит в том что как знать что значит той или иной принцип в UML.

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

Самая лучшая, на мой взгляд, вводная книга по UML - "UML Основы" Мартина Фаулера. Дальше более углублённо можно изучать по "UML. Классика CS" Буча, Якобсона и Рамбо.

tarasD, давайте я вас обучу.

У меня два десятка коллег уже подверглись этой процедуре, UML сделали внутренним стандартом, мы его в официальных документах используем.

Давайте!

Ууух, тема в руку, буду следить с удовольствием.

И я с удовольствием присоединюсь к группе обучающихся.  

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

Шансы есть.
Но невысокие.   

Всем, кому интересно - я начну у себя в журнале (ссылка внизу) разбирать примеры по UML. Кому нужно - поучаствуйте.

проектирование дело творческое...одна система может быть представлена по-разному..

0000, без сомнения. Именно поэтому я буду объяснять каждый пример.

Я тут насчитала четырех участников, которые хотели поучиться. Еще один написал мне в личную почту.

В журнале разобрала два примера.
Чувствую, надо разворачивать дело 

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

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

На каждый пример я беру неделю. Потом обсуждение.

Кто согласен?

Это сообщение отредактировал(а) ida - 13.5.2008, 16:50

Ida какие могут быть возражения.  
Мне UML на данном этапе интересен относительно позиций тестера и аналитика.
Книгой Язык UML Руководство пользователя (Буч, Рамбо, Джекобсон) вооружился.   


Это сообщение отредактировал(а) alexpotemkin - 13.5.2008, 23:14

alexpotemkin, а давайте примерчик тогда.
Пока остальные спят...

Давайте я 
Я студент, обучаюсь на 4 курсе политехнического института. Специальность называется "Системный анализ и управление".
Я до сих пор не совсем понимаю, чем должен заниматься специалист моего профиля после окончания института. Но есть идея, что анализом и проектированием различных систем, для чего мне потребуется UML.
Пример... Пусть вот такой:
---
Автоматизация складского учёта и оборота товаров на торговых точках.

1. Существует несколько торговых точек на разных рынках. Каждая из них представляет собой отдельный небольшой склад товаров.
2. На каждую торговую точку приходят товары от нескольких поставщиков. Товары также могут передаваться со склада на склад (без наценки). Для таких операций ведётся отчётность - формируются приходные накладные.
3. Каждая торговая точка продаёт товар, в розницу - обычным покупателям, оптом - перепродавцам по сниженой цене. Для каждого перепродавца идёт своя наценка на товары, для обычных покупателей - одна общая наценка на товары. При продаже должна формироваться расходная накладная.
4. Нужно иметь возможность видеть текущее состояние на всех торговых точках: цены, количество и суммарную стоимость каждого товара и всех товаров вместе.
5. Нужно, чтобы формировался отчёт об обороте товаров за указанный период на торговой точке и на всех точках вместе.
6. Нужно, чтобы формировался отчёт об обороте товаров за указанный период по указанному поставщику или перепродавцу.
Информация о товарах берётся из накладных.
---
Не знаю, насколько подходящий этот пример... Мне кажется, что RUP в таких проектах применять не стоит. Разве что для обучения 

ту Esperito
Вот хороший пример реализации диаграмм, практически по заданной вами теме
http://www.interface.ru/fset.asp?Url=/misc/uml1.htm

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

sandello, а представьтесь и вы тоже.

Esperito, п.1-3 это описание предметной области, а п. 4-6 - функциональные требования.

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

Торговая точка
Товар
Покупатель
Поставщик
Рынок (?)
Склад (?)

Возможно, есть еще какие-то кандидаты, которые в описании не упомянуты.

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

Это сообщение отредактировал(а) ida - 18.5.2008, 12:05

Спасибо за ссылку!

ida: Спасибо за пояснения.
1. Торговая точка и склад - суть одно и то же, мне кажется нет смысла их разделять. Это как бы ммм... именованый набор товаров, которые где-то хранятся.
Рынок тоже не стоит выделять.
Я ещё забыл написать, что владелец торговых точек (предприятие либо частное лицо) несёт дополнительные издержки - например, аренда торговых точек, расходы на бензин и т.п.
Т.е список классов наверное примерно такой:

Склад
Товар
Издержка
Покупатель
Поставщик

2. Классы пользователей:

Владелец - будет с помощью программы формировать отчёты о: а) состоянии складов, б) обороте товаров по складам, в) обороте товаров по поставщикам, г) обороте товаров по оптовым покупателям-перекупщикам.
Реализатор торговой точки - будет с помощью (другой?) программы вводить данные о накладных и формировать по ним отчёты.

3. Данные о накладных должны передаваться (например, на дискете или флешке) от каждого реализатора владельцу. На их основе он будет формировать свои отчёты.

Эээ... что хотите узнать? Имя-фамилия?
Звать Денисом. Текущая должность - начальник отдела разработки ПО.

Это сообщение отредактировал(а) sandello - 19.5.2008, 09:07

Пожалуй не соглашусь с Esperito по поводу выноса издержек в отдельный класс. По моему мнению издержка это скорее "процедура" которая может как внести изменение в стоимость товара и возможно оставляющая после себя документальное отображение, т.е. как например накладная на закупленное топливо для перевозки товара, счет на оплату аренды помещений - вот как раз эти документы можно отнести к классам (общим, таким как накладная и счет).
Но в данном случае предлагаю отказаться от таких глубоких построений и для начала принять определенный уровень абстракции, т.е. рассматривая эту задачу как полноценную мы получаем основательный набор классов, например: торговая точка (склад), поставщик, покупатель, бухгалтерия, отдел снабжения, служба реализации (магазин), сотрудники склада, документы склада (инвентаризационная ведомомсть), кладовщик, сотрудники бухгалтерии, документы бухгалтерии (приходные накладные, расходные накладные, акты перемещения, акты списания), бухгалтер, продавец магазина, документы магазина (чек) и т.п. Задача на вид простая на самом деле требует основательного описания для полноценного моделирования.
Возможно я ошибаюсь, поэтому хотелось бы знать мнение ida по моему тексту .



Это сообщение отредактировал(а) alexpotemkin - 19.5.2008, 09:41

Тогда почему по-разному называются?
Либо нужно выбрать какое-то одно название и придерживаться его, чтобы не было путаницы, либо описать ситуации, при которых разница имеет значение. Может ли торговая точка не быть складом?.. Может ли склад не быть торговой точкой? Если такие варианты в данной предметной области возможны и для нас имеют значение, то их нужно разделить.
То же самое с рынком.

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


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


В какой форме?


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

Это сообщение отредактировал(а) ida - 22.5.2008, 21:46

ida за что вы так кодеров 

Торговая точка (склад)
Продавец
Покупатель
Поставщик
Бухгалтер
Кладовщик
Приходной документ
Расходной документ

ida такой состав классов будет достаточным или нет? Или тут тоже есть избыточность?

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

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

тогда вычеркиваем документы и ждем автора примера
моя согласна сэнсей (а разве есть выбор?)  

Это сообщение отредактировал(а) alexpotemkin - 19.5.2008, 22:22

Ида закуривает ганджубас, присаживается на камушек и ждет рассвета... на рассвете из щелей между камнями вылезают Авторы... и идут греться на солнышке

ida, а ты в своих диаграммах учитываешь особенности реализации с разными технологиями? Или можно анализировать проблему и разложить её на языко-технологио-независимые компоненты? Но с другой стороны, тогда и самому аналитику приходится копаться в девелопменте?

chipset, какие технологии?..... Мы еще не дошли до проектирования.

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

Это сообщение отредактировал(а) ida - 21.5.2008, 08:40

Я вообще это немножко оффтоплю. ida, просто не знал что есть модель анализа и модель архитектуры  Я тупо набрасываю на клочке бумаге классы, девайсы, и всякого рода неразборчивые значки. Agile рулит!

chipset, у вас специфика другая скорее всего.

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

Не знаю, понятно ли я объяснила...

Здравствуйте, ida и товарищи обучающиеся!
Меня зовут Иван, я веб-разработчик. Интересуюсь грамотным проектированием, и задачка подходящая имеется.
У вас еще открыт набор в группу?

altspam, проходите, проходите...
Пока Esperito курит (похоже, что-то крепкое... ), мы и вашу задачку послушаем.   

Извиняюсь, что так долго отсутствовал. Локальная сеть падала.


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


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


Владелец всех торговых точек. Владелец хочет видеть прибыль, получаемую от товаров, завезённых и проданных на каждой торговой точке, прибыль, получаемую от каждой торговой точки (с учётом прибыли от всех товаров и издержек) и всех точек вместе для того, чтобы определить: 1) нужно ли ему, владельцу, продолжать закупать определённые наименования товаров (зависит от их прибыльности, не прибылен - не закупать) 2) стоит ли держать торговую точку или её нужно закрыть (издержки превышают прибыль от оборота товаров) 3) прибылен ли вообще этот бизнес и насколько (возможно стоит его закрыть и оборотные деньги пустить на другой бизнес).
Пользователей больше нет. Данные от реализаторов собирает себе один человек (владелец, либо главный бухгалтер).
Теоретически - проект рассчитан на частного предпринимателя, либо на небольшую фирму, с указанной выше структурой отношений участников в нём.


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


Мне хотелось бы разобраться в проектировании на примере небольшого проекта, поэтому я рассчитываю на "три человека и выполнять с ее помощью пять-шесть операций" 

P.S. Чем я только не занимался, пока не было сети... Какое там крепкое курево, тут без интернета не проживёшь и 3х дней, наркомания прямо 

Это сообщение отредактировал(а) Esperito - 22.5.2008, 15:22

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

• инфа о фирме и ее услугах
• справочные материалы + ответы на вопросы (львиная доля)
• развивающийся раздел о районе
• запылившийся исторический раздел
• продажа участков

Мы делаем ставку на предоставление исчерпывающей и актуальной информации по теме (простите за официоз) и общение посетителей с сотрудниками фирмы и между собой. 

Есть несколько типов данных, по сути — постов:

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

У каждого типа свои поля, например, у термина есть варианты и переводы; у участка — площадь, цена, коммуникации и привязка к населенному пункту, и так далее. 

К любому посту можно присоединить фотографии, файлы и объекты на карте.

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

Важный момент — фильтрация контента. Мы планируем для каждого типа данных ввести всевозможные фильтры, по которым человек легко сможет выбрать нужное для себя. Скажем для документа это будет тип (Закон, ГОСТ, СНиП), для заявки на участок — местоположение, приемлимая цена, наличие дома и т.п. И для всех объектов: раздел, метки и дата публикации.
---


Почитал статьи про UML и сейчас читаю книги:

• Г. Буч, Д. Рамбо, А. Джекобсон — «Язык UML. Руководство пользователя».
• К. Ларман — «Применение UML и шаблонов проектирования».
• М. Фаулер — «UML. Основы».

Особенно нравится последняя :) Но вообще непонятно, как все это применять к реальной задаче. Смотришь пример — все ясно, а берешь свой — тупик. Сначала я хотел просто составить схему БД, но застрял в ней, т.к. кроме списка принципов, на которых будет основан сайт, ничего больше нет.

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

В конце концов я попробовал выделить некоторые сущности и начал рисовать диаграмму классов, пока что она выглядит так:



Буду очень благодарен за наставление на путь истинный :)

Это сообщение отредактировал(а) altspam - 28.5.2008, 03:33

Тогда я считаю, что нам нужен класс Торговая точка. А классы Рынок и Склад не нужны.

А владелец с торговой точкой каким отношением связаны? Один ко многим?
В контексте данной задачи у всех торговых точек один владелец? Или есть много владельцев, и у каждого по несколько торговых точек?

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

Тогда получится такой набор классов:

Торговая точка
Товар
Владелец
Поставщик
Покупатель

Согласны?

А в вариантах использования действующими лицами будут Владелец и Реализатор (как пользователи программы).

Это сообщение отредактировал(а) ida - 22.5.2008, 22:11

altspam, у вас задача на проектирование, а не на анализ.

То, что вы перечислили, это обрывки функциональных требований, перемешанные с элементами модели проектирования. Поэтому вы и зашли в тупик. Уровни попутаны.

Давайте по порядку.

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

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

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

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

Администратор
Зарегистрированный пользователь
Незарегистрированный пользователь

Дальше определите наборы функций, которые должны быть доступны каждому из них.


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

Фильтрация или просмотр не являются вариантами использования - они имеют смысл только в контексте цели, которой пользователь достигает с их помощью, т.е., входят как отдельный шаг в какие-то варианты использования, например "Найти такую-то фигню".

Это сообщение отредактировал(а) ida - 22.5.2008, 22:50

Единственный владелец, много торговых точек. Один ко многим.


Да, понял, спасибо. Согласен.

Спасибо за пояснения. Попробую расписать варианты использования.


А они разве не взаимосвязаны? Мы проанализировали предметную область в силу своих скромных способностей, учитывали при этом опыт нынешнего сайта и его ошибки. Теперь можно начать делать сайт «на коленке», и решать проблемы по ходу появления, но хочется все же спроектировать цельную расширяемую систему и воплотить ее.

И где результаты анализа?...
Где процессы?
Где жизненные циклы объектов?
Где функциональные требования?
Ограничения?
И т.п.

А как быть с типизацией издержек? Есть издержка такая, есть сякая. И они как класс не зависят ни от чего. К примеру издержка "транспортные расходы", Эти транспортные расходы не зависят ни от чего. Конкретные Т.Р., конечно же, привязаны к конкретной торговой точке, владельцу, товару и т.д.

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

Если я правильно понял, на данном этапе (построение модели анализа) нужно выделить независимые классы предметной обласи. Т.е. классы, экземпляры которых «в жизни» могут существовать сами по себе. Так оно?

Тогда варианты использования предлагаю следующие:

1. Владелец:
Получить отчеты (разновидности отчетов вы перечисляли)

2. Реализатор:
Ввести данные из накладных
Получить отчеты

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

К размышлению:
Если требуется импорт данных из системы наружу, то надо подумать, кто будет производить этот импорт (или он будет производиться в автоматическом режиме?). Возможно, это будет делать Владалец, а возможно, другое действующее лицо - например, Бухгалтер. Т.е. есть вероятность, что мы сейчас нашли упущенного пользователя.


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


Обобщенно - да.

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

Это сообщение отредактировал(а) ida - 25.5.2008, 20:22

Попробую кратко описать.

Рассмотрим компанию, предоставляющие некоторые услуги абонентам. Особенность услуг - продолжительность: услуга начинает оказываться регулярно с момента заключения договора и до его разрыва. К примеру, услуга "телефонная связь". Или "вывоз мусора". Для предоствления конкретной услуги конкретному абоненту нужно обладать некоторой информацией, на пример, номером телефона для "телефонной связи" или "адресом" для "вывоз мусора.

Нужно построить систему которая
1. Будет хранить абонентов, услуги
2. Позволит понять каким абонентам какие услуги предоставляются. Когда начали предоставлять эти услуги, когда закончим.
3. Хранит информацию, необходимую для предоставления услуги каждому абоненту.

Далее.
Система предназначена для сотрудников абонентского отдела. Последние хотят:
1. завести нового абонента
2. найти существующего
3. заключить договор и начать предоставлять услуги
4. разорвать договор и прекратить предоставлять услуги
5. переключить в рамках одного договора с одной услуги на другую.
6. посмотреть абонента и его услуги

Пока все. Если это описание окажется не целостным (вдруг я что-то забыл ) - добавлю.

Это сообщение отредактировал(а) sandello - 26.5.2008, 14:33

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

Основная задача - деньги. Нужно считать, какой клиент сколько должен. И за что.

Т.е. это система контроля задолженностей?
А не предоставления услуг.

В вашем описании о задолженностях нет ни слова.

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

Я к чему это говорю - учитесь правильно ставить задачу, и вам ее правильно реализуют. Как поставите - так и реализуют. Не пинайте потом разработчиков. 

Это сообщение отредактировал(а) ida - 27.5.2008, 09:20

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


Дык, бизнес цели действительно пропустил 

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

Ну и далее, вторичные задачи, вытекающие из первых двух:
3. печать документов
4. учет оплат

Это сообщение отредактировал(а) sandello - 27.5.2008, 09:53

Владелец ещё вводит данные об издержках, т.к. знает о них только он.


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


Издержки бывают разных видов (я ранее указал примеры). Есть набор разных видов издержек, общая сумма которых учитывается в оборотной ведомости.

sandello, уже лучше.

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

Наверно, «проанализировали» — это громко сказано. Я представляю в целом, как все устроено, но не могу разложить по полочкам. Мы работаем в области геодезии и землеустройства, можно ли считать объектами регулирующие законы, нормы и правила, порядки оформления, земельные участки, заказчиков, госучреждения, выдающие справки, сами справки?


Незарегистрированный пользователь
1. Просмотр статей.
2. Скачивание файлов.
3. Контакт с фирмой
4. Контакт с представителем фирмы
5. Идентификация
6. Комментирование статей с проверкой email.
7. Расчет стоимости услуг
8. Регистрация

Зарегистрированный пользователь (клиент)
1. Авторизация
2. Авторизация через почту
3. Редактирование профиля.
4. Сохранение заказа.
5. Просмотр истории и статистики заказов.
6. Редактирование заказа.
7. Оформление заказа в офисе или по телефону.
8. Добавление вопроса специалисту.
9. Комментирование статей без проверки email.

Менеджер
1. Ответ на вопрос.
2. Редактирование заказа.
3. Оформление заказа.

Администратор
1. Управление контентом.
2. Управление пользователями.
3. Редактирование настроек сайта.
---

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

Проблема в том, что я не очень понимаю, как нужно строить варианты использования и как их дальше использовать. Например:
1) большая часть сайта — справочная информация, о компании и прочее — никак не отражается в моих вариантах, т.к. это суть просмотр страниц;
2) менеджер и клиент участвуют в одном процессе (оформление заказа), тут нужно по варианту для каждой стороны?
3) как раскрыть операции вроде управления контентом? «1. Администратор управляет контентом»? Тут столько вариантов добавлений, правок, удалений, перемещений, да еще есть админы с разным доступом;
4) нужно ли (и как?) показывать циклические действия, например, оценка суммы и редактирование заказа могут повторяться сколько угодно. Для циклов похоже будет другой тип диаграмм?
5) как отразить ветвления алгоритма? Читал про способ с указанием альтернатив, но это неудобно и ненаглядно;
6) как определить полноту описания и двинуть дальше?

Это сообщение отредактировал(а) altspam - 28.5.2008, 05:26

Присоединённый файл ( Кол-во скачиваний: 9 )
 use_cases.txt 4,69 Kb

где-то я уже это видел...   

ida, что еще не так?

altspam, вот уже появились какие-то кленты.
Они клиенты или все-таки зарегистрированные пользователи?...
Все клиенты являются зарегистрированными пользователями? Все зарегистрированные пользователи являются клиентами? Почему их называют клиентами?


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

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

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

1. Каких статей? Для чего они пользователю нужны?
2. Каких файлов? Для чего?
3. Для чего и с какой фирмой? В чем этот контакт заключается?
4. То же самое, что в предыдущем + в чем разница с предыдущим?
5. С какой целью?
6. Первое действие, похожее на настоящий вариант использования. 
7. Каких услуг? Кто их предоставляет?

1, 2 можно не разделять
3 нормально
4 непонятно - что значит "сохранение заказа" и почему оно отдельно?... Насколько я понимаю, чтобы что-то заказать, нужно проделать несколько шагов, сохранение - один из них. Где остальные?...
5, 6 нормально
7 какой участие принимает сайт в оформлении заказа в офисе или по телефону? Каким еще способом можно оформить заказ? И что же это наконец за заказ, про который мы уже полчаса говорим, а я так и не поняла, откуда и зачем он взялся?
8, 9 нормально.


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

2. Чтобы понять, "чей" вариант использования, полезно спросить: "кому нужно это действие? кто его инициирует?"
Поставив себя на место клиента, можно понять, что клиент инициирует оформление заказа, чтоб удовлетворить какую-то свою потребность (смотря что он там заказывает). Поэтому на диаграмме вариантов использования мы соединим этот вариант использования с действующим лицом Клиент (или как мы его там назовем).
У Менеджера цели будут явно другие - например, Посмотреть состояние заказов или Получить отчет.

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

4, 5. чтобы описать алгоритмы, нужно использовать диаграммы деятельности. Ими детализируют в том числе и сложные варианты использования, если требуется.

6. Еще рано 

Это сообщение отредактировал(а) ida - 28.5.2008, 12:10

sandello, а над вашей задачкой я еще подумаю.
Потому что из классов предметной области вижу ясно пока только один: Абонент.
Под вопросом: Услуга.

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

Свои версии?...

ida, 
Хых. Для описанной задачи мы сделали 3.
«Абонент» - его информация требуется для различной отчетности. Самостоятельная сущность
«Услуга» -  в данной поставновке требуется для задания способов расчета потребления. Они разные. Самостоятельная сущность.
«Подписка» на услугу или Услуга Абонента - сущность на стыке Абонентов и Услуг. Описывает подключение конкретного абонента к конкретной услуге.

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

Теперь вроде бы замкнутое описание 

А вы не посмотрели прикрепленный файл? Там я раскрыл варианты использования.


Зарегистрированный пользователь может стать клиентом, если закажет что-то.


Нет, есть и оффлайн-клиенты, которые нас не интересуют.


Нет, есть просто зарегившиеся на сайте для комментирования, вопросов и т.п. Это, так скажем, потенциальные клиенты.


Заказывающих удобнее называть клиентами. Думаете, нужен отдельный класс? Ведь функции у них одинаковы, «клиент» — это скорее условный статус зарегистрированного пользователя.


Поправьте, пожалуйста, ибо никак не могу взять в толк :)
Мы говорим об анализе предметной области.
Предметная область — часть реального мира, рассматриваемая в пределах данного контекста.
Соответственно, «Где процессы? Где жизненные циклы объектов? Где функциональные требования? Ограничения?» относится к реальному миру, с которым взаимодействует разрабатываемая система.
Возьмем объекты (классы?), которые я привел, какое отношение они имеют к сайту?

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

Я мыслю в правильном направлении?


Цели:

• привлечение клиентов;
• стимулирование потенциальных клиентов к контакту с фирмой;
• упрощение заказа услуг;
• увеличение авторитета фирмы на рынке.

А что нам это дает? В ТЗ всегда пишут «задачи сайта», «цели сайта», но на практике для 90% сайтов цели одни — увеличение продаж.



Справочная часть:

• Официальные документы — законы, ГОСТы, СНиПы, акты, рекомендации и т.п.
• Пояснения и комментарии к официальным документам.
• Рекомендации по самостоятельному оформлению — порядок действий, списки необходимых документов и т.д.
• Информация об организациях, имеющих отношение к землеустройству.
• Словарь терминов.

А также:

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

• Тексты официальных документов.
• Примеры и бланки документов, необходимых для самостоятельного оформления.
• Любые другие файлы, прикрепленные к статьям.

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


Это то же самое, но когда посетитель уже знаком с фирмой и ищет конкретного человека либо конкретного специалиста.


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


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


Землеустроительных услуг, которые предоставляет фирма-владелец сайта.



Шаги такие:

• Расчет стоимости.
• Сохранение заказа.
• Оформление заказа с менеджером (по номеру).

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

altspam, хорошо, ответьте мне на вопрос: для чего пользователь приходит на сайт?

Кто за чем.

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

altspam, вот это и будут ваши варианты использования.
Их и надо расписывать.

Кто-то хочет заказать съемку или оформление участка.


Кто-то хочет получить консультацию.


Многие ищут информацию, руководства, разбираются в теме.


Кто-то продает участок.
Кто-то хочет купить.

Кто-то просто интересуется геодезией.


Мм?

Добавлено через 5 минут и 48 секунд
ida, большое спасибо вам за помощь.
Вижу, что слишком загрузил, дальше буду разбираться сам. Направление примерно понятно.

Если нужно что сверстать — обращайтесь :)

Спасибо за еще одну классическую ошибочку :)

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

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

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

Это сообщение отредактировал(а) ida - 1.6.2008, 19:06

С этим согласен.  Я говорил про реализацию.

Тут я описал еще одну такую же модельную задачу. Она более детально прописана.  Предлагаю дальше на нее опираться.


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



Не вполне понял вопрос.

Так у вас там еще куча классов оказывается.

Я бы изобразила две системы на диаграмме кооперации и показала, какими данными они обмениваются.

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

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

Может не совсем в тему, но
Введение в UML.
Нотация и семантика языка UML
Может кому пригодиться.

Курсы курсами, а боевые задачи ничем не заменишь.

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

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

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


Там нет - а здесь есть.

Это сообщение отредактировал(а) ida - 6.6.2008, 15:21

ida, в блоге Вы решали несколько задач, приводили диаграммы, но изначальное описание отсутствует. Может добавить?

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

Доброе время суток.
Я студентка 4 курса, учусь на специальности - информационные управляющие системы и технологии в экономике.

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

Заранее спасибо.

А вам объяснили, что это такое? 

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