Последние сообщения

Страницы: 1 2 3 4 5 6 7 8 9 10
2
Интересный ресурс -- столько разных диаграммок.
Спасибо, Vadim! [Без шуток.]
3
В компанию ООО "СИБУР ИТ" (IT подразделение ПАО "СИБУР Холдинг" (https://www.sibur.ru/) требуется Архитектор производственной системы MES (г. Тюмень)

Обязанности:
• Управление изменениями в бизнес-приложениях (MES, LIMS) и инфраструктуре на предприятиях Холдинга (акцент на взаимодействие с «Функцией эффективности производства» (ФЭП) ООО «СИБУР»);
• Актуализация шаблона (типовых решений) MES;
• Взаимодействие с вендорами и системными интеграторами по изменениям и проблемам (нужен технический английский язык);
• Функциональный и системный анализ данных, метаданных и процессов в системе, требований, приживаемости системы;
• Регламентация ИТ-процессов и автоматизируемых производственных процессов;
• Архитектурная проработка новых и смежных инициатив (Система дистанционного контроля промышленной безопасности, машинное обучение, Real Time Optimization, Единый реестр событий и портал ФЭП, «Цифровой завод Запсибнефтехим», Единая диспетчерская управления цепями поставок и др.);
• Организация доступа к системам и выгрузки данных по запросу от пользователей ФЭП (Тюмень);
• Обучение пользователей ФЭП (Тюмень) MES, LIMS;
• Перспектива – через 2-3 года стать локальным архитектором производственных систем «Запсибнефтехима», после завершения его строительства и старта внедрения соответствующих систем.

Требования:
• Высшее техническое образование;
• Опыт во внедрении и/или сопровождении бизнес-приложений – от 3 лет;
• Знание языка SQL (MSSQL, Oracle: умение писать простые запросы, анализировать БД);
• Знание базовых технологий Microsoft Windows Server (RDP, IIS, .NET);
• Опыт участника процессов ИТ-сервиса (управление ЗНО, ЗНИ);
• Знание (и опыт) основ проектирования, шаблона MES (URS/FDS);
• Умение (и опыт) писать технические тексты (ТЗ, инструкции, методики);
• Разговорный технический английский;
• Аналитический склад ума, самоорганизация, активная жизненная позиция, желание развиваться.

Условия:
• Работа на территории работодателя (г. Тюмень)
• Оформление по ТК РФ;
• Заработная плата по результатам собеседования;
• Материальная помощь в трудных ситуациях и к значимым событиям;
• Расширенный соц.пакет (ДМС, скидки на спорт, льготное кредитование в банках-партнерах, оздоровление сотрудников и их детей в корпоративном центре отдыха);
• Возможность профессионального развития, обучение в Корпоративном университете, дистанционные курсы;
• График работы 5/2 (сб, вс выходной), с 9 до 18.

Контакты для связи:
Тел.: +7(3822)28-10-10 (доб. 13-14)
E-mail: stebaylovayua@tnhk.sibur.ru 
4
любой объект может изменить свой подкласс, например суперкласс - Человек, подклассы - Одинок, В браке, Разведен, Вдов
Есть такой диалект - ontoUML. Там стереотип <<Phase>> означает, что подкласс может меняться.
По ссылке пример прямо в тему:
https://ontouml.org/ufo/wiki/catalogue-ontological-patterns/phase-partition-pattern/
5
CloudLab.ru - компания-разработчик программного обеспечения.
Основные наши специализации:
  • BI
  • Корпоративные порталы
  • Заказная разработка

Ищем бизнес-аналитика на интересные проекты.

Обязанности:
  • Встречи с заказчиком. Сбор требований и их формализация в виде ТЗ и постановок разработчикам.
  • Формализация существующих и разработка новых бизнес-процессов.
  • Разработка проектной документации.
  • Разработка макетов интерфейсов
  • Работа с BI-инструментами

Требования:
  • Опыт работы в роли аналитика (не важно как называлась ваша позиция).
  • Самостоятельность и обучаемость.
  • Знание SQL на уровне "select from where".
  • Word, Excel, Visio.
  • Желательно знание UML.
  • Знание английского языка на уровне чтения технической литературы.

Условия:
  • От 80 000руб на руки.
  • Возможность работы из дома.
  • График: обсуждается
  • Возможен рост до руководителя проектов.
6
На "нормальной" старшинство по отношению к "хвосту" было бы размечено композицией / агрегацией.
Согласен с необходимостью внести на диаграмму (в модель) для ассоциации между Student и Classification какой-то "несимметричности".
Как вариант - конец при Student {readOnly} для обозначения
Смена типа студента состоит в том, что один "хвост" ему отрезают, а другой -- пришивают.
- студент может сменить "хвост", а "хвост" не может сменить студента - только "умереть", освободив место для свежерождённого "хвоста". И maxCourceLoad можно переместить в Student, чтобы не передавать его значение из старого "хвоста" в новый.
7
Реализация / Re: Композиция, Агрегация
« Последний ответ от [прилетело НЛО и...] 21 Января 2018, 04:12:04 »
"Don’t worry about the diamonds" -- наставляет Скот Амблер в своём "The Elements of UML 2.0 Style". При этом на его диаграмму из сопроводиловки лучше не смотреть, чтобы не терзаться популярным на здешней планете вопросом: "А что у Вас, ребята, в головах?"
8
Это тоже вариант. У него свои недостатки
Цитировалась та картинка, что нашлась в сети.
На "нормальной" старшинство по отношению к "хвосту" было бы размечено композицией / агрегацией.
9
Многие UML-модели делаются так, как-будто типы экземпляров статичны (с единственной поблажной имени Барбары Лисковы). Например, в классическом RUP-овом примере от Rational используется делегирование, чтобы показать, что студенты бывают разных типов и могут менять свой тип:
Это тоже вариант. У него свои недостатки:
  • громоздко
  • если представить, а Student имеет подклассы, например Left и Right, то будет непонятно: 1) это Student может менять FullTime на PartTime и обратно, а Classification нарисована, чтобы помочь это показать или 2) это Classification может менять Left на Right и обратно, а Student нарисован, чтобы помочь это показать
