Ohjelmistotehtaat. Helsingin yliopisto Tietojenkäsittelytieteen laitos SOSE seminaari esitelmä Matti Husu

Transkriptio

1 Ohjelmistotehtaat Helsingin yliopisto Tietojenkäsittelytieteen laitos SOSE seminaari esitelmä Matti Husu

2 Ohjelmistotehtaat Software Factories Ei aivan uusi termi, vaikka Microsoft ottanut nyt käyttöön To enhance programmer productivity through standardized tools, a computer-based interface, and a database with historical data for financial and management controls. [Bemer69] Systematic reusability of code when developing new programs. [McIlroy69] The term Software Factory has been used to describe large commercial efforts to automate software development along similar lines, suggesting a commitment to long-term integrated efforts to optimize software development methods and practices over the course of multiple projects. [Aaen97]

3 Ohjelmistotehtaat Microsoftin lanseeraamana asia on uusi, mutta sisältää vähän kokonaan uutta Kokelma jo käytössä olevia tekniikoita/tapoja usein pienillä muutoksilla Kokoaminen (assembly) komponenteista ja palveluista Mallinteet (patterns) Mallit Kehykset (frameworks) Tuoteperheet Päätavoitteena uudelleenkäytöllä, automatisoinnilla ja abstraktiotason nostolla saavuttaa parempi ohjelmistotuotantoprosessi ja alan teollistaminen

4 Ohjelmistotehtaat Ajatuksena ottaa mallia muista, tavallisista teollisuuden aloista Esim. Elektroniikkateollisuus suurelta osalta kokoaa tuotteet valmiista komponenteista Ohjelmistoteollisuutta kuvaavat keskiarvo luvut (USA) vähintäänkin huolestuttavia [Standish Group] 16% ohjelmistoprojekteista ajassa ja budjetissa 31% perutaan kokonaan laatuongelmien takia Budjetit ylitetään 189%:lla Valmiissa projekteissa vain 42% suunnitelluista piirteistä

5 Yhä monimutkaisempia ja suurempia ohjelmistoja Maailmanlaajuinen tarve ohjemistoille vain kasvaa Yhä suurempia kokonaisuuksia ja monimutkaisempia järjestelmiä Tämänhetkiset menetelmät ei pysy kyydissä Menetelmät, työkalut ja osaavat ihmiset rajoitteina Käsin rakentaminen tyhjästä työtä vaativilla menetelmillä Tuottavuus ja laatu kaavaneet vain marginaalisesti kymmenessä vuodessa

6 Ongelmat nykyisessä ohjelmistokehityksessä Ohjelmistojen kokoaminen valmiista osista kaupallisessa mittakaavassa Eri komponenttialustat eivät yhteensopivia Staattisen kapseloinnin takia komponenttien rajoja vaikea muuttaa Valmiiden komponenttien tarjonta olematonta Siirtyminen 3:n sukupolven yleisistä kielistä eteenpäin UML sopii dokumentaatioksi, mutta ei MDD:hen tai suorittamiseen Koodin generointi, round trip engineering malleista toisiin siirryttäessä Saman tuotteen useiden eri mallien yhteensopimattomuus (näkökulmat) Järjestelmällinen uudelleenkäyttö kaupallisessa mittakaavassa Useimmat tuotteet tehdään yksittäisinä Uudelleenkäyttö lähinnä copy+pastea / sattumanvaraista Ei menetelmiä uudelleenkäytettävien osien löytämiseen Aikatalut ja budjetit ylitetään Formaalit menetelmät tarkoitettu monimutkaisuuden, ei muutoksen hallintaan Ketterät metodit tarkoitettu muutoksen, ei monimutkaisuuden hallintaan

