DOCSLIB.ORG

Graphical Debugging of Distributed Applications Using UML Object Diagrams to Visualize the State of Distributed Applications at Runtime

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Graphical Debugging of Distributed Applications Using UML Object Diagrams to Visualize the State of Distributed Applications at Runtime Andreas Koch and Albert Zundorf¨ Software Engineering Research Institute, Kassel University, Wilhelmshoher¨ Allee 73, Kassel, Germany Keywords: Tool, Debug, Distributed, UML2, Objectdiagram, Eclipse. Abstract: While debugging is one of the most time consuming tasks software developers perform, the tool support, especially for distributed applications, is lacking according to many professional developers. The Visual De- bugger is an approach to provide an easy-to-use tool which gives software developers an abstract view on the current state of their application in debugging sessions. While similar tools for non distributed applications al- ready exist, the Visual Debugger addresses the more complex debugging scenarios in distributed applications. Therefore, several views with different levels of abstraction of the current state of an application are provided. Although the approach may be adapted to other object oriented programming languages, the current target of the Visual Debugger is languages running on the Java Virtual Machine with the focus on Java. 1 INTRODUCTION The steps 1, 3 and 4 are already well supported by tools and frameworks like logging or testing frame- Debugging is one of the most time consuming tasks in works, mature source code editors and more. In con- the daily work of a software developer. To tackle this trast, the second step is the most crucial and most time challenge, many tools were developed in research as consuming part of this process because there are a lot well as in the industry. Additionally, in each modern of different sources of an unwanted behaviour, that IDE as Eclipse, IntelliJ IDEA or NetBeans some kind must be considered: logical failures in algorithms, of debugging support is already integrated. Although performance issues, not catched exceptions and many so much work was invested into this area, there are more. still many professional software developers not sat- Most of these sources result in the same simple isfied with the provided support of debugging tools. outcome: values are changed or not changed as ex- (Layman et al., 2013) pected. To find a reproducible test scenario to trigger Started in a research project with industrial part- unwanted behaviour can be challenging. But even if ners, the Visual Debugger presented in this paper is this scenario is found, the search for the erroneous an approach to fill the gap of an easy-to-use, but help- source code is difficult. One common problem is the ful visualization of the state of distributed and non inability to understand the current state of the appli- distributed Java applications as a helper in debugging cation in a reasonable amount of time when the un- sessions. wanted behaviour occurs. To explain the usage of the Visual Debugger, at Apart from the research area, in the industry, most first it must be positioned in the debugging process. available debugging tools focus on a textual view on This process can be separated into several steps: the application state. One example, which can be 1. An unwanted behaviour of an application takes found in most IDEs and therefore is probably the most place. used tool during debugging sessions, is a tree repre- 2. The problematic part of the source code is located. sentation of the runtime state of objects like the vari- ables view in the Eclipse IDE in figure 1. This has 3. The source code is changed to prevent this be- indeed proven to be useful in many debugging situa- haviour. tions, but tends to be less helpful in object oriented 4. The test scenario is reproduced to ensure this programming languages when the application state changed behaviour is correct. becomes more complex. One reason is the visualiza- Koch A. and Zündorf A.. 223 Graphical Debugging of Distributed Applications - Using UML Object Diagrams to Visualize the State of Distributed Applications at Runtime. DOI: 10.5220/0005233202230230 In Proceedings of the 3rd International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2015), pages 223-230 ISBN: 978-989-758-083-3 Copyright c 2015 SCITEPRESS (Science and Technology Publications, Lda.) MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment non distributed applications have, the Visual Debug- ger provides two modes. One, which targets mainly on applications running in a single JVM and another mode, that adds additional functionality to support the visualization of distributed applications. This paper focuses on the second mode, but explains in the fol- lowing sections some basic behaviour which is valid for both modes and necessary to understand the sec- tions focused on distributed scenarios. Figure 1: A snippet of the Java heap in the Eclipse variables view. 2 RELATED WORK tion of a graph structure in a tree. Relations between objects are only visible from one object to another. Although graphical debugging tools are researched This results in duplications of objects in the variables quite well, they are rarely found as commercial prod- view, when different objects have relations with the uct. Especially when distributed applications come same child. As an example: browsing the state of the into play, most existing tools are limited in their us- topmost object in figure 1 (id=476), the highlighted ability. Besides, many of these tools focus on visu- object with id 427 is reachable (and therefore visible) alizing program behaviour instead of the application three times with different paths. Another reason this state. view is problematic in distributed (or concurrent) sce- Some tools that follow a similar idea as the Visual narios is, it only provides data for the current state Debugger are Jive (Gestwicki and Jayaraman, 2005) the user is looking at. Resuming the program exe- and the eDobs (Geiger and Zundorf,¨ 2002) (Geiger cution results in losing the current viewpoint and the and Zundorf,¨ 2006). But both tools lack of support for state needs to be re-evaluated again at the next inter- the special requirements of distributed applications. ruption of the execution. The situation is worsened There are tools, that are targeted at distributed ap- when a distributed application comes into play. This plications, but serve a different use case. One ex- increases the complexity of the state of an applica- ample for this tool section is the JRastro (da Silva tion. Usually objects live on different Java Virtual et al., 2003). While the Visual Debugger provides Machines (JVM) on the same or even on physically an abstract view on the state of the application during separated devices. the execution, JRastro helps with finding performance Hereinafter, the terms object and instance are used problems by visualizing the communication between in the following way. While the term instance is used the different nodes of the application. Tools follow- to describe the instantiation of a class in a (single) ing a similar idea than JRastro are Atropos (Lonnberg¨ JVM, object is used when two or more equals in- et al., 2011), JACOT (Leroux et al., 2003) or JaVis stances on different JVMs are meant. (Mehner, 2001). Understanding the current state of a distributed JAVAVIS (Oechsle and Schmitt, 2001) shows the application becomes more difficult, because during internal behaviour and state of an application with a debugging session much more state changes take UML sequence and object diagrams. But its usability place. Each time the developer is forcedoo to re- for distributed applications is limited as it is targeted evaluate the state. The identification of different in- on sequential program execution. stances of an object on different JVMs complicates a JAN (Lohr¨ and Vratislavsky, 2003) uses object di- debugging session as these state changes force devel- agrams to visualize the state of an application, but its opers to identify equal instances on different JVMs focus is on the animation of different states of an ap- again and again. Additionally, unexpected program plication to understand the behaviour of a program in- behaviour is more difficult to reproduce, which of- stead of debugging it. ten results in repeatedly executed debugging sessions until the unwanted behaviour appears again and the source behind it can be located. During the debug- ging sessions a lot of time is spent to understand the 3 ARCHITECTURE OF THE current state. The focus of the Visual Debugger is to VISUAL DEBUGGER provide an abstract view on the part of the application state that is relevant for a debugging session. To visualize a complex graph structure like the Java Due to the different requirements distributed and heap, an obvious choice is to use an object diagram. 224 GraphicalDebuggingofDistributedApplications-UsingUMLObjectDiagramstoVisualizetheStateofDistributed ApplicationsatRuntime In the Visual Debugger standard UML2 object dia- lated to the source code and are triggered, for exam- grams are used. While this forced us to use a strongly ple, when a specific line in the source code is exe- formalized and predefined syntax, it provides easy in- cuted, a method is called or the field of an object is teroperability with other tools. Each model created changed. Besides, there are events that notify about during a debugging session can be used as input in started/stopped threads respectively loaded/unloaded other UML compatible tools, for example as part of classes in a JVM or state changes of the JVM itself. the test documentation. On top of the JDI, Eclipse delivers with the JDT Three of the main design goals were to create ac- an easy-to-use layer to access the heap of a JVM. ceptance, simplicity and usability. Creating accep- The JDT is a mature framework and used in almost tance is difficult because many software developers all debugging tools integrated into the Eclipse IDE. have an existing workflow and a given set of tools It provides utilities to register requests, collect values they use in their daily work.
Recommended publications
  • Analysis and Exploration for New Generation Debuggers Thomas Dupriez, Guillermo Polito, Stéphane Ducasse

    Analysis and Exploration for New Generation Debuggers Thomas Dupriez, Guillermo Polito, Stéphane Ducasse

    Analysis and exploration for new generation debuggers Thomas Dupriez, Guillermo Polito, Stéphane Ducasse To cite this version: Thomas Dupriez, Guillermo Polito, Stéphane Ducasse. Analysis and exploration for new generation debuggers. International Workshop on Smalltalk Technology IWST’17, Sep 2017, Maribor, Slovenia. pp.5:1–5:6, 10.1145/3139903.3139910. hal-01585338 HAL Id: hal-01585338 https://hal.archives-ouvertes.fr/hal-01585338 Submitted on 11 Sep 2017 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Analysis and exploration for new generation debuggers Thomas Dupriez Guillermo Polito Stephane´ Ducasse ENS Paris-Saclay - RMoD, Inria RMoD - Univ. Lille, CNRS, Centrale RMoD, Inria Lille-Nord Europe Lille-Nord Europe Lille, Inria, UMR 9189 - CRIStAL - [email protected] [email protected] Centre de Recherche en Informatique Signal et Automatique de Lille, F-59000 Lille, France [email protected] Abstract offer a different perspective to this problem: it should be Locating and fixing bugs is a well-known time consuming possible to adapt a debugger to a given domain or task. task. Advanced approaches such as object-centric or back- In this position paper we motivate the need to mature and in-time debuggers have been proposed in the literature, still develop more advanced techniques by showing a complex in many scenarios developers are left alone with primitive debugging scenario obtained from a real use case.
  • Writing and Reviewing Use-Case Descriptions

    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.
  • Document Title Requirements on Debugging in AUTOSAR

    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.
  • The Guide to Succeeding with Use Cases

    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.
  • INCOSE: the FAR Approach “Functional Analysis/Allocation and Requirements Flowdown Using Use Case Realizations”

    INCOSE: the FAR Approach “Functional Analysis/Allocation and Requirements Flowdown Using Use Case Realizations”

    in Proceedings of the 16th Intern. Symposium of the International Council on Systems Engineering (INCOSE'06), Orlando, FL, USA, Jul 2006. The FAR Approach – Functional Analysis/Allocation and Requirements Flowdown Using Use Case Realizations Magnus Eriksson1,2, Kjell Borg1, Jürgen Börstler2 1BAE Systems Hägglunds AB 2Umeå University SE-891 82 Örnsköldsvik SE-901 87 Umeå Sweden Sweden {magnus.eriksson, kjell.borg}@baesystems.se {magnuse, jubo}@cs.umu.se Copyright © 2006 by Magnus Eriksson, Kjell Borg and Jürgen Börstler. Published and used by INCOSE with permission. Abstract. This paper describes a use case driven approach for functional analysis/allocation and requirements flowdown. The approach utilizes use cases and use case realizations for functional architecture modeling, which in turn form the basis for design synthesis and requirements flowdown. We refer to this approach as the FAR (Functional Architecture by use case Realizations) approach. The FAR approach is currently applied in several large-scale defense projects within BAE Systems Hägglunds AB and the experience so far is quite positive. The approach is illustrated throughout the paper using the well known Automatic Teller Machine (ATM) example. INTRODUCTION Organizations developing software intensive defense systems, for example vehicles, are today faced with a number of challenges. These challenges are related to the characteristics of both the market place and the system domain. • Systems are growing ever more complex, consisting of tightly integrated mechanical, electrical/electronic and software components. • Systems have very long life spans, typically 30 years or longer. • Due to reduced acquisition budgets, these systems are often developed in relatively short series; ranging from only a few to several hundred units.
  • Devops for Hybrid Cloud: an IBM Point of View

    Devops for Hybrid Cloud: an IBM Point of View

    IBM Cloud July 2017 Thought Leadership White Paper DevOps for hybrid cloud: an IBM point of view How DevOps for hybrid cloud can help organizations succeed with digital reinvention 2 DevOps for hybrid cloud: an IBM point of view Introduction The IBM point of view on DevOps makes the following DevOps started as a culture and set of practices to support assumptions: collaboration and communication across development and oper- ations, and to apply automation to key phases of the software ●● DevOps covers the end-to-end software delivery lifecycle delivery process. It has been popularized by successful new including an expanded set of stakeholders such as business companies developing business models and related applications owners and end users, and practices such as design thinking empowered by the cloud (cloud-native applications). More and user analytics. recently, large, established enterprises have recognized the need ●● DevOps adoption is expanding in large organizations as they to deliver innovation faster to stay relevant and capitalize on enable existing IT applications for cloud (cloud-enabled industry disruption, while also improving operational metrics for applications). New methods enable organizations to success- application quality and cost. DevOps and cloud have emerged as fully implement DevOps as they move to cloud. essential parts of their IT strategy as they improve core compe- ●● Hybrid cloud architecture is becoming the norm for both tency in continuous delivery of software-driven innovation. cloud-enabled and cloud-native applications. Hybrid cloud provides flexibility in deployment, enabling organizations to choose the right platform to run their workloads. ●● DevOps solutions can vary as teams across large organizations Business as usual have different goals, processes, culture and tools.
  • Plantuml Language Reference Guide (Version 1.2021.2)

    Plantuml Language Reference Guide (Version 1.2021.2)

    Drawing UML with PlantUML PlantUML Language Reference Guide (Version 1.2021.2) PlantUML is a component that allows to quickly write : • Sequence diagram • Usecase diagram • Class diagram • Object diagram • Activity diagram • Component diagram • Deployment diagram • State diagram • Timing diagram The following non-UML diagrams are also supported: • JSON Data • YAML Data • Network diagram (nwdiag) • Wireframe graphical interface • Archimate diagram • Specification and Description Language (SDL) • Ditaa diagram • Gantt diagram • MindMap diagram • Work Breakdown Structure diagram • Mathematic with AsciiMath or JLaTeXMath notation • Entity Relationship diagram Diagrams are defined using a simple and intuitive language. 1 SEQUENCE DIAGRAM 1 Sequence Diagram 1.1 Basic examples The sequence -> is used to draw a message between two participants. Participants do not have to be explicitly declared. To have a dotted arrow, you use --> It is also possible to use <- and <--. That does not change the drawing, but may improve readability. Note that this is only true for sequence diagrams, rules are different for the other diagrams. @startuml Alice -> Bob: Authentication Request Bob --> Alice: Authentication Response Alice -> Bob: Another authentication Request Alice <-- Bob: Another authentication Response @enduml 1.2 Declaring participant If the keyword participant is used to declare a participant, more control on that participant is possible. The order of declaration will be the (default) order of display. Using these other keywords to declare participants
  • 21 Scenario-Based Programming, Usability-Oriented Perception

    21 Scenario-Based Programming, Usability-Oriented Perception

    Scenario-Based Programming, Usability-Oriented Perception GIORA ALEXANDRON, MICHAL ARMONI, MICHAL GORDON, and DAVID HAREL, Weizmann Institute of Science In this article, we discuss the possible connection between the programming language and the paradigm behind it, and programmers’ tendency to adopt an external or internal perspective of the system they develop. Based on a qualitative analysis, we found that when working with the visual, interobject language of live sequence charts (LSC), programmers tend to adopt an external and usability-oriented view of the system, whereas when working with an intraobject language, they tend to adopt an internal and implementation- oriented viewpoint. This is explained by first discussing the possible effect of the programming paradigm on programmers’ perception and then offering a more comprehensive explanation. The latter is based on a cognitive model of programming with LSC, which is an interpretation and a projection of the model suggested by Adelson and Soloway [1985] onto LSC and scenario-based programming, the new paradigm on which LSC is based. Our model suggests that LSC fosters a kind of programming that enables iterative refinement of the artifact with fewer entries into the solution domain. Thus, the programmer can make less context switching between the solution domain and the problem domain, and consequently spend more time in the latter. We believe that these findings are interesting mainly in two ways. First, they characterize an aspect of problem-solving behavior that to the best of our knowledge has not been studied before—the programmer’s perspective. The perspective can potentially affect the outcome of the problem-solving process, such as by leading the programmer to focus on different parts of the problem.
  • Use Case Tutorial Version X.X ● April 18, 2016

    Use Case Tutorial Version X.X ● April 18, 2016

    Use Case Tutorial Version X.x ● April 18, 2016 Company Name Limited Street City, State ZIP Country phone: +1 000 123 4567 Company Name Limited Street City, State ZIP Country phone: +1 000 123 4567 Company Name Limited Street City, State ZIP Country phone: +1 000 123 4567 www.website.com [Company Name] [Document Name] [Project Name] [Version Number] Table of Contents Introduction ..............................................................................................3 1. Use cases and activity diagrams .......................................................4 1.1. Use case modelling ....................................................................4 1.2. Use cases and activity diagrams ..................................................7 1.3. Actors .......................................................................................7 1.4. Describing use cases.................................................................. 8 1.5. Scenarios ................................................................................10 1.6. More about actors ....................................................................13 1.7. Modelling the relationships between use cases ...........................15 1.8. Stereotypes .............................................................................15 1.9. Sharing behaviour between use cases........................................ 16 1.10. Alternatives to the main success scenario ..................................17 1.11. To extend or include? ...............................................................20
  • User-Stories-Applied-Mike-Cohn.Pdf

    User-Stories-Applied-Mike-Cohn.Pdf

    ptg User Stories Applied ptg From the Library of www.wowebook.com The Addison-Wesley Signature Series The Addison-Wesley Signature Series provides readers with practical and authoritative information on the latest trends in modern technology for computer professionals. The series is based on one simple premise: great books come from great authors. Books in the series are personally chosen by expert advi- sors, world-class authors in their own right. These experts are proud to put their signatures on the cov- ers, and their signatures ensure that these thought leaders have worked closely with authors to define topic coverage, book scope, critical content, and overall uniqueness. The expert signatures also symbol- ize a promise to our readers: you are reading a future classic. The Addison-Wesley Signature Series Signers: Kent Beck and Martin Fowler Kent Beck has pioneered people-oriented technologies like JUnit, Extreme Programming, and patterns for software development. Kent is interested in helping teams do well by doing good — finding a style of software development that simultaneously satisfies economic, aesthetic, emotional, and practical con- straints. His books focus on touching the lives of the creators and users of software. Martin Fowler has been a pioneer of object technology in enterprise applications. His central concern is how to design software well. He focuses on getting to the heart of how to build enterprise software that will last well into the future. He is interested in looking behind the specifics of technologies to the patterns, ptg practices, and principles that last for many years; these books should be usable a decade from now.
  • UNIT 1 UML DIAGRAMS Introduction to OOAD – Unified Process

    UNIT 1 UML DIAGRAMS Introduction to OOAD – Unified Process

    VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE UNIT 1 UML DIAGRAMS Introduction to OOAD – Unified Process - UML diagrams – Use Case – Class Diagrams– Interaction Diagrams – State Diagrams – Activity Diagrams – Package, component and Deployment Diagrams. INTRODUCTION TO OOAD ANALYSIS Analysis is a creative activity or an investigation of the problem and requirements. Eg. To develop a Banking system Analysis: How the system will be used? Who are the users? What are its functionalities? DESIGN Design is to provide a conceptual solution that satisfies the requirements of a given problem. Eg. For a Book Bank System Design: Bank(Bank name, No of Members, Address) Student(Membership No,Name,Book Name, Amount Paid) OBJECT ORIENTED ANALYSIS (OOA) Object Oriented Analysis is a process of identifying classes that plays an important role in achieving system goals and requirements. Eg. For a Book Bank System, Classes or Objects identified are Book-details, Student-details, Membership-Details. OBJECT ORIENTED DESIGN (OOD) Object Oriented Design is to design the classes identified during analysis phase and to provide the relationship that exists between them that satisfies the requirements. Eg. Book Bank System Class name Book-Bank (Book-Name, No-of-Members, Address) Student (Name, Membership No, Amount-Paid) OBJECT ORIENTED ANALYSIS AND DESIGN (OOAD) • OOAD is a Software Engineering approach that models an application by a set of Software Development Activities. YEAR/SEM: III/V CS6502-OOAD Page 1 VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE • OOAD emphasis on identifying, describing and defining the software objects and shows how they collaborate with one another to fulfill the requirements by applying the object oriented paradigm and visual modeling throughout the development life cycles.
  • Scenario-Driven Continuous Mobility Requirements Analysis in Mobile App Maintenance

    Scenario-Driven Continuous Mobility Requirements Analysis in Mobile App Maintenance

    Scenario-Driven Continuous Mobility Requirements Analysis in Mobile App Maintenance Xiaozhou Li1, Zheying Zhang2 and Timo Poranen3 1 University of Tampere, Kalevantie 4, 33014, Tampere, Finland {xiaozhou.li; zheying.zhang; timo.t.poranen}@uta.fi Abstract. As mobile devices have become an indispensable part of people’s lives, the growth of mobile app market is inevitably rapid. Accordingly, the mobile app users have increasing demands on the quality of the apps. Their tol- erance towards bugs and poor usability of the apps is growing low. In addition, as the mobile devices and apps have enabled users to use them in various con- texts, the mobility of the apps, referred to as their capability to provide ubiqui- tous services with quality, is also required. In this study, we propose the scenar- io-driven approach of mobility requirements analysis with context and ways of interaction. It supports the continuous requirements analysis in the maintenance of mobile apps where their mobility is constantly maintained despite the chang- es in the features. Keywords: Mobile App, Mobility, Requirements, Scenario, Situational Con- texts, Interaction, Maintenance. 1 Introduction The mobility of mobile apps, as their most significant feature, is defined as the ability to access services ubiquitously, on the move, though wireless networks and various mobile devices [1]. It enables the users to access the services with the independence from time and space [2]. The mobility of mobile apps is closely related to their con- text of use, especially the situational context, which largely influences the post- adoption behaviors of the users, including use continuance, word-of-mouth, and com- plaints [3].