DOCSLIB.ORG

Proof-Of-Concept of Model-Based Testing Based on an UML-Model of a Water-Level Measurement System

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Faculty of Technology and Society Master thesis Proof-of-concept of Model-based testing based on an UML-model of a water-level measurement system Zoubida Alshekhly Namra Jamshaid Gill Exam: Computer Science, Master’s Programme (One Year) Subject Area: Computer Science Date: 08/11-2019 Abstract Software testing is a very important phase in software development as it minimize risks in a software system, however, it consumes time and can be very expensive. With automatic test case generation time consumption and cost can be reduced. Model-based testing is a method to test a software system with a model of the systems behaviour. Automatic test case generation is often considered a favorable support in model-based testing. In this work, the concept of model-based testing is explored along with testing the embedded part of a water-level measurement system (WLM) to investigate the efficiency of model-based testing on a software system. As a result of this, a model-based testing tool, MoMut::UML is used to generate the test-cases on the UML model of WLM system that is built in a UML modeling environment, Eclipse-Papyrus. However, MoMut::UML implements a special type of model-based testing technique, model-based mutation testing; that injects faults in the UML model, and generates test-data on the fault-based model. By this, the behaviour of system-under-test, only the UML model of water-level measurement system, is tested. Keywords: Model-based testing, Model-based testing tool, software system, UML, auto- matic test case generation. Glossary LORAWAN: The LoRaWAN specification is a Low Power, Wide Area (LPWA) network- ing protocol designed to wirelessly connect battery operated ‘things’ to the internet in regional, national or global networks, and targets key Internet of Things (IoT) require- ments such as bi-directional communication, end-to-end security, mobility and localization services. System under test (SUT):System under test refers to a system that is being tested for correct operation. Test oracles:Test oracle, is a mechanism for determining whether a test has passed or failed. The Object Constraint Language (OCL): is a declarative language describing rules applying to Unified Modeling Language (UML) models. 3 Contents 1 Introduction1 1.1 Background....................................1 1.2 Vision of this work................................2 1.3 Contribution and novelty of this work.....................2 1.4 Motivation of using water-level measurement system.............2 1.5 Research aim and research questions......................3 1.5.1 Research aim...............................3 1.5.2 Research question (RQ).........................3 1.6 Scope and limitations..............................3 1.6.1 Research limitations...........................3 2 Theoretical background4 2.1 Automatic testing on software systems.....................4 2.2 Model-Based Testing...............................4 2.3 UML (Unified Modeling Language).......................5 2.4 Model-based testing test criteria........................5 2.5 Model-based testing tools............................6 3 Related work7 3.1 Experiences of System-Level Model-Based GUI Testing of an Android Ap- plication......................................7 3.2 Model Based Testing of System Requirements using UML Use Case Models7 3.3 An Evaluation of Model-Based Testing in Embedded Applications......7 3.4 Water-level measurement system (WLM)....................8 4 Method 10 4.1 Nunamaker and Chen’s methodology...................... 10 4.1.1 Construction of a Conceptual Framework............... 10 4.1.2 Development of a System Architecture................. 11 4.1.3 Analyze and Design the System..................... 11 4.1.4 Build the System............................. 11 4.1.5 Observe and Evaluate the System.................... 11 5 Implementation 12 5.1 Problem breakdown............................... 12 5.2 MBT tool literature review........................... 13 5.3 System Architecture............................... 15 5.3.1 System Architecture of whole process.................. 15 5.4 Model-Based Testing............................... 16 5.4.1 UML model................................ 16 5.4.2 Papyrus.................................. 18 5.4.3 UML model in Papyrus......................... 20 5.4.4 Model based testing tool - MoMuT::UML............... 22 4 5.5 Perform Model-Based Testing.......................... 23 5.5.1 Configuration of MoMut - tool..................... 24 5.5.2 Running the MoMut - tool with the AlarmSystem demo....... 26 5.5.3 Running the MoMut - tool with the water-level measurement system 29 5.6 Model-based Test suite generation....................... 33 6 Results & Analysis 36 6.1 Analysis of Model-based testing......................... 36 6.1.1 Challenges with model-based testing tool: MoMut:UML....... 36 6.1.2 Analysis of UML model......................... 37 6.1.3 Analysis of MBMT Test-suite generation................ 37 6.1.4 Drawbacks of Model-based testing................... 38 6.2 Analyse of the chosen command-line option for MoMut............ 38 6.3 Benefits of MoMut::UML for Model-based testing............... 39 7 Threats to Validity 39 8 Discussion & Conclusion 40 8.1 Awnsering the research questions........................ 40 8.2 Future work.................................... 41 8.3 Conclusion..................................... 41 References 42 9 Appendix A 45 10 Appendix B 46 5 6 1 Introduction This section presents the background of this work followed by the vision, the research aim and the research questions. The vision includes the contribution, and the novelty of the work. Moreover, the scope and limitations are also presented. 1.1 Background Testing is the evaluation process to improve the quality of a product [1]. During the execution of testing a software system, a failure can be detected. The failures are caused by faults in the software system. The faults are usually caused by human-error in design, code etc. When a failure is detected, the fault can be investigated. There are different types of software testing methods, techniques, and test data genera- tion. The different types of testing differ depending on their scale, characteristics and the information needed to design the tests. Examples of testing are; component testing, inte- gration testing, system testing, functional testing, robustness testing, performance testing, usability testing, black-box, white-box testing, and model-based testing which is a form of black-box testing [1]. The model-based testing generates functional tests and can be used for robustness testing. Figure1, illustrates a graph of how the different types of testing are divided into three axis. Every axis represent an aspect in testing, the first axis represents the scale of the system under test, SUT, the second one represents which characteristics to test, and the third axis shows the type of information to test. The figure also shows how the model-based testing is related to these different axis. Figure 1: Different types of testing One of the fundamental factors in software testing is the automatic test case generation. Automatic Test case generation for software testing indicates a process that generates test cases automatically. The automatic test case generation technique is convincing as it re- duces the cost and time, and increase the system efficiency, when it is compared to other 1 test generation processes [2]. The model-based testing (MBT) technique, is one of the popular searched phrases in con- nection with automatic test case generation. Model-based testing is built with the model of a system, in order to generate test cases of the model of a system [3]. There are multiple types of models that can be used in MBT. However, the most practical and widely used model for supporting the MBT technique is the unified modeling language, UML[4]. MBT technique is used in tools that are able to generate test cases by analyzing the behavior of the UML model. Model-based testing have different test criteria, and one of these criteria is used in this work and mentioned in section 2.4 [1]. The SUT used in this work is a water level measurement system [5]. The system consists of different technical parts: embedded, dashboard as a frontend, and a network part. The MBT is performed on the embedded part of the system. The motivation for selecting the embedded system part is mentioned in section 1.4. 1.2 Vision of this work The vision of this work is to provide a proof-of-concept of MBT. For this aim MBT is performed on an embedded system of water-level measurement system which is presented in section 3.4. Subsequently, a guide on how to implement and perform MBT is provided based on the experience developed while performing MBT. 1.3 Contribution and novelty of this work The contribution of the work is to provide the IT industry a base to start adopting MBT by creating an easy-to-follow guide on how to implement MBT. The guide indicates a clear explanation on how to test an embedded system using a specific MBT tool. In this way, a proof-of-concept of the MBT is established to illuminate the privileges of MBT approach. 1.4 Motivation of using water-level measurement system The motivation for using the water-level measurement system, WLM, as a test material for this work is because the system is already manually tested [5]. The automatically generated test cases are conducted by using a MBT tool. The reason behind selecting the embedded system part and not the other associated parts; the front-end part is presented as an open source dashboard, and the interface of the dashboard is not reachable for testing. The network part of the water-level measurement i.e. LoRaWAN network is also unreachable for executing test cases through MBT. Although, the embedded part of the system works as a state-machine and therefor is reasonable for MBT to test. 2 1.5 Research aim and research questions 1.5.1 Research aim The aim of this work is to provide a guide that explains how to generate test cases along with a model-based testing tool. To clarify, this work is a proof-of-concept of model-based testing implemented on a embedded system with test cases generated based on the UML model.
Recommended publications
  • ON SOFTWARE TESTING and SUBSUMING MUTANTS an Empirical Study

    ON SOFTWARE TESTING and SUBSUMING MUTANTS an Empirical Study

    ON SOFTWARE TESTING AND SUBSUMING MUTANTS An empirical study Master Degree Project in Computer Science Advanced level 15 credits Spring term 2014 András Márki Supervisor: Birgitta Lindström Examiner: Gunnar Mathiason Course: DV736A WECOA13: Web Computing Magister Summary Mutation testing is a powerful, but resource intense technique for asserting software quality. This report investigates two claims about one of the mutation operators on procedural logic, the relation operator replacement (ROR). The constrained ROR mutant operator is a type of constrained mutation, which targets to lower the number of mutants as a “do smarter” approach, making mutation testing more suitable for industrial use. The findings in the report shows that the hypothesis on subsumption is rejected if mutants are to be detected on function return values. The second hypothesis stating that a test case can only detect a single top-level mutant in a subsumption graph is also rejected. The report presents a comprehensive overview on the domain of mutation testing, displays examples of the masking behaviour previously not described in the field of mutation testing, and discusses the importance of the granularity where the mutants should be detected under execution. The contribution is based on literature survey and experiment. The empirical findings as well as the implications are discussed in this master dissertation. Keywords: Software Testing, Mutation Testing, Mutant Subsumption, Relation Operator Replacement, ROR, Empirical Study, Strong Mutation, Weak Mutation
  • Open Research Online UML in Practice Oro.Open.Ac.Uk

    Open Research Online UML in Practice Oro.Open.Ac.Uk

    Open Research Online The Open University’s repository of research publications and other research outputs UML in practice Conference Item How to cite: Petre, Marian (2013). UML in practice. In: 35th International Conference on Software Engineering (ICSE 2013), 18-26 May 2013, San Francisco, CA, USA (forthcoming), pp. 722–731. For guidance on citations see FAQs. c 2013 IEEE Version: Accepted Manuscript Link(s) to article on publisher’s website: http://2013.icse-conferences.org/ Copyright and Moral Rights for the articles on this site are retained by the individual authors and/or other copy- right owners. For more information on Open Research Online’s data policy on reuse of materials please consult the policies page. oro.open.ac.uk UML in Practice Marian Petre Centre for Research in Computing The Open University Milton Keynes, UK [email protected] Abstract—UML has been described by some as “the lingua UML “with rigor” (as he later expressed to the informant). In franca of software engineering”. Evidence from industry does contrast, the informant concluded that probably 45 of the 47 not necessarily support such endorsements. How exactly is UML were like him: “selective borrowers” … “who use some of the being used in industry – if it is? This paper presents a corpus of principles sometimes”. The IBM speaker and the informant interviews with 50 professional software engineers in 50 had very different models of what ‘using UML’ means in companies and identifies 5 patterns of UML use. practice, with different implications. Index Terms—UML, software development, software design, Budgen et al.
  • Tool Use in Software Modelling Education

    Tool Use in Software Modelling Education

    Tool use in software modelling education Seiko Akayama1, Birgit Demuth3, Timothy C. Lethbridge4, Marion Scholz2, Perdita Stevens5, and Dave R. Stikkolorum6 1 Kyushu University, Japan 2 Vienna University of Technology, Austria 3 Technische Universit¨atDresden, Germany 4 University of Ottawa Canada 5 University of Edinburgh Scotland 6 Leiden University The Netherlands Abstract. An important decision that must be taken by anyone design- ing a course involving (object oriented software) modelling is what tool support, if any, to use. Options include picking an industrial strength modelling tool, using a tool specifically designed for educational use, or eschewing tool use altogether in favour of pencil and paper. The best an- swer will depend on many factors, including the prior experience of the students (and staff), the length and organisation of the course, and the learning objectives. Moreover, decisions on tools have an impact on other aspects of course design. In this informal paper, the result of discussion at the MODELS Educators' Symposium 2013, we survey previous work on this question, discuss our own experience, and draw out some key issues that someone designing a new course involving modelling must consider. 1 Introduction Teaching object oriented design and modelling in a university is important not only because these are important skills that students will need if they pursue careers in software development, but also because this area is a key interface be- tween research and teaching. This double motivation { we might say, vocational and intellectual { for teaching design and modelling is itself a source of challenge for educators. We experience a tension between the desire to train students in the skills they will need after university, and the desire to have them reflect on the nature of design and modelling and the ways in which these activities could be improved with the help of cutting edge research.
  • Thesis Template

    Thesis Template

    Automated Testing: Requirements Propagation via Model Transformation in Embedded Software Nader Kesserwan A Thesis In The Concordia Institute For Information System Engineering Presented in Partial Fulfillment of the Requirements For the Degree of Doctor of Philosophy (Information and Systems Engineering) at Concordia University Montreal, Quebec, Canada March 2020 © Nader Kesserwan 2020 ABSTRACT Automated Testing: Requirements Propagation via Model Transformation in Embedded Software Nader Kesserwan, Ph.D. Concordia University, 2020 Testing is the most common activity to validate software systems and plays a key role in the software development process. In general, the software testing phase takes around 40-70% of the effort, time and cost. This area has been well researched over a long period of time. Unfortunately, while many researchers have found methods of reducing time and cost during the testing process, there are still a number of important related issues such as generating test cases from UCM scenarios and validate them need to be researched. As a result, ensuring that an embedded software behaves correctly is non-trivial, especially when testing with limited resources and seeking compliance with safety-critical software standard. It thus becomes imperative to adopt an approach or methodology based on tools and best engineering practices to improve the testing process. This research addresses the problem of testing embedded software with limited resources by the following. First, a reverse-engineering technique is exercised on legacy software tests aims to discover feasible transformation from test layer to test requirement layer. The feasibility of transforming the legacy test cases into an abstract model is shown, along with a forward engineering process to regenerate the test cases in selected test language.
  • Testing, Debugging & Verification

    Testing, Debugging & Verification

    Testing, debugging & verification Srinivas Pinisetty This course Introduction to techniques to get (some) certainty that your program does what it’s supposed to. Specification: An unambiguous description of what a function (program) should do. Bug: failure to meet specification. What is a Bug? Basic Terminology ● Defect (aka bug, fault) introduced into code by programmer (not always programmer's fault, if, e.g., requirements changed) ● Defect may cause infection of program state during execution (not all defects cause infection) ● Infected state propagates during execution (infected parts of states may be overwritten or corrected) ● Infection may cause a failure: an externally observable error (including, e.g., non-termination) Terminology ● Testing - Check for bugs ● Debugging – Relating a failure to a defect (systematically find source of failure) ● Specification - Describe what is a bug ● (Formal) Verification - Prove that there are no bugs Cost of certainty Formal Verification Property based testing Unit testing Man hours (*) Graph not based on data, only indication More certainty = more work Contract metaphor Supplier: (callee) Implementer of method Client: (caller) Implementer of calling method or user Contract: Requires (precondition): What the client must ensure Ensures (postcondition): What the supplier must ensure ● Testing ● Formal specification ○ Unit testing ○ Logic ■ Coverage criteria ■ Propositional logic ● Control-Flow based ■ Predicate Logic ● Logic Based ■ SAT ■ Extreme Testing ■ SMT ■ Mutation testing ○ Dafny ○ Input
  • Executing UML Models

    Executing UML Models

    Executing UML Models Miguel Pinto Luz1, Alberto Rodrigues da Silva1 1Instituto Superior Técnico Av. Rovisco Pais 1049-001 Lisboa – Portugal {miguelluz, alberto.silva}@acm.org Abstract. Software development evolution is a history of permanent seeks for raising the abstraction level to new limits overcoming new frontiers. Executable UML (xUML) comes this way as the expectation to achieve the next level in abstraction, offering the capability of deploying a xUML model in a variety of software environments and platforms without any changes. This paper comes as a first expedition inside xUML, exploring the main aspects of its specification including the action languages support and the fundamental MDA compliance. In this paper is presented a future new xUML tool called XIS-xModels that gives Microsoft Visio new capabilities of running and debugging xUML models. This paper is an outline of the capabilities and main features of the future application. Keywords: UML, executable UML, Model Debugging, Action Language. 1. Introduction In a dictionary we find that an engineer is a person who uses scientific knowledge to solve practical problems, planning and directing, but an information technology engineer is someone that spends is time on implementing lines of code, instead of being focus on planning and projecting. Processes, meetings, models, documents, or even code are superfluous artifacts for organizations: all they need is well design and fast implemented working system, that moves them towards a new software development paradigm, based on high level executable models. According this new paradigm it should be possible to reduce development time and costs, and to bring new product quality warranties, only reachable by executing, debugging and testing early design stages (models).
  • Case No COMP/M.4747 Œ IBM / TELELOGIC REGULATION (EC)

    Case No COMP/M.4747 ΠIBM / TELELOGIC REGULATION (EC)

    EN This text is made available for information purposes only. A summary of this decision is published in all Community languages in the Official Journal of the European Union. Case No COMP/M.4747 – IBM / TELELOGIC Only the English text is authentic. REGULATION (EC) No 139/2004 MERGER PROCEDURE Article 8(1) Date: 05/03/2008 Brussels, 05/03/2008 C(2008) 823 final PUBLIC VERSION COMMISSION DECISION of 05/03/2008 declaring a concentration to be compatible with the common market and the EEA Agreement (Case No COMP/M.4747 - IBM/ TELELOGIC) COMMISSION DECISION of 05/03/2008 declaring a concentration to be compatible with the common market and the EEA Agreement (Case No COMP/M.4747 - IBM/ TELELOGIC) (Only the English text is authentic) (Text with EEA relevance) THE COMMISSION OF THE EUROPEAN COMMUNITIES, Having regard to the Treaty establishing the European Community, Having regard to the Agreement on the European Economic Area, and in particular Article 57 thereof, Having regard to Council Regulation (EC) No 139/2004 of 20 January 2004 on the control of concentrations between undertakings1, and in particular Article 8(1) thereof, Having regard to the Commission's decision of 3 October 2007 to initiate proceedings in this case, After consulting the Advisory Committee on Concentrations2, Having regard to the final report of the Hearing Officer in this case3, Whereas: 1 OJ L 24, 29.1.2004, p. 1 2 OJ C ...,...200. , p.... 3 OJ C ...,...200. , p.... 2 I. INTRODUCTION 1. On 29 August 2007, the Commission received a notification of a proposed concentration pursuant to Article 4 and following a referral pursuant to Article 4(5) of Council Regulation (EC) No 139/2004 ("the Merger Regulation") by which the undertaking International Business Machines Corporation ("IBM", USA) acquires within the meaning of Article 3(1)(b) of the Council Regulation control of the whole of the undertaking Telelogic AB ("Telelogic", Sweden) by way of a public bid which was announced on 11 June 2007.
  • Challenges and Opportunity of UML Diagram for Software Project Development As a Complete Modeling Tool

    Challenges and Opportunity of UML Diagram for Software Project Development As a Complete Modeling Tool

    IOSR Journal of Mobile Computing & Application (IOSR-JMCA) e- ISSN: 2394-0050, P-ISSN: 2394-0042.Volume 7, Issue 3 (May - June 2020), PP 46-48 www.iosrjournals.org Challenges and Opportunity of UML Diagram for Software Project development as a complete Modeling Tool Ketema Kifle Gebretsadik1 Debre Markos University, School of Computing, Institute of Technology, Debre Markos, Ethiopia Abstract: UML(Unified Modeling Language) is a most useful method of visualization and documenting software systems design.UML uses object oriented design concepts and it is independent of specific programming language. Unified Modeling Language is a popular technique for documenting and modeling system. The UML uses set of symbols to represent graphically the various components and relationships within the system and UML can be used for business processing modeling and requirements modeling, it mainly is used to support object oriented system analysis and to develop the object models. Many articles describe UML features, but only very few of them discuss its downside in software design. This article discusses the downside of UML as a complete modeling tool for software design. Some of the disadvantages of UML areno specification for modeling of user interfaces, business rule specification a group exists for this within theObject Management Group(OMG), so we should see something in UML and Poor for distributed systems are no way to formally specify serialization and object persistence.Even though UML have many advantages it has also their owndownside for software design. Keyword: UML, Challenge of UML, Software design, UML diagrams ----------------------------------------------------------------------------------------------------------------------------- ---------- Date of Submission: 22-05-2020 Date of Acceptance: 09-06-2020 ----------------------------------------------------------------------------------------------------------------------------- ---------- I.
  • Fakulta Informatiky UML Modeling Tools for Blind People Bakalářská

    Fakulta Informatiky UML Modeling Tools for Blind People Bakalářská

    Masarykova univerzita Fakulta informatiky UML modeling tools for blind people Bakalářská práce Lukáš Tyrychtr 2017 MASARYKOVA UNIVERZITA Fakulta informatiky ZADÁNÍ BAKALÁŘSKÉ PRÁCE Student: Lukáš Tyrychtr Program: Aplikovaná informatika Obor: Aplikovaná informatika Specializace: Bez specializace Garant oboru: prof. RNDr. Jiří Barnat, Ph.D. Vedoucí práce: Mgr. Dalibor Toth Katedra: Katedra počítačových systémů a komunikací Název práce: Nástroje pro UML modelování pro nevidomé Název práce anglicky: UML modeling tools for blind people Zadání: The thesis will focus on software engineering modeling tools for blind people, mainly at com•monly used models -UML and ERD (Plant UML, bachelor thesis of Bc. Mikulášek -Models of Structured Analysis for Blind Persons -2009). Student will evaluate identified tools and he will also try to contact another similar centers which cooperate in this domain (e.g. Karlsruhe Institute of Technology, Tsukuba University of Technology). The thesis will also contain Plant UML tool outputs evaluation in three categories -students of Software engineering at Faculty of Informatics, MU, Brno; lecturers of the same course; person without UML knowledge (e.g. customer) The thesis will contain short summary (2 standardized pages) of results in English (in case it will not be written in English). Literatura: ARLOW, Jim a Ila NEUSTADT. UML a unifikovaný proces vývoje aplikací : průvodce ana­lýzou a návrhem objektově orientovaného softwaru. Brno: Computer Press, 2003. xiii, 387. ISBN 807226947X. FOWLER, Martin a Kendall SCOTT. UML distilled : a brief guide to the standard object mode•ling language. 2nd ed. Boston: Addison-Wesley, 2000. xix, 186 s. ISBN 0-201-65783-X. Zadání bylo schváleno prostřednictvím IS MU. Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval(a) samostatně.
  • Different Types of Testing

    Different Types of Testing

    Different Types of Testing Performance testing a. Performance testing is designed to test run time performance of software within the context of an integrated system. It is not until all systems elements are fully integrated and certified as free of defects the true performance of a system can be ascertained b. Performance tests are often coupled with stress testing and often require both hardware and software infrastructure. That is, it is necessary to measure resource utilization in an exacting fashion. External instrumentation can monitor intervals, log events. By instrument the system, the tester can uncover situations that lead to degradations and possible system failure Security testing If your site requires firewalls, encryption, user authentication, financial transactions, or access to databases with sensitive data, you may need to test these and also test your site's overall protection against unauthorized internal or external access Exploratory Testing Often taken to mean a creative, internal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it Benefits Realization tests With the increased focus on the value of Business returns obtained from investments in information technology, this type of test or analysis is becoming more critical. The benefits realization test is a test or analysis conducted after an application is moved into production in order to determine whether the application is likely to deliver the original projected benefits. The analysis is usually conducted by the business user or client group who requested the project and results are reported back to executive management Mutation Testing Mutation testing is a method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes ('bugs') and retesting with the original test data/cases to determine if the 'bugs' are detected.
  • Guidelines on Minimum Standards for Developer Verification of Software

    Guidelines on Minimum Standards for Developer Verification of Software

    Guidelines on Minimum Standards for Developer Verification of Software Paul E. Black Barbara Guttman Vadim Okun Software and Systems Division Information Technology Laboratory July 2021 Abstract Executive Order (EO) 14028, Improving the Nation’s Cybersecurity, 12 May 2021, di- rects the National Institute of Standards and Technology (NIST) to recommend minimum standards for software testing within 60 days. This document describes eleven recommen- dations for software verification techniques as well as providing supplemental information about the techniques and references for further information. It recommends the following techniques: • Threat modeling to look for design-level security issues • Automated testing for consistency and to minimize human effort • Static code scanning to look for top bugs • Heuristic tools to look for possible hardcoded secrets • Use of built-in checks and protections • “Black box” test cases • Code-based structural test cases • Historical test cases • Fuzzing • Web app scanners, if applicable • Address included code (libraries, packages, services) The document does not address the totality of software verification, but instead recom- mends techniques that are broadly applicable and form the minimum standards. The document was developed by NIST in consultation with the National Security Agency. Additionally, we received input from numerous outside organizations through papers sub- mitted to a NIST workshop on the Executive Order held in early June, 2021 and discussion at the workshop as well as follow up with several of the submitters. Keywords software assurance; verification; testing; static analysis; fuzzing; code review; software security. Disclaimer Any mention of commercial products or reference to commercial organizations is for infor- mation only; it does not imply recommendation or endorsement by NIST, nor is it intended to imply that the products mentioned are necessarily the best available for the purpose.
  • UML Modelleme Araçlarının Pratik Kullanım Için Analizi

    UML Modelleme Araçlarının Pratik Kullanım Için Analizi

    UML Modelleme Araçlarının Pratik Kullanım için Analizi Mert Ozkaya1 and Ferhat Erata2 1 Yeditepe Üniversitesi , Ataşehir, İstanbul [email protected] 2 UNIT Bilgi Teknolojileri R&D Ltd., Bornova, Izmir [email protected] Özet. Günümüzde, Unified Modeling Language(UML) pratisyenler tarafından en sık tercih edilen yazılım sistemi modelleme ve tasarlama notasyonu olarak kabul edilmektedir. UML, aynı zamanda, birçok yazılım modelleme aracı tarafın- dan desteklenmektedir, ve bu araçlar sayesinde, pratisyenler yazılım sistem- lerini kolayca UML notasyonunu kullanarak modelleyebilir ve analiz, yazılım kodu üretme, ve işbirliği gibi birçok faydalı değişik işlemler gerçekleştirebilirler. Bu çalışmada, tanınan 11 farklı UML modelleme aracını pratisyenlerin UML’i benimsemeleri açısından önemli olduğunu düşündüğümüz bir grup gereksinim bakımından analiz ettik. Bu gereksinimler başlıca, modellerin tasarımı, model analizi, modelden kod üretme, iş-birliği halinde modelleme, ve genişletilebilir- lik olmaktadır. Model tasarımı gereksinimi, modelleme araçlarının UML diya- gramlarına olan destekleri, yazılım modelleme bakış-açılarına olan destekleri, ve büyük ve karmaşık yazılım modellerinin tasarımına olan destekleri açıların- dan ele alınmaktadır. Model analizi gereksinimi, simülasyon ve doğrulama (hem önceden tanımlanmış doğrulama hem de kullanıcı tanımlı doğrulama) gereksin- imlerine olan destek bakımından incelenmektedir. İş-birliği halinde modelleme gereksinimi ise, senkron ve asenkron olarak çoklu kullanıcı desteği, görev yöne-