3481

Примеры / Re: Бакалаврская работа

« : 24 Апреля 2009, 22:33:30 »

Я понял вопрос Эдуарда по-другому. Для меня вопрос прозвучал так - правда ли, что ни у какого другого (похожего) завода нет такой площадки? Если да, то этот завод - новатор. Иначе - нет.

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

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

3482

Sparx / Re: Enterprise Architect: плюсы и минусы, жалобы и восхищения

« : 24 Апреля 2009, 22:22:12 »

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

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

3483

Sparx / Re: Enterprise Architect: плюсы и минусы, жалобы и восхищения

« : 24 Апреля 2009, 12:22:42 »

Вот попробовал поработать в Visual Paradigm.


Сделал
1. диаграмму активности
2. диаграмму юзкейсов
3. диаграмму классов

Предположим есть диаграмма юзкейсов. Из Model Explorera кидаю на диаграмму класс 1, раз, два три - кидается, ничего не говорит. Зер гуд. То что вы веротяно ждете. Далее. Рисую связи от класс 1 к классу 1 и еще к классу 1

Делаю диграмму классов, переношу, кидаю туда класс 1. Сразу образуются self-ассоциации ровно три штуки. Замечательно

Беру диаграмму активности: создаю пару активностей, кидаю класс 1 раза 4. Создаются ровно 4 объекта.

Внимательно смотрю на элеенты модели и что вижу? Объекта как такового нет - это Object Node причем двух разных типов Central Bufeer Node и Data Store Node

Те объекты что я создавал из класс 1 на самом деле теже самые Object Node. У них даже есть тип сортировки накапливаемых объектов.
Далее беру создаю еще один Object Node. Мышкой вытаскиваю его с Model Explorer раз 5. Задаю одному из них состояние.
Все другие клоны имеют тоже самое состояние

3484

Sparx / Re: Enterprise Architect: плюсы и минусы, жалобы и восхищения

« : 24 Апреля 2009, 11:09:10 »

Есть вопрос. А если я хочу показать те действия, которые переводят объект-сущность из одного состояния в другое? Пример, который вы приводите ниже с состояниями, с ним также я не согласен. Состояния "Зарегистрировать" и "Рассмотреть и подписать" не корректно именуются, "На регистрации" и "На рассмотрении и подписании" тогда уж. "Зарегистрировать" и "Рассмотреть и подписать" действия.

То что я привел - лишь пример, не имеющий к реальности никакого отношения. Чего его обсуждать?
Кроме того - это не состояния "Зарегистрировать" и "Рассмотреть и подписать", а деятельности или действия. Понимаете разницу?

Хм, у меня другое представление об объекте. Обратимся, в качестве одного из примеров, к описанию объекта в самом хелпе EA:
"An Object is a particular instance of a Class at run time. For example a car with the license plate AAA-001 is an instance of the general class of cars with a license plate number attribute."
Под объектом я понимаю конкретный образец класса (конкретную машину с номером AAA-001), а не некоторое совокупное понятие для всех объектов классификатора (именно так я прочитал вашу мысль). На мой взгляд объект есть конкретный единичный объект классификатора.

Да и ради бога, и флаг вам в руки.
Мы с вами о чем говорим? О применении объектов на диаграмме деятельности. Мы не обсуждаем диаграмму объектов.
Диаграмма объектов имеет занчимость для анализа и уточнения структуры диаграммы классов.

А вот когда мы говорим об объектах и объектных потоках на ДД, то объект там имеет несколько иной смысл. Который я вам пытаюсь передать - смотрите книгу Арлоу и Нейштадта UML2 и унифиуированный подход.

Забавно то, что EA я использую для бизнес-моделирования и начальной постановки задачи. Перешел на EA с Rational Rose, пытаюсь применить те методы, которые использовал с успехом там (и которые собирал по крупицам из инета и прочих статей и книг).
Почему же в Rational Rose это одинаковые квадратики?

