796

Обучение / Re: Компетенции в области архитектуры информационных систем

« : 21 Января 2014, 10:55:50 »

Мне не нравится определение ieee 1471. Из него непонятно, что относить к архитектурным решениям.

Концепция нравится- не нравится тут не очень подходит. Сергей, не уводи дискуссии в сторону. Мы говорим о компетенциях. Определение архитектуры оставим в стороне. Зачем выдумывать то, чего нет. Все сообщество Земли не стоит твоего мнения? Пусть.

Как я понимаю, ты считаешь, что студент должен понимать последствия архитектурной ошибки, различать архитектурные ошибки и уметь их не осуществлять (предвидеть)?

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

Итак мы ставим еще одну компетенцию: знать что такое UDDI и уметь что? описывать расположение веб-служб? каков контекст компетенции?

797

Обучение / Re: Компетенции в области архитектуры информационных систем

« : 20 Января 2014, 23:04:08 »

Угу, согласен. Довольно сложно определить, какие вещи относятся к архитектуре, а какие нет. В умах, к несчастью, разруха и хаос.
Определение из википедии "Архитектура программного обеспечения (англ. software architecture) — это структура программы или вычислительной системы, которая включает программные компоненты, видимые снаружи свойства этих компонентов, а также отношения между ними." Выглядит красиво, но совершенно бесполезно.

Любишь ты такие провокационные заявления.

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

Звучит недурно. А какого соглашения ты от меня ждешь?

ieee 1471 Дает такое определение
фундаментальная организация системы воплощенная через свои компоненты, связи между ними и ее окружением, а также принципы, руководящие ее проектированием и развитием.

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

Каждое из этих понятий естественно можно актуализировать через понятие последствие от ошибки. Очень хорошо.
Как это должно противоречить понятию архитектуры. Мы обсуждает это понятие?

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

798

Обучение / Re: Компетенции в области архитектуры информационных систем

« : 20 Января 2014, 13:55:54 »

Есть гипотеза: "Если человек не пишет код в течении года, он перестает быть архитектором." Но в этой гипотезе, скорее, имеется ввиду низкоуровневая архитектура.

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

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

А вот что нужно знать для высокоуровневой...
* В каких случаях нужно использовать UDDI? А для чего?

http://ru.wikipedia.org/wiki/UDDI/ - т.е. без этого специалист не специалист?

* Как версионируется система из десятка компонент? (в частности, по версиям протоколов обмена)

Если честно не понял, к чему это? Разве версионирование - это не вопрос проектирования и разработки?

* Почему не стоит хранить в БД ни пароли, ни хеши паролей? И где их хранить?

А причем тут архитектура?

* Почему автоинкремент идентификаторов must die?

Опять же причем тут архитектура? Если причем то хотелось бы услышать

* Во сколько раз увеличивается стоимость разработки при переходе от централизованной БД к распределенке?

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

799

Обучение / Компетенции в области архитектуры информационных систем

« : 20 Января 2014, 12:06:28 »

Друзья,

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

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

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

Например:
знать и понимать, что такое архитектура системы
знать архитектурные стили систем различного масштаба
знать атрибутно-ориентированный метод разработки архитектуры
....

800

Примеры / Re: Помогите срочно! Пожалуйста

« : 18 Января 2014, 19:40:01 »

Диаграмму рисовать несложно. Сначала нужно определится:
1. кто будет действующими лицами (т.е. те, кто выполняет варианты)
судя по вашему описанию - это администратор
2. другие внешние системы, к которым приходится обращаться для выполнения задач основного действующего лица
у вас возможно электронная система платежей
3. определить какие задачи решает администратор используя систему (это и варианты использования)
- Оформить услугу, оказанную клиенту
- Зарегистрировать данные клиента
- Оформить абонемент на посещение салона
- Вести список сотрудников
- Вести список оказываемых услуг
- Получить информацию об оказываемых услугах
4. Каждое ДЛ следует описать - по принципу словаря, дать определение
5. Каждый ВИ следует описать в известном вам формате - Наименование, Основной поток, Альтернативные потоки - это у вас есть только оформить нужно

