DOCSLIB.ORG

An Approach to Software Product Line Use Case Modeling LICENTIATE THESIS, 2006

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
An Approach to Software Product Line Use Case Modeling LICENTIATE THESIS, 2006 Magnus Eriksson An Approach to Software Product Line Use Case Modeling LICENTIATE THESIS, 2006 DEPARTMENT OF COMPUTING SCIENCE UMEÅ UNIVERSITY SE-90187 UMEÅ, SWEDEN © Magnus Eriksson, 2006 Print & Media, Umeå University UMINF-06.01 ISSN 0348-0542 ISBN 91-7264-023-5 iii Abstract Organizations developing software intensive defense systems are today faced with a number challenges related to characteristics of both the market place and the system domain: 1. Systems grow ever more complex, consisting of tightly integrated mechanical, electrical/electronic and software components. 2. Systems are often developed in short series; ranging from only a few to a few hundred units. 3. Systems have very long life spans, typically 30 years or longer. 4. Systems are developed with high commonality between different customers; however systems are always customized for specific needs. The goal of the research presented in this thesis is to investigate methods and tools to enable efficient development and maintenance of systems in such a context. The strategy adopted in this work is to utilize the forth system characteristic, high commonality, to achieve this. One approach to software reuse, which could be a potential solution as it enables reuse of common parts but at the same time allow for variations, is known as software product line development. The basic idea of this approach is to use domain knowledge to identify common parts within a family of related products and to separate them from the differences between the products. The commonalties are then used to create a product platform that can be used as a common baseline for all products within such a product family. The main contribution of this licentiate thesis is a product line use case modeling approach tailored towards organizations developing software intensive defense systems. We describe how a common and complete use case model can be developed and maintained for a whole family of products, and how the variations within such a family are modeled using a feature model. Concrete use case models, for particular products within a family, can then be generated by selecting features from a feature model. We furthermore describe extensions to the commercial requirements management tool Telelogic DOORS and the UML modeling tool IBM-Rational Rose to support the proposed approach. The approach was applied and evaluated in an industrial case study in the target domain. Based on the collected case study data we draw the conclusion that the approach performs better than modeling according to the styles and guidelines specified by the IBM-Rational Unified Process (RUP) in the current industrial context. The results however also indicate that for the approach to be successfully applied, stronger configuration management and product planning functions than traditionally found in RUP projects are needed. v Acknowledgements There are many people involved in the completion of this licentiate thesis that I am very grateful to. First of all, I would like to thank my academic supervisor Associate Professor Jürgen Börstler, and my industrial supervisor Kjell Borg. You always make yourselves available to discuss my ideas, and your advice has significantly increased the quality of my work. Dr. Örjan Olsson and Mats Bergström, without your support this doctorial project would never have been initiated in first place. Mats, I am really sad that you are no longer with us to see how it is starting to transform development at Hägglunds. Henrik Morast, without your enthusiasm developing tools to support my ideas, they would have had far less influence on development at Hägglunds. Thank you also for your sanity checks of my tool ideas. Dr. Carl-Gustav Löf and Conny Flemin, thank you for believing in me and providing me with the means to apply my ideas at Hägglunds. All the people at Hägglunds that applied my ideas and participated in my studies, without you, none of this work would have been possible. Thank you all! Dr. Charilaos Christopoulos, my master thesis supervisor at Ericsson Research, without your encouragement I would never have pursued a research degree in the first place. Finally, I would like to thank my family for their support, but also apologize to them. Conducting process improvement activities is very rewarding when things work out right, but sometimes also very frustrating when they do not. Thank you for always being there for me when I needed you, and sorry for all those long hours that were required to finish this work. Umeå, December 2005 Magnus Eriksson vii Preface This licentiate thesis consists of the following three papers and an introduction to the research area (Kappa): I. M. Eriksson, J. Börstler & K. Borg (2004): Marrying Features and Use Cases for Product Line Requirements Modeling of Embedded Systems1, Proceedings of the Fourth Conference on Software Engineering Research and Practice in Sweden, Institute of Technology, UniTryck, Linköping University, Sweden, pp. 73-82 II. M. Eriksson, J. Börstler & K. Borg (2005): The PLUSS Approach ─ Domain Modeling with Features, Use Cases and Use Case Realizations2, Proceedings of the 9'th International Conference on Software Product Lines, LNCS, Vol. 3714, Springer-Verlag, pp. 33-44 III. M. Eriksson, H. Morast, J. Börstler & K. Borg (2005): The PLUSS Toolkit ─ Extending Telelogic DOORS and IBM-Rational Rose to Support Product Line Use Case Modeling3, Proceedings of the 20th IEEE/ACM International Conference on Automated Software Engineering, Long Beach California, ACM Press, pp. 300-304 These papers have been reformatted, compared to the original publication, to have a consistent layout with the rest of the thesis. Furthermore, minor typographical errors have also been corrected. 1 © Magnus Eriksson, 2004 2 © Springer-Verlag, 2005 3 © ACM Press, 2005 ix Table of Contents 1 THESIS INTRODUCTION ____________________________________1 1.1 Background and Motivation __________________________________ 1 1.2 Research Question __________________________________________ 1 1.3 Research Context ___________________________________________ 1 1.4 Research Hypothesis ________________________________________ 3 1.5 Thesis Outline _____________________________________________ 3 2 RESEARCH METHOD ______________________________________3 3 SOFTWARE PRODUCT LINES________________________________5 3.1 Reuse ____________________________________________________ 6 3.2 Product Line Management____________________________________ 7 3.3 Essential Artifacts __________________________________________ 8 4 REQUIREMENTS ENGINEERING ____________________________10 4.1 Traceability ______________________________________________ 10 4.2 Use Case Modeling ________________________________________ 11 4.3 Feature Modeling__________________________________________ 12 5 THE IBM-RATIONAL UNIFIED PROCESS (RUP) _______________13 5.1 Develop Iteratively ________________________________________ 14 5.2 Manage Requirements ______________________________________ 17 5.3 Use Component Architectures ________________________________ 17 5.4 Model Visually ___________________________________________ 18 5.5 Continuously Verify Quality _________________________________ 18 5.6 Manage Change ___________________________________________ 19 6 THE PROPOSED APPROACH _______________________________19 6.1 Related Work_____________________________________________ 20 6.2 Marrying Use Case Modeling with Feature Modeling______________ 22 6.3 Product Instantiation _______________________________________ 23 6.4 A Note on Notations Used ___________________________________ 24 6.5 Tool Support _____________________________________________ 25 7 SUMMARY OF CONTRIBUTIONS ____________________________25 7.1 Paper I – Marrying Features and Use Cases _____________________ 26 7.2 Paper II – The PLUSS Approach______________________________ 26 7.3 Paper III – The PLUSS Toolkit _______________________________ 26 8 ONGOING AND FUTURE WORK _____________________________27 8.1 Test of Research Hypothesis _________________________________ 27 8.2 Further Development and Evaluation of the Proposed Approach _____ 27 8.3 Reuse of Systems Engineering Specifications ____________________ 28 8.4 Managing Variants in Design Specifications_____________________ 29 REFERENCES_______________________________________________29 PAPER I __________________________________________________ 35 PAPER II _________________________________________________ 53 PAPER III ________________________________________________ 67 Kappa 1 1 Thesis Introduction 1.1 Background and Motivation Organizations developing software intensive defense systems are today faced with a number challenges. These challenges, which are related to characteristics of both the market place and the system domain, include: 1. Systems grow ever more complex, consisting of tightly integrated mechanical, electrical/electronic and software components. This implies that strong means of communication between different engineering disciplines are important to achieve efficient development. 2. Systems are often developed in short series; ranging from a few to a few hundred units. This implies that it is important to achieve efficient development, since development costs are carried by only a few units. 3. Systems have very long life spans, typically 30 years or longer. This implies that it is important to develop high quality systems, and to achieve effective maintenance of these systems once developed. 4. Systems are developed with high commonality between different customers; however systems are
Load more