7 Krooniset ongelmat 1 Monoliittinen rakenne Ei koota olemassaolevista komponeneista Objektit liian hienojakoisia ja kontekstiriippuvia kokoamiseen Alustariippuvat protokollat Tämänhetkiset kokoamisteknologiat vaikeuttavat eri alustojen komponettien tai jopa eri versioiden komponenttien kokoamista Heikko pakkaus Pakkausteknologiat eivät sisällä tarpeeksi tietoa komponettien ominaisuuksista eivätkä niiden yhteistoiminnasta kootussa ohjelmistossa. Innokas kapselointi Komponenttien rajoja vaikea muuttaa NIH (Not Invented Here) Epäluottamus kaikkeen ulkopuolella tehtyyn. Kehittäjät poikkeuksetta aliarvioivat oman komponentin toteustus, testaus ja ylläpito sekä parannuskulut.

8 Krooniset ongelmat 2 Perusteeton yleisyys abstraktiotason nostossa Yleisiä 3n: sukupolven kieliä (3GL),kuten C# ja Java, ei välttämättä tarvita koko tuotteen kehittämiseen Suurin osa pystytään tekemään paremmin rajoitetuilla konfigurointimenetelmillä Ongelmia M odel Yleiset, heikot mallintamiskielet, kuten UML, eivät tue toteutusta eikä CBD:tä Heikko koodingeneroinnin tuki (CASE) Generated Application Code Heikko tuki eri työkalujen metadatan yhdistämiseen Platf orm Frameworks Platf orm Platf orm

9 Krooniset ongelmat 3 Yksittäinen kehittäminen Vaikka useissa ohjelmissa on yleensä enemmän yhteisiä kuin eroavia piirteitä, projekteja yleensä käsitellään uniikkeina. Prosessin kypsymättömyys Vain harvat kehittävät ohjelmistoja joiden budjetit ja aikataulut pitävät Yritetään hallita joko monimutkaisuutta tai muutostarvetta Liiallinen muodollisuus Ei aina tarvetta kaiken kuvaavalle ja säätelevälle raskaalle prosessille Liiallinen vapaus Vapaamuotoinen prosessi tukee ketteryyttä, muutoksen hallintaa

10 Kriittiset innovaatiot Systemaattinen uudelleenkäyttö Kehitys kokoamalla Mallipohjainen kehitys

11 Komponentit Komponentti Itsenäisesti toimiva kokonaisuus, voidaan käyttää kolmannen osapuolen taholta yksikkönä koostamaan uusia komponentteja Tarjotut ja vaaditut rajapinnat Alustariippuva, esim. CORBA, COM Ohjelmointikielen objektia käsitteellisesti isompi kokonaisuus Järjestelmän komponentit voivat olla eri suoritusymäristöissä

12 Palvelut Palvelu Käsitteellisesti yleensä isompi kuin komponentti. Business maailmassa toteuttaa yhden business prosessin tai konseptin. Esim. Tilausten hallinta Voidaan toteuttaa komponenteilla tai suoraan millä tahansa ohjelmointikielellä (OO, proseduraalinen) Alustariippumaton Asynkroninen kommunikointi Lähtevien ja saapuvien viestien järjestykset tiukasti määritelty Velvoitteet kuvattu SLA:ssa (Service Level Agreement)

13 Systemaattinen uudelleenkäyttö Tuoteperheet, joissa samoja piirteitä, tuotetaan ohjelmisto tuotelinjalla (software product line) Tuotelinja kehitys Tuotelinjan kehittäjät valmistavat uudelleenkäytettäviä tuotantohyödykkeitä, joita tuotteen kehittäjät käytävät tuotteen kehityksessä Erona yksittäiseen kehitykseen: Suunnittelun pitkäjänteisyys Kaksi eri yhteenliityvää prosessia Organisaatio rakenne tuottaa Tuotanto hyödykkeet käyttää Tuotekehitys käyttää Vaatimukset Palaute tuottaa Tuotteet tuottaa

14 Kehitys kokoamalla Oikeasti alustariippumattomat protokollat kuten Web Services Itsensä kuvaaminen sopimuksilla (contracts) ja sertifikaateilla Myöhäinen kapselointi Arkitehtuurilähtöinen kehitys Orkesterointi/organisointi-kokoaminen

