361
Теория моделирования и нотации / Re: Реинжиниринг АСУ. Выбор нотаций.
« : 26 Сентября 2008, 16:36:35 »...понять что и как работает...
...
...Внимательно поизучав структурные диаграммы UML...
А поведение как описывать будете?
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
А поведение как описывать будете?
362
ПО Аналитика / Re: Посоветуйте простой редактор
« : 18 Сентября 2008, 13:02:01 »
MS Visio + stencils. Например, http://softwarestencils.com/
363
Сообщество Аналитиков / Re: [Встреча] Сообщества 12 сентября 2008 г. в 19:00
« : 11 Сентября 2008, 18:33:03 »364
Сообщество Аналитиков / Re: [Встреча] Сообщества 12 сентября 2008 г. в 19:00
« : 11 Сентября 2008, 15:11:33 »Это петроградская? ... не знал, хоть и работал в ВТБ.Да, пролетарская, ошибся...
Похоже ничего не получится с пятницей. Вчера температура поднялась. Думал оклемаюсь, а пол-часа назад врач поставил диагноз - ангина. Так что я никуда не поеду. Буду дома лечится.
Сорри, что так вышло. Тренинг перенесут на пару недель, может тогда получится...
365
Сообщество Аналитиков / Re: [Встреча] Сообщества 12 сентября 2008 г. в 19:00
« : 11 Сентября 2008, 13:11:07 »На петроградской? А это где?
366
Сообщество Аналитиков / Re: [Встреча] Сообщества 12 сентября 2008 г. в 19:00
« : 11 Сентября 2008, 10:44:04 »
в 18 буду на петроградской.
367
Сообщество Аналитиков / Re: [Встреча] Сообщества 12 сентября 2008 г. в 19:00
« : 10 Сентября 2008, 17:35:11 »
У меня только в 18 заканчивается тренинг...
368
Методологии / Re: Классификация моделей разработки ПО
« : 05 Сентября 2008, 17:14:12 »оказалось, что ЭТО - на уровне личных наработок,
изложить которые в общем виде у автора не получается,
ЭТО, RUP и пр. - это СЛЕДСТВИЯ.
Разве вам не интересно подумать про ПРИЧИНЫ. Именно мое видение ПРИЧИН я описал в "предыдущем посте".
А про ЭТО есть книга. Рамбо и Блаха.
2) отсутствие четкого понимания используемых терминов "Аналитическая модель приложения и Проектная модель", вне контекста RUP ...
Ну что же. Повторение - мать ученья.
Модель, которая имеет место быть после завершения фазы анализа принято называть Аналитической моделью.
Модель, которая имеет место быть после завершения фазы проектирования принято называть Проектной моделью.
За деталями к известной книге.
369
Методологии / Re: Классификация моделей разработки ПО
« : 05 Сентября 2008, 00:36:22 »Реально ничего не понял из пояснения "прошлым постом" ... таки где "Аналитическая модель приложения и Проектная модель"?"Прошлым постом" я выразил свое мнение о том, каким образом создаются Процессы и считаю, что ... скажем так ... алгоритм их создания примерно одинаков и зависит только от креативности авторов, их опыта и пр.
"Аналитическая модель приложения и Проектная модель" - это артефакты, которые являются выходами различных видов деятельности. В частности "Анализа" и "Проектирования".
У разных авторов одни и те же модели могут носить различные названия. У RUP это, например, "Модели анализа, дизайна и имплементации".
Позволю себе не согласиться с изменением постановки вопроса и настаиваю на первоначальной формулировке .... чем ЭТО отличается от RUP? Задаю прямой и четкий вопрос, и прошу на него столь же четкий и прямой ответ.
Если под ЭТИМ подразумевается Процесс, описанный Блахом и Рамбо, то прямой и четкий ответ я дать не могу, так как не силен в RUP.
Что касается переформулировки вопроса, то я просто хотел обратить внимание, что по моему мнению выбор Процесса не должен повлиять на результат (с точность до именований фаз, артефактов и пр.).
В результате ведь получится модель?
Рисовать то ее (всю или часть) будем на UML (или на SysML или в другой нотации)?
А нотации к Процессам никак не привязаны (раньше это было не так).
370
Методологии / Re: Классификация моделей разработки ПО
« : 04 Сентября 2008, 22:30:21 »1. Ссылочки, где это описано у "знающих людей",Сложно сказать. Книжки читаешь, работаешь, ну и складывается впечатление....
2. Что лично Вы подразумеваете под приведёнными классами моделей?Аналитическая модель после анализа.
Проектная модель после проектирования.
При этом конечно задачи данных фаз надо иметь в виду.
А так Эдуард дал правильную ссылку. Заметьте кстати, один из авторов этой книги - автор RUP, но о нем (о RUP) даже не упоминает.
3. Какое лично у Вас отношение к RUP?Отношение такое - прекрасно разработанная теория, которую очень сложно и дорого применить на практике.
Просто не интересно? Или
интересно, но во многом не согласны с предлагаемыми концепциями
и поэтому - не приемлемо?
Тщательно изучать не пробовал, так как не вижу области применения. По моему мнению у нас (в России) это невостребованное знание.
371
Методологии / Re: Классификация моделей разработки ПО
« : 04 Сентября 2008, 22:21:17 »И чем это ОТЛИЧАЕТСЯ ОТ RUPВопрос мне кажется надо поставить по другому.??
А почему собственно RUP?
Правомощность такого вопроса попытался обосновать предыдущим постом.
372
Методологии / Re: Классификация моделей разработки ПО
« : 04 Сентября 2008, 22:19:29 »
Мое понимание.
Начнем с самого начала.
Есть субъект и есть объект.
Субъект что-то делает над объектом.
Субъект - тот кто делает.
Объект - тот над кем производят действия.
Например, программист исправляет баг.
Программист - субъект.
Баг - объект.
Обе эти сущности имеют свой Жизненный Цикл.
ЖЦ бага хорошо описывается диаграммой автомата, потому что это пассивная сущность (над ним совершают действия).
Какие состояния могут быть у бага?
Ну например, opened, assigned, closed, rejected, reopened, postponed, etc
Переход между этими состояниями осуществляется по событиям.
Кто генерирует события? Активная сущность - субъект (програмист)
Деятельность программиста при этом лучше всего описывается через диаграмму деятельности.
Какие деятельности могут быть?
Reproduce bag, Analysis, Coding, Testing, etc
Совокупность ЖЦ-ов субъекта и объекта определяет Процесс Исправления Бага!
Рассмотрим другой пример.
Разработчик разрабатывает ПО.
Все тоже самое.
Совокупность ЖЦ-ов субъекта и объекта определяет Процесс Разработки ПО!
Уделим внимание диаграмме деятельности разработчика.
Так сложилось исторически, что там есть такие деятельности как Анализ, Проектирование, Реализация и т.д. (а могут быть и другие, зависит от авторов)
Если мы после каждой фазы делаем последующую и назад не возвращаемся - Водопад/Каскад.
Думаю понятно, что вводя всякие обратные связи, циклы и прочее мы получим все множество процессов разработки, которые имеем.
Осталось сказать, что ПО разрабатывает не один человек, а команда. В команде каждый играет какую-то Роль.
Каждая роль (субъект) описывается своим ЖЦ. Ну и у каждой роли есть один или несколько объектов (на которые она влияет). Все это вместе и есть Процесс.
И последний вопрос. Что же мы получает после выполнения каждой деятельности? АРТЕФАКТЫ.
Это и документы, и модели, и исходный код, и исполняемые модули, и файлы конфигурации и т.д.
Они являются результатом деятельности субъектов над объектами.
Ну еще добавлю, что после каждой деятельности можно вехи порасставлять.
По поводу RUP.
Все построено по описанной схеме. RUP претендует на универсальность, поэтому он такой тяжелый. Там множество субъектов, объектов и артефактов. Еще он примечателен тем, что его описание сделано на UML.
Начнем с самого начала.
Есть субъект и есть объект.
Субъект что-то делает над объектом.
Субъект - тот кто делает.
Объект - тот над кем производят действия.
Например, программист исправляет баг.
Программист - субъект.
Баг - объект.
Обе эти сущности имеют свой Жизненный Цикл.
ЖЦ бага хорошо описывается диаграммой автомата, потому что это пассивная сущность (над ним совершают действия).
Какие состояния могут быть у бага?
Ну например, opened, assigned, closed, rejected, reopened, postponed, etc
Переход между этими состояниями осуществляется по событиям.
Кто генерирует события? Активная сущность - субъект (програмист)
Деятельность программиста при этом лучше всего описывается через диаграмму деятельности.
Какие деятельности могут быть?
Reproduce bag, Analysis, Coding, Testing, etc
Совокупность ЖЦ-ов субъекта и объекта определяет Процесс Исправления Бага!
Рассмотрим другой пример.
Разработчик разрабатывает ПО.
Все тоже самое.
Совокупность ЖЦ-ов субъекта и объекта определяет Процесс Разработки ПО!
Уделим внимание диаграмме деятельности разработчика.
Так сложилось исторически, что там есть такие деятельности как Анализ, Проектирование, Реализация и т.д. (а могут быть и другие, зависит от авторов)
Если мы после каждой фазы делаем последующую и назад не возвращаемся - Водопад/Каскад.
Думаю понятно, что вводя всякие обратные связи, циклы и прочее мы получим все множество процессов разработки, которые имеем.
Осталось сказать, что ПО разрабатывает не один человек, а команда. В команде каждый играет какую-то Роль.
Каждая роль (субъект) описывается своим ЖЦ. Ну и у каждой роли есть один или несколько объектов (на которые она влияет). Все это вместе и есть Процесс.
И последний вопрос. Что же мы получает после выполнения каждой деятельности? АРТЕФАКТЫ.
Это и документы, и модели, и исходный код, и исполняемые модули, и файлы конфигурации и т.д.
Они являются результатом деятельности субъектов над объектами.
Ну еще добавлю, что после каждой деятельности можно вехи порасставлять.
По поводу RUP.
Все построено по описанной схеме. RUP претендует на универсальность, поэтому он такой тяжелый. Там множество субъектов, объектов и артефактов. Еще он примечателен тем, что его описание сделано на UML.
373
Методологии / Re: Классификация моделей разработки ПО
« : 04 Сентября 2008, 17:51:29 »
а если совсем просто, то аналитическая модель - результат фазы анализа, а проектная - фазы проектирования.
374
Методологии / Классификация моделей разработки ПО
« : 04 Сентября 2008, 11:36:31 »
Мне интересно, но что такое "модель дизайна"?
Модель предметной области? Аналитическая модель приложения? Проектная модель?
Модель предметной области? Аналитическая модель приложения? Проектная модель?
375
Sparx / Re: Enterprise Architect: Практика использования
« : 29 Августа 2008, 20:32:43 »Насколько я знаю спецификация допускает помещать в пакеты другие пакеты и другие элементы, но в ней не сказано что пакет должен содержать что-то одно. Или я ошибаюсь?Не ошибаетесь.
Да и с точки зрения реализации, по-моему, естественно размещение и пакетов и классов внутри одного пакета.Пакеты UML не имеют никакого отношения к реализации, они просто группируют элементы модели для лучшей структуризации и т.д. Однако производители инструментов считают иначе (и наверное это удобно пользователям).