976

Системный Анализ и Требования / Re: Классификация требований

« : 21 Мая 2013, 23:14:22 »

Эдуард, чувствую, раскритикуете вы мой пример    К тому же подходы к написанию ТЗ (а также стиль изложения и форма представления информации) у всех разные, это все равно что спорить о вкусах.

Ну, Максим, это Вы напрасно. Не такой уж я и критикан, как меня малюют На самом деле, очень интересно посмотреть.

"Формирование требований пользователя к АС", на котором осуществляется "формулировка и оформление требований пользователя к АС" (ГОСТ 34.601). Это ли не описание юзкейсов?

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

Таким образом я это вижу так: 1. На стадии обследования осуществляется разработка диаграммы вариантов использования, проводится описание ВИ и т.д., вобщем описывается (в том числе, но не только) та самая точка зрения пользователя на Систему, о которой вы говорили. Отражается это в отчете о выполненной работе по обследованию объекта автоматизации.

Звучит разумно

2. На стадии разработки ТЗ эти юзкейсы используются как входные данные, которые трансформируются в те требования к Системе, которые все привыкли видеть в ТЗ. Как-то так (ИМХО).   

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

977

Sparx / Re: Ветвление потока управления в EA(диаграмма последовательности)

« : 20 Мая 2013, 23:15:37 »

Примерно так, особо никакими справками не пользовался

978

Системный Анализ и Требования / Re: Классификация требований

« : 20 Мая 2013, 23:00:16 »

Юзкейсы - это всего лишь форма представления информации. Тоже самое можно написать словами, придать нужную окраску (благо велик и могуч русский язык) и вот оно, ТЗ по ГОСТ   

Ой, а можно примерчик?

979

Для всех / Re: Правовой статус обозначений UML

« : 19 Мая 2013, 19:58:19 »

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

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

980

Задачи студентов / Re: Помогите с диаграммой вариантов использования

« : 19 Мая 2013, 19:41:29 »

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

Классики use cases говорят, что расширяющий use case начинает жить как альтернативный поток, и тот и тот запускается по условию.
Так что, если вам кажется, что это правильно и соответствует вашему пониманию - конечно делайте.

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

981

Для всех / Re: Правовой статус обозначений UML

« : 19 Мая 2013, 00:18:26 »

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

Более точно можно узнать на OMG.org, я думаю

982

Задачи студентов / Re: Помогите с диаграммой вариантов использования

« : 18 Мая 2013, 21:22:20 »

На каком слове акцент?

Быстро Тем более ведь еще надо работать. Вы читаете на английском? Могу прислать интересную книгу, если в личке дадите адрес.

983

Задачи студентов / Re: Помогите с диаграммой вариантов использования

« : 18 Мая 2013, 21:21:03 »

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

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

Вот пример из книги Use Case Modeling By Kurt Bittner, Ian Spence

Example
Outline for the use case Browse Products and Place Orders
Basic Flow
Browse Products
Select Products
Identify Payment Method
Identify Shipping Method
Confirm Purchase

Alternative Flows
A1 Keyword Search
A2 No Product Selected
A3 Product Out of Stock
A4 Payment Method Rejected
A5 Shipping Method Rejected
A6 Product Explicitly Identified
A7 Order Deferred
A8 Ship to Alternative Address
A9 Purchase Not Confirmed
A10 Confirmation Fails
etc….

Ну и немного описания
The Browse Products and Place Orders use case includes the following behavior:
The system displays the product offerings, highlighting the product categories associated with the Customer's profile.
The Customer selects a product to be purchased, entering the number of items required.
For each selected item that is in stock, the system records the product identifier and the number of items required, reserving them in inventory and adding them to the Customer's shopping cart.
Steps 3 and 4 are repeated until the Customer selects to order the products.

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

Таким образом варианты могут быть разные. Вам решать, что выбрать. Выделяя те или иные ВИ, Вы предлагаете свой вариант видения набора функциональности системы. И он ведь практически не обсуждался. Обсуждалась главным образом ДВИ и ее структура.

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

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

Так почему бы вам не описать все эти ВИ полностью и понять что в них общего, а что можно объединить и не рассматривать как отдельную часть функциональности?

984

Задачи студентов / Re: Помогите с диаграммой вариантов использования

« : 18 Мая 2013, 09:32:10 »

Эд, ты про магазин как коммерческое предприятие/организацию или про интернет-сайт?

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

985

Задачи студентов / Re: Помогите с диаграммой вариантов использования

« : 17 Мая 2013, 23:54:52 »

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

Я понял, мне не удастся Вас переубедить быстро. Ну как и Вам меня. Так что если все-таки хочется, давайте откроем тему или возможно такая тема уже есть?

986

Задачи студентов / Re: Помогите с диаграммой вариантов использования

« : 17 Мая 2013, 23:51:39 »

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

Конечно есть ошибки и не точности логического характера, но я не готов обсуждать каждый такой момент. В конце концов нет абсолютных правил как надо правильно писать ВИ, есть некий набор лучших практик и советы от  бывалых. (ну FAQ вы смотрели, можно поглядеть сюда.

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

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

Удачи!

987

Задачи студентов / Re: Помогите с диаграммой вариантов использования

« : 17 Мая 2013, 17:44:59 »

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

Может быть.
Но давайте развивать идею. ВИ - это набор сценариев: как минимум базовый успешный и масса разных альтернативных. Ясно, что альтернативы в принципе можно описать экстендами. А то что включается инклюдами - это по сути подпотоки базового потока, хотя они могут возникнуть и в алтернативных потоках. Если продолжить мысль, то наша ДВИ превратится в некоего монстра типа mind map. Но последнее - это мой слепок мозговой деятельности.

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

Очень хорошо. Это помогло Вам и может помочь другим, тогда нужно предложить методику и возможно ее обсудить и доказать ее эффективность, но может это сделать в другой ветке? Как считатете?

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

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

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

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

Пропустить первый этап и приступить ко второму - это не есть хорошо

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

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

Если отталкиваться от ДВИ как от центра и забыть о других средствах выражения - согласен.

Но это все, как говорится, ИМХО! 

Из разных имхо рождается истина

988

IDEF ARIS BPMN и пр. / Re: BPMN - Материалы по BPMN

« : 17 Мая 2013, 15:38:46 »

Бесплатный практический курс по BPMN:
http://elma-bpm.ru/blogs/kurs_bpmn/26.php

Спасибо

989

Задачи студентов / Re: Помогите с диаграммой вариантов использования

« : 17 Мая 2013, 12:01:30 »

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

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

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

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

990

Задачи студентов / Re: Помогите с диаграммой вариантов использования

« : 17 Мая 2013, 11:12:18 »

В точку! смотря с какого бока рисовать.

Ув. Briezzz. Да вы правы, есть набор правил, определяющий способы составления диаграмм, в частности ВИ. Однако тут нужно смотреть несколько аспектов: синтаксис, семантику и паргматику.

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

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

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

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

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

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

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