15 Abstraktiotason nostaminen Helpottaa suunittelua ja tuo sen suuremman joukon piiriin Komponenttien konfigurointi, muokkaus ja kokoaminen Mallineen (pattern) tunnistaminen komponettien kokoamisessa Kehyksien, jotka toteuttaa mallineita, rakentaminen Aiheuttaa kuilun alustan ja abstraktion väliin Mallien (model) käyttö kehyksen automaattiseen täydentämiseen

16 Kuilu mallin ja alustan välillä Model Model Application Generated Code Platform Frameworks Platform (a) Application Generated Code Domain Framework Specific Pattern Framework Language Platform Frameworks Platform (c) Model Model Application Generated Code Platform Platform Frameworks (b) Application Generated Code Platform Platform Frameworks (d) Lähde: Software factories, copyright Jack Greenfield, Keith Short

17 Mallipohjainen kehitys Model Driven Development (MDD) Työskentely eri abstraktiotasoilla Vähentää monimutkaisuutta Lisää ketteryyttä (agility) Tuotteen pitäikäisyys Kielipohjaiset abstraktiot Voidaan käyttää työkaluilla automaattiseen jalostukseen (refinement) Metadatan generointi->automatisointi Olemassa jo tiettyyn tarkoitukseen olevia kieliä kuten BPEL Uusien kielien kehittäminen ei välttämättä helppoa

18 Mallipohjainen kehitys Mallit sisältävät prosessoitavissa olevaa tietoa Suunnittelijan alkuper. aikomus ongelma-alasta mahdollisimman tarkasti Kehitykseen liittyvien toimintojen täydellinen tai osittainen automatisointi Tuotoksista toisia kuten käyttöliittymämalleista testihaarniskoita Adaptereja, kuten WS- kääreitä, automaattisesti eri toteutusteknologioiden välille Mallin, jonka tuotokset sisältävät sijoitettavan yksikön, automaattinen sijoittaminen

19 Mallipohjainen kehitys Alakohtaiset kielet (DSL) Hyvin tarkennettuja, tiettyyn ongelma-, alusta- tai tehtävä-alaan sopivia formaaleja kieliä Tuo toteutuksen sanaston lähemmäksi insinöörejä, loppukäyttäjiä ja tietyn asian tai alan asiantuntijoita. Tekee ongelman ja ratkaisun helpommaksi ymmärtää ja ylläpitää Kielen tarkoitus tulee olla määritelty eksplisiittisesti Kielen konseptit ja niiden nimet pitää olla helposti ymärrettävissä käyttötarkoituksen tunteville Helposti ymmärrettävä notaatio, joka vastaa kielen käsittelemää alaa Hyvin määritelty kielioppi, joka määrää miten konsepteja käytetään yhdessä Useita hyviä esimerkkejä jo olemassa kuten SQL, käyttöliittymän määrittelykielet ja sännölliset lausekkeet

20 Mallipohjainen kehitys Kehyksien täydentäminen Motivaationa täyttää kuilu abstraktioiden (mallien) ja alustan välillä Pidetään malli ylhäällä, eikä lasketa sitä M odel Generated A pplication Code Domain Framework S pecif ic Pattern Framework Language Platf orm Frameworks Platf orm Mallin vahvat abstraktiot säilyy Laitetaan väliin alaan liittyvä ohjelmistokehys Työkalut generoivat koodin pätkiä tiettyyn DSL:ään perustuvasta mallista täyttämään kehyksen laajennuspisteet Kehyksen ja kielen kehittäminen iso panostus ->tuoteperheet tasoittavat kustannuksia per tuote

21 Mallien muuntaminen Alemman tason DSL eikä kehystä tai mallinekieltä (vrt. aiempi) Progressiiviset transformaatiot mallista toiseen Toimii kuten Java tai C# kääntäjät M odel Generated Code Generated A pplication Code Platf orm Platf orm Frameworks Platf orm

22 Malline-perustaiset muunnokset Automaattisesti Avustettuna Käsin Lähde malli (Source model) Patterns (Mallineet) Kohde malli (Target model)

23 Lähde: Software factories, copyright Jack Greenfield, Keith Short

