Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Водолей

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 »
601
может в качестве первой (или последней) повесить страничку, типа: Здесь могло бы быть Ваше резюме участника Сообщества. в качестве фотографии - "дырка в картонке", в качестве описания - поля для заполнения. плюс кнопка Submit.

:о))


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

не совсем правильный способ, точнее недостаточно описанный. ведь известно, что в составе системы есть "основные" функции и "вспомогательные" (типа ведения справочников).

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

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

603
как Вам такая идея (не моя): пишешь "код" один раз, а по нему генеришь классы, структуру БД, код различного уровня?

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

604
Цитата: Galogen
Мне ваш подход понятен и импонирует, но он инженерный и, конечно, правильный. Но я хочу для начала пойти в теорию.

Как раз в том проекте был у нас соблазн всё сделать по теории. Но практика показала, что соблюдение всех загогулин избыточно :о((
Суть в том, что должны быть не все возможные артефакты проекта, а лишь необходимые для решения задачи.

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

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

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

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


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

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

Далее. Исходным материалом для формирования модели является всё-таки словесно-формульное описание задачи, для адептов добавлю "обычно". Довольно хорошо про это написано в книжке Баркера ("CASE*Method - Entity Relationship Modelling" by Richard Barker. (c) Copyright 1990 Oracle Corporation UK Limited (c) Перевод с английского к.т.н. Крюкова А.В., 1992. - кстати, советую почитать)

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

Касательно способа реализации.
"Первичная" модель делается ручками из примитивов (вспоминаем ERwin, PowerDesigner, встроенные фичи СУБД и иже с ними), так же ее можно записать в виде кода. "Трансформация" в физическую реализацию выполняется либо ручками (медленно, но при наличии нужного уровня квалификации довольно надежно), либо с помощью автоматических преобразователей (быстро, но всё равно потом надо проверять). Разумеется, из одной логической модели может быть построено много вариантов, я уж не говорю о приложениях.  

ну а для поведенческих аспектов нет ничего лучше имеющихся заготовок. (врочем и у них есть минусы)

P.S. Кстати, если Ваш интерес связан с реализацией подобного автоматического преобразователя, то это похвально, но, по-моему, сейчас бессмысленно. Во всех отношениях дешевле будет использовать любой подходящий (или просто грамотного специалиста) и приноровиться к его особенностям. Причина - скорость прохождения из точки А в точку Б.
Более того, я уже делал подобную работу и на своем опыте убедился в ее трудозатратности (т.е. значительных затратах на создание инструмента) и, следовательно, недостаточной эффективности. Хотя адаптивность получается довольно высокой, я уже писал про это. Но самое важное, что кодирование никуда не девается (вспоминаем правило Парето) :о((
Более-менее приемлемый вариант получается при создании целого комплекса средств автоматизации программистского труда (RAD'ы тут не считаются). Ну а это пока несбыточная мечта, к сожалению.

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

осталось перевести эти пользовательские истории в сообщения классов (подсказка: смотрим на глаголы) и рисуем следующую итерацию диаграммы классов.

на следующей итерации будем утрясать параметры сообщений.


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

Давайте сформулируем (для начала словами), что будет происходить с клиентами, заказами, товарами. Например, нужно ли отслеживать наличие товаров на складе и резервировать их или товаров всегда "неограниченное количество".

Видимо, Ваши затруднения напрямую связаны с реальной практикой (точнее ее отсутствием). Впрочем, Вы же "курируете" задачу по аттестации студентов (там ведь должны были дойти до этапа реализации), или там уже всё заглохло?

607
To Salar:
Насколько мне известно, приличные люди сначала договариваются о терминах. Так что порадуйте, плиз, народонаселение.

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

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

Что-то мне непонятны Ваши затруднения. Как говорил герой одного известного (в определенных кругах) мультика: "Нет никакого фокуса". Вы просто добавляете поведение к исходной модели в соответствии с требованиями Вашей задачи. Постепенно за счет добавлений поведенческих аспектов и, возможно, других cущностей и/или атрибутов исходная (она же аналитическая) модель станет искомой. Если говорить в терминах объектного подхода - нет кода без классов.

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

609
To SALar:

вот только не надо передергивать: цитируете, так делайте это полностью

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

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

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

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

Что из этого следует? А то, что испытание является частью трудовых отношений (ст 15), которые возникают при заключении трудового договора (также см. выделенный фрагмент).
Собеседование при "приеме на работу" (а по сути при подборе персонала), строго говоря, не является частью этих самых отношений - договора-то нет, нет каких-либо обязательств (также еще вопрос, возникают ли обязательства при выдаче приглашения/оффера). А процесс подбора персонала (в том числе: наличие, количество и содержание собеседований) определяется предприятиями самостоятельно. Так что придётся потерпеть... по меньшей мере до тех пор, пока не станете директором :о)))





610
Цитата: Galogen
а/ если принимать тот факт, что проект=набор документов, но у этого слова есть и другие значения в рамках рассматриваемого вопроса

а) однажды имел опыт определения нескольких сущностей, которые в контексте предметной областью назывались "проект" :о)) кончилось тем, что пришлось вводить еще несколько терминов, к сожалению, они не были восприняты представителями заказчика, так и мучались...
в данном случае говоря "проект", имею в виду "design" (но не в смысле "дизайн", а в смысле "проектирование ИС"), чего и всем желаю.

