76

Примеры / Re: Описание поведения GUI средствами UML

« : 11 Сентября 2011, 23:13:54 »

В том проекте, который рассматривается как пример в цикле моих статей (http://lnew.ucoz.ru/news/povyshenie_proizvoditelnosti_analitika/2011-07-25-18), веб-дизайнер делал прототип интерфейса по диаграмме граничных классов, представленной в спецификации UC. Системный аналитик должен согласовать этот прототип с заказчиком.
Но разработка прототипа - не его обязанность и в классике, и в большинстве проектных групп.

Поведение интерфейса вообще согласовывать с заказчикам нет необходимости, кроме как иллюстрацию к спецификации UC.

Видимо, в своей компании Вы аналитик, проектировщик и дизайнер в одном лице. Не позавидуешь!

Что касается артефактов, то они почти одни и те же при любой организации, только распределение исполнителей разное.

Как представлять "поведение интерфейса"? А что это такое?
- Поведение отдельного граничного класса во всех возможных ситуациях всех применений этого класса?
- Поведение граничного класса в кооперации взаимодействующих классов при реализации конкретного UC? Ну, это самое простое, описано во всех книжках по проектированию: диаграмма последовательности.
- Поведение всех граничных классов системы во всех ситуациях?

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

77

Примеры / Re: Описание поведения GUI средствами UML

« : 11 Сентября 2011, 16:15:25 »

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

Я должен описать UC так, чтобы обеспечить разработчику всю необходимую информацию. В частности, я должен описать вводы пользователя, какую информацию должен получить (увидеть) пользователь и т.д.

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

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

78

Примеры / Re: Описание поведения GUI средствами UML

« : 09 Сентября 2011, 20:50:16 »

Особенность ООП - "массовое" использование различных дихотомий.
При моделировании интерфейса (если это нужно в проекте, и если в этом проекте начальное представление интерфейса - обязанность системного аналитика) я использую дихотомию "статика/динамика".
В RUP определен профиль UML для модели анализа. Этот профиль получил широкое распространение вне RUP. Там есть стереотип "граничный класс". По сути - это класс, представляющий элемент GUI (окно, форма, область формы, кнопка и т.д.).

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

По мере рисования и описания деятельности я создаю граничные классы в модели анализа (это статическая модель интерфейса). Я использую классы для представления форм и областей форм, если есть, атрибуты для обозначения полей и операции для обозначения кнопок.
Прошу обратить внимание, что это УПРОЩЕННОЕ ОПИСАНИЕ способа. На самом деле есть много нюансов. Например, атрибуты формы представляют и области, которыми владеет форма, и т.д.
Если объекты интерфейса на диаграмме деятельности показаны явно, то этим объектам присваивается тип - соответствующий граничный класс.

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

Для каждого UC в модели анализа создается кооперация со стереотипом UCRealization. И рисуется диаграмма последовательности (полная или набор сценариев). В этой диаграмме показывается динамика: граничный класс получил сообщение пользователя, преобразовал и отправил контроллеру и т.д.

Но поведение, описанное в UCR, относится только к этому UC. А некоторые граничные классы участвуют в реализации различных UC!

Диаграмма состояний описывает полное поведение классификатора во всех возможных контекстах. По этому нарисовать ее довольно сложно. И не нужно.

Если я отвечаю за представление интерфейса, я включаю диаграмму классов (граничных) в спецификацию UC.
Пример можно посмотреть в приложении к статье "http://lnew.ucoz.ru/load/html_publikacii_modelej_rsa/opyt_ispolzovanija_uml/povyshenie_proizvoditelnosti_analitika_06/3-1-0-6". Это не по теме статьи, я случайно забыл убрать из живого документа.

Иногда (редко) я составляю по модели карту интерфейса (таблица со множеством столбиков; если кто хочет - могу прислать пример с пояснениями).

79

О Сайте и Форуме / Re: Лента внешних блогов аналитиков

« : 01 Сентября 2011, 19:33:46 »

Спасибо!
Т.е. любой человек "с улицы" может добавить ссылку в список от имени UML2?
Правильно ли это?

80

О Сайте и Форуме / Re: Лента внешних блогов аналитиков

« : 31 Августа 2011, 16:09:50 »

Товарищи командиры!
Объясните, мне, пожалуйста:
- кто и как помещает статьи (или ссылки) на эту ленту?
- если эти статьи идут от имени UML2, то как решаются вопросы единообразия мыслей, терминов и т.д.?

81

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

« : 25 Августа 2011, 21:09:07 »

Одна из дисциплин RUP называется "Бизнес-моделирование".

82

Идеи и мозговой штурм / Re: Повышение производительности аналитика

« : 25 Августа 2011, 21:03:41 »

6-я статья:
http://lnew.ucoz.ru/publ/opyt_modelirovanija_na_uml/povyshenie_proizvoditelnosti_analitika/povyshenie_proizvoditelnosti_analitika_06/6-1-0-31

Тема очень модная на нашем форуме: "Как описывать UC".

Жду комментариев!

83

Варианты Использования (Use Case) / Re: Кто нибудь встречал адекватный пример описания сценариев при обобщении ВИ?

« : 23 Августа 2011, 21:34:02 »

Честно говоря, я к наследованию UC всегда настороженно относился.Примерно так: в UML UC - это классификатор. И авторы предусмотрели наследование. Ну, пусть наследуют, если хотят. А я обойдусь!

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

Если хочется показать на диаграмме UC - показывать UC с точками расширения. У потомков в тех же точках расширения - другие UCE.

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

Это, конечно, "соображения". Реального примера у меня нет. А придумывать - будет "придуманное".

84

Варианты Использования (Use Case) / Re: Варианты использования не могут иметь пред и постусловия

« : 22 Августа 2011, 15:27:41 »

Фигушки!

Советую скачать и инсталлировать с IBM ru триал RMC.
Он содержит RUPы и "практики" (в т.ч. на русском).
RMC за ненадобностью деинсталлировать (инструмент для настройки или написания своего процесса). RUPы и "практики" остаются навсегда.

Но я этого не говорил!

Если кому надо, могу выслать свой неофициальный перевод (много, но, естественно, не все) в ворде.

85

Варианты Использования (Use Case) / Re: Варианты использования не могут иметь пред и постусловия

« : 22 Августа 2011, 12:40:38 »

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

На крайний случай, можно скачать псевдокнижку "Ведение в RUP". Написана (не дописана, по некоторым причинам) она очень давно, но до сих пор гуляет на просторах интернета: http://www.bookshunt.ru/b10345_vvedenie_v_rational_unified_process.

Многим терминология не нравится. Но это писалось тогда, когда на русском языке вообще почти ничего по RUP не было!

86

Варианты Использования (Use Case) / Re: Варианты использования не могут иметь пред и постусловия

« : 22 Августа 2011, 12:20:46 »

Я описываю этот шаг (если Вам так больше нравится): "Выполение UC включения <Название>".

87

Варианты Использования (Use Case) / Re: Варианты использования не могут иметь пред и постусловия

« : 20 Августа 2011, 22:26:28 »

Ну, что же. Я не Brain C

Но, как раз вчера вечером я выложил статью, которая предлагает другой вариант решения проблемы:
http://lnew.ucoz.ru/publ/opyt_modelirovanija_na_uml/povyshenie_proizvoditelnosti_analitika/povyshenie_proizvoditelnosti_analitika_05/6-1-0-30
И этот вариант, в принципе, не противоречит тому, что процитировал Эдуард.

Автор предлагает то же самое, что уже описано в RUPе: Если UseCase выполняются в определенной последовательности, то этот общий процесс можно определить как Use Case более высокого уровня, описать его как деятельность, действия которой - Use Case включения и расширения.

И на Use Case Diagram неправильно показывать последовательности их выполнения, она не для того предназначена.
Этим еще Коберн возмутился несколько лет назад.

А связано это с тем, что некоторые аналитики дальше Use Case Diagram UML не изучают!

Но причем тут пред- и постусловия? Не надо людей пугать!

88

Варианты Использования (Use Case) / Re: Варианты использования не могут иметь пред и постусловия

« : 20 Августа 2011, 17:08:01 »

Обнаружил вот такое интересное мнение. А что Вы думаете по этому поводу?
Use Cases Can Not Have Preconditions or Postconditions

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

Ребята!
Какая нам, аналитикам, разница, к "кому" относится предусловие, к UC или к его описанию? Все равно, UC можно выполнять только при соблюдении предусловий!

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

89

Идеи и мозговой штурм / Re: Повышение производительности аналитика

« : 20 Августа 2011, 13:28:09 »

Представляю 5-ю статью цикла:
http://lnew.ucoz.ru/publ/opyt_modelirovanija_na_uml/povyshenie_proizvoditelnosti_analitika/povyshenie_proizvoditelnosti_analitika_05/6-1-0-30.
Статья посвящена модели UC (как я использую бизнес-модель для создания модели прецедентов).
Не забудьте скачать приложение!

Заходите в гости!

90

Варианты Использования (Use Case) / Re: Несколько частных вопросов по ВИ

« : 19 Августа 2011, 10:43:07 »

Извините, Павел.
Я консультант по UML. Если Вы будете использовать UML, я готов Вам помочь.

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

До свидания на новом, более высоком уровне Ваших знаний и желаний!