Так пользуйетсь в этом случае привычным инструментом. Это раз
Обращайтеся к производителю ЕА - это два.

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

3485

Идеи и мозговой штурм / Re: Тематические анекдоты и смешные истории

« : 23 Апреля 2009, 22:51:29 »

да разумеется во всем виноват бог, который придумал этот мир

А Бог винит во всем idu (шутка)

3486

Sparx / Re: Enterprise Architect: плюсы и минусы, жалобы и восхищения

« : 23 Апреля 2009, 22:50:06 »

что такое "клинируете..."?

Опечатка - клонируете

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

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

В диаграмме этой я использую конкретный неименной объект, классификатором которого является "Заявление на отпуск". Так почему я не могу ОДИН и ТОТ же объект показать 2 раза на диаграмме, при этом в первом случае он будет находиться в состоянии "пустой бланк",а в другом "утверждено"? Как я понимаю, объект ассоциируется именно с конкретным экземпляром (читай бумажкой) заявления, и именно этот экземпляр может иметь состояния как пустого бланка, так и потом ОН ЖЕ (ОН ЖЕ, то есть это не будет другой объект) будут подписан.

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

Т.е. Заявление на отпуск [Предложено] - Зарегистрировать - Заявление на отпуск [зарегено] - Рассмотреть и подписать - Заявление на отпуск [Подписано].

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

P.S. Хотел спросить вас - согласны ли вы с тем, что один объект может быть только в одном состоянии его классификатора? Спрашиваю, так как пытаюсь понять схему вашего мышления...

Конечно, одновременно объект может быть только в одном состоянии его классификатора. Однако следует понять, что состояния не у класса, а у объекта. Объект меняет состояния. Состояние это конкретное значение атрибута, например. Класс не имеет конкретных значений

Мой ход мыслей следующий.

Класс в пределах пакета - уникальная сущность (хотя ЕА позволяет создавать сколько угодна классов с одинаковыми именами, что мне не нравится), т.е. по классике класс с именем А в пакете один.
В другом пакете может быть класс с тем же именем.
В любом случае в пределах некой системы класс- уникален - это полный аналог файла в файловой системе.
Имя класса - это не только его имя, но и имя всех пакетов в которые он входит иерархически

Аналогия с файлами и файловой системы бесподобна

Вы хотите создать ссылку на какой-то классификатор многократно в одной и той же диаграмме (читай в одном и том же пакете, папке каталоге). Но ссылка это тоже классификатор.

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

Мое мышление говорит мне ЕА - это инструмент проектировщика, а не художника. Но даже для художника, два разных квадратика хотя бы и с одинковыми именами - это два РАЗНЫХ квадратика.

Я все сказал

3487

Sparx / Re: Enterprise Architect: плюсы и минусы, жалобы и восхищения

« : 23 Апреля 2009, 13:17:12 »

(либо я чего то не понимаю...)

Вот ключевая фраза

Вот давайте рассуждать. Есть некий объект - экземпляр некоего класса, который меняет состояния.
Нам нужно отобразить три состояния этого объекта.
1. для этого есть диаграмма состояний
2. интересно как для одного и того же объекта (в смысле как некий фиксированный элемент графический) отобразить три разных состояния имея только один такой элемент на диаграмме. Да же если вы его клинируете ссылаясь на 1 объект, то почему вы считаете, что изменение состояния в одном месте не должно приводить в этом случае в другом?

3488

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

« : 23 Апреля 2009, 13:13:51 »

veta.

до первой контрльной точки состоится 7 занятий. 1 задание на 2 занятий. Т.е получаем 3,5 заданий. Т.е. к контрольной точке будет выполнено и нужно отчиться за 3

3489

Sparx / Re: Enterprise Architect: плюсы и минусы, жалобы и восхищения

« : 23 Апреля 2009, 09:45:51 »

Эд, реально нужно использовать два экземпляра одного и того же элемента на Д. Наример, рисуем Д БП, одно действие или составное действие используется несколько раз на Д с входами и выходами на разные Действия, получается нам нужно создать несколько элементов вместо того чтобы использовать все время один и тот же элемент и изменять его свойства в одном месте.

