4486

Примеры / Re: Задачка на диаграмму классов (концептуальную)

« : 25 Декабря 2007, 14:04:53 »

Опять 25.

Сережа, расслабся. Скажи я Солнце, большое горячее солнце. У меня теплые уши и мне очень хорошо

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

Так коррекция введена, работаем по ее оригинальной форме.

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

Я не против тренарных ассоциаций, и они тут вполне уместны.

Не очень понимаю твою аргументацию по поводу невозможности использовать тут класс ассоциации

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

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

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

Это хорошо! Это есть некое доказательство качества исходной формулировки, согласен?

4487

Примеры / Re: Задачка на диаграмму классов (концептуальную)

« : 25 Декабря 2007, 13:47:31 »

Вот еще прочтение

4488

Примеры / Re: Задачка на диаграмму классов (концептуальную)

« : 25 Декабря 2007, 13:27:57 »

Серега, кончай бузить

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

Тренарная связь - ее лучше избегать, можно ли ее считать атомарной в данном случае? И нельзя ли ее декомпозировать.

ну насчет 2 могет быть
насчет 3 возможно - возобладал здравый смысл, + запись о том что один из работкников отдела и является его руководителем

4 крыша у тебя не едет - она у меня едет

С точки зрения ER класс ассоциации будет фактически таблицей связью с дополнительными атрибутами: работник проект роль (вся коллекция уникальная)

4489

Бизнес-анализ и Целеполагание / Re: Вопрос по "оригинальной методике бизнес моделирования" от автора Е.Б. Золотухина

« : 25 Декабря 2007, 13:05:24 »

galiaskarov злой собака isuct офигенная точка ru

4490

Бизнес-анализ и Целеполагание / Re: Вопрос по "оригинальной методике бизнес моделирования" от автора Е.Б. Золотухина

« : 25 Декабря 2007, 12:08:05 »

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

4491

Проектирование / Re: Моделирование иерархической базы данных

« : 25 Декабря 2007, 12:04:55 »

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

4492

Примеры / Re: Задачка на диаграмму классов (концептуальную)

« : 25 Декабря 2007, 11:24:56 »

Мой вариант:

4493

Бизнес-анализ и Целеполагание / Re: Вопрос по "оригинальной методике бизнес моделирования" от автора Е.Б. Золотухина

« : 25 Декабря 2007, 11:22:47 »

А перевод того же Новичкова части книги Введение в RUP от Кратчена? По моему где в нашем архиве есть

4494

Проектирование / Re: Моделирование иерархической базы данных

« : 25 Декабря 2007, 11:19:23 »

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

Насчет связи между требованием и проектом - полностью согласен. Хотя может респондент имел в виду, что требование может и не принадлежать какой-либо группе?

4495

Проектирование / Re: Моделирование иерархической базы данных

« : 25 Декабря 2007, 10:20:04 »

Для ее описания я решил использовать диаграмму классов, описанную при помощи UML (другого не придумалось).

А ERWin не подойдет? На мой взгляд лучше, чем ERWin , и не предложишь.
Кажется, модель делана в VP UML? Но даже, если и нет, многие UML tools содержат средства работы с ERD.

В Розе есть инструмент Data Modeling, думаю он Вам здорово помог бы.

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

Ассоциации используются и отображают связи принадлежности между равноправными сущностями.

достаточно ли однозначно понимается модель?

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

не лучше ли использовать какой-нибудь другой вид диаграм для моделирования (какой, почему)?

Я бы предпочел ERWin. Он заточен для работы именно с данными и помогает быстро и эффектно построить модель БД, он умеет быстро и гладко соединяться с большим набром субд, генерить sql код и много других прелестей. Но это дело вкуса и доступности инструментов.

4496

Примеры / Задачка на диаграмму классов (концептуальную)

« : 24 Декабря 2007, 21:29:39 »

Одна "нехорошая" девочка подкинула мне тут задачку.

Составить диаграмму классов управления проектами, используя такое примерно описание:

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


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


Какие варианты?

4497

Управление Проектом / Re: Руководитель проекта, как им стать?

« : 24 Декабря 2007, 21:14:09 »

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

