Решил часть свободного времени уделить самообучению - потренироваться в написании требований и проектировании ИС.

Хочется получить на выходе веб-приложение, которое бы собирало информацию о здоровье пользователей и как-то анализировало бы эту информацию. Яркий пример Google health.

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

документ designing_axa.rtf был создан в libreoffice. поэтому при открытии в других приложениях может что-то поехать.
документ use_cases.rtf был создан в Visual Paradigm и конвертирован из формата docx в rtf тем же libreoffice.

Возможно вы заметите странный последний шаг в основной сценарии каждого ВИ. это шаг пришлось создать чтоб инструмент VP корректно генерировал диаграмму активности для ВИ. почему то не удаётся выйти из расширения миновав основной сценарий.

А может ли система сама инициировать выполнение сценария, для достижения цели пользователя?

А может ли система сама инициировать выполнение сценария, для достижения цели пользователя?

ну обычно сама система этого сделать не может. она ведь не имеет свободы воли как таковая. Но она работает по событиям, а события могут инициироваться определенными условиями, временем и т.п.

кроме того, звучит старнно, что система инициируется сама для исполнения желания пользователя, она его предугадывает?

было бы конструктивнее, если бы вы написали примерчик

Например в теме http://www.uml2.ru/forum/index.php?topic=1659.15 обсуждался кодовый замок. Добавляем к системе проход по карточкам. Когда система включается она включает надпись "поднесите карточку". Поэтому пользователь до того как приложит карточку видит разрешающий сигнал.

В этом случае мы же не можем начать ВИ "Открыть дверь" так:
1. Система сообщает пользователю о готовности для получения уникального кода. ("Поднесите карту")
2. Пользователь посылает системе уникальный код(подносит карту)
3. Система подтверждает код и разрешает доступ

Правильнее будет так:
1. Пользователь посылает системе уникальный код
2. Система подтверждает уникальный код и разрешает проход

тогда как пользователь узнал что система готова? по предусловиям?

тогда как пользователь узнал что система готова? по предусловиям?

Да, именно. Ведь система демонстрирует надпись не только в тот самый, когда пользователю вдург захотелось пройти дверь.

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

Так что не появились у кого нить идеи по ДБО. Что-нить добавить/удалить может? Вот нужно ли рисовать потомков от врача, для разных специализаций? Есть ли у нас в предметной области, например врач стоматолог?

Так что не появились у кого нить идеи по ДБО. Что-нить добавить/удалить может? Вот нужно ли рисовать потомков от врача, для разных специализаций? Есть ли у нас в предметной области, например врач стоматолог?

На стадии ДБО Вы можете упражняться как хочется. По сути даже в названии "объекты" подразумевается это.

У меня вопрос:
- что Вы хотели сказать этой диаграммой?
- пациент и медицинская карта - это независящие друг от друга сущности?
- что есть медицинская карта?

Ответ на первый вопрос: это визуально представить предметную область, чтоб выявить классы системы.

пациент связал с мед картой ассоциацией

ну медицинская карта, это странная штука история болезней + рецепты врача + анализы. Наверно надо анализы и рецепты в отдельную сущность выделить.

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

Ответ на первый вопрос: это визуально представить предметную область, чтоб выявить классы системы.

Или ответьте классы какой системы? Или тогда диаграмма не верна.

пациент связал с мед картой ассоциацией

Думаю это правильно. Рекомендую все-таки использовать или имена ассоциации или роли конца асоциации для усиения семантики.

ну медицинская карта, это странная штука история болезней + рецепты врача + анализы. Наверно надо анализы и рецепты в отдельную сущность выделить.

Надо моделировать. Трудно сказать. Вообще все эти элементы можно объединить (например, назначения, или медицинские записи, поскольку что есть История болезни? Что есть факт Анализов и т.п. - медицинская запись в медицинской карте) Имхо. Книга есть Роберта Максимчука и ее одного товарища что то про разработку баз даных с помощью UML у них там как раз используется модель лечебного учреждения. Попробуйте поискать...

Не совсем понял назначение связей зависимостей. Например, Лекарство зависит от Врача??? Ну и т.п.

Просто ДБО помогает построить диаграмму классов.

Имена ассоциаций добавлю позже.

ER диаграмма БД уже построена. Но смысла выкладывать её пока нет, пока не решены вопросы с предметной областью. Хотя до сих пор я так и не решил делать 3 базы данных, отдельно для пользователей и групп, отдельно для информации о здоровье, и отдельно для планирования времени. Просто если сделать 3 базы повышается модульность системы, а если одну вроде немного вырастет скорость

Зависимость на ДБО поставил после прослушивания видеолекций Дениса Иванова. Там примерно было сказано так, что если не знаете какое отношение нужно поставить между сущностями, то можно поставить зависимость. Просто ещё не понимаю, какое между ними отношение.