3301

Примеры / Re: Выполнение примера описания требований для ИС "Аттестации Студентов"

« : 02 Июля 2009, 14:23:33 »

ВИ 02. Управлять правами пользователей - Назначить уровень доступа, роль

ВИ 01. Управлять пользователями
Роли: администратор
Краткое описание: Администратор создает роли и пользователей в Системе
ИМХО - два разных ВИ-процесса. Формирование ролей (или формирование уровней доступа) и Управление пользователями куда может войти и ВИ02: создать учетную записб, редактировать учетную запись (в том числе назначить роль), заблокировать, удалить и т.п.

ВИ9 и 10 скорее всего будет объединен, нужно прописать и понять в будущем

ВИ 07. Получить учебные материалы
Роли: студент
Краткое описание: Студент авторизуется в Системе, после чего ему предоставляется доступ к учебным материалам по различным дисциплинам с учётом ограничений доступа, установленного на данные материалы Преподавателем.
Следует добавить, что материал предоставляется в соответствии с учебной программой или учебным планом

Администартор и Преподаватель - не является сотрудником вуза?

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

Но сначала думаю следует утрясти сами ВИ

3302

Sparx / Re: проектирование БД в Enterprise Architect

« : 01 Июля 2009, 19:17:40 »

к сожалению, речь идёт не о трансформациях, а о проектировании схемы БД "с нуля". А, как уже описывалось выше, это делается руками очень медленно, что неприемлемо...

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

я сказал вам, что делаете модель классов и ЕЕ трансформируете в модель данных со всеми первичными вторичными ключами и т.п.

к тому же - а зачем вам ЕА - делайте это в ЕРвине или бесплатных инструментах для DB дизайна

3303

Sparx / Re: проектирование БД в Enterprise Architect

« : 01 Июля 2009, 17:32:06 »

Вы имеете ввиду генерацию в DDL-скрипт? но пока об этом рано говорить. Речь идёт просто о том, чтобы "с нуля" нарисовать схему БД в EA

нет я говорю не о длл а MDA трансформации

3304

Sparx / Re: проектирование БД в Enterprise Architect

« : 01 Июля 2009, 14:23:39 »

Есть смотрите Project Transformations

3305

Проектирование / Re: Проектирование классов

« : 01 Июля 2009, 14:17:35 »

Есть у меня определенное ощущение, что цель искусственна.

да цель искусственна

P.S. Кстати, если Ваш интерес связан с реализацией подобного автоматического преобразователя, то это похвально, но, по-моему, сейчас бессмысленно.

нет - цель пока только чисто познавательная и учебная.
Еще раз повторюсь связь в БД формируется ограничениями, связь в ООЯ формируется другими способами - вот и хотелось бы узнать ретроспективу этих способов

3306

Проектирование / Re: Проектирование классов

« : 01 Июля 2009, 11:32:37 »

Водолей, спасибо. Очень интересно все это, но может начнем с науки.

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

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

Рассуждения таковы:
1. Клиент - Заказ
  Клиент трансформируется в таблицу Клиенты (КодКлиента(ПК), ФИО(Not Null), Адрес(Not Null))
  Заказ трансформируется в таблицу Заказы(НомерЗаказа(ПК), Дата (Инверсный ключ, Поумолчанию- Now()), КодКлиента(ВК))
  Отношение неидентифицирующее. Минимальная и максимальная кардинальность на стороне таблицы Клиенты - 1
  Минимальная кардинальность на стороне Заказы = 0, Максимальная - много
  Процедуры поддержания целостности: тригеры на стороне родителя Каскадное обновление каскадное удаления

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

Аналогично я бы хотел иметь правила преобразования аналитической модели в проектную и некую начальную структуру классов (скелет классов). Тут вариантов больше согласен, но их не бесконеное множетсво и всегда можно объяснить почем так а не иначе добавив в начале Если, то

3307

Проектирование / Re: Проектирование классов

« : 30 Июня 2009, 23:47:23 »

Водолей, я согласен со всеми Вашими словами.

За исключением практики. Действительно серьезной практики ООП нет.

Давайте опишем контекст следующими ВИ:

Разместить заказ (клиент)
Просмотреть статус заказа (клиент)
Выполнить заказ (некий менеджер)

Товары будем полагать для простоты в неограниченном количестве

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

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

3308

Проектирование / Re: Проектирование классов

