software engineering и UML

Здравейте колеги,

интересува ме мнението ви за възможностите на UML като инструмент за комуникация при проектирането на някаква софтуерна архитектура (приложение) - някой има ли задълбочен опит и може ли (ако желае) да сподели своите впечатления...

Поздрави,
Николай

за комуникация не знам. аз лично се опитвам да го ползвам най-вече заради клас диаграмите с разните релации. става хубава картинка пък и друго си е туул-а да ти генерира скелетите на класовете нали?

докато мажеш и рисуваш, ти щеш-не-щеш си принуден да мислиш за дизайн. тва май е доста хубав страничен ефект

цялата друга простотия с останалите диаграми ми се струва умряла работа. вярно, очевидно става за комуникация, ама защо да рисувам юз-кейсове или сикуънс диаграми като май е по-добре да напиша някой бърз ноут в друга диаграма и да приключим въпроса. то тоя тип диаграми май са само за кеф на мениджмънта, ако може да ги чете. едва ли има полза за програмиста.

защо пък да не можем да разделим модела на 2? една част -- дизайн и детайли по имплементацията, другата -- описване на поведението/функционалността/деплоймънт/знам ли още кво

техното е за неуспелите в поп-фолка
...стара китайска поговорка

Странно. Наистина най-използваните диаграми от UML си остават static diagrams (class diagrams), но защо пък use cases и sequence diagrams да не са полезни - според мен това строго зависи от типа софтуера, който се пише - моят опит ме кара да мисля че това което казваш е много вярно за приложения с много информация и бази данни, но пък от друга страна за софтуер, който е съставен предимно от много и най-различни активни (със собствени нишки) обекти може много да бъде онагледен именно със диаграми от вторият тип.

Поздрави,
Николай

АМи обсъждано е. Общо (но не и мое) мнение е че това е загуба на време. А клас диаграмите са най масови по 2 причини:

1.Правят ги програмисти.
2.Резултат са най-често от ревърс инжиниъринг.

Според мен проектиране на софтуер (и не само) в България почти не се прави - нямало време, задачата не била голяма и др.....

Темата е готина но времето и тук не е дошло. Няма и да дойде ...

Long live UB40

emi specialno nashte javisti sa mnogo po-v chas sys sekvite diagrami i designi otkolkoto C++ programistite.... moje bi zavisi i ot ezika - na c++ se uvlichat horata v debug i trace :-)

ne vijdam zashto iskash da delish procesa samo na 2 chasti, v povecheto kniki za OOA, OOD ili OOP razdelqt razrabotvaneto na nov software na 4 chasti:
1. Requirements
2. Analysis
3. Design
4. Implementation
i v zavisimost ot tova v koq chast si polzvash razlichni diagrami. USE CASE zadaljitelno se polzva pri predstavqne na requirements, zashtoto trqbva da predstavish procesa ot gledna tochka na usera. USE CASE mogat sashto da se polzvat i pri analiza.

COLLOBORATION i SEQUENCE diagramite se polzvat pri analiza, za da pokajesh koe sled koe sledva, kak si vzaimodeistvat, kakvo obmenqt i kakav e rezultata.

CLASS i STATE diagramite se polzvat pri designa, za da pokajesh koe kakvo e, kakvi metodi ili poleta ima i kakvo unasledqva. Tuk veche generirash skeletite na clasovete i metodite.

Implementaciata ostava v racete na programistite.

Razbira se za malki proekti ne moje i da stava duma za podobno razdelqne na procesite, zatova Requirement, Analysis and Design se preplitat, ne sa qsno izrazeni i se polzvat diagrami spored tova koi shte chete documentaciqta i kakva e bila glednata tochka na pisheshtiq.

Ako pak sam si pishesh software-a, veroqtno shte pochnesh ot zad - napred. V zavisimost ot tova kakvo mojesh, shte si izgradish predstava za tova kakvo iskash da postignesh.

V kraina smetka vsichko zavisi ot budgeta na proekta

Не мога да се съглася с теб Jamie. За едно имаш право - диаграмите най-често се правят след като софтуера е написан и "върви" някак, а не както би трябвало преди това...
Но защо да не му е "дошло времето" - какво е това което трябва да "узрее" според теб в нашата софтуерна индустрия?

Поздрави,
Николай

ami ne sym syglasen sys tebe - Collaboration i sequence diagrami sa podhodqshti, kogato naistina ima kakvo da opishesh sys tqh, a tova, koeto ti opisvash e vqrno osnovno za database prilojeniq - pri koito naistina nqma koj-znae kakvo dinamichno za opisvane.

Syshto i vidovete diagrami izobshto ne sa svyrzani sys fazite na proekta - moje bi nqkoi sa po-podhodqshti za opredelena faza, no po princip, mi e interesno kak shte opishesh silno multithreaded sistema samo sys class diagrama....

