2176

Теория моделирования и нотации / Re: Задача на n-арные связи

« : 29 Января 2007, 09:57:37 »

В первой диаграмме явная ошибка в навигации от ЦБ к Субъекту договора.

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

Вторая диаграмма вполне так себе. Разве что изображён момент до сделки, т.к. после совершения сделки владельцем уже является купивший.

2177

Системный Анализ и Требования / Уровни требований, связанные типы документов, источники, ответственные

« : 27 Января 2007, 23:42:29 »

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

Я изложил своё видение следующим образом:
Уровни требований, источники, документы, ответственные

Заодно отвечу на вопрос Юрия:

"Не могли бы вы более детально описать, что вы вкладываете в понятие "Требования к системе" (вид требования в вашей таблице)? И как он связан с источниками "Стандарты, Архитектурные шаблоны" и документом SAD?"

Тут идёт речь о высокоуровневых требованиях к ВНУТРЕННЕМУ устройству системы, т.е. по сути, об Архитектуре На самом деле было бы правильнее написать "Высокоуровневые требования к внутреннему устройству системы". Т.е. вся эта таблица - попытка взлянуть на процесс разработки и проход от потребностей до кода через призму требований. В таком контексте Архитектура системы, которую создаёт Архитектор системы, есть ничто иное, как ещё одни требования, для него исходящие, а для проектировщиков подсистем (это роль) - входящие.

2178

Сообщество Аналитиков / Re: Предложения по повестке для второй встречи сообщества аналитиков

« : 27 Января 2007, 23:19:41 »

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

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

Как НСП соотносится с "повышением рейтинга", поясни плиз.

По поводу реорганизации файлового архива - я понимаю, что ты волнуешься, но мы с БАСом договорились, что я на встречу принесу ДВД, который он зальёт на сайт, а я уже раскидаю по папкам.

2179

Сообщество Аналитиков / Re: Предложения по повестке для второй встречи сообщества аналитиков

« : 27 Января 2007, 21:30:02 »

Эдуард, вопрос "раскрутки" уже поднимался.

Я не вижу, каким образом задача "повышения рейтинга сайта" соотносится с задачами "накапливать, создавать и привлекать" (НСП), которые видим по крайней мере мы с Boatman'ом.

По поводу ресурса - не исключаю, что на встрече будет принято решение для задач НСП создать новый ресурс, без завязки на конкретную версию конкретного стандарта конкретной нотации, а с более общим названием и причём с привлечением людей из ooad.asf.ru, caseclub.ru, agiledev.ru в качестве полноправных участников

2180

Сообщество Аналитиков / Re: Предложения по повестке для второй встречи сообщества аналитиков

« : 26 Января 2007, 10:06:54 »

2 Boatman: По поводу "комсомольских заявлений" - это опять-таки был только пример формы формулировки целей )

С твоим набором задач "Собирать, Создавать и Привлекать" согласен.

2All: Ещё предлагаю выделить набор дисциплин, возможно, технологий, и закрепить каждого участника хотя бы за одной дисциплиной, лучше даже, если за одной. Так, например, если я закрепляюсь за дисциплиной "Архитектура ПО", то это значит, что в мои обязанности входит подготовка материала типа: Базовые концепции, История, Методы, Инструменты, Связь с другими дисциплинами, Стандарты, Имена, Сетевые ресурсы. Мне же адресуются прежде всего и все вопросы на эту тему. Таким образом мы разграничим области компетенций и ответственности, сфокусируем усилия. В качестве технологии специализации например у себя готов взять "Базы данных".

Какие дисциплины ещё хотелось бы, чтобы разобрали другие участники: "Управление проектами, Консалтинг, Бизнес-анализ, Объектный анализ и проектирование, Проектирование интерфейсов и информационная архитектура, Общий системный анализ, Требования, Тестирование и качество ПО, Программная инженерия".

