196
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
197
Обсуждение статей / Re: Включение вариантов использования
« : 01 Марта 2011, 23:08:30 »
Я прошу извинения за то, что "встрял"!
Конфликт, как я понимаю, исчерпан до моего выступления!
Конфликт, как я понимаю, исчерпан до моего выступления!
198
Обсуждение статей / Re: Включение вариантов использования
« : 01 Марта 2011, 23:04:11 »Отношения включения в uml нет. Есть отношение зависимости со стереотипом include.И все же это отношение включения, которое обозначается как зависимость со стереотипом Include.
Наверное, нет смысла обсуждать реализацию, т.е. каким именно образом "включаемое" поведение "включается" в основное. Если пойти в другие источники, например, RUP, то есть прямые рекомендации планировать реализацию включаемого поведения в план как компонент многоразового использования.
Но, вполне возможно, все это просто перерастет в очередную терминологическую войну.
Я сейчас в Москве, в командировке, справочника под рукой нет!
199
Обсуждение статей / Re: Понятие идеальности скрыто в нюансах
« : 01 Марта 2011, 22:50:08 »
"Костя" поступает на Высшие литературные курсы. Вступительное собеседование:
- Вы читали Достоевского?
- Нет.
- А Вы читали Марка Твена?
- Нет
- А что же Вы читали?
- "Костя" не читатель, "Костя" - писатель!
Думаю, некоторым писателям о взаимоотношениях в бизнесе следует почитать Маркса.
Что касается тонкостей, то есть интересные мысли. Но, увы, не решающие!
- Вы читали Достоевского?
- Нет.
- А Вы читали Марка Твена?
- Нет
- А что же Вы читали?
- "Костя" не читатель, "Костя" - писатель!
Думаю, некоторым писателям о взаимоотношениях в бизнесе следует почитать Маркса.
Что касается тонкостей, то есть интересные мысли. Но, увы, не решающие!
200
Идеи и мозговой штурм / Re: Семья
« : 01 Марта 2011, 22:36:38 »
Минут пятнадцать назад здесь была цитата о гармонии от одного авторитета. Наверное, модераторы вычистили! Я рад.
Я счастливый человек!
Я никогда не занимался тем, что мне не нравится. Наверное, это гармония.
Ida сказала, что ее семья - это команда ее проекта. Я могу сказать про свою семью, что мы одна команда.
У каждого есть своя часть жизни. Из этих частей складывается наша общая жизнь.
Я не IT-ишник, я моряк. Так жизнь сложилась, что стал почти IT-ишником. Как это повлияло на семью? У каждого свой комп, у кого-то два, а то и три (дома, в архив пойти и т.д.) Но фанатик я один.
Жена - журналист, сейчас - "бабка" (или ведьма, кто как называет). И я, и дочка легко "снимаем" боль у знакомых (с кем поведешься!).
Дочка - научный сотрудник в РНБ (с соответствующей зарплатой). Фанатик генеологии. Такую информацию отыскивает - ахнешь!
На каком месте семья?
Без семьи меня нет. Но, на первом месте - работа!
Я счастливый человек!
Я никогда не занимался тем, что мне не нравится. Наверное, это гармония.
Ida сказала, что ее семья - это команда ее проекта. Я могу сказать про свою семью, что мы одна команда.
У каждого есть своя часть жизни. Из этих частей складывается наша общая жизнь.
Я не IT-ишник, я моряк. Так жизнь сложилась, что стал почти IT-ишником. Как это повлияло на семью? У каждого свой комп, у кого-то два, а то и три (дома, в архив пойти и т.д.) Но фанатик я один.
Жена - журналист, сейчас - "бабка" (или ведьма, кто как называет). И я, и дочка легко "снимаем" боль у знакомых (с кем поведешься!).
Дочка - научный сотрудник в РНБ (с соответствующей зарплатой). Фанатик генеологии. Такую информацию отыскивает - ахнешь!
На каком месте семья?
Без семьи меня нет. Но, на первом месте - работа!
201
Системный Анализ и Требования / Re: Описание требований. Много документов или один
« : 17 Февраля 2011, 15:09:32 »
У каждого из тех, кто долго работает в какой-то сфере, вырабатываются свои приемы и стиль.
Я, например, давно не пишу документов, а думаю в терминах модели. И пишу шаблоны генератора отчетов (редко, т.к. наработал структуры моделей и шаблоны для них).
Мне легче рисовать на UML, чем писать, даже во время интервью.
Из одной общей модели можно "нагенерить" множество отчетов самого разного вида, размера и содержания.
А "государственными заказчиками" и ГОСТами, на мой взгляд, пугать не нужно.
1. Там люди. Если эти люди хотят получить хороший продукт, они с пониманием относятся к технологиям. Если им нужен "откат", никакие ГОСТы не помогут.
2. Из хорошей полной модели вполне можно создать "ТЗ-подобный" отчет простым использованием синонимов, соответстующих терминологии ГОСТов.
3. Плюс массу документов для разработчиков.
Ты, Юра, редко доходил до "сторибоарда"? А зря!
Спецификация прецедента на основе диаграммы деятельности (полезная при согласовании требований), при небольшом расширении шаблона может стать "сторибоардом" для разработчика, "тесткейзом" для тестировщика и "руководством пользователя".
И все они актуальны и синхронны.
Производительность труда группы в целом повышается.
Я, например, давно не пишу документов, а думаю в терминах модели. И пишу шаблоны генератора отчетов (редко, т.к. наработал структуры моделей и шаблоны для них).
Мне легче рисовать на UML, чем писать, даже во время интервью.
Из одной общей модели можно "нагенерить" множество отчетов самого разного вида, размера и содержания.
А "государственными заказчиками" и ГОСТами, на мой взгляд, пугать не нужно.
1. Там люди. Если эти люди хотят получить хороший продукт, они с пониманием относятся к технологиям. Если им нужен "откат", никакие ГОСТы не помогут.
2. Из хорошей полной модели вполне можно создать "ТЗ-подобный" отчет простым использованием синонимов, соответстующих терминологии ГОСТов.
3. Плюс массу документов для разработчиков.
Ты, Юра, редко доходил до "сторибоарда"? А зря!
Спецификация прецедента на основе диаграммы деятельности (полезная при согласовании требований), при небольшом расширении шаблона может стать "сторибоардом" для разработчика, "тесткейзом" для тестировщика и "руководством пользователя".
И все они актуальны и синхронны.
Производительность труда группы в целом повышается.
202
Системный Анализ и Требования / Re: Описание требований. Много документов или один
« : 17 Февраля 2011, 00:29:00 »
А "для работы" Вы use cases моделируете? На каком инструменте?
203
Системный Анализ и Требования / Re: Описание требований. Много документов или один
« : 16 Февраля 2011, 23:28:42 »
А Вы никогда не пытались посмотреть, что по этому поводу рекомендует RUP?
Или, например, Коберн?
Или, например, Коберн?
204
Примеры / Re: signal send state в UML. Ищу примеры
« : 15 Февраля 2011, 11:27:22 »
Зачем искать?
Рисуйте сами!
В нужном месте, где посылается сигнал, устанавливайте send.
В другом месте (м.б. даже в другой диаграмме), где сигнал нужно обработать, ставьте accept.
Если Вам нужно моделировать синхронное сообщение, сразу за Send поставьте Accept. Тогда после отправки сигнала действия в первой диаграмме остановятся, пока не будет получен ответ от второй.
На второй диаграмме после получения сигнала, он д.б. обработан (в других действиях), после чего можно постать сигнал в первую диаграмму.
Один и тот же сигнал может приниматься несколькими Accept.
С сигналом д.б. ассоциирован объект, содержащий информацию сигнала.
Этот аппарат может использоваться, например, при моделировании параллельных действий, когда требуется синхронизация.
Рисуйте сами!
В нужном месте, где посылается сигнал, устанавливайте send.
В другом месте (м.б. даже в другой диаграмме), где сигнал нужно обработать, ставьте accept.
Если Вам нужно моделировать синхронное сообщение, сразу за Send поставьте Accept. Тогда после отправки сигнала действия в первой диаграмме остановятся, пока не будет получен ответ от второй.
На второй диаграмме после получения сигнала, он д.б. обработан (в других действиях), после чего можно постать сигнал в первую диаграмму.
Один и тот же сигнал может приниматься несколькими Accept.
С сигналом д.б. ассоциирован объект, содержащий информацию сигнала.
Этот аппарат может использоваться, например, при моделировании параллельных действий, когда требуется синхронизация.
205
Примеры / Re: КАк правильно нарисовать цикл в Activity? на UML 2.0
« : 15 Февраля 2011, 11:07:59 »
Но можно же это сделать правильно!
Создайте "дорожки" для actors и для "системы".
Поместите в них соответствующие действия.
Создайте "дорожки" для actors и для "системы".
Поместите в них соответствующие действия.
206
Примеры / Re: КАк правильно нарисовать цикл в Activity? на UML 2.0
« : 14 Февраля 2011, 14:04:53 »
В UML2 (в отличие от UML) есть специальный модельный элемент объединения (merge). Если маркер приходит на узел объединения по одному из входов, он немедленно копируется на выход.
Присоединять два входа к действию можно. Но действие не начинается, пока маркеры не поступили на все входы (например, при параллельных вычислениях), т.е. это похоже на join.
В UML1 поведение действия со множеством входов не описано. UML2 разрабатывался под MDA (преобразование в код требует формализма)!
Т.о., цикл, когда возврат идет непосредственно в действие, выполняться не будет, т.к. маркер никогда не выйдет из действия.
Merge обозначается ромбиком, как "разветвление", но инструменты, поддерживающие MDA. имеют отдельный элемент.
Если инструмент не поддерживает MDA, но хочется соблюсти правила UML2, рисуют decision на месте merge.
Ну, а можно рисовать вообще в стиле UML1 (картинка на Вас не обидится).
P.S.
Мне непонятны actors, соединенные с действиями пунктирными линиями с треугольными стрелками ("реализация"). В UML такого нет!
Присоединять два входа к действию можно. Но действие не начинается, пока маркеры не поступили на все входы (например, при параллельных вычислениях), т.е. это похоже на join.
В UML1 поведение действия со множеством входов не описано. UML2 разрабатывался под MDA (преобразование в код требует формализма)!
Т.о., цикл, когда возврат идет непосредственно в действие, выполняться не будет, т.к. маркер никогда не выйдет из действия.
Merge обозначается ромбиком, как "разветвление", но инструменты, поддерживающие MDA. имеют отдельный элемент.
Если инструмент не поддерживает MDA, но хочется соблюсти правила UML2, рисуют decision на месте merge.
Ну, а можно рисовать вообще в стиле UML1 (картинка на Вас не обидится).
P.S.
Мне непонятны actors, соединенные с действиями пунктирными линиями с треугольными стрелками ("реализация"). В UML такого нет!
207
Обучение / Re: Системный аналитик курсы
« : 12 Февраля 2011, 20:26:40 »
Да, понимаю. И непременно, в банк!
Думаю, системными аналитиками не рождаются. Системными аналитиками становятся. И после самых замечательных курсов с самым замечательным сертификатом Вас, скорее всего, не возьмут системным аналитиком в банк, если Вы еще не стали системным аналитиком.
А, может быть, это вообще Вам не подходит?
Наверное, нужно пойти в какую-нибудь компанию, я видел объявления, помощником аналитика, посмотреть, что это такое. Кстати, м.б., и платить за обучение не придется, увидят, что Вы перспективный системный аналитик, на халяву учиться пошлют! А потом и в банк!
А с моей точки зрения, системный аналитик - это диагноз.
Думаю, системными аналитиками не рождаются. Системными аналитиками становятся. И после самых замечательных курсов с самым замечательным сертификатом Вас, скорее всего, не возьмут системным аналитиком в банк, если Вы еще не стали системным аналитиком.
А, может быть, это вообще Вам не подходит?
Наверное, нужно пойти в какую-нибудь компанию, я видел объявления, помощником аналитика, посмотреть, что это такое. Кстати, м.б., и платить за обучение не придется, увидят, что Вы перспективный системный аналитик, на халяву учиться пошлют! А потом и в банк!
А с моей точки зрения, системный аналитик - это диагноз.
208
Управление Проектом / Re: Особенности работы с госзаказчиками
« : 12 Февраля 2011, 15:28:13 »
Здравствуйте, Ida!
Полностью согласен с Водолеем: нужно привлекать Заинтересованных лиц. И "манипулировать" ими. В TOGAF это называется "управление заинтересованными лицами".
Какие бы интересы ни были у различных представителей заказчика, среди них есть люди (или человек), который, скорее всего, является автором идеи проекта и который больше всех заинтересован в результатах работы. Отстаивая свои интересы, он будет отстаивать и Ваши, если будет Вам доверять.
Пример из личного опыта.
В одном из учреждений Администрации Санкт-Петербурга (Заказчик) решили разработать систему для управления своими районными филиалами и оказанием услуг в этих филиалах. В качестве базовой была принята система, уже несколько лет функционировавшая в одном из филиалов и разработанная Исполнителем.
Заказчик предложил Исполнителю разработать систему по ТЗ, разработанному чиновниками (бывшими работниками оборонки). К ТЗ был приложен Календарный план.
Представитель Исполнителя эти документы плюс Контракт подписал!
Ситуация, почти как у Вас.
Есть жесткие документы, по которым невозможно сделать систему. (К счастью, в ТЗ требования были представлены на достаточно высоком уровне.)
У исполнителя не сохранилось никаких документов по старой системе, а люди уже уволились. Пришлось нанимать людей под проект.
У руководства Исполнителя единственное требование - чтобы Заказчик был доволен.
Усилия были направлены на работу с руководством филиала, определенного как "опытный полигон" и с инициатором проекта, одним из руководителей учреждения.
Удалось убедить, что требования ТЗ недостаточно конкретны, и их надо детализировать. А т.к. "детализация" - это "изменение", удалось убедить в необходимости создания и включения в перечень "неразрывно связанных с Контрактом" документа "Правила управления требованиями" (аналог плана управления требованиями RUP). Вводились правила упрощенного процесса согласования изменений требований, если они не вступают в противоречия в ТЗ.
Утвержденный ("водопадного" вида) План содержал (к счастью) этап Эскизного проектирования (все по ГОСТ!). Удалось убедить детализацию требований включить в отчет Эскизный проект (чтобы основополагающее ТЗ не менять!
И, в заключение, удалось убедить, что Заказчик заинтересован в пошаговой поставке функциональностей.
Ну, а дальше работа пошла по "нашим" правилам.
Документ под названием "Эскизный проект - общий отчет" - по шаблону RUP Vision.
Документ "Эскизный проект - Приложение №..." - это Use case Specification.
Согласование документов, быстрая реакция на замечания (документы небольшие!) увеличивало доверие.
Архитектурой заниматься почти не пришлось (модернизация старой системы), Поставки функциональностей пошли почти сразу за спецификациями.
Поставки сопровождались руководствами пользователей (отредактированные спецификации). Доверие было обеспечено. Окончательная сдача трудностей не вызвала: в филиале-полигоне система уже работала.
Конечно, не все было так просто и радужно. Но проблему удалось решить без большой крови.
P.S. Относительно технологии управления заинтересованными лицами: если Вам лень искать это в TOGAF (на английском), Вы можете посмотреть мой опус, посвященный моделированию заинтересованных лиц: http://lnew.ucoz.ru/publ/modelirovanie_arkhitektury_predprijatija/arkhitekturnye_karkasy/modelirovanie_zainteresovannykh_lic_v_togaf/4-1-0-5
Полностью согласен с Водолеем: нужно привлекать Заинтересованных лиц. И "манипулировать" ими. В TOGAF это называется "управление заинтересованными лицами".
Какие бы интересы ни были у различных представителей заказчика, среди них есть люди (или человек), который, скорее всего, является автором идеи проекта и который больше всех заинтересован в результатах работы. Отстаивая свои интересы, он будет отстаивать и Ваши, если будет Вам доверять.
Пример из личного опыта.
В одном из учреждений Администрации Санкт-Петербурга (Заказчик) решили разработать систему для управления своими районными филиалами и оказанием услуг в этих филиалах. В качестве базовой была принята система, уже несколько лет функционировавшая в одном из филиалов и разработанная Исполнителем.
Заказчик предложил Исполнителю разработать систему по ТЗ, разработанному чиновниками (бывшими работниками оборонки). К ТЗ был приложен Календарный план.
Представитель Исполнителя эти документы плюс Контракт подписал!
Ситуация, почти как у Вас.
Есть жесткие документы, по которым невозможно сделать систему. (К счастью, в ТЗ требования были представлены на достаточно высоком уровне.)
У исполнителя не сохранилось никаких документов по старой системе, а люди уже уволились. Пришлось нанимать людей под проект.
У руководства Исполнителя единственное требование - чтобы Заказчик был доволен.
Усилия были направлены на работу с руководством филиала, определенного как "опытный полигон" и с инициатором проекта, одним из руководителей учреждения.
Удалось убедить, что требования ТЗ недостаточно конкретны, и их надо детализировать. А т.к. "детализация" - это "изменение", удалось убедить в необходимости создания и включения в перечень "неразрывно связанных с Контрактом" документа "Правила управления требованиями" (аналог плана управления требованиями RUP). Вводились правила упрощенного процесса согласования изменений требований, если они не вступают в противоречия в ТЗ.
Утвержденный ("водопадного" вида) План содержал (к счастью) этап Эскизного проектирования (все по ГОСТ!). Удалось убедить детализацию требований включить в отчет Эскизный проект (чтобы основополагающее ТЗ не менять!
И, в заключение, удалось убедить, что Заказчик заинтересован в пошаговой поставке функциональностей.
Ну, а дальше работа пошла по "нашим" правилам.
Документ под названием "Эскизный проект - общий отчет" - по шаблону RUP Vision.
Документ "Эскизный проект - Приложение №..." - это Use case Specification.
Согласование документов, быстрая реакция на замечания (документы небольшие!) увеличивало доверие.
Архитектурой заниматься почти не пришлось (модернизация старой системы), Поставки функциональностей пошли почти сразу за спецификациями.
Поставки сопровождались руководствами пользователей (отредактированные спецификации). Доверие было обеспечено. Окончательная сдача трудностей не вызвала: в филиале-полигоне система уже работала.
Конечно, не все было так просто и радужно. Но проблему удалось решить без большой крови.
P.S. Относительно технологии управления заинтересованными лицами: если Вам лень искать это в TOGAF (на английском), Вы можете посмотреть мой опус, посвященный моделированию заинтересованных лиц: http://lnew.ucoz.ru/publ/modelirovanie_arkhitektury_predprijatija/arkhitekturnye_karkasy/modelirovanie_zainteresovannykh_lic_v_togaf/4-1-0-5
209
ПО Аналитика / Re: Как отобразить в Rational Software Modeler ....
« : 10 Февраля 2011, 22:53:20 »
Спасибо, Денис. Я действительно смотрел свой старый перевод спецификации, и, кроме того, не очень точно сформулировал мысль.
К сожалению, это не меняет сути. Особенно для Varg.
В Вашей цитате из спецификации говорится, что значок состояния - это альтернативное представление ограничения.
И далее говориться, что если поведение класса описывается машиной состояний, и мы хотим в качестве ограничения представить внутреннее состояние, то его название должно соответствовать одному из определенных состояний.
В остальном я, кажется, не "накривил".
Т.е. инвариант состояния представляет ограничение, в простейшем случае действующее как я написал в предыдущем письме. (В примере приведен более сложный случай).
И второй вывод - Rational выполнил спецификацию: есть два варианта нотации, и предлагается ввести текст ограничения и, не обязательно, название. Название может отражать состояние объекта.
М.б. им следовало предоставить опцию использования значений внутренних состояний, но в спецификации этого не предусмотрено.
К сожалению, это не меняет сути. Особенно для Varg.
В Вашей цитате из спецификации говорится, что значок состояния - это альтернативное представление ограничения.
И далее говориться, что если поведение класса описывается машиной состояний, и мы хотим в качестве ограничения представить внутреннее состояние, то его название должно соответствовать одному из определенных состояний.
В остальном я, кажется, не "накривил".
Т.е. инвариант состояния представляет ограничение, в простейшем случае действующее как я написал в предыдущем письме. (В примере приведен более сложный случай).
И второй вывод - Rational выполнил спецификацию: есть два варианта нотации, и предлагается ввести текст ограничения и, не обязательно, название. Название может отражать состояние объекта.
М.б. им следовало предоставить опцию использования значений внутренних состояний, но в спецификации этого не предусмотрено.
210
ПО Аналитика / Re: Как отобразить в Rational Software Modeler ....
« : 10 Февраля 2011, 18:48:39 »
Я еще раз внимательно прочитал спецификацию UML.
Инвариант состояния к диаграмме состояний, к сожалению, отношения не имеет.
Инвариант состояния - это условие, которое должно исполняться на протяжении периода активности этого состояния.
На линии жизни период активности состояния сохраняется между точками вхождения сообщений.
Т.е. если между двумя точками вхождения указано {f>0}, то во всех отправляемых между этими точками сообщениях будет использовано f>0. Вместо {f>0} может быть {состояние="РАбота"}.
Или искать другое решение. Увы!
Инвариант состояния к диаграмме состояний, к сожалению, отношения не имеет.
Инвариант состояния - это условие, которое должно исполняться на протяжении периода активности этого состояния.
На линии жизни период активности состояния сохраняется между точками вхождения сообщений.
Т.е. если между двумя точками вхождения указано {f>0}, то во всех отправляемых между этими точками сообщениях будет использовано f>0. Вместо {f>0} может быть {состояние="РАбота"}.
Или искать другое решение. Увы!