izobshto, vsichkoto, koeto si napisal mi zvuchi malko kato prevedeno ot "UML For Dummies" primerno :-)

da dopylnq - Class diagramite sa naj-masovi, zashtoto:

1. sa statichni ( za razlika ot sequence, koito sa dinamichni)
2. za database prilojeniq, prakticheski nqma nujda ot dinamichni (spravka - OOModeling and Design for DB applicatios - Blaha, Premerlani)
3. naj-masovo se pishat DB prilojeniq

i ot 1, 2, 3 => nujnoto :-)

Здравей,

Ами като цяло мнението ми е , че ти добре си го казал - UML-a е за да служи "като инструмент за КОМУНИКАЦИЯ......."

Лошото е, че масово хората смятат, че прочитайки 2 книжки, в които ти обясняват какво е квадратче, какво е стрелка с точка и т.н. - и хоп - вече са спецове по UML, ОО дизайн и анализ...

Тежък случай е вече, когато някой си напълни главата с примерно Rational Unified Process и почне да философства 'професионално' кое за какво е, и как RUP e the best и т.н. - като всъщност за всеки един вид диаграмка, процес и т.н. сигурно трябват години да се усъвършенстват и да се правят като хората...

Просто Rational си вършат работата - печелят много пари, рекламирайки добре продуктите си.... И масово фирмите им вярват - като дадат $30000 примерно и вече стават супер софтуерна фирма..

А - и напоследък гледам, че започват да се спрягат Design Patterns примерно - не е зле да видят хората и Design Antipatterns....

А и малко повод за размисъл - примерно Window-sa като е правен преди 93 и API-to им е що-годе обектно ориентирано - тия хора от Design Patterns ли са чели? :-)

zabraviate vsi4ki 4e OOD, OOA zapo4va ne ot diagramite a ot USE CASE-ovete
, minava prex CRC cards dokato se stigne do Class diagrams
po skoro CRC cartite triabva (kazvam triabva no nikoj ne go pravi tva) da sa naj razprostranenoto OOD-OOA sredstvo
az li4no samo 2 pyti sym polzval UML modelirane v commercial projects, ne az triabvashe da pravia modeliraneto, a software designer-ite (oba4e takiva niamahme), taj 4e hvanah knigite.

spored men UML e naj podhodiash v WEB i corporate software design-a kydeto e naj-iasno izrazena vryzkata user-software.

Spomenava se tuk 4e UML se polzva za DB design koeto spored men e greshno, za da se modelira DB se razglegdat ve4e krajnite produkti - taka (nare4enite fakti. kojto stavat osnova (tablici) za izgragdaneto na DB), kojto imat dimensions, attributes (columns), relations i t.n.
Nikyde ne sym vigdal uspeshno prilagane na niakakyv tip Slow Changing Dimensions, obiknovenno se kyrpi v poslednia moment i osnovnia problem e lipsata na opitni DB designeri.
DB triabva da se razglegdat kato DSS - Decision Support Systems i modeliraneto j niama nishto obshto s OOD, OOA
Pove4eto programisti shte se izsmeiat 4e DB design-a ne e nikakvo design-vane, no 50-100 GB DB kojato e designata greshno moge da provali business za milioni dollars.
temata e interesna, ama are stiga tolkoz

az ne razbrah kakyf e problema da se modelira multithread app s OOD i UML?

software engineers v USA po pravo vzemat pove4e pari ot obiknovenni coderi (programisto)
za BG ne mi se govori - tam e mnogo sle design-a vyobshte (ili pone beshe)

taj 4e kak taj pravite napravo diagramite?

Трябва шефовете да не го схващат като загуба на време - да дадат зелена светлина на проектирането. Защото сега повечето фирми имат само програмистки отдел - дори и QA нямат ! За анализ и дизайн не са и чували !
Мажат там пък каквото стане - и обикновено пренаписват после.
От друга страна и програмистите не са склонни на това - да проектират. Хванали са се за кода и край ! По тези две причини не смятам че ще доживея да видя в българска фирма UML диаграми в действие :-)

Long live UB40

Znachi za DB design-a - specialno Rational Rose-to ima takava vyzmojnost da se designva baza sys class diagrami - lichno az smqtam, che e mnogo zle i si polzvam ErWin-a.

A za multithreaded apps - spomenah go ne che ne moje da se designva s UML, a kato primer za kakvo ne sa podhodqshti (samo) class diagramite.

Обратното, ония хора от Design Patterns са гледали как тия хора от Windows са си писали програмите :)
Винаги така става. Когато някакви програмисти направят нещо хубаво, намират се други да го видят и да започнат да им обясняват какво са направили :)
Мен не може да ме впечатли никакво UML. Имам си достатъчно идеи как да проектирам софтуер - не ми стига време да ги пробвам.
Разните спорове от рода "как е редно и как не е редно да се работи в една фирма" се водят от мераклии да станат менаджери, защото им е омръзнало да програмират; не е лесно да поддържаш ниво; днес ако си добър, след 2 години със същите знания си out, понеже технологията се сменя з 2 години съществено.

