2 goodron: \r
Я студент. Столкнулся со следующей проблемой. Дали реализовывать нехилый проект, но техническое задание и описание предметной области никто, понятное дело, нормально предоставить не может. ... \r
\r
Мы все были когда-то студентами... :о) В ТехЗадание даны ссылки на топики,посвященные ТЗ и документированию проекта.\r
В В чем различия между термином методология и архитектура даны ссылки на топики,посвященные методологиям проектирования (RUP,UP,OOAD,XP) и UML (в них также есть и ссылки на лит-ру)\r
\r
.. Я понял, что пока клещами не вытащишь из людей информацию, никто и не рыпнется! Так с чего же следует все-таки начинать? Какие "правильные" вопросы необходимо задавать работникам в этой предметной области? Есть ли стандарты на это? \r
\r
В дополнение к тому, что уже сказали Dik76 и Jimmy по поводу структурных методологий функционального (IDEF0/3, DFD) и проектирования данных (IDEF1x): ваш вопрос лучше разделить на 3 подвопроса-подзадачи:\r
\r
выбор методологии анализа БП/структуры организации \r
\xa0 (цель: построение модели "КАК ЕСТЬ" бизнес-процессов/структуры (например,\r
\xa0 организационной) для лучшего понимания бизнеса заказчика. Здесь можно использовать:\r
\xa0 текстово-таблично описание, графические нотации/методологии типа SADT/IDEF0-3, \r
\xa0 ARIS, ISO, UP,RUP/UML - да, именно для получения бизнес-моделей);\r

выбор методологий анализа и проектирования ИС/ПО \r
\xa0 (цель создание моделей и описаний, например, ТЗ необходимых для понимания\r
\xa0 и создания ИС/ПО, автоматизирующей БП заказчика. Здесь можно использовать\r
\xa0 методологии/нотации: либо уже устаревшие чисто структурные типа SASD/DFD+ERD,\r
\xa0 либо чисто ОО или ОО-структурные типа XP,UP,RUP,ICONIX с нотациями UML/ERD);\r

как аналитику общаться с участниками проекта (заказчиком/пользователями и т.д)? \r
\xa0 (это отдельный и важный гуманитарный аспект 2 предыдущих подзадач)\r
\r
Если у вас возникнут вопросы по выбору методологии анализа и описания требований, а также проектирования именно ИС/ПО, то лучше задавать их в топике Подходы к проектированию системы.... Если у вас возникнут вопросы именно по OOAD/UML, то лучше задавать их в топике Обсуждение и Вопросы по ОБЪЕКТНО-ОРИЕНТИРОВАННЫМ МЕТОДАМ (ООАП / OOAD) и UML\r
\r
\r
2 Jimmy: \r
4. UML предназначен для работы с ОО технологиями, т.е. хорош, когда нужно описать модель ОО системы (довольно неразумно пытаться описать на UML схему РБД, хотя - сдуру можно и на ежика сесть). Обсуждается с представителями заказчика, которые понимают эту нотацию. \r
\r
Вообще UML универсален, т.е не предназначен для изображения только объектных моделей, т.е с его помощью можно достаточно хорошо изображать и структурные модели, например, функциональные (что делают IDEF0/DFD) или данных (что делают IDEF1x/IE)

2 Jimmy: \r
>Вообще UML универсален, т.е не предназначен для изображения только объектных моделей, т.е с его\r
>помощью можно достаточно хорошо изображать и структурные модели, например, функциональные (что\r
>делают IDEF0/DFD) или данных (что делают IDEF1x/IE) \r
\r
Вот это и сбивает с толку - универсальность. \r
Вернее - сбивает такое позиционирование UML (в отношении РСУБД). \r
Насколько я знаю, плата за универсальность - отказ от некоторых частностей (возможностей). \r
\r
Никакого отказа, т.е спецификация UML включает "механизмы", позволяющие изображать и хранить (например, в модели) не только модели/схемы данных, а очень многие виды статический и дианмических структур. Причем исходной целью было именно удобство (несколько возможностей для описания элемента), непротиворечивость, расширяемость (метамодель) и т.д. Например, в том же языке PL/SQL или Delphi есть масса возможностей языка, функций или тех же классов, к-рые при выборе своего стиля программистом, просто не используются :о)\r
\r
И здесь это очень заметно. \r
Например, хотелось бы увидеть, как с помощью UML можно сделать: \r
-- Primary Key \r
-- Foreign Key \r
-- Cascade update/delete/insert \r
-- Check constraint \r
-- Default constraint \r
\r
Вообще это имеет отношение не столько к UML, а к возможностям CASE-средства с поддержкой UML, т.е как это реализовано в нек-рых сегодняшних средствах:\r
\r
PK, FK, Check & Default constraints: стереотипом (например, <<PK>>),\r
  иконой (например, ключ для PK), цветом и стилем шрифта для атрибута\r
  (столбца таблицы) или класса (таблицы),\r

Cascade update/delete/insert: стереотипом, стилем, комментарием, если есть\r
  условные триггеры для стрелки ассоциации (отношения) или класса\r
  соответственно\r
\r
См. также топик Помогите выбрать CASE

Забавно :0))
Я хотел сначала добавить в свой пост примечание, что не нужно аппелировать к стереотипам - не стал.

И правильно, что не добавили! Неплохая попытка "очернить" (в хорошем смысле) стереотипы :о)

Почему?
Ну, я думал, что может быть есть таки механизм, который я просто не знаю и который может применяться для описания схем РСУБД.

Есть: стереотипы и все остальное

Стереотип - вещь неформализуемая, т.е. два человека, рисуя одну и ту-же схему РСУБД c использованием UML применят разные стереотипы (их реализацию) и не смогут прочитать диаграммы друг-друга.

Как это не странно, но сколько я видел CASE-средств, в к-рых UML (или чуть измененный UML) используется для моделирования данных - там везде используются одни и те же стереотипы:

<<PK>>, <<FK>>, <<unique>>, <<null>>/<<not null>>

<<index>>, <<trigger>>, <<sp>>

<<default>>, <<check>> и т.д (здесь могут быть вариации, но как я подозреваю
  это связано просто с желанием вывести больше инфы и обеспечить читабельность)

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

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

Лично я не против использования других нотаций вместе с UML. Это нисколько не затратно и даже оправдывает себя. Например, мы используем UML(также и для данных) + IE/DM(только для данных). Другое дело, что у нас средства это позволяют и они как бы "состыкованы", т.е модели передаются туда-обратно без проблем. А кто-то не может себе позволить купить достаточно дорогие средства с поддержкой UML и нотаций для данных поэтому он и выберет одно, но с универсальной нотацией - UML :о)