Диаграмма может выглядеть так

801

Задачи студентов / Re: Игра "Дурак"

« : 18 Января 2014, 14:37:04 »

Огромное спасибо за помощь. Курсовую сдал, во всём разобрался(в т.ч. и с ДП)

Молодец

802

Термины и Определения / Re: [Термин] Информационная система

« : 17 Января 2014, 23:02:18 »

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

Небольшая цитата:

"Существует 4 типа объектов, которые могут быть определены как ИС.

ИС1 - организация (автономная система), чей бизнес (цели) заключается в обеспечении информацией своих клиентов

ИС2 - подсистема существующая в любой системе, которая способна саморегулироваться (автономная система)

ИС3 -  любая комбинация активных объектов (процессоров), работающая только с символическими объектами (информацией)  и основной частью которых являются компьютеры или устройства - т.е. автоматизированная система

ИС4 - любая комбинация активных объектов (процессоров), работающая только с символическими объектами (информацией)"

803

ПО Аналитика / Re: ELMA для управления бизнесом. FAQ, новые «фишки», уникальные возможности

« : 17 Января 2014, 11:50:17 »

Да, большое спасибо за ответ.

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

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

Мой опыт использования Comindware, BizAgi, Unify показал, что это выполнить там практически невозможно, а если возможно, то только с привлечением компании разработчика. А в Вашем случае это обеспечивается как-то? Или все вопросы интеграции осуществляются только с вашим участием?

И последнее, можно ли сказать, что ваша система отвечает SOA? Или я пальцем в небо?

Спасибо

804

ПО Аналитика / Re: ELMA для управления бизнесом. FAQ, новые «фишки», уникальные возможности

« : 16 Января 2014, 13:25:37 »

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

Да, именно это и хотелось бы услышать. Как это происходит? Можно какие-то примерчики?

805

ПО Аналитика / Re: ELMA для управления бизнесом. FAQ, новые «фишки», уникальные возможности

« : 15 Января 2014, 17:02:15 »

Разрешите внести уточнение, мы всё-таки позиционируем себя как система управления бизнес-процессами.

Уточнение принимается Извините.
А если образно, о в чем отличие управления бизнес-процессами от управления задачами (работами)? Разве БП - не последовательность задач, работ?

По поводу Голдратта - да, такая возможность в ELMA заложена. Возможность непрерывного совершенствования - одно из главных преимуществ системы. Реализовать в системе можно произвольную модель управления,  стоит только ее настроить в самом начале работы, в дальнейшем ее можно развивать без длительных остановок системы, для этого есть всё необходимое.

На Comindware нам это сделать полностью не удалось. Это связано с особенностью виджетов Comindware. Больше удалось сделать с BizAgi Studio.
Однако думаю тут проблема в исходном процессе и невозможностью получить реальную рабочую нагрузку на систему

Дальше, если сравнивать с Comindware Tracker, наша система имеет другую архитектуру, на мой взгляд, более понятную. Взять хотя бы KPI. У нас очень интересная система мотивации, которая также предполагает возможность выбора механизма оценки.

Ну это понятно, и это мы узнаем в ходе будущей работы:)

806

Задачи студентов / Re: Игра "Дурак"

« : 14 Января 2014, 11:39:54 »

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

Если честно, мне твой ответ не понятен. Понимаешь - интерфейс, как и абстрактный класс только декларирует сигнатуру методов, их реализацию берет на себя конкретный класс. Как может класс реализовывать интерфейс по модели и не делать его по факту? Зачем тогда рисовать диаграмму? Странно.

но дело даже не в этом. Я не могу понять, как строить диаграмму последовательности. Все остальные диаграммы уже построил, правильно/неправильно - но я хотя бы понимал, что я делаю, как, для чего и зачем(ниже примеры). С диаграммой последовательности - полный ноль. Вроде бы всё просто, берёшь поток событий и строишь, но когда доходит до дела - дело не движется. Не могли бы вы объяснить мне, с чего вообще стоит начать?

