2086

Задачи студентов / Re: Курсовая работа

« : 26 Января 2011, 15:10:56 »

Вам следует внимательно изучить что такое ассоциация и зависимость. Без начального понимания дальнейшее движения весьма затруднительно.

Немного скажу.

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

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

В ОО программах чаще всего это ссылка на объект, атрибут типа . Например Ученик (класс: Класс)

Т.е. условно говоря, каждая линия на диаграмме соответствует наличию атрибута.

2087

Задачи студентов / Re: Курсовая работа

« : 25 Января 2011, 23:05:04 »

Мне во все не улыбается пересказывать здесь учебники, но что-это Вы тут нарисовали?

1. пунктирная стрелка - зависимость, стрелка указывает на класс, от реализации которого зависит класс, от которого пунктирная линия исходит
 т.е. читаем Участник системы зависит о реализации Обучающей системы
 Учреждение зависит от реализации Инспектора
 Ученик зависит от реализации Машины и т.д.

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

3.  Какой характер взаимодействия моделирует связь между Инспектором и Учеником? С какой целью Вы зафиксировали ее и обратили на нее внимание? Почему вам важно хранить во времени эту связь?

4. Связь между Участниками и Учениками на диаграмме объектов неоднозначна. Инспектор связан с Учреждением, а Наблюдатель не связан, на диаграмме классов этот факт исчезает, а его можно обыграть кратностью связи.

5. Исчез тот факт, что с одним Учеником связаны три Разных Участника системы

2088

Задачи студентов / Re: Курсовая работа

« : 25 Января 2011, 15:18:44 »

Диаграмма объектов - это диаграмма классов в ее конкретном мгновенном состоянии. Диаграмма объектов строится обычно для прояснения сложных моментов на диаграмме классов.

Отличие диаграммы объектов в том, что вместо ассоциаций там используются связи - экземпляры ассоциаций, имеющих на концах кратности равные 1. Соответственно - объект - экземпляр класса

Что делаем:
1. убираем наименования объектов и оставляем названия классификатора (но в единственном числе) - это класс
2. у каждого класса определяем атрибуты, убирая их конкретные значения
3. рисуем ассоциации - какие уже есть на диаграмме объектов
4. для каждого конца ассоциации определяем кратности, возможно уточням что это будет агрегация или композиция, возможно указываем квантификаторы и роли

размещаем здесь

2089

Задачи студентов / Re: Курсовая работа

« : 25 Января 2011, 13:48:43 »

1. где диаграмма объектов
2. после диаграммы объектов

2090

Примеры / Re: Пример диаграммы для описания функционирования формы

« : 25 Января 2011, 11:49:08 »

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

Для того чтобы описывать изменения состояний объектов в UML существует диаграмма состояний.
Форма - это как композитный объект, он содержит в своей структуре другие объекты имеющие свои состояния и правила перехода между ними.
Диаграмма последовательности мне кажется тут возможно, но вам придется делать их столько сколько возможных протоколов взаимодействия.

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

Весь вопрос - вам это действительно нужно? Может просто предоставить скриншоты форм с выделением ключевых моментов и оисанием порядка изменения, типа слайдшоу?

2091

Задачи студентов / Re: Курсовая работа

« : 23 Января 2011, 01:51:17 »

Тема курсовой "проектирование клиент-серверного приложения для тренажера иммитатора крана"Объект автоматизации это, получается, взаимодействие обучаемого и инструктора в процессе обучения.

Точно! Зачем вам что-то знать о лицензии? ведь это никакого отношение к программному обеспечению имитатора крана нет.

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

2092

Задачи студентов / Re: Курсовая работа

« : 23 Января 2011, 01:46:57 »

Договоримся считать системой преподавательский стол, а дальше - нет проблем: пинг-понг!

Дык, и я о том же самом. Всегда нужно указывать контекст, scope. Тогда я буду понимать Вас близко к однозначному.  Все условности возникают из разно понимаемых контекстов. Потому и следует говорить - вот вам моя условность в таком-то контексте...

Если интересно, я могу рассказать, почему использую термин "прецедент".

И почему термин RUP "Development Case" я перевел как "Адаптированный процесс". Скажи, где. Не для широкой публики!

1. в своем блоге
2. Но лучше в блоге сообщества

ps там и обсудим термин "прецедент", а причем тут development case, тоже объясните там

2093

Задачи студентов / Re: Курсовая работа

« : 22 Января 2011, 23:39:55 »

lnew, не хотел вас обидеть, если все-таки обидел, простите. Просто мне подумалось, что вы преподавали, и большинство студентов не сдают, а "спихивают" экзамен. Для меня (я преподаватель) такая картина (правда не массовая) знакомая.

Если ты не согласен с моими объяснениями первичности и вторичности, сверься с таким авторитетом, как RUP.