Технологии - ну тут понятно: Процедурные языки (PL/SQL, ABAP, 1C ...), Объектные языки (C++, Java, C#, Ruby, php), XML, OLAP/DW/BI, и т.д. Возможно, ещё имеет смысл специализация по классам систем.

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

2 Юрий Булуй: Конкретно от вас хотелось бы услышать следующее по теме Программная инженерия:
Как возникла работа по переводу и комментированию SWEBOK? Продолжается ли в каком-либо виде эта работа?
Какие есть основные книги и деятели в этой области? Какую книгу и для чего стоит читать?
Какие основные веб-ресуры и организации по этой теме в мире, России?
Что происходит в России в смысле Программной инженерии?
В какую сторону развивается дисциплина? Какие школы и направления сложились?
Как много вузов внесли эту дисциплину в учебную программу? Какие учебники есть? Какие проблемы в сфере преподавания SE?
Почему если, как пишет МакКоннел, ROI от внедрения методов программной инженерии составляет 500-600% процентов, это  (внедрение) не происходит повсеместно? Или у вас другие оценки эффективности и отдачи?

2181

Примеры / Re: Конкурс оригинальных примеров

« : 25 Января 2007, 16:01:25 »

"Применние CASE-средств (читать UML) для проектирование ПО и моделирования технических объектов

Что-то не понял, в чём прикол. Если понимать под SE - System Engineering, то любая CAD система, как подкласс CASE, это делает - позволяет моделировать технические объекты как разновидность систем.

Насчёт UML - было бы логичнее данную задачу решать уже на SySML, а не на UML. Или в марте 2003, когда UML for SE RFP вышел, ты уже диплом вовсю доделывал?

2182

Сообщество Аналитиков / Re: Предложения по повестке для второй встречи сообщества аналитиков

« : 24 Января 2007, 21:02:25 »

М... собирать, аннотировать, рецензировать, размечать.. Прям скопидомцы какие-то, Плюшкины, Кощеи бессмертные ))

Я хотел бы под целями сообщества нечто более высокоуровневое понимать - некое описание видения желаемого будущего. Формулировка цели должна мотивировать сама по себе, быть глаголом в совершённой форме ("Российские аналитики стали ведущими аналитиками в мире") или описанием ситуации (Дети накормлены, Коровы надоены), а не процессом. То, что перечисленно нами - скорее задачи, то, что валяется под ногами.

Зачем мы хотим это делать?

* Создать прочную основу для профессии "Системный аналитик" в русскоговорящем сегменте?
* Повысить профессиональный уровень отрасли до мирового признания?
* Создать и развить образ Аналитика как Профессионала, Решателя проблем (Problem Solver), способного практически в * любой задаче, относящейся к сфере организации систем, создать ценность своими действиями?

Понятно, что здесь всё непросто, именно для этого нужна встреча.

2183

Сообщество Аналитиков / Re: Встреча Сообщества Аналитиков №2

« : 24 Января 2007, 19:14:22 »

Я думаю, как минимум продолжим где остановились.

Т.к. с интересами и потребностями определились, то займёмся:
а) целями сообщества
б) соответственно задачами и
в) способами их решения.

Имхо, достаточно.
+ какие-то CASE-ы разберём, у кого что накопилось.

2184

Бизнес-анализ и Целеполагание / Re: Бизнес-процессы в UML

« : 24 Января 2007, 09:53:10 »

Рекомендую поискать в сети "ARIS vs IDEF", "UML vs IDEF", "ARIS vs UML".

Я например нашёл вот такой интересный документ - "Business Modelling: UML vs. IDEF" (3Мб, 53 стр.). Поскольку ARIS является развитием SADT-идей, то часть наблюдений и выводов применима и к нему.

2185

Сообщество Аналитиков / Русскоязычные ресурсы

« : 19 Января 2007, 16:47:13 »

После годовых спячек проснулись:
http://ooad.asf.ru/
http://www.caseclub.ru/

Предлагаю заходить к ним, общаться, устнавливать связи.

Также интересен:
http://agiledev.ru/

2186

Системный Анализ и Требования / Исторические основания системного анализа

« : 18 Января 2007, 20:58:31 »