в) я и говорю - прискорбно :о((

611
Цитата: Galogen
проект это мол набор документов, описывающих что и кк делать.

... регламентирует этапы ...

Проектирование как процесс вообще из понимания изчезает.


а) ну дык ведь это так и есть
б) не столько этапы, сколько документы по этапам (т.е. этапы не самоцель)
в) прискорбно. В качестве помощи могу отослать к книжке про RUP (недавно кто-то хвалился :о), что её наконец прочитал). Там явно описывается, что такое процесс разработки, и зачем он нужен (содержательно процессы в разных случаях могут различаться, но принципиально они сходны). Советую взять на вооружение эти несколько страничек.

612
Цитата: SALar
Может быть хоть вы расскажете, как вы используете инструкцию по подгонке в реальных проектах? И в каждом ли проекте вы используете инструкцию по подгонке?

что за зверь?

613
Цитата: SALar
Немного не в тему. ТК РФ предполагает прием сотрудников либо на основании конкурсного отбора, либо на основании испытательного срока. Использование и собеседования, и испытательного срока является нарушением ТК.

Во-во! Будете ходить на собеседования - обязательно расскажите работодателям. А то они не в курсе...

Цитата: SALar
... Был на днях в юрфирме. Так вот, один из первых вопросов на отсев будущих юристов это просьба посчитать площадь прямоугольной комнаты 4х5...
:о))
Чтобы найти площадь Ленина, нужно длину Ленина умножить на ширину Ленина.
Извините за кощунство, но не удержался...

614
Цитата: AlexTheRaven
Кладоискатели нашли клад и записку в которой было написано: В этих 20 мешках с золотыми монетами есть один мешок с фальшивыми монетами. Известно, что фальшивая монета в два раза тяжелее настоящей.
Задача: Как при помощи одного взвешивания определить в каком мешке находятся фальшивые монеты?


Сразу скажу, что ответа не помню, но (!) у меня есть книжка (кажется называется "Мир математических головоломок" или что-то подобное), в которой есть и такая задача, и ее решение.

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



615
Цитата: yaroslav
Но несогласен, что компании имеющие CMM или CMMI  по факту работают на коленке.   У нас в компании точно не так и за выполнением активностей в проектах строго следит аудит.
...
Эта модель предназначена для организации производственных процессов для достижения в первую очередь качества...

А как насчет конфликта интересов? между качеством и результатом...

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

Кстати, поделитесь, пожалуйста, KPI аудита.

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 »