Тут либо наше непонимание концепции UML, либо явное ограничение ЕА по своей внутренней модели.
Мне кажется нужно внимательно понять что ты хочешь от диаграммы и почему как ты хочешь сделать может быть неправильным. Пока мне сложно ответить так как нет картинки

3490

Sparx / Re: Enterprise Architect: плюсы и минусы, жалобы и восхищения

« : 22 Апреля 2009, 20:36:28 »

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

Прекрасный момент спросить, а правильно ли сделали диаграмму в таком случае? Если у вас возникла подобная проблема и вы не можете ее решить визуальными средствами как вам хочется, может посмотреть на ситуацию с другой стороны?
Нужна ли тогда подобная диаграмма?
Лично для меня обильное количество повторяющихся акторов только бы отвлекало от сути. Поймите. Диаграмма юзкейсов не имеет никакого практического значения, кроме как некоего оглавления, перечисления набора функций.
При этом все акторы по сути в дальнейшем нам не будут нужны вовсе, они за кадром, они те для кого мы делаем систему.
Если Вам нужно изобразить то, что Вы хотите используйте объекты, инстансисы. Это же просто изобразительное искусство и никакого значения на разрабатываемый продукт не имеет.
Так стоит ли копия ломать?
Причем а какие сложности показать 15 юзкейсов и двух актеров??
посередки юзкейсы - побокам два актера, линии хорошо ломаются и выстраиваются очень красиво и аккуратно веером

И все-таки я не понимаю, почему отображение одного классификатора на одной диаграмме не может быть дважды и более? Про ваше выражение "Актер, юзкейцс или другой элемент на модели, должен быть уникальным" - согласен абсолютно, только эта уникальность должна достигаться уровнем браузера проекта, а на диаграмме для удобства представления пользователю должна быть дана возможность отображения классификатора или его объекта произвольное количество раз, что мы и наблюдаем в таком продукте, как rational rose.

Так и пользуйтесь на здоровье розой, кто запрещает?
на мой же взгляд все абсолютно логично . Возможно со временем (хотя уже 7 версия чего было ждать) ЕА сделает вам такую фичу. Мне она ни разу почему-то не понадобилась. Если у вас такая трудность сделайте две разные диаграммы в разных пакетах, надеюсь будет вам

Про использование объектов классификаторов - то есть на каждое отображение актера делать новый объект от классификатора?

Ну именно это я и сказал по-моему?

3491

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

« : 22 Апреля 2009, 20:27:29 »

После бурных обсуждений с нашим менеджером  возникли вопросы к заказчику:
Верно ли :
1. Занятие является элементом Графика прохождения учебного плана?
2. График прохождения учебного плана - это по сути расписание занятий?

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

3492

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

« : 22 Апреля 2009, 20:24:51 »

Рейтинг - это по сути отчет по данным? Не знаю имет смысл его прилплять или нет.

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

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

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

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

1. кт№1 - нужно набрать 16 баллов. Студент набрал 10
2. кт№2 - нужно в сумме набрать 34 балла, по разнице можно добрать 18 баллов,т.об студент должен набрать не более 28 баллов и т.п.

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

На счет Графика прохождения и Контрольных Точках подумаем отдельно как их обозначить на Д, пока предлагаю оставить их на Д, но не связывать ни с чем.