24 Muunnostyypit Pystymuunnoset ovat jalostusta Vaakamuunnokset joko järjestelemistä delokalisaatiota Vinot muunnokset Yhdistää molempia yllä

25 Prosessikehykset Prosessin kypsyyden keskeinen tekijä on muutoksen ja monimutkaisuuden hallinta Prosessia kannattaa käyttää vain jos siitä on hyötyä! Tuoteperheissä hyöty helpommin Prosessikehys järjestää mikro-prosesseja, joita käytetään tuotoksien rakentamiseen Tuotoksista (artifacts) valmistetaan tuoteperheiden jäseniä Constrain Based Scheduling (CBS) Aktiivinen opastus (Active guidance)

26 Ohjelmistotehtaat Paradigman tarkoituksena teollistaa ohjelmistotuotanto prosessi Ironisesti muun teollisuuden prosesseja ohjaa ohjelmistot!

27 Ohjelmisto tehdas A software factory is a software product line that configures extensible tools, processes, and content using a software factory template based on a software factory schema to automate the development and maintenance of variants of an archetypical product by adapting, assembling, and configuring framework based components. Ohjelmistotehdas-skeema (schema) Ohjelmistotehdas-kaavain (template) Laajennettavasta kehitysympäristöstä kuten Visual Studio 2005 tai IBM WebSphere tulee tehdas tuotteen kehittämiseen

28 Product Line Engineering Product Line Analysis Product Line Definition Problem Domain Modeling Solution Domain Modeling Product Engineering Product Line Design Product Configuration Product Architecture Infrastructure Architecture Architecture Feature Mapping Software Schema Extensible Tools Product Line Implementation Asset Provisioning Asset Packaging Variable Variable Assets Assets Customized Tools Product Development Fixed Fixed Assets Assets Lähde: Software factories, copyright Jack Greenfield, Keith Short

29 Economies of scale & scope Reuse here Single design Initial use here Few prototypes Many copies Scale: Yhden suunnittelun useita instanseja tuotetaan yhdessä (vrt. Kone tekee ruuvimeisselin kopioita) Production assets Scope:Useista hieman poikkeavista suunnitteluista tuotetaan instansseja yhdessä. (vrt.tehdas tuottaa automalleja,joissa sama kori, mutta esim. eri moottori ja vaihteisto.) Initial use here Reuse here Multiple designs Production assets Few prototypes Many copies

30 Ohjelmistotehdas-skeema Rakenne kehitys-tuotoksille (development artifacts) XML dokumentit, mallit, buildaus skriptit, konfiguraatio-tiedostot, lähdekoodi tiedostot, SQL tiedostot, lokalisointitieostot, testitapaukset (test cases) Organisoidaan ja kategorisoidaan Yhteenvedot Tuotoksien väliset yhteydet Voidaan kuvata taulukkona Rivit kuvaavat abstraktiotasoa Sarakkeet kuvaavat osa-alueita (concerns) Solu kuvaa näkökulmaa, jonka avulla voidaan rakentaa joku ohjelmiston aspekti

31 Business Information Application Technology Conceptual Use Cases And Scenarios Business Goals And Objectives Business Entities And Relationships Business Processes Service Factoring Service Distribution Quality Of Service Strategy Logical Physical Workflow Models Role Definitions Process Specification Message Schemas And Document Specifications Database Schemas Data Access Strategy Service Interactions Service Definitions Object Models Detailed Design Technology Dependent Design Logical Server Types Service Mappings Physical Servers Software Installed Network Layout Lähde: Software factories, copyright Jack Greenfield, Keith Short

32 Ohjelmistotehdas-skeema Solujen välisien ja sisäisien funktioiden (mappings) avulla voidaan automatisoida: Mallimuunnoksia Koodin generointia Mallineiden soveltamista Testi- haarniskoiden tuottamista Käyttöliittymä komponenttien sijoittelua Tietokanta skeemojen suunnittelua

