CO-VAIHE

1. CO-VAIHE Oliokeskeisestä suunnittelusta OOA + muut tekniikat Oliokeskeisiä “metodologioita” Simplified Method OOA&D Coad & Yourdon, 1991 Mathiassen ym, 2000 OMT++ käyttöliittymän suunnittelussa

2. Johdanto CO-tasoon • CO-tasossa kuvataan sisäinen rakenne ja toiminta sekä kontrolli ja tukitoiminnot • secondary data IO-mallissa esitetyn perusdatan tehokkaan käytön toteuttamiseksi • esim. eheyssäännöt, saantioikeudet ohjeet yms. • teknis- ja laiteriippuvat vaiheet • siirto IO-tasolta CO-tasolle • käsiteteoreettisesti • teknisesti

3. PIOCO-asiaa CO-tasolta • IO-taso ja kohdejärjestelmän rajaus • rajatun sovelluksen kriteerit pitää tarkentaa • apuna oliokeskeinen suunnittelu CO-tasolla • vrt. PIOCO Figure 4. kriteerit • PIOCOn huomiointi CO-tasolla • “P-Design” ja “IO-Design” kiinnitetty • silti “P-Test” ja “IO-Test” mukana • kriteerit CO-tason mukaan: kokonaistehokkuus • silti käyttäjät mukana sovelluskeskeisessä analyysi-suunnittelu -tehtävissä (vrt. Jaaksi)

4. Tekniikat vs. tavoite • Olioanalyysi(Coad & Yourdon, 1991) • kaikkine “hienouksineen” • Simplified Method (Jaaksi, 1998) • use case (natural language) • class diagrams • operation list and sequence diagrams • OOA&D(Mathiassen ym., 2000) • Rich Picture, Class Diagram, Implementation Diagram, Statechart Diagram, Use Case Diagram, Navigation Diagram, Window Diagram

5. OO-lähestymistavasta • OO hankala käsite (Coad & Yourdon, 1991): • Information Modeling, reaalimaailman kuvaus • OOProgramming Language, luokkaohjelmointia • OO = Classes & Objects + Inheritance + Communication with messages • kapselointi, objektit luonnollisia, koko elinkaaren kattava (Mathiassen ym.) • sovelluskeskeisyys vs. datankäsittelysysteemit • “OO-systems support individual problem solving, communication and coordination” (Mathiassen ym.)

6. OOA&D (Coad & Yourdon, 1991) • OOA, ohjelmointikieliriippumaton 1) Finding class-&-objects 4) Defining attributes 2) Identifying structure 5) Defining services 3) Identifying subjects • OOD

7. OOA&D (Mathiassen ym.) • How to manage the solution of a unique task charactized by great uncertainty and high complexity? Concentration of • effort and • high speed (von Clausewitz, 1832) • “OOA&D are not the first activities in system development.” (Mathiassen ym.)

8. Analyysistä ja suunnittelusta • “Analysis and design cannot be reduced to pure routine. Both activities require a creative effort where experiments are combined with rational considerations…” (Mathiassen ym.) • analyysi tarkastelee sovellusta ulkopuolelta ja suunnittelu sisäpuolelta • “Analysis: an activity where some item is taken apart and described” • “Design: a constructive activity where known parts are put together in a new manner.” • molemmissa siis analyysiä ja suunnittelua

9. Simplified Method (1/2) • “the real problem with the (OO) methods available is the complexity of them” (p. 20) • vrt . PIOCOn perusideoihin • S.M. on pragmaattinen ja yksinkertainen • (uuden sovelluksen) koko elinkaari haltuun • kuvaa data, toiminta ja interaktiivisuus • dokumentoi • helppo oppia, käyttää ja laajentaa • prosess improvement team ~ fasilitaattori (s. 18)

10. Simplified Method (2/2) • Vaiheet (iteraatio sallittu) • Tarvekartoitus (Requirements Capture) • Analyysi (staattinen — funktionaalinen) • Suunnittelu (staattinen + funktionaalinen) • Ohjelmointi (staattinen + funktionaalinen) • Testaus • pala palalta kehitetään “täydellisemmäksi” (s. 16) • vrt. IE (osajoukkojen valinta)

11. Simplified M.: Tarvekartoitus • “…communicate with end users and document the requirements. All requirements should be exact and measurable.” (s. 7.) • yksinkertaiset (käyttäjäystävälliset) tekniikat • esim. use case -kuvaukset luonnollisella kielellä • toiminnalliset ja ei-toiminnalliset kriteerit • apuna myös FATCOP (OOA&D, Mathiassen ym., 2000) • Functionality, Application domain, Technology, Conditions, Object System, Philosophy

12. Simplified M.: Tarvekartoitus • “If possible, the customer should participate…” (s. 7.) • “Sketches of the user interface can make the use cases more concrete.” (s. 7.) • Keskeinen vaihe! • “In each step (of the method), phase products must be checked against the use cases and non-functional requirements. Finally, the use cases form the basic test case set for system testing.” (s.7-8)

13. Simplified M.: Analyysi • “… to understand the problem domain and the system to be implemented.” (s. 8) • operaatiot omaan listaansa pois oliomallista yksinkertaisuuden vuoksi • “… analysis is a difficult phase to master.” (s. 8) • team work • experts on analysis (IT-people) and • experts on problem domain (users, customers)

