Здравствуйте, serg0s, Вы писали:
S>Меня удручает тот факт, что практически не существует правил, позволяющих как-то получить структуру (объектную, компонентную) программы из требований к ней. Каждый раз приходится сначала «изобретать» что-то, а потом «примерять» требования к этому изобретению. Литература также не блещет особо примерами. S>Может, кто-то подскажет что, или где-то это есть в литературе?
Если коротко:
а) как правило методологии больше заточены под управление проектом/удовлетворение потребностей заказчика чем под создание качественного продукта. Сама по себе довольно холиварная тема в духе что круче — требования или архитектура. Собсно в этот холивар тема и вылилась, попробуете влезть — быстро надоест нудное выяснение отношений. Типичная цитата — "архитектура == функция от требований". На этом всё. Только не подумайте что я имею что-то против конкретных товарищей — довольно мило побеседовали о неспособности понимать друг друга
б) работа по дизайну системы/проектированию архитектуры кладётся на кого? На архитекторов. Значит идём втыкать в Zachman framework, TOGAF, 4+1 и т.п. Здесь другие грабли — первые два относятся скорее к принципам построения архитектуры предприятия и адаптации к этому делу IT. Последее — просто принцип работы основывающийся на использовании 4 основных моделей и одной на усмотрение. Почему-то всегда упоминаются рядом .
Кстати, Wikipedia (http://en.wikipedia.org/wiki/TOGAF) в одном списке упоминает DoDAF, Model-driven architecture и SAP Enterprise Architecture Framework. Так сказать, яблоки, груши и велосипеды Забавно, что по большому счёту TOGAF (да и значительная часть всего остального) — тот же цикл "анализ-проектирование-реализация-миграция", только "требования" заменены на "enterprize architecture". Хотя не, вру. DoDAF ближе к 4+1.
Можете покопаться, но почти наверняка утонете в тонннах нюансов управления бизнесом и особенностях enterprise architecture. Без подготовки туда лезть особо смысла нет.
в) Из современного и простого есть DDD Эрика Эванса — "Tackling the complicity in the heart of software". Прочитать стоит хотя бы для самообразования. Новых идей там почти нет — обычное использование концептуальной модели (впервые всплывало в типовой архитектуре субд от ANSI аж 71-го года вроде). Но методики и аргументация приятная.
Вот там, где он доходит до реализации и начинает дружить с агилистами, Бруксом и явой — стоит включать спамофильтр и думать самостоятельно. А то появляются идеи что "DDD==Scrum + repository model via Hibernate"
г) чтобы было о чём говорить — Gaperton где-то в середине моего выяснения отношений с поклонниками требований приводил определения архитектуры/дизайна. За неимением лучшего: http://www.rsdn.ru/forum/message/3290920.1.aspx
Здравствуйте, serg0s, Вы писали:
S>Меня удручает тот факт, что практически не существует правил, позволяющих как-то получить структуру (объектную, компонентную) программы из требований к ней.
Еще бы. Именно за это нам и платят деньги. Если бы такие формальные правила существовали, программы бы писали аналитики, а нас бы всех поувольняли
... << RSDN@Home 1.2.0 alpha 4 rev. 1137 on Windows Vista 6.0.6001.65536>>
Здравствуйте, serg0s, Вы писали:
S>Меня удручает тот факт, что практически не существует правил, позволяющих как-то получить структуру (объектную, компонентную) программы из требований к ней. Каждый раз приходится сначала «изобретать» что-то, а потом «примерять» требования к этому изобретению. Литература также не блещет особо примерами. S>Может, кто-то подскажет что, или где-то это есть в литературе?
Это лучшая книга по проектированию, которая учит преобразовывать требования в структуру. Великолепная вещь, аналогов которой не выпускалось после даже близко — она учит думать, а не оперировать паттернами. Основана на OMT Рэмбо — одного из авторов UML. OMT — лучшая методология анализа и проектирования, к сожалению, вытесненная сейчас творением того же Рэмбо (плюс еще пары товарищей) — UML. OMT — содержит всего 4 (четыре! задумайтесь!) типа моделей. И книга Рэмбо — это стройный учебник по ОО дизайну, и вообще — по дизайну. С упражнениями.
Меня удручает тот факт, что практически не существует правил, позволяющих как-то получить структуру (объектную, компонентную) программы из требований к ней. Каждый раз приходится сначала «изобретать» что-то, а потом «примерять» требования к этому изобретению. Литература также не блещет особо примерами.
Может, кто-то подскажет что, или где-то это есть в литературе?
Здравствуйте, serg0s, Вы писали:
S>Меня удручает тот факт, что практически не существует правил, позволяющих как-то получить структуру (объектную, компонентную) программы из требований к ней. Каждый раз приходится сначала «изобретать» что-то, а потом «примерять» требования к этому изобретению. Литература также не блещет особо примерами. S>Может, кто-то подскажет что, или где-то это есть в литературе?
Не совсем понятно, может, Domain Driven Design?
Здравствуйте, serg0s, Вы писали:
S>Меня удручает тот факт, что практически не существует правил, позволяющих как-то получить структуру (объектную, компонентную) программы из требований к ней. Каждый раз приходится сначала «изобретать» что-то, а потом «примерять» требования к этому изобретению. Литература также не блещет особо примерами. S>Может, кто-то подскажет что, или где-то это есть в литературе?
А как у вас требования выражены, что из них ничего получить нельзя?
На ум приходит только что-то типа: "Сделайте мне хорошо!".
Здравствуйте, serg0s, Вы писали:
S>Меня удручает тот факт, что практически не существует правил, позволяющих как-то получить структуру (объектную, компонентную) программы из требований к ней. Каждый раз приходится сначала «изобретать» что-то, а потом «примерять» требования к этому изобретению. Литература также не блещет особо примерами. S>Может, кто-то подскажет что, или где-то это есть в литературе?
Ты прав, в общем случае таких правил не существует. Требования предявляются к функциональности, а структура это детали реализации. Единственный, известный мне работособособный подход, это рисовать стуктуру из головы и проигрывать на ней юзкейзы из требований.
Кстати, позабавило — в оригинальном названии UML упоминается в самом конце: "Object-Oriented Modeling and Design with UML". В нашем почему-то UML вынесли на первое место и напечатали его очень большими буквами.
T>OMT — лучшая методология анализа и проектирования, к сожалению, вытесненная сейчас .. UML.
T>несколько странно рекомендовать в качестве замены перевод книжки по UML
Не очень понял, про какую замену идёт речь. Ссылка, которую я запостил, это ссылка на перевод второго издания упомянутой выше книги. Вот ссылка на оригинал: Object-Oriented Modeling and Design with UML (2nd Edition)
T>>OMT — лучшая методология анализа и проектирования, к сожалению, вытесненная сейчас .. UML.
T>>несколько странно рекомендовать в качестве замены перевод книжки по UML C>Не очень понял, про какую замену идёт речь. Ссылка, которую я запостил, это ссылка на перевод второго издания упомянутой выше книги. Вот ссылка на оригинал: Object-Oriented Modeling and Design with UML (2nd Edition)
Но вот только первая книжка-то не про UML, а про OMT
T>Но вот только первая книжка-то не про UML, а про OMT
Не, не про то книжки обе. Обе книжки про "Оbject-Oriented Modeling and Design". А уж какая конкретно нотация при изложении используется — OMT или UML — глубоко без разницы.
Здравствуйте, cvoronin, Вы писали:
T>>Но вот только первая книжка-то не про UML, а про OMT C>Не, не про то книжки обе. Обе книжки про "Оbject-Oriented Modeling and Design". А уж какая конкретно нотация при изложении используется — OMT или UML — глубоко без разницы.
C>Вот диаграмма на OMT с википедии: http://upload.wikimedia.org/wikipedia/commons/9/9d/OMT_object_diagram.png C>Сильно оно от UML отличается?
Очень сильно, если черпать свои знания не из вики, и поэтому знать, что в составе OMT есть функциональная data flow модель, которая отсутствует в UML как класс. Зато — в UML присутствует целая куча дурацких бесполезных моделей.
Ну... на первый взгляд OMT слегка читабельней. Субъективно конеш, но диаграммка прочиталась с лёту.
Кстати — откуда эта традиция обозначать тип связи стрелками/кружками/ромбами на концах? Имхо, традиционные кванторы 0, 1 и бесконечность воспринимаются легче.
Здравствуйте, Sinix, Вы писали:
S>Ну... на первый взгляд OMT слегка читабельней. Субъективно конеш, но диаграммка прочиталась с лёту. S>Кстати — откуда эта традиция обозначать тип связи стрелками/кружками/ромбами на концах? Имхо, традиционные кванторы 0, 1 и бесконечность воспринимаются легче.
Оттуда и традиция . Только стрелки и ромбы о другом. Стрелка характеризует однонаправленную связь, ромб — признак отношения "является составной частью" (то есть, отдельно существовать не может, и удаляется при удалении "главного" объекта).
Числа 0, 1, и прочие стали ставить в UML. До этого, все структурные диаграммы применяли символику для обозначения отношений 1 к 1, один ко мнигим, многие ко многим. Это пошло вероятно с нотаций для реляционных баз данных, так называемых ER-моделей. Тогда люди заметили, что в сущности не важно, какие стоят числа, важен тип _отношения_, которое задает связь. А их всего три. Поэтому, проще задавать символически, а не числами. Это становится очевидно, когда рисуешь и анализируешь таких диаграмм _много_.
C>>Вот диаграмма на OMT с википедии: http://upload.wikimedia.org/wikipedia/commons/9/9d/OMT_object_diagram.png C>>Сильно оно от UML отличается?
G>Очень сильно, если черпать свои знания не из вики, и поэтому знать, что в составе OMT есть функциональная data flow модель, которая отсутствует в UML как класс. Зато — в UML присутствует целая куча дурацких бесполезных моделей.
А зачем вика? У Грэхема про него достаточно написано. Так как вставлять ссылки на бумажные картинки я ещё не научился, вставил на ту, которая подвернулась — из вики.
Мне кажется, не стоит делать культа из нотации. Вопрос ведь не в способе обозначения кардинальности ассоциаций. Ну нет в UML DFD. Ну и ладно. Есть BPwin, в котором эти вещи хорошо описываются. Хотя лично мне BPMN кажется удобнее и гораздо выразительнее.
Здравствуйте, cvoronin, Вы писали:
C>Мне кажется, не стоит делать культа из нотации. Вопрос ведь не в способе обозначения кардинальности ассоциаций. Ну нет в UML DFD. Ну и ладно. Есть BPwin, в котором эти вещи хорошо описываются. Хотя лично мне BPMN кажется удобнее и гораздо выразительнее.
DFD это, простите, не "нотация", это модель. Обладающая описательной силой, которая не покрывается ни одной моделью в UML. UML и OMT — это не просто наборы правил рисования картинок, за ними стоят разные методологии анализа и проектирования, некоторый mindset, подход к анализу проблемы. Не путайте знание алгебры и умение рисовать знаки плюс, минус, и равно.
UML, например, практически бессилен по сравнению с OMT в случае системы с потоковой обработкой, где надо обязательно анализировать поток данных. В нем просто не "слов", чтобы описать то, на что надо обратить внимание. Зато UML компенсирует это наличием activity diagram, которая позволяет описывать параллельные процессы с взаимодействием, и делает акцент на Use Cases, в результате — она сильна при анализе интерактивных систем. Они разные.
.