33 Ohjelmistotehdas skeema Taulukko on itse asiassa malli skeeman visuaalista esittämistä varten. Oikeasti skeema on suunnattu verkko. Solmut näkökulmia Nuolet ovat laskettavissa olevia suhteita, funktioita Näin taulukon ei-vierekkäisille näkökulmille voidaan määritellä muunnos-funktio. Kaikki näkökulmat eivät myöskään sovi täydellisesti rivi ja sarake määrittelyihin Siten skeema kuvastaa enemmän ohjelmisto arkkitehtuuria

34 Abs traction & Refinement Abs traction & Refinement Abs traction & Refinement Functional C onfig uration B us ines s Proces s es Utility Portal S ervices S ervices Bus ines s B us ines s Proces s S ervices Entity S ervices Product Architecture Non-functional C onfig uration B us ines s Entities REQUIREMENTS ARCHITECTURE EXECUTION ARCHITECTURE CRM DEPLOY. UNIT TRANS FORMATION / RECONCILIATION CONS TRAINTS TRANS FORMATION / RECONCILIATION es ales DEPLOY. UNIT EXECUTAB LE ARTIFACTS Logical S erver Types Hos t S oftware S ettings INFRAS TRUCTURE ARCHITECTURE DEPLOYMENT Abs traction & Refinement MAP TO HARD- WARE PHYS ICAL DATACENTER Lähde: Software factories, copyright Jack Greenfield, Keith Short

35 Ohjelmistotehdas-skeema Functional C onfiguration Non-functional C onfiguration Abs traction & Refinement Business Processes Business E ntities REQUIREMENTS ARCHITECTURE TRANS FORMATION / RECONCILIATION Utility S ervices Portal S ervices Logical S erver Types Abs traction & Refinement Business Process S ervices Business E ntity S ervices P roduct Architecture EXECUTION ARCHITECTURE CONS TR AINTS Host S oftware S ettings INFRAS TRUCTURE ARCHITECTURE Abs traction & Refinement

36 Ohjelmistotehdas-skeema Utility S ervices Portal S ervices Logical S erver Types Abs traction & Refinement Bus ines s Proces s S ervices Product Architecture EXECUTION ARCHITECTURE B us ines s Entity S ervices CONS TRAINTS Hos t S oftware S ettings INFRAS TRUCTURE ARCHITECTURE Abs traction & Refinement TRANS FORMATION / RECONCILIATION MAP TO HARDWARE Abs traction & Refinement DB Schemas Config Files Classes Other artifacts XML Schemas CRM DEPLOY. UNIT Package definitions Frameworks Components EXECUTAB LE ARTIFACTS DB Schemas Config Files Classes XML Schemas Other artifacts Package definitions es ales DEPLOY. UNIT Components Frameworks DE PLOYMENT PHYS ICAL DATACENTER

37 Ohjelmistotehdas-kaavain (template) Skeema vain kuvaa hyödykkeet, joita tuoteperheen jäsenien tekemiseen tarvitaan Myös itse hyödykkeet tarvitaan DSL:t, mallineet, kehykset, kuvatut työkalut ym. Hyödykkeet muodostavat kaavaimen Sisältää koodia ja metadataa jotka voidaan ladata työkaluun, kuten kehitysympäristöön (IDE, Interactive Development, Environment) Pitää konfiguroida tietylle perheen jäsenelle

38 Tehtaan luominen Luodaan skeema Erikoistapaus kahdesta tuotantolinjan toiminnosta (analyysi ja suunnittelu) Tuotantolinjan analyysi Mitä tuotteita tehdas tuottaa Kuvataan ongelmakenttä mihin tuotteet ratkaisuna Tuotantolinjan vaatimukset Organisoidaan verkon solmuiksi eli näkökulmiksi (viewpoints)

39 Tehtaan luominen (skeema) 2 Tuotantolinjan suunnittelu Miten tuotteita tuotetaan Määritellään perheen arkkitehtuuri (tärkein) Kuten yhden tuotteen tapauksessa, mutta tuetaan vaihtelua perheenjäsenten välillä Organisoidaan verkon solmuiksi eli näkökulmiksi Tuottaa tuotoksia (artifacts) Vaatimusten muuntaminen Verkon kaariksi Tuotteen kehitys prosessi Näkökulmiin liitettyjä mikroprosesseja Suunnitelma työkalujen käytöstä kehitysprosessin osien automatisointiin.