Карта для медитации настоящего системного аналитика

NJoy!

Some Streams of Systemic Thought

2187

Примеры / Re: Применение множественной классификации

« : 18 Января 2007, 11:08:20 »

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

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

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

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

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

2188

Книги, статьи и ресурсы / Re: Применение UML 2.0 и шаблонов проектирования

« : 17 Января 2007, 17:01:52 »

Ещё интересно, удалось ли к 3-му изданию издательству найти научного редактора, знающего профессиональный контекст и правила транслитераций имён фамилий, чтобы соответствующим образом:
Коберн, Фаулер, Бертран Мейер, Рамбо,
а не Кокбурн, Фовлер, БертранД, Румбах, и что Барбара Лисков - женщина.

)

2189

Примеры / Re: Применение множественной классификации

« : 17 Января 2007, 13:56:43 »

Да, сложный вопрос.

Мацяшек похоже унёс у Фаулера, который пишет в Analysis Patterns и UML Distilled 3:

Multiple classification is different from multiple inheritance.
Multiple inheritance says that a type may have many supertypes but that a single type must be defined for each object.
Multiple classification allows multiple types for an object without defining a specific type for the purpose.

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

Мейер
Критерии для наследования видов

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

Все же я нахожу наследование видов полезным при выполнении следующих трех условий:
    * Различные критерии классификации одинаково важны, так что выбор одного в качестве основного представляется спорным.
    * Многие возможные комбинации (такие как в примере: permanent supervisor, temporary engineer, permanent engineer и так далее) являются необходимыми.
    * Рассматриваемые классы настолько важны, что стоит потратить время на разработку лучшей из возможных структур наследования. Чаще всего речь идет в таких случаях о библиотечных классах повторного использования.

Фаулер:
Should you use multiple, dynamic classification? I believe that it is useful for conceptual modeling. For software perspectives, however, the distance between it and the implementations is too much of a leap. In the vast majority of UML diagrams, you'll see only single static classification, so that should be your default.

2190

Примеры / Re: Применение множественной классификации

« : 17 Января 2007, 11:54:44 »

Эдуард, давай не будем рубить с плеча, ок?

Во-первых, диаграммы классов UML имеют средства для выражения множественной классификации, что нам Slav тут и подемонстрировал. По первой ссылке по словам multiple classification in uml можно почитать о том, как в Agile методах множественная классификация используется для составления визуальных глоссариев в UML.

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

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

Проблема, поставленная Slav, мне кажется несколько надуманной. Давайте вспомним, что каждая модель субъективна, можно создать разные модели одной и той же Пр.Обл.

Далее, давайте различать модели анализа, проектирования и реализации.

Представленная Slav модель по всей видимости является концептуальной моделью анализа, т.к. не содержит атрибутов. Для этих целей (моделирования ПрОбл) она, возможно, достаточно полезна и полна. Ограничение того, что в ЛВС может входить только ПК, можно задать с помощью ассоциации между Аппаратурой и ЛВС и указанием ограничений типа {Мобильность: Стационарная аппаратура; Категория: ПК}, подробнее см. напр. UML 2.0 OCL.

Проблемы и задачи реализации данной модели на конкретном языке программирования (построение модели реализации) возникают только тогда, когда объектная модель анализа будет дополнена атрибутами и методами и преобразована в модель проектирования. Так вот, при преобразовании проектировщиком модели анализа в модель проектирования он может например принять решение на основании свойств объектов иначе организовать наследование, чем в аналитической модели. Например, возможно, класс "Аппаратура" не несёт никаких полезных для проектирования свойств (на данной модели анализа это не видно) и может быть исключён. Возможно, стоит сделать центральным класс ПК, от него унаследовать СтацПК и МобПК, а для АСД посчитать, что её мобильность не имеет значения, т.к. не имеет специфических свойств, зависящих от мобильности.

"Персона наследует множественно классы: Мужчина - Женщина, Ребенок - Взрослый, Студент и Преподаватель."
Мне казалось, наследует наследник. Разве персона - наследник?