Мой преподаватель в моем курсовом проекте сказал, что БД является частью ИС и при проектировании ИС нельзя делать коммуникации БД(actor) и ВИ, т.к. ВИ - это реакция ИС на какое-либо действие, которое не может исходить от части ИС, а должно исходить от реальных actor...

Собственно в http://progbook.ru/ есть книга:
Роберт Дж. Мюллер - Базы данных и UML. Проектирование.djvu
82,84 страницы - живой пример тому.

Вот принтер (к примеру), тоже во многих книгах показан как actor (Луис Девидсон. Проектирование баз данных на SQL Server 2000, стр. 107).

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

Конечно же торопился и ошибся в названии темы.
Необходимо исправить заголовок если есть возможность:
"Можно ли в диаграммах Use Case представлять DataBase как Actor?

Все зависит от Контекста. Если БД - это часть вашей ИС (как это обычно бывает), то не надо его показывать на Диаграмме, т.к. кроме БД есть еще и другие компоненты ИС. Тоже самое и с Принтером.

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

Красота.

Структурированный набор данных у них может быть агентом.

Красота.

Структурированный набор данных у них может быть агентом.

Согласен с Денисом, но не согласен с его эмоциональной окраской ответа

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

Однако, есть варианты, когда СУБД может быть актором или Основным Действующим Лицом. Это вариант, когда СУБД по таймеру инициирует какие либо действия. Например, информационный обмен с дочерней или родительской БД. Важно то, что "структурированный набор данных" не может быть агентом, а СУБД может.

Однако, есть варианты, когда СУБД может быть актором или Основным Действующим Лицом. Это вариант, когда СУБД по таймеру инициирует какие либо действия. Например, информационный обмен с дочерней или родительской БД. Важно то, что "структурированный набор данных" не может быть агентом, а СУБД может.

В сообщении говорилось не об СУБД, а о Базе данных. Если в данном случае рассматривать именно как СУБД, то СУБД - нормальный внешний субъект с точки зрения приложения к базе данных, более того это ориентирует нас на создание(использование) интерфейса доступа к базе данных.

С точки зрения все системы Субд - компонент

Я пишу сайт на PHP + MySQL по роду своей деятельности (Сайтом его назвать сложно, т.к. это по большей части программа ввода данных о приеме вычислительной техники в ремонт, анализа этих данных в дальнейшем).
Сайт будет расположен на одном сервере, база данных - где угодно (в том числе может находиться на этом же сервере).
А ведь MySQL полноценная СУБД, т.е. моя программа будет обращаться не в отдельный файл как таковой (как ,к примеру, если бы на Дельфи писал и читал из файла .mdb от Майкрософт Акцесс) - а делать запросы к СУБД.
Но с другой стороны я же обращаюсь к базе данных, которая является частью СУБД
Сейчас сам себя запутаю А вдруг Вы передумаете

Я пишу сайт на PHP + MySQL по роду своей деятельности (Сайтом его назвать сложно, т.к. это по большей части программа ввода данных о приеме вычислительной техники в ремонт, анализа этих данных в дальнейшем).

Это называется веб-приложение. Место размещения которого - сайт

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

Архитектура приложения может быть любой. В вашем случае -это многозвенная архитектура (ну или для простоты клиент-серверная). Это логическая архитектура, которая может физически быть расположена на одном процессоре, а может на разных. В любом случае архитектура вашего веб-приложения предусматривает клиентскую часть - это что будет отображаться и исполняться непосредственно на браузере клиента (или каком-то веб-ориентированном клиенте), и серверной части - которая будет расположено соотвественно на веб-сервере(хосте) скорее всего apache, где в качестве модуля выступает препроцессор РНР (интерпретатор серверного рнр-кода).Механизм подключения к базе данных осуществляется через стандартные модули РНР. Способ изоляции может быть разным, вдруг Вы используете библиотеку PEAR. В любом случае в вашем приложении будет интерфейс доступа к базе данных: элементарно набор функции рнр для работы с mysql, либо набор классов самописных или библиотечных, той же PEAR. Таким образом база данных - это просто хранилище, СУБД - сторонний компонент - вы НЕ МОЖЕТЕ его проектировать, Вы можете его использовать использовать его API

Таким образом СУБД (именно субд) выступает как внешняя система (причем не только СУБД), а внешние системы принято изображать на ДВИ актерами.

Это называется веб-приложение. Место размещения которого - сайт

Ну да, я понимаю, просто выговорить что-то не смог. Смешно писать то, не зная что