14. Simplified M.: Suunnittelu • “transform the products of the analysis phase into a form that can be implemented…” (s. 10) • select or develop application architecture • “… successful design requires good knowledge of the selected programming language, operating system, hardware,…” (s. 10) • refine models using sequence diagrams (s. 11) • “the goal is to design classes that resemble objects of the real world and are at the same time suitable for implementation.” (s. 15)

15. S. M.: Ohjelmointi ja Testaus • Ohjelmointi • “… programming of classes is based on the design class diagrams and sequenece diagrams.” • “…programming deals with the inner functionality of individual objects.” (s. 15) • Testaus • “…each use case is run with the implemented system, and every non-functional requirement is checked.” (s. 16)

16. Iteratiivisuudesta • “… the first version of the system … should be given to the end users for comments.” (s. 17) • “the use case selected for the first iteration should be the most important from the end user’s point of view.” • EHDOTUS: TJK-jatkoprojekti: tärkeimmän use casen implementointi • “the software process must be visible” (s. 17) • “visual phase products that can be discussed” • dokumentit (s. 18)

17. Simplified Method ja PIOCO • pragmaattinen ja yksinkertainen • sovelluskeskeinen! • myös tietokeskeinen ? • ohjelmistokehityksen evolutionaarisuus • S.M., PIOCO ja … • TJK ja ohjausryhmä ? • TJK ja tuote ? • TJK ja prosessi ? • TJK ja arviointi ?

18. Oliokeskeisestä suunnittelusta • Filosofia? Intellektuaali viitekehys? TJK? • Voiko P-taso kuulua OO-ajattelumaailmaan? • P-taso : ? • IO-taso: OOA ja OOD käyvät myös tähän • CO-taso: OOA&D erityisesti tässä ja B-tasolla! • sovellusrajoittunut ? tehokas ~ tekniskeskeinen? • olioajattelu vaikeaa - menetelmät hankalia ? • olioajattelun hyödyntäminen koko elinkaaressa • paras tapa lähestyä ”ohjelmoitavaa ongelmaa”?

19. Projektin hallinnasta (oliokesk.) • Simplified Method, myös OOA&D yleisesti • osallistujaroolit OK • projektin sisältö, vaihejako OK • dokumentaatio OK • fasilitaattori hyvä • ylläpito • sisältyy ongelman hallintatapaan, josta seuraa helppo ja tehokas ylläpidettävyys

20. Käyttöliittymistä • OMT++ sovellettu käyttöliittymän suunnitteluun • “kotitehtävä” • jatkoprojektin yksi keskeisistä osista • HCI ym. käyttöliittymien perusteet muualta • esim. • Suppea: Pressman, R.S. Software Engineering. A Practitioner's Approach. Third Edition, McGraw-Hill, 1992, ss. 457-480. • Laaja: Booth. P. An Introduction to Human-Computer Interaction. Lawrence Erlbaum, London. 1989.

21. Kirjallisuutta • de Champeaux ym. Object-Oriented System Development. Addison Wesley. 1993. • Coad P. & Yourdon E. Object-Oriented Analysis. Prentice-Hall. 1991 • Mathiassen L., Munk-Madsen A., Nielsen P.A., Stage J. Object-Oriented Analysis & Design, 2000. • Jaaksi A. Object-Oriented Specification of User Interfaces. Software Practice & Experience, Nov. 1995. • Booth P. 1989. An Introduction to Human-Computer Interaction. Lawrence Erlbaum, London. • Shneiderman B. Designing the user interface : strategies for effective human-computer interaction 2nd ed. Reading, Mass., Addison-Wesley, 1992. • Redmond-Pyle D. & Moore A. Graphical user interface design and evaluation (guide) : a practical process, London : Prentice Hall, 1995

22. Finally: the ISD Scope of Domain The study of ISs and their development is a multi-disciplinary subject and addresses the range of strategic, managerial and operational activities involved in gathering, processing, storing, distributing and use of information, and its associated technologies, in society and organisations. 1. Theoretical underpinnings of ISs (e.g. theories of information, systems and organisation). 2. Data, information and knowledge management (theory and practice, including information resource management, database design and management, information and knowledge-based products/services). 3. Derivation, development and maintenance of ISs and processes (e.g. theory, notation, conventions, modelling, processes, methods, techniques, technology and tools). 4. Capabilities, potential and limitations of technology as an intrinsic component of ISs. 5. Management of ISs and services (including the development and management of specialist professional skills, staff, related technologies and suppliers). 6. Information in organisational decision making (e.g. decision and role theory and use of decision support and communication systems, management ISs, executive ISs, group decision support systems). 7. Strategic alignment (the role of ISs and technology in organisation strategies, planning, investment, risk, evaluation and benefit realisation). 8. Organisational and human impact of technolgy-based ISs. 9. Economic impacts of technology-based ISs (upon organisations, industries, including the information technology industry, and national and international economies). 10.Social and cultural effects of technology-based ISs (e.g. at individual, organisational, national, international levels and implications for social policies, professional, legal and ethical standards, employment, education).