40 Tehtaan luominen Tehdään kaavain (template) Erikoistapaus tuotantolinjan toteutuksesta Muodostaa tuotantolinjan instanssin Pakkaa tuotantohyödykkeet ohjelmistotehtaalle Vaatimushyödykkeet (esim. määritelmäkielet) Toteutushyödykkeet (esim. mallineet, kehykset, komponentit) Prosessihyödykkeet (esim. kehitystyökalut) Testaushyödykkeet(esim. testihaarniskat) Sijoitushyödykkeet (esim tuotteen loogisten palvelimien konfiguraatioita)

41 Tehtaan luominen Jatkuva prosessi, jossa kerätään palautetta tuotteiden tekemisestä ja siten tehdasta päivitetään palautteen perusteella Suurin, vaikein ja kallein osuus kielien (DSL) ja automatisointityökalujen kehittäminen Ongelmakentän analyysin tekeminen on myös iso panostus, joka vaatii ongelmakenttään liittyvää tietoutta/näkemystä, joka mahdollisesti ostettava ulkopuolelta

42 Tuotteen luominen tehtaassa Erikoistapaus tuotteen luomisesta käyttäen tuotantolinjaa Ongelma analyysi Voidaanko tuote tehdä ohjelmistotehtaalla Tuotteen määrittely Määrittelee tuotteen vaatimukset eroina tuotelinjan vaatimuksiin Tuotteen suunnittelu Muuntaa vaatimusten erot tuotantolinjan arkkitehtuurin eroiksi ja tuotteen kehitysprosessin eroiksi Tuottaa kustomoidun tuote arkkitehtuurin ja kehitysprosessin

43 Tuotteen luominen tehtaassa Tuotteen toteutus Normaaleja toteutustoimintoja kuten komponenttien koostamista Tuotteen sijoitus (deployment) Palvelinkonfiguraatioita, suoritettavien osien sijoitusta eri palvelimille, reurssien asennusta palvelimille, suoritettavien osien konfigurointia ym. Tuotteen testaus Testaushyödykkeiden, kuten testitapausten, testihaarniskoiden, testidatan ja skriptien luomista sekä uudelleenkäyttöä Mittaustyökalujen soveltamista

44 Esimerkki Aiheen laajuudesta johtuen on esimerkit liian laajoja tähän yhteyteen Web:stä löytyy paljon esimerkkejä, joita voi myös ladata kokeiltavaksi, jos XP Professional,.Net 2.0, Visual Studio 2005, MS SQL Server... ;)

45 Tulevaisuus Lähitulevaisuudessa, seuraavan 10 vuoden aikana, tuskin tullaan näkemään joukko-siirtymistä ohjelmistotehtaiden käyttöön Massiiviset aloituskustannukset Todennäköisesti joutuisi palkkaamaan uutta henkilöstöä, jolla tietotaitoa tai hankkimaan ulkopuolista konsultointia -> kallista Vähän alan osaajia edes lähitulevaisuudessa Todella laaja konsepti Valmiiden DSL:ien hankkiminen ulkopuolelta on vaikeaa Kun komponentit esiteltiin, ennakoitiin valmiiden komponenttien hylly -kauppaa Monet yritykset sinnitteleveät projektista toiseen ja tekevät hyvin vähän prosessiensa eteen

46 Tulevaisuus Kuitenkin jotkut tahot siirtyvät jo lähitulevaisuudessa / ovat siirtyneet osittain Suurin osa menetelmistä eivät uusia ja siten vahvuudet/heikkoudet tiedossa Microsoft ajaa asiaa eteenpäin Konseptissa on järkeä Nämä tienavaajat helpottavat tulevaisuudessa muiden siirtymistä Tehtaan ei tarvitse olla kaiken tekevä ja automatisoiva ihme, vaan voidaan ottaa asteittaisesti käyttöön