Архитектура приложения может быть любой. В вашем случае - это многозвенная архитектура (ну или для простоты клиент-серверная). Это логическая архитектура, которая может физически быть расположена на одном процессоре, а может на разных. В любом случае архитектура вашего веб-приложения предусматривает клиентскую часть - это что будет отображаться и исполняться непосредственно на браузере клиента (или каком-то веб-ориентированном клиенте), и серверной части - которая будет расположено соотвественно на веб-сервере(хосте) скорее всего apache, где в качестве модуля выступает препроцессор РНР (интерпретатор серверного рнр-кода).Механизм подключения к базе данных осуществляется через стандартные модули РНР. Способ изоляции может быть разным, вдруг Вы используете библиотеку PEAR. В любом случае в вашем приложении будет интерфейс доступа к базе данных: элементарно набор функции рнр для работы с mysql, либо набор классов самописных или библиотечных, той же PEAR. Таким образом база данных - это просто хранилище, СУБД - сторонний компонент - вы НЕ МОЖЕТЕ его проектировать, Вы можете его использовать использовать его API

Таким образом СУБД (именно субд) выступает как внешняя система (причем не только СУБД), а внешние системы принято изображать на ДВИ актерами.

Т.е. используя БД, находящуюся на сервере MySQL я использую его API для доступа к моей БД и получается обращаюсь к внешней системе?
Получается, что я верно привел пример Дельфи и файла ххх.mdb? Если бы я использовал такой способ - тогда нельзя будет показывать БД как внешнюю систему в виде Актёра?

ЗЫ:
Использую Апач сервер с ПХП, подключенный модулем.
К MySQL обращаюсь встроенными функциями PHP (Mysql_connect, Mysql_query...).

Ну да, я понимаю, просто выговорить что-то не смог. Смешно писать то, не зная что :)Т.е. используя БД, находящуюся на сервере MySQL я использую его API для доступа к моей БД и получается обращаюсь к внешней системе?
Получается, что я верно привел пример Дельфи и файла ххх.mdb? Если бы я использовал такой способ - тогда нельзя будет показывать БД как внешнюю систему в виде Актёра?

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

Правильно ли я понимаю UML в контексте задачи "сервисный центр по ремонту вычислительной техники?
Или первую диаграмму бизнес вариантов использования нужно декомпозировать по отдельности на диаграммы активности в каждом ВИ?
Можете посоветовать мне как лучше поступить? Я пишу диплом. Нам акцентировали BP Win для моделирования бизнес-процессов (один преподаватель), а UML - просто как новое модное веяние в проектировании (другой преподаватель). А для проектирования БД давали ER-Win (пожалуй его давали больше всего и понятнее всего).
Я в MySQL WorkBench спроектировал свою БД в виде ER диаграммы и теперь думаю:
"А нужно ли мне вообще использовать UML, или же проектная часть закончена?"
И вроде бы себе отвечаю:
"Проектная часть БД может быть и закончена, а вот проект приложения - нет!"

Правильно ли я понимаю UML в контексте задачи "сервисный центр по ремонту вычислительной техники?

Мне кажется, нет. Если задача состоит в описании бизнес процессов сервисного центра, то границы и есть сам сервисный центр, а актеры сосредоточенные вокруг него - это внешние сущности:клиенты, поставщики, партнеры и т.п., которые заинтересованы во взаимодействии с центром и имеет какие-то цели, достижение которых центр обеспечивает.
В этом случае у клиента нет цели Доставить СВТ, а есть цель Отремонтировать СВТ.
Сотрудник центра внутри границ этого контекста - он исполнитель. Смотрите на свою ДД на ней появились эти самые сотрудник-роли более подробно.
Если цель ваша построить решение Управления заявками на ремонт вычислительной техники, то контекстом станет эта самое решение - приложение, в котором Клиент может стать актером (если он работает с вашим приложением для размещения и отслеживания порядка исполнения заявки), а может и не стать, если заявку принимает сотрудник, вводит ее в систему и сам контролирует и извещает клиентов о готовности. В этом случае ВИ будут отражать цели пользователей подобной системы...

Или первую диаграмму бизнес вариантов использования нужно декомпозировать по отдельности на диаграммы активности в каждом ВИ?

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

Можете посоветовать мне как лучше поступить? Я пишу диплом. Нам акцентировали BP Win для моделирования бизнес-процессов (один преподаватель), а UML - просто как новое модное веяние в проектировании (другой преподаватель). А для проектирования БД давали ER-Win (пожалуй его давали больше всего и понятнее всего).

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

Я в MySQL WorkBench спроектировал свою БД в виде ER диаграммы и теперь думаю:
"А нужно ли мне вообще использовать UML, или же проектная часть закончена?"
И вроде бы себе отвечаю:
"Проектная часть БД может быть и закончена, а вот проект приложения - нет!"

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