Мога абсолютно да се съглася с crazy - освен всичко аз много харесвам CRC метода - кара те да мислиш "защо наистина" проектираш така класовете. По въпроса кое в какъв вид проектиране се ползва нека изкажа лично мнение. Преди пишех софтуер основно с бази данни, но от близо година работя нещо съвсем ново и екзотично за мен - пиша Front-End софтуер за управление на машини (някои от тях са доста "скъпи") за производство на полупроводници (wafers), т.е. критични приложения и с учудване забелязвам колко близки са проблемите по дизайна независимо от така наречения "application domain".
Аз твърдо застъпвам тезата че програмиста трябва да прекарва 50% от времето си с тетрадка и тебешир - а не на клавиатура...

Поздрави,
Николай

ne mi e qsno zashto namesvash DB applications i kak taka shte polzvash colloboration i sequence, kogato "naistina nqma koj-znae kakvo dinamichno za opisvane". Tqhnata cel e da opishat tochno vzaimodeistvieto i posledovatelsnostta na otdelnite procesi (moje da sa multi threadvoe, moje samo izvikvaniq na funkcii). Razbira se ako imash samo samo edin Standalone Application s edin main metod naistina nqma kakvo da opishesh s tezi diagrami, no podobni primeri mojesh da namerish samo v "Java for Dummies". Ako tova si imal v predvid moga da te razbera.

Inache sam napalno saglasen, che diagramite ne sa svarzani s fazite na proekta, nqkoi ot tqh mogat da badat po-podhodqshti za opredeleni fazi, no nqma pravilo koeto da te zadaljava da gi polzvash v opredelen red. Spored celta si izbirash diagrami, koito shte ti svarshat rabota v konkretniq sluchai. Az spomenah samo chast ot diagramite, koito sa nai-chesto izpolzvani, no ima i mnogo drugi, koito sa po-specifichni. Imenata im sashto mogat da badat razlichni v zavisimost ot metodologiqta izpolzvana za implementiraneto na saotvetniq UML tool.

Pitash za multithreadova sistema ...
Ami, s class diagrami shte opisha statichnoto sastoqnie na sistemata, s object diagrama shte opisha statichnoto sastoqnie na sistemata v tochno opredelen moment. Za dinamichnoto opisanie shte polzvam sequence diagrama - shte opisha vzimodeistvieto mejdu obektite ot gledna tochka na izvikvaneto im vav vremeto, a ako e nujno moje da se pokaje s colloboration diagrama, kak obektite si vzaimodeistvat ot gledna tochka na obmen na saobshteniq ili danni. Saotvetno use case diagramata shte pokaje vzaimodeistvieto na sistemata s vanshni obekti, ako razbira se ima takiva.

Ako si imal neshto po-konkretno predvid, spomenavaiki multithread system, dai poveche podrobnosti.

niqmashe kak da ne podam edno ramo kato prochetoh mnenieto ti

Napalno sam saglasen, che CRC kartite sa mnogo uspeshen metod - razviva asociativnoto mislene i mojesh po-lesno da pravish analogii i da obhvanesh neshtata po-globalno, t.e. razviva OOT (Object-Oriented Thinking). Spored men za da bade edin proekt uspeshen, zadaljitelno trqbva da se obmisli predvaritelno, da se preceni riska i chak togava da se deistva.

Pri nas blizo 80% ot vremeto se prekarva v proektirane i razqsnqvane na iziskvaniqta za daden proekt. Nie osnovno pravim web stranici i web tools. Polsednata stranica ni otne blizo 6 mseca rabota, kato po-malko ot 1 mesec beshe chistoto programirane. Celiqt proekt beshe za okolo $800 000, dnevno ima nad 2000 users i sistemata e izcqlo dinamicna, sadarjanieto moje da se promenq ejeminutno ako se nalaga. Zaradi mnogoto specificni iziskvaniq se naloji mnogokratno proektirane i odobrenie na rabotata.

V sashtata kompaniq stanah svidetel i na tochno obratnoto qvlenie, spontanni idei i realizaciqta im za edna dve sedmici. Sledvashe palna kasha i absoliutna nevazmojnost za poddarjane na sistemata, tova naloji prenapisvaneto po savsem druga tehnologiq.

V kraina smetka neshtata chesto oprat do tova, ne kakvi tools sa neobhodimi za UML ili reverse-engineering, ami list, himikal, asociativno mislene i malko vreme ...

neznam zashto mislish taka, no az znam nqkolko firmi (bivshata mi firma, i imam poznati na drugi mesta), kadeto se pravi predvaritelno proektirane. Moje bi ne stava duma za UML v idealniq mu variant, no horata se machat, malko ili mnogo i osnovno polzvat open source tools za da ne im izliza skapo.