(no subject)
6/10/06 15:15![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
singalenВчера бухтели как-то бессистемно.
Начали с того, что я почти отказался от своей критики DDD (Domain-driven design by Eric Evans), и выразил ему уважение за:
- паттерны анализа (и Фаулеру тоже. Эванс читал Фаулера.)
- описания ситуаций и критериев выбора того или иного паттерна моделирования предметной области.
- и ещё немалое количество практически полезной информации. Правда, слабо структурированной, так что её нужно просто читать и "вмыкать". Я бы переписал кое-какие главы более структурированно %)
Потом заговорили о моделировании информсистем, причём иногда ударялись в такие дебри, что понимать было очень тяжело. Начали с того, что смоделировать бизнес-процесс во всей полноте невозможно, и вопрошали, как его описать "быстро".
Моё мнение по этому вопросу такое: для каждой роли описать самые типичные задачи и информационные потоки - из этого можно сделать первое приближение к системе.
Кстати, мимоходом Сергей заметил, что в модели бизнес-процесса практически нет объектной ориентированности: есть только роли, их задачи, и информационные (документные) потоки.
потом понеслись в совсем отвлечённые вещи, типа вопроса - когда нужно выделять общего предка для двух классов. Сергей привел в пример собаку и корабль: у них есть имя, скорость, и "что они едят".
Но тут всё зависит от системы. Если это торговля, то вообще не нужно разделять их на разные классы. А если модель физики, то их общность будет ничтожно мала.
Наметили идею следующей игры: анализ бизнес-процесса. Почему-то говорили о процессе разработки ПО, хотя это неправильно: обычно анализируешь процесс, который тебе принципиально незнаком. Главная проблема при этом - объёть сложность процесса и выделить такой набор задач, который ты можешь формализовать в требования и автоматизировать. С разработкой же ПО мы все будем страдать "familiarity blindness", то есть упускать очевидные подробности.
Начали с того, что я почти отказался от своей критики DDD (Domain-driven design by Eric Evans), и выразил ему уважение за:
- паттерны анализа (и Фаулеру тоже. Эванс читал Фаулера.)
- описания ситуаций и критериев выбора того или иного паттерна моделирования предметной области.
- и ещё немалое количество практически полезной информации. Правда, слабо структурированной, так что её нужно просто читать и "вмыкать". Я бы переписал кое-какие главы более структурированно %)
Потом заговорили о моделировании информсистем, причём иногда ударялись в такие дебри, что понимать было очень тяжело. Начали с того, что смоделировать бизнес-процесс во всей полноте невозможно, и вопрошали, как его описать "быстро".
Моё мнение по этому вопросу такое: для каждой роли описать самые типичные задачи и информационные потоки - из этого можно сделать первое приближение к системе.
Кстати, мимоходом Сергей заметил, что в модели бизнес-процесса практически нет объектной ориентированности: есть только роли, их задачи, и информационные (документные) потоки.
потом понеслись в совсем отвлечённые вещи, типа вопроса - когда нужно выделять общего предка для двух классов. Сергей привел в пример собаку и корабль: у них есть имя, скорость, и "что они едят".
Но тут всё зависит от системы. Если это торговля, то вообще не нужно разделять их на разные классы. А если модель физики, то их общность будет ничтожно мала.
Наметили идею следующей игры: анализ бизнес-процесса. Почему-то говорили о процессе разработки ПО, хотя это неправильно: обычно анализируешь процесс, который тебе принципиально незнаком. Главная проблема при этом - объёть сложность процесса и выделить такой набор задач, который ты можешь формализовать в требования и автоматизировать. С разработкой же ПО мы все будем страдать "familiarity blindness", то есть упускать очевидные подробности.
Tags:
(no subject)
6/10/06 13:10 (UTC)