Мне кажется, нет. Если задача состоит в описании бизнес процессов сервисного центра, то границы и есть сам сервисный центр, а актеры
сосредоточенные вокруг него - это внешние сущности: клиенты, поставщики, партнеры и т.п., которые заинтересованы во взаимодействии с центром и
имеет какие-то цели, достижение которых центр обеспечивает.
В этом случае у клиента нет цели Доставить СВТ, а есть цель Отремонтировать СВТ.
Верно. Я только хотел показать, что к нам доставляют СВТ. А ведь действительно, зачем это показывать, если это нас не касается...
Картинка 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).
Просмотр сообщений