« : 30 Июня 2009, 21:51:52 »

Или я чего-то в Ваших исканиях опять не понял?

Чего-то наверное не поняли

Меня интересуют пока вопросы трансформации.
Есть скажем ассоциация 1-ко-многим между двумя классами - ассоциация аналитическая.
Далее мы должны ее превратить в то что возможно будет в коде.

Скажем связь двунаправленная, тогда в классе на стороне 1 появится некий атрибут типа массив или атрибут класса типа коллекция, а в класе на стороне много - объектная ссылка или указатель на класс со стороны 1

Если свзяь направленная вопрос а как правильно направлять - какая логика.
Пусть направление от класса 1 к классу много, следовательно нужно обеспечить видимость объектов класса много из объектов класса 1 - это либо массив либо класс коллекция

Если нужно что-то внести дополнительное в модель - давайте внесем - скажите только, у меня же пробел

3309

Проектирование / Проектирование классов

« : 30 Июня 2009, 20:48:13 »

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

Построить аналитическую модель классов не составляет труда. Но при переходе к проектной модели, а дальше к реализации, причем последнее очень важно, возникает сказанное выше.

Читаешь книги, понимаешь, что написано, даже вроде реализуешь, но все не то.

Потому прошу помощи по этому вопросу.

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

Пусть существует Клиент, который может делать множество заказов.
В каждом заказе можно заказать один или множество товаров
Один и тот же товар может быть заказ много раз в разных заказах

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

В результате получается например модель1

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

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

Спасибо

3310

UML SysML и пр. / Re: Вопрос по диаграмме деятельности

« : 30 Июня 2009, 13:28:57 »

Насколько уместно показывать такую связь при считывании файла (см. вложение)?

Неуместно, но можно использовать объектный узел - object.node

3311

Сообщество Аналитиков / Re: Компетенции аналитика (профессиональные и личностные)

« : 29 Июня 2009, 21:24:53 »

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

Что такое аналитик:
1. человек энергичный, болеющий за свое дело, но умеющий быть хладнокровным и трезвомыслящим
2. человек стремящийся понять нужды клиента, придумать как их можно устроить
3. человек влюбленный в своего клиента, потакающий ему, но вместе с тем умеющий успокоить, найти приемлеммое разруливание "стрессовой" для клиента ситуации в рамках текущих возможностей
4. человек продвигающий выполнение работ, созданных им в ходе взаимодействия с клиентом. Домагающийся до проектировщиков и программистов
5. человек с чувством собственного достоинства, но не обуяный гордыней
6. человек который не забывает об интересах своей фирмы-кормилицы
7. обладающий чувством юмора, оптимист

ну как-то так можно и продолжить:)

3312

Обсуждение статей / Re: Включение вариантов использования

« : 29 Июня 2009, 20:05:31 »

Ты меня успокоил, поскольку я так это и понимал

3313

Обсуждение статей / Re: Включение вариантов использования

« : 29 Июня 2009, 17:45:39 »

The OMG UML specification (UML Superstructure Specification, v2.1.1, p. 591) states:

Include is a DirectedRelationship between two Use Cases, implying that the behavior of the included Use Case is inserted into the behavior of the including Use Case. It is also a kind of NamedElement so that it can have a name in the context of its owning Use Case. The including Use Case may only depend on the result (value) of the included Use Case. This value is obtained as a result of the execution of the included Use Case.

А вот смотри, тут явно использовано слово - направленное отношение. Заметь, не зависимость, хотя дальше мы видим, что включающий ВИ может зависеть от результата включаемого. Интересна мысль по поводу МОЖЕТ зависеть

3314

Обсуждение статей / Re: Что такое метакласс и как его использовать?

« : 29 Июня 2009, 17:41:47 »

Может будем делать ревью какое-то перед публикацией?

Имеешь в виду - зачем это нужно? Если так - было бы здорово

3315

Обсуждение статей / Re: Как можно определить насколько один инструмент моделирования совместим с другим?

« : 29 Июня 2009, 17:09:06 »

Опять же, что касается русского языка и грамматики. В темах форума можно допустить ошибки и описки. Но в статье следует быть очень внимательным.

Тема должна называться так: Как можно определить, насколько один инструмент моделирования совместим с другим? т.е. тут налицо два сложноподчиненных предложения: Как можно определить (союз насколько) и инструмент совместим ...