ПМ - психолог, он должен вызывать у людей уважение. Он должен заботиться о людяй, об удобстве их работы и среды, в которой они работают

ПМ человек, которому приходится делать неприятные вещи. И он должен уметь их делать, не роняя своего и чужого достоинства.

ПМ - это благородный муж (благородная жена ) - в смысле, который в него вкладывает Конфуций.

ПМ - должен глубоко понимать жизненный цикл разработки, обладать как стратегическим, так и тактическим мышлением

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

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

4498

Бизнес-анализ и Целеполагание / Re: Вопрос по "оригинальной методике бизнес моделирования" от автора Е.Б. Золотухина

« : 24 Декабря 2007, 20:40:16 »

Прочтите например Коберна, Agile Software Development, глава Russian Programmers, мне очень понравилось.

Саша, хочу, хочу. Сделай мне подарок на Новый год, а? Отскань главку

Irrунь, ты прям трибун.

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

IDEF0, делает ставку на минимализм средств отображения. Фишкой, кажется, считается строгость нотации и наличие разных видов входов: собственно вход-сырье, вход-управление, вход-механизм. Строгость и сила, и слабость. Возникает потребность искуственной декомпозиции, иногда сложно разделить управление и вход, плохо согласуется с ОО

IDEF3, как мне, кажется, используется редко и часто совершенно неверно. Думаю, связано с тем, что появились более приемлемые решения в виде диаграмм видов деятельности и им подобным. Представитель направления workflow

DFD - интересная нотация, активно поддерживается до сих пор, однако кроме Калянова даже и не знаю, кто использует для описание бизнес-процессов

ARIS- штука интересная, но мною не изучалась глубоко. Однако, MS пытается сделать ее стандартом, что может иметь большие последствия

Расширения UML Эриксона-Пенкера, хороший переход от IDEF0 к использованию инструментов c UML. Наверное именно так и задумывался, поскольку сами авторы утверждают - никаких новых идей, никаких новых подходов.  Business Modeling with UML: Business Patterns at Work by Hans-Erik Eriksson and Magnus Penker ISBN: 0471295515 John Wiley & Sons © 2000 (459 pages). Опять же кроме как в Enterprise Architect больше и не встречал

BPMN - насчитывает 3 года торжественного шествия, часто реализуется в UML tools, в той или иной степени строгости. При этом явно утверждают - мы лишь язык описаний ничего большего, все правила использования полностью на отвественности автора. Регламентируется лишь стадия перехода от BPMN к конструкциям BPEL, по-моему. А это уже фактически программирование, тут без строгости не обойтись. Сам язык, не что иное как таже диаграмма активности, IDEF3, немного ARIS, чуточку IDEF0 в одном флаконе. Фишка - развитый набор событий и логических переходов, но опять же весь этот набор так специфичен и на уровне описание бизнес-модели, как мне думается, опасен к использованию.

Кто продолжит ?

4499

Бизнес-анализ и Целеполагание / Re: Вопрос по "оригинальной методике бизнес моделирования" от автора Е.Б. Золотухина

« : 24 Декабря 2007, 16:39:32 »

Присоединяюсь к Irr и хочу от себя добавить.

В ходе моделирования у Вас появляется потребность использовать один и тот же объект в разных пакетах. Вы порождаете объект в одном пакете, а вдругом ссылаетесь на него. А таких ссылок может быть немало. Следовательно, можно общие объекты сгруппировать в некотором одном пакете: "Общие сущности", например. Тогда в каждом пакете будут содержаться только объекты внутренние для данного пакета + ссылки на объекты общего назначения.
Скажем История болезни может заводится в процессе Зарегистрировать больного, в процессе Назначить лечение разные врачи вносят туда изменения и т.п.

Советую посмотреть книгку Нейбурга и Максимчука Применение UML в проектировании баз данных (как-то так называется). Там есть сквозной пример как раз про медицинское учреждение.

4500

Управление Проектом / Re: Руководитель проекта, как им стать?

« : 24 Декабря 2007, 14:57:27 »

Дмитрий, путь развития выбирает каждый сам.

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

Ваш товарищ, в целом прав, но примерьте это к себе, попробуйте сами "написать статью"