Диаграммы последовательностей строят для изображения сценария решения какой-то задачи. ДП строят для потоков вариантов использования и они описывают протокол взаимодействия объектов, участвующих в реализации определенного поведения классов.
Например, ты описываешь сценарий Разыграть раздачу (ну первый ход от захода игрока до отбоя или завала другого игрока)
1. В сценарии участвуют Игроки как действующие лица -actor
2. В сценарии участвуют Игроки - как объекты хранящие определенное состояние игры и обладающие каким-то внутренним поведением
3. В сценарии участвуют классы: карты, Игра что-то еще, что также сохраняет некоторое состояние игры и обладает каким то поведением
4. в Сценарии участвуют (должны) классы которые отвечают за управление (но не имеют состояния и ничего не хранят - транзиентные классы) и за взаимодействие с внешними по отношению к программе сущностями - т.е. например GUI - формы, контролы и т.п. - граничные классы

Все это хозяйство и используется для построение диаграмм последовательности и показывают ПОСЛЕДОВАТЕЛЬНОСТЬ обмена сообщениями(вызовами методов) между объектами (инстансами классов) - ghbvths http://www.uml-diagrams.org/sequence-diagrams-examples.html

807

Задачи студентов / Re: Игра "Дурак"

« : 14 Января 2014, 10:52:32 »

Следующую диаграмму классов преподаватель оценил как нормальную (правда в подробности особо не вникал)

Ну думаю, преподаватель увидел основные моменты в реализации твоей диаграммы классов. Видимо впечатлился:)
Мне только не понятен момент реализации интерфейса Play - почему класс Игрок содержит все методы этого интерфейса, а класс Game, который тоже реализует интерфейс Play нет?

808

ПО Аналитика / Re: ELMA для управления бизнесом. FAQ, новые «фишки», уникальные возможности

« : 13 Января 2014, 21:46:59 »

ELMA в основном позиционируется как система управления работами: выдать или принять задание, организовать маршрут его выполнения, проконтролировать дисциплину выполнения и в конечном итоге оптимизировать процесс (возможно).
Интересно можно ли реализовать алгоритм Голдрата (описанный им в книге Цель) или иную модель управления?

Можно ли дать сравнительную оценку с Comindware Tracker (здесь наш опыт его использования - статья в материалах конфренции http://objectsystems.ru/objectsystems2013/)

809

Проектирование / Re: Archimate: примеры использования

« : 13 Января 2014, 17:24:13 »

Эдуард, добрый вечер! Тема интересная. А по каким критериям был выбран именно Archimate, а не упомянутый UML или что-то другое? Чем он лучше для обучения студентов?

Сергей, добрый вечер.
Раньше я ответил формально, теперь я могу немного ответить более точно. Частично мой ответ сформирован по прочтению этого материала:  http://ailev.livejournal.com/988360.html, частично по прочтении других книг и раздумий.

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

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

Кроме того в отличии от UML, archimate имеет определенную методологическую составляющую. Нет типов и видов диаграмм, но есть слои и четкое разделение на пассивные и активные элементы. Причем матрица получает очень небольшая - 9 ячеек + две кроссобласти. При этом в отличии от того же UML, Archimate мотивирует проектировщика начинать от первопричин, т.е. людей.

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

810

Задачи студентов / Re: Игра "Дурак"

« : 12 Января 2014, 16:51:02 »

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

1. Т.е. хотите сказать, что класс Main_Menu здесь не нужен?

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

2. Т.е. Play должен быть интерфейсом? Связь реализации от Game к Play?

Ну, а что еще есть в классе Play - только поведение, какой смысл это поведение отображать в отдельном классе? Только если мы предполагаем будущую модификацию с одной стороны, а  с другой стороны это точно определяет поведение. И опять же все это так же как Menu - есть классы приложения. Мы же пока строим модель предметной области.

4. Ассоциация 1 ко многим?

Дело не в ассоциации. Карты могут находится на руках у игроков, могут быть в отбое, могут быть в колоде. Каким образом ты собираешься все это отражать в игре?

6. Эти методы реализованы в Play. Или они должны быть в Player, а в Play просто реализован класс Game?

А чем в твоем случае отличается Play Game и Player?