Sanokaa joku hyvä ja monipuolinen UML-mallinnusohjelma. Itselläni on kokemusta ArgoUML:stä sekä Microsoftin Visiosta ja kummastakaan en oikein tykkää... Ohjelma voi hyvin olla myös maksullinen, koska se tulisi myös yrityskäyttöön, mutta lisensiltään se saisi olla ns. "persistent license"...
Siedettävin UML-softa johon olen törmännyt on ilmainen Violet.
Ohjelma on moniin muihin verrattuna melko yksinkertainen, joten en ole ihan varma sisältääkö se kaiken mahdollisen mitä yrityskäytössä voi tarvita. Ainakin yksinertaisiin kaavioihin tuo on kuitenkin mukavan suoraviivainen eikä sisällä liikaa turhaa sälää häiritsemässä.
Umbrello on myös yksi ilmainen vaihtoehto, taitaa tosin olla vain Linuxille.
Yksi maksullinen vaihtoehto on Creately, mutta tarjolla on näköjään vain kuukausi- ja vuosimaksuversiot.
Sehän tässä juuri onkin, että ohjelmia löytyy kyllä vinopino, mutta sitten ne on joko kuukausi/vuosilaskutuksella tai muuten vaan liian "ahdasmielisiä" ominaisuuksiltaan...
Mikäs ongelma tuo kk-laskutus sitten on? Itse olen todennut että usein on kivempikin maksaa 5 e / kk kuin 1000 e kerralla.
IBM Rational Rose Modeler maksaa 2 166,55 USD sisältäen ensimmäisen vuoden ylläpidon, eikä ylläpitoa ole pakko ostaa sen jälkeen. Eli se täyttäisi ainakin tuon "A Perpetual License" vaatimuksesi, muuten en osaa kommentoida ko. tuotetta.
Grez kirjoitti:
Mikäs ongelma tuo kk-laskutus sitten on? Itse olen todennut että usein on kivempikin maksaa 5 e / kk kuin 1000 e kerralla.
Sama vika kuin vuokralla-asumisessa.
Mielestäni ei voi oikein verrata. Jos löytää paremman softan vuoden päästä, niin vanhasta softasta saa myymällä tuskin puoliakaan takaisin, toisin kuin asunnosta. Edelleen riippuu kovasti siitä ostohinnan ja kk-maksun suhteesta.
Triton kirjoitti:
Sama vika kuin vuokralla-asumisessa.
Kauanko ajattelit käyttää saman ohjelman samaa versiota? 10 vuotta? :D
5e * 12kk * 10v = 600e/10v
Eli 600 euroa saa yhden henkilön lisenssi maksaa kertaostona (en ota nyt korkoja huomioon).
Noiden ns. SaaS-palveluna myytävien ohjelmistojen etuna on se, että niihin normaalisti sisältyy kaikki päivitykset automaattisesti...
Miksei tässä ketjussa ole vielä mainittu Diaa? Ohjelma on ilmainen ja mielestäni ihan kelvollinen kaavioiden piirtelyyn.
Toisaalta, hyväkään kaavioiden piirrustamisohjelma ei korvaa sitä että piirtäjä todella osaa piirtää kaavioita eikä vain käyttää jotain kallista ohjelmaa.
Juuso kirjoitti:
Toisaalta, hyväkään kaavioiden piirrustamisohjelma ei korvaa sitä että piirtäjä todella osaa piirtää kaavioita eikä vain käyttää jotain kallista ohjelmaa.
Ei tietenkään. Tosin nyt täytyy kysyä, että epäiletkö taitojani? :D
Triton kirjoitti:
Tosin nyt täytyy kysyä, että [epäileekö Juuso] taitojani? :D
Kyllä tuollainen sairaalloinen piirtointo ainakin minua ihmetyttää. Tuntuu, että muistat mainita UML-kaaviot melkein jokaisessa keskustelussasi. Itsehän en ole piirtänyt kuin joskus töissä tietokantakaavioita ja niitäkin vain siksi, että se oli ainoa tapa tehdä muutoksia kantaan.
Mutta piirrä toki, jos se jotenkin suunnitteluasi helpottaa.
Juuso kirjoitti:
Dia
Screenhosteista päätellen aika hyvä ohjelma, mutta vähän liian vanha (minulle). ;)
Metabolix kirjoitti:
Kyllä tuollainen sairaalloinen piirtointo ainakin minua ihmetyttää. Itsehän en ole piirtänyt kuin joskus töissä tietokantakaavioita ja niitäkin vain siksi, että se oli ainoa tapa tehdä muutoksia kantaan.
Hö? Minulle (ja arvaan, että Tritonillekin) opetetaan / on opetettu, että mallintaminen on tooooosi tärkeää. UML (ja ER) ovat must, kun tehdään softaa. Olenko ymmärtänyt jotain väärin tunnilla tai Metabolixin viestistä?
Metabolix kirjoitti:
Triton kirjoitti:
Tosin nyt täytyy kysyä, että [epäileekö Juuso] taitojani? :D
Kyllä tuollainen sairaalloinen piirtointo ainakin minua ihmetyttää. Tuntuu, että muistat mainita UML-kaaviot melkein jokaisessa keskustelussasi. Itsehän en ole piirtänyt kuin joskus töissä tietokantakaavioita ja niitäkin vain siksi, että se oli ainoa tapa tehdä muutoksia kantaan.
Mutta piirrä toki, jos se jotenkin suunnitteluasi helpottaa.
No kun tuon putkarts:n kehitystä on seurannut niin voi kysyä, että olisiko sittenkin se kaavioiden (sairraalloinen) piirtäminen ollut tarpeellista?
Opetelkaahan mallintamaan, sillä sillä on tulevaisuutta. Saatta edes jonkinlaista ammatillista kehitystä.
Koodari on kuoleva ammatti. Mallinnuksen taitava voi toimia eri toimialoilla. Ei tartte olla pelkkä koodari koko ikäänsä, eikä toimia softa-alalla, jos ei vättämättä halua.
tepokas kirjoitti:
No kun tuon putkarts:n kehitystä on seurannut niin voi kysyä, että olisiko sittenkin se kaavioiden (sairraalloinen) piirtäminen ollut tarpeellista?
Opetelkaahan mallintamaan, sillä sillä on tulevaisuutta. Saatta edes jonkinlaista ammatillista kehitystä.
Meinaatko tosissasi, että peli valmistuisi nopeammin ihan vaan kaavioita piirtelemällä? ;-) Kyllähän noilla kaavioilla varmaan käyttönsä on, mutta ei kai niiden pitäisi sentään pääasia kehitysprosessissa olla?
Metabolix: Mikä ihmeen sairaalloinen piirtelyinto? Olen maininnut ne vain sen takia, ettei niitä kukaan muu ole nähdäkseni koskaan maininnut. Olen vain oman työskentelyn yhteydessä nähnyt, että ne helpottavat koodausta huomattavasti...
jukkah: Tuskin ymmärsit mitään väärin. Tuo on vain tyypillistä Metabolixin v*ttuilua :D
jalski kirjoitti:
Meinaatko tosissasi, että peli valmistuisi nopeammin ihan vaan kaavioita piirtelemällä? ;-) Kyllähän noilla kaavioilla varmaan käyttönsä on, mutta ei kai niiden pitäisi sentään pääasia kehitysprosessissa olla?
Ensimmäiseen kyllä, ja toiseen kyllä.
Mallinnukseen kuuluu mennä about puolet koodaukseen käytetystä ajasta (ammattimaisessa projektissa). Koodausta on myös enintään 30 % koko ajasta yläkanttiin arvioituna. Suunnitteluun (sis. määrittely ja mallinnus) ja testaukseen käytetty aika on laadun parantamista, ei Kankkulan kaivon täyttämistä.
Triton kirjoitti:
... ne [kaaviot] helpottavat koodausta huomattavasti...
Asiaa...
Ensiksi mainitsen, että poikkeus yleiseen kaaviopolitiikkaani ovat mutkikkaiden sovellusten käyttötapauskaaviot. Niitä sietää johtoportaan piirrelläkin, ennen kuin koodarit laitetaan hommiin. Seuraavat kommentit koskevat siis vain koodin rakenteen suunnitteluun liittyviä kaavioita.
jukkah kirjoitti:
Hö? Minulle (ja arvaan, että Tritonillekin) opetetaan / on opetettu, että mallintaminen on tooooosi tärkeää. UML (ja ER) ovat must, kun tehdään softaa.
Suunnittelu on tärkeää, kaaviot eivät. Kaavio on vain tapa esittää suunnitelma graafisesti – ja toki ryhmätyössä on eduksi käyttää standardoituja merkintöjä. Tiedollisesti kaavio ei tuo mitään uutta jo ennestään hyvään suunnitelmaan. (Lisäksi kaavioiden piirtäminen kaikenlaisista triviaaleista asioista on ajanhukkaa, mutta ei mennä siihen nyt.)
En oikein usko, että itse löytäisin jostain kaaviosta mahdollisuuden tai suunnitteluvirheen, jota en mitenkään tulisi ajatelleeksi ilman kaaviota. Saa tulla osoittamaan sellaisen jostain koodistani, niin muutan näkemystäni. ;)
Vaikka monella on pakkomielle nimenomaan nähdä asioita, kaikki eivät ole yhtä visuaalisesti orientoituneita, vaan jotkut uskovat, ymmärtävät ja muistavat paremmin kuulemaansa, lukemaansa tai tekemäänsä. Tämä luultavasti vaikuttaa myös siihen, miten hyödyllisiltä kaaviot tuntuvat.
jukkah kirjoitti:
jalski kirjoitti:
Meinaatko tosissasi, että [PutkaRTS] valmistuisi nopeammin ihan vaan kaavioita piirtelemällä? ;-)
Ensimmäiseen kyllä – –
Mallinnukseen kuuluu mennä about puolet koodaukseen käytetystä ajasta (ammattimaisessa projektissa). Koodausta on myös enintään 30 % koko ajasta yläkanttiin arvioituna.
Eräissä kohdissa olen käyttänyt suunnitteluun yli 90 % ajasta, oletko siihen tyytyväinen? Sen sijaan joissain kohdissa osuudet ovat päinvastaiset ja laatu silti hyvä, eikä se ole minusta mitenkään paha asia – se vain kertoo, että helpot asiat ovat helppoja, kuten kuuluu ollakin. Minusta on erittäin huolestuttavaa, jos "ammattilainen" joutuu oikeasti tekemään kaksi tuntia kaavioita koodatakseen ristinollan, jonka koodaaminen kestää vaikka tunnin.
Mutta osittain olet oikeassa. Monta muutosta on pitänyt hylätä siksi, että niitä ei ole suunniteltu tarpeeksi hyvin. Usein huonoon suunnitteluun liittyy huono koodin laatu matalammalla tasolla, ja taidankin silloin antaa liikaa palautetta jälkimmäisestä. Vielä ei ole tullut vastaan täydellisen tyylikkäästi koodattua mutta väärin suunniteltua pätkää. :P
Tuskinpa mikään projektin yleinen suunnitelma auttaisi tässä tippaakaan. Usein toteutettavana on vain yksittäinen luokka tai olemassaolevaan luokkaan pieni toiminto, jonka vaatimukset lyhyellä tähtäimellä ovat selvät ja josta minun mielestäni ainakin pitäisi pystyä tekemään tyylikäs ja virheetön kokonaisuus puuttumatta muuhun koodiin. Jokaisen pitäisi siis tehdä omasta palasestaan oma suunnitelmansa (kaavioilla tai ilman, lopputulos ratkaisee) sovittujen speksien mukaan. Kannatan UNIX-tyylistä lähestymistapaa "do one thing and do it well"; hyvin kirjoitettua koodia on helppo järjestellä sitten, kun tarvittavat palaset järkevää kokonaisuutta varten on toteutettu.
jalski kirjoitti:
Meinaatko tosissasi, että peli valmistuisi nopeammin ihan vaan kaavioita piirtelemällä? ;-) Kyllähän noilla kaavioilla varmaan käyttönsä on, mutta ei kai niiden pitäisi sentään pääasia kehitysprosessissa olla?
No justiinsa putkarts-tyypin projekteissa mallinnuksesta on paljonki hyötyä, hajautettua työvoimaa, ovat paikalla ku sattuu, osallistujien taso on "ennalta määrittelemätön" ja "tekijät" katoaa suht noppeesti.
Mallinnuksella saadaan nopeahko sketsaus/määrittely projektin osa-alueista. Tätä sketsausta/määrittelyä on hankala (=vaatii paljon aikaa) tehdä ilman aiempaa kokemusta eli vaatii "tekijäkseen" sellasen joka on jotain tehnyt. Nämä "tekijät" tuppaa katoamaan toisiin projekteihin suht nopeasti.
Tästä päästään siihen, että niitä "tekijöitä" tulisi käyttää tehokkaasti siinä projektin alkuvaiheessa, kun ne on vielä aktiivisesti mukana. UML-kaavioiden piirtely on kumminkin joutusampaa kuin koodailu&kokeilu.
Kun sketsaus/määrittely on tehty, palasien koodausta voi sitten opettaa kelle hyvänsä. Tai pitää vaikkapa viikkokilpailuja tyyliin: Koodaa pala xx, palkintona mainetta ja kunniaa & saat nimesi tekijöiden listaan.
Näitä "kelle hyvänsä"-tyyppejä löytyy kumminkin isompi joukko kuin noita "tekijöitä". Valmiiksi määriteltyjä palasia on helppo jakaa näille "kelle tahansa"-tyypeille ja sitä kautta nopeuttaa projektin valmistumista.
Lisäksi kaaviosta/mallista on ulkopuolisten helppo seurata softaprojektin etenemistä. Vaikkei nämä ulkopuoliset aktiivisesti osallistu projektiin, niin niillä on kumminkin mahdollisuus kommentoida/antaa vinkkejä toteutukselle. Ja niistä vinkeistä voi joskus jopa olla jotain hyötyä.
Eihän tietenkään missään yksittäisen luokan suunnittelussa mitään UML-kaavioita kannata käyttää, sehän vain hidastaisi projektia entisestään. Nyt puhunkin projekteista mihin tarvitaan vähintääkin kymmeniä/satoja luokkia ja nimenomaan sen rakenteen hahmottamista varten suunnittelu on tärkeää.
jukkah kirjoitti:
Hö? Minulle (ja arvaan, että Tritonillekin) opetetaan / on opetettu, että mallintaminen on tooooosi tärkeää. UML (ja ER) ovat must, kun tehdään softaa.
Kannattaa muistaa kaksi asiaa:
1. Useimmissa ohjelmointiin liittyvissä asioissa ei ole yhtä totuutta. Kaksi asiantuntijaa voi olla täysin eri mieltä asiasta, ja kummallakin voi olla hyvät perustelut kannalleen. Yleensä kuitenkin hyvin jyrkkä mielipide (esim. "ilman UML-kaavioita ei voi tehdä kunnon ohjelmaa") viestii siitä, että henkilö ei ymmärrä asiaa.
2. Ohjelmistojen suunnittelua opettavilla on usein vähän tai ei ollenkaan kokemusta suurten ohjelmistojen toteutuksesta ja työelämästä. Monella opettajalla ei ole aitoa tietoa opettamastaan asiasta. En väitä, että teidän opettajanne eivät tuntisi alaa, mutta tämä mahdollisuus kannattaa pitää mielessä.
Antti Laaksonen kirjoitti:
Yleensä kuitenkin hyvin jyrkkä mielipide viestii siitä, että henkilö ei ymmärrä asiaa.
Jos muistan oikein, tiedemiehet tekevät kaiken tiukkojen sääntöjen mukaan (mutta muut eivät). Oma mieltymykseni on selvästi ensin mainitsemaani suuntaan. :)
jukkah kirjoitti:
[Koulussa opetetaan, että] mallintaminen on tooooosi tärkeää.
Tuli mieleen, että mikäli sitä ei (yli)korostettaisi, kukaan opiskelija ei tekisi mitään kaavioita tai suunnitelmia.
jukkah kirjoitti:
Jos muistan oikein, tiedemiehet tekevät kaiken tiukkojen sääntöjen mukaan (mutta muut eivät). Oma mieltymykseni on selvästi ensin mainitsemaani suuntaan. :)
No ohjelmointihan ei tyypillisesti olekaan tieteen tekemistä vaan sen soveltamista.
Siis tietenkin UML-kaavioiden tekeminen kannattaa vain siinä tilanteessa kun se tuo jotain lisäarvoa koko tuotantoprosessille ts. eihän niitä kaavioita kannata piirtämisen ilosta tehdä ellei esimerkiksi ole mitään koodigeneraattoria käytössä, joka osaisi kaavion perusteella jo valmiin ohjelmakoodin vääntää (tietääkseni näitäkin on jo joitain olemassa, mutta taso ei ole kovin korkea ellei jotain perus luokkakaavion muuttamista luokanrungoksi lasketa). Minulle UML:stä on tullut tärkeä juuri sen takia, että kun koodi määrä kasvaa jo muutamiin satoihin riveihin alkaa koko softan rakenne karkaamaan lapasesta ja juuri tässä UML on todella paljon auttanut. En sano, että jokaisessa softatalossa todellisuudessa edes väännettäisiin UML:llää ja jos väännetään, niin vain tiettyjen kaavioiden osalta. Sitäpaitsi tämä nykyinen trendi käyttää agile-menetelmiä kuten Scrumia, johtaa siihen, että suunnittelusta leikataan yhä enemmän ja jokaisella sprintillä vain koodataan jokin ominaisuus valmiiksi. Tottakai kouluissa opetetaan teoriaa enemmän kuin käytäntöä ja se pragmaattisuus varmasti tulee työelämän myötä paremmin esille...
Jotenkin tuntuu, että tämän koko threadin pointti karkasi taas käsistä ja todella pahasti. Yritin löytää softaa yritys- sekä opiskelukäyttöön, mutta tämä menikin nyt siihen, että väitellään siitä, että kannattaako koko UML-mallinnus. Aika vähän tälläkin foorumilla on vuosia töitä tehneitä ohjelmistotuotannonammattilaisia, joilla olisi oikeasti kanttia sanoa juuta tai jaata asian suhteen.
Ja Metabolix, olenhan minä joka 3-4 viestissä maininnut UML-kaaviot reilusta 750 viestistä eli kiitos vaan tästä hyvästä ja hienosta "melkein jokaisessa keskustelussa" -viestissä.
Tässä olisi muutama harkitsemisen arvoinen vaihtoehto:
https://www.magicdraw.com/home
http://www.sparxsystems.com/
Näistä olen MagicDraw:ta kokeillut (lyhyesti) ja se vaikutti ihan pätevältä ohjelmalta. Kummastakin pitäisi olla kokeiluversio saatavilla.
Triton kirjoitti:
Nyt puhunkin projekteista mihin tarvitaan vähintääkin kymmeniä/satoja luokkia ja nimenomaan sen rakenteen hahmottamista varten suunnittelu on tärkeää.
Yleensä niistä luokista vain hyvin pieni osa on olennaisia samalla kertaa. Väitän, että suurista suunnitelmista on sitä vähemmän hyötyä, mitä modulaarisempi järjestelmä on, ja olemme toivottavasti jotenkin samaa mieltä siitä, että isoissa sovelluksissa kannattaa yleensä pyrkiä modulaarisuuteen.
Triton kirjoitti:
Ja Metabolix, olenhan minä joka 3-4 viestissä maininnut UML-kaaviot reilusta 750 viestistä eli kiitos vaan tästä hyvästä ja hienosta "melkein jokaisessa keskustelussa" -viestissä.
Trololoo. 8D No mutta onhan se aika paljon verrattuna useimpiin.
tepokas kirjoitti:
No justiinsa putkarts-tyypin projekteissa mallinnuksesta on paljonki hyötyä, hajautettua työvoimaa, ovat paikalla ku sattuu, osallistujien taso on "ennalta määrittelemätön" ja "tekijät" katoaa suht noppeesti.
Projektissa oli tarkoitus olla jollain tavalla pysyvä ydintiimi, jolla päästäisiin ainakin alkuun, vaan eipä päästy. Vaikea on jakaa mitään pieniä projekteja satunnaisille tunareille, kun ihan pelimoottorin keskeisimmät toiminnotkin ovat vielä kesken. Siinä ei paljon UML-kaavio lohduta. Kunhan tästä päästään vähän parempaan vaiheeseen, alan laittaa ideoita GitHubin Issues-sivulle. Sitä en silti ymmärrä, millä tavalla laatikot ja viivat edistäisivät ominaisuuksien toteuttamista verrattuna siihen, että ihan tekstimuodossa kerrotaan, mitä pitäisi saada. Jos koodari ei osaa sitä omaan palaseensa liittyvää yhden tai kahden luokan kokoista suunnitelmaa tehdä itse, tuskin hän osaa kovin hyvää toteutusta tehdä valmiin kaavionkaan perusteella.
jukkah kirjoitti:
Jos muistan oikein, tiedemiehet tekevät kaiken tiukkojen sääntöjen mukaan (mutta muut eivät). Oma mieltymykseni on selvästi ensin mainitsemaani suuntaan. :)
Tärkeä sääntö tieteessä on, että jos jotain väittää, niin asia tulee perustella. Ohjelmistosuunnittelua käsittelevässä tieteellisessä tutkimuksessa ei näe koskaan väitteitä, että UML-kaavioiden (tai jonkin muu menetelmän) käyttäminen olisi ainoa oikea tapa suunnitella ohjelmia.
Metabolix kirjoitti:
Sitä en silti ymmärrä, millä tavalla laatikot ja viivat edistäisivät ominaisuuksien toteuttamista verrattuna siihen, että ihan tekstimuodossa kerrotaan, mitä pitäisi saada.
Esimerkiksi luokkakaaviolla on helppo esittää luokkien väliset yhteydet, jäsenfunktiot, jäsenmuuttujat, perintähierarkia, lukumääräsuhteet sekä elinkaarien riippuvuuksia (muodoste/kooste/assosiaatio) kaikki yhdessä kompaktissa paketissa. Samojen asioiden esittäminen pelkällä tekstillä (ilman mitään kaaviota) johtaa helposti hyvin epäselvään ja tulkinnanvaraiseen speksiin.
Kaaviot ovat myös hyvä tapa dokumentoida ohjelma. Erityisesti ohjelmistoalihankinnassa asiakas usein vaatii varsinaisen ohjelman/koodin lisäksi myös dokumentaation ja tässä UML on mielestäni hyvin kätevä. Kun kaavioita on tehty/ylläpidetty jo määrittelyvaiheesta lähtien, niin on dokumentaatio helpompi tehdä.
Sampe: Jos lukisit viestini (tai peräti koko keskustelun) kokonaisuutena, varmaan näkisit, ettei vastauksesi liity viestiini oikeasti mitenkään. Puhe oli opetusprojektista, jossa tekijöiden pitäisi itse opetella suunnittelua ja toteutusta. Jos tekisin etukäteen perusteelliset, funktiotasolle asti ulottuvat suunnitelmat jokaisesta pikku yksityiskohdasta, voisin saman tien tehdä koko projektin alusta loppuun itse. Vaivaakin säästyisi, kun ei tarvitsisi muiden koodeja katsella ja korjailla. Et varmaan sinäkään saa alihankinnassa asiakkailta tuollaisia dokumentaatioita, vaan teet toteutussuunnitelman ja dokumentaation itse osana työtä. (Sitä paitsi nyt on kyseessä huvin vuoksi tehtävä peli, jossa osa hauskuudesta on, että tekijät saavat ideoida ominaisuuksia itse.)
Luin kyllä ketjun alusta alkaen ja kommentoin yleisellä tasolla kaavioiden hyödyllisyyttä pelkkään tekstimuotoiseen speksiin verrattuna. Projektinne vaikuttaa mielenkiintoiselta ja tarjoaa varmasti osallistujille mielekkään tavan opiskella uutta. Harrasteprojekteissa ei välttämättä ole järkevää tehdä hyvin yksityiskohtaisia suunnitelmia etukäteen, mutta väittäisin, että projektin aikana ylläpidettävä korkean tason kuvaus olisi silti hyödyllinen. Ainakin se auttaa hahmottamaan kokonaisuuden ja auttaa esimerkiksi uusia kehittäjiä pääsemään mukaan projektiin (em. kuvauksenhan ei tarvitse olla UML-kaavio, vaan se voi olla mikä vain tapa, jonka kehittäjät kokevat luontevaksi).
Täytyy vielä kommentoida, että UML-kaaviothan eivät nimenomaan mene vielä kovinkaan yksityiskohtaiselle ts. eihän niillä varsinaisia algoritmejä niinkään kuvata, vaan lähinnä ohjelmiston staattisia- ja dynaamisiarakenteita, kuten juurikin paketteja, luokkia tai olioiden välisiä viestiyhteyksiä. Varsinaisia algoritmeja varten taas ovat vuokaaviot, joiden hyödyllisyyden tosin aikalailla kyseenalaistan...
Toni: tähän tuli useita viestejä väliin, niin en tiedä huomasitko viestini liittyen ketjun varsinaiseen aiheeseen. Laitoin linkit MagicDraw sekä Enterprice Architect -ohjelmien sivuille.
UML-kaaviothan eivät sinänsä ole sidottuja tiettyihin hierarkiatasoihin eli niitä voi käyttää melko joustavasti erilaisiin tarkoituksiin. Osa kaavioista sopii käytettäväksi myös ohjelmistokehityksen ulkopuolellakin (esim. tilakaavio ja tapahtumasekvenssikaavio)
Sampe: Kyllä huomasin, kiitos.
Antti Laaksonen kirjoitti:
Tärkeä sääntö tieteessä on, että jos jotain väittää, niin asia tulee perustella.
Siinä(kin) kohdassa näyttäisi minulla olevan vielä kehittymisen varaa. ;)
jukkah kirjoitti:
Jos muistan oikein, tiedemiehet tekevät kaiken tiukkojen sääntöjen mukaan (mutta muut eivät). Oma mieltymykseni on selvästi ensin mainitsemaani suuntaan. :)
Mielestäni parhaimmillaan ohjelmointi on sääntöjen rikkomista tai kiertämistä... ;-)
Kyllähän sitä itsekin välillä tulee jonkun idean saatuaan piirreltyä ja hahmoteltua asioita, tosin ihan vaan paperille.
Mielestäni parhaimmat oivallukset tulevat silti välillä ihan yllättäen. Palkitsevinta on, kun keksii jonkun mielenkiintoisen erilaisen lähestymistavan johonkin ongelmaan.
Kirjoittelin juuri koodivinkin PL/I:llä kaikkien vuoden 2012 perjantai 13. päivien nopeaan selvittämiseen (en tiedä julkaistaanko). Koodia tuo vaati n. 40 riviä. En usko, että kaavioita ensin piirtelemällä tuosta olisin saanut yksinkertaisemman (voit tietysti todistaa väitteeni vääräksi kirjoittamalla yksinkertaisemman ratkaisun).
jalski kirjoitti:
Mielestäni parhaimmillaan ohjelmointi on sääntöjen rikkomista tai kiertämistä... ;-)
Riippuu tietty mitä ne säännöt on. Itse näkisin ohjelmointiin liittyvät säännöt sellaisina, että niitä ei kannata rikkoa. Esimerkiksi tietoturvaan liittyvä sääntö: "Tarkista ja/tai käsittele aina käyttäjältä tuleva syöte." En pysty mitenkään näkemään miten esim. tuon säännön rikkominen olisi "ohjelmointia parhaimmillaan".
Jos taas ajattelet että "nopein tunnettu tapa jakaa luku tekijöihin on O(jotain)" on "sääntö", niin sitten tietysti säännön rikkominen olisi ohjelmointia parhaimmillaan. Harvalta vaan onnistuu. Ja toisaalta en itse puhuisi säännöstä.
jalski kirjoitti:
Kirjoittelin juuri koodivinkin PL/I:llä kaikkien vuoden 2012 perjantai 13. päivien nopeaan selvittämiseen (en tiedä julkaistaanko). Koodia tuo vaati n. 40 riviä.
Useimmilla tehtävään soveltuvilla kielillä vie 1-3 riviä koodia. Tästä tulee lähinnä mieleen oikean työkalun valinta.
jalski kirjoitti:
... voit tietysti todistaa väitteeni vääräksi kirjoittamalla yksinkertaisemman ratkaisun.
Jos jotain olen oppinut tästä keskustelusta, en aio todistaa väitettäsi vääräksi. :)
Edit. Grez näköjään ehti tekemään sen sillä aikaa, kun kirjoittelin viestiä.
Grez kirjoitti:
Useimmilla tehtävään soveltuvilla kielillä vie 1-3 riviä koodia. Tästä tulee lähinnä mieleen oikean työkalun valinta.
Teen tuon parilla bittimerkkijonolla ja yhdellä AND-operaatiolla. Onko mielessäsi parempi ja nopeampi tapa?
En osaa sanoa kuinka hankala asia tuo mahdollisesti on PL/I:lle, mutta esim. C#:lla, joka sekään ei ehkä ole paras kieli tehtävään
for (var p = new DateTime(2012, 1, 13); p.Year < 2013; p = p.AddMonths(1)) {
if (p.DayOfWeek == DayOfWeek.Friday) Console.WriteLine(p.ToString());
}Selkeä, nopeasti kirjoitettava (alle minuutti), suoritusajaltaan merkityksetön. Eiköhän tuossa olennaisimmat paremmuuskriteerit.
Jos ihan vaan suoritusnopeutta haetaan niin
Console.Writeline("13.1., 13.4. ja 13.7.2012");Grez kirjoitti:
En osaa sanoa kuinka hankala asia tuo mahdollisesti on PL/I:lle, mutta esim. C#:lla, joka sekään ei ehkä ole paras kieli tehtävään
for (var p = new DateTime(2012, 1, 13); p.Year < 2013; p = p.AddMonths(1)) { if (p.DayOfWeek == DayOfWeek.Friday) Console.WriteLine(p.ToString()); }Selkeä, nopeasti kirjoitettava (alle minuutti), suoritusajaltaan merkityksetön. Eiköhän tuossa olennaisimmat paremmuuskriteerit.
No, hitaampi tuo toteutus kuitenkin on varmasti, kuin tämä.
jalski kirjoitti:
No, hitaampi tuo toteutus kuitenkin on varmasti
Aika nopee toteuttamaan kyllä oot jos ton suunnittelusta kirjoittamiseen toteutit alle minuutissa. Hatunnosto siitä.
Edelleen jos suoritusnopeutta tarkoitat, niin laitoin myös sen kannalta optimoidun version. Uskon, että sekin tuli kirjoitettua nopeammin kuin laittamasi. Sisältää myös vähemmän koodarin laskemia vakioita.
Vakavasti ottaen pidän täysin typeränä käyttää moninkertainen aika siihen, että jonkun asian suoritus on 0-23 % nopeampaa tilanteessa, jossa hitaus ei alunperinkään ole ongelma.
Ton mun softan suoritusnopeus konsoliin kirjoituksen kanssa oli 0,0000175 s ja ilman konsoliin kirjoitusta 0,0000047 s, joten on ihan hirveän vaikea kuvitella tilannetta jossa tuosta 4,7 mikrosekunnin osuudesta olisi järkeä lähteä nipistämään pois tekemällä monimutkaisempaa ja hankalammin ylläpidettävää koodia.
En toki sano, etteikö ajankulukseen voisi koittaa nipistää jostain merkityksettömästä algoritmista viimeisiäkin mehuja, mutta koodivinkiksi sellainen olisi tyhmää laittaa.
Ymmärrän toki tarpeen esitellä "omaa hienoa tuotosta", mutta koodivinkkisi on mielestäni huono lähes kaikissa koodivinkille tärkeissä asioissa.
Edelleen jos nyt pitäisi nopeusoptimoida ja vieläpä haluaisi olla käyttämättä valmista kalenteria niin seuraava on mielestäni nopea (ehkäpä nopeampi kuin esimerkkisi) olematta silti turhaan kryptinen (laskennan suoritusaika 0,1 µs)
int[] monthdays = { 31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 };
int year = 2012;
int firstFriday = 6;
for (int month = 0; month < 12; month++)
{
//Jos eka perjantai on 6. päivä, niin 13. päivä on perjantai
if (firstFriday == 6) Console.WriteLine("13.{0}.{1}", (month + 1), year);
firstFriday = (firstFriday - monthdays[month] + 35) % 7;
}Grez kirjoitti:
Ymmärrän toki tarpeen esitellä "omaa hienoa tuotosta", mutta koodivinkkisi on mielestäni huono lähes kaikissa koodivinkille tärkeissä asioissa.
Itseasiassa tuon koodivinkin tarkoituksena oli vain näyttää yksi mahdollinen käyttötarkoitus bittimerkkijonoille, eikä muuta.
Lisäsinpä kuitenkin koodivinkin loppuun äsken myös sen perinteisemmän versionkin:
*PROCESS MARGINS(1, 120) pp(macro);
%replace FRIDAY by 6;
f13th: proc options (main);
dcl wd fixed bin (31);
dcl i fixed bin;
dcl 1 date,
2 dd pic '99' init ('13'),
2 mm pic '99' init ('01'),
2 yyyy pic '9999' init ('2012');
dcl (days, weekday, string) builtin;
put list ('Friday, the 13th dates in 2012:');
put skip;
do i = 1 to 12;
wd = weekday(days(string(date), 'DDMMYYYY'));
if wd = FRIDAY then
put skip list(date.dd || '.' || date.mm || '.' || date.yyyy);
date.mm += 1;
end;
end f13th;Voitais seuraavaksi keskustella vaikka Jumalan olemassaolosta...
Triton kirjoitti:
Voitais seuraavaksi keskustella vaikka Jumalan olemassaolosta...
Tämä aihe ei liity siihen mitenkään, eli tee uusi aihe. Tulen varmasti mukaan keskusteluun. ;)
Aihe on jo aika vanha, joten et voi enää vastata siihen.