4111

UML SysML и пр. / Re: Практическое применение UML

« : 09 Июня 2008, 22:30:44 »

В связи с этим возник вопрос: есть ли реальные проекты, реализованные на инструментальных средствах  IBM Rational или это фантастика? Учебные проекты разработанные в институтах в рассчет не идут - это все мулькина грамота, ничего не имеющая с реальными разработками ПО.

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

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

4112

ПО Аналитика / Re: [Посчитаемся] Какие CASE средства с поддержкой UML вы используете?

« : 09 Июня 2008, 15:20:47 »

Слышал, кто-то EA научил, мне КГ говорил...

Yumata, вот интересно освежить слух и найти корни его рождения

4113

Для всех / Re: помогите начинаюшему.

« : 09 Июня 2008, 15:10:53 »

Посмотрите внимательно например это http://www.uml2.ru/forum/index.php?topic=565.0 и вообще раздел примеры

4114

Sparx / Re: EA - скрытие наследуемых атрибутов, операций объектвов на диаграме?

« : 06 Июня 2008, 12:04:44 »

Ира, имхо, ты совершенно о другом

4115

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

« : 06 Июня 2008, 11:02:27 »

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

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

4116

Sparx / Re: EA - скрытие наследуемых атрибутов, операций объектвов на диаграме?

« : 06 Июня 2008, 09:06:03 »

самое неприятное то...что вышеупомянутая тафталогия-тафтология пишется как тавтология.

это ценное замечание, конечно тавтология

4117

Бизнес-анализ и Целеполагание / Re: Начало в описании БП.

« : 05 Июня 2008, 16:39:57 »

Насчет описания БП именно в телекоммуникационной компании сказать что-то сложно, нужно поискать материалы в интернете, насчет же образцов описания БП на просторах нашего форума я выкладывал как-то методику. Кроме того можно посмотреть как это делается в разных методологиях например RUP. Еще очень советую посетить и зарегистрироваться на сайте http://finexpert.ru. Там есть шаблоны описания регламентов БП и даны общие рекомендации, а также есть ряд референтных моделей.

В чем конкретно делать вопрос открытый: это может быть АРИС, нотация IDEF0 и IDEF3, BPMN, нотация Эрикссона-Пенкера, диаграммы деятельности UML

4118

UML SysML и пр. / Re: Теория и практика использования диаграмм классов

« : 05 Июня 2008, 12:31:58 »

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

Совершенно не сопоставимо.
1. сначала были языки, потом родилась нотация язык описания, метаязык.
2. UML - это не язык программирования
3. не все вещи реализуются сразу, например, принципиально возможно летать на Марс, но вот пока не летают
или ну вот нет еще нормальных средств распознования рукописного текста, но вообще  - это возможно и единично решено.
4. так и с множественным наследованием - хотя причем тут множественное наследование? тут вообще тема была про другое немного, про использование или не использование диаграммы классов для отображения программы

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

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

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

4119

UML SysML и пр. / Re: Теория и практика использования диаграмм классов

« : 04 Июня 2008, 21:26:46 »

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

4120

UML SysML и пр. / Re: Теория и практика использования диаграмм классов

« : 04 Июня 2008, 19:59:21 »

задирать нос не стоит.

Да нет что Вы, я не задираю высказываю свое мнение. Вы же его высказываете, я не говорю не задирайте мол нос.

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

4121

UML SysML и пр. / Re: Теория и практика использования диаграмм классов

« : 03 Июня 2008, 23:01:13 »

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

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

Потому и говорят множественная классификация, часто на практике встречающаяся ситуация.

4122

UML SysML и пр. / Re: Теория и практика использования диаграмм классов

« : 03 Июня 2008, 22:58:12 »

вы похоже утверждаете, что системный анализ и задачи системного программирования несовместимы и понятие системы в них разныя?
тогда дайте понятие системы, в том и другом случае, и покажите разницу.

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

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

Системный анализ возник в эпоху разработки компьютерной техники. Успех его применения при решении сложных задач во многом определяется современными возможностями информационных технологий. Н.Н. Моисеев приводит, по его выражению, довольно узкое определение системного анализа [1]: «Системный анализ — это совокупность методов, основанных на использовании ЭВМ и ориентированных на исследование сложных систем — технических, экономических, экологических и т.д. Результатом системных исследований является, как правило, выбор вполне определенной альтернативы: плана развития региона, параметров конструкции и т.д. Поэтому истоки системного анализа, его методические концепции лежат в тех дисциплинах, которые занимаются проблемами принятия решений: теории операций и общей теории управления».

Вне всякого сомнения нельзя противопоставлять эти понятия. но нельзя и сравнивать.

Вы же не сравниваете периодическую систему Менделева и синтез аммиака.

представление данных и логическая классификация понятий - вещи разные.

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

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

Классический? Но тут не сопоставимые понятия. Цвет - это конечно может быть класс, но все-таки скорее простой тип, не обладающий функциональностью и свойствами, вернее имеющее одно единственное свойство - самое себя, ну или если хотите длину волны.

Шар же  имеет форму, структуру, фактуру, вес, размер, материал. Скажите существует не цветной шар? т.е. бесцветный? и какого цвета цветной шар ночью?

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

А если взять такое понятие как частица. Известно что она дуальна: она есть материальный объект и волна.

Или возьмем растение Росинка - это и растение - но и животное, там есть и то и другое.

А как назвать профессора, который обучается? Ну конечно такие глупости делать в программировании не нужно, но в ПРИКЛАДНОМ программирование всякое может возникнуть.

Хотя часто встречающая проблема. Сотрудник: руковдитель и просто исполнитель, еще он может быть на окладе и иметь почасовую оплату.

А классический пример с АМФИБИЕЙ! Ой если покопаться найти можно еще. Конечно гуру говорят нам избегайте таких проблем - ибо ну не могут это делать просто ООЯ.

Аналогичная ситуация с ER и реляционной БД. Нет в ней связей многие ко многим, потому такая связь называется неспецифичной и требует разруливания через таблицу связи.

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

4123

UML SysML и пр. / Re: Теория и практика использования диаграмм классов

« : 03 Июня 2008, 22:34:10 »

Alys, нажимаем на кнопочку ЦИТИРОВАТЬ, в результате в форме быстрого ответа появлется цитата. Править и что-то делать не удобно?
Согласен, хотя несложно переключиться на латиницу и написать для первой цитаты [/quotе]
а все последующие [quotе] [/quotе]

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

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

4124

Sparx / Существуют ли скрипты отчетности в SPARX EA?

« : 03 Июня 2008, 18:05:09 »

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

4125

Sparx / Существуют ли скрипты отчетности в SPARX EA?

« : 03 Июня 2008, 15:07:09 »

Такая возможность есть, но хотелось бы уточнить что Вы хотите. Поскольку с АРИС я не работал и не могу точно знать, что Вам требуется