1006

Реализация / Re: Эффективная инженерная (и не только) документация

« : 23 Июня 2008, 18:57:57 »

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

А в чём противоречие? Разве в этом всём заключается эффективность?

1007

Для всех / Re: как не нужно делать. пример неудачной классификации.

« : 23 Июня 2008, 17:10:49 »

Это как проблема того, правильно ли я сделал какую-либо диаграмму uml. Один скажет правильно, другой - нет. Это субъективно, ИМХО.

Особенно если эта диаграмма была сделана пару тысяч лет назад...

1008

Управление Проектом / Re: Народ! Я изобрел проектное управление...

« : 23 Июня 2008, 13:45:50 »

Очень понравилась оригинальная иконка "потребитель". Сразу видно, откуда у него растут руки.
Интересно, это нарочно так сделано, или само всплыло из глубины подсознания?

1009

Обучение / Re: Обучение SPARX EA

« : 23 Июня 2008, 12:22:20 »

Интересно... Что, нет никаких отдельных курсов? Как-то ведь люди учатся с ним работать...

1010

Системный Анализ и Требования / Re: Преимущества выстроенного процесса Управления Требованиями

« : 10 Июня 2008, 15:40:04 »

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

Так может, и не надо тогда никакого процесса?

1011

Системный Анализ и Требования / Re: Преимущества выстроенного процесса Управления Требованиями

« : 10 Июня 2008, 15:08:38 »

По-моему, никакой количественной оценки не получится. Потому что на ноль делить нельзя.

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

IMHO, чтобы убедить заказчика, нужно непрерывно капать ему на мозги, приводя пункты 4.1-4.14 на человеческом языке в разных вариантах, подкрепляя примерами из жизни (причём из ЕГО жизни).

1012

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

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

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

Я, честно говоря, из всех объектных языков серьёзно только на C++ и работал. Java изучал когда-то, даже сертификаты есть, но не пригодились.

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

"Отношение ассоциации" у меня лично никаких вопросов не вызывает. Разве что само слово раздражало поначалу своим наукообразием, но не больше, чем "инкапсуляция" и "агрегация", не говоря уже о "полиморфизме". Есть стрелочка, она нужна для понимания взаимосвязи объектов, и всегда понятно, что она означает в данном конкретном случае. А относится она к классу "стрелочек", "заострённых палочек", или "графических обозначений отношения ассоциации в нотации диаграмм классов UML 2.0" - какая разница?

Это же как с алфавитом - когда я читаю текст, какая мне разница, из чего состоит слово - из "букв", "литер" или "графем"?

1013

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

« : 05 Июня 2008, 14:20:32 »

uml ная диаграмма классов была явно навеяна языком с++ с его множественным наследованием. если бы она не покрывала возможности с++, это вызвало бы отторжение программистской общественности. никакой более глубокой мысли в наборе возможностей диаграммы классов в uml и нет.

Но вдруг есть? Неужели все, кто использует UML не ведают, что творят? Причём вот уже двадцать лет... Прямо МАТРИЦА какая-то получается.

1014

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

« : 05 Июня 2008, 13:33:55 »

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

Морякам это скажите.

Шаровая краска используется для окраски кораблей.

Кубовый цвет упоминается даже в словаре Ожегова.
http://ozhegov.ru/slovo/20245.html

1015

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

« : 05 Июня 2008, 12:51:35 »

я пока говорить шаровой цвет не научился. и кубовый краситель тоже.

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

1016

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

« : 05 Июня 2008, 11:34:37 »

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

"...Люди - это идиоты.
Себя я тоже включаю сюда...
Неважно, насколько вы остроумны и находчивы, всё равно большую часть дня вы проводите, как идиот."

Эдвард Йордон, Death March (в русском переводе - "Путь камикадзе")

1017

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

« : 04 Июня 2008, 11:29:31 »

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

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

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

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

1018

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

« : 03 Июня 2008, 20:46:32 »

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

А как быть с ОС, претендующей на полезность? А с ОС, претендующей на коммерческий успех?

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

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

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

Действительно, йерунда получается. А СУБД вы тоже до сих пор только иерархические используете?

1019

IDEF ARIS BPMN и пр. / Re: IDEF0 - описание правил оформления документов

« : 02 Июня 2008, 12:43:43 »

Собственно, о чём это я... Я же сам могу его добавить в файловый архив.

Добавил.

1020

IDEF ARIS BPMN и пр. / Re: IDEF0 - описание правил оформления документов

« : 02 Июня 2008, 11:58:46 »

Наткнулся на описание IDEF0 на русском языке. По-моему, в файловом архиве uml2.ru такого документа ещё нет.

http://www.businessstudio.ru/files/idef0rus.pdf