Смена типа студента состоит в том, что один "хвост" ему отрезают, а другой -- пришивают.
Причем отрезанный "хвост" надо сразу уничтожить, а пришиваемый - прямо перед "этим" (или даже в ходе "этого") создать, да ещё с тем же значением maxCourceLoad!
Если требуется комментарий к решению с powertype, то он есть в книжке Milicev "MDD with xUML". В таком ключе: powertype придумали бизнес-аналитики, пусть они им и пользуются.
Перечитал Milicev "MDD with xUML". Он просто своим OOIS UML никак не обрабатывает powertype, поэтому тоже не знает, может ли объект менять тип (или считает, что всегда не может).

Есть такой диалект - ontoUML. Там стереотип <<Phase>> означает, что подкласс может меняться.
10
UML, на моей планете), предпочитает не касаться вопроса о том, может ли менять свой тип экземпляр класса. С него достаточно, что он позволяет через запятую указать несколько не конфликтующих (текущих) типов экземпляра (в этом месте у многих кодеров может взорваться мозг). Но это _имеющиеся_ у экземпляра типы. Может ли объект менять тип -- это свойство ОО-среды реализации, например, OO-языка программирования. Многие UML-модели делаются так, как-будто типы экземпляров статичны (с единственной поблажной имени Барбары Лисковы). Например, в классическом RUP-овом примере от Rational используется делегирование, чтобы показать, что студенты бывают разных типов и могут менять свой тип:

Смена типа студента состоит в том, что один "хвост" ему отрезают, а другой -- пришивают.

Мне нравится, как легко "развинчивается" UML. Достаточно взять примитивы языка и соединить в таком сочетании, которое авторы языка / стандарта / книг на публике не использовали. И вуаля.
Если требуется комментарий к решению с powertype, то он есть в книжке Milicev "MDD with xUML". В таком ключе: powertype придумали бизнес-аналитики, пусть они им и пользуются.
Страницы: 1 2 3 4 5 6 7 8 9 10