Recommended publications
  • Revealing the Secrets of David Parnas
    Revealing the Secrets of David Parnas H. Conrad Cunningham Department of Computer and Information Science University of Mississippi March 7, 2014 Those of us in the fast-changing field of computing often dismiss anything writ- ten more than five years ago as obsolete. Yet several decades-old papers by David L. Parnas [1, 4, 5, 6, 7, 8] are as timely as those published in recent issues of the top journals. Parnas articulates the timeless software design concepts known as information hiding and abstract interfaces. Most programmers would describe a module as a unit of code such as a sub- routine or class. Parnas focuses on the programmers rather than the programs. He defines a module as \a work assignment given to a programmer or group of programmers" as a part of a larger software development project [7]. His goals are to enable programmers to develop each module independently, change one module without affecting other modules, and comprehend the overall system by examining one module at a time [5]. Programmers often design a software system by breaking the required pro- cessing into steps and making each step a module. Instead, Parnas uses in- formation hiding to decompose the system into modules that satisfy his goals (2); each module keeps its own secreta design decision about some aspect of the system (e.g., choice of a data structure). A modules design decision can change but none of the other modules should be affected. If some aspect is unlikely to change, the design can distribute this knowledge across several modules and the interfaces among them.
    [Show full text]
  • ASP.NET MVC with Entity Framework and CSS
    ASP.NET MVC with Entity Framework and CSS Lee Naylor ASP.NET MVC with Entity Framework and CSS Lee Naylor Newton-le-Willows, Merseyside United Kingdom ISBN-13 (pbk): 978-1-4842-2136-5 ISBN-13 (electronic): 978-1-4842-2137-2 DOI 10.1007/978-1-4842-2137-2 Library of Congress Control Number: 2016952810 Copyright © 2016 by Lee Naylor This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made.
    [Show full text]
  • Configuring Metadata Manager Privileges and Permissions
    Configuring Metadata Manager Privileges and Permissions © Copyright Informatica LLC 1993, 2021. Informatica LLC. No part of this document may be reproduced or transmitted in any form, by any means (electronic, photocopying, recording or otherwise) without prior consent of Informatica LLC. All other company and product names may be trade names or trademarks of their respective owners and/or copyrighted materials of such owners. Abstract You can configure privileges to allow users access to the features in Metadata Manager. You can configure permissions to allow access to resources or objects in Metadata Manager. This article describes the privileges and permissions that you can configure in Metadata Manager. Supported Versions • Metadata Manager 9.6.1 Table of Contents Introduction................................................................ 2 Users, Groups, Privileges, and Roles................................................ 3 Privileges ................................................................. 4 Catalog Privilege Group...................................................... 4 Load Privilege Group........................................................ 6 Model Privilege Group....................................................... 7 Security Privilege Group...................................................... 7 Permissions................................................................ 8 Types of Permissions........................................................ 9 Rules and Guidelines.......................................................
    [Show full text]
  • Writing and Reviewing Use-Case Descriptions
    Bittner/Spence_06.fm Page 145 Tuesday, July 30, 2002 12:04 PM PART II WRITING AND REVIEWING USE-CASE DESCRIPTIONS Part I, Getting Started with Use-Case Modeling, introduced the basic con- cepts of use-case modeling, including defining the basic concepts and understanding how to use these concepts to define the vision, find actors and use cases, and to define the basic concepts the system will use. If we go no further, we have an overview of what the system will do, an under- standing of the stakeholders of the system, and an understanding of the ways the system provides value to those stakeholders. What we do not have, if we stop at this point, is an understanding of exactly what the system does. In short, we lack the details needed to actually develop and test the system. Some people, having only come this far, wonder what use-case model- ing is all about and question its value. If one only comes this far with use- case modeling, we are forced to agree; the real value of use-case modeling comes from the descriptions of the interactions of the actors and the system, and from the descriptions of what the system does in response to the actions of the actors. Surprisingly, and disappointingly, many teams stop after developing little more than simple outlines for their use cases and consider themselves done. These same teams encounter problems because their use cases are vague and lack detail, so they blame the use-case approach for having let them down. The failing in these cases is not with the approach, but with its application.
    [Show full text]
  • Lecture for Chapter 2, Modeling With
    09/10/2019 Overview: modeling with UML Modeling with UML What is modeling? What is UML? Use case diagrams Class diagrams Oriented Software Engineering - Object What is modeling? Example: street map Modeling consists of building an abstraction of reality. Abstractions are simplifications because: They ignore irrelevant details and They only represent the relevant details. What is relevant or irrelevant depends on the purpose of the model. Why model software? Systems, Models and Views Why model software? A model is an abstraction describing a subset of a system A view depicts selected aspects of a model Software is getting increasingly more complex A notation is a set of graphical or textual rules for depicting views Windows XP > 40 million lines of code Views and models of a single system may overlap each other A single programmer cannot manage this amount of code in its entirety. Code is not easily understandable by developers who did not Examples: write it System: Aircraft We need simpler representations for complex systems Models: Flight simulator, scale model Modeling is a mean for dealing with complexity Views: All blueprints, electrical wiring, fuel system 1 09/10/2019 Systems, Models and Views Models, Views and Systems (UML) Flightsimulator Blueprints * * System Model View Aircraft Described by Depicted by Model 2 View 2 View 1 System Airplane: System View 3 Model 1 Scale Model: Model Flight Simulator: Model Electrical Wiring Scale Model Blueprints: View Fuel System: View Electrical Wiring: View What is UML? What is UML? UML (Unified Modeling Language) The Unified Modeling Language (UML) is a language for Specifying An emerging standard for modeling object-oriented software.
    [Show full text]
  • Document Title Requirements on Debugging in AUTOSAR
    Requirements on Debugging in AUTOSAR AUTOSAR Release 4.2.2 Document Title Requirements on Debugging in AUTOSAR Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification No 332 Document Classification Auxiliary Document Status Final Part of AUTOSAR Release 4.2.2 Document Change History Release Changed by Change Description 4.2.2 AUTOSAR Marked the document as obsolete Release Management 4.2.1 AUTOSAR Editorial changes Release Management 4.1.2 AUTOSAR Updated reference to RS feature document Release Editorial changes Management 4.1.1 AUTOSAR Updated the format of requirements according Administration to TPS_StandardizationTemplate Updated the chapters 2 and 5 Replaced Complex Device Driver by Complex Driver 3.1.5 AUTOSAR Initial release Administration 1 of 19 Document ID 332: AUTOSAR_SRS_Debugging - AUTOSAR confidential - Requirements on Debugging in AUTOSAR AUTOSAR Release 4.2.2 Disclaimer This specification and the material contained in it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR and the companies that have contributed to it shall not be liable for any use of the specification. The material contained in this specification is protected by copyright and other types of Intellectual Property Rights. The commercial exploitation of the material contained in this specification requires a license to such Intellectual Property Rights. This specification may be utilized or reproduced without any modification, in any form or by any means, for informational purposes only. For any other purpose, no part of the specification may be utilized or reproduced, in any form or by any means, without permission in writing from the publisher. The AUTOSAR specifications have been developed for automotive applications only.
    [Show full text]
  • The Guide to Succeeding with Use Cases
    USE-CASE 2.0 The Guide to Succeeding with Use Cases Ivar Jacobson Ian Spence Kurt Bittner December 2011 USE-CASE 2.0 The Definitive Guide About this Guide 3 How to read this Guide 3 What is Use-Case 2.0? 4 First Principles 5 Principle 1: Keep it simple by telling stories 5 Principle 2: Understand the big picture 5 Principle 3: Focus on value 7 Principle 4: Build the system in slices 8 Principle 5: Deliver the system in increments 10 Principle 6: Adapt to meet the team’s needs 11 Use-Case 2.0 Content 13 Things to Work With 13 Work Products 18 Things to do 23 Using Use-Case 2.0 30 Use-Case 2.0: Applicable for all types of system 30 Use-Case 2.0: Handling all types of requirement 31 Use-Case 2.0: Applicable for all development approaches 31 Use-Case 2.0: Scaling to meet your needs – scaling in, scaling out and scaling up 39 Conclusion 40 Appendix 1: Work Products 41 Supporting Information 42 Test Case 44 Use-Case Model 46 Use-Case Narrative 47 Use-Case Realization 49 Glossary of Terms 51 Acknowledgements 52 General 52 People 52 Bibliography 53 About the Authors 54 USE-CASE 2.0 The Definitive Guide Page 2 © 2005-2011 IvAr JacobSon InternationAl SA. All rights reserved. About this Guide This guide describes how to apply use cases in an agile and scalable fashion. It builds on the current state of the art to present an evolution of the use-case technique that we call Use-Case 2.0.
    [Show full text]
  • UML Tutorial: Part 1 -- Class Diagrams
    UML Tutorial: Part 1 -- Class Diagrams. Robert C. Martin My next several columns will be a running tutorial of UML. The 1.0 version of UML was released on the 13th of January, 1997. The 1.1 release should be out before the end of the year. This col- umn will track the progress of UML and present the issues that the three amigos (Grady Booch, Jim Rumbaugh, and Ivar Jacobson) are dealing with. Introduction UML stands for Unified Modeling Language. It represents a unification of the concepts and nota- tions presented by the three amigos in their respective books1. The goal is for UML to become a common language for creating models of object oriented computer software. In its current form UML is comprised of two major components: a Meta-model and a notation. In the future, some form of method or process may also be added to; or associated with, UML. The Meta-model UML is unique in that it has a standard data representation. This representation is called the meta- model. The meta-model is a description of UML in UML. It describes the objects, attributes, and relationships necessary to represent the concepts of UML within a software application. This provides CASE manufacturers with a standard and unambiguous way to represent UML models. Hopefully it will allow for easy transport of UML models between tools. It may also make it easier to write ancillary tools for browsing, summarizing, and modifying UML models. A deeper discussion of the metamodel is beyond the scope of this column. Interested readers can learn more about it by downloading the UML documents from the rational web site2.
    [Show full text]
  • The Timeboxing Process Model for Iterative Software Development
    The Timeboxing Process Model for Iterative Software Development Pankaj Jalote Department of Computer Science and Engineering Indian Institute of Technology Kanpur – 208016; India Aveejeet Palit, Priya Kurien Infosys Technologies Limited Electronics City Bangalore – 561 229; India Contact: [email protected] ABSTRACT In today’s business where speed is of essence, an iterative development approach that allows the functionality to be delivered in parts has become a necessity and an effective way to manage risks. In an iterative process, the development of a software system is done in increments, each increment forming of an iteration and resulting in a working system. A common iterative approach is to decide what should be developed in an iteration and then plan the iteration accordingly. A somewhat different iterative is approach is to time box different iterations. In this approach, the length of an iteration is fixed and what should be developed in an iteration is adjusted to fit the time box. Generally, the time boxed iterations are executed in sequence, with some overlap where feasible. In this paper we propose the timeboxing process model that takes the concept of time boxed iterations further by adding pipelining concepts to it for permitting overlapped execution of different iterations. In the timeboxing process model, each time boxed iteration is divided into equal length stages, each stage having a defined function and resulting in a clear work product that is handed over to the next stage. With this division into stages, pipelining concepts are employed to have multiple time boxes executing concurrently, leading to a reduction in the delivery time for product releases.
    [Show full text]
  • How to Build a UML Model Announcements Rational Unified
    Announcements How to build a UML model ❚ HW3 – Phase 1 due on Feb 6th, 5:00pm (need to create new pairs, accounts) ❚ Feedback on M2: turn procedural code RUP into OO code, Planning game (show tables Steriotypes, packages, and with features, subtasks, estimates, object diagrams actuals, pair-programming partners) Case study ❚ Register for the Feb 18 Industry Reception 1 CS361 7-2 Rational Unified Process How RUP builds a model ❚ Designed to work with UML ❚ Gather use cases from customer ❚ No longer being promoted by IBM ❚ Make initial object model ❚ Roles - (out of 20 or so) ❚ For each use case: ❙ Architect ❙ step through use case, ❙ UI designer ❙ note the objects it requires ❙ Use case specifier ❙ note the operations it uses ❙ Use case engineer ❙ Component engineer ❚ Clean up the model CS361 7-3 CS361 7-4 Architect UI design ❚ Determine which use cases need to be ❚ Logical design developed first. ❙ Which user-interface elements are needed for ❚ High priority use cases each use case? ❙ describe important and critical functionality ❙ What information does the actor need to receive from or give to the system? ❘ security ❘ database ❚ Prototyping ❙ hard to retrofit later ❙ Often is on paper. ❙ Test on real users CS361 7-5 CS361 7-6 1 Requirements Specification Analysis model ❚ Not all requirements go in a use case. ❚ Class diagrams ❙ Example: security ❙ vague interfaces (“responsibilities”) ❙ Example: global performance ❙ vague associations (ignore navigability) ❚ Requirements document describes all ❙ stereotype classes: other requirements
    [Show full text]
  • Best Practice of SOA
    JOURNAL OF COMPUTING, VOLUME 2, ISSUE 2, FEBRUARY 2010, ISSN: 2151-9617 38 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ Improvement in RUP Project Management via Service Monitoring: Best Practice of SOA Sheikh Muhammad Saqib1, Shakeel Ahmad1, Shahid Hussain 2, Bashir Ahmad 1 and Arjamand Bano3 1Institute of Computing and Information Technology Gomal University, D.I.Khan, Pakistan 2 Namal University, Mianwali , Pakistan 3 Mathematics Department Gomal University, D.I.Khan, Pakistan Abstract-- Management of project planning, monitoring, scheduling, estimation and risk management are critical issues faced by a project manager during development life cycle of software. In RUP, project management is considered as core discipline whose activities are carried in all phases during development of software products. On other side service monitoring is considered as best practice of SOA which leads to availability, auditing, debugging and tracing process. In this paper, authors define a strategy to incorporate the service monitoring of SOA into RUP to improve the artifacts of project management activities. Moreover, the authors define the rules to implement the features of service monitoring, which help the project manager to carry on activities in well define manner. Proposed frame work is implemented on RB (Resuming Bank) application and obtained improved results on PM (Project Management) work. Index Terms—RUP, SOA, Service Monitoring, Availability, auditing, tracing, Project Management NTRODUCTION 1. I 2. RATIONAL UNIFIED PROCESS (RUP) Software projects which are developed through RUP RUP is a software engineering process model, which provides process model are solution oriented and object a disciplined approach to assigning tasks and responsibilities oriented. It provides a disciplined approach to within a development environment.
    [Show full text]
  • Architectural Improvement of Display Viewer 5 Software
    Teemu Vähä-Impola Architectural Improvement of Display Viewer 5 Software Master’s Thesis in Information Technology November 6, 2020 University of Jyväskylä Faculty of Information Technology Author: Teemu Vähä-Impola Contact information: [email protected] Supervisors: PhD Raino Mäkinen, MSc Tommy Rikberg, and MSc Lauri Saurus Title: Architectural Improvement of Display Viewer 5 Software Työn nimi: Display Viewer 5 -ohjelmiston arkkitehtuurin parantaminen Project: Master’s Thesis Study line: Software Technology Page count: 76+1 Abstract: In this thesis, an improved architecture for Display Viewer 5 (DV5) software was studied. The new architecture would enforce MVVM architecture more strongly, make clearer divisions of the software’s parts and enhance maintainability and reusability of the software, thus making the software more customizable for new projects and suitable for the customers’ needs. As a result, the existing MVVM architecture was strengthened by enforcing division into models, views and viewmodels. In addition, redundant duplications were removed and certain code was divided into their own separate entities. Keywords: architecture, software engineering Suomenkielinen tiivistelmä: Tässä tutkielmassa Display Viewer 5 (DV5) -ohjelmistolle pyrittiin löytämään parempi arkkitehtuuri, jonka seurauksena huollettavuus ja uudelleenkäytet- tävyys kasvavat ja ohjelmiston kustomointi uusille asiakkaille helpottuu. Tuloksena päädyt- tiin vahvistamaan jo nykyistä MVVM-arkkitehtuuria tekemällä jokaiselle luokalle tarvitta- van arkkitehtuurin
    [Show full text]