Я не выступаю против авторитета RUP, и не буду спорить, чтобы не уводить тему в другое русло обсуждения. Однако я считаю, что синтаксис, семантика и прагматика диаграмм использования предполагает, что вариант использования (прецедент по-вашему) это вариант использования чего-то (какой-то системы) и при использовании этой системы Первичным действующим лицом, она (эта система) может прибегать к услугам внешних ВТОРИЧНЫХ систем, для достижения цели ее использования первичным

2094

Задачи студентов / Re: Курсовая работа

« : 22 Января 2011, 22:38:08 »

Студент пришел на экзамен с целью "спихнуть".

У студента есть желание "столкнуть", наконец, экзамен.

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

У студента есть желание "столкнуть", наконец, экзамен.Его ассоциация первичная. Профессор сидит за столом и по мере сил "помогает" студенту сдать экзамен. Без его участия прецедент невыполним. Но он вторичный: у него нет цели принять экзамен.

Учебный центр обращается за лицензией (первичный), надзорный орган дает лицензию (за плату!) - вторичный.

[/quote]
В Ваших примерах и диаграмме топикстартера не хватает контекста. В зависимости от контекста Профессор и Надзорный орган могут быть как вне рамок систем, так и внутри нее.

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

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

2095

Обучение / Re: Дисциплина "Технология обработки информации"

« : 22 Января 2011, 17:29:44 »

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

2096

UML SysML и пр. / Re: Можно ли в диаграммах Use Case представлять DataBase как Actor?

« : 22 Января 2011, 15:29:05 »

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

Неа. Вы просто не догоняете, что такое ВИ. ВИ - это вариант использования как минимум одной сущностью (субъектом), другой сущности (объекта). Т.е. ВИ всегда предполагает 2 актеров, один указывается явно - Клиент, другой указывается контекстом-границей - Сервисный центр. При этом ВИ, указанные в границах этого контекста изображают ту ответственность (функциональность), которую ожидают от системы внешние заинтересованные лица. (мой ответ Вам смотрите во вложеии)
Скажите, что Вы как покупатель ожидаете от магазина, с какой целью Вы туда идете, какие функции с вашей т.зр. должен иметь магазин? Важно ли с вашей т.зр. как и каким образом магазин достигает ваши ожидания?
Теперь спросите себя как поставщика, что по вашему должен делать магазин? какой функциональностью обладать, какие ваши цели преследовать?
Если уж Вы решили описывать бизнес-контекст с помощью UML (а в этом нет ничего неожиданного, uml - это язык и вполне имеет средства для выражения вашей мысли), то вы должны описывать его именно с точки зрения предметной области бизнеса, не системной реализации
Нужен ли такой бизнес-анализ в вашем случае? Может быть и нет, хотя ничего не мешает этому. Далее для ВИ ремонт вы даете сценарий (прозрачный ящик) типа: клиент приносит технику для ремонта, сотрудник СЦ оценивает возможность и общую предварительную стоимость ремонта, Сотрудник СЦ принимает заявку и выписывает талон клиенту, заявка и техническое средство передается в отдел разработки. Когда ремонт завершен, сотрудник извещает клиента об этом. Клиент приезжает и забирает ТС и бла бла. Каждый из этих шагов может превратится в системные ВИ, ведь что есть СВИ - функциональное требование к системе: Зарегистрировать заявку, Проверить статус исполнения заявки, Отметить исполнение заявки и выдачу ТС, /Найти клиента, Найти заявку, Создать клиента ...../
Это уже будет предметная области ограниченная вашим приложением.

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

Естественно!

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

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

Кстати UML вполне подходит для рисования ЕR-диаграмм, более того если на диаграмме классов для ряда сущностей вы определите операции (а в смысле ER - это могут быть триггеры и хранимые процедуры, возможно функции определяемые пользователями, или некие алгоритмы которые будут исполняться на клиентском приложении), то вы частично опишите поведение, которое в дальнейшем можно развернуть с диаграммами активностей, диаграммами последовательности и состояний

2097

UML SysML и пр. / Re: Можно ли в диаграммах Use Case представлять DataBase как Actor?

« : 22 Января 2011, 00:26:15 »

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

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

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

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

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

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

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

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

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

2098

UML SysML и пр. / Re: Можно ли в диаграммах Use Case представлять DataBase как Actor?

« : 21 Января 2011, 17:18:08 »

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

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

2099

Примеры / Re: Пример диаграммы для описания функционирования формы

« : 21 Января 2011, 13:47:10 »

Диаграмма состояний - она же конечный автомат.

Способов много.

2100

UML SysML и пр. / Re: Можно ли в диаграммах Use Case представлять DataBase как Actor?

« : 21 Января 2011, 13:45:36 »

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

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

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

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

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