Т.е. все это будет зашито в приложении видимо. А как будет разрабатываться приложение? С использованием паттерна Magic Button или Document-View или это будет что-то более передовое. Планируется ли использование ОО программирования, или это будет аля студнеческое понимание Дельфи с обработкой бизнес логики на событиях кнопок и контролов форм? Знаете ли Вы вообще что либо о приниципах структурного или ОО проектирования?

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

сосредоточенные вокруг него - это внешние сущности: клиенты, поставщики, партнеры и т.п., которые заинтересованы во взаимодействии с центром и

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

Верно. Я только хотел показать, что к нам доставляют СВТ. А ведь действительно, зачем это показывать, если это нас не касается...
Картинка Bussines_UseCase.jpg - так должна выглядеть ДБВИ ?
Дальше получается нужно описывать уже ДСВИ?

Сотрудник центра внутри границ этого контекста - он исполнитель. Смотрите на свою ДД на ней появились эти самые сотрудник-роли более подробно.

А я думал, что нужно указывать границы самого приложения.
Или это уже в ДСВИ делается (System Boundary)...
Я попробовал вот так:
System_UseCase_Diag.jpg

Если цель ваша построить решение Управления заявками на ремонт вычислительной техники, то контекстом станет эта самое решение - приложение, в

котором Клиент может стать актером (если он работает с вашим приложением для размещения и отслеживания порядка исполнения заявки),

Да, цель именно в этом, только без участия в этом клиента.

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

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

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

Без или. Каждый ВИ должен быть специфицирован тем или иным способом. Способ спецификации (текст, диаграммы) должен быть продиктован

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

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

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

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

автоматы, сети петри и т.п.

Ясно. Мой научный руководитель говорит, что этой ER-диаграммы вполне достаточно для части проектирования.

Я бы не назвал это полным проектом БД, это лишь часть метасхемы:
- каковы процедуры ссылочной целостности
- доменная структура только базовая
- не заданы альтернативные ключи, инвертированные входы(индексы) кроме первичных
- не определены бизнес правила на значения
- нет представлений обеспечивающие инкапсуляцию структуры
- нет ни триггеров ни хранимых процедур определяющих некоторую бизнес-логику
Т.е. все это будет зашито в приложении видимо. А как будет разрабатываться приложение? С использованием паттерна Magic Button или Document-View

или это будет что-то более передовое. Планируется ли использование ОО программирования, или это будет аля студнеческое понимание Дельфи с

обработкой бизнес логики на событиях кнопок и контролов форм?

Так глубоко мы не изучали ни один предмет. Самостоятельно у меня ещё не получилось уделить должное внимание подобным моментам, т.к. недавно родился ребенок и читать совершенно некогда - всё на бегу... Хотя всё это очень интересно и нужно для меня.
Всё что нам давали по БД - основные комманды SQL, основные понятия (домены, кортежи, таблицы, ключи ФК, ПК, Альт.К, , связи, отношения).. всё.

Знаете ли Вы вообще что либо о приниципах структурного или ОО проектирования?

Со структурным проектированием я познакомился на предмете Экономические Информационные Системы. Там нам показывали (IDEF)SADT методологию и учили работать в BP Win.
А на предмете по проектированию ИС нас грузили определениями из ГОС. Точнее мы только писали, писали, писали сами не понимая и не осознавая что мы пишем и зачем (хотя курс у нас конечно очень сжатый - всего наверное часов 30 и то не было)  и в конце всего курса бегом показали StarUML.
Но когда надо было делать курсовик по проектированию ИС - пришлось почитать Вендрова, посмотреть курсы UML Грекула на Intuit.ru. Но в голове образовалась такая каша, которую Вы сейчас наблюдаете. Курсовик я так и сдал - видели что сам учил, вникал - видимо заслужил. Это что касается ООП проектирования.
Поэтому могу сказать, думал что знаю о принципах проектирования структурного и ООП. Но сам понимаю, что слишком мало прочитал и освоил для того, чтобы свободно в этом разбираться.
Структурное проектирование - SADT (с этой методологией знаком по Case средсву BPWin.
ООП проектирование - UML как один из вариантов (Case средств много - я использую StarUML).

Я понял уже что первый скрин в этом сообщении неверный, т.к. клиента можно вообще убрать из диаграмм и сотрудника сделать внешним для системы актёром. А потом провести декомпозицию каждого ВИ. Сегодня уже 6 утра - завтра к вечеру постараюсь сделать ДД (почему-то у меня в StarUML они обозначаются как ActivityDiagram).