226
О Сайте и Форуме / Раздел: терминология
« : 18 Марта 2007, 15:18:43 »
Не добавить ли нам раздел Терминология, в котором мы будем обсуждать вопросы связанные с пониманием терминов и т.п.
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
227
Бизнес-анализ и Целеполагание / Формулировка цели
« : 16 Марта 2007, 09:08:43 »
Хорошо известно, что система служит для достижения цели в ходе своего функционирования.
Цель - это жлаемое состояние, которое следует достичь в ходе функционирования системы.
Системный анализ учит, что первым принципом является принцип конечной цели.
Принцип конечной цели означает абсолютный приоритет конечной цели и имеет правила:
• для проведения системного анализа необходимо точно сформулировать цель;
• анализ следует проводить на базе уяснения основной цели (функции основного назначения), при этом определяются существенные свойства показателя качества и критерия оценки;
• при синтезе любая попытка изменения или улучшения должна оцениваться относительно того помогает ли или мешает она достижению цели;
• цель функционирования системы задается суперсистемой.
За частую самое сложное - это грамотно определить цель системы. В литературе мы можем найти массу примеров формулировок целей в связанном с ними контексте. Тем не менее, в реальной практике, в начале приобретении опыта, процесс целеполагания представляет известную трудность. Зачастую исследователь интуитивно понимает, что он хочет достигнуть или какой цели должна отвечать разрабатываемая система. Однако ее конкретная и однозначная формулировка зачастую ускользает от него.
Понимая вопрос чисто теоретически, лично у меня нет глубоко практического понимания этого вопроса.
Будет интересно услышать мнения коллег по этому вопросу.
Чтобы дискуссия была предметной попытаюсь сформулировать ряд целей и дать свой анализ им.
Предположим я ставлю цель: научиться кататься на коньках! Будет ли это целью? Или все-таки цель должна звучать примерно так: Научиться кататься на коньках на уровне любителя (твердо держаться на ногах, делать вполне веренные движения, выполнять несложные действия: поворот, движения назад, разгон, торможение) за 4 месяца.
Насколько и когда приемлема формулировка цели в первом и втором случае?
Возможно, ни одна из формулировок не верна?
Верна первая, потому как она общая?
Верна вторая, так как задает четкие критерии достижимости?
Во второй формулировки смешаны понятие цели и критериев ее достижения?
Обе формулировки вполне допустимы?
Далее меня волнует вопрос связанный с различием целей системы, то есть цели для которой строится система, целей анализа или моделирования.
Почему эти цели отличаются?
Должны ли эти цели соотноситься?
Например цель системы: проводить экзамен по программирования в режиме автоматизированного тестирования
а цель анализа(моделирования): разработать правила проведения автоматизированного экзамена по программированию?
Цель - это жлаемое состояние, которое следует достичь в ходе функционирования системы.
Системный анализ учит, что первым принципом является принцип конечной цели.
Принцип конечной цели означает абсолютный приоритет конечной цели и имеет правила:
• для проведения системного анализа необходимо точно сформулировать цель;
• анализ следует проводить на базе уяснения основной цели (функции основного назначения), при этом определяются существенные свойства показателя качества и критерия оценки;
• при синтезе любая попытка изменения или улучшения должна оцениваться относительно того помогает ли или мешает она достижению цели;
• цель функционирования системы задается суперсистемой.
За частую самое сложное - это грамотно определить цель системы. В литературе мы можем найти массу примеров формулировок целей в связанном с ними контексте. Тем не менее, в реальной практике, в начале приобретении опыта, процесс целеполагания представляет известную трудность. Зачастую исследователь интуитивно понимает, что он хочет достигнуть или какой цели должна отвечать разрабатываемая система. Однако ее конкретная и однозначная формулировка зачастую ускользает от него.
Понимая вопрос чисто теоретически, лично у меня нет глубоко практического понимания этого вопроса.
Будет интересно услышать мнения коллег по этому вопросу.
Чтобы дискуссия была предметной попытаюсь сформулировать ряд целей и дать свой анализ им.
Предположим я ставлю цель: научиться кататься на коньках! Будет ли это целью? Или все-таки цель должна звучать примерно так: Научиться кататься на коньках на уровне любителя (твердо держаться на ногах, делать вполне веренные движения, выполнять несложные действия: поворот, движения назад, разгон, торможение) за 4 месяца.
Насколько и когда приемлема формулировка цели в первом и втором случае?
Возможно, ни одна из формулировок не верна?
Верна первая, потому как она общая?
Верна вторая, так как задает четкие критерии достижимости?
Во второй формулировки смешаны понятие цели и критериев ее достижения?
Обе формулировки вполне допустимы?
Далее меня волнует вопрос связанный с различием целей системы, то есть цели для которой строится система, целей анализа или моделирования.
Почему эти цели отличаются?
Должны ли эти цели соотноситься?
Например цель системы: проводить экзамен по программирования в режиме автоматизированного тестирования
а цель анализа(моделирования): разработать правила проведения автоматизированного экзамена по программированию?
228
Бизнес-анализ и Целеполагание / Роль бизнес-аналитика
« : 15 Марта 2007, 12:24:51 »
Коллеги, давайте все-таки подискутируем и определимся окончательно, кто что и как понимает под понятием бизнес-анализ и бизнес-аналитик. Что это за роль , какое место она занимает, как соотносится с ИТ-проектами.
Т.е. я все-таки от себя постулирую тот факт, что понимание, анализ и поиск путей решения проблем бизнеса, задача не тривиальная и требует серьезной подготовки и солидного опыта. Я очень сомневаюсь, что выпускник скажем кафедры САПР, ИС или иной "программисткой" кафедры, может стать бизнес-аналитиком.
Вот даже среди форумчан, кто в своем послужном списке имеет такую красивую профессию как бизнес-аналитик имеет первичное или вторичное образование юриста, экономиста и т.п.
Давайте посморим еще раз, что пишет RUP. Возьмем методические указания Золотухиной.
Я постарался привести полную цитату, так как Денис меня всегда обвиняет в придумывании того, чего типа нет в тексте.
Правда, я думаю, что он неправ. Поскольку текст - это не жесткая формализация как математическая формула, а потому имеет возможность для широкой интерпретации...
Как мы видим процесс бизнес-моделирования включает как минимум три различные роли. Вопрос кто делает эту работу? Сам заказчик? Фирма-разработчик? Или сторонний системный интегратор?
Я понимаю, что практика в России такова, что нам нужен специалист, который "коня на скаку остановит, в горящую избу войдет".
Однако я полагаю это есть порочная практика. Поясню, я подрабатываю техническим писателем в фирме, которая разрабатывает КИС "Восточный экспресс", ориентированную на текстильную отрасль. Команда работает уже 10 лет и состоит из
внедренцев, которые по большему счету имеют экономическое образование, программированием не занимаются
функциональщиков - задача которых разработка прикладной части системы - опятьже все они имеют экономическое образование, а в течение 10 лет стали и специалистами в области текстильной промышленности
системщики - задача которых реализация системных функций КИС
Так вот представитель этой фирмы, отвечающий за кадры, мне прямо говорит - нам не нужны сильные программистя без знаний экономики, бухучета и управленческого учета, не понимающих принципы организации бизнеса и т.п.
Я внимательно изучал десяток учебных планов так или иначе связанных с ИТ, знаете, максимум, что я нашел в них - это две-три дисциплины, так или иначе связанных с экономикой. При этом это часто чисто теоретические курсы, без серьезной практики.
Т.е. я все-таки от себя постулирую тот факт, что понимание, анализ и поиск путей решения проблем бизнеса, задача не тривиальная и требует серьезной подготовки и солидного опыта. Я очень сомневаюсь, что выпускник скажем кафедры САПР, ИС или иной "программисткой" кафедры, может стать бизнес-аналитиком.
Вот даже среди форумчан, кто в своем послужном списке имеет такую красивую профессию как бизнес-аналитик имеет первичное или вторичное образование юриста, экономиста и т.п.
Давайте посморим еще раз, что пишет RUP. Возьмем методические указания Золотухиной.
Цитировать
Основными ролями в проектной команде по RUP, участвующими в бизнес моделирования являются:
• бизнес аналитик (Business-Process Analyst);
• бизнес проектировщик (Business Designer);
• рецензент моделей бизнес процессов и моделей анализа бизнеса (Business-Model Reviewer).
Основными видами деятельности бизнес аналитика являются:
• оценка организации заказчика;
• определение и уточнение целей организации заказчика;
• определение бизнес правил;
• разработка словаря бизнес терминов;
• выявление бизнес процессов и действующих лиц, инициирующих процесс или являющихся потребителями его результатов;
• уточнение связей между бизнес процессами;
• описание архитектуры бизнеса;
• разработка рекомендаций по бизнес моделированию.
Результатами деятельности бизнес аналитика являются:
• разработанные модели бизнес процессов и модели анализа или объектные модели, описывающие реализа-ции бизнес процессов;
• подготовленные документы:
• документ Оценка автоматизируемой организации (Target-Organization Assessment);
• документ Архитектура бизнеса (Business Architecture Document);
• документ Словарь предметной области (Business Glossary);
• документ Бизнес правила (Business Rule);
• документ Концепция развития организации (Business Vision);
• документ Дополнительные требования к деятельности организации (Supplementary Business Specifications);
• документ Рекомендации по бизнес моделированию (Guidelines).
Основными видами деятельности бизнес проектировщика являются:
• описание бизнес процессов;
• определение участников бизнес процессов;
• детальное описание участников бизнес процессов;
• детальное описание бизнес сущностей;
• определение требований к системе на основе документов и моделей.
Основными результатами деятельности бизнес проектировщика являются:
• документ Описание бизнес процесса (Business Use Case);
Основными видами деятельности рецензента моделей бизнес процессов и моделей анализа бизнеса или объект-ных моделей бизнеса являются:
• рецензирование модели бизнес процессов;
• рецензирование моделей анализа или объектных моделей бизнеса.
Результатами деятельности рецензента моделей бизнес процессов и объектных моделей бизнеса являются:
• рецензии на модели бизнес процессов;
• рецензии на модели анализа бизнеса или объектные модели бизнеса.
Я постарался привести полную цитату, так как Денис меня всегда обвиняет в придумывании того, чего типа нет в тексте.
Правда, я думаю, что он неправ. Поскольку текст - это не жесткая формализация как математическая формула, а потому имеет возможность для широкой интерпретации...
Как мы видим процесс бизнес-моделирования включает как минимум три различные роли. Вопрос кто делает эту работу? Сам заказчик? Фирма-разработчик? Или сторонний системный интегратор?
Я понимаю, что практика в России такова, что нам нужен специалист, который "коня на скаку остановит, в горящую избу войдет".
Однако я полагаю это есть порочная практика. Поясню, я подрабатываю техническим писателем в фирме, которая разрабатывает КИС "Восточный экспресс", ориентированную на текстильную отрасль. Команда работает уже 10 лет и состоит из
внедренцев, которые по большему счету имеют экономическое образование, программированием не занимаются
функциональщиков - задача которых разработка прикладной части системы - опятьже все они имеют экономическое образование, а в течение 10 лет стали и специалистами в области текстильной промышленности
системщики - задача которых реализация системных функций КИС
Так вот представитель этой фирмы, отвечающий за кадры, мне прямо говорит - нам не нужны сильные программистя без знаний экономики, бухучета и управленческого учета, не понимающих принципы организации бизнеса и т.п.
Я внимательно изучал десяток учебных планов так или иначе связанных с ИТ, знаете, максимум, что я нашел в них - это две-три дисциплины, так или иначе связанных с экономикой. При этом это часто чисто теоретические курсы, без серьезной практики.
229
Бизнес-анализ и Целеполагание / Пошаговый перевод избранных мест из BABOK
« : 13 Марта 2007, 20:32:53 »
Вот решил начать данный тяжкий труд. Надеюсь найдутся энтузиасты и присоединятся ко мне.
Исходный текст оригинала можно найти по ссылке из файлового архива.
Итак начнемс.
1.4. Базовые концепции бизнес-анализа
1.4.1 Определение роли бизнес-аналитика
Бизнес-аналитик работает связующим звеном между участниками процесса разработки системы и стремится выявлять, анализировать, сообщать и утверждать требования к изменению бизнес-процессов, политик и информационных систем. Бизнес-аналитик понимает бизнес-проблемы и возможности в контексте требований и рекомендует решения, способствующие достижению целей организации
1.4.2. Определение требований
Требование это:
1. Условие или способность, необходимая участнику для решение проблемы (задачи) и достижения цели.
2. Условие или способность, которому должна соотвествовать или которым должна обладать систему или системный компонент для удовлетворения соглашения, стандарта, спецификации или другим формально введенным (определенным) документам.
Требования служат основанием систем или системных компонентов. Требование может быть представлено как нечто необходимое или обязательное для исполнения; как свойство существенно важное для выполнения системой ее функций. Требования различаются в назначении и типах свойств. Они могут быть функциями, ограничениями или другими элементами, которые необходимы для удовлетворения потребностей предполагаемых участников. Требования могут быть описаны как условия или способности необходимые клиенту (пользователю) для решения проблемы (задачи) или достижения цели. Для прояснения целей (намерений) требования должны сопровождаться описателем (идентификатором типа требования): бизнес-требования, требования пользователя, функциональные требования.
Исходный текст оригинала можно найти по ссылке из файлового архива.
Итак начнемс.
1.4. Базовые концепции бизнес-анализа
1.4.1 Определение роли бизнес-аналитика
Бизнес-аналитик работает связующим звеном между участниками процесса разработки системы и стремится выявлять, анализировать, сообщать и утверждать требования к изменению бизнес-процессов, политик и информационных систем. Бизнес-аналитик понимает бизнес-проблемы и возможности в контексте требований и рекомендует решения, способствующие достижению целей организации
1.4.2. Определение требований
Требование это:
1. Условие или способность, необходимая участнику для решение проблемы (задачи) и достижения цели.
2. Условие или способность, которому должна соотвествовать или которым должна обладать систему или системный компонент для удовлетворения соглашения, стандарта, спецификации или другим формально введенным (определенным) документам.
Требования служат основанием систем или системных компонентов. Требование может быть представлено как нечто необходимое или обязательное для исполнения; как свойство существенно важное для выполнения системой ее функций. Требования различаются в назначении и типах свойств. Они могут быть функциями, ограничениями или другими элементами, которые необходимы для удовлетворения потребностей предполагаемых участников. Требования могут быть описаны как условия или способности необходимые клиенту (пользователю) для решения проблемы (задачи) или достижения цели. Для прояснения целей (намерений) требования должны сопровождаться описателем (идентификатором типа требования): бизнес-требования, требования пользователя, функциональные требования.
230
Системный Анализ и Требования / Рекомендации по анализу
« : 08 Марта 2007, 13:32:33 »
Интересно, автор объявления как-то прокомментирует тут фантазии завсегдатаев форума?
Участникам форума - Юрию и Сергею в первую очередь - есть вполне очевидное направление:
А. описание (краткое ясное без слюней) методик и методологий проектирования (RUP, EUP, Agile анд аверз)
B. более детальное описание, рекомендации по этапам и позициям процесса.
1. когда и зачем делаем бизнес-анализ
2. чем отличаются бизнес-требования от требований пользователя требований к системе, когда одно и тоже описание требования может фигурировать на разных уровнях под разными типами, почему. Какие методики сбора требований существуют, чем они отличаются, как реализуются, когда их следует использовать и почему
3. всегда ли требуются требования к системе? какие системы нуждаются в анализе требований, а какие нет.
4. с чего следует начинать анализ предметной о области: сначала понять требования или сначала построить структуру Пр Об, почему в одних случаях можно начать сразу с диагарммы классов, а в другом лучше пройти этап сценарии ВИ, диаграмм взаимодействия, а потом диаграмм классов
5. когда и почему можно вообще обойтись без понимания структуры классов, как накладывать результаты моделирования на конкретные системы программирования (скажем Дельфи, где все объекты так или иначе наследники TObject)
6. какую пользу дают диаграммы состояний - как они практически трансформируются в практическое решение?
7. кому и когда и чем полезна та или иная диаграмма, что помимо единого понимания системы дают все эти диаграммы.
8 насколько каждая диаграмма полезна, каково ее реальное время жизни, т.е. какие диаграммы следует считать вспомогательными, а какие основными - скажем так системоописательными. Насколько вообще следует уделять внимания на документирование моделей.
9 Что такое трассировка требований, как ее правильно проводит, как она проявляется на практике.
10. Есть ли четкие теоретические основы практики моделирования - или они основаны на наблюдении и эмпирическом опыте?
Участникам форума - Юрию и Сергею в первую очередь - есть вполне очевидное направление:
А. описание (краткое ясное без слюней) методик и методологий проектирования (RUP, EUP, Agile анд аверз)
B. более детальное описание, рекомендации по этапам и позициям процесса.
1. когда и зачем делаем бизнес-анализ
2. чем отличаются бизнес-требования от требований пользователя требований к системе, когда одно и тоже описание требования может фигурировать на разных уровнях под разными типами, почему. Какие методики сбора требований существуют, чем они отличаются, как реализуются, когда их следует использовать и почему
3. всегда ли требуются требования к системе? какие системы нуждаются в анализе требований, а какие нет.
4. с чего следует начинать анализ предметной о области: сначала понять требования или сначала построить структуру Пр Об, почему в одних случаях можно начать сразу с диагарммы классов, а в другом лучше пройти этап сценарии ВИ, диаграмм взаимодействия, а потом диаграмм классов
5. когда и почему можно вообще обойтись без понимания структуры классов, как накладывать результаты моделирования на конкретные системы программирования (скажем Дельфи, где все объекты так или иначе наследники TObject)
6. какую пользу дают диаграммы состояний - как они практически трансформируются в практическое решение?
7. кому и когда и чем полезна та или иная диаграмма, что помимо единого понимания системы дают все эти диаграммы.
8 насколько каждая диаграмма полезна, каково ее реальное время жизни, т.е. какие диаграммы следует считать вспомогательными, а какие основными - скажем так системоописательными. Насколько вообще следует уделять внимания на документирование моделей.
9 Что такое трассировка требований, как ее правильно проводит, как она проявляется на практике.
10. Есть ли четкие теоретические основы практики моделирования - или они основаны на наблюдении и эмпирическом опыте?
231
Системный Анализ и Требования / Технология системного анализа
« : 25 Февраля 2007, 16:52:44 »
Читая книгу: Ю. П. Сурмина "Теория систем и системный анализ", обнаружил интересные мысли, которые и хочу донести до общественности и обсудить в дискуссии.
Системный анализ в первую очередь, лишь часть методов исследования систем, системный анализ направлен на устранение проблемы либо ее глубокого понимания
Если появится интерес к теме, постараюсь сделать продолжение..
Системный анализ в первую очередь, лишь часть методов исследования систем, системный анализ направлен на устранение проблемы либо ее глубокого понимания
Цитировать
Выходные данные:
Сурмин Ю. П.
Теория систем и системный анализ: Учеб. пособие. — Киев.:МАУП, 2003. — 368 с.: Библиогр. в конце глав. ISBN 966-608-290-Х
Цитировать
Популярность системного анализа ныне столь велика, что можно
перефразировать известный афоризм выдающихся физиков Уилья-
ма Томсона и Эрнеста Резерфорда относительно науки, которую
можно разделить на физику и собирание марок. Действительно, сре-
ди всех методов анализа системный — настоящий король, а все дру-
гие методы можно с уверенностью отнести к его невыразительной
прислуге.
Вместе с тем всякий раз, когда ставится вопрос о технологиях
системного анализа, сразу же возникают непреодолимые трудности,
связанные с тем, что устоявшихся интеллектуальных технологий
системного анализа в практике нет. Имеется только некоторый опыт
применения системного подхода в различных странах. Таким
образом, налицо проблемная ситуация, характеризующаяся посто-
янно нарастающей потребностью технологического освоения сис-
темного анализа, которое разработано весьма недостаточно.
Ситуация усугубляется не только тем, что не разработаны интел-
лектуальные технологии системного анализа, но и тем, что нет одно-
значности в понимании самого системного анализа. Это несмотря на
то что уже 90 лет прошло со времени выхода в свет основополагающе-
го труда в области теории систем — “Тектологии” А. А. Богданова, и
почти полстолетия насчитывает история развития системных идей.
Достаточно рельефно выделяются несколько вариантов понима-
ния сущности системного анализа:
• Отождествление технологии системного анализа с технологией
научного исследования. При этом для самого системного анали-
за в этой технологии практически не находится места.
• Сведение системного анализа к системному конструированию.
По сути системно-аналитическая деятельность отождествляется с
системотехнической деятельностью.
• Очень узкое понимание системного анализа, сведение его к одной
из его составляющих, например к структурно-функциональному
анализу.
• Отождествление системного анализа системным подходом в ана-
литической деятельности.
• Понимание системного анализа как исследования системных за-
кономерностей.
• В узком смысле под системным анализом довольно часто пони-
мают совокупность математических методов исследования сис-
тем.
• Сведение системного анализа к совокупности методологических
средств, которые используются для подготовки, обоснования и
осуществления решений по сложным проблемам.
В этом случае то, что называют системным анализом, представ-
ляет собой недостаточно интегрированный массив методов и прие-
мов системной деятельности. В табл. 31 дана характеристика основ-
ных видов системной деятельности, среди которых фактически теря-
ется системный анализ.
Следует подчеркнуть, что ныне практически не встречаются на-
учные и педагогические разработки в различных областях управле-
ния, в которых не уделялось бы внимание системному анализу. При
этом его вполне справедливо рассматривают как эффективный ме-
тод изучения объектов и процессов управления. Однако практичес-
ки отсутствует анализ “точек” приложения системной аналитики к
решению конкретных управленческих задач и ощущается дефицит
технологических схем такого анализа. Системный анализ в управле-
нии представляет ныне не развитую практику, а нарастающие мен-
тальные декларации, не имеющие какого-либо серьезного технологи-
ческого обеспечения.
| Виды деятельности | Цель деятельности | Средства деятельности | Содержание деятельности |
| Системное познание | Получение знания | Знания, методы познания | Изучение объекта и его предмета |
| Системный анализ | Понимание проблемы | Информация, методы ее анализа | Рассмотрение проблемы посредством методов анализа |
| Системное моделирование | Создание модели системы | Методы моделирования | Построение формальной или натурной модели системы |
| Системное конструирование | Создание системы | Методы конструирования | Проектирование и опредмечивание системы |
| Системная диагностика | Диагноз системы | Методы диагностики | Выяснение отклонений от нормы в структуре и функциях системы |
| Системная оценка | Оценка системы | Теория и методы оценки | Получение оценки системы, ее значимости |
Если появится интерес к теме, постараюсь сделать продолжение..
232
Обучение / Опыт преподавания объектно-ориентированного подхода в моделировании, анализе
« : 14 Февраля 2007, 19:54:41 »
Сегодня провел первое занятие по ООП. Общая цель занятий - познакомить с методологией ООП, моделирования систем в UML.
Первое занятие - Мозговой штурм. Придумывание бизнеса, business case, если хотите.
Группа из 28 человек поделена на 4 подгруппы. Каждой подгруппе предложено придумать бизнес на заданную тему (Кафе, магазин, мелкое производства, оказание услуг и т.п.). Задача подгруппы - расписать все аспекты своего бизнеса. Полагается бизнес уже существует и работает. Требуется определить все процессы, связи между ними, сценарии их выполнения, ресурсы, цели. Ориентация на личный опыт и фантазию. Я как преподаватель курирую группу, корректирую их обсуждение, не навязываю свое мнение, а просто указываю на некоторые ошибки обсуждения, даю мелкие советы: не выкидывайте идею, запишите ее, обсудите, потом отбросьте. пропишите каждый момент исполнения каких-либо действий. Что значит купить товар, как это может происходить, какие варианты вы видете, будете ли вы учитывать все варианты или строго ограничите этот вариант и т.д.
В конце занятия у каждой группы (их у меня 2) принял их самое общее представление о бизнесе,попытался задать определенные вопросы в случае неясных, двухсмысленных моментов. Выдал домашнее задание - подготовить общегрупповую презентацию их бизнеса. Презентация будет проходить на следующем занятии. На презентацию никаких ограничений не накладывал, единственно просил сделать в PowerPoint. Будет ли презентация чисто текстовая или графическая, решать студентам. Им предлагается подумать и попытаться принять полную ответственность на себя. Срок исполнения 2 недели до следующего занятия.
Впечатления: мозговой штурм прошел интересно. Студенты чувствовали себя комфортно. В группе выделились авторитеты и лидеры. В целом обсуждение захватило студентов. На мой взгляд пока им понравилось.
Увиденные проблемы: боязнь принять неверное решение или вывод. Обращаются например с вопросом: "А можно у нас покупки будут также и через интернет?", "А нам следует описывать поставщиков", "А как лучше описать процесс так-то или так-то". Отвечаю - ваша полная воля, как вы определите, так и будет. Что у вас получится обсудим на следующем занятии, ваши коллеги зададут вам вопросы, выступая вы и сами заметите какие-то неувязки и проблемы описания. Вводите любые правила и ограничения. Думайте сами, решайте сами (с)
Первое занятие - Мозговой штурм. Придумывание бизнеса, business case, если хотите.
Группа из 28 человек поделена на 4 подгруппы. Каждой подгруппе предложено придумать бизнес на заданную тему (Кафе, магазин, мелкое производства, оказание услуг и т.п.). Задача подгруппы - расписать все аспекты своего бизнеса. Полагается бизнес уже существует и работает. Требуется определить все процессы, связи между ними, сценарии их выполнения, ресурсы, цели. Ориентация на личный опыт и фантазию. Я как преподаватель курирую группу, корректирую их обсуждение, не навязываю свое мнение, а просто указываю на некоторые ошибки обсуждения, даю мелкие советы: не выкидывайте идею, запишите ее, обсудите, потом отбросьте. пропишите каждый момент исполнения каких-либо действий. Что значит купить товар, как это может происходить, какие варианты вы видете, будете ли вы учитывать все варианты или строго ограничите этот вариант и т.д.
В конце занятия у каждой группы (их у меня 2) принял их самое общее представление о бизнесе,попытался задать определенные вопросы в случае неясных, двухсмысленных моментов. Выдал домашнее задание - подготовить общегрупповую презентацию их бизнеса. Презентация будет проходить на следующем занятии. На презентацию никаких ограничений не накладывал, единственно просил сделать в PowerPoint. Будет ли презентация чисто текстовая или графическая, решать студентам. Им предлагается подумать и попытаться принять полную ответственность на себя. Срок исполнения 2 недели до следующего занятия.
Впечатления: мозговой штурм прошел интересно. Студенты чувствовали себя комфортно. В группе выделились авторитеты и лидеры. В целом обсуждение захватило студентов. На мой взгляд пока им понравилось.
Увиденные проблемы: боязнь принять неверное решение или вывод. Обращаются например с вопросом: "А можно у нас покупки будут также и через интернет?", "А нам следует описывать поставщиков", "А как лучше описать процесс так-то или так-то". Отвечаю - ваша полная воля, как вы определите, так и будет. Что у вас получится обсудим на следующем занятии, ваши коллеги зададут вам вопросы, выступая вы и сами заметите какие-то неувязки и проблемы описания. Вводите любые правила и ограничения. Думайте сами, решайте сами (с)
233
О Сайте и Форуме / Полезен ли наш форум?
« : 08 Февраля 2007, 20:09:02 »
Наш форум существует не долго. Однако статистика уже не такая плохая.
104 зарегистрированных пользователя.
117 тем и 1179 сообщений.
Средняя активность 40-50 пользователей в день.
Вместе с тем, активными пользователями является небольшая группа 4-5 человек. Остальные пассивные наблюдатели.
Данное голосование предполагает выявить некоторую статистику полезности и интересности форума.
Что не возможно выявить голосованием, можно высказать в сообщении.
Просим Вас высказать свои пожелания форуму: какие темы Вас интересуют, что Вам кажется мало интересным и другие ваши пожелания
104 зарегистрированных пользователя.
117 тем и 1179 сообщений.
Средняя активность 40-50 пользователей в день.
Вместе с тем, активными пользователями является небольшая группа 4-5 человек. Остальные пассивные наблюдатели.
Данное голосование предполагает выявить некоторую статистику полезности и интересности форума.
Что не возможно выявить голосованием, можно высказать в сообщении.
Просим Вас высказать свои пожелания форуму: какие темы Вас интересуют, что Вам кажется мало интересным и другие ваши пожелания
234
RUP EUP AUP OpenUP / Практика использования RUP. Или бег на месте...
« : 06 Февраля 2007, 10:12:53 »
Уважаемые аналитики. Бизнес-аналитики, системные аналитики. Опытные аналитики и только начинающие. Срочно, просто срочно требуется внятная консультация.
Многие меня на форуме знают. Я не новичок в целом. Но все равно пока не могу "сшить" одно с другим. Прежде чем задать вопрос некоторые мыли по поводу понимания самого процесса RUP и использования ООАП.
Не будем говорить о том, когда и зачем нужно бизнес-моделирование. Возьмем это за постулат. Оно нужно всегда. Пусть оно простое, в целом очевидное. Все равно оно требуется для задания контекста, для создания красочных иллюстраций, для обучения наконец.
Бизнес-моделирования какрезультат должно привести к построению как минимум двух моделей: модели бизнес-вариантов использования и модели бизнес-объектов. Модель бизнес-объектов - задает, определяет статическую структуру бизнес-систему, модель вариантов использования - поведение системы. Бизнес варианты-использования обычно сводят до уровня пользователя такой бизнес-системы: внешние действующие лица, ради которых собственно и работает бизнес, производит некоторую ценность. Внешние действующие лица часто являются участниками, инициаторами, источниками и потребителями бизнес-процессов системы. Очевидно у бизнес-системы могут быть один или несколько основных бизнес-процессов, куча вспомогательных. Каждый такой бизнес-процесс, выделенный и очерченный в ходе анализа, является отличным кандидатом на подсистему в будущей системе, которую мы захотим построить. естественно IT-специалиста в первую очередь интересует информационная составляющая таких процессов.
Бизнес-вариант использования может быть детализирован диаграммой деятельности или диаграммой последовательности. Отдельная деятельность может стать хорошим кандидатом на системный вариант использования.
Т.е. в RUP на мой взгляд прослеживается такой переход от БМ к модели системной:
1.Внешнее действующее лицо трансформируется либо в основное действующее лицо(пользователя системы) либо становится третьестепенным(закулисным)либо становится классом-сущностью системы
2.Бизнес-вариант использования становится подсистемой системы или остается вариантом использования системы
3.Деятельность может стать отдельным вариантом использования системы
4. Бизнес-имсполнитель превращается в основное действующее лицо системы(пользователя системы) или превращается в управляющую автоматическую структуру.
Это, конечно , рекомендации, а не руководства к действию. Но в целом мне кажется вполне логичным
Однако-таки есть червячок сомнение, этакая вольная интерпетация того, чего может я не понимаю на самом деле.
Хотелось бы предложить некоторую практическую задачу, для анализа и устранения ошибок.
Задача чисто вымышленная.
Предположим мы с вами организовали небольшой бизнес: скажем маленькое студентческое кафе (такое я видел в Португалии в их техническом универститете): 10 столиков, а то и того меньше, по 4 человека за столик. Относительно разнообразное меню: закуски, вторые блюда, первые блюда, выпечка, десерты, напитки. Пусть для простоты и опрделенности сделаем как это было в Португалии: каждый день кафе анонсирует пять блюд: обычно это рыба в сочетании с разным гарниром и 1-2 блюда с мясом: - это основные блюда. Есть еще супы, но они не анонсируются.
Естественно у нас есть повар с помощниками, кассир, директор, бухгалтер, закупщик продуктов. Это роли. Штат значение не имеет.
Основным бизнес-процессом будет обслуживание клиента, нужно также организовать закупку свежих продуктов, приготовить блюда, решать разные оргвопросы.
Какие проблемы возникают и зачем нам строить информационную систему? Ну скажем нужно знать какова средняя интенсивность обслуживания, какое количество продуктов требуется на день, какова выручка, что следует сдлеать чтобы увеличивать прибыль и поддерживать качество обедов и обслуживания. Очевидно для ответа на эти и другие вопросы нам нужна информация. Чобы получить ее нужна ежедневная регистрация данных: сколько каких продуктов купили, сколько народу посетило кафе, какие блюда пользуются спросом, какие цены выставлять, и т.п.
Начинаем строить контекст, используя инструментраий UML.
Внешние действующие лица:
клиенты (студенты, преподаватели, возможно случайные посетители вуза) - те кто приходят покушать
поставщики (магазины, рынки, торговые базы) - все те, у кого мы закупаем продукты
администрация вуза - кому мы оплачиваем аренду, кто обеспечивает законность нашего бизнеса - есть возможность, что мы не образуем отдельного юридического лица - 1 вариант, а можем быть и самостоятельным юридическим лицом - тогда появляется еще связь с налоговыми органами
санитарные службы - у которых мы должны получить лицензию
Очевидно, не все из перечисленного значимо для нашего случая, однако очевидно, что важными для нас будут клиенты, поставщики, администрация.
Основным вариантом использования уровня облака или воздушного змея наверное будет "Обслужить клиента", а цель получение прибыли от своей деятельности, очевидно. Если детализировать это процесс, то вероятно можно выделить:
БП1: Накормить клиента - (ДЛ клиент)
БП2: Приготовить блюда - (включается в БП1)
БП3: Закупить продукты - (Дл постащики)
БП4: Оплатить аренду - (ДЛ администрация вуза(бухгалтерия вуза))
БП1: Накормить клиента
1. Клиент изучает меню.
2. Клиент выбирает блюда.
3. Продавец-официант выдает заказанные блюда
4. Кассир расчитывает сумму и выбивает чек
5. Клиент расплачивается разрешенным способом(наличными или кредитной картой)
6. Клиент есть свой обед
7. Клиент относит посуду.
БП3: Закупить продукты (доставит продукты??)
1. повар планирует меню следующего дня
2. Повар составляет реестр необходимых продуктов
3. Закупщик закупает продукты у поставщика(в магазине, оптовой базе)
4. Поставщик выдает накладную (счет-фактуру)
5. Закупщик доставляет продукты в кафе
6. Бухгалтер оформляет поступление продуктов
Останавлюсь пока на этом, поскольку чувствую что-то не совсем так....
Однако скажем посел построения БМ - я перейду к системе:
Очевидно - пользователями будут кассир, бухгалтер, повар, закупщик??
а варианты использования будем рассматриватьс точки зрения уже их:
Кассир: рассчитать клиента
Повар: составить реестр продуктов, составить меню
Закупщик: составить заказ
Бухгалтер: Оприходывать продукты, Рассчитать арендную плату, что-то еще?
Директор: провести инвентаризацию....
Вот такая каша в голове? Может кто-то поможет сделать это ясным, логичным и точным?
Но нужно как можно скорее, через неделю начинаются занятия, не хотелось бы учить ошибкам...
Многие меня на форуме знают. Я не новичок в целом. Но все равно пока не могу "сшить" одно с другим. Прежде чем задать вопрос некоторые мыли по поводу понимания самого процесса RUP и использования ООАП.
Не будем говорить о том, когда и зачем нужно бизнес-моделирование. Возьмем это за постулат. Оно нужно всегда. Пусть оно простое, в целом очевидное. Все равно оно требуется для задания контекста, для создания красочных иллюстраций, для обучения наконец.
Бизнес-моделирования какрезультат должно привести к построению как минимум двух моделей: модели бизнес-вариантов использования и модели бизнес-объектов. Модель бизнес-объектов - задает, определяет статическую структуру бизнес-систему, модель вариантов использования - поведение системы. Бизнес варианты-использования обычно сводят до уровня пользователя такой бизнес-системы: внешние действующие лица, ради которых собственно и работает бизнес, производит некоторую ценность. Внешние действующие лица часто являются участниками, инициаторами, источниками и потребителями бизнес-процессов системы. Очевидно у бизнес-системы могут быть один или несколько основных бизнес-процессов, куча вспомогательных. Каждый такой бизнес-процесс, выделенный и очерченный в ходе анализа, является отличным кандидатом на подсистему в будущей системе, которую мы захотим построить. естественно IT-специалиста в первую очередь интересует информационная составляющая таких процессов.
Бизнес-вариант использования может быть детализирован диаграммой деятельности или диаграммой последовательности. Отдельная деятельность может стать хорошим кандидатом на системный вариант использования.
Т.е. в RUP на мой взгляд прослеживается такой переход от БМ к модели системной:
1.Внешнее действующее лицо трансформируется либо в основное действующее лицо(пользователя системы) либо становится третьестепенным(закулисным)либо становится классом-сущностью системы
2.Бизнес-вариант использования становится подсистемой системы или остается вариантом использования системы
3.Деятельность может стать отдельным вариантом использования системы
4. Бизнес-имсполнитель превращается в основное действующее лицо системы(пользователя системы) или превращается в управляющую автоматическую структуру.
Это, конечно , рекомендации, а не руководства к действию. Но в целом мне кажется вполне логичным
Однако-таки есть червячок сомнение, этакая вольная интерпетация того, чего может я не понимаю на самом деле.
Хотелось бы предложить некоторую практическую задачу, для анализа и устранения ошибок.
Задача чисто вымышленная.
Предположим мы с вами организовали небольшой бизнес: скажем маленькое студентческое кафе (такое я видел в Португалии в их техническом универститете): 10 столиков, а то и того меньше, по 4 человека за столик. Относительно разнообразное меню: закуски, вторые блюда, первые блюда, выпечка, десерты, напитки. Пусть для простоты и опрделенности сделаем как это было в Португалии: каждый день кафе анонсирует пять блюд: обычно это рыба в сочетании с разным гарниром и 1-2 блюда с мясом: - это основные блюда. Есть еще супы, но они не анонсируются.
Естественно у нас есть повар с помощниками, кассир, директор, бухгалтер, закупщик продуктов. Это роли. Штат значение не имеет.
Основным бизнес-процессом будет обслуживание клиента, нужно также организовать закупку свежих продуктов, приготовить блюда, решать разные оргвопросы.
Какие проблемы возникают и зачем нам строить информационную систему? Ну скажем нужно знать какова средняя интенсивность обслуживания, какое количество продуктов требуется на день, какова выручка, что следует сдлеать чтобы увеличивать прибыль и поддерживать качество обедов и обслуживания. Очевидно для ответа на эти и другие вопросы нам нужна информация. Чобы получить ее нужна ежедневная регистрация данных: сколько каких продуктов купили, сколько народу посетило кафе, какие блюда пользуются спросом, какие цены выставлять, и т.п.
Начинаем строить контекст, используя инструментраий UML.
Внешние действующие лица:
клиенты (студенты, преподаватели, возможно случайные посетители вуза) - те кто приходят покушать
поставщики (магазины, рынки, торговые базы) - все те, у кого мы закупаем продукты
администрация вуза - кому мы оплачиваем аренду, кто обеспечивает законность нашего бизнеса - есть возможность, что мы не образуем отдельного юридического лица - 1 вариант, а можем быть и самостоятельным юридическим лицом - тогда появляется еще связь с налоговыми органами
санитарные службы - у которых мы должны получить лицензию
Очевидно, не все из перечисленного значимо для нашего случая, однако очевидно, что важными для нас будут клиенты, поставщики, администрация.
Основным вариантом использования уровня облака или воздушного змея наверное будет "Обслужить клиента", а цель получение прибыли от своей деятельности, очевидно. Если детализировать это процесс, то вероятно можно выделить:
БП1: Накормить клиента - (ДЛ клиент)
БП2: Приготовить блюда - (включается в БП1)
БП3: Закупить продукты - (Дл постащики)
БП4: Оплатить аренду - (ДЛ администрация вуза(бухгалтерия вуза))
БП1: Накормить клиента
1. Клиент изучает меню.
2. Клиент выбирает блюда.
3. Продавец-официант выдает заказанные блюда
4. Кассир расчитывает сумму и выбивает чек
5. Клиент расплачивается разрешенным способом(наличными или кредитной картой)
6. Клиент есть свой обед
7. Клиент относит посуду.
БП3: Закупить продукты (доставит продукты??)
1. повар планирует меню следующего дня
2. Повар составляет реестр необходимых продуктов
3. Закупщик закупает продукты у поставщика(в магазине, оптовой базе)
4. Поставщик выдает накладную (счет-фактуру)
5. Закупщик доставляет продукты в кафе
6. Бухгалтер оформляет поступление продуктов
Останавлюсь пока на этом, поскольку чувствую что-то не совсем так....
Однако скажем посел построения БМ - я перейду к системе:
Очевидно - пользователями будут кассир, бухгалтер, повар, закупщик??
а варианты использования будем рассматриватьс точки зрения уже их:
Кассир: рассчитать клиента
Повар: составить реестр продуктов, составить меню
Закупщик: составить заказ
Бухгалтер: Оприходывать продукты, Рассчитать арендную плату, что-то еще?
Директор: провести инвентаризацию....
Вот такая каша в голове? Может кто-то поможет сделать это ясным, логичным и точным?
Но нужно как можно скорее, через неделю начинаются занятия, не хотелось бы учить ошибкам...
235
Сообщество Аналитиков / Ваше базовое образование
« : 05 Февраля 2007, 12:15:48 »
Предлагаю провести небольшое голосование по поводу Вашего образования.
Как Вы пишли в IT специализацию? Какое было Ваше образование?
Закончили ли Вы любой технический вуз, но по специальности не связанной с IT?
Закончили ли Вы какую-то гуманитарную спеуиальность?
А может Вы получили университетское образование в области или гуманитарного или естественно-научного направления?
А возможно Вы закончили только школу и, тем не менее, работаете в IT индустрии или по IT профилю в силу своей одаренности?
Как Вы пишли в IT специализацию? Какое было Ваше образование?
Закончили ли Вы любой технический вуз, но по специальности не связанной с IT?
Закончили ли Вы какую-то гуманитарную спеуиальность?
А может Вы получили университетское образование в области или гуманитарного или естественно-научного направления?
А возможно Вы закончили только школу и, тем не менее, работаете в IT индустрии или по IT профилю в силу своей одаренности?
236
Проектирование / Информационно-справочная система(domain model)
« : 01 Февраля 2007, 14:57:53 »
Это не провокация!
Однажды мы решали такую задачу с одним дипломником. Система была разработана как веб-приложение на платформе Apache+PHP+MySQL. Реализация была вполне успешная, для разработки и проектирования использовался структурный подход. Модель данных проектировалась в IDEF1x. Физическая реализация БД была изменена, поскольку наша ИЛМ(инфологическая модель) создавала проблемы в реализации. Какие пока говорить не буду.
Для определенности будем полагать конкретную организацию - а именно ВУЗ.
Итак, вот набор фактов, которые были выявлены в ходе анализа ПрОб.
ВУЗ - организация, состоящая из подразделений. Подразделение в свою очередь может также включать другие подразделения. В качестве подразделения можно например назвать: ректорат, бухгалтерия, отдел кадров ит.п., факультет, деканат, кафедра, лаборатория, и т.п. Очевидно что подразделение ректорат подчинено самому вузу, так же например как и факультет, но на факультете есть деканат, кафедры и т.п. В месте с тем можно различать учебные и не учебные подразделения. Однако мы этого не делали в силу общности ИСС.
Организация имеет несколько зданий. Здания имеют уникальное имя и нумеруются буквой русского алфавита.
Здание состоит из помещений. Помещения бывают аудиториями и комнатами. Для нашего случая аудитории не интересны, т.к. цель иметь информацию о том, где расположен тот или иной сотрудник, как его найти и как с ним связаться.
Помещения принадлежат определенному подразделению либо вузу как главному подразделению. Подразделение может размещаться не в одном здании. Каждое помещение в рамках здания имеет номер. Обычно это цифровой код - числа по порядку, но возможны и номера с буквами 9а, 12б и т.п.
В некоторых помещениях располагаются телефоны. Телефон может быть местный и/или городской. Один и тот же номер телефона может быть закреплен за разными помещениями. Обычно в одном помещении может быть только один местный телефон.
В помещении могут находится(работать, быть закрепленными) 1 или более сотрудников.
Сотрудник может иметь 1 или более должностей. Вторые должности - совместительство. При этом работая на разных должностях сотрудник может быть закреплен за разными помещениями. Скажем мистер Х - заведующий кафедры Y находится в кабинете №3 в заднии В(Учебно-лабораторный корпус) и местный номер телефона и городской номер телефона. (Чаще всего городской номер закреплен за подразделением). Тот же мистер Х - декант факультета Z - находится в деканате в комнате №56 корпуса А(аудиторный) имея телефон или несколько...
Однажды мы решали такую задачу с одним дипломником. Система была разработана как веб-приложение на платформе Apache+PHP+MySQL. Реализация была вполне успешная, для разработки и проектирования использовался структурный подход. Модель данных проектировалась в IDEF1x. Физическая реализация БД была изменена, поскольку наша ИЛМ(инфологическая модель) создавала проблемы в реализации. Какие пока говорить не буду.
Для определенности будем полагать конкретную организацию - а именно ВУЗ.
Итак, вот набор фактов, которые были выявлены в ходе анализа ПрОб.
ВУЗ - организация, состоящая из подразделений. Подразделение в свою очередь может также включать другие подразделения. В качестве подразделения можно например назвать: ректорат, бухгалтерия, отдел кадров ит.п., факультет, деканат, кафедра, лаборатория, и т.п. Очевидно что подразделение ректорат подчинено самому вузу, так же например как и факультет, но на факультете есть деканат, кафедры и т.п. В месте с тем можно различать учебные и не учебные подразделения. Однако мы этого не делали в силу общности ИСС.
Организация имеет несколько зданий. Здания имеют уникальное имя и нумеруются буквой русского алфавита.
Здание состоит из помещений. Помещения бывают аудиториями и комнатами. Для нашего случая аудитории не интересны, т.к. цель иметь информацию о том, где расположен тот или иной сотрудник, как его найти и как с ним связаться.
Помещения принадлежат определенному подразделению либо вузу как главному подразделению. Подразделение может размещаться не в одном здании. Каждое помещение в рамках здания имеет номер. Обычно это цифровой код - числа по порядку, но возможны и номера с буквами 9а, 12б и т.п.
В некоторых помещениях располагаются телефоны. Телефон может быть местный и/или городской. Один и тот же номер телефона может быть закреплен за разными помещениями. Обычно в одном помещении может быть только один местный телефон.
В помещении могут находится(работать, быть закрепленными) 1 или более сотрудников.
Сотрудник может иметь 1 или более должностей. Вторые должности - совместительство. При этом работая на разных должностях сотрудник может быть закреплен за разными помещениями. Скажем мистер Х - заведующий кафедры Y находится в кабинете №3 в заднии В(Учебно-лабораторный корпус) и местный номер телефона и городской номер телефона. (Чаще всего городской номер закреплен за подразделением). Тот же мистер Х - декант факультета Z - находится в деканате в комнате №56 корпуса А(аудиторный) имея телефон или несколько...
237
О Сайте и Форуме / Добавлена возможность комментирования на сайте
« : 31 Января 2007, 22:53:09 »
Я добавил компонент для комментирования - пока ограничил его разделом книги, просьба добавлять туда свои рекомендации и впечатления, кроме того вы можете заказать через меня отдельные главы для подробного знакомства, которые я буду публиковать параллельно.
238
Нововведения / Популярно об UML 2.0
« : 31 Января 2007, 18:59:40 »
UML 2.0 становится стандартом или уже стал таковым.
Есть публикации, книи, которые рассказывают об этомстандарте. Во многих пакетах есть описание стандарта и сравнение его с предыдущими. Однако мне все равно кое-что не понятно.
Не понятно, например, что такое collaboration и как его использовать. И вообще хотелосьбы узнать как применять новые диаграммы и как они согласуются со старыми
Есть публикации, книи, которые рассказывают об этомстандарте. Во многих пакетах есть описание стандарта и сравнение его с предыдущими. Однако мне все равно кое-что не понятно.
Не понятно, например, что такое collaboration и как его использовать. И вообще хотелосьбы узнать как применять новые диаграммы и как они согласуются со старыми
239
Теория моделирования и нотации / Задача на n-арные связи
« : 28 Января 2007, 20:37:08 »
Вот интересная задача, мозговая разминка для наших посетителей.
Не вдаваясь в подробности всей предметной области, выделим только существенные её факты.
Два юридических лица могут вступать в отношения купли-продажи на основании договора.
В рамках договора одна сторона продает(выступает как продавец), а другая приобретает (выступает как покупатель) некие ценные бумаги. Таким образом, одно и тоже юридическое лицо может быть как продавцом, так и покупателем. Очевидно, что в рамках конкретного договора юридическое лицо может играть только одну роли.
Для отображения юридического лица можно было бы предложить некий класс СубъектДоговора. Можно предложить самоассоциацию с ролями продавец и покупатель и кратностью 1.
Можно предположить, что между СубъектомДоговора и Ценными бумагими - также есть ассоциация с классом ассоциации Договор. Либо указать две ассоциации между СубъектомДоговора и ЦеннойБумагой с ролями - покупается и продается и с классом ассоциацией - Договор.
Проблема - пытался нарисовать этот факт в enterprise architect - не выходит.
Привожу два первичных варианта
Не вдаваясь в подробности всей предметной области, выделим только существенные её факты.
Два юридических лица могут вступать в отношения купли-продажи на основании договора.
В рамках договора одна сторона продает(выступает как продавец), а другая приобретает (выступает как покупатель) некие ценные бумаги. Таким образом, одно и тоже юридическое лицо может быть как продавцом, так и покупателем. Очевидно, что в рамках конкретного договора юридическое лицо может играть только одну роли.
Для отображения юридического лица можно было бы предложить некий класс СубъектДоговора. Можно предложить самоассоциацию с ролями продавец и покупатель и кратностью 1.
Можно предположить, что между СубъектомДоговора и Ценными бумагими - также есть ассоциация с классом ассоциации Договор. Либо указать две ассоциации между СубъектомДоговора и ЦеннойБумагой с ролями - покупается и продается и с классом ассоциацией - Договор.
Проблема - пытался нарисовать этот факт в enterprise architect - не выходит.
Привожу два первичных варианта
240
Сообщество Аналитиков / Рецензии на книги
« : 27 Января 2007, 19:27:35 »
Уважаемые коллеги
Вот у же примерно 2 недели я активно веду переговоры с издательством "Диалектика-Вильямс". Вернее с ее представителем.
Нам сделали такое предложение, которое я попытался реализовать (смотри главную страницу нашего сайта http://www.uml2.ru):
1. издательство дает нам информацию о своих новых книгах
2. Мы публикуем эту инофрмацию у себя на сайте
3. Издательство дает нам несколько глав на ознакомление, которые мы можем разместить в прямом доступе
4. Нам следует давать рецензию, или рекомендации на книгу, которая должна публиковаться в месте где книга аннонсируется, либо указываются ссылки - например на форум, где книга обсуждается
5. Мы можем заключать договоры с магазинами, которые отчисляют нам определенный процент от продажи, если книгу купили при переходе с нашего сайта
6. Через месяц анонса издательство может выслать нам бумажную копию книги в вечное пользование (как я понял бесплатно)
Приглашаю участвовать активно в написании рекомендаций...
Вот у же примерно 2 недели я активно веду переговоры с издательством "Диалектика-Вильямс". Вернее с ее представителем.
Нам сделали такое предложение, которое я попытался реализовать (смотри главную страницу нашего сайта http://www.uml2.ru):
1. издательство дает нам информацию о своих новых книгах
2. Мы публикуем эту инофрмацию у себя на сайте
3. Издательство дает нам несколько глав на ознакомление, которые мы можем разместить в прямом доступе
4. Нам следует давать рецензию, или рекомендации на книгу, которая должна публиковаться в месте где книга аннонсируется, либо указываются ссылки - например на форум, где книга обсуждается
5. Мы можем заключать договоры с магазинами, которые отчисляют нам определенный процент от продажи, если книгу купили при переходе с нашего сайта
6. Через месяц анонса издательство может выслать нам бумажную копию книги в вечное пользование (как я понял бесплатно)
Приглашаю участвовать активно в написании рекомендаций...