сам график не нужен, достаточно расписания занятий, которое вколачивается либо самим преподом, либо работником учебного отдела.
Преподаватель должен определить максимальное число баллов за занятие, какие занятия будут включаться в контрольную точку. Поясню. Пусть за период между контрольными точками 7  занятий, при это на седьмом занятии студенты получают 4 задание на исполнение, ясно, что они еще не успеют выполнить задание к контрлльной точке, т.к. отчетное занятие будет после.
Пусть каждое занятие оценено в 4 балла, тогда к контрольной точке нужно сдать работы на 3*4 = 12 баллов
Я вообще ставлю 1 балл за то, что человек уже присутствовал. Т.е. отсуствующий получает как бы -1 балл. Это стимулирует не колоть занятия. Скажем пропустил все 18 занятий сразу получаешь минус 18 из 50, итого только 32 балла, даже если работы все сдал на сверх отлично, все равно. Тут я обычно сразу предупреждаю стуентов о правилах игры: тот кто по тем или иным соображением не ходят на занятия но не хочет потерять баллы должны брать индивидуальные дополнительные задания, поскольку на своих занятиях я много чего даю, а те кто не ходят часть этих знаний теряют

3493

Sparx / Re: Enterprise Architect: плюсы и минусы, жалобы и восхищения

« : 22 Апреля 2009, 13:31:10 »

Коллеги, почему я могу использовать только один instance одного элемента на одной диаграмме??? Это дико раздражает (либо я чего то не понимаю)!

Давайте рассуждать здраво.  Актер, юзкейцс или другой элемент на модели, должен быть уникальным. Причем уникальность достигается не наименованием класса. а его идентификатором. Хотя имя класса в пакете должно быть уникальным. Тут я ругаю ЕА за то, что он позволяет создавать классификатор с одинаковым именем многократно в одном пакете.

Когда вы делаете ссылку, вы по сути включаете в пакет диаграммы ссылку на классификатор, т.е. почти сам классификатор. Ясно, что классификатор не может быть на одной диаграмме дважды, так что тут все в порядке. Претензий нет. И Еа делает все корректно

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

Правда мне сложно понять в чем проблема и почему так захотелось включить еще один инстансиси на одну и туже диаграмму?

3494

Примеры / Re: Бакалаврская работа

« : 22 Апреля 2009, 12:35:15 »

Ездил к начальнику Аналитического отдела завода, чтобы понять что требуется сделать. Была поставлена цель: есть сайт предпрития, необходимо доработать и сделать что-то вроде модуля который бы позволял посетителям выбрать товар, сформировать корзину товаров и оформить заказ, который бы посредством электронной почты отправлялся бы в коммерческий отдел ОАО "НИЗ", где с заказом бы уже работали менеджеры по стандартной схеме, оформление договора, счет-фактур, товарных накладных.

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

1. Организационная структура
   коммерческий отдел ОАО "НИЗ"
      менеджеры

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

3. что используем:
   Есть База данных коммерческого отдела - как к ней получают доступ, что из нее берется? Является ли эта база частичным клоном центральной базы? И следовательно не будет ли БД ком отдела основой вашего приложения?

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

Поскольку Вашей задачей является создание модули принятиязаявки, то очевидно нужно сосредоточить внимание:
1. на каталоге товаров
2. на способах формирования корзины
3. на оформлении заказ-заявки
4. вход и регистрация клиента

Остальное как я понимаю за кадром

Вам похожеоргструктура почти и не нужна

3495

Примеры / Re: Бакалаврская работа

« : 22 Апреля 2009, 12:16:52 »

Смотрите, Ваша тема "Автоматизация оформления покупок через веб-портал ОАО Новосибирский Инструментальный Завод". Есть некое описание этого процесса или то, что предполагается получит от этого.

Сразу возникает вопрос:
1. Является ли ОАО Новосибирский Инструментальный Завод новатором в этой области?
2. Каким образом именно сейчас осущестувляется оформление каких-либо покупок?
3. А какие виды покупок различают, в чем их особенности?
4. Кто оформляет покупку сейчас? Как он это делает? Кто еще вовлечен в процесс покупки?
5. Что нужно, чтобы осуществить покупку?
6. Как клиент узнает о предмете покупки?
7. Что собственно продает ОАО Новосибирский Инструментальный Завод?
8. Чем это отличается от того, что например продает книжный магазин?
9. Почему возникла потребность создания интернет-площадки для продажи?
10. Кто является покупателем-клиентом завода?