Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => UML SysML и пр. => Тема начата: KJIaBogaB от 18 Января 2011, 13:07:42
-
Мой преподаватель в моем курсовом проекте сказал, что БД является частью ИС и при проектировании ИС нельзя делать коммуникации БД(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).
-
Верно. Я только хотел показать, что к нам доставляют СВТ. А ведь действительно, зачем это показывать, если это нас не касается...
Картинка Bussines_UseCase.jpg - так должна выглядеть ДБВИ ?
Неа. Вы просто не догоняете, что такое ВИ. ВИ - это вариант использования как минимум одной сущностью (субъектом), другой сущности (объекта). Т.е. ВИ всегда предполагает 2 актеров, один указывается явно - Клиент, другой указывается контекстом-границей - Сервисный центр. При этом ВИ, указанные в границах этого контекста изображают ту ответственность (функциональность), которую ожидают от системы внешние заинтересованные лица. (мой ответ Вам смотрите во вложеии)
Скажите, что Вы как покупатель ожидаете от магазина, с какой целью Вы туда идете, какие функции с вашей т.зр. должен иметь магазин? Важно ли с вашей т.зр. как и каким образом магазин достигает ваши ожидания?
Теперь спросите себя как поставщика, что по вашему должен делать магазин? какой функциональностью обладать, какие ваши цели преследовать?
Если уж Вы решили описывать бизнес-контекст с помощью UML (а в этом нет ничего неожиданного, uml - это язык и вполне имеет средства для выражения вашей мысли), то вы должны описывать его именно с точки зрения предметной области бизнеса, не системной реализации
Нужен ли такой бизнес-анализ в вашем случае? Может быть и нет, хотя ничего не мешает этому. Далее для ВИ ремонт вы даете сценарий (прозрачный ящик) типа: клиент приносит технику для ремонта, сотрудник СЦ оценивает возможность и общую предварительную стоимость ремонта, Сотрудник СЦ принимает заявку и выписывает талон клиенту, заявка и техническое средство передается в отдел разработки. Когда ремонт завершен, сотрудник извещает клиента об этом. Клиент приезжает и забирает ТС и бла бла. Каждый из этих шагов может превратится в системные ВИ, ведь что есть СВИ - функциональное требование к системе: Зарегистрировать заявку, Проверить статус исполнения заявки, Отметить исполнение заявки и выдачу ТС, /Найти клиента, Найти заявку, Создать клиента ...../
Это уже будет предметная области ограниченная вашим приложением.
Это именно мой случай. Тогда вообще от клиента можно избавиться в диаграммах, если я описываю систему, в которой клиент не учавствует ???
Естественно!
Ясно. Мой научный руководитель говорит, что этой ER-диаграммы вполне достаточно для части проектирования.
Все зависит от того, что вы понимаете под ER-диаграммой, что ваш преподаватель. Я под ней понимаю - статическую структуру. Сама по себе корректно созданная она определяет набор ограничений (а ограничения реально выводятся из требований): связи между сущностями, типы связей, типы процедур ссылочной целостности, ключи и доменные определения (включая дефолтные значения и правила ввода значений (маски, проверки, форматы)). Этого может быть достаточно в определенных случаях. Но ER-диаграмма не определяет поведение системы, она лишь может указать на ограничения такого поведения
Кстати UML вполне подходит для рисования ЕR-диаграмм, более того если на диаграмме классов для ряда сущностей вы определите операции (а в смысле ER - это могут быть триггеры и хранимые процедуры, возможно функции определяемые пользователями, или некие алгоритмы которые будут исполняться на клиентском приложении), то вы частично опишите поведение, которое в дальнейшем можно развернуть с диаграммами активностей, диаграммами последовательности и состояний
-
Всем здравствуйте!
Посмотрите пожалуйста мои варианты ВИ. Я думаю мне достаточно этого.
Или я (опять) вообще ничего не понял и мне лучше не делать UML (ООП), а проще описать структурным (IDEF0, DFD).
Долго не отвечал, т.к. иду с обратной стороны (писал приложение). В принципе, уже почти написал (есть ввод справочников (формы), ввод клиентов (формы с выбором данных из справочников и просто текстовый ввод), ввод средств вычислительной техники (СВТ) - тоже формы с выбором из справочников производителей, категорий и моделей и вводом серийников и инвентарников.
Форма оформления сервисного листа помогает выбрать(если оформлен) клиента; показать (если оформлял) СВТ, которые бывали в ремонте и закреплены за этим клиентом и ввести новую единицу, если в списке нет этой единицы; показывает выбранные (или введенные в момент оформления) клиента и единицу СВТ и позволяет заполнить остальные поля (контактную информацию и т.д.).
Теперь хочу сделать генерацию заявки на работу по сервисному листу (первоначальную - диагностика), и если понадобится что-либо делать - открывать новые заявки используя номер сервисного листа.
Я понимаю, что сначала идет проектирование, а уж потом реализация. Но я, к примеру, не пойму пока не реализую хотя бы раз (то есть пойти обратным путём) - а уж потом когда я буду себе представлять как реализуется то, что спроектировал - тогда буду в дальнейшем делать всё по-правилам :)
-
Забыл приаттачить картинки ВИ
-
Варианты использования - одна из форм представления функциональных требований к системе. В ВИ-ориентированных системах разработки, варианты использования или лучше сказать представление использования, играет центральную роль. Почему? Да потому, что ВИ это
- удобная единица декомпозиции функциональных требований к системе
- удобная единица планирования разработки
- это описание, которое может эффективно использоваться в хранении сведений (знаний ) о предметной области, согласовании с заказчиком, написании технологических инструкций и справок, использовании при составлении тестовых ситуаций
Но - это не все требования к системе. Т.е. одних ВИ недостаточно для проектирования системы. Это нужно учитывать.
Мне кажется последняя диаграмма (на другие я не обращаю внимание) не совсем корректна. Я вообще у вас не улавливаю разницу между БВИ и СВИ.
На самом деле ошибки есть
1. зачем демонстрировать уточняющие роли, что они дополнительного показывают? Другое дело, если бы Вы тем самым показали, что у разных ролей могут быть разные цели использования (ВИ)
2. Ввод информации о СВТ и ввод информации о клиенте - бессмысленен без оформление сервисного листа, вернее наоборот оформление всегда включает первые два действия, а смысл этой демонстрации?
3. связано с пунктом 1 - не показана дифференциация пользователей их целей - отсюда и ВИ использования системы не совсем внятные
4. а это связано с тем, что неясны цели использования системы, ее назначение
-
Но - это не все требования к системе. Т.е. одних ВИ недостаточно для проектирования системы. Это нужно учитывать.
Я это учитываю. Просто я показал пока только ВИ, потому, что нет смысла дальше двигаться не поняв ВИ.
Мне кажется последняя диаграмма (на другие я не обращаю внимание) не совсем корректна. Я вообще у вас не улавливаю разницу между БВИ и СВИ.
Я представляю себе СВИ, как варианты использования системы мной. Что бы я хотел делать с помощью системы.
Ну как я это вижу, так и показал... Другое дело что:
На самом деле ошибки есть
1. зачем демонстрировать уточняющие роли, что они дополнительного показывают? Другое дело, если бы Вы тем самым показали, что у разных ролей могут быть разные цели использования (ВИ)
2. Ввод информации о СВТ и ввод информации о клиенте - бессмысленен без оформление сервисного листа, вернее наоборот оформление всегда включает первые два действия, а смысл этой демонстрации?
3. связано с пунктом 1 - не показана дифференциация пользователей их целей - отсюда и ВИ использования системы не совсем внятные
4. а это связано с тем, что неясны цели использования системы, ее назначение
1. Вроде бы понятно.
2. Не знал. Почему-то думал, что именно так и надо показывать (уточнять). Теперь понятно.
3. Вроде бы понятно. Постараюсь переделать и показать что получилось.
4. Цели использования системы:
а)Открыть новый сервисный лист для внесения данных о клиенте, СВТ, причине обращения с возможностью печати копии для клиента.
б)Сформировать заявку на ремонт/обслуживание СВТ клиента по открытому сервисному листу.
в)Отслеживать сформированные заявки на предмет своевременного их выполнения.
г)Формирование отчетов для анализа эффективности выполненных работ
д)Сбор статистических данных.
Т.е. по пункту 3+4 можно сделать диаграмму СВИ, где актер зав.склад будет ассоциироваться к ВИ (д), а актер начальник будет ассоциироваться с ВИ (г) ?
-
4. Цели использования системы:
а)Открыть новый сервисный лист для внесения данных о клиенте, СВТ, причине обращения с возможностью печати копии для клиента.
б)Сформировать заявку на ремонт/обслуживание СВТ клиента по открытому сервисному листу.
в)Отслеживать сформированные заявки на предмет своевременного их выполнения.
г)Формирование отчетов для анализа эффективности выполненных работ
д)Сбор статистических данных.
Т.е. по пункту 3+4 можно сделать диаграмму СВИ, где актер зав.склад будет ассоциироваться к ВИ (д), а актер начальник будет ассоциироваться с ВИ (г) ?
Да, сейчас больше понятно, что должна делать система, какой функциональностью она должна обладать.
Иерархия ролей будет нужна, если каждая уточняющая роль может делать то, что делает более общая + нечто свое. Таким образом мы задаем разделение использования по ролям.
Что может делать абстрактный сотрудник?
Что может делать каждый сотрудник в указанной ролью?
Я бы составил табличку: Роль - Возможные ВИ
Из анализа таблички, можно было бы сделать требуемую иерархию
-
Здравствуйте.
Вот я и дописал приложение. Всё работает и радует глаз :)
Посмотрите пожалуйста ещё раз ВИ - можно ли эту ДСВИ оставлять в таком виде.
Заинтересованные лица:
1) Руководитель – желание знать кто, когда и сколько заявок выполнил по оформленным сервисным листам, как быстро, как качественно (т.к. повторные сервисные листы от одного клиента по одной и той же причине вероятнее всего говорят о некачественно выполненной работе).
2) Зав.склад – желание оперативно предоставлять отчеты руководству о находящихся на хранении единицах СВТ (готовые к выдаче после ремонта, ожидающих запчастей, списанных, полученных по распоряжениям для выдачи на новые рабочие места или замены существующим)
3) Технолог – желание оперативно отслеживать ход выполнения ремонта единиц СВТ по своей зоне ответственности за определенные рабочие места (для последующей установки и/или настройки дополнительного ПО).
4) Администратор СПД – желание оперативно отслеживать ход выполнения ремонта единицы СВТ для последующей настройки СВТ (ведь для работы в СПД необходимо ввести ПК в домен, установить антивирус, настроить сетевые подключения и т.д.)
5) Электроник – желание один раз оформить новую единицу СВТ и закрепить её за одним пользователем (чтобы в дальнейшем при оформлении в ремонт/обслуживание выбирать нужного клиента и его СВТ из списка оформленных ранее).
Ещё приложил ДД (так как я всё равно её сделал, чтобы сразу и оценили, можно ли в таком виде оставить). А ДА (диаграммой активности) её вообще нельзя называть? Или это просто старое название ДД ?
-
По поводу ДСВИ.
Если это системные варианты использования, то некоторые формулировки я бы все-таки изменил
Прием СВТ (не помню правда что такое С) - мне кажется так звучит бизнес ВИ, а на уровне системы Электроник что-то для этого делает
Проведение ТО и ремонта СВТ - это некий процесс, но не как не ВИ, это все-таки некоторая совокупность ВИ системного уровня...
Выдача СВТ - аналогично
Даже если сравнить с другими названиями ВИ бросается в глаза в одном случае информационность действия, а в другом материальность что ли :)
Далее... диаграмму можно сделать более понятной и обозримой
Электроник выполняет все ВИ кроме последнего
Руководитель, технолог и администратор - практически не отличаются, что странно
Завсклада делает 3 вещи из того, что делает электроник + тоже что и руковдитель
Можно поиграться отношением обобщения
-
По поводу ДСВИ.
Если это системные варианты использования, то некоторые формулировки я бы все-таки изменил
Прием СВТ (не помню правда что такое С) - мне кажется так звучит бизнес ВИ, а на уровне системы Электроник что-то для этого делает
Средства вычистительной техники. Долго мы к этому слову привыкали :)
Проведение ТО и ремонта СВТ - это некий процесс, но не как не ВИ, это все-таки некоторая совокупность ВИ системного уровня...
Выдача СВТ - аналогично
Видимо я что-то пропустил мимо ушей. Вы же мне уже советовали при оформлении сервисного листа не показывать include работы по вводу информации о клиенте и его СВТ. Я вывернул всё наоборот и показал прием и выдачу.
А надо наверное нарисовать ВИ:
1 - оформление сервисного листа,
2 - оформление наряда на выполение работ,
3 - отображение хода выполнения работ (или лучше написать фиксация выполненных работ),
2 - изменение статуса сервисного листа (закрываем сервисный лист когда все работы выполнены).
Эти ВИ касаются только электроников. По идее они могут иметь возможность сидеть в системе и смотреть информацию о клиентах, СВТ и в поисках прочих статистических данных, но зачем? Они же работают (ремонт и обслуживание СВТ). Пусть поиском нужных данных их анализом занимается руководитель группы.
Зав.склад мною изменен на руководителя группы, т.к. нет у нас зав.склада (это я уже тут выдумывать начал непонятно зачем). Выдает нам технику и запчасти девушка (мат.ответственное лицо) - вот для неё я и написал этот сайт, чтобы она могла нормально анализировать собранную информацию.
Даже если сравнить с другими названиями ВИ бросается в глаза в одном случае информационность действия, а в другом материальность что ли :)
Вроде бы понял ошибку. Исправил диаграмму.
Далее... диаграмму можно сделать более понятной и обозримой
Электроник выполняет все ВИ кроме последнего
Руководитель, технолог и администратор - практически не отличаются, что странно
Завсклада делает 3 вещи из того, что делает электроник + тоже что и руковдитель
Я поменял завсклад на руководителя группы и убрал отношения электроника и тех ВИ, которые относятся и к руководителю группы.
Можно поиграться отношением обобщения
А можно так оставить как на последнем слайде?
-
Немного исправил (там был ляп на слайде СДВИ) и добавил новый - декомпозицию ВИ - Оформить новый сервисный лист.
Посмотрите, что я опять не так делаю :)
Или ещё пока рано на декомпозицию замахиваться? (посмотрел пример курсовика Книжный магазин - там вообще нет декомпозиции СДВИ на ВИ - сразу ДД и ДП).
Вообще, хотелось бы знать Вашего мнения по количеству диаграмм разного рода.
Если я функциональные требования к системе выражу через ДСВИ, проведу декомпозицию каждого ВИ, сделаю для каждого ВИ свою ДП и для всей работы создам диаграмму классов и отношений между ними - этого может быть достаточно?
Попробовал ещё и диаграмму классов составить. Посмотрите пожалуйста нужно ли мне в диаграмму классов все экземпляры включать (которые я представил ранее на ER диаграмме - их 18) или же того, что я включил достаточно сейчас на ДК, т.к. это устойчивые классы, а остальные - это по сути справочники?
-
Вот, лично мне нравится такой вариант больше. По-моему, он в данном случае уже ориентирует нас на то, что должна делать система
Вторая диаграмма мне не совсем понятна. Это какой-то, как я понимаю, симбиоз. Вообще по РУП далее следует реализация ВИ: т.е. по каждому ВИ делается какой-то комплект реализующих его диаграмм (классов, коммуникации, последовательности и т.п.). Отображения форм, мне представляется лишним, потому как каждая линия коммуникации между актером и ВИ предполагает наличие какого-то интерфейса: графического пользовательского или программного.
Обычно это отображается на диаграмма реализации. Т.е. форма становится классом
Вопрос декомпозиции тем способом, что вы изобразили вызывает вопросы:
1. действительно ли каждый раз, когда оформляется сервисный лист вводится информация о клиенте и о СВТ
2. можно ли вводить информацию о клиенте и СВТ, не оформляя сервисный лист (на диаграмма говорится да)
3. если информацию о клиенте и свт можно вводит независимо, не означает ли, что при оформлении сервисного листа нужно найти уже введенного клиента и выбрать СВТ из его списка СВТ?
Так или иначе, все-таки не стоит перегружать ДВИ какой-либо сложной логикой. Главное наглядность и понятность. Поведенческие моменты лучше демонстрировать через конкретные сценарии
По диаграмме классов. Тут следует спросить себя, что я хочу передать этой диаграммой? Отвечает ли диаграмма на поставленную задачу? Не противоречит ли она другим диаграммам?
-
А вот так нормально будет, если оставить СДВИ без изменения?
-
Не влезли все изображения.
Кстати по поводу вопроса декомпозиции тем способом, что я изобразил:
============================================================================================
1. действительно ли каждый раз, когда оформляется сервисный лист вводится информация о клиенте и о СВТ
2. можно ли вводить информацию о клиенте и СВТ, не оформляя сервисный лист (на диаграмма говорится да)
3. если информацию о клиенте и свт можно вводит независимо, не означает ли, что при оформлении сервисного листа нужно найти уже введенного клиента и выбрать СВТ из его списка СВТ?
============================================================================================
1. А разве нельзя подразумевать, что даже если выбираешь информацию из выпадающего списка - всё равно она вводится в сервисный лист (в таблицу Service_list коммандой insert intо) ?
2. Да, можно.
3. Да - именно так.
-
1. А разве нельзя подразумевать, что даже если выбираешь информацию из выпадающего списка - всё равно она вводится в сервисный лист (в таблицу Service_list коммандой insert intо) ?
Это уже способ реализации. Т.е. что делает система когда вводится новый клиент? Запускается ВИ создать нового клиента, а как это будет реализовано, это уже второй вопрос, возможно у вас будут несколько разных вариантов.
Однако вводить клиента командой insert - это моветон на мой взгляд, такое допустимо для каких-то перечислений
-
Это уже способ реализации. Т.е. что делает система когда вводится новый клиент? Запускается ВИ создать нового клиента, а как это будет реализовано, это уже второй вопрос, возможно у вас будут несколько разных вариантов.
Про реализацию понятно. Но в целом, если я опишу и процесс создания нового клиента и новой единицы СВТ в одной из диаграмм последовательности для ВИ "Оформить сервисный лист" - это будет нормально? Вообще мои диаграммы последовательности верно направлены? Или я что-то грубо нарушаю?
Нужно ли Добавление клиента и добавление СВТ показать на СДВИ? Ведь эти пункты являются составной частью ВИ - Оформление сервисного листа. Отдельных пунктов в меню сайта у меня нет, но есть возможность выбрать эти пункты из формы оформления сервисного листа.
Однако вводить клиента командой insert - это моветон на мой взгляд, такое допустимо для каких-то перечислений
Возможно я не так выразился.
Insert добавляет в таблицу сервисного листа только индекс клиента (id). Сами данные клиента вносятся в таблицу Клиента.
Или я что-то не так понял? Почему моветон? Можно как то по другому добавлять данные в таблицы помимо комманды insert ?
-
Про реализацию понятно. Но в целом, если я опишу и процесс создания нового клиента и новой единицы СВТ в одной из диаграмм последовательности для ВИ "Оформить сервисный лист" - это будет нормально? Вообще мои диаграммы последовательности верно направлены? Или я что-то грубо нарушаю?
Вообще мне они показались мало полезными. Поскольку Вы проектирует, а не просто рисуете, то каждая модель должна отвечать на вопросы и продвигать вас к ясному решению. Мне кажется диаграммы последовательности должны писаться в некотором "программистком" стиле в терминах реакции системы, т.е. системных событий операций и реализаций этих операций.
Нужно ли Добавление клиента и добавление СВТ показать на СДВИ? Ведь эти пункты являются составной частью ВИ - Оформление сервисного листа. Отдельных пунктов в меню сайта у меня нет, но есть возможность выбрать эти пункты из формы оформления сервисного листа.Возможно я не так выразился.
Тут следует исходить из принципа минимальности. Если все и так понято, зачем прегружать
Хотя в вашем случае, если нет отдельных пунктов, значит нет конкретных ВИ, т.е. эти ВИ запускаются только при выполнении некоторого базового, но тут ведь возможны ситуации по условию:
1. клиента нет - добавить нового - выполняем ВИ, это расширение
2. клиент есть - ищем клиента - выполняем ВИ, возможно всегда, тогда включение
Но в целом это не важно. Вы же один работаете, другое дело, когда нужно распределять работу. Кроме того возможно поиск клиента может иметь самостоятельное значение в других местах
Insert добавляет в таблицу сервисного листа только индекс клиента (id). Сами данные клиента вносятся в таблицу Клиента.
Или я что-то не так понял? Почему моветон? Можно как то по другому добавлять данные в таблицы помимо комманды insert ?
На самом деле это исполнение не поддерживаемой стандартной процедуры ссылочной целостности. Если у вас нужно выбрать клиента, а его нет в списке, вы конечно можете сделать триггер на вставку новой записи по заявке или процедуру на изменение в поле комбо, когда добавляет нечто и система автоматом делает инсерт в таблицу Клиент, возвращает полученный id и рефрешить запрос по комбо.
Возможно этого достаточно, если требуется только добавить ФИО, а если адреса, контактная информация, именование орагнизации, паспортные данные и т.п.? Конечно все можно свести в одну форму и при кнопке сабмит все аккуратно запросом раскладывать по таблицам. Особенно если вы используете MyISAM MySQL , то поддержание целостности и непротиворечивости лежит на плечах вашего скрипта
Понятно я объяснил? К тому же следует учесть и сеансовость работы через веб
-
Переделал ДП для ВИ "Оформление сервисного листа". Показал возможность выбора из списка как клиента, так и зарегистрированных на него единиц СВТ..
Прикрепил скрины с моего сайта, чтобы показать, как я ввожу и выбираю клиента.
Ссылочная целостность у меня работает. Таблицы InnoDB. Поддержание целосности лежит на скрипте (проверяется отсутствие одинаковых записей перед добавлением нового клиента, модели СВТ, Новой Единицы СВТ и т.д.). Для этого и сделаны формы ввода в справочники моделей, категорий, брэндов, организаций, городов, должностей и т.д.).
Удаляя из справочника строчку должности - удаляются и все записи где использовалась эта должность. Изменяя её в справочнике - меняются все данные. Следовательно On Delete Cascade и On Update Cascade работают.
-
По поводу выбора клиента из комбика.
Типичная ошибка начинающего программера. Я понимаю проект учебный, но
если у вас будет много, очень много клиентов. Ну не меньше несколько сотен, Вы их тоже все будете загонять в комбик? А сам список как формируете, вероятно прямо на браузер клиента портируете весь список чухом?
Хорошо если вы продумали такое поведение датасета, при котором происходит подгрузка данных по мере движения в комбике
-
дааа, не самое лучшее интерфейсное решение. много вопросов возникает: как найти клиента, что делать с группировкой клиентов, да и просто долго выбирать из такого списка.
я бы предложил посмотреть на то, как организован интерфейс выбора авторов на lib.rus.ec
-
По поводу выбора клиента из комбика.
Типичная ошибка начинающего программера. Я понимаю проект учебный, но
если у вас будет много, очень много клиентов. Ну не меньше несколько сотен, Вы их тоже все будете загонять в комбик? А сам список как формируете, вероятно прямо на браузер клиента портируете весь список чухом?
Хорошо если вы продумали такое поведение датасета, при котором происходит подгрузка данных по мере движения в комбике
В комбик я подгружаю чухом данные из таблицы клиентов. Всего клиентов не более 1500 из которых наверняка всех никогда не зарегистрируем.
С другой стороны я подумал об этом перед реализацией. Я проверил возможность выбора из всего этого списка по первым набранным буквам. Вываливается список, жмакаешь и тут же курсор выделяет нужные фамилии. Вообще Вы верно заметили - учебный проект. Я переделаю исходя из предложений, пожеланий коллег. Я вообще по ходу написания изучал php, html.
я бы предложил посмотреть на то, как организован интерфейс выбора авторов на lib.rus.ec
Спасибо за предложение. Я после защиты обязательно займусь дальнейшим изучением предмета. Мне всегда это всё нравилось. Да и хватит пользоваться трудами других и не знать как это всё работает изнутри. Нужно уже и самому в жизни что-то сделать! :)
ЗЫ: да и добавить форму поиска клиента не проблема. Самый наверное простой вариант, который я и реализую позже.
-
По поводу выбора клиента из комбика.
Типичная ошибка начинающего программера. Я понимаю проект учебный, но
если у вас будет много, очень много клиентов. Ну не меньше несколько сотен, Вы их тоже все будете загонять в комбик? А сам список как формируете, вероятно прямо на браузер клиента портируете весь список чухом?
Хорошо если вы продумали такое поведение датасета, при котором происходит подгрузка данных по мере движения в комбике
Я например всегда через поиск делал вывод из больших справочников, по первым буквам фамилии например, потом давал соответствующий LIKE в SQL запросе, и уже тащились на клиента не все записи из справочника.
-
Я например всегда через поиск делал вывод из больших справочников, по первым буквам фамилии например, потом давал соответствующий LIKE в SQL запросе, и уже тащились на клиента не все записи из справочника.
Ну примерно так и я хочу сделать.. Спасибо за подсказку.
Я вот другого не понял:
Однако вводить клиента командой insert - это моветон на мой взгляд, такое допустимо для каких-то перечислений
всё же моветон клиента так вставлять, как я реализовал? Или у меня нормально?
Я коммандой insert вставляю в таблицу клиента текстовые поля (ФИО), а организацию, тип клиента, местонахождение, должность - вставляются значения внешних ключей соответствующих родительских таблиц (выбранных из комбиков).
Подробнее рассказать можете где что не так?
-
Я вот другого не понял:всё же моветон клиента так вставлять, как я реализовал? Или у меня нормально?
Я коммандой insert вставляю в таблицу клиента текстовые поля (ФИО), а организацию, тип клиента, местонахождение, должность - вставляются значения внешних ключей соответствующих родительских таблиц (выбранных из комбиков).
Подробнее рассказать можете где что не так?
как показано на ваших скриншотах - нормально. Это по сути отдельный ВИ, который вызывается в Вашем случае, только из документа оформления заявки. Это хорошо, это не моветон
моветоном я бы считал такое действие (а так иногда делают)
нет клиента - в комбике ввести фио, по событию выхода или принудительно жамкая на рядом кнопочку делаем insert, получаем новый id, обновляем список, подставляем новое ФИО в форму
моветоном я считаю получения списка клиента в выпадающем списке - это нормально для однопользовательских десктопных систем с очень ограниченным списком
для вебприложения, для больших списков комбик не очень подходит. Для этих целей лучше некий компонет с кнопкой выбора, которая запускает некую поисковую форму или компонент с "интеллектуальной подгрузкой", т.е. вы вводите фио или ее часть, посылается запрос на сервер, если результат запроса 1 запись, производится подстановка ФИО и заполнение других данных формы, если возвращается несколько записей, отображается этот список из которого Вы и выбираете. Хотя тоже следует предусмотреть ситуации когда и таким образом можно получить слишком большой список
-
Спасибо всем за советы, помощь и предложения.
Защитился на 5. Рекомендовали поступать в аспирантуру.
Я конечно понимаю, что уровень не тот, но всё равно очень приятно...
-
Поздравляю! Это хорошо. Помните, UML не простой язык, разработка ПО - сложный многообразный процесс. Обучиться можно только долго и постоянно практикуя.
Вы встали на начала пути. Найдите силы и мотивы для его продвижения. Это того стоит!
-
Поздравляю! Это хорошо. Помните, UML не простой язык, разработка ПО - сложный многообразный процесс. Обучиться можно только долго и постоянно практикуя.
Вы встали на начала пути. Найдите силы и мотивы для его продвижения. Это того стоит!
Я сейчас пойду по верному пути - сначала изучу UML, т.к. его ещё изучать и изучать. Хочу связать все ниточки процесса проектирования приложения от прецедентов до кодогенерации. А то диаграммы классов вроде бы аналогичны диаграммам ER, но это далеко не весь их функционал. Так же и с остальными диаграммами. Ещё и шаблоны для меня пока темный лес. Но я интуитивно понимаю для чего они нужны, но нужно вникать.
Начал пролистывать книгу Нейштадта и Эрлоу (по памяти пишу могу ошибаться) - нашел интересный пример того, как не нужно показывать диаграммы прецедентов. Сразу вспомнил свои диаграммы :)
Вообщем ещё учиться и учиться.
Я загорелся этим делом. Всегда мечтал программировать (ну и сейчас осознаю, что и проектировать) - но затянула "обслуга" вычислительной техники и сетей передачи данных так, что забыл про все свои мечты. А тут уже 30 лет и надо что-то для себя решать :) Решил.